/runway
目标：所有问题现在就问完，这样在第 40 回合时就不需要再问任何问题。之后，用户批准一个计划然后离开；仅在停靠点时才会通过电话联系他们。
基本规则（用户可能在他们的 CLAUDE.md 中有自己的规则；以用户的为准）：
- 本地且可逆的工作（编辑、构建、测试、本地命令、在分支或工作树上提交）直接运行，无需询问。
- 始终在这些情况下停下： 推送或部署、发送任何消息、提交任何申请、花费金钱、删除数据、发布任何公开内容。
- 对于繁重的工作（搜索、测试运行、日志分类），使用更便宜的 subagent 模型；仅在设计及困难调试时使用顶级模型。
0. 预备检查（静默，无问题）
- 找到仓库根目录及其状态：
git status、当前分支、现有的SPEC.md、测试和构建脚本（package.json、Makefile等）。查明事实是你的工作，不是用户的。 - 检查电话审批是否已启用。如果
~/.claude/settings.json有一个PermissionRequest钩子运行了phone-approve.js，或者此插件的钩子已启用，并且~/.claude/phone-approve.json存在，则电话审批已启用。否则，告知用户一次（设置方法：运行node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init，然后将 ntfy 应用订阅到该文件中列出的请求主题）并继续；之后停靠点将回退到桌面对话框。 - 检查停靠点命令是否被强制要求提示，因为自动模式可能在没有拨打电话的情况下批准它们。在用户、项目和本地设置中查找
permissions.ask（或deny）规则，这些规则应涵盖git push、此仓库的部署命令（vercel、aws s3 sync、cdk deploy、npm publish、gh release、gh pr merge）以及删除命令（rm -r、git clean、git branch -D）。如果缺少这些规则，请提出具体的规则，显示差异，并仅当用户同意时才添加它们（插件的examples/permissions-ask.json是一个起点）。切勿为发送、发布或部署工具添加allow规则，也切勿添加Bash(*)。
1. 面谈直至规范完成
如果安装了 grilling 或 grill-me 技能，请调用它并在此功能上运行；其规则完全适用。如果没有，则自己进行面谈，如下所示：以轮次提问；每一轮包含所有其先决条件已确定的问题，每个问题都带有编号，每个问题都带有你的推荐答案，这样“是”就表示接受它。等待答案，重新计算现在可以问什么，然后重复。自己查找环境事实（使用 subagent 进行繁重的搜索），永远不要问用户你自己能找到的东西。决策由用户做出。
如果用户之前在此对话中已经对该功能进行过面谈并确认了共同理解，则不要重复面谈：重复使用之前的答案，仅询问其未涵盖的清单项目。
持续进行，直到以下所有项目都没有未解决的问题：
- 目标：一到两句话，用户可见的结果。
- 范围：将会更改的内容（区域、文件、表面）。
- 范围外：不得触及的内容。
- 验收标准：一个清单，其中每个项目都可以通过命令输出证明为真。
- 验证命令：恰好一个命令，其退出码为 0 表示完成（例如
npm run lint && npm test && npm run build）。如果不存在，则规范包括将其编写为第一个任务。 - 停靠点：此功能将触及哪些操作（推送/部署/发送/提交/花费/删除/发布），以及用户在每一个操作上的预期（例如“推送分支，打开一个 PR，不要合并”）。
- 你本来会在任务中途做出的决策：库、命名、数据结构、文案、边缘情况行为。现在就问，并附上推荐。
- 回合上限（默认为 60）以及任何预算问题。
在用户确认共同理解之前，不要继续下一步。
2. 编写 SPEC.md 并在本地提交
在仓库根目录编写 SPEC.md：
# <功能名称>
## 目标
## 范围
## 范围外
## 验收标准
- [ ] ...
## 验证命令
`<一条命令>`
## 停靠点
| 操作 | 预期处理 |
## 已做出的决策
## 回合上限
60
创建一个分支（git switch -c runway/<slug>），或者当其他会话正在编辑同一文件夹时使用工作树，然后只提交 SPEC.md。这是本地且可逆的操作；无需询问。切勿推送。
3. 一次计划审批
进入计划模式并呈现一个单一计划：有序的步骤，哪些步骤交给 subagent（以及在哪个模型上）、验证命令以及带有预期处理的停靠点。这是运行前唯一的审批。使用 ExitPlanMode 并让用户选择 “是，并使用自动模式”。（电话钩子故意跳过计划审批，因此用户需要在电脑前执行此操作。）
如果审批后自动模式未激活，请告知用户并要求其切换。不要在手动模式下运行循环。
4. 在 /goal 下运行，带有回合上限
内置的斜杠命令无法由模型调用，因此结束上一步时给用户提供一行可粘贴的命令（填写实际命令和上限）：
/goal <验证命令> exits 0, every acceptance criterion in SPEC.md is checked off with evidence in the transcript, and nothing in SPEC.md's out-of-scope list was touched, or stop after 60 turns
如果会话已经在运行一个目标，/goal 会替换它。评估者只能看到记录，所以在工作时：经常运行验证命令，打印其结果，并用证据勾选 SPEC.md 中的标准。每回合报告相对于回合上限的进度。
运行时：
- 不要提问。如果出现了未详细说明的情况，选择最接近规范的选项，将其记录在“已做出的决策”下，然后继续。仅当继续进行会触及停靠点或与规范冲突时，才停下来提问。
- 在 runway 分支上以小提交的方式提交工作。未经停靠点批准切勿推送。
- 在停靠点，正常进行调用；权限提示正是用来拨打电话的方式。如果被拒绝，不要尝试其他方法：记录下来，完成不需要它的部分，然后报告。
- 如果连续 3 个回合没有进展，停下来并报告是什么阻碍了你。
5. 完成
当验证通过（或达到上限）时，按以下顺序报告：
- 结果：完成 / 部分完成 / 受阻，以及分支和任何 PR 链接。
- 差异统计（
git diff --stat <基础>...HEAD）。 - 已验证：已证实的标准，包括命令和结果。
- 未验证：未证实或仅部分证实的标准；在停靠点被跳过或拒绝的任何内容。
- 使用的 Subagent，在哪个模型上，以及在哪些地方较小的模型表现更差。
- 使用的回合数和大致成本，相对于上限。