| name | spec-driven |
| description | 開発タスクを仕様駆動の5ゲート（要件→仕様→計画→実装→検証）で進行管理するスキル。機能要求や Issue を受けたとき、受け入れ基準の確定と仕様文書の先行更新をゲートとして強制し、進行表に証拠付きで記録する。「仕様駆動で進めて」「spec-driven」「ゲート管理して」「要件から順に固めて」「受け入れ基準を決めてから実装して」と言われたとき、または曖昧な機能要求のまま実装に入りそうなときに使用。 |
仕様駆動ゲート管理（spec-driven）
開発セッションを「要件確認 → 仕様 → 計画 → 実装 → 検証」の5ゲートで統制する。
FeelFlow の書籍『AI仕様駆動開発』の方法論を蒸留したもの。成果物ドキュメントを作る genai-consultant 系と違い、開発の進行そのものを駆動するプロセススキル。
成果物
ゲート進行表 spec-driven-gates-{タスクslug}-{YYYYMMDD}.md（YYYYMMDD は開始日＝初回実行日〔実行環境のローカルタイムゾーン〕。タスク中は同一ファイルを更新し続ける）— 以下の構成:
- タスクサマリー（要求の出所〔Issue 番号・依頼文〕・現在のゲート・モード〔標準/軽量〕。直下にメタ情報欄〔slug の由来・対象リポジトリ〕）
- ゲート進行表（G0〜G4 の各ゲートに: 状態〔未着手 / 通過 / 提案通過〔更新案の提示のみで適用待ち〕/ 差し戻し〕 / 通過条件チェック結果 / 証拠〔質問と回答・更新した文書のパス・テスト結果等〕 / 通過日時）
- 受け入れ基準と検証結果（基準ごとに 未検証 / PASS / FAIL）
- 未解決事項リスト（ID 採番〔SD-1, SD-2, …。進行表本文の出現順〕。本文→ID 参照と、リスト側に発生ゲート・関連する受け入れ基準を記載〔双方向〕。ブロッカーには「誰に確認するか」を明記）
※ 進行表は監査可能性のための記録であり、これ自体が目的ではない。記録は簡潔に、判断の証拠を残すことを優先する。
参照ファイル（progressive disclosure）
| ファイル | 読むタイミング |
|---|
references/gate-criteria.md | ゲート判定時（Step 2 以降常時）。各ゲートの通過条件チェックリストと運用原則 |
references/spec-docs-map.md | G1 仕様ゲート時。7文書体系・判断マトリクス・影響度評価 |
${CLAUDE_PLUGIN_ROOT}/docs-template/（${CLAUDE_PLUGIN_ROOT} は本スキルを提供するプラグインのインストールルート） | 仕様文書が存在しないとき。コア7文書のテンプレート（MASTER.md はルート直下、他は 01-context/PROJECT.md・02-design/ARCHITECTURE.md・02-design/DOMAIN.md・03-implementation/PATTERNS.md・04-quality/TESTING.md・05-operations/DEPLOYMENT.md）。frontmatter はテンプレート本体に組み込み済み。ドキュメント体系のフル整備・検証は /init-docs・/validate-docs コマンドを使う（ゲート判定には gate-criteria.md を使う） |
実行手順
Step 1: タスクの受領とモード判定
- 入力（Issue・機能要求・依頼文）を読み、タスクサマリーを書く
- モード判定: typo 修正・文言変更などの軽微なタスクは「軽量モード」を宣言する（G1〜G2 を簡略化。ただし受け入れ基準1個と影響度 LOW の確認は必須）。それ以外は標準モード
- タスク slug: Issue 番号があれば
issue-{番号}。なければタスク名から導出する（英語名はそのまま kebab-case、日本語名は読みのヘボン式ローマ字 kebab-case〔長音は省略（しょう→sho・ちゅう→chu・おう→o）、促音は子音重ね〕）
- ゲート進行表を作成する（保存先: ユーザー指定。指定がなければカレント作業ディレクトリ）
Step 2: G0 要件ゲート
references/gate-criteria.md の G0 チェックリストに従う:
- 要求を Why / What の1〜2文に言語化する
- 受け入れ基準を 3〜5 個、観測可能な形で書く
- スコープ外を明記する
- 曖昧な点は実装案でなく質問にする。対話できる場合はユーザーに確認し、できない場合（バッチ・自律実行）は質問を SD-n に記録し、回答がなくても安全に進められる範囲だけを対象にスコープを絞る（勝手な補完で埋めない）
- チェック結果と証拠を進行表に記録して G0 を通過判定する
Step 3: G1 仕様ゲート
references/spec-docs-map.md を読み:
- 変更が影響する仕様文書を判断マトリクスで特定する。文書がなければ
${CLAUDE_PLUGIN_ROOT}/docs-template/ の対応テンプレートから最小構成で新設する（新設するのは変更が影響する文書のみ。7文書・最小3文書への底上げは別タスクとして SD-n に提案する。書く材料がない文書を推測で起こさない）
- コードより先に仕様文書を更新する（ドキュメント先、コード後）。依頼範囲が実装前まで（G2 以前）の場合は、更新案（差分）の提示に留め、適用はユーザー確認後とし、G1 の状態は「提案通過」と記録する（適用後に「通過」へ更新）
- 影響度を LOW / MEDIUM / HIGH で評価する。HIGH の場合は一旦停止し、関係者確認・ADR・移行計画の要否を判定する（対話できない場合は SD-n に記録して停止し、指示を仰ぐ）
- frontmatter（version / updated / changeImpact〔値は小文字: low|medium|high〕）の更新を差分に含め、進行表に証拠（更新した文書のパスと差分要約）を記録する。テンプレートから新設する場合、frontmatter はテンプレート本体に組み込み済みのため、プレースホルダー（owner / created 等）を実際の値で埋める（
changeImpact キーが無いテンプレート由来文書には追記し、テンプレート初期値が大文字の場合は小文字へ正規化する）
Step 4: G2 計画ゲート
- 実装を検証可能な単位に分解する（1単位 = 1つの明確な出力 + 完了条件）
- 分解した単位と受け入れ基準の対応表を作る（カバー漏れの検出）
- 触ってよい範囲・触らない範囲を明示する
- 進行表に記録して通過判定する
Step 5: G3 実装ゲート
- 単位ごとに「実装 → テスト → 確認」を回す（一括実装しない）
- 仕様にない挙動が必要になったら G1 に戻る（仕様を先に更新してから実装。戻った事実を進行表に記録）
- スコープ外に踏み出しそうになったら止まり、別タスク化を提案する
- 全単位の完了とテストのパスを確認して通過判定する
Step 6: G4 検証ゲートと完了
- 受け入れ基準を1つずつ実行して判定し、結果（PASS/FAIL と証拠）を進行表に記録する。FAIL があれば完了と言わずに該当ゲートへ戻る
- 仕様文書と実装の乖離がないか最終確認する
- 学び（ハマりどころ・設計判断）があれば1〜3行で進行表に記録する
- 進行表を完成させ、ユーザーに以下を報告する: 全ゲートの通過状況 / 受け入れ基準の判定結果 / 未解決事項（SD-n）
注意事項
- 保存前のセルフチェック: 本スキルの ID リスト（未確定・未合意・未確認・未解決・確認事項）の全 ID が、リスト自身を除く本文に少なくとも1回出現することを確認する（双方向参照の破れ防止）
- ゲートを飛ばさない。ただし前提が崩れたら前のゲートに戻るのは正常（戻りを失敗として隠さない）
- 通過判定を自己申告にしない。証拠（質問と回答・文書パス・テスト結果）のないチェックは未通過として扱う
- 曖昧な要求を推測で補完しない。質問するか、安全な範囲にスコープを絞って SD-n に残す
- 進行表の記録が目的化して開発が止まるのは本末転倒。1ゲートの記録は数行でよい
- 本スキルの方法論の出典は references/ 各ファイル末尾の「出典」セクションを参照
