reviewing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reviewing

文档评审

You are performing a structured critique of a document (research, plan, or brainstorm) to identify gaps, weaknesses, and quality issues.

你需要对文档（研究、计划或头脑风暴文档）进行结构化评审，识别其中的缺口、不足与质量问题。

Working Agreement

工作约定

All user-facing questions go through
AskUserQuestion
(when not Autopilot) — see

desplega:ask-user

for conventions. Never ask in chat as plain bullets.

File-review is on by default — invoke it after the automated review (skip only if Autopilot).

所有面向用户的问题需通过
AskUserQuestion
发起（非Autopilot模式下）——相关规范请参考

desplega:ask-user

。禁止在聊天中以普通项目符号形式提问。

文件评审默认开启——自动评审完成后需调用该功能（仅Autopilot模式下可跳过）。

Output Mode

输出模式

Unless Autopilot, ask once at the start:

Question	Options
"How should I present the review findings?"	1. Append errata section to the document (Recommended), 2. Auto-apply fixes to the document, 3. Write a separate review file to thoughts/*/reviews/

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

问题	选项
"评审结果应如何呈现？"	1. 在文档末尾添加勘误章节（推荐），2. 自动将修复应用到文档中，3. 在thoughts/*/reviews/目录下撰写独立的评审文件

When to Use

使用场景

This skill activates when:

User invokes
```
/review
```
command
Another skill references the reviewing skill at completion
User asks to review, critique, or check a document

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

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

Autonomy Mode

自主模式

At the start of review, adapt your interaction level based on the autonomy mode:

Mode	Behavior
Autopilot	Run full review, auto-fix minor issues, present summary at end
Critical (Default)	Ask about Critical/Important findings, auto-fix Minor ones
Verbose	Walk through each finding, confirm before any changes

The autonomy mode is passed by the invoking command. If not specified, default to Critical.

评审开始时，需根据自主模式调整交互程度：

模式	行为
Autopilot	执行完整评审，自动修复小问题，最后呈现总结
Critical（默认）	询问关于严重/重要问题的处理方式，自动修复小问题
Verbose	逐一展示每个问题，在进行任何更改前确认

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

Process Steps

流程步骤

Step 1: Read & Classify

步骤1：阅读与分类

Read the input document fully. Determine the document type from its path and content structure:

Path contains	Type
`/research/`	Research document
`/plans/`	Plan
`/brainstorms/`	Brainstorm
`/qa/`	QA report

If the type is ambiguous, infer from content structure or use AskUserQuestion to clarify.

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

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

若类型不明确，可根据内容结构推断，或使用AskUserQuestion澄清。

Step 2: Structural Check

步骤2：结构检查

Verify required sections exist based on document type:

Research documents:

YAML frontmatter with required fields (date, researcher, topic, status)
Research Question section
Summary section
Detailed Findings with file:line references
Code References table
Open Questions section

Plans:

YAML frontmatter with required fields (date, planner, topic, status)
Overview with Motivation + Related links
Current State Analysis
Desired End State
What We're NOT Doing
Implementation Approach (bullet one-liners)
Quick Verification Reference
Phases with Changes Required and Success Criteria (all three subsections: Automated Verification, Automated QA, Manual Verification)
QA Spec (when present) is a link to a
```
desplega:qa
```
-generated doc, not inline scenarios
Appendix (follow-up plans, derail notes, references)

Brainstorms:

YAML frontmatter with required fields (date, author, topic, status)
Context section
Exploration section with Q&A pairs
Synthesis section
Next Steps section

QA reports:

YAML frontmatter with required fields (date, author, topic, status)
Context section
Scope section (In Scope / Out of Scope)
Test Cases with Steps, Expected, Actual, Status per case
Evidence section (Screenshots, Videos, Logs, or External Links)
Verdict section with overall status and summary

根据文档类型验证是否存在必填章节：

研究文档：

包含必填字段的YAML前置内容（日期、研究者、主题、状态）
研究问题章节
总结章节
带file:line引用的详细发现章节
代码引用表格
未解决问题章节

计划文档：

包含必填字段的YAML前置内容（日期、制定者、主题、状态）
包含动机+相关链接的概述章节
当前状态分析章节
期望最终状态章节
非工作范围章节
实现方案（项目符号式单行描述）
快速验证参考章节
包含所需变更和成功标准的阶段章节（需包含三个子章节：自动验证、自动QA、手动验证）
QA规范（若存在）需链接到
```
desplega:qa
```
生成的文档，而非内联场景
附录（后续计划、偏离记录、参考资料）

