auYeCoding · Nov 13, 2026 · Nov 13, 2026
@@ -6,6 +6,11 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+### Fixed
+
+- `project-navigator`: replies were hard to read. They now follow one of three layouts (waiting, report, asking the user to decide or act); the question and its options come right after the first paragraph, with the options in a code block; the progress line moves to the end and appears only when it changed; intake raises open questions one at a time instead of listing them all; the review report leads with the conclusion and the steps the user must perform. When the session offers a question box at the end of a turn, the skill uses it for every decision, in Simplified Chinese.
+- `project-navigator`: the reviewer subagent runs on Sonnet again. 2.0.0 removed the `model` command and was meant to keep this default, but the rewritten subagent definition left it out, so the reviewer followed the orchestrator's model.
+
 ## [2.0.0] - 2026-11-12
 
 ### Changed

@@ -2,6 +2,7 @@
 name: navigator-reviewer
 description: project-navigator 的验收子代理, 只由编排会话按 brief review 生成的提示词派出, 逐条核对切片的完成标准, 接线与结构, 并交回证据. Acceptance reviewer for project-navigator; dispatched only by the orchestrator session with the generated review brief. Do not use for anything else.
 disallowedTools: Write, Edit, MultiEdit, NotebookEdit
+model: sonnet
 ---
 
 你是 project-navigator 的验收子代理, 在全新的上下文中核对一个切片是否完成.

