cc-sdd は、AI コーディングエージェントに 仕様駆動開発 をもたらす npm パッケージであり、1 回の npx 実行でインストールされ、その後はすべてスラッシュコマンドを通じて操作される。その目的として掲げられているのは、エージェントと協働して開発を進めながら、要件・設計・タスクを Markdown ファイルとしてリポジトリ内に保持することであり、これによって要件から実装に至る段階的な進行と、各段階でのレビューポイントを、エージェントのインターフェースを離れることなく利用できるようにしている。
その設計は Kiro の仕様駆動開発に着想を得たものとされており、Kiro の仕様とも互換性がある。本ページの執筆のもとになった入門ガイドである 仕様から書くAI駆動開発へ ― cc-sdd 入門 は、この互換性を、Kiro に由来するベストプラクティスを cc-sdd のもとでそのまま再利用できる理由として挙げている。
インストールでは 2 つの場所に書き込みが行われる。スラッシュコマンドはエージェント自身のコマンドディレクトリの下に置かれ、テンプレートと生成ルールのファイルは .kiro/settings/ ツリーの下に置かれる。このツリーには、3 つの仕様ドキュメントのテンプレート、3 つのステアリングドキュメントのテンプレート、そして EARS 形式や設計原則といった事項を扱うルールが含まれる。プロジェクトのコンテキスト用と機能ごとの仕様用のディレクトリはインストール時には作成されず、それぞれ最初にそこを埋めるコマンドによって作成されるため、インストール直後の状態には設定ツリーだけが含まれる。
プロジェクト自身のバージョン 3.0 の README は、cc-sdd をより野心的に、承認済みの仕様を長時間の自律的な実装へと変えるものとして説明しており、その根拠を率直に述べている。cc-sdd は仕様を、エージェントに渡すマスターの指示書ではなく、システムの各部分のあいだの契約として扱う。コードが信頼できる唯一の情報源であり続け、仕様はコードの各部分のあいだの境界を明示することで、人間とエージェントが並行して作業できるようにする。その要約によれば、エージェントが仕様を書き、人間がフェーズゲートで契約を承認し、出荷されるのはコードである。パッケージは MIT ライセンスのもとで公開されている。
機能
バージョン 3.0 は、README では Agent Skills と長時間の自律的な実装を中心とした作り直しとして説明されている。1 つのコマンドでエージェントごとに 17 個のスキルがインストールされ、必要に応じて読み込まれる。以前の /kiro:* コマンドのモードも引き続き利用できるが、非推奨となっている。README が新機能として挙げているのは次のものである。
- エントリーポイントとなるディスカバリースキル。新しい作業を、既存の仕様の拡張、仕様なしでの直接実装、新しい仕様 1 つの作成、または複数の仕様への作業の分解のいずれかに振り分け、ブリーフ（必要に応じてロードマップも）を書き出すことで、スコープを説明し直すことなく作業の流れを再開できるようにする。
- 長時間の自律的な実装のための実装スキル。ホストのエージェントがネイティブのサブエージェントを備えている場合は、各タスクに、フィーチャーフラグの背後でテストファースト（RED → GREEN）で作業する新しい実装担当、独立したレビュー担当、そして行き詰まったときやレビューで繰り返し却下されたときの自動デバッグのパスが割り当てられる。そうでない場合は、実装とレビューはメインのコンテキスト内でインラインに実行される。得られた学びはタスクファイルの実装メモのセクションに引き継がれ、各イテレーションは 1 つのタスクを扱い、記録されたタスクの状態によって再開が可能になっている。
- 境界を優先する仕様の規律。設計ドキュメントにはタスクの境界を決めるファイル構成計画が含まれ、タスクには境界と依存関係の注釈が付き、レビューではスタイルの問題だけでなく境界違反も確認される。
- ロードマップを依存関係のウェーブごとに複数の仕様へと変換する一括作成スキル。ネイティブのサブエージェントが利用できる場合は並列に実行され、矛盾、責務の重複、インターフェースの不一致を確認する仕様横断のレビューを伴う。
サポートされる 8 種類のエージェントのうち、README は Claude Code と Codex（OpenAI Codex）を安定版、Cursor、GitHub Copilot、Devin Local / CLI（Devin）、OpenCode、Gemini CLI、Antigravity（Google Antigravity）をベータ版としており、スキルをインストールしても、そのホストが完全な自律ループを実行できることまでは検証されないと注意を促している。典型的な仕様の出力としては、受け入れ基準を伴う EARS 形式の要件、Mermaid の図とファイル構成計画を含む設計ドキュメント、境界と依存関係の注釈が付いたタスクリストが挙げられており、設定ディレクトリの下にあるテンプレートと生成ルールはチームのワークフローに合わせて編集できるとしている。
コマンドベースの形態を対象に書かれた入門ガイドは、次のものを説明している。
- インストール時のフラグで選択する 8 種類のコーディングエージェントのサポート。そのうち 2 つでは、さらにコマンド形式とサブエージェント形式のどちらかを選べる。
- 言語フラグで選択する複数言語での仕様出力。これにより、生成される要件ドキュメントや設計ドキュメントを英語以外の言語で作成できる。ガイドは 13 言語を挙げているが、バージョン 3.0 の README は 14 言語を挙げている。
- さらに 2 つのインストールフラグ。何も書き込まずに変更内容をプレビューするドライランと、既存のファイルを上書きする前に保存しておくバックアップである。
- コードベースを読み取り、3 つのプロジェクトコンテキストのファイルを生成するステアリングコマンド。それぞれ、プロダクトの目的・対象ユーザー・中核的な価値、技術スタック・バージョン管理の戦略・コーディング規約、ディレクトリ構成のパターンと命名規則を扱う。これらは他のすべてのコマンドが参照するプロジェクトメモリとして機能し、変更されたプロジェクトでこのコマンドを再実行すると差分を検出して同期を提案する。既存のソースを分析することで動作するため、空のディレクトリでは実行できない。
- EARS 形式で要件を作成する要件コマンド。EARS（Easy Approach to Requirements Syntax）は、「〜のとき、システムは〜しなければならない（When…, the system shall…）」といったパターンを用いて曖昧さを減らす構造化された自然言語の形式であり、このコマンドは何を作るのかに答える。
- それをどのように作るのかに答える設計コマンド。エージェントに既存のコードを調査させ、技術設計を別のファイルに書く前に、調査ログを 1 つのファイルに書き出させる。
- 実装のチェックリストを作成するタスク分解コマンド。各タスクに、逐次実行が必要か並列実行が可能かのラベルを付けることで、並行作業の境界を明示する。
- 単一のタスク、順に実行する複数のタスク、または未完了のすべてのタスクを対象にできる実装コマンド。
- 実装の途中で要件が変わったときに使う、更新された仕様とすでに完了したタスクとのあいだの整合性を確認するための検証コマンド。
- 完了時に手動で更新される仕様ごとのステータスフィールド。これによって進行中の仕様と完了した仕様が区別される。
採用とエコシステム
ここには採用状況の数値は記録されていない。その代わりに記録されているのはこのツールの想定される使い方であり、ツールを紹介するガイドは実践上の 2 つの点を強調している。前のフェーズを自動承認するフラグは、ツールを学んでいるあいだは避けるべきである。要件の誤りが設計とタスク分解の両方に波及するからである。また、大きな機能では、精度を保つために、タスクを 1 つか 2 つずつ実行し、そのあいだにエージェントのコンテキストをクリアまたは圧縮するべきである（コンパクション を参照）。いずれも、ツールの文書化された挙動ではなく、そのガイドの著者による推奨である。
ガイド自身の立場は、仕様は実装されたら凍結されるものではなく、開発を通じて継続的に更新される生きたドキュメントであり続けるというものであり、完了した仕様は削除せずにリポジトリにコミットすることを推奨している。その理由は、設計意図の記録として、コードからは読み取れない共有コンテキストとして、将来の保守のための参照として、そしてレビュー担当者のためのコンテキストとしてである。推奨される粒度は、1 つのプルリクエストにつき 1 つの仕様である。これに向かない作業として、誤字のような小さな修正、1 回のやり取りで片が付くタスク、明確な目標のない探索的な作業の 3 種類が挙げられている。