Back to Details

review-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<skill name="apex:review-plan" phase="advisory"> <overview> Lightweight plan review that catches gaps and errors before implementation commitment.
Three focused lenses:
  1. Completeness - Are all required plan artifacts present and substantive?
  2. Gap Analysis - What did research find that plan doesn't address?
  3. Correctness - Is the plan internally consistent and feasible?
Output goes to chat. User fixes issues inline, then proceeds to implement. </overview>
<phase-gate requires="none" sets="none"> <reads-file>./apex/tasks/[ID].md</reads-file> <expects-sections>research, plan</expects-sections> <outputs-to>chat</outputs-to> </phase-gate> <principles> - **Advisory Only**: No phase changes, no file modifications - **Fast**: Direct analysis, no subagents - **Actionable**: Every gap or error includes what to fix - **Honest**: Call out real problems, don't rubber-stamp - **Flexible**: Works regardless of current phase </principles> <initial-response> <if-no-arguments> I'll review the plan for gaps and correctness. Please provide the task identifier.
You can find tasks in 
./apex/tasks/
or run with: 
/apex:review-plan [identifier]
</if-no-arguments> <if-arguments>Load task file and begin review.</if-arguments> </initial-response>
<workflow> <step id="1" title="Load task and extract sections"> <instructions> 1. Read `./apex/tasks/[identifier].md` 2. Note current phase from frontmatter (informational only - don't block) 3. Extract and parse (note any missing sections): - `<task-contract>` - From within `<research>` section - `<research>` - All findings from research phase - `<plan>` - All artifacts from plan phase 4. If `<research>` or `<plan>` sections are missing/empty, report as finding (don't refuse) 5. Verify file paths mentioned in `<plan><architecture-decision><files-to-modify>` exist using glob/ls </instructions> </step> <step id="2" title="Completeness Check"> <purpose> Verify all mandatory plan artifacts are present and substantive. </purpose> <mandatory-artifacts> Look for these concepts (tag names may vary):
  1. Design Rationale - Current state, problem breakdown, hidden complexity, success criteria
  2. Tree of Thought - 3 different solution approaches with a winner selected
  3. Chain of Draft - Evolution through multiple drafts
  4. YAGNI - What's explicitly excluded, complexity budget
  5. Patterns - Which patterns are being applied (can be empty)
  6. Architecture Decision - Files to change, implementation steps, how to validate
  7. Builder Handoff - Clear mission, ordered steps, validation checkpoints
  8. Contract Validation - AC coverage confirmation </mandatory-artifacts>
<contract-validation> - [ ] Plan acknowledges the current contract version - [ ] If amendments exist in task-contract, they are acknowledged in plan - [ ] Every AC in task-contract is addressed somewhere in plan </contract-validation> <output-format>
<skill name="apex:review-plan" phase="advisory"> <overview> 轻量级计划评审，在确定实施前发现漏洞和错误。
三个核心评审维度：
  1. 完整性 - 所有必需的计划工件是否齐全且内容充实？
  2. 漏洞分析 - 研究发现了哪些计划未涉及的内容？
  3. 正确性 - 计划是否内部一致且具备可行性？
评审结果将发送至聊天窗口。用户可在线修复问题，随后即可推进实施。 </overview>
<phase-gate requires="none" sets="none"> <reads-file>./apex/tasks/[ID].md</reads-file> <expects-sections>research, plan</expects-sections> <outputs-to>chat</outputs-to> </phase-gate> <principles> - **仅提供咨询建议**：不更改阶段，不修改文件 - **高效快速**：直接分析，不使用子代理 - **可落地执行**：每个漏洞或错误都包含修复说明 - **客观坦诚**：指出真实问题，不走过场 - **灵活适配**：不受当前阶段限制 </principles> <initial-response> <if-no-arguments> 我将评审计划以查找漏洞并验证正确性。请提供任务标识符。
你可以在
./apex/tasks/
目录中找到任务，或运行以下命令： 
/apex:review-plan [identifier]
</if-no-arguments> <if-arguments>加载任务文件并开始评审。</if-arguments> </initial-response>
<workflow> <step id="1" title="加载任务并提取内容板块"> <instructions> 1. 读取`./apex/tasks/[identifier].md`文件 2. 从前置元数据中记录当前阶段（仅作参考，不阻塞流程） 3. 提取并解析（记录任何缺失的部分）： - `<task-contract>` - 来自`<research>`部分 - `<research>` - 研究阶段的所有发现 - `<plan>` - 计划阶段的所有工件 4. 如果`<research>`或`<plan>`部分缺失/为空，将其作为发现结果上报（不拒绝执行） 5. 使用glob/ls命令验证`<plan><architecture-decision><files-to-modify>`中提及的文件路径是否存在 </instructions> </step> <step id="2" title="完整性检查"> <purpose> 验证所有必填计划工件是否齐全且内容充实。 </purpose> <mandatory-artifacts> 查找以下核心要素（标签名称可能有所不同）：
  1. 设计依据 - 当前状态、问题拆解、隐藏复杂度、成功标准
  2. 思路树 - 3种不同的解决方案，并选定最优方案
  3. 草稿迭代链 - 经过多版草稿的演化过程
  4. YAGNI原则 - 明确排除的内容、复杂度预算
  5. 设计模式 - 拟采用的模式（可留空）
  6. 架构决策 - 待修改文件、实施步骤、验证方式
  7. 执行者交付内容 - 清晰的目标、有序的步骤、验证检查点
  8. 契约验证 - 确认验收标准（AC）覆盖范围 </mandatory-artifacts>
