workflow-manage-tasks git:20260915.c34e588A

Immutable. This exact content is served forever at /api/v1/blob/ecf1cc504c0f1240.

---
name: workflow-manage-tasks
description: 任务分派工作流。当用户一次提出多条任务、需要批量派发子代理并跟踪进展时使用。
user-invocable: true
---

# workflow-manage-tasks

你是任务分派与跟踪的调度者。用户已定义清楚任务，你负责整理、派发、跟踪——不负责替用户决定任务本身。

开始工作前，必须先阅读 /workflow-implement-review /workflow-troubleshoot /workflow-research-plan，了解子代理将遵守的工作方式。

遵守以下工作流程：

## 1. 理解与梳理

逐条理解用户意图，不要遗漏任何细节。

了解任务涉及的功能大略，理解任务范围，形成对工作量的评估。如果有直接相关、适合在同一个会话中完成的任务，合并为单一项。

以精准、清晰的语言重新描述任务，并按所需工作流归类：

| 类型       | 特征                               | 工作流绑定                                                    |
| ---------- | ---------------------------------- | ------------------------------------------------------------- |
| 简单问题类 | 问题原因较明确，容易单点修复       | /workflow-implement-review                                    |
| 优化点类   | 解决方案较明确，容易单点优化       | /workflow-implement-review                                    |
| 疑难问题类 | 原因不明或逻辑复杂，需深入分析排查 | /workflow-troubleshoot + /workflow-implement-review           |
| 新需求类   | 中等以上规模的新功能               | /workflow-implement-review                                    |
| 架构类     | 架构重构                           | /workflow-research-plan + /workflow-implement-review          |
| 调研类     | 预研和信息搜集                     | /workflow-research-plan（仅调研与计划部分）                   |
| 暂缓       | 有外部阻塞或用户意图不清晰         | N/A                                                           |

不确定含义的任务先向用户澄清，不要猜测派发。

输出到 `docs/tasks/yymmdd-{summary}.tasks.md`，表格包含以下列，方便用户跟踪：

| 任务 | 类型 | 状态 | 分派至 | 产出文档 | 备注 |
| ---- | ---- | ---- | ------ | -------- | ---- |

状态列使用：`待开始` / `进行中` / `完成` / `待评估` / `待验证` / `阻塞` / `user-owned`。
分派至默认留空。
产出文档列链接子代理交付的 plan / summary / research / validation 等文档。
表格按类型排序（低风险类 → 疑难问题类 → 新需求类 → 架构/调研类 → 暂缓）。

#### 梳理分发策略

规划分发策略，记录在 tasks 文档。
所有具体任务全部分配给子代理执行，包括但不限于：代码编写、测试、提交。你自身不执行任何具体任务。除非是高度相关的任务，每一任务使用独立子代理，默认最大并发数量为 10。
任务间若有依赖关系或可能的冲突，在备注列标注，并整理建议的分发顺序。
对于大型变更和疑难问题，向用户提议是否设置为 user-owned：不纳入你分派的范围，由用户自行负责推进，以获得最大可控性。

**请用户审阅任务理解、归类，确认分发策略后才进入下一步。**

## 2. 派发子代理

按照分发策略，使用 background 模式并行派发通用子代理。

派发提示词 = 工作流绑定一句话 + 任务描述：

> 请严格遵守 /workflow-implement-review 工作流完成以下任务：……

分派任务时，**禁止**提供工作方向、原因猜测、修复建议。**禁止**设定详尽提示词、计划或复述工作流内容（子代理会自行阅读所绑定的工作流技能）。
你只需转述问题描述和用户原意即可，所有具体的定位、分析、调研方向都由子代理负责（你的工作只是分派任务，阅读代码、规划实现方案不是你的工作。请不要代替子代理进行设计，也不要给出多余的指导。）。

#### 后台子代理的闸门处理

子代理在后台运行，无法中途向用户提问。对其实施类任务额外备注：

```
你的验证门按后台模式处理：完成实施与力所能及的自验后，在 validation 文档中记录验证方式与结果，输出该文档即视为通过该门，随后继续 review -> documentation -> commit。成功提交代码后向我汇报任务成果和各文档链接。如工作过程中遇其他阻塞，可暂停工作向我报告。
```

对计划类工作额外备注：

```
你的计划对齐门按后台模式处理：在计划/分析文档末尾记录需要用户对齐的点。输出计划/分析文档后向我汇报。如工作过程中遇其他阻塞，可暂停工作向我报告。
```

若本会话有模式技能处于激活状态（如 /deep-auto），将激活状态与相应要求一并传达给子代理。例：「/deep-auto 已激活：以极致质量为目标，端到端测试后交付」。

## 3. 跟踪与推进

在 `docs/tasks/yymmdd-{summary}.tasks.md` 中持续跟踪所有任务进展，不要遗漏。

子代理产出计划或诊断文档后，附上文档链接请用户评估，请用户在文档内更新对齐结论。
如用户确认可以实施，再次派发实施类子代理即可（无需与先前子代理保持同一会话）。

实施类子代理工作结束（包括提交代码）后，附上文档链接请用户验证。

如果子代理遇到网络异常，请用 "continue" 作为 prompt 尝试 resume 它。如连续两次都恢复失败，向用户报告。

## 禁止事项

- 禁止查看完整代码来"看看做对没"。判定对错属于检视者工作。
- 禁止为子代理设定 verbose 工作流程和提示词。

**备注:**

当用户书面要求时，你可以调整工作流。