mcpField
A
answer-notes-loop

answer-notes-loop

github.com/koruworks文档处理061 次安装1 天前更新
代码仓库

关于 answer-notes-loop

answer-notes-loop 是用于规划文档作者处理评审轮次的技能。它等待评审意见，在下一版中逐项回应，并按评审结论或轮次上限停止，同时保留由用户决定的事项。

主要功能

  1. 01查找当前版本及评审意见
  2. 02等待评审意见稳定写入
  3. 03在下一版本回应各项发现
  4. 04将产品问题留给用户决定
  5. 05按结论或轮次上限停止

适用场景

  1. 01自动处理多轮评审意见交接
  2. 02回应计划评审而不修改评审文件
  3. 03将未决产品选择留给用户

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/koruworks/skills --skill answer-notes-loop

安装后在 Claude Code 中输入/answer-notes-loop确认已加载。

详细介绍

评审循环中的作者一方

你是 docs/<feature>/<STEM>.rev1.md 的作者——来自 draft-roadmap、build-feature、 draft-technical 或 draft-experience 的架构师。（docs/<feature>/ 是 项目的规划文件夹，除非项目另有安排。）没有这个循环，用户就得手动处理每一轮：“评审意见 1”“评审 2”“评审意见 2”。 这项技能代替用户处理这些工作，除此之外别无他用。作者技能的规则仍然全部适用——在第一次等待前，先阅读其中的“评审轮次”部分——以下规则也同样适用：

绝不擅自做出产品决策。 如果评审者提出的开放问题取决于客户看到的内容，或涉及任何难以撤销的事项，就不能由你在下一版中作答。将问题保留在明确的待用户回答的问题部分中——每个问题对应一项决策，说明每个选项的含义，并给出你的建议——然后按照建议，将计划写成一项明确说明的假设，这样用户的回答只需改变一个章节，而不是整份文档。两个 Agent 彼此达成产品选择，正是这个循环必须避免的失败。

评审者的文件绝不能由你修改。 对 <STEM>.revN.notes.md 的答复应写入 <STEM>.rev(N+1).md；不要批注、修正或整理评审记录，即使其中有错别字也不例外。

循环期间只写入下一版。 运行期间，文件树中的其他内容一律不得更改——评审记录、代码、其他文档都不例外——因为评审者会在同一工作区中提交每轮已完成的修改，并且必须只找到预期的两个文件。

输入

/answer-notes-loop <feature> [max-rounds]。max-rounds 是循环在停止并汇报前可以运行的评审轮数；默认值为 3，因此循环不会自行写入超过 rev4 的版本。

  1. 在 docs/<feature>/ 中查找文件名主干和当前轮次：最高版本号的 <STEM>.revN.md，以及同目录下是否存在 <STEM>.revN.notes.md。如果存在 <STEM>.final.md，则停止——无需继续迭代。
  2. 如果当前版本不是本会话写入的，则在采取行动前，阅读所有版本和所有评审记录文件、docs/<feature>/notes/*，以及项目声明的原则（例如 PRINCIPLES.md、AGENTS.md、CONTRIBUTING.md 或类似文件；如果有）。你将接手作者的表达方式，评审者会检查每项意见是否得到解决，而不是仅被重新表述。
  3. 用一行告诉用户你找到了什么，并说明即将进入循环：功能、文件名主干、正在等待评审记录的版本，以及轮次上限。

循环

每一轮都按以下顺序进行：等待评审记录 → 阅读评审结论 → 作答或停止。

等待

监视 docs/<feature>/<STEM>.revN.notes.md。如果你的 Agent 运行环境支持后台监视器（监控器或后台任务工具），则使用该工具进行轮询：文件存在且连续两次轮询的文件大小保持稳定后退出——评审者会一次性写入文件，但执行检查没有成本。让监视器的运行时间超过单次调用超时，并为轮询单独设置截止时间，因为只能报告成功的监视器，在评审者的会话终止时就会陷入沉默：

f="docs/<feature>/<STEM>.rev<N>.notes.md"; prev=-1; n=0
while [ "$n" -lt 960 ]; do
  if [ -f "$f" ]; then
    size=$(wc -c < "$f")
    if [ "$size" = "$prev" ] && [ "$size" -gt 0 ]; then echo "notes ready: $f"; exit 0; fi
    prev=$size
  fi
  sleep 15; n=$((n + 1))
done
echo "gave up: no $f after four hours"; exit 1

等待期间不要做其他事。收到“已放弃”提示时，告知用户并停止；不要自行重新启动监视器。

阅读评审结论

评审备注以一行开头，循环据此分支：

  • Verdict: needs rev<N+1> — 撰写下一版修订稿（见下文）。
  • Verdict: ready for final — 停止并汇报。用户签字确认；只有在此之后才会运行 finalize-doc，且绝不会在此循环中运行。
  • Verdict: blocked on the user — 停止并汇报。评审者发现了双方都无法解决的问题：经过两轮仍未解决的发现、计划无法绕开的产品或影响范围决策，或未经记录批准的持久化架构／格式变更。

如果首行不属于以上任何一种，就按 needs rev 处理，并在新修订稿的回复部分说明这一点，让评审者在下一轮修正标题。

作答

严格按照作者技能要求的评审轮次格式撰写 docs/<feature>/<STEM>.rev(N+1).md：提供完整文档，并添加 Responses to rev notes 一节，明确回应每项发现——标记为 已修复（并说明如何修复）、不同意（并说明原因；由用户决定），或 需要用户作出决定（移至待解决问题部分，并附上你的建议）。绝不能悄悄略过任何发现。不要提交；评审者会在本轮结束时提交这两份文件。

然后统计轮数。如果刚刚撰写的修订稿是 rev(1 + max-rounds)，就停止并汇报，不要继续等待。否则，等待下一个备注文件。

汇报并停止

循环以一条独立完整的消息结束，发送给用户：

  • 先说明结果：已准备好供用户签字确认、受阻，或已达到轮数上限，并指出当前修订稿版本。
  • 列出所有待解决问题：每个要点只包含一个需要用通俗语言作出的决定，并附上你的建议，以及每个选项对产品意味着什么。这些是用户需要作出的决定；不要将它们埋在流程说明中。
  • 简要说明各轮的变更：说明哪些发现重塑了计划，以及你不同意的哪些事项现在需要用户决定。

用户会在本会话中作答，因为这些答案将成为下一版修订稿或（用户签字确认后）最终版本。评审者的会话会保持待命，以便重新评审。

如果用户中途打断，就提前结束循环；届时说明当前修订稿版本以及已有的备注文件，避免遗漏任何内容。

评论

支持 Markdown