reviewing

审查

你正在对文档（研究、计划或头脑风暴）进行结构化评析，以找出其中的缺漏、弱点和质量问题。（如需审查代码差异，请改用 desplega:code-reviewing——此技能用于审查文档。）

协作约定

所有面向用户的问题都必须通过 AskUserQuestion 提出（Autopilot 模式除外）——约定请参阅 desplega:ask-user。切勿在聊天中以普通项目符号提问。

默认启用文件审查——自动审查完成后调用此功能（Autopilot 模式下除外）。

输出模式

除非处于 Autopilot 模式，否则请在开始时询问一次：

问题	选项
“你希望如何呈现审查结果？”	1. 在文档末尾附加勘误部分（推荐），2. 自动修复文档中的问题，3. 在 thoughts/*/reviews/ 中新建单独的审查文件

使用时机

出现以下情况时，此技能会激活：

• 用户调用 /review 命令
• 其他技能在完成时引用审查技能
• 用户要求审查、评析或检查文档

自主模式

开始审查时，根据自主模式调整交互方式：

模式	行为
Autopilot	执行完整审查，自动修复轻微问题，并在最后提供摘要
Critical（默认）	就严重/重要的问题征求意见，自动修复轻微问题
Verbose	逐项说明每个问题，任何修改前都先确认

自主模式由调用命令传入。若未指定，默认使用 Critical。

流程步骤

第 1 步：阅读并分类

完整阅读输入文档。根据文档路径和内容结构确定文档类型：

路径包含	类型
/research/	研究文档
/plans/	计划
/brainstorms/	头脑风暴
/qa/	QA 报告

如果类型不明确，请根据内容结构推断，或使用 AskUserQuestion 进行确认。

第 2 步：结构检查

根据文档类型检查是否包含必需章节：

研究文档：

• 包含必需字段（date、researcher、topic、status）的 YAML frontmatter
• Research Question 章节
• Summary 章节
• 包含文件及行号引用的 Detailed Findings
• Code References 表格
• Open Questions 章节

计划：

• 包含必需字段（date、planner、topic、status）的 YAML frontmatter
• 包含 Motivation + Related links 的 Overview
• Current State Analysis
• Desired End State
• What We're NOT Doing
• Implementation Approach（项目符号形式的单行条目）
• Quick Verification Reference
• Phases，包含 Changes Required 和 Success Criteria（必须包含以下三个子章节：Automated Verification、Automated QA、Manual Verification）
• QA Spec（如有）应为指向由 desplega:qa 生成文档的链接，而非内嵌的场景
• Appendix（后续计划、偏离说明、参考资料）

头脑风暴：

• 包含必需字段（date、author、topic、status）的 YAML frontmatter
• Context 章节
• 包含问答对的 Exploration 章节
• Synthesis 章节
• Next Steps 章节

QA 报告：

• 包含必需字段（date、author、topic、status）的 YAML frontmatter
• Context 章节
• Scope 章节（In Scope / Out of Scope）
• Test Cases；每个用例包含 Steps、Expected、Actual、Status
• Evidence 章节（Screenshots、Videos、Logs 或 External Links）
• Verdict 章节，包含整体状态和摘要

步骤 3：内容分析

应用特定类型的质量标准：

研究文档：

• 结论是否有具体的文件:行号引用作为依据？
• 是否存在缺乏代码库证据支撑的主张？
• 是否有明显未调查的领域？
• 未解问题是否确实尚无定论（无法根据调查结果回答）？

计划：

• 是否缺少阶段，或实施顺序中存在漏洞？
• 成功标准是否足够具体，便于采取行动？
• 是否存在未说明的代码库假设？
• 是否说明了错误处理或回滚？
• 是否存在范围蔓延风险（做超出所述范围的工作）？
• 是否有阶段设计过度？依据 desplega:engineering-standards（删除测试、双适配器规则、新依赖测试）评估拟议的抽象、层级和新依赖——将不符合项标记为 Important。

头脑风暴：

• 是否遗漏了重要的探讨角度？
• 是否在充分探索之前就过早得出结论？
• 是否清楚地确定了约束和需求？
• 文档是否已准备好用于研究或规划？

QA 报告：

• 每个测试用例是否都有实际结果和状态？
• 失败是否提供了证据（截图、日志）？
• 总体结论是否与各测试用例的结果一致？
• 是否记录了边界情况和探索性测试？
• 是否在相关情况下附上了外部引用（Sentry、PR、CI）的链接？

步骤 4：识别差距

查找缺失或未经证实的内容：

• 如有需要，将主张与代码库交叉核对（启动 codebase-analyzer Agent 进行验证）
• 找出未说明的假设
• 检查内部矛盾
• 验证外部引用是否仍然有效

步骤 5：呈现发现

将所有发现分为三个严重程度级别：

严重程度	含义	操作
Critical	阻碍正确性或完整性——必须处理	与用户讨论
Important	存在重大差距或缺陷——应当处理	与用户讨论（或在 Autopilot 中自动修复）
Minor	格式、拼写错误、小的不一致	除非处于 Verbose 模式，否则自动修复

以文本形式提供摘要，并按严重程度归类发现。

步骤 6：应用或讨论

根据输出模式偏好进行处理：

如果选择“追加勘误”：

• 直接在文档中自动修复 Minor 问题
• 对于 Critical/Important 项目，在文档末尾追加 ## Review Errata 部分，其中包含：

  ## Review Errata
  
  _Reviewed: YYYY-MM-DD by [reviewer]_
  
  ### Critical
  - [ ] [Finding description and recommended action]
  
  ### Important
  - [ ] [Finding description and recommended action]
  
  ### Resolved
  - [x] [Minor issue] — auto-fixed
  

如果选择“自动应用”：

• 直接在文档中自动修复 Minor 问题
• 直接在文档中自动修复 Important 问题
• 对于 Critical 发现，使用 AskUserQuestion，询问：

问题	选项
“有 [N] 项 Critical 发现。要我也自动应用这些修复吗？”	1. 是，也应用 Critical 修复，2. 否，将 Critical 项目留作勘误，由我处理

• 如果获得授权，则应用 Critical 修复；否则，将其作为未勾选的勘误事项保留
• 追加 ## Review Errata 部分，概述所有更改：

  ## Review Errata
  
  _Reviewed: YYYY-MM-DD by [reviewer]_
  
  ### Applied
  - [x] [Finding description] — auto-applied
  - [x] [Finding description] — auto-applied
  
  ### Remaining (if any Critical items were not auto-applied)
  - [ ] [Critical finding description and recommended action]
  

如果选择“单独文件”：

• 将审查结果写入 thoughts/*/reviews/YYYY-MM-DD-review-of-<original-slug>.md
• 包含所有发现，并注明指向原始文档的引用

