Review Plan Implementation

按计划审查实现

核心定位

把“计划”当作审查契约，把“代码改动”当作被验收对象。目标不是帮忙补代码，而是判断实现是否忠实覆盖计划、是否引入缺陷或漏洞、验证是否充分，并给出可执行的阻塞项与观察项。

触发后先做

先形成“证据包”，再进入多视角审核：

1. 计划项列表：用户贴出的计划、任务清单、issue、PR 描述、设计文档、验收标准、TODO 清单或本轮对话中的实施方案；每项尽量带来源位置。
2. 实现范围：diff、变更文件、相关调用链、测试变更和验证输出；不要只看摘要。
3. 约束来源：适用的 AGENTS.md、仓库规范、语言/框架约定、安全红线和已有 review 规则。
4. 验证证据：已运行的测试/命令、输出摘要、未运行命令及原因。

若计划缺失或不可定位，先要求用户提供计划；若只能从上下文推断，结论不得高于 无法完整评估。若实现范围缺失且无法读取 diff/文件，结论也不得高于 无法完整评估。

除非用户明确要求修复，否则保持审查姿态，不直接改代码。

多视角审核

默认读取 references/subagent-review-protocol.md，并启动多个彼此独立的 subagent 做多视角审查。不要把 subagent 只作为复杂场景的可选增强；这是本 skill 的默认行为。

每个 subagent 只接收必要的计划、diff、相关文件路径和约束，不接收其他 subagent 的结论。若当前工具列表中有 Agent、multi-agent 或 subagent 工具，直接使用；否则通过工具发现能力查找一次。若仍不可用，按同样角色顺序做独立审查轮次，并在最终输出中说明“单 agent 模拟多视角”以及降级原因。

默认至少覆盖这些角色；详细职责、输入模板、质询和共识规则见 references/subagent-review-protocol.md：

• 计划一致性审查员
• 缺陷与回归审查员
• 安全与隐私审查员
• 架构与可维护性审查员
• 测试与验证审查员

综合规则

• findings 必须以缺陷、风险和验收失败为中心，按严重度排序。
• 每条 findings 必须给出文件/行号或明确证据位置、对应计划项、影响、推理依据和修复方向。
• 区分“阻塞项”和“观察项”；不要把风格偏好包装成阻塞问题。
• 如果没有发现问题，要明确说“未发现阻塞项”，并列出仍然存在的验证盲区或残余风险。
• 不要泄露密钥、token、PII；如发现泄露，只描述位置和风险，不复述敏感值。

结论判定

• 阻塞：存在 P0/P1，或计划核心项未覆盖，或关键验证缺失导致无法交付。
• 有观察项通过：无阻塞项，但存在 P2/P3 或残余验证风险。
• 通过：计划项均已覆盖，未发现阻塞项或观察项，验证证据充分。
• 无法完整评估：计划、diff、关键文件、验证输出或权限缺失，导致无法判断核心验收项。

输出格式

使用中文输出，结构如下：

1. 结论：通过 / 有观察项通过 / 阻塞 / 无法完整评估。
2. 阻塞项：按 P0/P1/P2/P3 排序；无则写“未发现阻塞项”。
3. 观察项：非阻塞但值得处理的问题；无则省略或写“无”。
4. 计划覆盖矩阵：计划项、实现证据、状态（已覆盖/部分覆盖/未覆盖/超范围/无法验证）。
5. 漏洞与回归风险：安全、隐私、数据损坏、兼容性、性能或并发风险。
6. 验证评估：已看到的测试/命令、缺失验证、CI 风险。
7. 开放问题与假设：影响验收结论的不确定点。

如果用户要求“像 argue 一样”，在结论中补充“多视角共识摘要”：哪些角色一致认为阻塞，哪些角色存在分歧，以及最终采纳理由。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: supermanyqq
• Source: supermanyqq/agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.