skills/handover/SKILL.md
Generates a comprehensive handover document for another AI agent to seamlessly continue work on a task without prior context. Use when asked to "handover", "save state", "switch providers", "switch to claude/codex/opencode/cursor", or prepare a summary for the next AI session. Also use when moving work between directories of the same repository.
npx skillsauth add cvscarlos/ai-skills handoverInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Generate a structured handover file (tmp/HANDOVER.md) that captures enough context for any AI agent — regardless of provider or tool — to continue the current task from scratch.
If there are uncommitted changes, commit them before creating the handover so nothing is lost:
git status --short
# If changes exist:
git add <relevant-files>
git commit -m "wip: save progress before handover"
Run these commands and capture output:
# Branch and repo
git branch --show-current
git remote get-url origin
# Detect base branch: PR base → main → master
BASE=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null \
|| (git rev-parse --verify main 2>/dev/null && echo main) \
|| echo master)
# Recent commits on this branch (since diverging from base)
git log --oneline "$BASE"..HEAD
# Uncommitted changes (if any remain)
git status --short
git diff --stat
# PR context (if any)
gh pr view --json number,title,url,state,baseRefName,reviewDecision 2>/dev/null
From the conversation history, identify:
tmp/ exists and is in .gitignore.tmp/HANDOVER.md.Before writing the file, verify:
Reply: "Handover saved to tmp/HANDOVER.md. To resume: cat tmp/HANDOVER.md"
AGENTS.md, README, Makefile, package.json, etc.Too vague — useless to the next agent:
## Progress
- Did some stuff with the API
- Made progress on auth
## Next Steps
- Finish the feature
Missing context — leaves the next agent guessing:
## Progress
- [x] Implemented the auth module
## Next Steps
- Fix the tests
No explanation of WHICH tests are failing, WHY they fail, or what was already tried.
# Handover
> **Date:** YYYY-MM-DD
> **Repository:** <remote-url>
> **Branch:** `<current-branch>`
> **PR:** <PR-url-or-"N/A">
> **Completion:** <estimated % and one-line summary of what's done vs remaining>
## Objective
<1-3 sentences: what feature, fix, or refactor is in progress and why>
## Progress
### Done
- [x] <completed task — include file paths, function names, commit hashes>
- [x] <completed task>
### In Progress
- [ ] <partially-done task — describe current state and what remains>
### Remaining
- [ ] <not-yet-started task>
## What Didn't Work
- <failed approach> → <why it was abandoned>
- <approach that hit a dead end> → <what went wrong>
## Key Decisions
| Decision | Rationale |
| ---------- | --------- |
| <decision> | <why> |
## Gotchas
- <non-obvious issue that would waste time if rediscovered>
- <important context the next agent needs>
## Test Status
- **Passing:** <yes/no/partial>
- **Failing:** <specific test failures or "none">
## Blockers
<failing tests, unresolved errors, open questions — or "None">
## Next Steps
1. <specific first action to take>
2. <subsequent action>
3. <subsequent action>
## Key Files to Read First
1. `<path/to/file>` — <why it's important>
2. `<path/to/file>` — <why it's important>
testing
Decide whether a GitHub PR can be approved, then optionally write and submit the approval comment when the user explicitly authorizes it. Use when the user says "review this PR", "review PR
tools
Writes human-friendly Markdown documentation for non-developer audiences — Implementation, product, project, CS, support, QA, ops, business analysts. Explains how a feature works, how to set it up or configure it for a client, how it ties to business rules and the product roadmap — for technical readers who don't read code. Code blocks appear only when the reader will copy, paste, send, or recognize them (embed snippets, config values, sample payloads) — not to explain how the system is built. Use when asked to "document this for the implementation team", "write a guide for product / PM / CS", "explain how X works for non-devs", or for setup guides, runbooks, FAQs, hand-off docs aimed at internal non-dev teams. Also use when adding or editing a Markdown file inside the repo's `docs/` folder for a non-developer audience. Do NOT use for API reference, developer READMEs, code-level docs (JSDoc, docstrings), or framework / testing guides — those are different docs.
development
Run a Socket.dev supply-chain check before installing, updating, or executing any npm package. Triggers on `npm install/i/add/update/upgrade <pkg>`, `yarn add/upgrade/dlx`, `pnpm add/install/update/dlx`, `bun add/install`, `npx`, `pnpx`, `bunx`, or any phrase that adds/bumps a Node dependency ("let's use <pkg>", "install X", "bump <pkg>"), including direct `package.json` edits. Use this skill EVEN IF the user did not ask — npm typosquats, malware, and malicious postinstall scripts are common, and one extra check beats days of cleanup. Checks Socket score, malware verdicts, install scripts, capabilities, CVEs, and maintainer trust, then decides PROCEED, WARN, or ABORT.
development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.