引き継ぎ可能な自己完結ドキュメントを書く

なぜこの skill があるか

別セッションのエージェントへ引き継ぐ成果物を書くとき、書き手の会話文脈が "のり" になる。ドキュメントに書かれていない前提を書き手は脳内で補完しながら読むため、本人には完成・自己完結して見える。だから書き手自身の自己点検では穴が見つからない。

この skill は、そういう「別セッションへ引き継ぐ前提の成果物」を自己完結に書くための規律と、書き終えたときに文脈ゼロで点検する動線を配る。

想定読者と方針

• 想定読者は会話文脈を持たない別セッションのエージェント。
• 人間向けの読みやすさ・簡潔さのために情報を削らない。削ると、別セッションで前提・判断の経緯が欠落し、設計意図とズレた実装に流れる。
• 簡潔さより文脈の完全性を優先する。長くてよい。 別セッションでそのまま動くために必要なコンテキストを漏れなく書き起こす方向に倒す。

自己完結性の規律 (漏らさず書く)

引き継ぎ先が会話文脈ゼロで読んで下流タスクに着手できるように、次を漏らさず書く:

• Why: なぜやるか、何の課題を解くか
• 決定の根拠: なぜこの判断にしたか
• 前提: 何を所与としているか
• 制約: 動かせない条件
• スコープ境界: やること / やらないこと
• 却下案とその理由: なぜ他の選択肢を採らなかったか (これがないと引き継ぎ先が同じ選択肢を再検討して時間を溶かす)
• 残タスクの続き: 残タスクは字面通りに着手できるだけでなく、続く可能性が高いこと (例: レビュー対応 → 再検証) に進める前提まで残す。ありうること全部でなく高確率なものに絞る
• やった検証・調査: 既にやった検証・調査は、その条件と結果を漏らさず残す (結論だけに畳まない)。条件には前提 (どんな環境・版で何を固定して確かめたか)・仕込み・手順・観測基準を含む — 結果はその前提の上でしか成り立たず、前提が落ちると次の人が結果を読み違える。再現・再確認できる形で書き、高確率で絞らず網羅する (既にやった事実だから)

表現の規律:

• 文脈なしで読めるように書く。会話文脈に依存する指示語・略号を持ち込まない (「案 A」「さっきのあれ」「上記の方針」で外部の会話を指す、など)。対象は具体名で書く。
• 番号・識別子だけで参照しない。内容で参照する。読み手は番号が指す中身を会話で共有していないので、番号だけでは伝わらない。

書き終えたら文脈ゼロで点検する (handoff-verifier を呼ぶ)

成果物を「自己完結した」「引き継げる」と宣言する前に、handoff-verifier subagent を呼んで文脈ゼロで点検する。書き手自身は会話文脈が "のり" になって穴が見えないので、自己点検では引き継ぎ可能性を担保できない。文脈ゼロの読み手を再現できるのは、会話を持たない独立の点検者だけ。

呼び出し側の規律 (文脈ゼロを壊さないために必須):

• handoff-verifier を呼ぶとき、渡すのは成果物のファイルパスと下流タスクの指定だけ (例「この要件定義から実装に着手できるか」)。
• 会話の背景・要約・意図の補足を渡す指示に書かない。背景を書くと、引き継ぎ先の条件 (会話文脈ゼロ) が再現できず、点検の意味が消える。書き手が「ここはこういう意図」と補足したくなるが、その補足こそ点検すべき穴 (ドキュメントに書かれていない前提) なので、渡してはいけない。
• 「文脈ゼロ」でゼロにするのは会話文脈であって、プロジェクトの既存資産ではない。handoff-verifier はプロジェクトのコードや他ドキュメントは読んでよい (引き継ぎ先の別セッションも読めるので、条件を揃える)。

Yes になるまで回す

handoff-verifier は「Yes / No と穴の具体指摘」を返す。read-only なので成果物は直さない。ループを回すのは呼んだ側 (あなた):

• No なら、指摘された穴を 1 つずつ直して、再度 handoff-verifier を呼ぶ。
• Yes になるまで繰り返す。
• 収束しない (同じ No が続く) ときは、成果物の構造自体を見直す。自己完結性の穴に見えて、根因が要件・設計そのものの欠落のことがある。

点検を通ったら引き継ぎの一言を出す

handoff-verifier が Yes になったら、成果物を「引き継げる」と宣言して終わりにせず、次のセッション / エージェントへの引き継ぎの一言 を出す。成果物を書いただけでは、受け手はどのファイルを読み何に着手すればいいか分からない。実際に引き継ぎを起動する一言まで出して、引き継ぎが完了する。

一言に含めるもの:

• 読む成果物: 引き継ぎ先が最初に読むファイルのパス
• 下流タスク: 何に着手してほしいか (「この要件定義から設計を進めて」等)
• 着手前の確認: 前提が揃っているか確認してから動くよう促す

出す形は、依頼者がそのまま次のセッションに渡せる短い依頼文にする。

担う範囲 — 自己完結性だけ (妥当性は別の役割)

この skill が担うのは成果物の 自己完結性 (文脈ゼロで読んで下流タスクに着手できるか) だけ。成果物の 妥当性 (Why が正しいか、設計に無理がないか) は別の役割 (要件・設計の第三者レビュー) の責務で、この skill は問わない。

引き継ぐ前提の成果物を書く場面ならどこでも、書き終える箇所でこの skill を効かせ、handoff-verifier で引き継ぎ可能性を点検してから次へ渡す。