spec-driven-tdd について
spec-driven-tddは、OpenSpecとSuperpowersを使う開発者向けの実装スキルです。タスクごとにテスト駆動開発を進め、worktreeの分離やレビュー、進捗管理を工程に組み込みます。
主な機能
- 01OpenSpecによる計画とタスク管理
- 02リスクに応じた実現可能性の検証
- 03変更ごとのGit worktree分離
- 04REDからGREENへ進めるタスク実装
- 05完了前のコードレビュー
- 06検証、アーカイブ、仕様同期
活用シーン
- 01OpenSpecで実装範囲とタスクを整理
- 02テストを先に書いて変更を実装
- 03進行中のコード作業を分離
- 04レビュー後にタスクを完了扱いにする
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/spec-driven-tddを入力して読み込まれたか確認します。
詳細
spec-driven-tdd
OpenSpec で計画と進捗を管理します。Superpowers の規律に従って実装します。一度に一つの変更、一度に一つのタスクを扱います。
基本原則： OpenSpec は 何をするか と 進捗 を管理し、実行スキルは どのように行うか を担います。タスクが完了となるのは、テストが成功したときではなく、レビューで問題がなくなったときだけです。
依存関係
OpenSpec CLI と Superpowers のインストールが必要です。参照されているスキルまたはコマンドを利用できない場合は、その旨を伝え、docs/dependencies.md に従って代替手段に切り替えてください。手順を黙って省略してはいけません。/code-review は Claude-Code 専用の任意の拡張機能です。
ライフサイクル
1. 計画（OpenSpec）
任意 — 実現可能性のスパイク（リスクに応じて実施）。 未検証のアプローチ、外部 API、「これは可能か」という未解決の疑問など、技術的なリスクが実証されていない場合は、提案の前に spike スキルを呼び出してください。実現可能性がすでに明らかな場合は省略します。判定結果に従ってください。VALIDATED → 提案に進みます。PARTIAL → 実行可能な範囲にスコープを絞ってから提案します。INVALIDATED → 停止し、変更を作成しないでください（その理由をユーザーに伝えます）。スパイクのコードは破棄可能なものであり、変更の作業ツリーには決して含めません。
作業に対応する変更が存在しない場合は、/opsx:propose を実行します（brainstorming を使ってスコープをまとめてから、提案、設計、タスクを作成します）。OpenSpec をスコープとタスクリストの唯一の信頼できる情報源とします。そこにないタスクを独自に追加してはいけません。
2. 分離（worktree）
コードに手を加える前に、using-git-worktrees を呼び出して変更用の独立した worktree を作成し、メインのワークスペースをクリーンな状態に保ちます。（最後には finishing-a-development-branch と組み合わせます。）
3. 実装 — タスクごとのループ
/opsx:apply を使ってタスクリストとコンテキストを取得します（contextFiles のパスをすべて読みます）。次に、保留中のタスクごとに、以下の短いサイクルを実行します。
- RED —
test-driven-developmentを呼び出し、まず失敗するテストを書きます。失敗するテストなしに本番コードを書いてはいけません。 - GREEN — テストを通すための最小限のコードを実装します。テストが予想外に失敗した場合は、推測する前に
systematic-debuggingを呼び出します。 - REFACTOR — テストが成功している状態で、ユニット内のコードを整理します。
- 簡素化 — このパックの
simplifyスキルを呼び出し、差分全体の品質を確認してもらいます。編集も適用されます。 - テストを再実行 — 簡素化の後もテストが成功する状態を保つ必要があります。
- レビュー — タスクの差分に対して
requesting-code-reviewを呼び出し、指摘にはreceiving-code-reviewを使って対応します。Claude Code では、追加で/code-reviewを実行してもかまいません。続行する前に、Critical と Important の指摘を修正します。 - 完了にする — ここまで完了してから、OpenSpec のタスクファイルでタスクを
- [ ]から- [x]に変更します。
任意のモード — 大規模な変更： タスクリストが実際に大規模で、タスクが互いに独立している場合に限り、subagent-driven-development に委任します。インラインで実行できる少数のタスクには使いません。このスキルは各タスクを新しいサブエージェントに割り当て、タスクごとにレビューを行います。dispatching-parallel-agents は共有状態のないタスクにのみ使い、同時に実行するサブエージェントの数は少なく保ちます。
タスクが曖昧な場合、または実装中に設計上の問題が判明した場合は、一旦停止して確認を求めます（その際、OpenSpec の成果物を更新することを提案します）。
4. 完了
すべてのタスクが [x] になったら、次の手順を実行します。
verification-before-completion— 変更が実際に機能することを確認します。finishing-a-development-branch— worktree のブランチを統合します。/opsx:archive、続けて/opsx:sync— 追跡を終了し、メインの仕様を更新します。
チェックリスト
- OpenSpec で変更を選択または作成済み
- worktree を作成済み
- すべてのタスクで
[x]にする前に RED→GREEN→REFACTOR→簡素化→レビューを実施済み - すべてのタスクが
[x] - 検証済み、ブランチを完了し、変更をアーカイブして同期済み