头脑风暴文档：

包含必填字段的YAML前置内容（日期、作者、主题、状态）
背景章节
包含问答对的探索章节
综合分析章节
下一步行动章节

QA报告：

包含必填字段的YAML前置内容（日期、作者、主题、状态）
背景章节
范围章节（包含范围内/范围外）
带步骤、预期结果、实际结果、状态的测试用例章节
证据章节（截图、视频、日志或外部链接）
包含整体状态和总结的结论章节

Step 3: Content Analysis

步骤3：内容分析

Apply type-specific quality criteria:

Research documents:

Are findings supported by specific file:line references?
Are there claims without evidence from the codebase?
Are there obvious areas that weren't investigated?
Are open questions actually open (not answerable from the findings)?

Plans:

Are there missing phases or gaps in the implementation sequence?
Are success criteria specific enough to be actionable?
Are there unstated assumptions about the codebase?
Is error handling or rollback addressed?
Is there scope creep risk (doing more than stated)?

Brainstorms:

Were important angles left unexplored?
Were conclusions reached prematurely before sufficient exploration?
Are constraints and requirements clearly identified?
Is the document ready to feed into research or planning?

QA reports:

Does every test case have an actual result and status?
Is evidence provided for failures (screenshots, logs)?
Is the verdict consistent with individual test case results?
Are edge cases and exploratory testing documented?
Are external references (Sentry, PRs, CI) linked where relevant?

应用针对不同类型文档的质量标准：

研究文档：

发现内容是否有具体的file:line引用支持？
是否存在无代码库证据支撑的断言？
是否有明显未调查的领域？
未解决问题是否真的无法从现有发现中找到答案？

计划文档：

是否存在缺失的阶段或实现顺序中的缺口？
成功标准是否足够具体可执行？
是否存在关于代码库的未说明假设？
是否涉及错误处理或回滚方案？
是否存在范围蔓延风险（超出既定工作范围）？

头脑风暴文档：

是否遗漏了重要的探讨角度？
是否在充分探索前过早得出结论？
是否明确识别了约束条件和需求？
文档是否已准备好用于后续研究或规划？

QA报告：

每个测试用例是否都有实际结果和状态？
失败案例是否提供了证据（截图、日志）？
结论是否与单个测试用例结果一致？
是否记录了边缘案例和探索性测试？
是否在相关位置链接了外部参考资料（Sentry、PR、CI）？

Step 4: Gap Identification

步骤4：缺口识别

Look for what's missing or assumed:

Cross-reference claims against the codebase if needed (spawn codebase-analyzer agent for verification)
Identify unstated assumptions
Check for internal contradictions
Verify external references are still valid

查找缺失或被默认假设的内容：

必要时将断言与代码库交叉验证（调用codebase-analyzer agent进行验证）
识别未说明的假设
检查内部矛盾
验证外部参考资料是否仍然有效

Step 5: Present Findings

步骤5：呈现结果

Categorize all findings into three severity levels:

Severity	Meaning	Action
Critical	Blocks correctness or completeness — must be addressed	Discuss with user
Important	Significant gap or weakness — should be addressed	Discuss with user (or auto-fix in Autopilot)
Minor	Formatting, typos, small inconsistencies	Auto-fix unless Verbose mode

Present a summary as text output with findings grouped by severity.

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

严重级别	含义	行动
Critical	影响正确性或完整性，必须解决	与用户讨论
Important	存在显著缺口或不足，应该解决	与用户讨论（或在Autopilot模式下自动修复）
Minor	格式错误、拼写错误、小的不一致	自动修复，除非处于Verbose模式

以文本输出形式呈现总结，按严重级别分组展示发现内容。

Step 6: Apply or Discuss

步骤6：应用修复或讨论

Based on output mode preference:

If "Append errata":

Auto-fix Minor issues directly in the document

For Critical/Important items, append a

## Review Errata

section at the end of the document with:

## 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

If "Auto-apply":

Auto-fix Minor issues directly in the document
Auto-fix Important issues directly in the document
For Critical findings, use AskUserQuestion with:

Question	Options
"There are [N] Critical findings. Would you like me to auto-apply fixes for those too?"	1. Yes, apply Critical fixes too, 2. No, leave Critical items as errata for me to address

