document-review by everyinc/compound-engineering-plugin
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill document-review通过结构化评审改进需求或规划文档。
如果提供了文档路径: 读取它,然后继续步骤 2。
如果未指定文档: 询问要评审哪个文档,或者在 docs/brainstorms/ 或 docs/plans/ 中查找最新的需求/规划文档。
通读文档并提出以下问题:
这些问题旨在发现问题。先不要修复——只需记录你的发现。
根据以下标准对文档进行评分:
| 标准 | 检查内容 |
|---|---|
| 清晰度 | 问题陈述清晰,没有模糊语言(如"可能"、"考虑"、"尝试") |
| 完整性 | 必要的部分齐全,约束条件已说明,未解决的问题明确标记为阻塞性或已推迟 |
| 具体性 | 足够具体以进行下一步(需求 → 可规划,规划 → 可实施) |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 适当的层级 | 需求文档保持在行为/范围层面,除非文档本身是技术性的,否则不应涉及实现细节 |
| YAGNI | 避免推测性复杂性,其维护成本超过其价值;在易于维护时保留低成本、有意义的优化 |
如果在工作流中调用(在 /ce:brainstorm 或 /ce:plan 之后),还需检查:
在步骤 2-3 中发现的所有问题中,是否有某个问题特别突出?如果某个问题能显著提高文档质量,这就是"必须解决"的事项。请突出显示它。
呈现你的发现,然后:
简化是有目的地移除不必要的复杂性,而不是为了缩短而缩短。
在以下情况下进行简化:
不要简化:
在不适当时也应移除:
更改完成后,询问:
经过 2 次优化后,建议完成——很可能收益递减。但如果用户希望继续,请允许。
选择后将控制权交还给调用者(工作流或用户)。
每周安装次数
221
仓库
GitHub 星标
10.9K
首次出现
2026年2月9日
安全审计
安装于
codex211
opencode208
gemini-cli208
github-copilot204
cursor196
amp192
Improve requirements or plan documents through structured review.
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 requirements/plan in docs/brainstorms/ or docs/plans/.
Read through the document and ask:
These questions surface issues. Don't fix yet—just note what you find.
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, and outstanding questions clearly marked as blocking or deferred |
| Specificity | Concrete enough for next step (requirements → can plan, plan → can implement) |
| Appropriate Level | Requirements doc stays at behavior/scope level and does not drift into implementation unless the document is inherently technical |
| YAGNI | Avoid speculative complexity whose carrying cost outweighs its value; keep low-cost, meaningful polish when it is easy to maintain |
If invoked within a workflow (after /ce:brainstorm or /ce:plan), also check:
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.
Present your findings, then:
Simplification is purposeful removal of unnecessary complexity, not shortening for its own sake.
Simplify when:
Don't simplify:
Also remove when inappropriate:
After changes are complete, ask:
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.
Weekly Installs
221
Repository
GitHub Stars
10.9K
First Seen
Feb 9, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex211
opencode208
gemini-cli208
github-copilot204
cursor196
amp192
开源项目教练指南 - 诊断问题、制定行动计划、优化开源项目运营
31,600 周安装