spec-driven

name	spec-driven
description	開発タスクを仕様駆動の5ゲート（要件→仕様→計画→実装→検証）で進行管理するスキル。機能要求や Issue を受けたとき、受け入れ基準の確定と仕様文書の先行更新をゲートとして強制し、進行表に証拠付きで記録する。「仕様駆動で進めて」「spec-driven」「ゲート管理して」「要件から順に固めて」「受け入れ基準を決めてから実装して」と言われたとき、または曖昧な機能要求のまま実装に入りそうなときに使用。

仕様駆動ゲート管理（spec-driven）

開発セッションを「要件確認 → 仕様 → 計画 → 実装 → 検証」の5ゲートで統制する。 FeelFlow の書籍『AI仕様駆動開発』の方法論を蒸留したもの。成果物ドキュメントを作る genai-consultant 系と違い、開発の進行そのものを駆動するプロセススキル。

成果物

ゲート進行表 spec-driven-gates-{タスクslug}-{YYYYMMDD}.md（YYYYMMDD は開始日＝初回実行日〔実行環境のローカルタイムゾーン〕。タスク中は同一ファイルを更新し続ける）— 以下の構成:

1. タスクサマリー（要求の出所〔Issue 番号・依頼文〕・現在のゲート・モード〔標準/軽量〕。直下にメタ情報欄〔slug の由来・対象リポジトリ〕）
2. ゲート進行表（G0〜G4 の各ゲートに: 状態〔未着手 / 通過 / 提案通過〔更新案の提示のみで適用待ち〕/ 差し戻し〕 / 通過条件チェック結果 / 証拠〔質問と回答・更新した文書のパス・テスト結果等〕 / 通過日時）
3. 受け入れ基準と検証結果（基準ごとに 未検証 / PASS / FAIL）
4. 未解決事項リスト（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: タスクの受領とモード判定

1. 入力（Issue・機能要求・依頼文）を読み、タスクサマリーを書く
2. モード判定: typo 修正・文言変更などの軽微なタスクは「軽量モード」を宣言する（G1〜G2 を簡略化。ただし受け入れ基準1個と影響度 LOW の確認は必須）。それ以外は標準モード
3. タスク slug: Issue 番号があれば issue-{番号}。なければタスク名から導出する（英語名はそのまま kebab-case、日本語名は読みのヘボン式ローマ字 kebab-case〔長音は省略（しょう→sho・ちゅう→chu・おう→o）、促音は子音重ね〕）
4. ゲート進行表を作成する（保存先: ユーザー指定。指定がなければカレント作業ディレクトリ）

Step 2: G0 要件ゲート

references/gate-criteria.md の G0 チェックリストに従う:

1. 要求を Why / What の1〜2文に言語化する
2. 受け入れ基準を 3〜5 個、観測可能な形で書く
3. スコープ外を明記する
4. 曖昧な点は実装案でなく質問にする。対話できる場合はユーザーに確認し、できない場合（バッチ・自律実行）は質問を SD-n に記録し、回答がなくても安全に進められる範囲だけを対象にスコープを絞る（勝手な補完で埋めない）
5. チェック結果と証拠を進行表に記録して G0 を通過判定する

Step 3: G1 仕様ゲート

references/spec-docs-map.md を読み:

1. 変更が影響する仕様文書を判断マトリクスで特定する。文書がなければ ${CLAUDE_PLUGIN_ROOT}/docs-template/ の対応テンプレートから最小構成で新設する（新設するのは変更が影響する文書のみ。7文書・最小3文書への底上げは別タスクとして SD-n に提案する。書く材料がない文書を推測で起こさない）
2. コードより先に仕様文書を更新する（ドキュメント先、コード後）。依頼範囲が実装前まで（G2 以前）の場合は、更新案（差分）の提示に留め、適用はユーザー確認後とし、G1 の状態は「提案通過」と記録する（適用後に「通過」へ更新）
3. 影響度を LOW / MEDIUM / HIGH で評価する。HIGH の場合は一旦停止し、関係者確認・ADR・移行計画の要否を判定する（対話できない場合は SD-n に記録して停止し、指示を仰ぐ）
4. frontmatter（version / updated / changeImpact〔値は小文字: low|medium|high〕）の更新を差分に含め、進行表に証拠（更新した文書のパスと差分要約）を記録する。テンプレートから新設する場合、frontmatter はテンプレート本体に組み込み済みのため、プレースホルダー（owner / created 等）を実際の値で埋める（changeImpact キーが無いテンプレート由来文書には追記し、テンプレート初期値が大文字の場合は小文字へ正規化する）

Step 4: G2 計画ゲート

1. 実装を検証可能な単位に分解する（1単位 = 1つの明確な出力 + 完了条件）
2. 分解した単位と受け入れ基準の対応表を作る（カバー漏れの検出）
3. 触ってよい範囲・触らない範囲を明示する
4. 進行表に記録して通過判定する

Step 5: G3 実装ゲート

1. 単位ごとに「実装 → テスト → 確認」を回す（一括実装しない）
2. 仕様にない挙動が必要になったら G1 に戻る（仕様を先に更新してから実装。戻った事実を進行表に記録）
3. スコープ外に踏み出しそうになったら止まり、別タスク化を提案する
4. 全単位の完了とテストのパスを確認して通過判定する

Step 6: G4 検証ゲートと完了

1. 受け入れ基準を1つずつ実行して判定し、結果（PASS/FAIL と証拠）を進行表に記録する。FAIL があれば完了と言わずに該当ゲートへ戻る
2. 仕様文書と実装の乖離がないか最終確認する
3. 学び（ハマりどころ・設計判断）があれば1〜3行で進行表に記録する
4. 進行表を完成させ、ユーザーに以下を報告する: 全ゲートの通過状況 / 受け入れ基準の判定結果 / 未解決事項（SD-n）

注意事項

• 保存前のセルフチェック: 本スキルの ID リスト（未確定・未合意・未確認・未解決・確認事項）の全 ID が、リスト自身を除く本文に少なくとも1回出現することを確認する（双方向参照の破れ防止）
• ゲートを飛ばさない。ただし前提が崩れたら前のゲートに戻るのは正常（戻りを失敗として隠さない）
• 通過判定を自己申告にしない。証拠（質問と回答・文書パス・テスト結果）のないチェックは未通過として扱う
• 曖昧な要求を推測で補完しない。質問するか、安全な範囲にスコープを絞って SD-n に残す
• 進行表の記録が目的化して開発が止まるのは本末転倒。1ゲートの記録は数行でよい
• 本スキルの方法論の出典は references/ 各ファイル末尾の「出典」セクションを参照