@@ -65,7 +65,7 @@ Almost all of the 1.x iterations went into process control (the work order state
 - **The orchestrator session does not register; it is recognized by the orchestrator marker in the transcript.** The output of `enter` carries "编排标记: project-navigator 编排标记 <编号>" (orchestrator marker: project-navigator orchestrator marker <id>), where the id is the first 12 characters of the SHA-256 of the project path (lowercased first on Windows); the output is injected into the skill content, the skill content is recorded in the session transcript, and the hook reads `transcript_path` to find this marker. The source code contains only the prefix, so a session that reads the source code is not mistaken for one; `status` does not output the marker. A forked session copies the transcript and so naturally carries the marker. If changed: identity may be misjudged every time the session id changes.
 - **The executor subagent cannot ask questions, so there is only one kind of handback.** It ends the current run, and the first line of its last message says "交回: 需要回答" (handback: needs an answer) or "交回: 需要操作" (handback: needs an action); the orchestrator session tells the user, then uses SendMessage to let the same subagent continue (measured: SendMessage can resume an ended subagent with its context). The slice status stays "实现中" (implementing) throughout. 1.x had three channels (blocked, waiting for action, pending criteria), each with its own reply type and state transitions. If changed: every extra channel adds a set of states and decisions.
 - **Delegation prompts are generated by scripts, and the orchestrator session uses them unchanged.** `brief exec` and `brief review` are the only source of the prompts, and the section names in them come from the spec. If changed: the prompts scatter across rule files and gradually stop matching the structure of the slice file.
-- **Subagents do not declare `tools` (executor) or only disable write tools (reviewer), and the model follows the session.** MCP tools installed by the user may be needed. The model configuration command from 1.4.0 was removed: it was one more piece of state, and the user can use Claude Code's own subagent model setting directly. If changed: listing `tools` misses the user's tools.
+- **Subagents do not declare `tools` (executor) or only disable write tools (reviewer), the reviewer always runs on Sonnet, and the executor follows the session.** MCP tools installed by the user may be needed, so `tools` is not listed. Review is item-by-item comparison and evidence gathering and does not need the strongest model; the model is fixed in the `model` field of `agents/navigator-reviewer.md`. The model configuration command from 1.4.0 was removed: it was one more piece of state and one more place to go wrong; to change the model, edit that one line. The 2.0.0 rewrite of the subagent definitions left this line out, so the reviewer followed the session's model; 2.0.1 restores it. If changed: listing `tools` misses the user's tools; removing `model` makes review cost the same as the main model.
 
 ### Slices and review
 
@@ -99,7 +99,10 @@ Almost all of the 1.x iterations went into process control (the work order state
 
 ### Replies
 
-- **Replies have no template and no validation.** The only rules are: conclusion on the first line, progress on the second, options listed at the end when a decision is needed, no pasted code. The reply types, skeleton commands, and Stop hook of 1.x were all removed: they existed to recognize the user's choice from a reply (the approval in work order review), and the workflow no longer depends on the structure of replies. The cost is that "conclusion first" relies on rules alone. If changed: back to rejections and rewrites.
+- **Replies have three layouts and no validation.** The layouts are written only in the "回复" (replies) section of `SKILL.md`: waiting, report, and asking the user to decide or act. The reply types, skeleton commands, and Stop hook of 1.x were all removed: they existed to recognize the user's choice from a reply (the approval in work order review), and the workflow no longer depends on the structure of replies. The cost is that the layouts rely on rules alone. If changed: back to rejections and rewrites.
+- **When the user must decide, the question and options come right after the first paragraph, and the options go in a code block.** The 2.0.0 rules were only "conclusion on the first line, progress on the second, options at the end". Real sessions then showed: the question buried under long background; adjacent "A. B. C." lines merged into one paragraph by Markdown; the progress line glued to the first line; every open doubt listed to the user at once during intake. Line breaks inside a code block are never merged, so options always use a code block. If changed: the user has to read the whole reply to learn what to answer.
+- **A question box tool must be used when present, but nothing depends on it.** The desktop app offers a question box at the end of a turn (`wrap_up`); the terminal does not. The rule is "when such a tool exists, use it every time, in Simplified Chinese, with buttons matching the options in the code block", and the code block always stays, so replies are complete in both environments. If changed: with the code block alone the desktop app has no buttons to click; with the question box alone the terminal shows no options.
+- **Progress goes at the end of the reply, and only when it changed.** On the second line it took the most visible spot in every reply, while its content rarely changed.
 
 ### Installation
 

@@ -65,7 +65,7 @@
 - **编排会话不做登记, 按转录中的编排标记认出.** `enter` 的输出带 "编排标记: project-navigator 编排标记 <编号>", 编号是项目路径 SHA-256 的前 12 位 (Windows 上先转小写); 输出注入技能内容, 技能内容记在会话转录中, hook 读 `transcript_path` 找这个标记. 源代码里只有前缀, 读源代码的会话不会被误认; `status` 不输出标记. 分叉出的会话复制了转录, 自然带着标记. 改掉的后果: 每次换会话编号都可能误判身份.
 - **实现子代理不能提问, 所以只有一种中途交回.** 它结束本次运行, 最后一条消息第一行写 "交回: 需要回答" 或 "交回: 需要操作"; 编排会话转告用户, 再用 SendMessage 让原子代理继续 (实测 SendMessage 能带着上下文续接已结束的子代理). 切片状态一直是实现中. 1.x 有受阻, 等待操作, 待定判据三条通道, 各有自己的回复类型与状态转换. 改掉的后果: 每多一条通道, 多一组状态与判断.
 - **委派提示词由脚本生成, 编排会话原样使用.** `brief exec` 与 `brief review` 是提示词的唯一来源, 其中的小节名取自规格. 改掉的后果: 提示词散落在规则文件里, 与切片文件的结构逐渐对不上.
-- **子代理不写 `tools` (实现) 或只禁用写入工具 (验收), 模型跟随会话.** 用户装的 MCP 工具可能用到. 1.4.0 的模型配置命令去掉了: 多一条状态, 而用户可以直接用 Claude Code 自己的子代理模型设置. 改掉的后果: 列出 `tools` 时漏掉用户的工具.
+- **子代理不写 `tools` (实现) 或只禁用写入工具 (验收), 验收固定用 Sonnet, 实现跟随会话.** 用户装的 MCP 工具可能用到, 所以不列 `tools`. 验收是逐条对照与取证, 不需要最强的模型, 模型写死在 `agents/navigator-reviewer.md` 的 `model` 中. 1.4.0 的模型配置命令去掉了: 多一条状态, 多一处出错; 要换模型时改这一行. 2.0.0 重写子代理定义时漏掉了这一行, 验收跟随了会话的模型, 2.0.1 补上. 改掉的后果: 列出 `tools` 时漏掉用户的工具; 去掉 `model` 时验收的开销与主模型相同.
 
 ### 切片与验收
 
@@ -99,7 +99,10 @@
 
 ### 回复
 
-- **回复没有模板, 也没有校验.** 规则只有: 第一行结论, 第二行进展, 需要决定时末尾列选项, 不贴代码. 1.x 的回复类型, 骨架命令与 Stop hook 都去掉了: 它们是为了从回复里识别用户的选择 (工单审阅的认可), 现在流程不再依赖回复的结构. 代价是 "结论先行" 只靠规则. 改掉的后果: 回到打回与重写.
+- **回复有三种版式, 没有校验.** 版式只写在 `SKILL.md` 的 "回复" 一节: 等待, 报告, 要用户决定或操作. 1.x 的回复类型, 骨架命令与 Stop hook 都去掉了: 它们是为了从回复里识别用户的选择 (工单审阅的认可), 现在流程不再依赖回复的结构. 代价是版式只靠规则. 改掉的后果: 回到打回与重写.
+- **要用户决定时, 问题与选项紧跟在第一段之后, 选项放在代码块里.** 2.0.0 的规则只有 "第一行结论, 第二行进展, 末尾列选项", 实际会话中出现了: 问题埋在长篇背景之后; 相邻的 "A. B. C." 三行被 Markdown 合并成一段; 进展行与第一行粘在一起; 立项时把全部疑点一次列给用户. 代码块中的换行不会被合并, 所以选项固定用代码块. 改掉的后果: 用户读完整条回复才知道要回答什么.
+- **有提问框工具时必须用它, 但不依赖它.** 桌面应用在回合结束时提供提问框 (`wrap_up`), 终端里没有. 规则写成 "有这类工具时每次都用, 内容用简体中文, 按钮与代码块的选项对应", 代码块始终保留, 两种环境下回复都完整. 改掉的后果: 只写代码块时桌面应用里没有按钮可点; 只靠提问框时终端里看不到选项.
+- **进展写在回复末尾, 有变化时才写.** 放在第二行时, 它每条回复都占着最显眼的位置, 而内容多数时候没有变化.
 
 ### 安装
 

@@ -46,7 +46,7 @@ Any session that invokes the skill continues from the recorded state; there is n
 
 ## Quick start
 
-Take "build a tool that collects the team's weekly reports" as an example, starting from a new repository that has only a README. In every reply from the orchestrator session, the first line is the conclusion and the second line is the progress; when you need to decide something, the reply ends with options that start with a letter, and you answer with the letter.
+Take "build a tool that collects the team's weekly reports" as an example, starting from a new repository that has only a README. Every reply from the orchestrator session opens with a one-sentence conclusion; when you need to decide something, a code block listing the options follows immediately, and you answer with the letter, or click a button under the reply in the desktop app; progress is written at the end of the reply when it changed.
 
 ### First invocation
 
@@ -257,7 +257,7 @@ Run `/waypoint:project-navigator uninstall`. The allow rules are removed, the pl
 - Every machine that uses the project needs Node.js 22 or later.
 - The plugin's hook fires in every project, and every write-tool call and every message starts Node.js once; in a project that has not been initialized the script ends immediately.
 - The guard only checks the target paths of write tools, not the command line: when the orchestrator session changes code or installs dependencies from the command line, only the skill's rules constrain it.
-- The reply format (conclusion first, one line of progress) relies only on the skill's rules and is not validated.
+- The reply format (conclusion first, options in a code block) relies only on the skill's rules and is not validated.
 - A slice file is written part by part by the orchestrator session and the executor. The script uses the digest of the Plan part to discover that it was changed during implementation; it can detect this but cannot prevent it.
 - No script checks whether the orchestrator session really read the code before writing the plan; errors in the plan are caught by the executor subagent's "修正" (corrections) and by the review.
 - Apart from the filters check, the items of "结构核对" (structure check) are judged by the reviewer subagent and are not deterministic.

@@ -46,7 +46,7 @@
 
 ## 快速上手
 
-以 "做一个团队周报汇总工具" 为例, 从一个只有 README 的新仓库开始. 编排会话的每条回复第一行是结论, 第二行是进展; 需要你决定时, 末尾列出以字母开头的选项, 回复字母即可.
+以 "做一个团队周报汇总工具" 为例, 从一个只有 README 的新仓库开始. 编排会话的每条回复第一段是一句结论; 需要你决定时, 紧接着是一个列出选项的代码块, 回复字母即可, 桌面应用中也可以点回复下方的按钮; 进展有变化时写在回复末尾.
 
 ### 第一次调用
 
@@ -257,7 +257,7 @@ project-navigator init --archive
 - 使用本项目的每台机器都需要 Node.js 22 或更高版本.
 - 插件的 hook 在所有项目中触发, 每次写入类工具调用与每条消息都会启动一次 Node.js; 未初始化的项目中脚本立即结束.
 - 守卫只检查写入类工具的目标路径, 不检查命令行: 编排会话用命令行改代码或装依赖时, 只靠技能规则约束.
-- 回复的格式 (结论先行, 一行进展) 只靠技能规则, 没有校验.
+- 回复的版式 (结论先行, 选项放在代码块里) 只靠技能规则, 没有校验.
 - 一份切片文件由编排会话与实现方分段写. 脚本靠计划段的摘要发现它在实现期间被改动, 能发现, 不能阻止.
 - 写计划前编排会话是否真的读了代码, 没有脚本把关; 计划中的错误由实现子代理的 "修正" 与验收兜底.
 - "结构核对" 中除筛选器检查之外的各项由验收子代理判断, 不是确定性的.

@@ -36,9 +36,34 @@ allowed-tools: Bash(node *) PowerShell(node *) Bash(project-navigator *) PowerSh
 
 ## 回复
 
-- 第一行写结论: 先说结果, 再说要用户做的事.
-- 第二行写进展, 照抄 `status` 的 "当前进展".
-- 需要用户决定时, 在末尾列出选项, 每项一行, 以字母开头; 一次只问一件事. 不需要决定时不加选项.
+用户读回复是为了知道两件事: 现在怎样了, 要不要他做什么. 回复只有三种, 先判断是哪一种, 再按它的版式写; 段与段之间空一行.
+
+| 种类             | 何时用                           | 版式                                                                                                   |
+| ---------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------ |
+| 等待             | 子代理在后台, 用户不用做事       | 一两句话: 在等什么, 结果回来后做什么. 不复述计划, 也不复述子代理的报告                                 |
+| 报告             | 做完了一件事, 不需要用户决定     | 第一段一句结论; 然后是不超过 5 条的要点. 细节留在文件里, 给出文件路径                                  |
+| 要用户决定或操作 | 需要用户选择, 回答或亲手做一件事 | 第一段一句话: 结果, 以及要用户做什么; 紧接着是选项代码块或编号的操作步骤; 之后才是理由与背景, 能少则少 |
+
+需要用户决定时, 选项写在代码块里, 格式固定:
+
+```
+[问题 2: 对战场景的范围]
+
+A. 只做 1v1 决斗 (推荐)
+B. 1v1 为主, 设计时预留多人
+C. 一开始就支持多人
+```
+
+- 一次只问一件事. 其它待定的事不提前列给用户, 轮到时再问.
+- 每个选项一行, 以字母开头; 有推荐时把它排在 A 并标 "(推荐)". 选择之后会发生什么, 用半句话写在同一行.
+- 用户看完第一段与代码块就应当能作答. 放在代码块之前的内容只有第一段.
+- 会话中有回合结束时的提问框工具时 (例如桌面应用的 `wrap_up`), 每次要用户决定或操作都调用它: 内容用简体中文, 按钮与代码块中的选项对应; 按钮数不够时放推荐项与最可能被选的另一项. 提问框已经显示问题句时, 正文不再重复问一遍, 代码块照常保留. 没有这类工具时只用代码块.
+
+其它规则:
+
+- 进展有变化时, 在回复末尾单独一段写 "当前进展: ...", 照抄 `status` 的 "当前进展". 没有变化时不写.
+- 标题, 表格与加粗只在内容确实有这种结构时用; 一条回复只有一个需要用户回应的地方.
+- 工具调用之间的过渡句也用简体中文, 不超过一句.
 - 不贴代码. 用简体中文与英文 (ASCII) 标点, 每个标点后加一个空格. 写朴素的话, 不自造简称.
 
 ## 路由表
@@ -78,7 +103,7 @@ allowed-tools: Bash(node *) PowerShell(node *) Bash(project-navigator *) PowerSh
 - 实现: `waypoint:navigator-executor`, 提示词是 `brief exec` 的输出原文, 用 Agent 工具在后台派出 (`run_in_background`). 它结束后会自动通知编排会话.
 - 验收: `waypoint:navigator-reviewer`, 提示词是 `brief review` 的输出原文.
 - 委派提示词原样使用, 不增删内容. 需要读大量文件时可以用内置的 Explore 子代理.
-- 等待子代理期间, 回复只写在等什么, 结果回来后做什么.
+- 等待子代理期间, 按 "回复" 中的 "等待" 版式回复.
 
 ## 调用参数
 

@@ -5,8 +5,8 @@
 ## 确认需求
 
 1. 读用户给的初始需求. 已有项目先读一遍项目: 入口在哪里, 有哪些模块, 沿用什么约定. 文件多时用 Explore 子代理.
-2. 向用户复述你的理解, 指出含糊, 缺失, 互相冲突的地方.
-3. 把待定问题列出来, 与用户逐个确认, 一次只问一个, 不自行假设. 用户说 "你定" 时给出建议与理由, 由用户确认.
+2. 向用户复述你的理解, 不超过 5 条, 只写会影响路线的要点.
+3. 含糊, 缺失, 互相冲突的地方都是待定问题: 自己列成清单, 不一次全部展示给用户. 每条回复只提一个, 先说还剩几个, 再按技能 "回复" 一节的选项代码块提问, 不自行假设. 用户说 "你定" 时给出建议与理由, 由用户确认.
 4. 讨论中冒出的, 不属于本项目范围的想法, 记进 `.navigator/backlog.md`.
 
 ## 需求文件