Spec-Driven Development (SDD) スキルは何をしますか？

GitHubのSpec-Kitを使用してSpec-Driven Development（仕様駆動開発）をユーザーに案内します。これは、仕様を実行可能にし、直接動作する実装を生成することで、従来のソフトウェア開発を反転させる方法論です。

核となる哲学

Spec-Driven Developmentは以下を重視します：

インテント駆動開発：「どのように」の前に「何を」を定義する
リッチな仕様作成：ガードレールと組織原則を使用する
マルチステップの洗練：ワンショットのコード生成ではない
AIネイティブ：高度なAI機能への強い依存

重要なのは、これはAIネイティブな開発であるということです。仕様は単なるドキュメントではなく、実装を直接駆動する実行可能なアーティファクトです。AIエージェントはこれらを使用して、仕様で定義された意図に一致する動作コードを生成します。

受け入れ基準：Gherkin形式（必須）

すべてのspec.md（またはspecify.md）内のユーザーストーリーには、散文の説明に加えて、Gherkinスタイルの受け入れ基準を必須とします。 これはグリーンフィールドとブラウンフィールドの両方、すべてのユーザーストーリーに適用され、成果物が/speckit.specifyによって生成されたか、CLIで生成されたテンプレートを使用しないリポジトリのために手動で作成されたかに関係ありません。散文はストーリーの内容を説明します。Gherkinシナリオは、それを正確に検証する方法を示します。これこそが仕様を説明的ではなく実行可能にするものです。

形式 — 各ユーザーストーリーの直下に、フェンスで囲まれたgherkinブロックを配置します。シナリオは1〜4個で、最初にハッピーパス、次にそのストーリーにとって重要なエッジケース/ネガティブケースを配置します（仕様全体のすべてのエッジケースではありません。それらは仕様の独自のエッジケースセクションに属します。ここにあるのはこのストーリーに固有のものだけです）。

Scenario: <短く具体的な名前 — 「ハッピーパス」ではなく>
  Given <前提条件 / 開始状態>
  When <アクターが取る単一のアクション>
  Then <観測可能でテスト可能な結果>
  And <必要に応じて追加の結果>

Scenario: <このストーリーのエッジケース/ネガティブケース>
  Given <前提条件>
  When <アクション>
  Then <結果 — 発生すべきでないことは有効なThenです>

記述ルール：

シナリオごとにWhenは1つだけ。 複数のアクションは複数のシナリオを意味します。これにより、各シナリオが1つのテストにマッピングされます。
Thenは観測可能であること。 内部的なものではありません。「ユーザーに確認トーストが表示される」は良いですが、「状態が正しく更新される」は良くありません。誰かがそれをどのように確認するかを言えないなら、準備はできていません。
仕様の語彙を再利用すること。 Given/When/Thenのステップは、ユーザーストーリーや機能要件と同じ名詞（アセット名、ディールタイプ、フィールド名）を使用して読み取れるようにしてください。言い換えは避けてください。
機能要件をGherkinとして言い換えないでください。 受け入れ基準はストーリーを検証します。機能要件は個別にトレースされます。重複は問題ありませんが、すべての機能要件をシナリオとして複製することは避けてください。
ストーリーに複数のシナリオがある場合、トレーサビリティのためにシナリオに番号を付けます： Scenario: AC-1 — ...、Scenario: AC-2 — ...（単一シナリオのストーリーではオプション）。

要約するとき（10項目テンプレート、「生成されたもの」）、ユーザーストーリー/成功基準の数とともにシナリオ数を報告します。例：「5ユーザーストーリー（11 Gherkinシナリオ）、8成功基準。」 ユーザーストーリーに受け入れ基準がない場合は、/speckit.planに進む前に「🔍 重要なレビュー項目」でフラグを立ててください。受け入れ基準のないストーリーに基づいた計画は、テストを過小評価する傾向があります。

行動的ACs：LLMが関与するストーリーのみ

