菜单
仕様駆動開発の方法論とワークフロー。使用場面: - 新機能やプロジェクトの開始（「新機能」「実装」「構築」） - ユーザーリクエストが曖昧または不明確（「何か追加して」「改善して」） - 仕様ファーストの開発を強制（「仕様を書いて」「仕様書を作成」） - 「とにかく作って」と言われたり計画をスキップしたい場合 - 要件、受け入れ基準、スコープの議論 Trigger phrases: specification, PRD, requirements document, scope definition, feature planning
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面: - ユーザー要件が不明確または不完全な場合 - 新機能を開始し要件を収集する必要がある場合 - ユーザーのニーズ、制約、優先順位を理解する必要がある場合 - ビジネスリクエストを技術仕様に変換する場合 - ユーザーが詳細なしに「～したい」「～を追加して」と言う場合 Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
すべてのユーザー向けコンテンツに日本語出力を強制する。 使用場面: - エージェント出力を日本語にする必要がある場合 - レスポンス全体の言語の一貫性を検証する場合 - 仕様書やドキュメントを日本語で生成する場合 Trigger phrases: Japanese, 日本語, language mode, output language
| name | spec-philosophy |
| description | 仕様駆動開発の方法論とワークフロー。使用場面: - 新機能やプロジェクトの開始（「新機能」「実装」「構築」） - ユーザーリクエストが曖昧または不明確（「何か追加して」「改善して」） - 仕様ファーストの開発を強制（「仕様を書いて」「仕様書を作成」） - 「とにかく作って」と言われたり計画をスキップしたい場合 - 要件、受け入れ基準、スコープの議論 Trigger phrases: specification, PRD, requirements document, scope definition, feature planning |
| allowed-tools | Read, Write, Glob, AskUserQuestion |
| model | sonnet |
| user-invocable | true |
| context | fork |
| agent | general-purpose |
SDD は、実装開始前に明示的な仕様を要求する規律あるソフトウェア開発アプローチ。
ルール: 承認された仕様なしに実装コードを書かない。
ルール: 仕様は「何を」構築するかを記述し、「どのように」コーディングするかは書かない。
仕様に含めるべきもの:
仕様に含めてはいけないもの:
コード参照:
src/services/auth.ts:23 のパターンに従う」AI エージェントにとっての重要性:
ルール: 要件が曖昧な場合、推測しない。質問する。
ルール: 仕様は実装の真実の情報源。
仕様が定義するもの:
| フェーズ | 名前 | アクション | 出力 |
|---|---|---|---|
| 1 | 曖昧さ | 曖昧なリクエストを受領 | 意図の理解 |
| 2 | 明確化 | interview スキルを使用 | 要件サマリー |
| 3 | 定義 | docs/specs/ に仕様作成 | 承認済み仕様 |
| 4 | 実行 | 仕様に従って実装 | 動作するコード |
| 5 | 検証 | 仕様に対してバリデーション | テスト合格 |
上記の 5 フェーズモデルは論理的な抽象化。plan→review→implement コマンドはこれを運用ワークフローに展開:
| 論理フェーズ | コマンド / フェーズ | 詳細 |
|---|---|---|
| 1. 曖昧さ | /spec-plan: ディスカバリー | 初期要件収集 |
| 2. 明確化 | /spec-plan: 探索 + 明確化質問 | コードベース分析とユーザーインタビュー |
| 3. 定義 | /spec-plan: 仕様ドラフト + アーキテクチャ設計 | セルフレビュー付きの仕様と設計 |
| 4. レビュー | /spec-review: インタラクティブフィードバック | ユーザー主導のプランレビューと改善 |
| 5. 実行 | /spec-implement: 実装 | TDD 駆動の開発 |
docs/specs/
├── SPEC-TEMPLATE.md # 新規仕様のテンプレート
└── feature-*.md # 機能仕様
| エージェント | SDD での役割 |
|---|---|
product-manager | 仕様を作成 |
system-architect | システムレベル設計（ADR、スキーマ） |
code-architect | 機能実装のブループリント |
*-specialist | 仕様を実装 |
qa-engineer | 仕様を検証 |
security-auditor | セキュリティ NFR を監査 |
詳細情報:
docs/specs/SPEC-TEMPLATE.md を参照SDD は構造を提供するが、厳格な遵守は効果的な問題解決を妨げることがある。
Claude Code Best Practices より:
"Claude often performs better with high level instructions rather than step-by-step prescriptive guidance."
SDD への適用:
| シナリオ | フル Plan→Implement | 簡略化 |
|---|---|---|
| 新機能 | はい | |
| 複雑な変更 | はい | |
| アーキテクチャ判断 | はい | |
| バグ修正 | はい /debug | |
| タイポ/設定変更 | はい /quick-impl | |
| 明確でスコープが限定されたタスク | はい /quick-impl |
SDD ワークフローはフレームワークであり、チェックリストではない。
逸脱が必要な状況を特定した場合:
L1 ルール（絶対にスキップしない）:
L2/L3（必要に応じて適応）:
/spec-plan を使用（明らかに小さなタスクには /quick-impl を使用可能）