st-execute-blueprint

st-execute-blueprint

输入

用户会在对话中提供数字计划 ID。

操作流程

1. 定位 strikethroo 根目录

在用户的工作目录中运行 scripts/find-strikethroo-root.cjs。如果该脚本以非零状态码退出，则停止并请用户运行 npx strikethroo init。

将其打印的路径视为后续每个步骤中的 <root>。

委派执行的工作器跳过此步骤，且不发送更新通知。

使用此技能的脚本路径，单独运行 scripts/check-for-updates.cjs "<root>" 命令。保持用户的工作目录不变。读取标准输出中的那一行 JSON。如果存在 notice，则在最终面向用户的回复中保留其原文。绝不暂停等待许可，也绝不运行更新。

2. 解析计划

运行 scripts/validate-plan-blueprint.cjs <plan-id> planFile，获取计划文件的绝对路径。输入其他字段名则会打印该字段。

如果脚本以非零状态码退出，则停止并请用户确认计划 ID。不要猜测其他 ID。

运行 scripts/validate-plan-blueprint.cjs <plan-id> planDir，并将打印的路径视为 <plan-dir>。

3. 验证任务和蓝图是否存在

运行 scripts/validate-plan-blueprint.cjs <plan-id> taskCount 和 scripts/validate-plan-blueprint.cjs <plan-id> blueprintExists。

4. 缺少任务或蓝图时自动生成

如果 taskCount 为 0，或 blueprintExists 为 no：

通知用户：“未找到任务或执行蓝图。正在自动生成任务……”

• 按照 st-generate-tasks 技能为此计划 ID 执行完整操作流程，包括运行 POST_TASK_GENERATION_ALL.md 以编写执行蓝图。
• 重新运行 planFile、planDir、taskCount 和 blueprintExists 查询，以刷新解析出的路径和计数。

如果计划仍然没有任务或蓝图，则停止并报告失败。

5. 可选：创建功能分支

在阶段执行前运行一次 scripts/create-feature-branch.cjs <plan-id>。跳过不算失败。继续使用当前分支，绝不要手动创建分支。未提交或未跟踪的更改仅允许出现在仓库根目录下的 .ai/strikethroo 子树中。发生错误时停止执行并报告。

然后运行一次 scripts/capture-base-commit.cjs <plan-id>，记录评审关卡用于生成差异的提交。结果为 skipped 时继续执行，这意味着评审关卡将跳过。只有结果为 error 时才停止。

6. 加载项目上下文和执行蓝图

按顺序读取以下文件：

• <root>/config/STRIKETHROO.md
• 步骤 2 中路径所指向的计划文档，包括其中定义阶段分组和任务分派顺序的“执行蓝图”部分。
• <root>/config/shared/verification-gate.md 和 <root>/config/shared/anti-rationalization.md，两者均应用于下方的阶段循环。

7. 按顺序执行阶段

使用内部任务或待办事项跟踪器监控进度。针对执行蓝图中定义的每个阶段：

7a. 阶段执行前

运行 scripts/check-phase-readiness.cjs <plan-id> <phase-number>。如果脚本以非零状态码退出，则暂停该阶段，并在继续前报告阻塞问题。

读取 <root>/config/hooks/PRE_PHASE.md，并在开始阶段前执行其中的说明。

7b. 任务分派

找出此阶段中依赖项已全部满足的所有计划任务。读取 <root>/config/hooks/PRE_TASK_ASSIGNMENT.md，并按照其中的说明选择 Agent，然后再分派任务。

先解析每个选定任务的执行路线。对每个选定任务各调用一个解析器，并在一次并行工具操作中同时调用：

scripts/dispatch-task-execution.cjs resolve <task-file> <current-harness> <workspace> <plan-id> <task-id>

解析器不会启动外部进程。解读所有路线结果后，在一次并行工具操作中同时启动所有外部执行和所有子 Agent。外部执行使用：

scripts/dispatch-task-execution.cjs execute <handoff> <task-file> <current-harness> <workspace> <plan-id> <task-id>

<current-harness> 是运行此技能的、确切受支持的 harness 标识符；<workspace> 是项目工作目录。

解读单行 JSON 结果，并严格按照 kind 执行对应操作，且只执行一次：

kind	必须执行的操作
native-default	以原生方式分派，不附带任何执行设置说明。
native-override	以原生方式分派，并明确要求使用返回的确切 model。仅当存在 reasoningEffort 属性时，才要求使用返回的 reasoningEffort。
external-override	使用返回的 handoff 运行 execute 命令，然后根据同一张表解读其结果。
fallback	未启动任何进程。清楚记录返回的 reason 和 detail，然后以原生方式分派，不附带任何执行设置说明。
launched-success	外部进程已正常退出，退出代码为零。不要以原生方式分派；像审核原生 Agent 一样审核状态和证据。
launched-failure	任务失败。将其状态设为 failed，并运行 <root>/config/hooks/POST_ERROR_DETECTION.md。绝不要以原生方式重试。
infrastructure-failure	严格按照上一行处理。

交接规则：

