Handover
Personal agent skills for Claude Code, Codex, and other Agent Skills-compatible agents, distributed via local symlinks.
npx -y skills add gitt510/agent-skills --skill handoverAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 15 days oldThe repository was created 15 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Record task- or topic-level progress into a single HANDOVER.md. Use when updating a handover, logging progress, or summarizing work to hand off.
SKILL.md
4.5 KB, as published. Nobody here has run it
Handover
Goal: Record task/topic progress in a structured format that allows resuming work across multiple sessions and contexts.
The primary reader is the AI in the next session, not a human. Optimize for action: classify information by role (constraint / decision / state / task / reference), not by narrative. Markdown body with XML tags for section boundaries β tags make scope explicit; md keeps tables/code/lists cheap.
Output path
Save to the project root as HANDOVER.md:
HANDOVER.md
- Single file at the project root (no subdirectory, no slug)
- One file per project; overwrite/update in place
File format
---
title: <task/topic title>
updated: YYYY-MM-DD
status: <one-line: where we are + what remains>
sot: <paths to canonical sources this handover points at>
---
<constraints>
Rules that hold regardless of the task. Violating one breaks the system or
the SoT. State each as an imperative with the failure mode.
</constraints>
<decisions>
Settled. Do not relitigate. Record the rationale with each decision so the
next session does not reopen it.
</decisions>
<state>
What is done and verified (committed, tested, deployed). Facts only.
</state>
<tasks>
Each task is independently actionable and includes its completion check.
<task id="<slug>" priority="1">
What to do, with enough context to start without rereading the file.
constraint: <pointer into constraints, if the task is near a landmine>
verify: <observable condition that means done>
</task>
<task id="<slug>" priority="2" optional="true">
...
</task>
</tasks>
<reference>
Plain facts: tables, commands, paths, device/env identifiers, links to
issues/ADRs (`../issues/`, `../adr/`). Use md tables and code blocks here.
</reference>
Section rules:
- Omit a section if empty (e.g. no
<constraints>yet) β do not leave placeholder text. - Add
<blockers>between state and tasks when something is stuck on an external dependency. - Importance is expressed by section membership, not decoration: no bold for emphasis, no π₯-style markers. If everything is bold, nothing is.
- Tasks replace checkbox lists:
verifyis the checkbox. - Tags are delimiters for the model, not validated XML β no escaping needed; md syntax stays as-is inside them.
Workflow
0) Preconditions
- Must be inside a project directory.
1) Gather context
Review the conversation and existing handover file (if present), then classify each piece of information by role:
- constraint β must always hold; breaking it damages the system
- decision β settled choice with rationale
- state β done and verified
- task β remaining work, each with a verify condition
- reference β plain facts (paths, commands, tables, issue/ADR links)
A "learning" from the session is usually a constraint (if it guards future action) or a decision (if it closed an alternative) β file it there, not in a narrative section.
2) Draft handover
Create or update HANDOVER.md:
- If file exists: re-sort content into the role sections; move completed tasks into state, drop narrative that does not change future action
- If new file: create with the format above
- Update frontmatter
updatedto today andstatusto the current one-liner
3) Save file
Save as HANDOVER.md at the project root.
Rules
Required
- Save to
HANDOVER.mdat project root (invariant path) - One file per project (do not split)
- Every piece of content lives in exactly one role section
- Every task has a
verifycondition - Keep language consistent with conversation context (ζ₯ζ¬θͺ or English)
Prohibited
- Do NOT include secrets, tokens, passwords, or sensitive credentials
- Do NOT record work that wasn't actually done
- Do NOT treat handover as the single source of truth (SoT remains in issue/ADR)
- Do NOT delete all existing context without tracking/migration path
Related to SoT
- Handover is for continuity, not as the canonical source of truth
- Link to related issues/ADRs for authoritative requirements and decisions
- Use relative paths for cross-references:
../issues/,../adr/
Trigger hints (JP/EN)
- JP:
handover ζ΄ζ°γγ¦ - JP:
ι²ζθ¨ι²γγ¦ - JP:
γΏγΉγ―εΌηΆγγΎγ¨γγ¦ - JP:
HANDOVER.md γ«δΏεγγ¦ - EN:
update handover - EN:
record progress - EN:
save task handover - EN:
save to HANDOVER.md