review-plan 是一个规划评审关卡技能，定位在规划产物（prd.md / design.md / implement.md）已经存在、但尚未执行 task.py start 的时间点运行。它的目标是在实现开始之前，对规划文档做一次结构化审计，避免两类失败模式：其一，跨文档断连、模糊描述、规范冲突在未被发现的情况下流入实现阶段；其二，使用方对子智能体的误读过度反应，不加判断地接受所有被报告的问题。
用途 该技能用于规划阶段的质量把关。它在实现开始前派发一个子智能体，对规划产物执行四个维度的审查，然后由使用方独立判断子智能体的发现，接受有证据支持的项，驳回误报并给出具体理由。
主要能力与四个评审维度 A. 跨文档断连：检查 prd.md / design.md / implement.md 之间是否存在矛盾，例如 PRD 要求某一项而 design 遗漏、implement 列出了没有 design 依据的步骤、文档之间数值不一致、PRD 验收标准没有对应的 implement 验证步骤。 B. 模糊点：找出会让实现智能体困惑的地方，例如未定义的颜色、尺寸、上限值，写成“X 或 Y”但未做决定的行为，未说明的组件交互，缺失的空、加载、边界状态。 C. 规范冲突：检查 design/PRD 是否与任何规范冲突，例如字体规则、导航规则、状态访问规则、枚举向后兼容规则，以及任何写着 MUST / never / single channel 的规范条目。 D. 架构深度：判断 design.md 描述的是深模块（小接口、大实现）还是浅模块（接口约等于实现）。使用 codebase-design 的词汇：module、interface、depth、seam、locality、leverage、deletion test。检查模块边界是否清晰、接口是否明显小于实现、接缝是否可隔离测试、局部性是否可从一个文件理解一个概念、删除测试是否会让复杂度集中、杠杆是否以小接口产生大功能。对 UI 任务有校准说明：基于区域的 composable 可以合法地拥有更宽的接口，其深度来自职责划分而非单个 composable 的深度；只有当单个 composable 混合了不相关职责，或划分过细导致理解一个区域需要读 3 个以上文件时才应标记。
使用方式 步骤一：收集上下文。在派发前，收集子智能体需要的准确文件路径，包括三个任务产物文档、参考文件（如 UI 任务的设计参考、当前被修改的源码）、相关规范（例如 .trellis/spec/game/*.md，最低包括 theming.md、navigation.md、game-state.md，按需补充领域规范）、架构词汇（加载 codebase-design 技能中的 leading words，子智能体在报告架构深度发现时必须使用这些术语）、流程文档（.trellis/workflow.md）。要求逐项列出绝对路径，不留下“去 spec 目录里找相关文件”这类模糊表述。 步骤二：派发评审子智能体。使用通用子智能体类型，派发提示词有固定结构，包含活动任务路径、任务上下文、要读取的文件列表、四个维度的评审标准。输出为单一结构化报告，使用表格列：#、Severity（HIGH/MED/LOW）、Dimension（A/B/C/D）、Location、Issue；引用具体章节或行号；某个维度没有发现时写 “None found.”。完成标准是子智能体返回覆盖四个维度的报告。 步骤三：独立判断发现。对子智能体报告的每一项发现，使用方要独立判断：亲自阅读被引用的规范或行，不能只信任子智能体的描述；将每项分类为 Accept（确为真实问题，修复）、Reject（自身检查后不准确，写一行理由，例如早于本任务存在、子智能体误读规范、超出本任务范围）、Defer（真实但属于其他任务或阶段）。关键驳回信号包括：信任边界混淆（把内部数据当成不可信外部输入）、忽略设计注释（把注释中有意为之的行为当成缺陷）、变量误读（未追溯到变量定义）。完成标准是每项发现都有基于证据而非主观意见的判定和一行理由。 步骤四：修复被接受的发现。对每项被接受的发现，编辑规划文档以弥补缺口，优先使用编辑工具做定向字符串替换。优先级为 HIGH（规范冲突）优先，其次 MED（实现智能体会猜错的模糊点），最后 LOW（次要润色）。全部修复后做最终交叉核对，确认被修改的关键决定在文档之间不再互相矛盾。
适用场景 在规划产物已经产出、任务尚未开始实现的关卡处使用，用于审查规划质量，尤其适合存在多份规划文档、跨文档一致性要求高、有明确规范约束、以及对架构深度有要求的设计。
限制 该技能的介绍中未提供关于收费、价格、平台、具体效果或其它未提及的功能。所有使用步骤与评审维度均以资料所载为准，资料未涉及的内容暂未提供。