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
以下の順で出力すること。順序を変えない。
- 論点: この handoff で最も注意が必要なポイント(施工AI が誤解しやすい箇所)
- 根拠: その論点をそう判断した理由
- ゲート確認: implementation-gate の結果を要約(通過・条件付き・ブロックのどれか)
- 含意: 指示書の不備が引き起こすリスク
- 指示書本文: 施工AI向けの実行可能な指示書(後述フォーマット)
- 代替スコープ: 全条件が揃わない場合に着手できる限定スコープ案
- 判断材料: 「この指示書で委譲する / 修正してから委譲する / 委譲しない」を選ぶための情報
指示書本文 フォーマット
## タスク概要
(1〜3文。何を、なぜ、どの状態にするか)
## 実行範囲
(触ってよいファイル・関数・DB テーブルのリスト)
## 禁止範囲
(触ってはいけないファイル・関数・DB・インフラのリスト)
## 完了条件
(何がどの状態になれば完了か。テストで確認できる形で書く)
## 失敗条件
(何が起きたら実装を中断すべきか)
## テスト手順
(完了条件の確認方法。コマンドまたは手動確認ステップ)
## ロールバック手順
(失敗時の戻し方。git コマンドまたは手動手順)
## 注意事項
(設計上の制約・既存コードとの整合・依存関係など)
Review Lens
- 目的妥当性: 指示書の粒度が施工AI が単独で実行できる水準に達しているか
- 範囲の過不足: 実行範囲と禁止範囲の両方が明示されているか
- 中長期リスク: 指示書の曖昧さが施工AI の過剰実装や誤実装につながらないか
- LAB全体との整合性: 実行範囲が
implementation-gateのチェック結果と一致しているか - 非エンジニア理解可能性: 完了条件・失敗条件が技術者以外にも確認できる形か
- 他LLM移植耐性: 指示書フォーマットが特定の AI ツールに依存した記法を含んでいないか
Instructions
implementation-gateの出力を読み込み、着手可・条件付き・ブロックのいずれかを確認する- ブロック状態の場合は指示書生成を中止し、gate へ差し戻す
- タスク概要を「何を / どのファイルで / どの状態にする」の形式に整理する
- 実行範囲は具体的なファイルパス・関数名レベルで列挙する
- 禁止範囲は「不明」を許容しない。不明な場合は「不明(確認が必要)」と明示する
- 完了条件はテストコマンドまたは手動確認ステップとして書く(「動けばOK」は不可)
- 最終判断(委譲するかどうか)は人間に委ねる
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-gateskill — handoff 前のゲートチェック(本 Skill の前提)rollback-planskill — ロールバック手順の詳細設計change-impact-scanskill — 影響範囲の深掘りtest-scope-definitionskill — テスト手順の設計- プロジェクトの TASKS.md — タスク状態との照合(該当ファイルに置き換えること)