Cursor handoff

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. 判断材料: 「この指示書で委譲する / 修正してから委譲する / 委譲しない」を選ぶための情報

指示書本文 フォーマット

## タスク概要
（1〜3文。何を、なぜ、どの状態にするか）

## 実行範囲
（触ってよいファイル・関数・DB テーブルのリスト）

## 禁止範囲
（触ってはいけないファイル・関数・DB・インフラのリスト）

## 完了条件
（何がどの状態になれば完了か。テストで確認できる形で書く）

## 失敗条件
（何が起きたら実装を中断すべきか）

## テスト手順
（完了条件の確認方法。コマンドまたは手動確認ステップ）

## ロールバック手順
（失敗時の戻し方。git コマンドまたは手動手順）

## 注意事項
（設計上の制約・既存コードとの整合・依存関係など）

Review Lens

• 目的妥当性: 指示書の粒度が施工AI が単独で実行できる水準に達しているか
• 範囲の過不足: 実行範囲と禁止範囲の両方が明示されているか
• 中長期リスク: 指示書の曖昧さが施工AI の過剰実装や誤実装につながらないか
• LAB全体との整合性: 実行範囲が implementation-gate のチェック結果と一致しているか
• 非エンジニア理解可能性: 完了条件・失敗条件が技術者以外にも確認できる形か
• 他LLM移植耐性: 指示書フォーマットが特定の AI ツールに依存した記法を含んでいないか

Instructions

1. implementation-gate の出力を読み込み、着手可・条件付き・ブロックのいずれかを確認する
2. ブロック状態の場合は指示書生成を中止し、gate へ差し戻す
3. タスク概要を「何を / どのファイルで / どの状態にする」の形式に整理する
4. 実行範囲は具体的なファイルパス・関数名レベルで列挙する
5. 禁止範囲は「不明」を許容しない。不明な場合は「不明（確認が必要）」と明示する
6. 完了条件はテストコマンドまたは手動確認ステップとして書く（「動けばOK」は不可）
7. 最終判断（委譲するかどうか）は人間に委ねる

Guardrails

• implementation-gate の結果を確認せずに指示書を生成しない
• 「たぶんこうすればよい」という推測を指示書に含めない
• 実行範囲外のファイルを指示書に含めない
• 禁止範囲を省略しない（不明な場合は「不明」と明示する）
• 施工AI の具体的な実装手法（アルゴリズム選択等）を指示書で決定しない
• 最終判断（委譲するかどうか）は人間に委ねる

Failure Modes

Failure Mode	対応
implementation-gate を通過していない	gate を先に実行するよう求める。指示書は生成しない
対象ファイルが具体的なパスレベルで不明	指示書生成不可を宣言し、対象特定を先行タスクにする
ロールバック方針が未定義	rollback-plan を先に実行するよう求める
禁止範囲が指定されていない	「禁止範囲不明」として指示書に明記し、人間の確認を求める
完了条件がテスト不可能な形で記述されている	テスト可能な形に書き直すよう求める

LAB Cross-Check

観点	状態	備考
自動化フロー	—	自動化タスクの handoff 時は禁止範囲に本番フロー定義が含まれているか
データ / 認証 / ログ	—	DB・RLS 変更を含む場合は auth-boundary-check との連携が推奨されているか
実装 / 運用フロー	—	implementation-gate 通過が前提として確認されているか
非エンジニア理解可能性	—	施工AI向け指示書は技術的記述が主。非エンジニアへの説明には stakeholder-translation が別途必要
会員共有 / 再利用耐性	—	指示書テンプレートからプロジェクト固有の名称が分離されているか
他LLM移植耐性	—	指示書フォーマットが Cursor 固有の記法（@参照等）に依存していないか

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AIへの委譲後、以下を記録しておくこと。

• 委譲日時: いつ委譲したか
• 委譲先: どの AI・セッションに委譲したか
• 指示書バージョン: この handoff で使用した指示書の内容（git 管理推奨）
• 確認タイミング: 完了確認をいつ行うか
• エスカレーション条件: 施工AIが判断できない状況が起きた場合の連絡方法

Further Reading

• implementation-gate skill — handoff 前のゲートチェック（本 Skill の前提）
• rollback-plan skill — ロールバック手順の詳細設計
• change-impact-scan skill — 影響範囲の深掘り
• test-scope-definition skill — テスト手順の設計
• プロジェクトの TASKS.md — タスク状態との照合（該当ファイルに置き換えること）