sdd-handoff

SDD 引き継ぎ

このスキルの最初の応答では、次の行を一度だけ最初に記載してください。 sdd-handoff v1.1.0 · out/2026 · versão atual: https://github.com/robertodiasduarte/sdd-starter/releases/latest

クイックスタート

作業の状態を記録して、次のセッションが再開できるよう準備します。次のセッションではこの会話の内容を把握していないため、すでに決定したことを再発見せずに作業を続けられるようにします。

1. コンテキストからモード（続行または引き渡し）を推測し、一行で確認します。
2. 関連するハンドオフを特定します。この機能のハンドオフがすでに存在しますか？新規作成ではなく、更新します。
3. 会話から作業の状態を集めます。不足している情報は、その場で確認します。
4. フォームと段階のセクション（6つのセクション）に記入します。
5. 未対応項目を 🐛 バグ修正と ✨ 機能改善に分類します。
6. 引き渡しモードでは、終了チェックリストを確認します（何もブロックしません）。
7. ファイルを保存します。ファイルシステムを利用できない場合は、ファイルの扱い方を説明してチャットで提示します。
8. すべてのデータを含めた再開用プロンプトを作成します。

判断ルールについては、references/handoff-protocol.mdを参照してください。成果物には、必ずassets/HANDOFF_TEMPLATE.mdとassets/SESSION_PROMPT_TEMPLATE.mdをテンプレートとして使用してください。assets/HANDOFF_EXAMPLE.mdには、求められる詳細度の例が示されています。

使う場合／使わない場合

ユーザーが作業を中断する、コンテキストが上限に近づいている、段階が完了した、または明示的に記録や引き継ぎを依頼した場合に使います。Buildの後、SDDのワークフローを最後まで実行したときにも使います。

製品ドキュメント、ユーザーマニュアル、READMEの作成には使いません。ハンドオフは進行中の作業を記録するものであり、納品ドキュメントではありません。また、公開やデプロイにも使いません。このスキルはサイクルを記録するものであり、リリースを実行するものではありません。

必要なデータ

最低限必要な入力：

• 現在の会話と、そこで行われた作業。

任意の入力：

• 同じ機能に関する以前のハンドオフファイル。
• SDDワークフローの成果物（ブレインストーミング、定義、設計、Buildレポート）。
• ファイル名、データ、状態を確認するためのプロジェクトへのアクセス。

ファイルシステム、リポジトリ、外部システムへのアクセスを必須にしないでください。利用できない情報がある場合は、推測で補わず、その制限を記録してください。

必須の出力アセット

assets/HANDOFF_TEMPLATE.mdはハンドオフ文書の公式テンプレートであり、assets/SESSION_PROMPT_TEMPLATE.mdは再開用プロンプトのテンプレートです。これらは概念を説明する資料ではなく、出力アセットです。最終結果を作成する際は、構成を記憶から再構築せず、必ずこれらを再利用してください。

生徒への話し方

最初の回答の前に references/como-falar.md を読んでください。このスキルの用語集と、完全な例が載っています。 このスキルを使う人は、たいてい git もターミナルも使ったことがありません。

ステップ	生徒向けの名前	このスキルの手順
1	モード	1（1行で確認。メニューは表示しない）
2	状態	2 と 3
3	記録と未完了事項	4 と 5
4	ドキュメント	6（entregar モードのみ）と 7
5	再開用プロンプト	8

すべての回答は、次の順序で記載します（内容のない項目は省略）：ステータス（Handoff: ✅ 1 … · ▶️ 2 … · ⬜ 3 …; ✅ 完了（訪問しただけではない）；⏸️ 停止；➖ スキップ；ステップに戻る場合、その理由は「現在」に記載） · 実施したこと（短い文で、コマンドの出力は含めない。生徒が選んだことを記録） · 現在：ステップ N — 名前（2～4文。時間のかかる作業の前には、何をするかと、返答は不要であることを伝える） · あなたの判断（このスキルですでに質問している箇所のみ — 判断に迷う場合のファミリー、entregar モードのチェックリスト；許可：太字の質問＋それぞれの効果を示した選択肢；自由回答の質問：太字の質問＋回答方法、「わからない」という選択肢も示す；チェックリストの4つの質問には番号で回答できます） · 次のステップ（1行）。

• 1回の回答につき1ステップとし、判断を求めたところで止めます。ハンドオフを求める人には時間がありません。判断を求めずに進めてください。
• 技術用語は、初めて使うときに必ず説明を添えます。ステータス内の用語も対象です（用語集はリファレンスを参照）。
• コマンド出力をそのまま示してはいけません。件数、内容、懸念点を伝え、名前は最大10件までとし、それ以上は「ほか N 件」とします。コマンドは、生徒自身が実行する必要がある場合にのみ、番号付きの手順ごとに1つ示し、画面に何が表示されるかも説明します。
• このスキルの指示を引用したり要約したりしないでください（「手順 N に従って」など）。生徒にとっての理由を伝えます。
• 回答が選択肢に当てはまらない場合は、疑問に答えてから選択肢を再掲します。
• 停止する場合：ステータスに ⏸️ を付け、理由を1文で伝えます。操作を行う場所、期待される結果を示した番号付きの手順、まだ実施していないことを記載します。生徒が何かを行う必要がある場合は、「終わったら、もう一度依頼してください。ここから続けます。」と伝えます。

