この記事の対象読者
- Claude Code に cc-sdd v3（Kiro スタイルの仕様駆動開発ツール）を入れてみたけど、
/kiro-*コマンドが多すぎて最初の一手で固まっている人 - とりあえず動かして、仕様駆動開発の雰囲気を掴みたい人
この記事は cc-sdd（執筆時点の最新 v3.0.2）の Claude Code 版スキル（全 17 個）を前提にしています。
先に結論
迷ったら /kiro-discovery から！
先に自分的答えを言います。
初めてなら、あるいは新規プロジェクトなら、これ一択かなと思います。
/kiro-discovery "作りたいもの / やりたいことを自然言語で"
ちょっと昔に触った方でも暫く触らないうちに v3 でかなり仕様が変更されていました。
「あれ、でも kiro-steering が Phase 0 にあるじゃん。0 って一番最初でしょ？ そっちが先じゃないの？」と思うかもしれませんが、次の章でスッキリさせます。
/kiro-steering は必要？
CLAUDE.md に cc-sdd のワークフローはこう書かれています。
Phase 0 (optional): /kiro-steering, /kiro-steering-custom
Discovery: /kiro-discovery "idea"
Phase 1: /kiro-spec-init → requirements → design → tasks
Phase 2: /kiro-impl
kiro-steering が Phase 0、kiro-discovery がその後。だから「番号順にやるなら steering が先では？」と読めてもしまいます。
「Phase 0」の "0" は「やるなら一番最初」という順序ラベルであって、「必ず最初にやれ」という意味ではありません。Phase 0 には (optional) = 任意 と明記されていますので、つまり「やってもやらなくてもいい。もしやるなら他より前」というだけです。
では、いつ steering をやるべきで、いつスキップしていいのか？ 判断基準はたった 1 つ、「既存のコードベースがあるか」 です。
| あなたの状況 | 最初にやること |
|---|---|
| 新規プロジェクト（コードがまだ無い） |
/kiro-discovery から始める。steering は後回しで OK |
| 既存コードベースがある（途中から cc-sdd 導入） | 先に /kiro-steering で既存コードの前提を吸い上げてから discovery へ |
kiro-steering の仕事は「既存のコードベースを読み取って、プロジェクト全体のルール（技術スタック・構成・プロダクト方針）をメモリ化する」ことです。
そのため、新規プロジェクトにはまだ読み取る対象のコードがないので、プロジェクトの方向性が固まってきた後や、コードが育ってきた段階でやる方が、はるかに価値が出ます。
kiro-discovery は何をするの？
一言でいうと「やりたいことを聞いて、この先どう進めるべきかを仕分けてくれる受付」です。あなたは分類を考える必要がありません。丸投げで OK。
/kiro-discovery "〇〇を作りたい" と打つと、内部で次を自動でやってくれます。
- 既存の
.kiro/specs/や.kiro/steering/の状態を軽くスキャン - 5 つの進め方（Path A〜E）から自動で判定
- 対話で不明点を深掘り
- 2 〜 3 案を提示して、おすすめを提案
-
brief.md（単一 spec）やroadmap.md（複数 spec）をファイルに書き出す - 次に打つべきコマンドを教えてくれて停止
つまり「次に何を打てばいいか」で悩む必要が構造的に無い。discovery が毎回ナビしてくれます。
discovery が判定する 5 つの Path
| Path | どんな時 | discoveryが案内する次の一手 |
|---|---|---|
| A 既存 spec 拡張 | 既存 spec の範囲内の追加・改修 | /kiro-spec-requirements {feature} |
| B spec 不要 | バグ修正・設定変更・些細な追加 | そのまま直接実装（spec を作らない） |
| C 新規・単一 spec | 新機能で 1 つの spec に収まる | /kiro-spec-init |
| D 新規・複数 spec | 複数領域にまたがる大きめの機能 | /kiro-spec-batch |
| E 混在 | 既存拡張＋新規 spec が混ざる | 内容に応じて init / batch |
全体フロー
仕様駆動開発の前提は変わらない
cc-sdd を「ただのコマンド集」だと思うと本質を見失います。核心は requirements → design → tasks → implementation を、人間の承認で 1 段ずつ進める ことは今までと変わりません。
- 各フェーズで人間のレビューが必須です。承認するまで次に進めません
-
kiro-implは tasks まで承認済みにならないと実装を始めません -
-y（kiro-spec-design/kiro-spec-tasks）や--auto（kiro-spec-quick）は、この承認の一時停止を意図的にスキップする早送りフラグで、内容を確認せず通すことになるので、理解してから利用するのがおすすめ
なお、各 spec の状態管理は .kiro/specs/{feature}/spec.json で管理されます。
全 17 スキル早見表
Phase 0：準備（任意 / 主に既存コードがある人向け）
| スキル | 用途 | コマンド |
|---|---|---|
kiro-steering |
プロジェクト全体のルールをメモリ化 | /kiro-steering |
kiro-steering-custom |
ドメイン特化のカスタム steering を追加 | /kiro-steering-custom |
入口
| スキル | 用途 | コマンド |
|---|---|---|
kiro-discovery |
進め方の仕分け＋アイデア整理 | /kiro-discovery "アイデア" |
Phase 1：仕様策定
| スキル | 用途 | コマンド |
|---|---|---|
kiro-spec-init |
spec を初期化 | /kiro-spec-init "説明" |
kiro-spec-requirements |
EARS 形式で要件生成 | /kiro-spec-requirements {feature} |
kiro-validate-gap（任意） |
既存コードとの差分分析 | /kiro-validate-gap {feature} |
kiro-spec-design |
要件→設計 | /kiro-spec-design {feature} [-y] |
kiro-validate-design（任意） |
設計レビュー | /kiro-validate-design {feature} |
kiro-spec-tasks |
設計→タスク分解 | /kiro-spec-tasks {feature} [-y] |
kiro-spec-quick |
要件〜タスクを一括生成 | /kiro-spec-quick "説明" [--auto] |
kiro-spec-batch |
複数 spec を並列一括作成 | /kiro-spec-batch |
kiro-spec-status |
進捗確認（いつでも） | /kiro-spec-status [feature] |
Phase 2：実装
| スキル | 用途 | コマンド／呼ばれ方 |
|---|---|---|
kiro-impl |
タスクを TDD で実装（自律/手動） | /kiro-impl {feature} [tasks] |
kiro-review |
タスク単位のレビュー | 実装中に自動適用 |
kiro-debug |
詰まった時の原因調査 | 実装中に自動適用 |
kiro-verify-completion |
「完了」主張前の証拠確認 | 完了報告前に自動適用 |
kiro-validate-impl |
feature 全体の最終統合検証 | /kiro-validate-impl {feature} |
よくある疑問（FAQ）
Q1. バグ修正みたいな小さい作業でも /kiro-discovery を使うの？
使って OK です。 discovery の役割は「新規 spec を作ること」ではなく「spec 化が必要かどうかを判定すること」。
バグ修正なら一瞬で「Path B＝spec不要、直接直そう」と判定して即終了するだけで、重い処理は走りません。
ただし、typo 修正のように「どう見ても spec いらない」と自明なら、discovery を挟まず普通に「ここ直して」と頼んでも全く問題ありません。
Q2. 「何が起きてるか分からない、まず調査したい」時はどのコマンド？
kiro コマンドは使いません。 普通に自然言語で Claude に「これ調べて」と頼めば OK です。kiro コマンドは「これから何をすべきか方針が見えている話」を仕分けるためのもの。原因や対応が見えてきた時点で、初めて /kiro-discovery に渡します。
Q3. /kiro-spec-quick と個別コマンド、どっちを使えばいい？
急いでいて要件〜タスクを一気に作りたいなら kiro-spec-quick。1 フェーズずつ内容を確認しながら進めたいなら個別コマンド（init → requirements → design → tasks）。初回はまず個別コマンドで、各フェーズで何が生成されるかを見ながら進めるのがおすすめです。
Q4. kiro-discovery や kiro-impl が勝手に起動しないんだけど？
仕様です。この2つは disable-model-invocation: true が設定されていて、Claudeの自動判断では起動しません。必ずスラッシュコマンドで明示的に打ってください。
まとめ
初めての人が覚えることは実質 2 つだけ
- 新規プロジェクトなら、まず
/kiro-discovery "作りたいもの"を！ - あとは discovery が次のコマンドを毎回教えてくれるので、requirements → design → tasks を承認で 1 段ずつ進めて、tasks まで承認したら
/kiro-implで実装！