xallindrome-labs/claude-code-ops

/runway

目標：每個問題都在現在被提出，這樣在第 40 回合時就不需要再問任何問題。之後，使用者批准一個計畫然後離開；只有在停止點時才會透過電話聯繫他們。

基本規則（使用者可能在他們的 CLAUDE.md 中有自己的規則；以使用者的規則為準）：

• 本地且可逆的工作（編輯、建置、測試、本地指令、在分支或 worktree 上提交）可以在不詢問的情況下執行。
• 以下情況務必停止： 推送或部署、發送任何訊息、提交任何申請、花費金錢、刪除資料、發布任何公開內容。
• 對大量工作（搜尋、測試執行、日誌分類）使用較便宜的副代理模型；頂級模型只用於設計和困難的除錯。

0. 前置檢查（靜默執行，不詢問問題）

• 找到儲存庫根目錄及其狀態：git status、目前分支、既有的 SPEC.md、測試和建置腳本（package.json、Makefile 等）。找出事實是你的工作，不是使用者的。
• 檢查電話審批是否啟用。如果 ~/.claude/settings.json 中有一個執行 phone-approve.js 的 PermissionRequest hook，或者這個外掛的 hook 已啟用，並且 ~/.claude/phone-approve.json 存在，則表示已啟用。如果沒有，請告知使用者一次（設定方式：執行 node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init，然後讓 ntfy 應用程式訂閱該檔案中的請求主題）並繼續；停止點則會回退到桌面對話框。
• 檢查停止點指令是否被強制要求提示，因為自動模式可能會在沒有打電話的情況下批准它們。在使用者、專案和本地設定中尋找涵蓋 git push、此儲存庫的部署指令（vercel、aws s3 sync、cdk deploy、npm publish、gh release、gh pr merge）和刪除指令（rm -r、git clean、git branch -D）的 permissions.ask（或 deny）規則。如果缺少規則，請提出具體的規則，顯示 diff，並且只有在使用者同意時才加入（外掛的 examples/permissions-ask.json 是一個起點）。永遠不要為發送、發布或部署工具添加 allow 規則，也不要為 Bash(✱) 添加規則。

1. 訪談直到規格完成

如果已安裝 grilling 或 grill-me 技能，則呼叫它並在此功能上執行；其規則完全適用。如果沒有，則像這樣自己進行訪談：以輪次提問；每一輪包含所有先決條件已經確定的問題，每個問題都有編號，每個問題都附上你的建議答案，以便使用者說「是」就代表接受。等待回答，重新計算現在可以問哪些問題，然後重複。自己查詢環境事實（對大量搜尋使用副代理），永遠不要問使用者你自己可以找到的東西。決策是使用者的。

如果使用者在此對話中稍早已經對這個功能進行過 grilling 環節並確認了共同理解，則不要重複：重用這些答案，僅針對以下清單中它遺留的檢查項目進行提問。

持續進行，直到以下所有項目都沒有遺留問題：

1. 目標：一兩句話，使用者可見的成果。
2. 範圍：會更改的內容（區域、檔案、表面）。
3. 不包含在範圍內：不得觸及的內容。
4. 驗收標準：一個檢查清單，其中每個項目都可以透過指令輸出來證明為真。
5. 驗證指令：一個指令，其 exit 0 表示完成（例如 npm run lint && npm test && npm run build）。如果不存在，則規格中應包含將其編寫為第一個任務。
6. 停止點：此功能會觸及的推送/部署/發送/提交/花費/刪除/發布項目，以及使用者在每個項目上的期望（例如「推送分支，開啟 PR，不要合併」）。
7. 你原本會在中途做出的決策：函式庫、命名、資料形狀、文案、邊緣情況行為。現在就問，附上建議。
8. 回合上限（預設為 60）和任何預算考量。

在使用者確認共同理解之前，不要繼續進行。

2. 撰寫 SPEC.md 並在本地提交

在儲存庫根目錄撰寫 SPEC.md：

# <功能名稱>
## 目標
## 範圍
## 不包含在範圍內
## 驗收標準
- [ ] ...
## 驗證指令
`<一個指令>`
## 停止點
| 動作 | 預期處理方式 |
## 已做出的決策
## 回合上限
60

建立一個分支（git switch -c runway/<slug>），或者當其他會話正在編輯同一個資料夾時使用 worktree，然後只提交 SPEC.md。這是本地且可逆的；不要詢問。絕對不要推送。

3. 一次計畫批准

進入計畫模式並提出單一計畫：有序的步驟、哪些步驟交給副代理（以及使用哪個模型）、驗證指令，以及帶有預期處理方式的停止點。這是在執行之前唯一的批准。使用 ExitPlanMode 並要求使用者選擇**「是，並使用自動模式」**。（電話 hook 故意跳過計畫批准，所以使用者會在電腦前執行此操作。）

如果批准後自動模式未啟用，請告知使用者並要求他們切換。不要在手動模式下執行迴圈。

4. 在 /goal 下以回合上限執行

內建斜線指令無法由模型呼叫，因此結束上一個步驟時，提供使用者一行可貼上的指令（填入實際指令和上限）：

/goal <驗證指令> 退出碼為 0，SPEC.md 中的每個驗收標準都已勾選並在對話記錄中附上證據，且未觸及 SPEC.md 中不包含在範圍內的任何內容，或在 60 回合後停止

如果會話已在執行 goal，/goal 會取代它。評估器只會看到對話記錄，因此在工作時：經常執行驗證指令，列印其結果，並在 SPEC.md 的標準上打勾並附上證據。每回合報告相對於回合上限的進度。

執行期間：

• 不要問問題。如果出現了未指定的情況，選擇最接近規格的選項，將其記錄在「已做出的決策」下，然後繼續。只有在繼續進行會觸及停止點或與規格矛盾時，才停下來提問。
• 在 runway 分支上以小規模提交進行工作。未經停止點批准，絕對不要推送。
• 在停止點時，正常進行呼叫；權限提示就是用來打電話的。如果請求被拒絕，不要嘗試其他方式：記錄下來，完成不需要該操作的部分，然後回報。
• 如果連續 3 個回合沒有進展，請停止並回報是什麼阻礙了你。

5. 完成

當驗證通過（或達到上限）時，按以下順序回報：

1. 結果：完成/部分完成/受阻，以及分支和任何 PR 連結。
2. Diff 統計（git diff --stat <基底>...HEAD）。
3. 已驗證：已證明的標準，附上指令和結果。
4. 未驗證：未證明或僅部分證明的標準；任何在停止點被跳過或拒絕的項目。
5. 使用的副代理、使用的模型，以及較小模型表現較差的地方。
6. 使用的回合數和相對於上限的粗略成本。