新規プロジェクトで始める¶

このページでは、まだ実装を始めていないプロジェクトへ SpecBind を導入し、最初のリリース範囲を複数の責務へ分けて、スコープの確認から実装の検証まで進めます。

必要な環境とエージェントについては、ルートを選ぶの「どちらのルートでも必要なもの」を確認しておいてください。

用語について

出てくる用語（ Spec、Steering、Milestone、Gate など）は基本概念にまとめています。先に目を通しても、出てきたときに参照してもかまいません。

始める前に¶

SpecBind が得意なのは、何を作るかをゼロから探索することではありません。ある程度見えてきたプロダクトの輪郭を仕様として定着させ、その仕様で計画・実装・検証を駆動することです。MVP や主要ユースケースが頻繁に入れ替わる段階では、SpecBind の成果物が探索の足枷になることがあります。

次のような状態になっていれば、このルートで始められます。

何を作るかは決まっている
MVP やスコープもだいたい決まっている
画面・機能・主要ユースケースが列挙できる
ただし実装詳細や例外系、画面間の契約までは詰め切れていない

まだこの状態でなければ、先に SpecBind を使わずにプロトタイプを作る探索フェーズを進め、維持したいプロダクト意図と最初の責務が見えてから導入することをおすすめします。その場合は既存プロジェクトで始めるへ進んでください。

なお、導入前に要件定義をすべて終える必要はありません。詰め切れていない内容は Requirements や Design で具体化できます。それまでの成果物は、後述する Discovery のインプットにできます。

1. プロジェクトの土台を作る¶

対象プロジェクトを Git リポジトリとして初期化します。少なくともプロジェクトの目的を短く書いた README を用意し、ライセンス、言語やフレームワークの設定など、すでに決めた土台があれば一緒に追加してください。利用した雛形生成ツールが Git も初期化した場合は、git initを省略できます。

最初の Milestone は Git コミットを基準にするため、SpecBind で Discovery を始める前に、この土台をコミットしておく必要があります。

git init
git status --short
git add .
git commit -m "Initialize project"

git status --shortで追加対象を確認してからステージしてください。コミットする内容やメッセージは、プロジェクトの方針に合わせます。

2. SpecBind をインストールする¶

CLI の導入とプロジェクトへの配置は、両ルート共通の SpecBind をインストールするにまとめています。

mise use github:Huruikagi/specbind
mise lock
specbind install --agent codex --language ja --project-instructions

エージェントの選び方、--dry-runでの事前確認、書き込まれるファイル、コミットとセッションの開き直しは、そのページを参照してください。手順 1 で作った土台とは分けてコミットします。

インストールが済んだら、このページへ戻ってきてください。以降のスキル呼び出しは Codex の表記（$）で示します。Claude Code では/に読み替えてください。

3. 設定は既定のまま進める¶

初回のインストールが成功すると、sb-configureで設定レビューを行うよう案内されます。ただし最初は、この案内に従う前に、既定値のまま最初のリリース範囲を一周することをおすすめします。SpecBind の既定のテンプレートや判断基準は、そのまま使えるように設計されています。特に新規プロジェクトでは、まだ判断材料が少ないので、一周して調整したい面が見えてからsb-configureに見直しを依頼すれば十分です。方法はカスタマイズにまとめています。

4. 最初のリリース範囲を用意する¶

新規プロジェクトでは、1 つの小さな機能に絞る必要はありません。最初のリリースで一緒に届けたいプロダクト範囲をまとめて用意します。Discovery が入力全体を読み、長く維持する責務の境界、作業順序、Spec 間の依存へ振り分けます。

このガイドでは、タスクの登録・一覧・完了と、期限前のリマインダーを最初のリリース範囲とします。すでにある要件定義の成果物を、プロジェクト内のディレクトリへ置いたとします。

docs/product-definition/
├─ task-management.md
└─ reminders.md

Discovery へ渡せるのは、プロジェクト内にあって Git で追跡済みのテキストファイルまたはディレクトリです（ Source Collection ）。ディレクトリは配下を再帰的に棚卸しします。未追跡・シンボリックリンク・読めない形式が混ざっていると一部だけで進めずに停止するので、渡す前に資料を確認し、手順 1 の土台と一緒にコミットしておいてください。

すでに決めた長期的な方針がある場合¶

Steering は、プロジェクト全体で長く維持する目的、技術上の制約、構造上の方針を記録する場所です。空の Steering も有効なので、最初の範囲を始めるためだけに方針を作り足す必要はありません。

すでに決めた長期的な方針がある場合は、Discovery の前にsb-steeringへ bootstrapモードでの作成を依頼しておくことができます。

$sb-steering この新規プロジェクトで、すでに決めた長期的な方針から
最初のSteeringを提案して。書く前に内容を確認したい。

