用途
review-docs 用于评审“门面文档”（默认 README.md，也可遵循用户指定的路径），方式是模拟真实读者的阅读体验，而非作者视角。作者清楚每一行的含义，但首次阅读的读者并不清楚。该技能的目标是找出特定受众在何处感到困惑、未被充分服务或直接流失，对其评分，并提出具体修改建议。
主要能力
- 多角色并行评审：为每个读者画像（persona）生成一个子代理，全部并行运行，各自以该读者身份进行冷读。不同读者能发现不同问题，并行运行更快，且各次阅读互不污染。
- 统一评分标准：每个子代理使用相同评分规则，仅更换读者画像。评分采用 5 分制，并包含“30 秒测试”（仅看首屏后，用一句话判断该工具做什么，以及判断是否正确/错误/模糊）。
- 具体问题定位：每个子代理需给出前 3 个具体问题，引用原文行/短语，并给出具体改写建议，涵盖令人困惑的术语、承载过多想法的句子、缺乏卖点的内容、影响扫读的格式、损害信任的夸大宣传等。
- 术语检查：列出每个需要停下来思考的词（如 harness、spec、eval、subagent、rings、recall/precision 等），判断其是否在上下文中被定义，还是让读者自行猜测。
- 保留优点：记录哪些内容有效，以便修改时不丢失。
- 综合汇总：收集评分与报告后，优先处理影响多个读者画像的跨领域问题；以最低分为上限，指出阻碍该读者画像的因素；产出按读者影响排序的修复清单。
- 可选迭代：仅当用户明确要求“修到 N/5”或“直到 5/5”时，才进入应用修复并重新评审的循环。默认仅报告，不直接改写文档。
使用方式
- 先自行通读目标文档，并浏览其链接的文档，以便判断子代理的发现并后续应用修复。
- 在单条消息中并行派出多个子代理（多个 Agent/Task 调用同时进行），每个子代理对应一个读者画像。建议使用快速、低成本的模型（如 Sonnet 或 Haiku），因为这是阅读/判断任务，而非重度综合任务。
- 为每个子代理提供相同的评分规则，仅更换读者画像。规则要求子代理以该读者身份冷读指定路径（忽略顶部 HTML 注释块，那是内部作者笔记，非面向用户的文案），采用严格评分（多数 README 为 3 分；5/5 意味着读者会真正据此行动且全文清晰），并仅返回：评分、30 秒测试、前 3 个具体问题（引用原文并给出改写建议）、术语检查、有效内容、最能提升分数的一项改动。要求引用原文，追求有用而非客气。
- 默认读者画像集合包括：Claude Code 新手、Claude Code 高级用户、插件/技能作者、持怀疑态度的资深/主任工程师、决策者（不会运行命令）、Codex 用户（可选）。除非用户限定子集，否则运行全部。可根据具体文档自由调整集合。
- 综合汇总：先处理跨领域问题（影响多个读者画像的 2–4 个问题，杠杆最高）；以最低分为上限，指出阻碍该读者画像的因素；产出按读者影响排序的修复清单，每项为一行行动，引用原文并给出修复。
- 仅在用户明确要求时进入迭代循环：应用最高杠杆的修复，然后重新派出子代理（恢复相同子代理并附上变更清单，或生成新的）并收集新评分。重复直到每个读者画像达到目标或评分不再变化。需设边界：若一轮无改进，或约 3 轮后，停止并报告阻碍最后一点的原因，而非空转。默认该技能仅报告；只有明确要求“修复它 / 修到 N/5”时才进入应用并迭代循环。
适用场景
- 评审 README 或文档页面，尤其是面向新用户的门面文档。
- 需要从多个真实读者视角发现文档中的困惑点、术语障碍、格式问题或夸大宣传。
- 团队决定是否采用某工具前，需要评估其文档对决策者的可读性。
- 希望获得可操作的、引用原文的修改建议，而非泛泛而谈。
限制
- 默认仅报告，不直接改写文档；只有用户明确要求时才进入应用并迭代循环。
- 迭代循环有边界：若一轮无改进或约 3 轮后停止，并报告阻碍最后一点的原因。
- 评分采用严格标准，多数 README 为 3 分，5/5 意味着读者会真正据此行动且全文清晰。
- 子代理建议使用快速、低成本模型（如 Sonnet 或 Haiku），因为这是阅读/判断任务。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。