task-runner

任务执行器

概述

加载计划，仔细审查，分批执行任务，并在每批之间暂停，等待架构师审查。

核心原则： 分批执行，并设置检查点供架构师监督。

开始时声明：“我正在应用任务执行器技能来执行此实施计划。”

首要原则

NO PLAN EXECUTION WITHOUT CRITICAL REVIEW OF EACH TASK FIRST

不容例外。不走捷径。不耍花招。

计划中可能包含错误、歧义和过时的假设。开始执行前，必须仔细审查每项任务。盲目遵循计划并非“高效”——而是在错误的工作上浪费时间。

适用场景

digraph applicability {
    "Written plan exists?" [shape=diamond];
    "Tasks independent?" [shape=diamond];
    "Human reviews between batches?" [shape=diamond];
    "task-runner" [shape=box];
    "delegated-execution" [shape=box];
    "Manual execution" [shape=box];

    "Written plan exists?" -> "Tasks independent?" [label="yes"];
    "Written plan exists?" -> "Manual execution" [label="no - write plan first"];
    "Tasks independent?" -> "Human reviews between batches?" [label="yes"];
    "Tasks independent?" -> "Manual execution" [label="no - tightly coupled"];
    "Human reviews between batches?" -> "task-runner" [label="yes - architect reviews"];
    "Human reviews between batches?" -> "delegated-execution" [label="no - stay in session"];
}

在以下情况下使用 task-runner：

• 已有书面实施计划（来自 task-planning 或同等来源）
• 任务应分批执行，并在批次之间接受人工审查
• 架构师希望检查进度，并在批次之间进行修正
• 在并行会话中工作（与规划会话分开）

在以下情况下改用 delegated-execution：

• 留在同一会话中（不切换上下文）
• 相较于人工审查，更倾向于自动化的两阶段审查（规格 + 质量）
• 任务彼此独立，可以分派给全新的子 Agent

在以下情况下手动执行：

• 尚无书面计划
• 任务紧密耦合，需要持续的人工指导
• 属于探索性工作，制定计划还为时过早

入场流程

开始执行计划前，请确认以下各项全部满足：

1. 计划存在且可访问——你能找到书面计划文件
2. 计划已仔细审查——你已认真阅读每项任务并标记疑虑
3. 疑虑已解决——问题和歧义都已提出并得到答复
4. 基线测试通过——进行任何更改前，现有测试均已通过
5. 分支干净——在功能分支上工作（不是 main/master），且没有未提交的更改
6. 已配置工作树——使用 git worktree 实现隔离（godmode:workspace-isolation）
7. 任务清单已填充——所有任务都已载入跟踪清单

如果任一项未通过，立即停止。 所有检查项都通过前，不得继续。

认知陷阱

合理化说法	实际情况
“计划看起来没问题，跳过审查吧”	计划中可能有错误。审查能在错误工作浪费时间前发现这些问题。
“我可以边执行边审查”	执行期间审查意味着你已经投入其中。应在开始前审查。
“这项任务不言自明”	看似不言自明的任务也可能隐藏假设。花 30 秒审查，可以避免返工 30 分钟。
“分批太慢了，我一次性全做完”	分批是为了接受人工审查。跳过审查会让错误在所有任务中累积。
“测试太慢了，这轮跳过验证吧”	未验证的批次会掩盖失败。之后调试的代价更高。
“计划要求做 X，但我觉得 Y 更好”	向人类协作者提出这个问题。擅自偏离计划会造成混乱。

流程

步骤 1：加载并审查计划

1. 阅读计划文件
2. 批判性审查——标记每项任务中的问题或疑虑
3. 如有疑虑：开始前向人类协作者提出
4. 如无疑虑：创建任务清单并继续

步骤 2：执行批次

默认批次大小：3 项任务

对每项任务：

1. 标记为进行中
2. 严格遵循每个步骤（计划会提供详细步骤）
3. 按要求运行验证
4. 标记为已完成

步骤 3：报告

批次完成时：

• 展示已实现的内容
• 展示验证输出
• 说：“准备好听取反馈了。”