步骤 7：工作流交接

审查完成后，确定文档类型（根据 frontmatter、文件路径或内容），并提出合适的下一步操作。

使用 AskUserQuestion，并根据上下文提供选项：

如果审查的是头脑风暴文档：

问题	选项
"审查完成。接下来要如何处理这份头脑风暴文档？"	1. 开始研究（→ /research），2. 直接制定计划（→ /create-plan），3. 暂时到此为止

如果审查的是研究文档：

问题	选项
"审查完成。接下来要如何处理这份研究？"	1. 制定计划（→ /create-plan），2. 暂时到此为止

如果审查的是计划文档：

问题	选项
"审查完成。接下来要如何处理这份计划？"	1. 开始实施（→ /implement-plan），2. 暂时到此为止

如果审查的是实施后验证：

问题	选项
"审查完成。接下来要做什么？"	1. 完成 — 标记为已完成，2. 处理剩余事项

如果审查的是 QA 报告：

问题	选项
"审查完成。接下来要如何处理这份 QA 报告？"	1. 运行 QA 后验证（→ /verify-plan），2. 处理发现的问题，3. 完成

如果文档类型不明确，请提出通用问题：

问题	选项
"审查完成。要继续执行下一步工作流吗？"	1. 是，请建议下一步，2. 暂时到此为止

学习记录

可选子技能： 如果在此工作流中出现了重要见解、模式、注意事项或决策，可考虑使用 desplega:learning，通过 /learning capture 将其记录下来。重点记录能帮助他人在未来会话中有所收获的内容。

不得重写规则

**重要：**审查者负责发现问题，而不是重写文档。请列出发现的问题，由原作者处理。以下情况除外：

• 始终自动修复轻微问题（拼写错误、格式问题）
• 在 自动应用 模式下，审查者会根据用户授权直接应用重要问题以及（可选的）严重问题修复

审查集成

默认启用文件审查（Autopilot 除外）：

• 自动审查后，调用 /file-review:file-review <path>，以获取行内人工评论
• 使用 file-review:process-review 技能处理反馈