<contract-validation> - [ ] 计划确认了当前契约版本 - [ ] 如果任务契约中存在修订内容，计划已确认这些修订 - [ ] 任务契约中的每一条验收标准（AC）都在计划中有所涉及 </contract-validation> <output-format>

Completeness Check

完整性检查

Missing Artifacts

缺失的工件

  • [Artifact name]: Not found or empty
    • Fix: Add required section to plan
  • [工件名称]: 未找到或内容为空
    • 修复方案: 在计划中添加所需板块

Incomplete Artifacts

不完整的工件

  • [Artifact name]: Missing [specific subsection]
    • Fix: Add [subsection] with [expected content]
  • [工件名称]: 缺失[具体子板块]
    • 修复方案: 添加包含[预期内容]的[子板块]

Contract Issues

契约问题

  • Version mismatch: Contract v[X] but plan references v[Y]
    • Fix: Update plan to reference current contract version
  • Unacknowledged amendment: Amendment not recorded in plan
    • Fix: Acknowledge the amendment in plan
Completeness Score: [N] artifacts present, [N] issues </output-format> </step>
<step id="3" title="Gap Analysis"> <purpose> Find what research discovered that plan doesn't address. </purpose> <checklist> **Research Risks vs Plan Mitigations:** - [ ] Every risk identified in research has a mitigation in plan - [ ] High-probability AND high-impact risks have explicit handling - List any unaddressed risks with their probability/impact
Research Security Concerns vs Plan:
  • Security concerns from research are addressed in plan OR explicitly excluded
  • List any unaddressed security concerns
Pattern Provenance:
  • Patterns claimed in plan can be traced to research (pattern library or codebase conventions)
  • Trust scores roughly match what research found
  • List any patterns that appear fabricated or unsupported
Documentation Drift:
  • Docs flagged for update in research are included in plan's files to modify (or noted as intentionally skipped)
  • List any documentation that will drift
Research Recommendations vs Chosen Solution:
  • Plan's chosen solution aligns with research recommendation (or has justification for divergence)
  • List any unexplained divergences
Task Contract Coverage:
  • Every AC in task-contract maps to implementation steps
  • Non-functional requirements are addressed in validation approach
  • List any uncovered ACs or NFRs
Complexity Budget:
  • Plan's complexity estimate is reasonable given what research found
  • Flag if plan seems significantly over/under-scoped </checklist>
<output-format>
  • 版本不匹配: 契约版本为v[X]，但计划引用的是v[Y]
    • 修复方案: 更新计划以引用当前契约版本
  • 未确认的修订: 修订内容未在计划中记录
    • 修复方案: 在计划中确认该修订内容
完整性得分: [N]个工件已存在，[N]个问题 </output-format> </step>
<step id="3" title="漏洞分析"> <purpose> 找出研究发现但计划未涉及的内容。 </purpose> <checklist> **研究风险 vs 计划缓解措施：** - [ ] 研究中识别的每一项风险都在计划中有对应的缓解措施 - [ ] 高概率且高影响的风险有明确的处理方案 - 列出所有未处理的风险及其概率/影响等级
研究安全关注点 vs 计划：
  • 研究中提出的安全关注点已在计划中处理或被明确排除
  • 列出所有未处理的安全关注点
设计模式溯源：
  • 计划中提及的模式可追溯至研究来源（模式库或代码库规范）
  • 信任评分与研究结果大致匹配
  • 列出所有看似虚构或无依据的模式
文档偏差：
  • 研究中标记需更新的文档已纳入计划的待修改文件列表（或注明故意跳过）
  • 列出所有将出现偏差的文档
