sdd

name	sdd
description	仕様駆動開発のナビゲーター。タスクの規模を判断し、小規模なら即座にsdd-liteルートへ、 大規模ならPRD→プロトタイピング→Issue分解→TDD→アーキテクチャ改善のフルパイプラインを案内する。 トリガー: /sdd, spec-driven, 仕様駆動, 機能を実装したい, 新しいプロダクトを作りたい。

SDD - 仕様駆動開発

タスクの規模に応じて適切な開発ワークフローに案内するナビゲーター。

フルパイプライン

Phase 1: PRD作成          → /write-a-prd
Phase 2: プロトタイピング  → /prototype
Phase 3: Issue分解        → /prd-to-issues
Phase 4: 実装(TDD)        → /tdd
Phase 5: アーキテクチャ改善 → /improve-codebase-architecture

起動時の手順

1. 状態を確認する

まず .specs/ ディレクトリを確認し、進行中のプロジェクトがあるか調べる。

• .specs/{project}/progress.md が存在する → 途中から再開（ステップ3へ）
• 存在しない → 新規開始（ステップ2へ）

2. 規模を判断する

ユーザーにタスクの概要を聞き、以下の基準で判断する：

sdd-liteルート（/sdd-lite を案内）:

• 既存機能への小〜中規模の追加・変更
• 1セッションで完結しそう
• 要件が明確で、深い検討が不要
• 1人で実装する

フルルート（このスキルで続行）:

• 新しいプロダクトや大きな機能
• 要件が曖昧で、検証が必要
• 複数セッションにまたがる
• チームでの共有が必要（PRD, Issue）
• アーキテクチャへの影響が大きい

判断に迷う場合はユーザーに「フルプロセスで進めますか？それとも軽量版で十分ですか？」と確認する。

3. 現在のフェーズを特定して案内する

.specs/{project}/progress.md を確認し、次に実行すべきスキルを案内する。

progress.md が存在しない場合は新規作成し、Phase 1から開始する。

各フェーズの案内テンプレート：

現在のプロジェクト: {project-name}
完了済み: Phase 1 (PRD作成)
次のステップ: Phase 2 (プロトタイピング)

→ プロトタイピングを行いますか？
  - はい → `/prototype` を実行してください。
  - スキップ → Phase 3 (Issue分解) に進みます。`/prd-to-issues` を実行してください。

progress.md のフォーマット

各フェーズ完了時に .specs/{project}/progress.md を更新する。

# {project-name} 進捗

## フェーズ状況

| Phase | 名前               | 状態        | 成果物                      | 完了日     |
| ----- | ------------------ | ----------- | --------------------------- | ---------- |
| 1     | PRD作成            | done        | 1-prd.md (GitHub Issue #42) | 2026-03-25 |
| 2     | プロトタイピング   | skipped     | -                           | -          |
| 3     | Issue分解          | in_progress | -                           | -          |
| 4     | 実装(TDD)          | pending     | -                           | -          |
| 5     | アーキテクチャ改善 | pending     | -                           | -          |

## メモ

- Phase 2はスキップ。要件が明確なため。

状態の値: pending, in_progress, done, skipped

各フェーズの詳細

Phase 1: PRD作成

問題定義、解決策、ユーザーストーリー、技術的決定事項を文書化する。

実行: /write-a-prd を使用

完了条件: PRDがGitHub issueとして作成された

成果物: .specs/{project}/1-prd.md にPRDのローカルコピーを保存し、GitHub issue番号を記録

Phase 2: プロトタイピング（オプション）

使い捨てのプロトタイプで体験を検証する。

スキップ条件: 要件が明確で、UIの「感触」の検証が不要な場合

実行: /prototype を使用

成果物: .specs/{project}/2-prototype-notes.md

Phase 3: Issue分解

PRDをトレーサーバレット方式の垂直スライスに分割し、GitHub issueとして作成する。

実行: /prd-to-issues を使用（Phase 1で作成したPRDのissue番号を渡す）

完了条件: すべてのissueがGitHub上に作成された

成果物: .specs/{project}/3-issues.md に作成されたissue一覧を記録

Phase 4: 実装(TDD)

Phase 3で作成したissueをTDDで実装する。

実行: 各issueに対して /tdd を使用

完了条件: すべてのissueがクローズされた

Phase 5: アーキテクチャ改善（オプション）

実装後のコードベースを探索し、リファクタリングの機会を発見する。

スキップ条件: 小規模な変更で、アーキテクチャへの影響が軽微な場合

実行: /improve-codebase-architecture を使用

重要なルール

• 各フェーズ完了時に必ず progress.md を更新する
• フェーズはスキップ可能だが、その判断はユーザーに確認する
• フェーズの順序を入れ替えない（依存関係がある）
• 前のフェーズの成果物を次のフェーズで参照する
• セッションの最初に progress.md を確認し、途中から再開できるようにする