st-execute-task

st-execute-task

关键规则

1. 保持状态准确——在整个执行生命周期中更新任务状态。
2. 记录执行情况——记录所有结果和遇到的问题。

输入

用户会在对话中提供数字计划 ID 和任务 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. 验证任务文件

查找 <plan-dir>/tasks/<task-id>--*.md，然后查找带零填充的 <plan-dir>/tasks/0<task-id>--*.md。如果两者都未匹配，则列出 <plan-dir>/tasks/ 中的文件并停止。将匹配项作为 <task-file>。

4. 检查任务状态

读取 <task-file> frontmatter 中的 status。

• 如果是 completed、in-progress 或 needs-clarification：停止，并说明如何继续（通过 execute-blueprint 重新执行已完成的任务；先回答未解决的澄清问题）。
• 如果是 pending 或 failed：执行。
• 如果缺失或无法识别：谨慎继续，并注明存在歧义。

5. 验证依赖项

运行 scripts/check-task-dependencies.cjs <plan-id> <task-id>。如果该命令以状态码 1 退出，请停止并说明未解决的依赖项阻碍了任务。满足依赖项前不要继续。

6. 选择 Agent

读取 <root>/config/hooks/PRE_TASK_ASSIGNMENT.md，并遵循其中的说明为该任务选择合适的 Agent 或技能集。

7. 将状态更新为进行中

重写 <task-file> 的 YAML frontmatter，将 status 设为 "in-progress"。其他 frontmatter 字段一律保持原样。

8. 执行任务

部署任何 Agent 之前，先解析路由；解析不会启动任何任务 工作：

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

外部执行使用：

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。
external-override	使用返回的 handoff 运行 execute 命令，然后按照同一张表解读其结果。
fallback	未启动任何任务。明确记录返回的 reason 和 detail，然后原生派发，不附带任何执行设置说明。
launched-success	外部进程已正常退出。不要原生派发；像检查原生 Agent 一样检查状态和证据。
launched-failure	任务失败。将其状态设为 failed，并运行 <root>/config/hooks/POST_ERROR_DETECTION.md。绝不要改用原生派发重试。
infrastructure-failure	严格按照上一行处理。

交接规则：

• 对该任务使用解析器返回的确切不透明 handoff 字符串。绝不要重新构造。
• 绝不要将一个任务的 handoff 用于其他任务，也绝不要在开始启动任务后重新解析路由。

第 9–11 步是此技能处理失败状态和错误钩子的流程。

若要原生派发，请使用内部 Task 工具部署 Agent。该 Agent 必须先读取并执行 <root>/config/hooks/PRE_TASK_EXECUTION.md，再进行任何实现工作；随后读取完整的 <task-file> 并完成实现。 不要运行 scripts/check-for-updates.cjs；委派的工作者不会接收更新通知。

9. 将状态更新为 completed 或 failed

Agent 完成后，根据结果重写 <task-file> 的 YAML frontmatter：

• 如果任务已成功实现且满足所有验收标准，则设置 status: "completed"。
• 如果任务无法完成、未满足验收标准，或发生不可恢复的错误，则设置 status: "failed"。

原样保留所有其他 frontmatter 字段。

10. 记录值得注意的事件

如果执行期间发生任何重大事项——例如作出的决定、遇到的问题、偏离计划的情况或需要采取的后续行动——请在 <task-file> 末尾追加一个“值得注意的事件”部分：

## Noteworthy Events
- [YYYY-MM-DD] [Event description with sufficient context for the orchestrator]

11. 错误处理

如果执行期间发生任何错误，请读取 <root>/config/hooks/POST_ERROR_DETECTION.md 并执行其中的说明。 在“值得注意的事件”中记录错误，并确保任务状态设为 failed（如果尚未设置）。

当保留的更新 notice 存在时，请将该确切句子追加在结构化摘要块之后；如果此技能未输出摘要块，则追加在最终回复之后。该通知之后不得有任何内容。

失败模式

• 执行错误。 如果任务失败，请读取 <root>/config/hooks/POST_ERROR_DETECTION.md，在“值得注意的事件”中记录错误，并确保任务状态设为 failed。