document-review
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseDocument Review
文档评审
Improve brainstorm or plan documents through structured review.
通过结构化评审优化头脑风暴或计划类文档。
Step 1: Get the Document
步骤1：获取文档
If a document path is provided: Read it, then proceed to Step 2.
If no document is specified: Ask which document to review, or look for the most recent brainstorm/plan in or .
docs/brainstorms/docs/plans/如果提供了文档路径： 读取文档，然后进入步骤2。
如果未指定文档： 询问用户需要评审哪份文档，或者在或目录下查找最新的头脑风暴/计划文档。
docs/brainstorms/docs/plans/Step 2: Assess
步骤2：问题排查
Read through the document and ask:
- What is unclear?
- What is unnecessary?
- What decision is being avoided?
- What assumptions are unstated?
- Where could scope accidentally expand?
These questions surface issues. Don't fix yet—just note what you find.
通读文档并思考以下问题：
- 哪些内容表述模糊？
- 哪些内容冗余多余？
- 刻意回避了哪些决策？
- 存在哪些未明确说明的假设？
- 哪些地方可能会意外扩大范围？
这些问题可以帮助发现文档中的问题。此时暂不修复，只需记录发现的内容。
Step 3: Evaluate
步骤3：标准评估
Score the document against these criteria:
| Criterion | What to Check |
|---|---|
| Clarity | Problem statement is clear, no vague language ("probably," "consider," "try to") |
| Completeness | Required sections present, constraints stated, open questions flagged |
| Specificity | Concrete enough for next step (brainstorm → can plan, plan → can implement) |
| YAGNI | No hypothetical features, simplest approach chosen |
If invoked within a workflow (after or ), also check:
/workflows:brainstorm/workflows:plan- User intent fidelity — Document reflects what was discussed, assumptions validated
根据以下标准对文档进行评分：
| 标准 | 检查要点 |
|---|---|
| 清晰度 | 问题陈述清晰，无模糊表述（如“可能”“考虑”“尝试”等） |
| 完整性 | 包含所有必填部分，明确说明约束条件，标记未解决问题 |
| 具体性 | 内容足够具体，可支撑进入下一环节（头脑风暴→可制定计划，计划→可执行） |
| YAGNI原则 | 无假设性功能，选择最简方案 |
如果是在工作流中调用（在或之后），还需检查：
/workflows:brainstorm/workflows:plan- 用户意图一致性 — 文档是否反映了讨论内容，假设是否已验证
Step 4: Identify the Critical Improvement
步骤4：确定关键改进点
Among everything found in Steps 2-3, does one issue stand out? If something would significantly improve the document's quality, this is the "must address" item. Highlight it prominently.
在步骤2-3中发现的所有问题里，是否有一个最突出的问题？如果某问题的解决能显著提升文档质量，那么这就是“必须解决”的事项，需重点突出。
Step 5: Make Changes
步骤5：执行修改
Present your findings, then:
- Auto-fix minor issues (vague language, formatting) without asking
- Ask approval before substantive changes (restructuring, removing sections, changing meaning)
- Update the document inline—no separate files, no metadata sections
先展示发现的问题，然后：
- 自动修复 小问题（如模糊表述、格式问题），无需征求用户同意
- 征求同意 后再进行实质性修改（如重新架构、删除章节、更改语义）
- 在线更新 文档——不生成单独文件，不添加元数据章节
Simplification Guidance
简化指导
Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
Simplify when:
- Content serves hypothetical future needs, not current ones
- Sections repeat information already covered elsewhere
- Detail exceeds what's needed to take the next step
- Abstractions or structure add overhead without clarity
Don't simplify:
- Constraints or edge cases that affect implementation
- Rationale that explains why alternatives were rejected
- Open questions that need resolution
简化是指有针对性地移除不必要的复杂性，而非为了缩短篇幅而缩短。
以下情况需简化：
- 内容服务于假设性的未来需求，而非当前需求
- 章节重复了其他地方已涵盖的信息
- 详细程度超出进入下一环节的需求
- 抽象表述或结构增加了理解成本却未提升清晰度
以下情况请勿简化：
- 影响执行的约束条件或边缘情况
- 解释为何否决其他方案的理由
- 需要解决的未明确问题
Step 6: Offer Next Action
步骤6：提供后续操作选项
After changes are complete, ask:
- Refine again - Another review pass
- Review complete - Document is ready
修改完成后，询问用户：
- 再次优化 - 进行另一轮评审
- 评审完成 - 文档已就绪
Iteration Guidance
迭代指导
After 2 refinement passes, recommend completion—diminishing returns are likely. But if the user wants to continue, allow it.
Return control to the caller (workflow or user) after selection.
经过2轮优化后，建议结束评审——此时继续优化的收益可能会递减。但如果用户希望继续，可允许其操作。
用户选择后，将控制权交还给调用方（工作流或用户）。
What NOT to Do
禁止事项
- Do not rewrite the entire document
- Do not add new sections or requirements the user didn't discuss
- Do not over-engineer or add complexity
- Do not create separate review files or add metadata sections
- 请勿重写整个文档
- 请勿添加用户未讨论过的新章节或需求
- 请勿过度设计或增加复杂性
- 请勿创建单独的评审文件或添加元数据章节