task-orchestration

Files (1)

• SKILL.md

SKILL.md (first lines)

# 任务编排元技能

本技能用于实施规划，先确认用户已要求代码实施。原因排查和方案交付使用 analysis 契约，不为只读调查创建虚构实施项。新 implementation 契约可用 `plan` 原子登记完整计划。默认主会话；只有真实并行、上下文隔离或独立核对等明确收益时才提供 `delegation_benefit`。以下旧任务操作继续兼容，不能把 independent 标签直接当作必须委派。

把需求和架构决定拆成按实现先后推进的步骤。每步写清依赖、预期代码或文档产物、完成判据及交接给下一步的内容；先实现基础能力，再实现依赖它的能力。拆分服务于正确推进，不按人员或分支数量机械分包。使用 `dev_task record` 写入 `task-plan` 产物，`steps` 每项单独起行并以稳定 ID 开头（例如 `- I1 数据模型`、`- I2 服务实现`），再用 `dev_task items` 按同样的 ID 和顺序登记全部实施项。进入代码开发前会核对两边的 ID，遗漏项不能静默消失。

交接给代码开发：有序任务清单、依赖关系、每步完成定义。负责人和分支仅在用户或团队配置要求时记录。

每项同时交付实现与其完成前必需的回归测试。不要把必要单测拆到依赖本项 done 的后续项，避免“实现等测试、测试等实现完成”的循环。跨项联调放在测试阶段。登记实施项后，用 plan_verification 声明各组真实测试命令、生产/测试/配置输入 files 和所属 item_ids，再为所有实施项记录执行策略；派发前检查 status.verification_planning.blockers。

登记实施项后，对每项调用 `dev_task plan_execution`，提供 `item_id`、`task_boundary`、`files`、`acceptance`、`depends_on` 和说明事实的 `execution_reason`。不要等用户提醒“使用子代理”；默认省略 `execution`，由引擎按边界、上下文需要和宿主实际能力选方式。局部小改选 `local`；输入/输出、允许修改范围和验收明确、可在接口稳定后独立完成的工作选 `independent`；需要反复联动同一组实现细节选 `coupled`。有依赖不等于不能委派：通过 `depends_on` 排在前置项完成后。不要为凑子代理数量拆任务，也不要把所有工作笼统归为耦合。

发生委派时默认使用独立上下文；只有本项确需继承已完成轮次的讨论时才传 `context_need=history`，并在原因中解释。新契约没有明确 delegation_benefit 时 auto 留在主会话，旧契约保持原路由。工具返回实际能力、选择理由及审核方式；宿主无对应能力时自动选择会明确回退主会话。所有实施项都要有策略记录才可离开编排；无需让用户逐项指定。

所有交付文件及对应测试必须归属到实施项计划，派发前会检查是否遗漏。很短且当前会话可直接验证的独立项，可显式选 execution=direct，并说明委派成本与收益；不要把“文件独立”直接等同于“必须启动子代理”。

执行计划的 files 是本项负责修改和交付的范围；测试计划的 files 还包含只读依赖。不要因测试读取共同配置，就把未修改的 package.json、锁文件或构建配置登记为多项共同交付物。配置需要修改时明确交付归属；共同交付会扩大返工范围，共同只读输入则在内容变化时使相关验证失效。

计划删除/重命名文件时，实施前在 plan_execution 的 changes 声明 `{path,kind:"delete"}` 或 `{path,kind:"rename",to}`，旧路径及目标都保留在 files。引擎捕获 Git 与已有未提交文本的变更前快照，供只读审核核对；不能把已删路径移出范围来消除报错。二进制或没有可核对基线时按返回的阻塞处理。发现风险上升用 set_risk 升级后重新读取 status，按更新后的审核策略重新验收已打开项，不必重做未变化且仍有效的实现/测试。

如果团队已有经确认的外部实施清单，核对其需求编号和实现先后，在 `task-plan` 的对应实施项记录来源编号；`dev_task items` 始终是本次实施进度的唯一台账。没有外部清单时直接按已确认需求编排。影响分析给出需要回归的接口、页面、数据及外部协同，供测试阶段使用。

From godv61/dsh-task-engine, MIT.

More from godv61/dsh-task-engine