在 repo 根目錄建立、修訂或反向傳播 bug 至 SPEC.md。專案規格唯一的修改者。當使用者要求撰寫規格、開始新規格、從現有程式碼提煉規格、新增不變量、修訂章節（§G、§C、§I、§V、§T、§B），或透過反向傳播記錄 bug 時觸發。常見說法：「為...撰寫規格」、「新規格」、「bug: ...」、「修訂 §V.3」、「從程式碼提煉規格」、「將此想法寫成規格」。閱讀並遵循 FORMAT.md 以了解 caveman 編碼規則以及 §T 和 §B 的 pipe-table 格式。
spec — 規格修改器
若尚未載入，請閱讀 repo 根目錄的 FORMAT.md。此處所有寫入皆適用 caveman 技能。
分派
檢查使用者請求與專案狀態：
- repo 根目錄沒有
SPEC.md且參數描述想法 → 新增 - 沒有
SPEC.md且參數包含from-code→ 提煉 SPEC.md存在且參數以bug:開頭 → 反向傳播SPEC.md存在且參數以amend開頭 → 修訂SPEC.md存在且無參數 → 詢問使用者要哪種模式
輸入 — spec 是唯一的修改器
其他動詞產生素材；spec 負責寫入。將它們的交接區塊整合到正確的章節，顯示差異，確認後寫入：
- grill → 精煉的 §G + §C
- research → §R 行（若無 §R 章節則新增）
- review → 草擬的 §V 行 + 風險判定
- deepen → §I/§V/§T 修訂
⊥ 重寫交接未指名的章節。章節所有權（見 FORMAT.md）。
新增 — 想法 → 規格
輸入：使用者想法。若想法模糊，建議先執行 grill。
步驟：
- 提取目標（1 行，caveman）。→ §G。
- 列出使用者陳述或暗示的限制。→ §C。
- 列出使用者指名的外部介面。→ §I。
- 僅當 research 已執行時才加入 §R — 否則省略該章節（適度調整）。
- 提出初始不變量。→ §V（編號 V1…）。
- 將目標分解為有序任務。→ §T pipe table，所有狀態為
.，id 為 T1… - §B 章節僅含標題列（
id|date|cause|fix）。
寫入 SPEC.md。向使用者顯示完整檔案。詢問：「規格 OK？高風險請 /review，否則 /build。」
提煉 — 程式碼 → 規格
走訪 repo。產生 §G（從 README/package.json/main entry 推斷）、§C（從技術棧推斷）、§I（列舉公開 API/CLI/設定）、§V（從測試與斷言推導）、§T（每個已知 TODO 或缺少的測試一個任務）、§B（空）。
全程使用 caveman。不確定的項目在文字中以 ? 標記，供使用者確認。
反向傳播 — bug → §B + §V
輸入：bug: <description>。
步驟：
- 解析 bug 描述。
- 找出根本原因（閱讀相關程式碼）。
- 決定：新不變量是否能防止重複發生？若是 → 草擬
V<next>。 - 附加 §B 行：
B<next>|<date>|<cause>|V<N>。 - 將新不變量附加到 §V。
- 若修正也改變行為 → 新增/更新 §T 行。
- 顯示差異。僅在使用者確認後套用。
規則：每個 bug 都必須有 §B 條目。不變量可選但建議。
修訂 — 針對性編輯
輸入：amend §V.3 或 amend §T 等。
閱讀該章節。顯示目前內容。詢問使用者要什麼變更。寫入。顯示差異。
絕不靜默重寫使用者未指名的章節。
輸出規則
- 依
FORMAT.md的 caveman 格式。 - 保留識別碼、路徑、程式碼原樣。
- 編號單調遞增 — 絕不重用 §V.N 或 §B.N。
- §T 行的
cites欄位！列出 §V/§I 依賴：T5|.|impl auth mw|V2,I.api。
非目標
- 無子代理。主執行緒負責寫入。
- 無儀表板、無日誌、除 SPEC.md 本身外無狀態檔案。
- 規格後不自動建置。使用者明確呼叫 build。
