Parallel Task

am-will/codex-skills/skills/parallel-task

作者 am-will9f954c3b63fda0d1875252009c196bf15072c1ca無授權條款1K 個星標收錄於 2026年10月9日更新於 2026年10月9日儲存庫2 個月前更新

Only to be triggered by explicit /parallel-task commands.

僅含說明AI & Agents

AI 產生的概覽

依 markdown 計畫協調平行子代理，按相依性分批啟動可執行任務，直到全部完成。

功能: 把 markdown 計畫檔案解析為任務，取出任務 ID、名稱、depends_on 清單、驗收條件與驗證步驟，也可依要求只篩選指定任務子集。它用固定的子代理提示範本平行啟動所有已解除阻塞的任務，接著檢查並驗證每個結果，要求提供 RED 到 GREEN 的測試證據或已記錄的非可測試驗證，任務才算完成。它也會確保每個任務在本機提交，並把完成狀態、工作日誌、變更檔案與遇到的問題寫回計畫檔案，循環推進各批次直到計畫完成。最後輸出執行摘要，列出已完成、有問題與被阻塞的任務。
適用情境: 適用於已有開發計畫檔案，希望由子代理在遵守相依關係的前提下平行執行其中任務的情況。它由明確的 /parallel-task 指令觸發，可附上計畫路徑與指定任務 ID。適合每個任務都能獨立驗證並提交的多任務計畫。
執行需求: 此技能不附帶指令碼，僅為指示。它依賴代理的子代理協調能力、包含任務小節與 depends_on 清單的 markdown 計畫檔案，以及能讀寫檔案、執行測試並在本機提交的子代理。未說明需要憑證或網路存取。

Parallel Task Executor

You are an Orchestrator for subagents. Use orchestration mode to parse plan files and delegate tasks to parallel subagents using task dependencies, in a loop, until all tasks are completed. Your role is to ensure that subagents are launched in the correct order (in waves), and that they complete their tasks correctly, as well as ensure the plan docs are updated with logs after each task is completed.

Process

Step 1: Parse Request

Extract from user request:

Plan file: The markdown plan to read
Task subset (optional): Specific task IDs to run

If no subset provided, run the full plan.

Step 2: Read & Parse Plan

Find task subsections (e.g., ### T1: or ### Task 1.1:)
For each task, extract:
- Task ID and name
- depends_on list (from - **depends_on**: [...])
- Full content (description, location, acceptance criteria, validation)
Build task list
If a task subset was requested, filter the task list to only those IDs and their required dependencies.

Step 3: Launch Subagents

For each unblocked task, launch subagent with:

description: "Implement task [ID]: [name]"
prompt: Use template below

Launch all unblocked tasks in parallel. A task is unblocked if all IDs in its depends_on list are complete.

Task Prompt Template

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]
## Instructions1. 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 encountered9. 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

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]
## Instructions1. 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 encountered9. 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

Ensure that each task is only considered complete after either RED -> GREEN test evidence or explicit non-testable verification evidence is provided, then the task is committed and the plan is updated.

Step 4: Check and Validate.

After subagents complete their work:

Inspect their outputs for correctness and completeness.
Validate the results against the expected outcomes.
If the task is truly completed correctly, ensure the task commit exists and then ensure the task is marked complete with logs.
If a task was not successful, have the agent retry or escalate the issue.
Ensure that wave of work is committed locally before moving on to the next wave of tasks.

Step 5: Repeat

Review the plan again to see what new set of unblocked tasks are available.
Continue launching unblocked tasks in parallel until plan is done.
Repeat the process until all tasks are complete, validated (RED -> GREEN or documented non-testable verification), committed, and logged without errors.

Error Handling

Task subset not found: List available task IDs
Parse failure: Show what was tried, ask for clarification

Example Usage

'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

'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 Template

markdown

# 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]

# 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]

來源與署名

來源：am-will/codex-skills位於skills/parallel-task提交9f954c3

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

Parallel Task

Parallel Task Executor

Process

Step 1: Parse Request

Step 2: Read & Parse Plan

Step 3: Launch Subagents

Task Prompt Template

Step 4: Check and Validate.

Step 5: Repeat

Error Handling

Example Usage

Execution Summary Template

來源與署名

更多來自 am-will/codex-skills 的技能

Vercel React Best Practices

Role Creator

Swarm Planner

Super Swarm Spark

Plan Harder

Planner

更多AI & Agents技能

Discernment Nudge

Ppt Template Creator

Skill Development

Plugin Structure

Command Development

Claude Md Improver