Handover
Minimalistic, project-agnostic skills and rules for AI coding agents
npx -y skills add eai-org/agent-toolkit --skill handoverAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Use when handing finished work over to code review — writing a PR description or packaging a change for review by a human, an agent, or both.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.6 KB, as published. Nobody here has run it
Handover
Package a finished change so its reviewers never reconstruct intent from the diff. Write for a reviewer holding the diff and nothing else — no planning docs, no session, no knowledge that either exists.
Gather
Start the project's checks (tests, lint, build — whatever it defines) first, unless this session already ran them on this tree; read these while they run, skipping what doesn't exist:
- Decisions log — a
*.DECISIONS.mdbeside the task's plan. - Planning docs — the task's requirements, plan, and ticket in the project's planning directory.
- The session, when it produced the change: decisions, pivots, constraints.
- The diff against the target, plus commit subjects.
Each source once, no deeper than the artifact needs: skim the diff whole, deep-read only the files you will name in the Review guide, and never rebuild history commit by commit — which commit changed what is the diff's job, not yours.
Then match the plan's steps and acceptance criteria against the diff both ways — planned but absent, present but unplanned. Done when every source is read or confirmed absent and every planned item is matched.
Never invent rationale
State a "why" only where a source gives it. A deviation nothing explains is asked of the author once; unanswered or unaskable, it ships flagged in plain words ("nothing records why — worth confirming"), since it may be an unintentional gap rather than a decision. Sourcing is your gate, not the reviewer's reading: it decides what you may write, and never appears in the text. When not sure, always ask. Never guess.
The artifact
<slug>.HANDOVER.md beside the task's plan; if no planning directory → present the content and ask
where to save it. Its body is paste-ready as the PR description, and stands alone:
- Mention only what the reviewer can open — a tracker URL, or a file you verified is committed on the branch. Everything else — planning docs, decisions log, session, commit hashes — is neither linked nor named: write what it says ("this was meant to …"), never where it says it.
- Under a screen, ~400 words; the caps below are limits, not targets.
- Plain reviewer-facing wording, never this skill's vocabulary. Before drafting, actually invoke use-conversational-language — reciting its rules from memory does not count.
Sections, skipped only when truly empty:
- What and why — 2–3 lines.
- Decisions worth knowing — at most 5 lines, each: what was chosen or what departs from the plan, its why or the missing-why flag, and where in the code to see it.
- Testing — commands actually run with their real output, then what was not verified — untested paths, unmet or unchecked acceptance criteria, manual steps skipped. Describing what the tests cover is not evidence.
- Review guide — the few files where judgment matters and why; the rest named as mechanical.
- Known gaps — at most 3: shortcomings, assumptions, open questions.
Done when every section is filled or knowingly skipped, nothing reads as verified that wasn't, and nothing in the text points at something the reviewer cannot open.
Boundaries
- Modify no source files; the handover doc is the only file written.
- Never push, or open/comment on a PR — publishing is the user's explicit call.
- The project's own checks are in scope to run; anything beyond (deploys, migrations, data jobs) is not.