spec — spec ミューテータ

まだ読み込まれていない場合は、リポジトリのルートの FORMAT.md を読む。Caveman スキルはここでのすべての書き込みに適用される。

DISPATCH

ユーザーリクエストとプロジェクト状態を検査:

1. SPEC.md がリポジトリのルートにない かつ args でアイデアを記述 → NEW
2. SPEC.md がない かつ args に from-code → DISTILL
3. SPEC.md が存在 かつ args が bug: で開始 → BACKPROP
4. SPEC.md が存在 かつ args が amend で開始 → AMEND
5. SPEC.md が存在、args なし → ユーザーにモードを尋ねる

NEW — アイデア → 仕様

入力: ユーザーのアイデア。

ステップ:

1. ゴールを抽出（1行、caveman）。→ §G.
2. ユーザーが述べた、または暗に示唆した制約をリストアップ。→ §C.
3. ユーザーが名付けた外部サーフェスをリストアップ。→ §I.
4. 初期不変条件を提案。→ §V（番号付き V1…）。
5. ゴールを順序立てたタスクに分解。→ §T パイプテーブル、すべてのステータスは .、id は T1…
6. §B セクション、ヘッダー行のみ（id|date|cause|fix）。

SPEC.md に書き込む。ユーザーに完全なファイルを表示。「spec OK? 編集を提案するか build を呼び出してください」と尋ねる。

DISTILL — コード → 仕様

リポジトリを歩く。§G を生成（README/package.json/メインエントリから推測）、§C（スタックから推測）、§I（パブリック API/CLI/設定を列挙）、§V（テストとアサーションから派生）、§T（既知の TODO または欠落しているテストごとに 1 タスク）、§B（空）。

すべての箇所で Caveman を使用。不確かなアイテムに ? でフラグを付けてユーザーが確認できるように。

BACKPROP — バグ → §B + §V

入力: bug: <description>。

ステップ:

1. バグの説明をパース。
2. 根本原因を見つける（関連コードを読む）。
3. 判断: 新しい不変条件が再発を防ぐだろうか? Yes の場合 → ドラフト V<next>。
4. §B 行を追記: B<next>|<date>|<cause>|V<N>。
5. 新しい不変条件を §V に追記。
6. 修正が動作を変更する場合 → §T 行を追加/更新。
7. diff を表示。ユーザーが OK したときのみ適用。

ルール: すべてのバグは §B エントリを取得。不変条件はオプションだが推奨。

AMEND — ターゲット編集

入力: amend §V.3 または amend §T など。

そのセクションを読む。現在の状態を表示。ユーザーに何を変更するか尋ねる。書き込む。diff を表示。

ユーザーが名付けなかったセクションを暗黙的に書き換えることはない。

OUTPUT ルール

• FORMAT.md ごとの Caveman 形式。
• 識別子、パス、コードはそのままに保持。
• 番号付けは単調 — §V.N または §B.N を再利用しない。
• §T 行の cites カラム ! §V/§I deps のリスト: T5|.|impl auth mw|V2,I.api。

NOン GOALS

• サブエージェントなし。メインスレッドが書き込む。
• ダッシュボード、ログ、SPEC.md 自体以外の状態ファイルなし。
• 仕様後の自動ビルドなし。ユーザーは明示的に build を呼び出す。