Apply Critical fixes if authorized, otherwise leave them as unchecked errata items

Append a

## Review Errata

section summarizing all changes:

## 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]

If "Separate file":

Write review to

thoughts/*/reviews/YYYY-MM-DD-review-of-<original-slug>.md

Include all findings with references back to the original document

根据输出模式偏好执行：

若选择“添加勘误”：

直接在文档中自动修复Minor问题

对于Critical/Important问题，在文档末尾添加

## Review Errata

章节，内容如下：

## Review Errata

_评审时间：YYYY-MM-DD by [评审人]_ 

### Critical
- [ ] [问题描述及建议行动]

### Important
- [ ] [问题描述及建议行动]

### 已解决
- [x] [Minor问题] — 已自动修复

若选择“自动应用修复”：

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

问题	选项
"存在[N]个Critical问题。是否需要我也自动应用这些问题的修复方案？"	1. 是，同时应用Critical问题的修复，2. 否，将Critical问题保留为勘误由我自行处理

若获得授权则应用Critical问题的修复，否则将其保留为未勾选的勘误项

在文档末尾添加

## Review Errata

章节，总结所有变更：

## Review Errata

_评审时间：YYYY-MM-DD by [评审人]_ 

### 已应用修复
- [x] [问题描述] — 已自动应用修复
- [x] [问题描述] — 已自动应用修复

### 剩余问题（若存在未自动修复的Critical项）
- [ ] [Critical问题描述及建议行动]

若选择“独立文件”：

将评审内容写入

thoughts/*/reviews/YYYY-MM-DD-review-of-<original-slug>.md

文件

包含所有发现内容，并提供指向原文档的引用

Step 7: Workflow Handoff

步骤7：工作流交接

After the review is complete, determine the document type (from frontmatter, file path, or content) and propose the appropriate next step.

Use AskUserQuestion with context-dependent options:

If reviewing a brainstorm document:

Question	Options
"Review complete. What's next for this brainstorm?"	1. Start research (→ `/research` ), 2. Create a plan directly (→ `/create-plan` ), 3. Done for now

If reviewing a research document:

Question	Options
"Review complete. What's next for this research?"	1. Create a plan (→ `/create-plan` ), 2. Done for now

If reviewing a plan document:

Question	Options
"Review complete. What's next for this plan?"	1. Start implementation (→ `/implement-plan` ), 2. Done for now

If reviewing a post-implementation verification:

Question	Options
"Review complete. What's next?"	1. Done — mark as complete, 2. Address remaining items

If reviewing a QA report:

Question	Options
"Review complete. What's next for this QA report?"	1. Run post-QA verification (→ `/verify-plan` ), 2. Address issues found, 3. Done

If document type is unclear, ask a generic question:

Question	Options
"Review complete. Would you like to proceed to the next workflow step?"	1. Yes, suggest next step, 2. Done for now

评审完成后，确定文档类型（从前置内容、文件路径或内容中获取）并提出合适的下一步建议。

使用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. 暂时结束

Learning Capture

经验捕获

OPTIONAL SUB-SKILL: If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using

desplega:learning

to capture them via

/learning capture

. Focus on learnings that would help someone else in a future session.

可选子技能： 若在此工作流中获得了重要见解、模式、注意事项或决策，可考虑使用

desplega:learning

通过

/learning capture

命令进行记录。重点记录能帮助他人在未来会话中避免问题的经验。

No Rewriting Rule

禁止重写规则

CRITICAL: The reviewer identifies issues — the reviewer does NOT rewrite the document. Present findings and let the original author address them. Exceptions:

Minor auto-fixes (typos, formatting) are always applied
In Auto-apply mode, the reviewer applies Important and (optionally) Critical fixes directly, as authorized by the user

重要提示：评审者仅负责识别问题——不得重写文档。需呈现问题发现，由原作者进行处理。例外情况：

小问题的自动修复（拼写错误、格式问题）始终允许
在Auto-apply模式下，经用户授权后，评审者可直接应用Important及（可选）Critical问题的修复方案

Review Integration

评审集成

File-review is on by default (unless Autopilot):

After the automated review, invoke
```
/file-review:file-review <path>
```
for inline human comments
Process feedback with the
```
file-review:process-review
```
skill

文件评审默认开启（Autopilot模式除外）：

自动评审完成后，调用
```
/file-review:file-review <path>
```
获取内联人工评论
使用
```
file-review:process-review
```
技能处理反馈