关于 plan-review
Plan Review Skill 用于在实施前只读审查技术计划、提案和设计文档。它检查风险、假设、缺漏与范围，并输出标注严重程度的发现及结论。
主要功能
- 01产品、工程或综合审查视角
- 02检查隐含假设
- 03梳理故障模式与风险
- 04评估范围及实施顺序
- 05输出严重程度标记和结论
适用场景
- 01编码前审查设计方案
- 02发现故障与恢复路径缺漏
- 03检查范围及任务依赖关系
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/plan-review确认已加载。
附带文件evals/cases.yamlreferences/project-detection.md
详细介绍
计划评审技能
目的
对技术计划、提案或设计文档进行结构化的实施前审查。在编写任何代码_之前_，尽早发现风险、不当假设、缺失内容和范围问题——此时纠正成本最低。
此技能为只读，不会修改代码。它会生成一份标注严重程度的评审文档，并给出最终的发布／重新考虑／拒绝结论。
步骤 0 — 选择模式
通过 AskUserQuestion 向用户提出一个问题：
请选择评审视角。（1）产品——范围、用户影响、业务契合度。 （2）工程——架构、故障模式、测试策略、性能。 （3）综合（默认）——整合两种视角。
接受用户的回答并继续。不要再询问其他配置问题。
同时根据计划评估范围大小：
- 小型变更（单个文件，约 100 行或更少）：提交精简的四部分评审——范围、风险、缺失内容、结论。跳过完整的多部分模板。
- 标准变更：执行以下完整评审流程。
完整评审流程
1. 理解计划
从头到尾阅读计划。用 2–3 句话概述，确认你已理解计划。明确列出：
- 既定目标——计划声称要实现的目标。
- 非目标——明确排除在范围之外的内容。
- 约束条件——计划中提及或暗示的预算、时间线、兼容性、团队规模或技术约束。
如果概述有误，用户可在此处纠正，然后再继续评审，避免后续评审建立在错误理解之上。
2. 质疑假设
提取所有隐含假设。针对每个假设填写：
| 假设 | 如果不成立？ | 支持证据 | 什么情况会证伪？ |
|---|
需要探查的常见假设类别：
- 数据的可用性和形态
- 第三方 API 的稳定性和速率限制
- 团队对所选工具的熟悉程度
- 依赖项的性能特征
- 向后兼容要求
- 部署环境能力
3. 风险与故障映射
为计划中的每个组件或子系统填写故障模式表：
| 组件 | 故障模式 | 影响范围 | 恢复策略 |
|---|
此外，还要识别数据流中的隐蔽路径——不属于正常流程，但会在生产环境中执行的副作用、异步回调、事件传播或缓存失效链。
如果计划涉及三个或更多相互交互的组件，请使用 ASCII 图示说明不明显的数据流或故障传播路径。
4. 逐个组件评审（工程视角）
评估每个主要组件的以下方面：
- 错误处理策略——错误是否分类后通过注册表分发，还是被兜底处理程序静默吞掉？
- 数据完整性不变量——必须满足哪些不变量？如何保证？违反时会发生什么？
- 并发与竞态条件——共享状态、锁的顺序、乐观与悲观策略、幂等性保证。
- 负载下的性能——在当前规模的 10 倍下，预期吞吐量、延迟预算和资源消耗如何？
- 测试策略是否充分——组件的单元、集成和端到端测试覆盖情况如何？哪些内容无法测试，原因是什么？
本节不依赖特定语言或框架。已知用户所用技术栈时，请参阅 references/project-detection.md，了解针对框架的示例。
仅运行产品视角模式时，跳过本节。
5. 范围与优先级评估（产品视角）
- 必需项与锦上添花项 — 哪些功能对既定目标至关重要？哪些只是推测性的？
- 可延后事项 — 哪些内容可以在后续版本中发布，而不会增加风险？
- 过度设计的迹象 — 是否存在当前需求并不要求的抽象、可配置性或可扩展性？
- 对用户的影响 — 复杂度是否带来了相称的用户价值？
仅运行工程视角模式时，跳过本节。
6. 集成审查
组件彼此之间以及与外部系统的连接方式：
- API 契约 — 模块之间的请求／响应结构、版本控制和错误代码。
- 跨边界状态管理 — 谁负责管理状态？状态如何同步？发生局部故障时会怎样？
- 迁移与部署顺序 — 哪些组件必须先部署？系统是否会出现不一致的中间状态？
- 回滚兼容性 — 每个部署步骤都能否独立撤销？哪些数据不可逆？
7. 缺失内容
计划中没有涉及但应当涉及的内容：
- 监控与可观测性（指标、日志、告警、仪表板）
- 首次重试之后的错误恢复路径
- 已说明的正常流程之外的边缘情况
- 安全考量（身份验证、授权、输入验证、密钥管理）
- 负载与扩展影响（连接池、队列深度、存储增长）
- 事件响应运维手册
8. 执行评估
评估提议的实现顺序：
- 依赖顺序 — 是否先构建前置组件，再构建依赖组件？
- 并行工作机会 — 哪些任务之间没有依赖，可以同时进行？
- 风险优先还是价值优先 — 计划是否及早处理风险最高的未知因素，还是将其推迟？
- 原型候选项 — 哪些组件应先进行快速验证，再决定是否全面实现？
9. 结论
只能给出以下结论之一：
| 结论 | 含义 |
|---|---|
| 发布 | 计划完善。按原计划推进。 |
| 修改后发布 | 方案可行，但推进前必须完成下方列出的具体修改。 |
| 重新规划 | 存在根本性结构问题，需要重新规划。逐项列出必须修改的内容。 |
| 拒绝 | 计划不可行。说明原因，并提出可考虑的替代方向。 |
用一段话说明结论理由。
精简审查（小型变更）
对于范围较小的变更（单个文件，约 100 行），仅提供以下四个部分：
- 范围 — 变更的作用及其边界。
- 风险 — 失效模式和影响范围（简要表格）。
- 缺失内容 — 即使在此规模下也值得解决的缺口。
- 结论 — 发布／修改后发布／重新规划／拒绝。
交互协议
- 一次只针对一个问题使用
AskUserQuestion。切勿在同一条提示中批量提出多个问题。 - 对于 HIGH 严重性的问题，应立即指出，并询问是继续还是暂停讨论，然后再进入下一节。
- 此技能为只读。不得创建、修改或删除任何文件。
- 在有助于说明故障传播或集成拓扑时，使用 ASCII 图展示数据流和组件关系。
输出格式
结构化审查文档，包含：
- 与上述顺序一致的编号章节
- 每条发现都标注严重性：[HIGH]、[MEDIUM]、[LOW]
- 文末按严重性分组列出所有发现的汇总表
- 最终结论及理由