← ClaudeAtlas

agent-handoff-docslisted

Documentation framework for multi-session, multi-agent development — how to structure project docs so the next agent (or human) picks up work cold. A four-document split with declared canonical scope: REQUIREMENTS (with an acceptance-criteria status table), as-built ARCHITECTURE, REPORT (history and measurements), and one living HANDOFF; plus a START_HERE kickoff file and a task ledger that doubles as a delegation spec. Use on symptoms like "handoff docs keep going stale", "stale docs", "documentation restructuring", "living handoff", "onboarding a new agent onto an existing repository", "which document is the source of truth", dated handoff snapshots piling up, or 引き継ぎ資料の整理・要件定義書の逆起こし. Includes bilingual (EN/JA) templates.
h8nc4y/agent-handoff-docs · ★ 0 · Data & Documents · score 72
Install: claude install-skill h8nc4y/agent-handoff-docs
# Agent Handoff Docs A documentation framework for development that spans multiple agent sessions, multiple agent products, or agents working alongside humans. The next reader arrives with zero context. What they need is not more documentation — it is documentation whose ownership is unambiguous: every file states what it is the source of truth for, exactly one file states where work stands right now, and everything else can be compressed or deleted without fear of losing the only copy of a fact. The file names used below (REQUIREMENTS, ARCHITECTURE, REPORT, HANDOFF, START_HERE, TASKS) are conventions, not requirements. What matters is that the names are consistent across every repository you maintain, and that each document declares its scope at the top. ## When To Use - Work on a repository spans multiple sessions or is handed between agents (or between agents and humans), and every new session pays a re-discovery cost before producing anything. - Handoff documents keep going stale: dated snapshots pile up, "current state" appears in several files, and no reader trusts any of them. - You are onboarding a new agent onto an existing repository and want one kickoff prompt that works identically across every repository you own. - Implementation ran ahead of documentation and you need to reconstruct requirements after the fact (reverse-engineered requirements). - You are about to restructure a pile of legacy documents and need a target shape plus a safe migration