build

build — 仕様を実装する

ネイティブな単一スレッドの計画→実行。あなたがメインのClaudeです。スウォームは使いません。

LOAD

1. SPEC.md を読みます。存在しない場合 → まずspecスキルを呼び出すようユーザーに伝えます。そこで停止します。
2. まだ読み込んでいない場合は、FORMAT.md を一度読みます。
3. §Rがあれば読みます — ビルドで順守すべき外部事実です。⊥ 再導出または矛盾がないか確認します。
4. 呼び出し引数を解析します。
   • §T.n → そのタスクのみ
   • --next → ステータスが . または ~ の行のうち、番号が最も小さいもの
   • --all または引数なし → §Tの順に、すべての . 行

影響範囲が大きい場合（共有モジュール、認証、データ、金銭、公開されている§I）は、先に /review を実行します。簡単で元に戻せる場合は、計画の手順を省略してEXECUTEに進みます。

PLAN

ネイティブな計画モードを使います。タスク分解を独自に作り直さず、計画モードに委ねます。選択したタスクごとに：

1. 該当する§Vの不変条件をすべて引用します。計画ではすべて順守する必要があります。
2. 変更する§Iのインターフェースをすべて引用します。形状を維持する必要があります。
3. 作成／編集するファイルを列挙します。
4. 検証条件 — 該当する各§Vを証明する、正確なテスト／受け入れ基準を明記します。「テストを追加する」ではなく、どのテストかを示します。「TDDを行う」だけでは逆効果です。仕様には何を確認すべきかが書かれています。該当する各§Vについて、最初に失敗する名前付きテストを指定します。
5. 検証コマンド（テスト、ビルド、lint）を明記します。これが外部オラクルです。成功なら完了、⊥「完了したように見える」ではありません。

計画を提示します。自動モードでない限り、ユーザーの承認を待ちます。

EXECUTE

タスクごとに、順番に実行します。

1. §T.nのステータス欄を . から ~ に変更します。SPEC.mdにのみ書き込みます。
2. 計画に従ってコードを編集します。
3. 検証コマンドを実行します。
4. 成功 → ~ から x に変更します。次のタスクに進みます。
5. 失敗 → backpropスキルを呼び出します。やみくもに再試行してはいけません。

FAIL → BACKPROP

テスト／ビルドの失敗時：

1. 失敗出力を読みます。
2. 問いかけます。失敗の原因は（a）自分のコードのバグ、（b）仕様の誤り、（c）未指定のエッジケースのどれか？
3. （a）の場合 → コードを修正して再実行します。仕様は変更しません。
4. （b）または（c）の場合 → まず bug: <cause> を指定してspecスキルを呼び出し、§Vと§Bを更新させてから、更新済みの仕様に基づいてビルドを再開します。

ルール：バックプロパゲーションを検討せずに、根本原因を黙って修正してはいけません。§Bは再発を防ぐための記録です。

WRITE POLICY

• §Tのステータスのみ変更します。buildからSPEC.mdの他の箇所を編集してはいけません。
• その他の仕様変更にはspecスキルを呼び出します。
• §Tの完了ごとにコミットします。メッセージ：T<n>: <goal line> + §Vの引用。

VERIFICATION

以下の場合のみ、タスクを x にします。

• 検証コマンド（オラクル）が終了コード0で終了する。
• 該当するすべての§Vに、検証条件で指定した名前付きテストがあり、それらが成功する。
• §Vの不変条件に後退がない（最後に全テストスイートを実行する）。

NON-GOALS

• サブエージェントは使いません。並列ワーカーも使いません。メインスレッドのみです。
• 進捗ダッシュボードは作りません。cat SPEC.md | grep §T がダッシュボードです。
• 選択したタスクの範囲を超える、推測に基づく作業はしません。