Work Handoff

Produce a standalone work contract, not a conversation summary. Someone arriving in a fresh session must understand what the work is, why it matters, what is already decided, what must remain true, and how to recognize a useful result. The recipient may need to investigate the actual codebase, but must not need the source chat to recover the intent.

A handoff can be pasted into another agent session, stored as a document, or published as a GitHub issue. This skill owns the meaning; the destination does not change that meaning. Use github-issue for publishing, relationships, metadata, and other GitHub-specific management. Neither skill creates permission to implement an unapproved idea.

Scope and authority

• Preserve accepted intent, requirements, constraints, exclusions, and relevant decisions. A question, example, agent proposal, or convenient implementation is not automatically approved.
• Treat later explicit corrections as superseding earlier suggestions. Preserve unresolved contradictions as decisions, not as invented conclusions.
• Explain the required outcome before prescribing a mechanism. Include a required method or interface only when it was actually established.
• Distinguish observations, reported symptoms, hypotheses, and unverified repository claims. Do not invent root causes, reproduction steps, paths, sources, tests, or owners.
• Do not convert the handoff into a scheduler, fixed agent chain, task-by-file breakdown, or authorization to modify code. The recipient uses its normal project instructions and planning/review practices.
• An issue or another session may be the destination, not the source of authority. Publishing does not approve an undecided product choice.

Method