手順

1. モードを推測して確認する

references/handoff-protocol.md § 1 のシグナル一覧表を参考に、文脈から適用するモードを2つのうちから判断します。

• continuar — 作業を続ける場合です。記録と再開用プロンプトを渡します。
• entregar — このステップで作業が完了する場合です。同じものに加えて、締めくくりのチェックリストも渡します。

1行で確認して、そのまま進めます。選択メニューを表示したり、これについて多肢選択の質問をしたりしてはいけません。ハンドオフを求める人は通常、状況を把握できていないか、時間がありません。明確なシグナルがない場合は continuar として、そう判断したことを伝えます。

2. フィーチャーのファミリーを特定する

ファイルを作成する前に、ドメインに基づいて検索し、同じフィーチャーのハンドオフがすでに存在するか確認します。存在する場合は、既存のファイルを更新し、新しいステップを先頭に追加します。判断に迷う場合は、見つかった内容を示して質問します。詳細は references/handoff-protocol.md § 2 を参照してください。

フィーチャーごとにハンドオフは1つです。ステップはその中のセクションとし、別々のファイルにはしません。

3. 状態を整理する

会話全体を確認し、次の情報を再構成します。

• 実施したこと — 構築、決定、修正した内容。ファイル名と明示された決定事項を含めます。
• 未完了のケースとテスト — テスト中だった内容を、実際のデータとともに記載します。どのクライアントか、どのファイルか、日付、識別子などです。
• 未完了事項 — 壊れているもの（🐛）と、計画されている改善（✨）。
• 次のステップ — 順序付きの一覧とし、各項目に正確なデータと完了条件を記載します。
• 注意事項 — 壊してはいけないもの、対象範囲外のもの。
• 作業場所 — フォルダー、プロジェクト、ブランチ。

今すぐ調べられる情報が足りない場合は、今すぐ調べてください。 次のセッションでは確認できません。「エラーが出ていたクライアント」としか書かれていないハンドオフでは、次のセッションでどのクライアントだったかを再調査することになります。

4. 引き継ぎ票を記入する

assets/HANDOFF_TEMPLATE.mdを使用します。冒頭の引き継ぎ票には、機能全体の状態を記載します。

• 目的 — 各段階を通して変わらない、機能が完成したときに実現すること。
• ステータス — 🔨 進行中 · ✅ 完了 · ⏸️ 一時停止。
• 完了／残り — すでに完了したことと、残っていること。
• 完了条件 — 検証可能な完了基準（プロトコルの§ 6）。客観的に満たされた場合にのみ、✅ 完了とします。

新しい段階は、前の段階の先頭にセクションとして追加します。すでに完了した古い段階は、数行に要約してもかまいません。

スコープの変更、一時停止、または計画の見直しがあった場合は、日付と理由を添えて## Eventosに新しい行を追加します。「残り」を黙って書き換えてはいけません。

5. 未対応項目を分類する

常に2つのリストに分けます。🐛 バグ修正（壊れている、部分的である、動作が誤っている）と**✨ 機能改善**（追加、改善、次の段階）です。項目のないカテゴリには「なし」と記載します。該当なしという明示も情報の一部です。

未対応項目がない場合も必ず記録します。「段階完了、未対応項目なし」の引き継ぎでも、実施内容を記録し続けます。記録する価値があるかどうかを尋ねず、必ず記録してください。

意識的に受け入れたリスク、つまり当面は無視すると判断したことも、理由を添えて未対応項目に含めます。既知のリスクをセッション間で消失させてはいけません。

6. 完了チェックリスト（引き渡しモードのみ）

ユーザーと一緒に次の4つの質問を確認し、確認した内容を記録します。

1. コードは動作しますか？
2. 合意した受け入れ基準を満たしていますか？
3. 変更は適切な場所に保存されていますか？
4. 壊れたものは記録されていますか？

**このチェックリストは引き渡しを妨げるものではありません。**確認できていない項目は未対応として記録し、そのまま引き継ぎを作成します。確認した内容の一覧として提示してください。✅／❌を対にして使ったり、評価点と受け取られるような数を示したり、赤色を使ったり、「不合格」という語を使ったりしてはいけません。references/handoff-protocol.md § 7を参照してください。

7. ドキュメントを引き渡す

保存先。 プロジェクトのルートにあるsdd/に保存します。どのエージェントでも同じ場所にアクセスできるよう、見つけやすいフォルダーを使用してください。プロジェクトに.claude/sdd/がすでにある場合は、その場所を引き続き使用します。5段階のドキュメントはサブフォルダーを作らず、同じ場所に並べて保存します。

