cursor-handofflisted

## Purpose `implementation-gate` が「着手可」を宣言した後、人間が手動で施工AIへの指示を組み立てる工程を構造化する。 指示の抜け・粒度不足・コンテキスト不足を防ぎ、施工AIへの handoff 品質を標準化する。 ## Use When - `implementation-gate` が「着手可」または「条件付き着手」を宣言した直後 - 施工AI（Cursor / GitHub Copilot / 他 AI コーディングアシスタント）にタスクを委譲する前 - 過去に「施工AIが意図と違う実装をした」経験があるタスクの開始前 ## Use When NOT - `implementation-gate` を通過していない場合 → `implementation-gate` を先に使う - 要件・設計がまだ確定していない場合 → `implementation-gate` または `scope-design` を先に使う - ロールバック方針が未定義の場合 → `rollback-plan` を先に使う ## Inputs 以下を準備すること。不足している場合は推測せず、不足を明示する。 - **implementation-gate の出力**: ゲートチェック結果（着手可判定と条件の記録） - **タスク概要**: 実装する機能・修正の説明（1〜3文） - **対象ファイル・関数**: 実装範囲の具体的なパスとシグネチャ - **禁止範囲**: 触ってはいけないファイル・DB・機能のリスト - **完了条件**: 何がどの状態になれば完了か（テスト可能な形で） - **ロールバック手順**: 実装が失敗した場合の戻し方 ## Output Contract 以下の順で出力すること。順序を変えない。 1. **論点**: この handoff で最も注意が必要なポイント（施工AI が誤解しやすい箇所） 2. **根拠**: その論点をそう判断した理由 3. **ゲート確認**: implementation-gate の結果を要約（通過・条件付き・ブロックのどれか） 4. **含意**: 指示書の不備が引き起こすリスク 5. **指示書本文**: 施工AI向けの実行可能な指示書（後述フォーマット） 6. **代替スコープ**: 全条件が揃わない場合に着手できる限定スコープ案 7. **判断材料**: 「この指示書で委譲する / 修正してから委譲する / 委譲しない」を選ぶための情報 ### 指示書本文 フォーマット ```text ## タスク概要 （1〜3文。何を、なぜ、どの状態にするか） ## 実行範囲 （触ってよいファイル・関数・DB テーブルのリスト） ## 禁止範囲 （触ってはいけないファイル・関数・DB・インフラのリスト） ## 完了条件 （何がどの状態になれば完了か。テストで確認できる形で書く） ## 失敗条件 （何が起きたら実装を中断すべきか） ## テスト手順 （完了条件の確認方法。コマンドまたは手動確認ステップ） ## ロールバック手順 （失敗時の戻し方。git コマンドまたは手動手順） ## 注意事項 （設計上の制約・既存コードとの整合・依存関係など） ``` ## Review Lens - **目的妥当性**: 指示書の粒度が施工AI が単独で実行できる水準に達しているか - **範囲の過不足**: 実行範囲と禁止範囲の両方が明示されているか -