Implementation Gate

Purpose

「要件が曖昧なまま実装を始め、後から大幅に作り直す」を防ぐ。 実装着手前の最後のゲートとして、必要な前提条件が揃っているかを確認する。

Use When

• 新機能・修正の実装に入る前
• 施工AIへのタスク委譲前に handoff の品質を確認したい場合
• design → implementation の境界で立ち止まりたい場合
• 過去に「要件が途中で変わった」経験があるタスクの開始前

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• タスク概要: 実装する機能・修正の説明
• 要件: 何をどの状態にするか（完了条件を含む）
• 対象ファイル・機能: 実装の実行範囲
• 影響範囲: 変更が波及する他のファイル・機能・DB
• ロールバック方針: 実装が失敗した場合の戻し方

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: このタスクが着手可能かを左右する核心的な判断軸
2. 根拠: その論点をそう判断した理由
3. ゲートチェック結果: 各チェック項目の状態
4. 含意: ゲートを通過/不通過が示す中長期的な意味
5. 改善案: 不足している前提条件を揃えるための最小ステップ
6. 代替案: 全条件が揃わない場合に着手可能な限定スコープ
7. 判断材料: 「着手 / 条件付き着手 / ブロック」を選ぶための情報

ゲートチェック結果 フォーマット

Review Lens

• 目的妥当性: チェック項目が実装リスクに対して適切か
• 範囲の過不足: ゲートが厳しすぎて常にブロックになっていないか
• 中長期リスク: 「条件付き着手」が後から問題化しないか
• LAB全体との整合性: 主力プロダクト（LMS）の既存設計決定と矛盾していないか
• 非エンジニア理解可能性: ブロック理由を非技術者に説明できるか
• 他LLM移植耐性: チェック基準が Claude 固有の解釈に依存していないか

Instructions

1. タスク概要を「何を / どのファイルで / どの状態にする」に分解する
2. 各ゲート項目を OK / 注意 / NG で評価する
3. NG が1つでもあれば「ブロック」を宣言し、不足情報を具体的に列挙する
4. 「注意」のみの場合は「条件付き着手」とし、条件を明示する
5. 全項目 OK の場合のみ「着手可」を宣言する
6. ブロック・条件の解消に必要な最小アクションを提示する（実装を始めない）
7. 最終判断は人間に委ねる

Guardrails

• ゲートを通過させるために項目を甘く評価しない
• 「たぶん大丈夫」で OK を付けない。不明なものは「注意」または「NG」にする
• 実装の提案をここで行わない。このスキルはチェックのみ
• 影響範囲が「不明」の場合は必ず NG または注意にする
• ロールバック方針がない場合は必ず指摘する

LAB Cross-Check

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

Handoff Notes

• 要件: ゲートを通過した後の実装仕様（完了条件を含む）
• 成功条件: 実装完了と判断できる状態
• 失敗条件: 実装を中断・ロールバックすべき状態
• 実行範囲: 実装してよいファイル・関数・DB テーブル
• 影響範囲: 変更が波及する箇所のリスト
• ロールバック方針: 失敗時の戻し手順
• コスト比較: 着手コスト vs ブロックして要件整理するコスト

Further Reading

• change-impact-scan skill — 影響範囲の深掘り
• test-scope-definition skill — テストスコープの定義
• rollback-plan skill — ロールバック方針の詳細設計
• docs/TASKS.md — 現在のタスク状態
• docs/DECISIONS.md — 設計決定記録（ADR）