用全新上下文的子代理对文档做事实核查（重跑命令…

当用户要求对已完成的文档页面、章节或改动过的断言做验证/事实核查/准确性检查时，用独立子代理逐条核对命令、示例与结构。

适用场景

解决思路

1. 确认核查目标：一个页面、一个 `##` 章节，或一组改动过的断言；若调用时未给出目标则先询问。
2. 阅读目标所在文档树根目录的 README，其中的不变量（invariants）和页面地图也属于被核查内容。
3. 每个单元（一个 `##` 章节，或给定的断言列表）分配一个子代理；整页拆成多个子代理并行运行。
4. 使用通用型（general-purpose）子代理；子代理不会继承技能，因此提示词中要通过路径把一切材料交给它。填满所有占位符、把所有路径写成绝对路径，并发送如下提示词：
5. 提示词内容：『你正在 OpenSpec 用户文档的某个单元送达文档负责人之前对其进行评审。请扮演它将遇到的两个最苛刻的读者：一个冷启动阅读的怀疑派开发者，和一个开着仓库的事实核查员。仓库根目录：<ABSOLUTE REPO ROOT>。所有工具都使用绝对路径。先阅读：1. <DOCS TREE ROOT>/README.md：页面地图与固定不变量。2. <ABSOLUTE REPO ROOT>/.agents/skills/write-openspec-docs/writing.md：内部写作规则。3. <PAGE PATH>：只评审 <the section "<HEADING>" | these changed claims: <LIST>>；页面其余部分仅作上下文阅读。』
6. 提示词要求按以下顺序检查：1. 事实。每一条命令、flag、路径、配置键、输出块、默认值和行为断言。重跑文中展示的终端命令：只读命令可在任意位置运行，任何会改变状态的命令放到临时目录中运行或干脆不运行。AI 聊天界面类命令（如 /opsx:propose）无法在 shell 中运行，需对照本仓库随附的技能源码核对其名称与行为。名称对照 src/ 和 CLI 自身的 --help 检查。输出块必须与命令实际打印的内容一致。
7. 2. 示例。任何示例 spec 或 change 必须通过 `openspec validate`；当示例存在于磁盘上时运行它。
8. 3. 结构。标记任何重复解释某个主题（其规范归属在另一页面）的内容，或违反文档树 README 所述规则的内容。
9. 4. 职责契合度。该单元是否服务于页面声明的职责（标题下的一句话陈述，若有）？新到的读者能否快速得到他们想要的东西？
10. 5. 可信度与注水。标记：炒作或安慰性形容词（easy、simple、powerful、seamless）、没有展示证据的断言、该用具体事实却用含糊概括、二元对比（"not X, it's Y"）、冒号式揭晓、重要性吹捧、总结式结尾、em dash、本该用散文却用项目符号列表、连续三句排比式短句。
11. 提示词要求：只报告发现，最严重的排在最前。每条发现：引用原句、说明错在哪里、用一行给出修复建议。对每一条已核实的事实，说明核实方式（运行的命令，或检查的文件与行号）。列出任何无法核实的断言及原因。不要重写该单元。若该单元干净，就说明干净并列出你确切核实了什么。
12. 处理报告：默认只报告、不重写——向用户展示按严重程度排序的发现，每条附引用原句和一行修复建议，外加已核实内容及核实方式，以及评审者无法核实的断言。
13. 仅当用户要求「验证并修复」或批准这些发现时才应用修复。评审者也可能出错：拒绝的发现要连同你的理由写进报告，以便用户推翻你的判断。
14. 若应用的修复改动了事实性断言，则再次验证，范围限定在改动过的断言上；拼写和措辞修复不需要二次核查。
15. 两轮之后仍未收敛就停下来，把问题交给用户。不要陷入反复打磨的循环。

适用边界 · 注意事项

• 起草过程中不要调用本技能；起草由 `write-openspec-docs` 负责，除非用户明确要求做一次验证。
• 用户没有要求验证/事实核查时不要运行（本技能为手动触发）。
• 不要用它来重写或润色文档——默认只报告发现，不重写。