步骤 4：继续

根据反馈：

• 如有需要，应用更改
• 执行下一批次
• 重复上述流程，直到所有任务完成

步骤 5：收尾

所有任务完成并通过验证后：

• 宣布：“我正在应用 merge-protocol 技能来完成这项工作。”
• 必需的子技能： 使用 godmode:merge-protocol
• 按照该技能验证测试、提供选项并执行所选方案

何时停止并询问

遇到以下情况时，立即停止执行：

• 批量处理中遇到阻碍（缺少依赖项、测试失败、指令不明确）
• 计划存在妨碍启动的关键缺漏
• 你不理解某条指令
• 验证屡次失败

应请求澄清，而不是猜测。

何时重新审视前面的步骤

遇到以下情况时，返回审查（步骤 1）：

• 合作伙伴根据你的反馈更新计划
• 需要重新思考根本方案

不要强行突破阻碍——应停止并询问。

护栏

绝不：

• 执行尚未经过严格审查的任务
• 为了“节省时间”而跳过验证步骤
• 不告知人类合作伙伴就悄悄偏离计划
• 未经用户明确同意就在 main/master 分支上开始实施

始终：

• 在将每项任务标记为 in_progress 前进行审查
• 按计划要求，在每项任务完成后运行验证
• 遇到阻碍时停止并询问（不要猜测或自行其是）
• 汇报已完成的批次，并等待反馈后再继续

批量执行图

digraph batch_flow {
    rankdir=TB;

    gate [label="Entry Protocol\n(all checks pass?)", shape=diamond];
    gate_fail [label="STOP\nResolve before proceeding", shape=box, style=filled, fillcolor="#ffcccc"];
    load [label="Load plan\nBuild task checklist", shape=box];
    review_task [label="Scrutinize next task", shape=box];
    concerns [label="Concerns?", shape=diamond];
    raise [label="Raise with\nhuman partner", shape=box, style=filled, fillcolor="#ffffcc"];
    execute [label="Mark in_progress\nExecute task steps\nRun verifications", shape=box];
    mark_done [label="Mark completed", shape=box];
    batch_done [label="Batch complete?\n(default: 3 tasks)", shape=diamond];
    report [label="Report results\nSay: Ready for feedback", shape=box, style=filled, fillcolor="#ccffcc"];
    feedback [label="Wait for\nhuman feedback", shape=box];
    apply [label="Apply adjustments\nif needed", shape=box];
    more [label="More tasks?", shape=diamond];
    finish [label="Invoke merge-protocol\nskill", shape=box, style=filled, fillcolor="#ccccff"];

    gate -> gate_fail [label="no"];
    gate -> load [label="yes"];
    load -> review_task;
    review_task -> concerns;
    concerns -> raise [label="yes"];
    raise -> review_task [label="resolved"];
    concerns -> execute [label="no"];
    execute -> mark_done;
    mark_done -> batch_done;
    batch_done -> review_task [label="no"];
    batch_done -> report [label="yes"];
    report -> feedback;
    feedback -> apply;
    apply -> more;
    more -> review_task [label="yes - next batch"];
    more -> finish [label="no - all done"];
}

提醒

• 开始前严格审查计划
• 严格遵循计划步骤
• 不要跳过验证
• 计划要求时，参考相关技能
• 批次之间：汇报并等待
• 遇到阻碍时停止，不要猜测
• 未经用户明确同意，绝不在 main/master 上开始实施

关联

必需的工作流技能：

• godmode:workspace-isolation - 必需：开始前设置隔离工作区
• godmode:task-planning - 创建此技能执行的计划
• godmode:merge-protocol - 所有任务完成后完成开发

执行期间，任务可能会调用：

• godmode:test-first - 计划任务涉及编写新代码时
• godmode:fault-diagnosis - 任务遇到意外故障时
• godmode:completion-gate - 汇报前验证每个批次

替代工作流：

• godmode:delegated-execution - 使用此工作流在同一会话中执行，并通过自动化两阶段审查替代人工参与的批次流程