Gherkinは、1回の実行で合否が決まると仮定します。モデルの出力が結果を決定する場合、これは機能しません。非決定論的なストーリーの1回のグリーン実行はほとんど何も証明しません。そのようなストーリーについては、Gherkinブロックの下に行動的ACsブロックを追加します。

ストーリーの観測可能な結果がモデルの出力に依存する場合にのみ生成します。 例：プロンプト、システムプロンプト、ミッション、スキルファイル、ツールの説明が変更される場合。モデルがアクションを選択したり、何かを判断/解決したり、ユーザーに表示されるテキストを書いたりする場合。モデルまたはそのパラメータが変更される場合。決定論的なコード、保存されたデータのUIレンダリング、配管、またはモデル呼び出しが存在するがその出力がアサートされないストーリーでは生成しないでください。疑わしい場合は1つ質問してください。ブロックを推測で追加しないでください。LLMが関与するストーリーがない仕様には、行動的ACsはまったくなく、空のプレースホルダーもありません。

形式：該当するストーリーごとに1つのブロックを、そのGherkinの直後に配置します。

**行動的ACs**（LLM-in-the-loop: <モデルが決定する内容>）
- **ケース:** <ケースセットへのパス>にある<N>ケース、<実際の障害/トレース/トランスクリプト>から取得。ギャップを埋めるためのみに合成入力を使用し、合成された期待出力は決して使用しない
- **実行:** ケースあたり k = <k>（≈ 3 / 期待される障害率。不明な場合は20〜30）
- **合格基準:** <メトリック> ≥ <しきい値>（k回にわたって）、ベースラインをノイズよりも大きく上回る（現在のバージョンとのペア比較）
- **評価者:** コードチェック | LLM判定（バイナリ、障害モードごとに1つ）| 人間。判定はその検証を明記：TPR/TNR ≥ 0.9（下限0.8）の保持済み人間ラベル、または「UNVALIDATED」と率直に記載
- **コマンド:** `<それを実行し、合格率、コスト、レイテンシを出力する1つのコマンド>`

ルール：

実際のモデル実行のみがカウントされます。 モック、キーワードシミュレーション、予測スコアは結果ではありません。実行できない場合（コスト、キー）、ストーリーはUNEVALUATEDと記載してください。数値を偽装しないでください。
コード評価者を優先してください。 コードがチェックできないものに対してのみ判定を使用してください。
Gherkinは引き続き適用されます。 Gherkinシナリオは決定論的なシェル（作成されたアーティファクト、保持されたガード）をカバーします。行動的ACsはモデルの動作をカバーします。
plan.mdは評価を保持します： ケースセットの場所、実行コマンド、実行あたりのコスト、および実行タイミング（PRごと、または高コストの場合はマージ前のみ）。

要約するとき、それらを別々にカウントします。例：「5ユーザーストーリー（11 Gherkinシナリオ、うち2つに行動的ACsあり）」 ブロックが欠落しているLLM-in-the-loopストーリー、およびUNVALIDATEDとマークされた判定は、「重要なレビュー項目」でフラグを立ててください。

クイック決定木

これは新規プロジェクトですか（グリーンフィールド）？

→ 完全な6ステップのプロセスについては、グリーンフィールドワークフロー を参照してください

これは既存のコードベースですか（ブラウンフィールド）？

→ リバースエンジニアリングと統合ガイダンスについては、ブラウンフィールドワークフロー を参照してください

インストールのヘルプが必要ですか？

→ セットアップとトラブルシューティングについては、インストールガイド を参照してください

インストールクイックスタート

推奨（永続的）：

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

1回限りの使用：

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

確認：

specify check

詳細なインストールオプション、トラブルシューティング、環境変数については、インストールガイドを参照してください。

サポートされているAIエージェント

対応：

✅ Claude Code
✅ GitHub Copilot
✅ Gemini CLI
✅ Cursor
✅ Qwen Code
✅ opencode
✅ Windsurf
✅ Kilo Code
✅ Auggie CLI
✅ CodeBuddy CLI
✅ Roo Code
✅ Codex CLI
✅ Amp
⚠️ Amazon Q Developer CLI（スラッシュコマンドのカスタム引数をサポートしていません）

