| name | parallel-worktree |
| description | 多任务 work tree 并行执行的编排与执行 skill。用于:(1) 编排模式 - 分析多个任务的文件级冲突,规划并行/串行执行顺序,创建 work tree;(2) 执行模式 - 在 work tree 中读取任务报告并执行。触发词:并行执行、多任务、work tree 并行、任务编排、并行任务、parallel tasks。 |
多任务 Work Tree 并行执行
概述
本 skill 支持两种模式:
- 编排模式:分析任务冲突,规划执行顺序,创建 work tree
- 执行模式:在 work tree 中读取任务报告并执行
用户作为传递员,告知编排端任务完成状态。
模式判断
根据用户意图选择模式:
- 用户说"我要做这些任务" / "并行执行" / "任务编排" → 编排模式
- 用户说"执行这个任务" / "继续执行" / 在 work tree 中 → 执行模式
编排模式
流程
1. 接收任务列表
↓
2. 探索每个任务可能修改的文件(文件级)
↓
3. 评估冲突程度
↓
4. 排序与分组
↓
5. 创建 work tree
↓
6. 生成 TASK_REPORT.md(只写影响范围,不写具体内容)
↓
7. 向用户展示执行计划
步骤 1:接收任务列表
明确每个任务的一句话描述,向用户确认。
步骤 2:探索任务影响范围
对每个任务,必须探索:
输出:每个任务 → 可能修改的文件列表(文件级)
步骤 3:评估冲突程度
根据文件列表判断:
- 无冲突:文件列表完全不重叠
- 低冲突:可能修改同一目录但不同文件
- 高冲突:很可能修改相同文件
步骤 4:排序与分组
- 低冲突任务 → 可并行
- 高冲突任务 → 必须顺序(先完成一个再开始下一个)
输出执行计划:
并行组 1:任务 A、任务 B(低冲突)
顺序组:任务 C → 任务 D(高冲突)
步骤 5:创建 work tree
以当前分支为起点创建:
git worktree add .claude/worktrees/task-{序号}-{功能名} -b task-{序号}-{功能名}
命名规范:task-{序号}-{简短功能名}(如 task-1-group-fork)
步骤 6:生成 TASK_REPORT.md
在每个 work tree 根目录生成 TASK_REPORT.md:
# 任务报告
## 基本信息
- **任务名称**:<标题>
- **Work Tree**:<路径>
- **分支名**:<分支名>
- **冲突等级**:无/低/高
- **可并行任务**:<任务列表>
## 任务目标
<一句话说明要实现什么>
## 可能修改的文件
- `path/to/file1.py`:<预期修改类型>
- `path/to/file2.ts`:<预期修改类型>
## 不可变内容
以下文件在本次任务中不应修改:
- `path/to/unrelated.py`
## 依赖关系
- 依赖任务:<任务名>(如有)
- 被依赖:<任务名>(如有)
重要:只写影响范围,不写具体实现内容。具体内容由用户在执行窗口说明。
步骤 7:展示执行计划
向用户展示:
- 任务分组(并行/串行)
- 每个 work tree 的路径
- 建议的执行顺序
执行模式
流程
1. 读取当前 work tree 下的 TASK_REPORT.md
↓
2. 确认任务目标和影响范围
↓
3. 等待用户说明具体任务内容
↓
4. 执行任务
↓
5. 运行验证
↓
6. 通知用户:任务完成
步骤 1:读取任务报告
读取 TASK_REPORT.md,了解:
步骤 2:确认影响范围
检查当前 work tree 的文件状态,确认报告中的影响范围。
步骤 3:等待用户说明
关键:不在报告中写具体内容,等待用户在执行窗口说明具体要做什么。
步骤 4:执行任务
根据用户说明执行任务,遵守:
- 只修改报告中列出的文件
- 不修改"不可变内容"中的文件
步骤 5:运行验证
运行相关测试、类型检查等。
步骤 6:通知完成
告知用户任务完成,等待下一步指示。
合并策略
当用户告知某些任务完成后:
合并顺序
- 收集完成任务的
TASK_REPORT.md
- 按冲突等级排序:低冲突 → 中冲突 → 高冲突
- 低冲突任务可同时合并
- 高冲突任务逐个合并
合并流程
1. 选择下一个要合并的任务
2. 读取该任务的 TASK_REPORT.md
3. git merge 到主分支
4. 如果有冲突:
a. 读取冲突双方的 TASK_REPORT.md
b. 基于"任务目标"理解意图
c. 基于"不可变内容"保护无关代码
d. 解决冲突
5. 运行测试验证
6. 继续下一个任务
冲突解决原则
- 参考 TASK_REPORT.md 中的"任务目标"理解意图
- "不可变内容"是保护清单
- 无法判断时,询问用户
用户交互示例
编排阶段
用户:我要做这三个任务:群聊 fork、群聊 compact、消息导出
AI:我来分析这三个任务的影响范围...
[探索代码后]
AI:
任务分析结果:
1. 群聊 fork - 可能修改:group_chat.py, group_chat_service.py
2. 群聊 compact - 可能修改:group_chat.py, context_manager.py
3. 消息导出 - 可能修改:message_service.py, export_utils.py
冲突评估:
- 任务 1 和 2:高冲突(都修改 group_chat.py)
- 任务 3:无冲突(独立文件)
执行计划:
- 并行组:任务 3(独立执行)
- 顺序组:任务 1 → 任务 2(高冲突,需顺序)
已创建 3 个 work tree:
- .claude/worktrees/task-1-group-fork
- .claude/worktrees/task-2-group-compact
- .claude/worktrees/task-3-message-export
请先在 task-3 中执行消息导出,同时在 task-1 中执行群聊 fork。
完成后告诉我,我再安排后续。
执行阶段
用户:(在 task-1 work tree 中)执行这个任务
AI:读取 TASK_REPORT.md...
任务:群聊 fork
目标:复制群聊状态创建新群聊
可能修改:group_chat.py, group_chat_service.py
请告诉我具体要怎么实现?
用户:实现一个 fork 方法,复制当前群聊的所有成员和配置...
AI:(执行任务)
任务完成。已修改 group_chat.py 和 group_chat_service.py。
请告知编排端可以合并。
合并阶段
用户:任务 1 和 3 都完成了
AI:检查任务报告...
- 任务 1(群聊 fork):高冲突
- 任务 3(消息导出):无冲突
建议先合并任务 3(无冲突),再合并任务 1。
执行合并...