plan-founder-review

此技能用于以阅读为主的计划审计工作流。以下规则不可妥协： 1. 阅读完整的计划 Markdown 和配套 JSON（如果存在）。 2. 对照实际代码库核实计划中的说法，不要轻信计划文本。 3. 质疑缺失依赖、虚构路径、不实的复用声明和语义缺口。 4. 完成所需的审查部分后，才能给出结论。 5. 调用内容应聚焦于审查循环；从参考文件中加载详细检查项和结论规则。

创始人审查

输入

• $request：可选的计划名称、计划直接路径或模式覆盖选项，例如 auth-system、.ulpi/plans/foo.md、--quick 或 foo --full。

目标

在 Agent 执行计划之前发现计划缺陷：虚构文件路径、Markdown/JSON 不一致、隐藏的前置条件、糟糕的任务边界、不安全的重写、缺失的测试，以及过度乐观的执行图。

步骤 0：确定目标计划和审查模式

定位要审查的计划：

• 如果 $request 指定了计划名称，则解析为 .ulpi/plans/<name>.md
• 如果 $request 提供了直接路径，则使用该路径
• 如果未提供目标，则选择 .ulpi/plans/ 下最近修改的 .md 计划

然后：

• 阅读完整的 Markdown 计划
• 阅读配套的 JSON 文件（如果存在）
• 提取标题、模式、任务数量、任务 ID、文件路径和依赖摘要
• 确定审查模式为 FULL 还是 QUICK

加载 references/review-rubric.md，了解：

• 模式选择规则
• 各模式的章节要求
• 结论标准

遇到以下情况时提前停止：

• 不存在计划
• 无法读取 Markdown 计划
• 审查目标太小，不适合正式的创始人审查，应直接执行

成功标准：在开始详细审查前，明确目标计划和审查模式。

步骤 1：核查代码库实际情况

对照实际代码库核实计划：

• 每个 filesToModify 路径都存在
• 每个 filesToCreate 路径都有有效的父路径或先行创建该路径的任务
• Markdown 和 JSON 在任务 ID、文件路径和执行含义上保持一致
• 声称复用的内容在本地确实存在
• 计划没有重复构建已有功能
• 如果计划引入公共 SQL、API 或 CLI 接口，则计划明确给出实际签名或示例，而不是含糊带过

加载 references/review-checklist.md，并完整完成第 1 节。

成功标准：已对照代码库核实计划中的文件路径、复用声明和产物一致性。

步骤 2：质疑范围和策略

审查：

• 计划模式是否符合实际范围
• 每项任务是否都服务于既定目标
• 非目标是否可信
• 发布范围是否切实可行
• 是否存在隐藏的前置条件或范围蔓延

加载 references/review-checklist.md，并完成第 2 节。

成功标准：范围、模式和最低可交付版本均有充分依据。

步骤 3：审计架构、契约和依赖

审查：

• 架构图是否完整
• 任务与架构图是否一致
• 生产者与消费者之间的契约是否清晰
• 依赖 JSON 是否切合实际
• 执行摘要是否一致
• 共享接线点的负责人是否明确，例如路由器、注册表、清单、启动钩子或导出入口
• 重写、规划器、优化器、筛选器或查询组合的语义安全性

加载 references/review-checklist.md，并完成第 3 节。

如果审查模式为 QUICK，则在此步骤后直接跳至步骤 6。

成功标准：计划的架构和依赖关系清晰且可执行。

步骤 4：审计风险、恢复和降级模式安全性

仅适用于 FULL 审查，需质疑：

• 对故障模式的覆盖情况
• 缓解措施的质量
• 回滚或遏制策略
• 降级模式语义
• 对格式错误的输出或上游故障的处理

加载 references/review-checklist.md，并完成第 4 节。

成功标准：关键风险都有可执行的缓解措施，而非含糊的警告。

步骤 5：审查测试覆盖范围和执行可行性

仅针对 FULL 审查，检查以下方面：

• 测试覆盖映射是否完整
• 测试类型是否恰当
• 验收标准是否覆盖边缘情况
• 是否覆盖安全敏感路径
• DAG 效率
• Agent 匹配情况
• 工作量评估是否合理
• P0 基础是否如实说明
• 写入范围冲突或隐性重叠

加载 references/review-checklist.md 并完成第 5 和第 6 部分。

成功标准：计划可测试、可执行，且不存在明显的约束过度或规范不足。

步骤 6：评估各部分并给出结论

使用 references/review-rubric.md：

• 将每个受审查部分评为 PASS、WARN 或 FAIL
• 将发现分类为 BLOCK、CONCERN 或 OBSERVATION
• 确定结论为 APPROVE、REVISE 或 REJECT

随后生成简洁的创始人审查报告，其中包括：

• 计划标题和模式
• 结论
• 各部分摘要表
• 阻塞问题
• 疑虑
• 观察结果
• 需要修订时建议的计划变更

审查结束时不要向用户提出流程性问题。提交审查结果，并由主线程决定后续处理方式。

成功标准：结论直接依据有证据支持的发现和评审标准得出。

护栏

• 不要将计划文件作为此技能的一部分进行修改。
• 不要对非简单计划敷衍通过。
• 不要凭空编造发现；没有问题的部分可以正常通过。
• 不要添加 disable-model-invocation；用户要求审查计划时，此技能应仍可调用。
• 不要添加 paths:；这是通用审查工作流。
• 不要在 SKILL.md 中内嵌冗长示例、质量评分卡或门槛表。
• 不要用 AskUserQuestion 代替审查结论。
• 不要忘记，此技能最适合在独立推理预算下，以分叉审查工作流运行。

何时加载参考资料

• references/personality.md 在会话开始时加载，用于了解审查角色、特征和沟通风格。

• references/review-checklist.md 用于逐部分审查检查项和证据要求。

• references/review-rubric.md 用于确定模式、结论规则、部分评分以及发现分类（BLOCK/CONCERN/OBSERVATION 门槛表）。

输出约定

报告：

1. 受审查的计划和选定模式
2. 结论
3. 各部分状态摘要
4. 阻塞问题
5. 疑虑
6. 观察结果
7. 适用时要求进行的计划变更