成果物の要約とフィードバックループ

重要なワークフロー：SDDコマンドが成果物を生成または変更した後は、自動的にこのフィードバックループに従ってユーザーのエンゲージメントを維持します。

各コマンド完了後

成果物の変更を検出
- 作成または変更された成果物を特定します：
  - constitution.md（プロジェクト原則）
  - spec.md（要件仕様）
  - plan.md（技術実装計画）
  - tasks.md（アクション可能なタスク分割）
  - ブラウンフィールドワークフローからの分析レポート
読み取りと要約
- 関連する成果物を読み取ります
- 主要な情報を抽出します：
  - constitution.mdの場合：コア原則、コーディング標準、制約
  - spec.mdの場合：主要な要件、ユーザーストーリー（Gherkin受け入れ基準を含む）、成功基準
  - plan.mdの場合：テクノロジースタックの選択、アーキテクチャ上の決定、マイルストーン
  - tasks.mdの場合：タスク数、主要なタスクカテゴリ、依存関係
  - 分析レポートの場合：現在のパターン、技術的負債、統合ポイント
構造化された要約を提示（以下の10項目テンプレートを使用）
- 何が生成され、なぜ生成されたかを示す
- 最も重要な決定を理由とともに強調
- 品質インジケーターと注意点を含める
- 要約は焦点を絞り、実行可能なものに保つ
- 各セクションに明確な見出しを使用
機能ステータスを含める（ハイブリッドアプローチ）
- すべての要約に簡単なステータス行を含める
- 要求に応じて/speckit.statusで詳細なステータスを提供
- 以下の「機能ステータス追跡」セクションを参照
フィードバックオプションを提供
- オプションA：「良さそう、次のステップに進む」
- オプションB：「[特定のセクション]を変更したい」
- オプションC：「これらの変更で再生成：[ユーザー入力]」
- オプションD：「なぜ[特定の決定]が行われたか説明して」

10項目の要約テンプレート

SDDコマンドが完了した後は、常にこの構造化された形式を使用します：

## ✅ [コマンド名] 完了 - ここで行われたこと

### 🎯 行われた主な決定（トップ3）
1. [決定] - **理由：** [なぜこれが選ばれたか]
2. [決定] - **理由：** [なぜこれが選ばれたか]
3. [決定] - **理由：** [なぜこれが選ばれたか]

### 📋 生成されたもの
- [成果物1]： [内容の簡単な説明]
- [成果物2]： [内容の簡単な説明]

### 🔍 レビューすべき重要な項目（トップ3）
1. [確認すべき重要な項目とその理由]
2. [検証すべき重要な詳細と潜在的な影響]
3. [考慮すべきエッジケースと設計への影響]

### ⚠️ 注意すべき点（トップ2）
- [潜在的な問題または落とし穴] - **回避方法：** [ガイダンス]
- [よくある間違い] - **回避方法：** [ガイダンス]

### 🔄 これにより次に可能になること（2つのオプション）
- **オプション1：** [次のステップ] - 最適な場合： [条件]
- **オプション2：** [代替ステップ] - 最適な場合： [条件]

📊 **機能ステータス：** [現在の機能名] ([ステージ]) → 次： [次の機能]
   進捗： [●●●○○] [X]% | 完了： [N]/[合計] 機能 | 依存関係： [ステータス]

**あなたのオプション：** [A] 進む [B] 変更する [C] 詳しく説明する [D] 完全なステータスを表示

例：`/speckit.specify` 後の拡張要約

## ✅ Specify 完了 - ここで行われたこと

### 🎯 行われた主な決定
1. **認証：JWTトークン** - 理由：ステートレスアーキテクチャ、水平方向にスケーラブル、業界標準
2. **パスワード要件：複雑性のある12文字以上** - 理由：セキュリティ（NISTガイドライン）とユーザビリティのバランス
3. **セッションタイムアウト：24時間** - 理由：ウェブアプリの標準、セキュリティとユーザー利便性のバランス