研究建议 vs 选定方案：
  • 计划选定的方案与研究建议一致（或有偏离的合理理由）
  • 列出所有无合理解释的偏离情况
任务契约覆盖：
  • 任务契约中的每一条验收标准（AC）都对应到实施步骤
  • 非功能需求在验证方案中已被覆盖
  • 列出所有未覆盖的验收标准（AC）或非功能需求（NFR）
复杂度预算：
  • 计划的复杂度估算与研究结果相符
  • 若计划范围明显过大/过小，需标记出来 </checklist>
<output-format>

Gap Analysis

漏洞分析

Unaddressed Risks

未处理的风险

  • [Risk name] (probability: [H/M/L], impact: [H/M/L]): Research identified [description]. Plan has no mitigation.
    • Fix: Add mitigation to plan's risk section.
  • [风险名称]（概率：[高/中/低]，影响：[高/中/低]）：研究指出[描述]，但计划中无缓解措施。
    • 修复方案: 在计划的风险板块中添加缓解措施。

Security Gaps

安全漏洞

  • [Concern]: From research, not addressed in plan.
    • Fix: Add to risks or explicitly exclude with rationale.
  • [关注点]: 来自研究，但未在计划中处理。
    • 修复方案: 将其添加至风险列表或明确排除并说明理由。

Pattern Issues

模式问题

  • [Pattern]: Claimed in plan but can't find source in research.
    • Fix: Remove pattern or trace back to research source.
  • [Pattern]: Confidence rating mismatch ([X] in plan vs [Y] in research).
    • Fix: Align confidence rating with research.
  • [模式名称]: 计划中提及但无法在研究中找到来源。
    • 修复方案: 删除该模式或追溯至研究来源。
  • [模式名称]: 信任评分不匹配（计划中为[X]，研究中为[Y]）。
    • 修复方案: 调整信任评分使其与研究结果一致。

Documentation That Will Drift

将出现偏差的文档

  • [doc path]: Research flagged for update, not in plan's files to modify.
    • Fix: Add to files or note why update not needed.
  • [文档路径]: 研究中标记需更新，但未纳入计划的待修改文件列表。
    • 修复方案: 将其添加至待修改文件列表或说明无需更新的理由。

Uncovered Requirements

未覆盖的需求

  • AC-[N]: [Description] - No implementation step addresses this.
    • Fix: Add step to cover this AC.
  • NFR [type]: [Constraint] - Not validated.
    • Fix: Add validation for this constraint.
Gap Score: [N] gaps ([N] critical, [N] moderate, [N] minor) </output-format> </step>
<step id="4" title="Correctness Check"> <purpose> Verify plan is internally consistent and feasible. </purpose> <checklist> **Internal Consistency:** - [ ] Chosen solution in summary/metadata matches the winner in Tree of Thought - [ ] Complexity estimate aligns with risks (high risk → expect higher complexity) - [ ] Implementation sequence in architecture decision matches builder handoff - [ ] Risk level matches actual risks identified - List any contradictions
Tree of Thought Validity:
  • 3 solutions are genuinely different approaches (not variations of same idea)
  • Winner selection has concrete reasoning citing evidence (not "this feels right")
  • Pros/cons reference specific findings from research, not hypotheticals
Chain of Draft Evolution:
  • Final draft is meaningfully different from first draft (not cosmetic rewording)
  • Issues identified in earlier drafts are resolved in later drafts
  • Evolution shows actual refinement based on research insights
YAGNI Coherence:
  • Excluded features don't contradict task contract in-scope items
  • Excluded features aren't required by any AC
Implementation Sequence:
  • Steps are in dependency order (foundations before dependents)
  • Each step has a concrete validation (command to run, not "verify it works")
  • File paths to modify exist (verify via glob)
  • New files are clearly marked as new
Validation Quality:
  • Automated validation includes actual runnable commands (npm test, pytest, etc.)
  • Manual verification has specific steps, not vague checks
Feasibility:
  • No circular dependencies in implementation sequence
  • Patterns applied at sensible locations (not generic "apply everywhere")
  • No magical thinking ("this edge case won't happen") </checklist>
<output-format>
  • AC-[编号]: [描述] - 无实施步骤对应此需求。
    • 修复方案: 添加步骤以覆盖该验收标准。
  • NFR [类型]: [约束条件] - 未进行验证。
    • 修复方案: 添加针对该约束条件的验证步骤。