• 对每个任务，传递解析器返回的确切不透明 handoff 字符串。绝不要重新构造。
• 绝不要将某个任务的 handoff 用于其他任务，也绝不要在启动后重新运行解析。
• 同时部署所有剩余的原生子 Agent。每个子 Agent 必须先读取并执行 <root>/config/hooks/PRE_TASK_EXECUTION.md，然后才能开展任何实现工作；随后执行任务并更新其状态。不要运行 scripts/check-for-updates.cjs；受委派的工作进程不会读取更新通知。

7c. 阶段完成验证

确保阶段中的每项任务状态均为 completed，并收集其输出。不要将子 Agent 的成功报告视为证明。将证据关卡应用于 <root>/config/shared/verification-gate.md，然后再将阶段标记为完成。

7d. 阶段执行后

读取 <root>/config/hooks/POST_PHASE.md 并执行其中的说明。此钩子成功之前，不要进入下一阶段。

将计划中 Execution Blueprint 部分的阶段状态更新为 completed。

对下一阶段重复上述步骤，直到所有阶段完成。

将 <root>/config/shared/anti-rationalization.md 应用于此合理化表：

你发现自己在想……	约束规则
“子 Agent 报告成功了，所以任务完成了。”	报告只是一个说法，不是证据。将证据关卡应用于阶段，然后再将阶段标记为完成。
“测试应该能通过。”	“应该”是一个危险信号。运行验证命令，检查其输出和退出代码，然后说明结果。
“我会在下一阶段之后再验证。”	只有在通过已验证证据成功执行 POST_PHASE.md 后，阶段才算完成。现在就验证；不要在阶段未经验证时继续推进。

8. 执行后验证

读取 <root>/config/hooks/POST_EXECUTION.md 并执行其中的说明。如果验证失败，则停止执行。计划保留在 plans/ 中以供调试。

在宣布执行完成之前，将证据关卡应用于计划的 Success Criteria 和 Self Validation 步骤。

运行代码审查门禁

POST_EXECUTION.md 报告通过后，遵循 st-code-review 技能并运行其捆绑机制：

code-review.cjs <plan-id> <current-harness>

从 st-code-review 技能的同级 scripts 目录解析 code-review.cjs，并传入运行此技能的确切受支持的 harness 标识符。如果未安装 st-code-review 技能，请在执行摘要中记录这一结果，然后继续生成摘要并归档。

按以下顺序处理它在 stdout 上打印的那一行 JSON：

1. 将其原样复制到执行摘要的审查结果中。不要重新格式化，也不要省略字段。将 codeReview 原样复制到终端的 Code Review 条目中。
2. 按照顶层 action 执行。如果值为 halt，则停止，报告顶层 detail，并输出包含审查结果的终端 Execution Summary。如果值为 continue，则继续生成执行摘要并归档。
3. 仅当 verdict.kind 为 review-recorded 时，才读取 <plan-dir>/review/review.xml 和 <plan-dir>/review/findings.json，然后决定要处理哪些发现。severity 和 confidence 是参考标签，不是指令。

绝不能将未经认证的审查报告为通过。

硬性规则：

• 审查只运行一次。不要为了检查修复而重新运行门禁。
• 检测使用审查者路径。每项修复都通过实施者路径分派；审查者不负责修复其发现的问题。
• 进行任何修复后，必须完整重新运行 POST_EXECUTION.md，然后才能宣布执行完成。此前的通过结果不再适用。

9. 追加执行摘要

在计划文档中追加一个执行摘要部分，填写 <root>/config/templates/EXECUTION_SUMMARY_TEMPLATE.md 中的每个字段。根据结果的 codeReview 字段添加 Code Review 条目；如果未生成结果，则填写 Failed，并说明原因。在 Noteworthy Events 下，始终原样记录门禁输出的 JSON 行，然后说明处理了哪些发现、忽略了哪些发现及其原因。

10. 归档计划

将已完成的计划目录从 <root>/plans/<plan-folder> 移至 <root>/archive/<plan-folder>，并保留完整的文件夹结构。如果移动失败，记录错误，但不要因此判定整体执行失败。

失败模式

• 执行错误。 如果任务失败，请阅读 <root>/config/hooks/POST_ERROR_DETECTION.md，在 Noteworthy Events 中记录错误，暂停此阶段，并在继续前请求用户指示。

执行摘要

以且仅以此代码块结束（如有保留的更新通知，则另行附在其后）：

---
Execution Summary:
- Plan ID: [numeric-id]
- Status: [Archived or Halted]
- Location: [absolute path to current plan directory]
- Code Review: [codeReview from the review result, or Failed with the reason no result was produced]
---

即使审查门禁暂停执行，也要输出此代码块。使用实际状态和位置；暂停后绝不能声称已归档。复制 codeReview 时，不得省略 harness、模型信息或拒绝原因。已处理的发现不会将 Address 变为 Pass，因为审查不会重新运行。如果执行在审查前停止，请报告 Failed，并附上“Review was not run”和阻止继续的原因。

下游自动化会处理此摘要；请保持格式完全一致。

如果存在保留的更新 notice，请在结构化摘要代码块之后，或在此技能未输出摘要代码块时于最终回复之后，追加该原句。通知之后不得有任何内容。