spec-driven-development
作成者 addyosmanispec-driven-development は、コードを書く前に仕様を作成し、その後、人のレビューを挟みながら計画、タスク、実装へと進めるワークフロースキルです。
このスキルの評価は74/100で、十分に実用的ですが最上位ではない候補です。ディレクトリ利用者にとっては、仕様先行のワークフローを必要とするエージェントにはしっかり役立ち、迷いを減らせるだけの構造もありますが、導入をすぐにスムーズにする補助ファイルやパッケージ化されたガイダンスはまだ不足しています。
- 開始条件が明確: 新規プロジェクト、機能追加、要件が曖昧な変更で使うべきと示し、単純な修正には向かないことも明記している。
- 運用フローが強い: Specify → Plan → Tasks → Implement の4段階をゲート付きで進め、各段階で人のレビューを挟む設計になっている。
- 実用的な深さがある: 複数の見出し、制約、コード例を含む充実した SKILL.md により、エージェントが手順を追いやすい。
- 補助ファイルやインストールコマンドがないため、導入はほぼ SKILL.md の指示に依存する。
- 単一ファイル構成のため、ワークフローを補強したり例外ケースを扱ったりするスクリプト、参照資料、追加リソースがない。
spec-driven-development スキルの概要
spec-driven-development は、コードを書く前に明確な仕様を作り、その仕様をもとに計画・タスク分解・実装を進めるためのワークフロースキルです。新機能の立ち上げ、アーキテクチャ変更、要件があいまいな状態から作業を始める場面で、最終的な実装に含まれる思い込みを減らしたいときに、spec-driven-development スキルは特に効果を発揮します。
このスキルの用途
この spec-driven-development ガイドは、「雑に作ってしまうこと」よりも「そもそも違うものを作ってしまうこと」が主なリスクである場合に向いています。粗いアイデアを、実装に入る前にスコープ・振る舞い・制約・受け入れ基準を定義する共有の正本へと落とし込むのに役立ちます。
導入に向いているケース
このスキルは、特に人間のレビュアーとの認識合わせをより厳密にしたいチームや個人開発者に適しています。たとえば、変更が複数ファイルにまたがる、プロダクト判断に依存する、あるいは「とりあえず実装」で進めると手戻りが出やすい規模のタスクで有効です。また、Skill Authoring 向けの spec-driven-development として、スキル自体に規律あるレビュー可能なアウトプットを生成させたい場合にも役立ちます。
他と違うポイント
このスキルの価値は、仕様策定 → 計画 → タスク化 → 実装というゲート付きの進め方にあります。各段階で人間のレビューを挟むため、単なる汎用プロンプトよりも隠れた前提を減らし、変更コストが低いうちに意思決定を前倒しできます。
spec-driven-development スキルの使い方
インストールしてコンテキストを読み込む
spec-driven-development をインストールするには、エージェントの skills 設定に追加し、まず最初にスキルファイルを開きます。
npx skills add addyosmani/agent-skills --skill spec-driven-development
その後、何より先に SKILL.md を読んでください。このリポジトリには rules/、references/、scripts/ のような補助フォルダは含まれておらず、スキルの文脈はほぼすべてメインのスキルファイルに集約されています。
スキルに具体的な出発点を渡す
spec-driven-development の使い方では、目標・制約・既知の不確定要素を明示すると最も効果が出ます。弱い入力例は「ダッシュボードを作って」。強い入力例は次のようなものです。
“Create a spec for a dashboard that shows subscription health, supports role-based access, and must work with our existing REST API. Ask clarifying questions before drafting the spec. Do not propose implementation details yet.”
このくらい具体性があると、スキルが前提を表に出しやすくなり、設計を早まるリスクも減らせます。
ゲート付きワークフローに従う
このスキルは、各フェーズで妥当性が確認されるまで先に進まない前提で設計されています。実運用では、次の流れになります。
- 問題設定と前提を仕様化する。
- 仕様が承認されたら進め方を計画する。
- 計画をタスクに分解する。
- タスクレビュー後に初めて実装する。
レビューのゲートを飛ばすと、このスキル最大の利点である「未検証の前提による手戻りを減らすこと」が失われます。
まず読んで、そのあと使う
最初に読むべきなのは SKILL.md です。そのうえで、overview、when to use、gated workflow の各セクションを運用ルールとして使ってください。自分のエージェント運用向けにこのスキルを調整する場合も、レビューのチェックポイントと「具体化できるまで問い続ける」挙動は残すのが重要です。ここが最も出力品質の改善につながりやすい部分です。
spec-driven-development スキル FAQ
spec-driven-development は普通のプロンプトより優れていますか？
たいていの場合、タスクがあいまい・横断的・やり直しコストが高いなら優位です。通常のプロンプトは素早くコードを出せますが、誰かが実装を始める前に「何を作るべきか」の合意を取りたいなら、spec-driven-development のほうが向いています。
使わないほうがいいのはどんなときですか？
些細な修正、明白なバグ修正、プロダクト上のあいまいさがほとんどない完結した変更には、spec-driven-development スキルは使わないほうがよいです。そうしたケースでは、完全な仕様サイクルを回すオーバーヘッドのほうが、実作業より重くなることがあります。
初心者でも使いやすいですか？
はい。確認質問に答え、ドラフトをレビューする前提なら、初心者にも扱いやすいです。独自の進め方を一から組み立てるより簡単で、エージェントに対して「一度止まる」「前提を表に出す」「順番どおりに進める」と指示してくれるためです。
Skill Authoring のワークフローにも合いますか？
はい。特に Skill Authoring 向けの spec-driven-development として、新しいスキルを書く、あるいは既存スキルを改善するための再現性ある進め方がほしい場合に向いています。スコープを明確にしたい、レビューのゲートを置きたい、実装前に検証できる仕様が必要、といったオーサリング作業で特に有効です。
spec-driven-development スキルを改善するには
最初に入力の解像度を上げる
最も良い結果が出やすいのは、対象ユーザー・達成したい成果・制約・まだ不明な点を最初から明示したときです。たとえば次のように伝えます。
“Migrate the checkout flow without changing the public API, preserve existing analytics events, and identify any dependency risks before planning.”
前提を必ず列挙させる
よくある失敗は、一見まとまって見えるのに重要な判断が埋もれた、あいまいな仕様です。仕様ドラフトの前に assumptions を列挙するようモデルに求め、その assumptions を計画フェーズへ進む前に人間のエンジニアと確認してください。spec-driven-development が最も時間を節約しやすいのは、たいていこの段階です。
コードではなく仕様を反復する
最初のドラフトがずれていた場合、すぐ実装に行くのではなく、スコープ・受け入れ基準・制約を修正してください。このワークフローは、各修正によって仕様という契約がより明確になるほど効果を発揮します。後続のフェーズは仕様の精度に強く依存するためです。
レビューコストが高い場面で使う
このスキルが最も価値を発揮するのは、誤った前提のコストが高いケースです。たとえば複数ファイルにまたがる変更、アーキテクチャの転換、複数のステークホルダーに影響する機能などです。仕様の初稿がまだぼんやりしているなら、早くタスク化や実装に進めるより、spec フェーズに長めに留めたほうがうまくいきます。