漏洞得分: [N]个漏洞（[N]个严重，[N]个中等，[N]个轻微） </output-format> </step>
<step id="4" title="正确性检查"> <purpose> 验证计划是否内部一致且具备可行性。 </purpose> <checklist> **内部一致性：** - [ ] 摘要/元数据中的选定方案与思路树中的最优方案一致 - [ ] 复杂度估算与风险等级匹配（高风险→预期复杂度更高） - [ ] 架构决策中的实施顺序与执行者交付内容一致 - [ ] 风险等级与识别出的实际风险相符 - 列出所有矛盾点
思路树有效性：
  • 3种解决方案是真正不同的思路（而非同一方案的变体）
  • 最优方案的选择有基于证据的具体理由（而非“感觉正确”）
  • 优缺点参考了研究中的具体发现，而非假设
草稿迭代链演化：
  • 最终草稿与初始草稿有实质性差异（而非仅文字修饰）
  • 早期草稿中发现的问题在后续草稿中已解决
  • 演化过程显示基于研究见解的实际优化
YAGNI原则一致性：
  • 排除的功能与任务契约中的范围内项目无冲突
  • 排除的功能并非任何验收标准（AC）所要求
实施顺序：
  • 步骤按依赖顺序排列（基础工作优先于依赖项）
  • 每个步骤都有具体的验证方式（可执行命令，而非“验证可用”）
  • 待修改的文件路径已通过glob验证存在
  • 新文件被明确标记为新增
验证质量：
  • 自动化验证包含可实际运行的命令（如npm test、pytest等）
  • 人工验证有具体步骤，而非模糊检查
可行性：
  • 实施顺序中无循环依赖
  • 设计模式应用于合理场景（而非泛泛的“全场景应用”）
  • 无理想化假设（如“该边缘情况不会发生”） </checklist>
<output-format>

Correctness Check

正确性检查

Internal Contradictions

内部矛盾

  • [Field A] vs [Field B]: [A] says [X] but [B] says [Y]
    • Fix: Reconcile to [recommendation]
  • [字段A] vs [字段B]: [A]说明[X]但[B]说明[Y]
    • 修复方案: 调整为[建议内容]

Tree of Thought Issues

思路树问题

  • Solutions not distinct: [A] and [B] are variations of same approach
    • Fix: Replace [B] with genuinely different architecture
  • Weak winner reasoning: Selection based on preference, not evidence
    • Fix: Add specific research findings supporting choice
  • 方案无明显差异: [A]和[B]是同一方案的变体
    • 修复方案: 将[B]替换为真正不同的架构方案
  • 最优方案理由薄弱: 选择基于偏好而非证据
    • 修复方案: 添加支持该选择的具体研究发现

Implementation Issues

实施问题

  • Step [N]: [Problem - missing validation, wrong order, etc.]
    • Fix: [Specific correction]
  • Vague validation gate: "[gate text]" is not testable
    • Fix: Replace with concrete command: 
      [suggested command]
  • 步骤[编号]: [问题 - 缺失验证、顺序错误等]
    • 修复方案: [具体修正建议]
  • 模糊验证节点: "[节点文本]" 无法测试
    • 修复方案: 替换为具体命令：
      [建议命令]

File Path Issues

文件路径问题

  • [path]: Listed in files-to-modify but does not exist
    • Fix: Correct path or move to files-to-create
  • [路径]: 列入待修改文件列表但不存在
    • 修复方案: 修正路径或移至待创建文件列表

Feasibility Concerns

可行性担忧

  • [Concern]: [Why this might not work]
    • Fix: [How to address]
Correctness Score: [SOUND / MINOR_ISSUES / MAJOR_ISSUES] </output-format> </step>
<step id="5" title="Deliver Review"> <output-format>
  • [担忧点]: [为何可能无法生效]
    • 修复方案: [解决方法]
正确性得分: [合理 / 轻微问题 / 严重问题] </output-format> </step>
<step id="5" title="交付评审结果"> <output-format>

Plan Review: [Task Title]

计划评审：[任务标题]

Summary

摘要

DimensionStatusIssues
Completeness[✅ Complete / ⚠️ Gaps / ❌ Missing Artifacts][N]
Gap Analysis[✅ Clean / ⚠️ Gaps / ❌ Major Gaps][N]
Correctness[✅ Sound / ⚠️ Minor Issues / ❌ Major Issues][N]
Recommendation: [PROCEED / REVISE / RETHINK]
维度状态问题数量
完整性[✅ 完整 / ⚠️ 存在漏洞 / ❌ 缺失工件][N]
漏洞分析[✅ 无问题 / ⚠️ 存在漏洞 / ❌ 严重漏洞][N]
正确性[✅ 合理 / ⚠️ 轻微问题 / ❌ 严重问题][N]
建议: [推进实施 / 修订计划 / 重新规划]

