先週で完了したSpec Driven Development入門シリーズ、入門(1)、入門(2)、入門(3)、ECサイトを完成してみた で使ったSpec Driven Developmentフレームワークcc-sddがどうやって動いているのか調べてみました。
Bing Image Creatorが生成した画像を使っています
GitHub上のcc-sdd
まずcc-sddのGitHubを見てみましょう。下のディレクトリー構造のようにsrc/ディレクトリーにはTypeScriptで書かれNode.js等で動くコードもあります。しかしAIへのプロンプトと思われるMarkdownファイルが半分以上です。
tools/cc-sdd/
├── src/ # TypeScript ソースコード
│ ├── cli.ts # エントリポイント
│ ├── cli/ # CLI処理 (引数解析, UI, ポリシー)
│ ├── agents/ # エージェントレジストリ
│ ├── manifest/ # マニフェスト読込・計画・処理
│ ├── plan/ # 実行計画 (カテゴリ分け, ファイル操作, 出力)
│ ├── resolvers/ # OS/ディレクトリ解決
│ ├── template/ # テンプレートレンダリング
│ ├── constants/ # 言語定義
│ └── utils/ # ファイルシステムユーティリティ
├── templates/ # 全エージェント用テンプレート (153ファイル)
│ └── agents/ # 10種のエージェント定義
└── package.json
TypeScriptのコードはインストール(例 npx cc-sdd@latest --claude --lang ja)時にのみ動くコードでプロジェクトにインストールされるプロンプトの選択やテンプレート変数の置き換えなどを行っています。
cc-sddはClaude Code専用ツールではなくCodex, Cursor, Geminiなど多数のAIツールで動くフレームワークなので複雑なインストラーが必要になるのですね。
- Claudeが作った処理フロー
npx cc-sdd --claude --lang ja
│
▼
┌─ cli.ts ─────────────────────┐
│ バージョン読込, runCli()呼出 │
└──────────┬───────────────────┘
▼
┌─ index.ts (runCli) ───────────┐
│ 1. args.ts で引数解析 │
│ 2. store.ts でユーザー設定読込 │
│ 3. config.ts で設定マージ │
│ 4. agents.ts でエージェント選択 │
└──────────┬────────────────────┘
▼
┌─ manifest/ ──────────────────┐
│ loader.ts: JSON読込 │
│ processor.ts: 条件フィルタ │
│ + プレースホルダー置換 │
│ planner.ts: 統合処理 │
└──────────┬───────────────────┘
▼
┌─ plan/ ──────────────────────┐
│ fileOperations.ts: │
│ テンプレート走査→操作リスト │
│ categories.ts: カテゴリ分類 │
│ policies.ts: 競合ポリシー決定 │
│ executor.ts: 書き込み実行 │
└──────────┬───────────────────┘
▼
┌─ 完了 ───────────────────────┐
│ agents.ts: 完了ガイド表示 │
│ store.ts: 設定保存 │
└──────────────────────────────
プロジェクト内のcc-sdd
cc-sddをインストールするとプロジェクトに以下のように.claude, .kiroフォルダーが作成され以下のようなファイルが置かれます。
├── .claude
│ ├── commands
│ │ └── kiro ↓ cc-sddのコマンド群
│ │ ├── spec-design.md
│ │ ├── spec-impl.md
│ │ ├── spec-init.md
│ │ ├── spec-requirements.md
│ │ ├── spec-status.md
│ │ ├── spec-tasks.md
│ │ ├── steering-custom.md
│ │ ├── steering.md
│ │ ├── validate-design.md
│ │ ├── validate-gap.md
│ │ └── validate-impl.md
│ └── settings.local.json ← Claude Codeの設定（例 パーミッション）
├── .kiro
│ ├── settings
│ │ ├── rules ↓ 設計ルール群（cc-sddコマンドから参照されます）
│ │ │ ├── design-discovery-full.md
│ │ │ ├── design-discovery-light.md
│ │ │ ├── design-principles.md
│ │ │ ├── design-review.md
│ │ │ ├── ears-format.md
│ │ │ ├── gap-analysis.md
│ │ │ ├── steering-principles.md
│ │ │ ├── tasks-generation.md
│ │ │ └── tasks-parallel-analysis.md
│ │ └── templates ↓ 設計情報等の初期ファイル
│ │ ├── specs
│ │ ├── steering
│ │ └── steering-custom
│ ├── specs
│ │ └── wine-ec-site ↓ コマンドが生成したプロジェクトの設計ファイル等
│ │ ├── design.md
│ │ ├── requirements.md
│ │ ├── research.md
│ │ ├── spec.json
│ │ └── tasks.md
│ └── steering ↓ 人間が指定したステアリング情報
│ ├── product.md
│ ├── structure.md
│ └── tech.md
├── CLAUDE.md
コマンド
以下はインストールされたコマンドの一覧です。
| ファイル名 | 内容 |
|---|---|
spec-design.md | 仕様の包括的な技術設計を作成する |
spec-impl.md | TDD手法を使用して仕様タスクを実行する |
spec-init.md | 詳細なプロジェクト説明で新しい仕様を初期化する |
spec-requirements.md | 仕様の包括的な要件を生成する |
spec-status.md | 仕様のステータスと進捗を表示する |
spec-tasks.md | 仕様の実装タスクを生成する |
steering.md | steeringを永続的なプロジェクト知識として管理する |
steering-custom.md | 特殊なプロジェクトコンテキスト向けにカスタムステアリングドキュメントを作成する |
validate-design.md | インタラクティブな技術設計品質レビューと検証 |
validate-gap.md | 要件と既存コードベース間の実装ギャップを分析する |
validate-impl.md | 要件、設計、タスクに対して実装を検証する |
spec-design.md
設計を行ってくれるspec-designを見てみましょう、今回はClaude Code用のコマンドです。また、実際のファイルは英語ですが、わかりやすいようにClaudeに日本語に翻訳してもらいました。
最初の---に囲まれた部分はClaude Codeのカスタムコマンドの定義で説明、実行中に使えるツール、引数のヒントです。
---
description: 仕様の包括的な技術設計を作成する
allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch
argument-hint: <フィーチャー名> [-y]
---
以下はコマンドの実行手順やAIへの指示などが自然言語で書かれています。基本フォーマットはMarkdownですが一部にはXML（例 <background_information> 〜 </background_information>）を使う事で文章の構造を明確化していますね。
重要が何度も出てきますね、Claudeに「重要と書く効果はありますか？」と聞いたところ「ある程度の効果はありますが、期待するほど強力ではありません。」と帰って来ました。😅
# 技術設計ジェネレーター
<background_information>
- **ミッション**: 要件（WHAT）をアーキテクチャ設計（HOW）に変換する包括的な技術設計ドキュメントを生成する
- **成功基準**:
- すべての要件が明確なインターフェースを持つ技術コンポーネントにマッピングされている
- 適切なアーキテクチャ調査とリサーチが完了している
- 設計がステアリングコンテキストと既存パターンに整合している
- 複雑なアーキテクチャにはビジュアル図を含める
</background_information>
<instructions>
## コアタスク
承認された要件に基づき、フィーチャー **$1** の技術設計ドキュメントを生成する。
## 実行ステップ
### ステップ1: コンテキストの読み込み
**必要なコンテキストをすべて読み込む**:
- `.kiro/specs/$1/spec.json`, `requirements.md`, `design.md`（存在する場合）
- **`.kiro/steering/` ディレクトリ全体**（完全なプロジェクトメモリのため）
- `.kiro/settings/templates/specs/design.md` ドキュメント構造用
- `.kiro/settings/rules/design-principles.md` 設計原則用
- `.kiro/settings/templates/specs/research.md` 調査ログ構造用
**要件の承認を検証する**:
- `-y` フラグが指定されている場合（$2 == "-y"）: spec.json で要件を自動承認する
- それ以外の場合: 承認ステータスを確認する（未承認の場合は停止、安全策とフォールバックを参照）
### ステップ2: 調査と分析
**重要: このフェーズにより、設計が完全で正確な情報に基づくことを保証します。**
1. **フィーチャータイプの分類**:
- **新規フィーチャー**（グリーンフィールド）→ 完全な調査が必要
- **拡張**（既存システム）→ 統合に焦点を当てた調査
- **単純な追加**（CRUD/UI）→ 最小限または調査不要
- **複雑な統合**→ 包括的な分析が必要
2. **適切な調査プロセスの実行**:
**複雑/新規フィーチャーの場合**:
- `.kiro/settings/rules/design-discovery-full.md` を読み込んで実行する
- WebSearch/WebFetchを使用して徹底的なリサーチを実施する:
- 最新のアーキテクチャパターンとベストプラクティス
- 外部依存関係の検証（API、ライブラリ、バージョン、互換性）
- 公式ドキュメント、移行ガイド、既知の問題
- パフォーマンスベンチマークとセキュリティ考慮事項
**拡張の場合**:
- `.kiro/settings/rules/design-discovery-light.md` を読み込んで実行する
- 統合ポイント、既存パターン、互換性に焦点を当てる
- Grepを使用して既存コードベースのパターンを分析する
**単純な追加の場合**:
- 正式な調査をスキップし、簡単なパターンチェックのみ
3. **ステップ3のために調査結果を保持する**:
- 外部APIの契約と制約
- 根拠を伴う技術的意思決定
- 従うまたは拡張する既存パターン
- 統合ポイントと依存関係
- 特定されたリスクと軽減戦略
- 潜在的なアーキテクチャパターンと境界オプション（`research.md` に詳細を記載）
- 将来のタスクの並列化に関する考慮事項（`research.md` に依存関係を記録）
4. **調査結果をリサーチログに永続化する**:
- 共有テンプレートを使用して `.kiro/specs/$1/research.md` を作成または更新する
- 調査範囲と主要な発見を要約する（サマリーセクション）
- リサーチログのトピックにソースと影響を含む調査内容を記録する
- テンプレートセクションを使用して、アーキテクチャパターンの評価、設計決定、リスクを文書化する
- `research.md` の作成・更新時は spec.json で指定された言語を使用する
### ステップ3: 設計ドキュメントの生成
1. **設計テンプレートとルールの読み込み**:
- 構造用に `.kiro/settings/templates/specs/design.md` を読み込む
- 原則用に `.kiro/settings/rules/design-principles.md` を読み込む
2. **設計ドキュメントの生成**:
- **specs/design.md テンプレートの構造と生成指示に厳密に従う**
- **すべての調査結果を統合する**: リサーチした情報（API、パターン、テクノロジー）をコンポーネント定義、アーキテクチャ決定、統合ポイント全体に活用する
- ステップ1で既存の design.md が見つかった場合、参照コンテキストとして使用する（マージモード）
- 設計ルールを適用する: 型安全性、ビジュアルコミュニケーション、フォーマルなトーン
- spec.json で指定された言語を使用する
- セクションが更新された見出し（"アーキテクチャパターンと境界マップ"、"テクノロジースタックとアライメント"、"コンポーネントとインターフェース契約"）を反映し、`research.md` からのサポート詳細を参照することを確認する
3. **メタデータの更新**（spec.json内）:
- `phase: "design-generated"` を設定する
- `approvals.design.generated: true, approved: false` を設定する
- `approvals.requirements.approved: true` を設定する
- `updated_at` タイムスタンプを更新する
## 重要な制約
- **型安全性**:
- プロジェクトのテクノロジースタックに合わせた強い型付けを適用する。
- 静的型付け言語では、明示的な型/インターフェースを定義し、安全でないキャストを避ける。
- TypeScriptでは、`any` を絶対に使用しない; 正確な型とジェネリクスを優先する。
- 動的型付け言語では、利用可能な場合は型ヒント/アノテーションを提供し（例: Pythonの型ヒント）、境界で入力を検証する。
- パブリックインターフェースと契約を明確に文書化し、コンポーネント間の型安全性を確保する。
- **最新情報**: 外部依存関係とベストプラクティスにはWebSearch/WebFetchを使用する
- **ステアリングとの整合**: ステアリングコンテキストの既存アーキテクチャパターンを尊重する
- **テンプレート準拠**: specs/design.md テンプレートの構造と生成指示に厳密に従う
- **設計への集中**: アーキテクチャとインターフェースのみ、実装コードは含めない
- **要件トレーサビリティID**: 数値の要件IDのみを使用する（例: "1.1", "1.2", "3.1", "3.3"）。requirements.md で定義された通りに正確に使用する。新しいIDを作成したりアルファベットラベルを使用したりしないこと。
</instructions>
## ツールガイダンス
- **先に読み込む**: アクション前にすべてのコンテキストを読み込む（仕様、ステアリング、テンプレート、ルール）
- **不確かな場合はリサーチする**: 外部依存関係、API、最新のベストプラクティスにはWebSearch/WebFetchを使用する
- **既存コードを分析する**: Grepを使用してコードベースのパターンと統合ポイントを検索する
- **最後に書き込む**: すべてのリサーチと分析が完了した後にのみ design.md を生成する
## 出力の説明
**コマンド実行出力**（design.md の内容とは別）:
spec.json で指定された言語で簡潔な要約を提供する:
1. **ステータス**: `.kiro/specs/$1/design.md` に設計ドキュメントが生成されたことを確認する
2. **調査タイプ**: どの調査プロセスが実行されたか（完全/簡易/最小限）
3. **主要な発見**: 設計を形作った `research.md` からの2〜3の重要な知見
4. **次のアクション**: 承認ワークフローのガイダンス（安全策とフォールバックを参照）
5. **リサーチログ**: `research.md` が最新の決定で更新されたことを確認する
**フォーマット**: 簡潔なMarkdown（200語以内） - これはコマンド出力であり、設計ドキュメント自体ではない
**注意**: 実際の設計ドキュメントは `.kiro/settings/templates/specs/design.md` の構造に従います。
## 安全策とフォールバック
### エラーシナリオ
**要件が未承認**:
- **実行停止**: 承認された要件なしでは進行できない
- **ユーザーメッセージ**: "要件がまだ承認されていません。設計生成前に承認が必要です。"
- **推奨アクション**: "`/kiro:spec-design $1 -y` を実行して要件を自動承認し、続行してください"
**要件が不在**:
- **実行停止**: 要件ドキュメントが存在する必要がある
- **ユーザーメッセージ**: "`.kiro/specs/$1/requirements.md` に requirements.md が見つかりません"
- **推奨アクション**: "先に `/kiro:spec-requirements $1` を実行して要件を生成してください"
**テンプレート不在**:
- **ユーザーメッセージ**: "`.kiro/settings/templates/specs/design.md` にテンプレートファイルがありません"
- **推奨アクション**: "リポジトリのセットアップを確認するか、テンプレートファイルを復元してください"
- **フォールバック**: 警告付きのインライン基本構造を使用する
**ステアリングコンテキスト不在**:
- **警告**: "ステアリングディレクトリが空または不在です - 設計がプロジェクト標準に整合しない可能性があります"
- **続行**: 生成を続行するが、出力に制限事項を記載する
**調査の複雑さが不明確**:
- **デフォルト**: 完全な調査プロセスを使用する（`.kiro/settings/rules/design-discovery-full.md`）
- **根拠**: 重要なコンテキストを見逃すより、過剰にリサーチする方が良い
- **無効な要件ID**:
- **実行停止**: requirements.md に数値IDがない場合、または非数値の見出しを使用している場合（例: "Requirement A"）、停止して続行前に requirements.md を修正するようユーザーに指示する。
### 次のフェーズ: タスク生成
**設計が承認された場合**:
- `.kiro/specs/$1/design.md` で生成された設計をレビューする
- **オプション**: `/kiro:validate-design $1` を実行してインタラクティブな品質レビューを行う
- その後 `/kiro:spec-tasks $1 -y` を実行して実装タスクを生成する
**修正が必要な場合**:
- フィードバックを提供し、`/kiro:spec-design $1` を再実行する
- 既存の設計が参照として使用される（マージモード）
**注意**: タスク生成に進む前に設計の承認が必須です。
spec-impl.md
実装を行ってくれるspec-implも見てみましょうか。TDD（テスト駆動開発）で開発する手順が書かれていますね。
---
description: TDD手法を使用して仕様タスクを実行する
allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS, WebFetch, WebSearch
argument-hint: <フィーチャー名> [タスク番号]
---
# 実装タスクエグゼキューター
<background_information>
- **ミッション**: 承認された仕様に基づき、テスト駆動開発手法を使用して実装タスクを実行する
- **成功基準**:
- すべてのテストが実装コードの前に書かれている
- コードがすべてのテストに合格し、リグレッションがない
- tasks.md で完了したタスクがマークされている
- 実装が設計と要件に整合している
</background_information>
<instructions>
## コアタスク
テスト駆動開発を使用して、フィーチャー **$1** の実装タスクを実行する。
## 実行ステップ
### ステップ1: コンテキストの読み込み
**必要なコンテキストをすべて読み込む**:
- `.kiro/specs/$1/spec.json`, `requirements.md`, `design.md`, `tasks.md`
- **`.kiro/steering/` ディレクトリ全体**（完全なプロジェクトメモリのため）
**承認の検証**:
- spec.json でタスクが承認されていることを確認する（未承認の場合は停止、安全策とフォールバックを参照）
### ステップ2: タスクの選択
**実行するタスクを決定する**:
- `$2` が指定されている場合: 指定されたタスク番号を実行する（例: "1.1" または "1,2,3"）
- それ以外の場合: すべての保留中のタスク（tasks.md の未チェック `- [ ]`）を実行する
### ステップ3: TDDで実行する
選択した各タスクについて、Kent BeckのTDDサイクルに従う:
1. **RED - 失敗するテストを書く**:
- 次の小さな機能部分のテストを書く
- テストは失敗するべき（コードがまだ存在しない）
- 説明的なテスト名を使用する
2. **GREEN - 最小限のコードを書く**:
- テストを通す最もシンプルなソリューションを実装する
- このテストを通すことだけに集中する
- 過剰設計を避ける
3. **REFACTOR - クリーンアップ**:
- コード構造と可読性を改善する
- 重複を除去する
- 適切な場合にデザインパターンを適用する
- リファクタリング後もすべてのテストが通ることを確認する
4. **VERIFY - 品質検証**:
- すべてのテストが通る（新規および既存）
- 既存機能にリグレッションがない
- コードカバレッジが維持または改善されている
5. **完了マーク**:
- tasks.md でチェックボックスを `- [ ]` から `- [x]` に更新する
## 重要な制約
- **TDD必須**: テストは実装コードの前に書かなければならない
- **タスクスコープ**: 特定のタスクが要求することのみを実装する
- **テストカバレッジ**: すべての新しいコードにはテストが必要
- **リグレッションなし**: 既存のテストは引き続き通る必要がある
- **設計との整合**: 実装は design.md の仕様に従わなければならない
</instructions>
## ツールガイダンス
- **先に読み込む**: 実装前にすべてのコンテキストを読み込む
- **先にテスト**: コードの前にテストを書く
- 必要に応じて **WebSearch/WebFetch** でライブラリのドキュメントを参照する
## 出力の説明
spec.json で指定された言語で簡潔な要約を提供する:
1. **実行されたタスク**: タスク番号とテスト結果
2. **ステータス**: tasks.md で完了したタスクをマーク、残りのタスク数
**フォーマット**: 簡潔（150語以内）
## 安全策とフォールバック
### エラーシナリオ
**タスクが未承認または仕様ファイルが不在**:
- **実行停止**: すべての仕様ファイルが存在し、タスクが承認されている必要がある
- **推奨アクション**: "前のフェーズを完了してください: `/kiro:spec-requirements`, `/kiro:spec-design`, `/kiro:spec-tasks`"
**テスト失敗**:
- **実装を停止**: 続行前に失敗したテストを修正する
- **アクション**: デバッグして修正し、再実行する
### タスクの実行
**特定のタスクを実行する**:
- `/kiro:spec-impl $1 1.1` - 単一タスク
- `/kiro:spec-impl $1 1,2,3` - 複数タスク
**すべての保留中を実行する**:
- `/kiro:spec-impl $1` - すべての未チェックタスク
ルール
コマンドは手順を中心に記述されており、設計や実装のルールは.kiro/settings/rulesフォルダーの下に置かれていてコマンドから参照されます。ルールファイルには以下のようなものがあります。
| ファイル | 内容 |
|---|---|
| design-discovery-light.md | 拡張機能向けライトディスカバリープロセス |
| design-discovery-full.md | 技術設計のためのフルディスカバリープロセス |
| design-principles.md | 技術設計ルールと原則 |
| design-review.md | 設計レビュープロセス |
| ears-format.md | EARS形式ガイドライン |
| gap-analysis.md | ギャップ分析プロセス |
| steering-principles.md | Steering原則 |
| tasks-generation.md | タスク生成ルール |
| tasks-parallel-analysis.md | 並列タスク分析ルール |
design-principles.md
設計の原則が書かれたルールファイルです。設計の原則やベストプラクティスが記述されていますね。
このファイルも英語ですが、わかりやすいように日本語に翻訳してもらいました。
長いので後半は省略しました。
# 技術設計ルールと原則
## コア設計原則
### 1. 型安全性は必須
- TypeScriptインターフェースで`any`型を**絶対に使用しない**
- すべてのパラメータと戻り値に明示的な型を定義
- エラーハンドリングには判別共用体を使用
- ジェネリクス制約を明確に指定
### 2. 設計と実装の分離
- **「何を」に焦点を当て、「どのように」は扱わない**
- コードではなく、インターフェースとコントラクトを定義
- 事前条件/事後条件で振る舞いを規定
- アルゴリズムではなく、アーキテクチャ上の決定を文書化
### 3. 視覚的コミュニケーション
- **シンプルな機能**: 基本的なコンポーネント図またはなし
- **中程度の複雑さ**: アーキテクチャ＋データフロー
- **高い複雑さ**: 複数の図（アーキテクチャ、シーケンス、状態）
- **常にプレーンなMermaid**: スタイリングなし、構造のみ
### 4. コンポーネント設計ルール
- **単一責任**: コンポーネントごとに1つの明確な目的
- **明確な境界**: 明示的なドメイン所有権
- **依存関係の方向**: アーキテクチャ層に従う
- **インターフェース分離**: 最小限で焦点を絞ったインターフェース
- **チームセーフなインターフェース**: マージコンフリクトなしに並行実装可能な境界を設計
- **調査の追跡可能性**: 境界の決定と根拠を`research.md`に記録
### 5. データモデリング標準
- **ドメインファースト**: ビジネス概念から開始
- **一貫性の境界**: 明確な集約ルート
- **正規化**: パフォーマンスと整合性のバランス
- **進化**: スキーマ変更に備えた計画
### 6. エラーハンドリングの哲学
- **早期失敗**: 早期かつ明確にバリデーション
- **優雅な劣化**: 完全な障害より部分的な機能を優先
- **ユーザーコンテキスト**: 対処可能なエラーメッセージ
- **可観測性**: 包括的なロギングとモニタリング
### 7. 統合パターン
- **疎結合**: 依存関係を最小化
- **コントラクトファースト**: 実装前にインターフェースを定義
- **バージョニング**: APIの進化を計画
- **冪等性**: リトライ安全な設計
- **コントラクトの可視性**: APIおよびイベントコントラクトをdesign.mdに表面化し、`research.md`から拡張詳細をリンク
## ドキュメント標準
### 言語とトーン
- **宣言的**: 「システムはユーザーを認証する」（「認証すべき」ではない）
- **正確**: 曖昧な説明より具体的な技術用語
- **簡潔**: 必要不可欠な情報のみ
- **公式**: プロフェッショナルな技術文書
### 構造要件
- **階層的**: 明確なセクション構成
- **追跡可能**: 要件からコンポーネントへのマッピング
- **完全**: 実装に必要なすべての側面を網羅
- **一貫性**: 全体を通じて統一された用語
- **焦点**: design.mdはアーキテクチャとコントラクトに集中し、調査ログや詳細な比較は`research.md`に移動
## セクション作成ガイダンス
### 全体の順序
- デフォルトの流れ: 概要 → 目標/非目標 → 要件追跡可能性 → アーキテクチャ → 技術スタック → システムフロー → コンポーネントとインターフェース → データモデル → オプションセクション。
- チームは、明確性が向上する場合、追跡可能性を前に移動したり、データモデルをアーキテクチャの近くに配置したりできるが、セクション見出しはそのままにする。
- 各セクション内では、**サマリー → スコープ → 決定 → 影響/リスク** の順に従い、レビュアーが一貫してスキャンできるようにする。
### 要件ID
- 要件は接頭辞なしで`2.1, 2.3`として参照（「要件2.1」とはしない）。
- すべての要件には数値IDが必須。数値IDがない要件がある場合は、続行する前に`requirements.md`を修正する。
- `N.M`形式の数値IDを使用。`N`はrequirements.mdのトップレベル要件番号（例: 要件1 → 1.1, 1.2; 要件2 → 2.1, 2.2）。
- すべてのコンポーネント、タスク、追跡可能性の行は同じ正規の数値IDを参照する必要がある。
### 技術スタック
- この機能で影響を受けるレイヤーのみを含める（フロントエンド、バックエンド、データ、メッセージング、インフラ）。
- 各レイヤーにツール/ライブラリ＋バージョン＋役割を指定し、詳細な根拠、比較、ベンチマークは`research.md`に記載。
- 既存システムを拡張する場合は、現在のスタックからの逸脱を強調し、新しい依存関係をリストする。
・・・以下省略・・・
design-discovery-full.md
設計時に使われる、最新の情報をネット等から取得し分析する際のルールです。
# 技術設計のためのフルディスカバリープロセス
## 目的
技術設計が完全で正確かつ最新の情報に基づくよう、包括的な調査と分析を実施する。
## ディスカバリーステップ
### 1. 要件分析
**要件を技術ニーズにマッピング**
- EARS形式からすべての機能要件を抽出
- 非機能要件の特定（パフォーマンス、セキュリティ、スケーラビリティ）
- 技術的な制約と依存関係の決定
- コアとなる技術的課題のリスト化
### 2. 既存実装の分析
**現在のシステムの把握**（変更/拡張の場合）:
- コードベースの構造とアーキテクチャパターンの分析
- 再利用可能なコンポーネント、サービス、ユーティリティのマッピング
- ドメイン境界とデータフローの特定
- 統合ポイントと依存関係の文書化
- アプローチの決定: 拡張 vs リファクタリング vs ラッピング
### 3. 技術調査
**ベストプラクティスとソリューションの調査**:
- **WebSearch**を使用して以下を検索:
- 類似問題に対する最新のアーキテクチャパターン
- 技術スタックに関する業界のベストプラクティス
- 関連技術の最新のアップデートや変更
- よくある落とし穴とソリューション
- **WebFetch**を使用して以下を分析:
- フレームワーク/ライブラリの公式ドキュメント
- APIリファレンスと使用例
- 移行ガイドと破壊的変更
- パフォーマンスベンチマークと比較
### 4. 外部依存関係の調査
**各外部サービス/ライブラリについて**:
- 公式ドキュメントとGitHubリポジトリを検索
- APIシグネチャと認証方法を検証
- 既存スタックとのバージョン互換性を確認
- レート制限と使用制約を調査
- コミュニティリソースと既知の問題を検索
- セキュリティに関する考慮事項を文書化
- 実装調査が必要なギャップを記録
### 5. アーキテクチャパターンと境界分析
**アーキテクチャオプションの評価**:
- 関連パターンの比較（MVC、クリーン、ヘキサゴナル、イベント駆動）
- 既存のアーキテクチャとsteering原則との適合性を評価
- チームの競合を避けるために必要なドメイン境界と所有権の境界を特定
- スケーラビリティへの影響と運用上の懸念を考慮
- 保守性とチームの専門知識を評価
- 採用パターンと却下された代替案を`research.md`に文書化
### 6. リスク評価
**技術的リスクの特定**:
- パフォーマンスのボトルネックとスケーリングの限界
- セキュリティの脆弱性と攻撃ベクトル
- 統合の複雑さと結合度
- 技術的負債の発生 vs 解消
- 知識のギャップとトレーニングのニーズ
## 調査ガイドライン
### 検索すべきタイミング
**常に検索すべきもの**:
- 外部APIのドキュメントとアップデート
- 認証/認可のセキュリティベストプラクティス
- 特定されたボトルネックに対するパフォーマンス最適化技術
- 依存関係の最新バージョンと移行パス
**不確実な場合に検索すべきもの**:
- 特定のユースケースに対するアーキテクチャパターン
- データ形式/プロトコルの業界標準
- コンプライアンス要件（GDPR、HIPAAなど）
- 予想されるロードに対するスケーラビリティアプローチ
### 検索戦略
1. 公式ソースから開始（ドキュメント、GitHub）
2. 最近のブログ記事や記事を確認（過去6ヶ月）
3. Stack Overflowで一般的な問題をレビュー
4. 類似のオープンソース実装を調査
## 出力要件
設計の決定に影響するすべての調査結果を、共有テンプレートを使用して`research.md`に記録:
- アーキテクチャ、技術整合性、コントラクトに影響する主要な知見
- 調査中に発見された制約
- 推奨アプローチと選択されたアーキテクチャパターン（根拠付き）
- 却下された代替案とトレードオフ（設計決定セクションに文書化）
- コンポーネントとインターフェースコントラクトに情報を与える更新されたドメイン境界
- リスクと緩和戦略
- 実装中にさらなる調査が必要なギャップ
まとめ
cc-sddの実体は、膨大な自然言語により設計・実装手順とそれを支えるルール類の集まりでした。総文字数はコマンド、ルール両方を足すと11万字（日本語に翻訳した場合）もあります❗
これだけの、設計・実装に関する知恵を利用できるのは素晴らしい事ですね。
ただし、これらの記述は特定のプラットフォームに依存した知識や、特定のドメインの知識も書かれていないので実際の仕事で使うには、プロジェクト独自の知識やプラットフォーム独自の知識を追加するのが良いかなと思いました。
コマンドやルールのカスタマイズ方法はドキュメントに書かれています。
それらの知識を加えた場合の成果を確認するのに、人間が開発していた時代とは違い高速で低コストにサイクルを回して行けるのは、ソフトウェア開発の新しい時代を導くものだと感じました。
