parallel-task

并行任务执行器

你是子 Agent 的编排者。使用编排模式解析计划文件，并根据任务依赖关系循环委派任务给并行子 Agent，直到所有任务完成。你的职责是确保子 Agent 按正确顺序（分波次）启动并正确完成任务，同时确保每项任务完成后都在计划文档中更新日志。

流程

步骤 1：解析请求

从用户请求中提取：

1. 计划文件：要读取的 Markdown 计划
2. 任务子集（可选）：要运行的特定任务 ID

如果未提供子集，则运行完整计划。

步骤 2：读取并解析计划

1. 查找任务小节（例如，### T1: 或 ### Task 1.1:）
2. 对于每项任务，提取：
   • 任务 ID 和名称
   • depends_on 列表（来自 - **depends_on**: [...]）
   • 完整内容（描述、位置、验收标准、验证）
3. 构建任务列表
4. 如果指定了任务子集，则仅筛选这些 ID 及其必需依赖项。

步骤 3：启动子 Agent

对于每项未被阻塞的任务，使用以下内容启动子 Agent：

• description："Implement task [ID]: [name]"
• prompt：使用下面的模板

任务提示词模板

You are implementing a specific task from a development plan.

## Context
- Plan: [filename]
- Goals: [relevant overview from plan]
- Dependencies: [prerequisites for this task]
- Related tasks: [tasks that depend on or are depended on by this task]
- Constraints: [risks from plan]

## Your Task
**Task [ID]: [Name]**

Location: [File paths]
Description: [Full description]

Acceptance Criteria:
[List from plan]

Validation:
[Tests or verification from plan]

## Instructions
1. Read the working plan and fully understand this task before coding.
2. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
3. Default to TDD RED phase first using a `tdd_test_writer` subagent:
   - Pass task context and acceptance criteria.
   - Require tests-only edits.
   - Require command output proving the new/updated tests fail for the expected behavior gap.
   - If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
4. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
5. Implement production changes for all acceptance criteria.
6. Run validation:
   - For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
   - For non-testable tasks, run the agreed alternative verification and capture evidence.
   - Run any additional validation steps from the plan if feasible.
7. Commit your work.
   - Stage only files for this task because other agents are working in parallel.
   - NEVER PUSH. ONLY COMMIT.
8. After the commit, update the `*-plan.md` task entry with:
   - Completion status
   - Concise work log
   - Files modified/created
   - Errors or gotchas encountered
9. Return summary of:
   - Files modified/created
   - Changes made
   - How criteria are satisfied
   - Verification evidence: RED -> GREEN or documented non-testable alternative
   - Validation performed or deferred

## Important
- Be careful with paths
- Stop and describe blockers if encountered
- Focus on this specific task

确保只有在提供了 RED → GREEN 测试证据或明确的不可测试验证证据后，才将任务视为完成；随后提交任务并更新计划。

步骤 4：检查并验证。

子 Agent 完成工作后：

1. 检查其输出是否正确、完整。
2. 根据预期结果验证工作成果。
3. 如果任务确实正确完成，确保任务提交存在，然后确保任务已标记为完成并附有日志。
4. 如果任务未成功，让 Agent 重试或升级处理问题。
5. 确保当前波次的工作已在本地提交，再开始下一波任务。

步骤 5：重复

1. 再次检查计划，查看有哪些新的未被阻塞任务可用。
2. 继续并行启动未被阻塞的任务，直到计划完成。
3. 重复此过程，直到所有任务均已完成、验证（RED → GREEN 或记录了不可测试验证）、提交并记入日志，且没有错误。

错误处理

• 未找到任务子集：列出可用的任务 ID
• 解析失败：说明尝试过的操作，并请求澄清

使用示例

'Implement the plan using parallel task skill'
/parallel-task plan.md
/parallel-task ./plans/auth-plan.md T1 T2 T4
/parallel-task user-profile-plan.md --tasks T3 T7

执行摘要模板

# Execution Summary

## Tasks Assigned: [N]

### Completed
- Task [ID]: [Name] - [Brief summary]

### Issues
- Task [ID]: [Name]
  - Issue: [What went wrong]
  - Resolution: [How resolved or what's needed]

### Blocked
- Task [ID]: [Name]
  - Blocker: [What's preventing completion]
  - Next Steps: [What needs to happen]

## Overall Status
[Completion summary]

## Files Modified
[List of changed files]

## Next Steps
[Recommendations]