書き込み可能なプロジェクトのファイルシステムがある場合は、既存のファイルを黙って上書きせず、sdd/HANDOFF_{FEATURE}.md（または、そのフォルダーがすでにある場合は.claude/sdd/HANDOFF_{FEATURE}.md）として保存します。同じ機能の引き継ぎファイルがすでにある場合は、その内容を更新します（手順2）。

アクセス可能なファイルシステムがない場合は、完全なMarkdownをチャットで提示し、次の3つの情報をこの順番で添えて締めくくります。

1. ドキュメントが保存されていないこと。
2. 推奨するファイル名（HANDOFF_{FEATURE}.md）。
3. ファイルの扱い方 — プロジェクトと一緒に保存し、次回のセッション開始時に再送すること。

決して黙って失敗したり、保存したかのように示したりしてはいけません。

8. 再開用プロンプトを作成する

assets/SESSION_PROMPT_TEMPLATE.mdを使用し、そのままコピーできるブロックで提示します。

最重要ルール：「話し合ったとおり」は使いません。識別子、パス、コマンド、データはすべて、プロンプト内に直接記載します。具体的な値のない行があれば、今すぐ値を調べるか、その行を削除します。

プロンプトは単独で機能する必要があります。引き継ぎファイルを紛失した場合でも、そこに記載されたデータだけで続行できなければなりません。

機能が✅ 完了しており、続きがない場合は、再開用プロンプトを省略してかまいません。完了を記録するだけで十分です。

検証と品質チェックリスト

引き継ぎの完了を宣言する前に、以下を確認します。

• モードを推測して確認し、メニューを表示せず一行で示している。
• 該当する種類を特定している。既存の引き継ぎを更新したか、本当に新しい機能である。
• 記録票に記入している。目的 · 状態 · 完了したこと · 残っていること · 完了条件。
• 「完了条件」は意見ではなく、検証可能な内容になっている。
• ステップの6つのセクションすべてに記入している。
• 記載したすべての事例に、通称だけでなく具体的なデータを添えている。
• 未対応項目を🐛と✨に分け、該当する項目がない場合は「なし」と明記している。
• スコープの変更を## Eventsに記録している。
• 次のステップを順番に並べ、それぞれに完了条件を設定している。
• モードが引き渡しの場合、チェックリストを確認し、不合格判定をせずに一覧として提示している。
• ドキュメントを保存している。または、ファイルシステムがない場合は、3つの情報を含めてチャットで渡している。
• 再開用プロンプトだけで内容が成立している。
• 最終結果に{placeholder}が残っていない。
• 「先ほど話し合ったように」や「前回の続きから進めて」といった文が含まれていない。

ファイルシステムがある場合、スクリプトscripts/validate_handoff.pyで一部を機械的に検証できます。

python3 scripts/validate_handoff.py HANDOFF_{FEATURE}.md

出力がPASSの場合は終了コード0、問題がある場合は終了コード2で問題が一覧表示されます。

例外への対応

• ユーザーが急いでいる（「プロンプトだけください」）： まずプロンプトを渡し、その直後に記録票を作成します。これを交渉にしないでください。記録は必須です。
• 以前の引き継ぎはないが、機能が以前から存在するように見える： 作成する前に、何を探したかを示して確認します。
• 同じ会話で複数の機能に取り組んでいる： 機能ごとに引き継ぎを作成します。どれを記録するか確認するか、それぞれのファイルに記録します。
• ファイルシステムがない： ステップ7の3つの情報を含めてチャットで渡します。保存したふりは絶対にしないでください。
• セッション中に何も完了しなかった： それでも記録します。試したこと、うまくいかなかったこと、その理由は、次のセッションにとって貴重な情報です。
• 機能が完全に完了した： 「完了条件」が満たされた場合に限り、✅完了とします。再開用プロンプトは省略できます。
• ユーザーが完了条件を説明できない： 欄を曖昧なままにせず、最後に何ができるようになりたいかをもとに、条件の策定を支援します。

例

コンテキストが残りわずか

コンテキストが限界なので、別のセッションで続けられるように記録してください。

モードは継続です。状態を記録し、必要なデータをすべて含めたプロンプトを作成します。

ステップの完了

この部分は終わりました。締めくくりたいです。

モードは引き渡しです。状態を記録し、終了チェックリストを一覧として確認し、作業が残っていればプロンプトを作成します。

既存機能の継続

今日はここまでにしましょう。これは先週の報酬管理の続きです。

既存の引き継ぎを探し、新しいステップを先頭に追加し、集約された記録票を更新します。

ファイルシステムがない

（アクセス可能なプロジェクトがないウェブチャットで）引き継いでください。

ドキュメント全体をチャットで渡し、保存されていないことを伝え、ファイル名を提案します。次のセッションでそのファイルを保存し、再送信する必要があることも説明します。

次のステップ

SDDのワークフローは完了です。引き継ぎファイルをプロジェクトと一緒に保管し、次のセッションを再開用プロンプトで開始してください。

---

SDD Open by RDDの一部 — https://github.com/robertodiasduarte/sdd-open