Completeness Check

完整性检查

[From step 2]
[来自步骤2的内容]

Gap Analysis

漏洞分析

[From step 3]
[来自步骤3的内容]

Correctness Check

正确性检查

[From step 4]
[来自步骤4的内容]

Action Items

行动项

Must Fix Before Implement

实施前必须修复

Issues that will cause implementation to fail or produce wrong results
  1. [Issue with specific fix]
会导致实施失败或产出错误结果的问题
  1. [问题及具体修复方案]

Should Address

建议修复

Issues that won't block but will cause problems later
  1. [Issue with specific fix]
不会阻塞实施但会引发后续问题的问题
  1. [问题及具体修复方案]

Consider

优化建议

Improvements that would make the plan better
  1. [Suggestion]
可提升计划质量的改进点
  1. [建议内容]

Next Steps

下一步行动

[If PROCEED]: Ready for 
/apex:implement [identifier]
[If REVISE]: Fix the issues above in this session, then re-run 
/apex:review-plan [identifier]
[If RETHINK]: Fundamental issues found - consider returning to 
/apex:plan [identifier]
to rework architecture </output-format> </step>
</workflow> <classification-rubric> **Must Fix** (blocks implementation): - Missing mandatory artifacts (completeness) - Unaddressed high-impact risks - Fabricated patterns (no source in research) - Uncovered acceptance criteria - File paths that don't exist (listed as modify, not create) - Internal contradictions (metadata vs content) - Vague validation gates with no concrete commands
Should Address (causes problems later):
  • Unaddressed medium-impact risks
  • Documentation drift (docs-to-update not in plan)
  • Unacknowledged contract amendments
  • Weak Tree of Thought (solutions too similar)
  • Chain of Draft shows no real evolution
  • Trust score mismatches
  • NFRs not validated
Consider (improvements):
  • Minor inconsistencies in wording
  • Complexity budget slightly high
  • Could use additional patterns
  • Validation could be more thorough </classification-rubric>
<recommendation-criteria> - **PROCEED**: 0 Must Fix items - **REVISE**: 1-3 Must Fix items (fixable in current session) - **RETHINK**: 4+ Must Fix items OR most key artifacts missing OR fundamental architecture problems (wrong solution chosen, contradicts research) </recommendation-criteria> <success-criteria> - Task file read (regardless of phase) - Missing sections reported as findings, not errors - File existence verified via glob/ls - Completeness check: key artifacts assessed - Gap analysis: risks, security, patterns, docs, ACs, NFRs checked - Correctness check: consistency, validity, feasibility assessed - Classification rubric applied consistently - Clear recommendation with actionable next steps </success-criteria> </skill>
[若建议推进实施]: 可执行
/apex:implement [identifier]
开始实施 [若建议修订计划]: 在此会话中修复上述问题，然后重新运行
/apex:review-plan [identifier]
[若建议重新规划]: 发现根本性问题 - 考虑返回
/apex:plan [identifier]
重新设计架构 </output-format> </step>
</workflow> <classification-rubric> **必须修复**（阻塞实施）： - 缺失必填工件（完整性问题） - 未处理高影响风险 - 虚构模式（无研究来源） - 未覆盖验收标准（AC） - 待修改文件路径不存在（标记为修改而非创建） - 内部矛盾（元数据与内容不符） - 无具体命令的模糊验证节点
建议修复（引发后续问题）：
  • 未处理中等影响风险
  • 文档偏差（需更新文档未纳入计划）
  • 未确认契约修订
  • 思路树薄弱（方案过于相似）
  • 草稿迭代链无实质性演化
  • 信任评分不匹配
  • 非功能需求（NFR）未验证
优化建议（提升计划质量）：
  • 文字表述轻微不一致
  • 复杂度预算略高
  • 可增加更多设计模式
  • 验证可更全面 </classification-rubric>
<recommendation-criteria> - **推进实施**: 0个必须修复项 - **修订计划**: 1-3个必须修复项（可在当前会话中修复） - **重新规划**: 4个及以上必须修复项 或 核心工件缺失 或 根本性架构问题（选定方案错误、与研究矛盾） </recommendation-criteria> <success-criteria> - 已读取任务文件（无论当前阶段） - 缺失板块已作为发现结果上报，未标记为错误 - 已通过glob/ls验证文件存在性 - 完整性检查：已评估核心工件 - 漏洞分析：已检查风险、安全、模式、文档、验收标准（AC）、非功能需求（NFR） - 正确性检查：已评估一致性、有效性、可行性 - 分类规则应用一致 - 提供清晰建议及可落地的下一步行动 </success-criteria> </skill>