### 📋 生成されたもの
- `.speckit/features/user-auth/specify.md`：5つのユーザーストーリー（12 Gherkin受け入れ基準シナリオ）、8つの成功基準、3つのエッジケースを含む完全な要件

### 🔍 レビューすべき重要な項目
1. **パスワードリセットフロー** - 電子メール要件がインフラストラクチャ（SMTPサーバー、テンプレート）と一致することを確認
2. **多要素認証** - 現在「将来の機能拡張」としてマークされています。MVPに含める必要があるかもしれません
3. **レート制限** - 15分あたり5回のログイン試行に設定。セキュリティポリシーに適合するか検討

### ⚠️ 注意すべき点
- **メールサービス依存関係が指定されていない** - 回避方法：plan.mdの依存関係にメールサービスを追加
- **ユーザーデータのGDPR準拠** - 回避方法：データ保持とユーザー削除の要件を確認

### 🔄 これにより次に可能になること
- **オプション1：** `/speckit.plan`を実行して技術実装を設計 - 最適な場合：要件が良さそうに見える場合
- **オプション2：** specify.mdを変更 - 最適な場合：要件を調整したり機能を追加したりする必要がある場合

📊 **機能ステータス：** user-authentication（Specified）→ 次： profile-management
   進捗： [●●○○○] 40% | 完了： 1/5 機能 | 依存関係： database-setup ✅

**あなたのオプション：** [A] 計画に進む [B] 要件を変更する [C] JWTの選択を説明する [D] 完全なステータスを表示

要約をスキップするタイミング

以下の場合のみ、要約ステップをスキップします：

ユーザーが明示的に「要約をスキップ」または「すべてのステップを自動実行」を要求した場合
成果物の変更なしでコマンドを再実行する場合
コマンドが失敗するかエラーを生成する場合（代わりにトラブルシューティング）

このワークフローの利点

「ブラックボックス」感を排除：何が生成され、なぜ生成されたかを明確に説明
早期フィードバックを可能に：実装前の誤解をキャッチ
俊敏性を維持：長い承認プロセスではなく、構造化された形式での迅速なレビュー
信頼を構築：ユーザーはAIの推論と理由を伴う決定を見ることができる
コンテキストを提供：機能ステータスはユーザーをプロジェクト全体の中で方向付けする

機能ステータス追跡

ハイブリッドアプローチ

SDDコマンドのたびに、要約に簡単な機能ステータス行を含めます。要求に応じて/speckit.statusで詳細なステータスを提供します。

簡単なステータス行の形式

すべての要約の最後にこれを含めます：

📊 **機能ステータス：** [現在の機能名] ([ステージ]) → 次： [次の機能名]
   進捗： [●●●○○] [X]% | 完了： [N]/[合計] 機能 | 依存関係： [依存] ✅/⏸️

ステージの値：

Specifying（20%完了）
Planning（40%完了）
Tasking（60%完了）
In Progress（80%完了）
Complete（100%完了）

進捗インジケーター：

完了したステージには塗りつぶしの丸（●）を使用
保留中のステージには空の丸（○）を使用
ステージに基づいてパーセンテージを計算

詳細なステータスダッシュボード

ユーザーが完全なステータスを要求した場合（オプションD）または/speckit.statusを実行した場合、以下を表示します：

📊 プロジェクト機能ステータスダッシュボード

🎯 現在の機能
├─ [機能名] ([ステージ] - [X]%完了)
│  ├─ ✅ 要件指定済み
│  ├─ 🔄 実装計画進行中
│  ├─ ⏸️ タスク未開始
│  └─ ⏸️ 実装未開始
│  ブロッカー： [なし | 説明]
│  依存関係： [機能名] ✅

✅ 完了した機能 ([N])
├─ [機能1] (100%完了)
└─ [機能2] (100%完了)

📋 今後の機能 ([N])
├─ [機能3] (依存： [現在の機能])
└─ [機能4] (依存： [機能3])

⚠️ ブロックされた機能
...

[翻訳のために切り詰め]

Spec-Driven Development (SDD) スキル