Reviewing 是一个用于文档结构化评审的技能，隶属于 desplega-ai/ai-toolbox。它对 research、plan、brainstorm 文档进行评论，找出缺口、弱点和质量问题。资料明确说明：它评审文档；如果要评审代码差异，应使用 desplega:code-reviewing。
何时使用： 用户调用 /review 命令时；其他技能在完成时引用 reviewing 技能时；用户要求评审、批评或检查某文档时。
自主模式： 开始时依据传入的自主模式调整交互级别。Autopilot 模式会执行完整评审、自动修复小问题并在最后给出摘要；Critical 模式（默认）就 Critical/Important 发现与用户讨论，自动修复 Minor 问题；Verbose 模式逐条走查每个发现，任何改动前都先确认。若未指定，默认 Critical。
输出模式： 除非处于 Autopilot，开始时只问一次如何呈现评审结果，选项为：1. 在文档中追加 errata 段落（推荐）；2. 自动把修复应用到文档；3. 将独立评审文件写入 thoughts/*/reviews/。
工作约定： 所有面向用户的问题通过 AskUserQuestion 提出（Autopilot 时除外），不要在聊天中以普通列表形式提问。File-review 默认开启——在自动评审后调用（仅在 Autopilot 时跳过）。
处理步骤： 第 1 步：读取并分类。完整读取输入文档，根据路径和内容结构判断文档类型：路径含 /research/ 为研究文档，/plans/ 为计划，/brainstorms/ 为头脑风暴，/qa/ 为 QA 报告。类型不明确时从内容结构推断或用 AskUserQuestion 澄清。 第 2 步：结构检查。按文档类型核对所需章节：研究文档需 YAML frontmatter（date、researcher、topic、status 等字段）、Research Question、Summary、带 file:line 引用的 Detailed Findings、Code References 表格、Open Questions；计划需 YAML frontmatter（date、planner、topic、status）、Overview（含 Motivation 与 Related 链接）、Current State Analysis、Desired End State、What We're NOT Doing、Implementation Approach（单行要点）、Quick Verification Reference、各 Phase 的 Changes Required 与 Success Criteria（含 Automated Verification、Automated QA、Manual Verification 三个子节）、QA Spec（存在时须链接到 desplega:qa 生成的文档而非内联场景）、Appendix；头脑风暴需 YAML frontmatter（date、author、topic、status）、Context、含 Q&A 对的 Exploration、Synthesis、Next Steps；QA 报告需 YAML frontmatter（date、author、topic、status）、Context、Scope（In Scope / Out of Scope）、每个用例含 Steps/Expected/Actual/Status 的 Test Cases、Evidence（截图、视频、日志或外部链接）、含总体状态与摘要的 Verdict。 第 3 步：内容分析。按类型应用质量标准。研究文档：findings 是否有具体 file:line 引用支持、是否存在无代码库证据的断言、是否有明显未调查区域、open questions 是否确实开放。计划：实施顺序是否有缺失阶段或断档、成功标准是否足够具体可执行、是否有未言明的代码库假设、是否处理错误处理或回滚、是否有范围蔓延风险、是否有阶段过度构建（对拟议的抽象、层次和新依赖运行 desplega:engineering-standards 的删除测试、双适配器规则、新依赖测试，未通过标记为 Important）。头脑风暴：是否遗漏重要角度、是否在充分探索前就过早下结论、约束与需求是否明确、文档是否可进入研究或规划阶段。QA 报告：每个用例是否都有实际结果与状态、失败是否提供证据、verdict 是否与各用例结果一致、边界与探索性测试是否记录、相关外部引用（Sentry、PR、CI）是否链接。 第 4 步：缺口识别。查找缺失或假设内容：必要时对照代码库交叉核验断言（可启动 codebase-analyzer 代理验证）、识别未言明假设、检查内部矛盾、核实外部引用是否仍有效。 第 5 步：呈现发现。将全部发现分为三级：Critical 表示阻碍正确性或完整性、必须处理，与用户讨论；Important 表示重大缺口或弱点、应当处理，与用户讨论（Autopilot 下可自动修复）；Minor 表示格式、错字、小的不一致，除 Verbose 模式外自动修复。以文本输出给出摘要，按严重级别分组。 第 6 步：应用或讨论。按输出模式：若选“追加 errata”，自动修复 Minor 问题，并对 Critical/Important 在文档末尾追加 ## Review Errata 段落，包含 Critical、Important、Resolved 分区；若选“自动应用”，自动修复 Minor 与 Important，对 Critical 用 AskUserQuestion 询问是否也自动修复，经授权则应用，否则留作未勾选的 errata 项，并追加包含 Applied 与 Remaining 的 Review Errata；若选“独立文件”，将评审写入 thoughts/*/reviews/YYYY-MM-DD-review-of-<original-slug>.md，包含所有发现并回引原文档。 第 7 步：工作流交接。评审完成后判断文档类型，提出下一步：头脑风暴可选开始研究（→ /research）、直接创建计划（→ /create-plan）或到此为止；研究文档可选创建计划或到此为止；计划可选开始实施（→ /implement-plan）或到此为止；实施后验证可选标记完成或处理剩余项；QA 报告可选运行 post-QA 验证（→ /verify-plan）、处理发现的问题或到此为止；类型不明时给出通用询问。
学习捕获：可选子技能。若流程中出现重要见解、模式、坑点或决策，可考虑使用 desplega:learning 通过 /learning capture 捕获，聚焦对后续会话有帮助的学习内容。
禁止重写规则：评审者识别问题，不重写文档，呈现发现交由原作者处理。例外：Minor 自动修复（错字、格式）始终应用；Auto-apply 模式下，评审者按用户授权直接应用 Important 和（可选）Critical 修复。
评审集成：File-review 默认开启（Autopilot 除外）。自动评审后调用 /file-review:file-review <path> 收集内联人工评论，并用 file-review:process-review 技能处理反馈。
限制：本技能针对文档而非代码差异；具体安装命令、收费与价格、平台支持等信息暂未提供。