スキルはプロジェクトの証拠を調べ、書く内容を先に提案します。まだ決めていない技術や構造を先回りして決める必要はありません。作成した場合は内容を確認し、コミットしてから続けます。

5. Discovery でスコープを確認する¶

用意したディレクトリを、最初のリリース範囲として discovery スキルへ渡します。

$sb-discovery docs/product-definition/ の内容を最初のリリース範囲としたい

Discovery はコレクションを全部棚卸しし、各ファイルをどの作業に使うか、今回は使わないかを示します。細かい要件や設計は後続の Plan で詰めます。技術や構成の選定も Discovery の範囲外で、決まっていれば手順 4 の Steering、まだなら後続の Design で扱います。

Discovery は、プロジェクトの現在の状態（ Spec、Steering、Milestone ）を読んだうえで、入力を分類します。新規プロジェクトではまだ既存の Spec が無いので、今回の範囲は Direct（既存の仕様を変えずにできる小さな変更）か 新規 Spec（プロジェクトに新しい責務を 1 つ増やす）のいずれかになります。

用語: Spec

Spec は「プロジェクトが持ち続ける 1 つの能力の境界」で、責務を表す短い kebab-case の ID が付きます（用語は基本概念）。今回の範囲がタスク管理とリマインダーの 2 つの責務に分かれるなら、それぞれ別の新規 Spec になります。

分類の結果は、次の項目にまとめて提案されるので、確認してください。

作業項目（ Work items ） — 今回行う作業の一覧
新規 Spec （ New Specs ） — 新しく作る責務の境界
Gate の無効化（ Gate invalidations ） — やり直しになる既存の承認
依存関係（ Dependencies ） — 作業どうしの依存関係（例: リマインダー → タスク管理）
入力資料の網羅状況（ Source coverage ） — 棚卸しした全ファイルと、その振り分け先または不使用の理由（資料を渡したときに付く）

入力に取りこぼしがないこと、責務の境界、依存関係に納得してから承認します。ここでの結論が以降のワークフロー全体の前提になります。

承認すると、CLI が Milestone と Spec の状態を作ります。エージェントは、Roadmap にコレクション全体の振り分けを、各 Spec の作業メモ（brief.md）にはその Spec が参照する資料だけを記録します。資料は仕様そのものではないので、後続の Requirements と Design が該当ファイルを読み、採用した内容を正規の成果物へ書き直します。

途中で状態を確認したくなったら、次のように依頼できます。

$sb-status

このスキルは読み取り専用で、承認したり成果物を書き換えたりはしません。

6. 計画と実装の進め方を選ぶ¶

最初のリリース範囲には複数の Spec があるため、通常は次の組み合わせで進めます。

$sb-plan --all
$sb-drive

Plan で Milestone 全体の Requirements、Design、Contract レビュー、Tasks を確定し、Drive で安全に到達可能な実装と検証を進めます。局所的な判断待ちは保留して独立項目を続け、リリース前で停止します。詳しい動作と停止条件は Plan と Drive で Milestone を進めるを参照してください。

各成果物と Gate を段階ごとに確認する場合は、 1 件ずつ計画・実装するへ進みます。どちらも同じ所有スキル、レビュー、CLI が記録する証拠を使い、各境界を自分で選ぶ粒度だけが異なります。

7. 生成された成果物を見る¶

Spec の成果物は、既定では.specbind/specs/<spec>/にできます。

.specbind/
├─ steering/roadmap.md
└─ specs/
   ├─ task-management/
   │  ├─ spec.yaml
   │  ├─ brief.md
   │  ├─ requirements.md
   │  ├─ design.md
   │  ├─ contract.yaml
   │  └─ tasks.yaml
   └─ reminders/
      └─ ...

spec.yaml、roadmap.md、tasks.yamlに入っている実行状態は CLI の持ち物です。状態を進める目的で手編集しないでください。Requirements、Design、Contract、 Tasks の計画部分は、それぞれを所有するスキル経由で保守します。

現在の状態は、CLI から直接確認することもできます。

specbind milestone status
specbind spec status <spec-id>
specbind tasks list <spec-id>
specbind artifact list <spec-id>

周辺ツールやスクリプトから Milestone と Spec の状態を読む場合に限り、2 つの statusコマンドはコマンド固有の JSON 出力も提供します。通常の利用では既定の簡潔なテキスト出力をそのまま使います。

specbind milestone status --json
specbind spec status <spec-id> --json

次に読む¶

基本概念
1 件ずつ計画・実装する
Plan と Drive で Milestone を進める
リリースする — Milestone を実際に締めるとき
カスタマイズ — 一周して調整したい点が見えてから
現在のスキル一覧（英語）
現在の成果物一覧（英語）

ユーザーガイド | SpecBind をインストールする | 既存プロジェクトで始める