Execute pending Claude Code Tasks in dependency order with wave-based concurrent execution and adaptive verification. Supports task group filtering and configurable parallelism. Use when user says "execute tasks", "run tasks", "start execution", "work on tasks", or wants to execute generated tasks autonomously.
Executes Claude Code tasks autonomously with dependency-aware parallel processing and adaptive verification.
/plugin marketplace add sequenzia/agent-alchemy/plugin install agent-alchemy-sdd-tools@agent-alchemyThis skill is limited to using the following tools:
references/execution-workflow.mdreferences/orchestration.mdreferences/verification-patterns.mdscripts/poll-for-results.shThis skill orchestrates autonomous task execution for Claude Code Tasks. It builds a dependency-aware execution plan, launches a dedicated agent for each task through a 4-phase workflow (Understand, Implement, Verify, Complete), handles retries with failure context, and shares learnings across tasks through a shared execution context file.
Never write code without first understanding:
Match the codebase's established patterns:
Do not assume implementation is correct. Verify by:
Produce accurate verification results:
This skill orchestrates task execution through a 10-step loop. See references/orchestration.md for the full detailed procedure.
Retrieve all tasks via TaskList. If a --task-group argument was provided, filter tasks to only those with matching metadata.task_group. If a specific task-id argument was provided, validate it exists.
Handle edge cases: empty list, all completed, specific task blocked, no unblocked tasks, circular dependencies.
Resolve max_parallel setting using precedence: --max-parallel CLI arg > .claude/agent-alchemy.local.md setting > default 5. Build a dependency graph from pending tasks. Assign tasks to waves using topological levels: Wave 1 = no dependencies, Wave 2 = depends on Wave 1 tasks, etc. Sort within waves by priority (critical > high > medium > low > unprioritized), break ties by "unblocks most others." Cap each wave at max_parallel tasks.
Read .claude/agent-alchemy.local.md if it exists for execution preferences, including max_parallel setting. CLI --max-parallel argument takes precedence over the settings file value.
Generate a task_execution_id using three-tier resolution: (1) if --task-group provided → {task_group}-{YYYYMMDD}-{HHMMSS}, (2) else if all open tasks share the same metadata.task_group → {task_group}-{YYYYMMDD}-{HHMMSS}, (3) else → exec-session-{YYYYMMDD}-{HHMMSS}. Clean any stale __live_session__/ files by archiving them to .claude/sessions/interrupted-{YYYYMMDD}-{HHMMSS}/, resetting any in_progress tasks from the interrupted session back to pending. Check for and enforce the concurrency guard via .lock file. Create .claude/sessions/__live_session__/ directory containing:
execution_plan.md — saved execution plan from Step 5execution_context.md — initialized with standard templatetask_log.md — initialized with table headers (Task ID, Subject, Status, Attempts, Duration, Token Usage)tasks/ — subdirectory for archiving completed task filesprogress.md — initialized with status template for real-time progress trackingexecution_pointer.md at ~/.claude/tasks/{CLAUDE_CODE_TASK_LIST_ID}/ — created immediately with absolute path to .claude/sessions/__live_session__/Display the plan showing tasks to execute, blocked tasks, and completed count. Also display the details of step 5 which includes the session directory path (.claude/sessions/__live_session__/) and files created, including the execution pointer file location.
Then ask the user to confirm before proceeding with execution. If the user cancels, stop without modifying any tasks.
Read .claude/sessions/__live_session__/execution_context.md (created in Step 5). If a prior execution context exists, look in .claude/sessions/ for the most recent timestamped subfolder and merge relevant learnings into the new one.
Execute tasks in waves. For each wave: snapshot execution_context.md, mark wave tasks in_progress, update progress.md with all active tasks, launch up to max_parallel background agents simultaneously via parallel Task tool calls with run_in_background: true, recording the {task_list_id → background_task_id} mapping from each Task tool response. Each agent writes to context-task-{id}.md and a compact result-task-{id}.md (completion signal). The orchestrator polls for result files via the poll-for-results.sh script in multi-round Bash invocations (each with timeout: 480000), logging progress between rounds, then batch-reads results to process outcomes — avoiding full agent output in context. After polling, the orchestrator calls TaskOutput on each background task_id to reap the process and extract per-task duration_ms and total_tokens usage metadata for the task log. If TaskOutput times out (agent stuck), TaskStop is called to force-terminate the agent. Failed tasks with retries remaining are re-launched as background agents (same TaskOutput reaping after retry polling). After all wave agents complete: merge per-task context files into execution_context.md, clean up result and context files, archive completed task JSONs, refresh TaskList for newly unblocked tasks, form next wave, repeat.
Display execution results with pass/fail counts, total execution time (sum of per-task duration_ms), failed task list, newly unblocked tasks, and total token usage (sum of per-task total_tokens captured via TaskOutput). Save session_summary.md to .claude/sessions/__live_session__/. Archive the session by moving all contents from __live_session__/ to .claude/sessions/{task_execution_id}/, leaving __live_session__/ as an empty directory. execution_pointer.md stays pointing to __live_session__/.
Review execution context for project-wide changes (new patterns, dependencies, commands, structure changes, design decisions). Make targeted edits to CLAUDE.md if meaningful changes occurred. Skip if only task-specific or internal implementation details.
Determine whether a task is spec-generated or general to select the right verification approach.
**Acceptance Criteria:** with categorized criteria (_Functional:_, _Edge Cases:_, etc.)metadata.spec_path fieldSource: {path} Section {number} in the descriptionIf any check matches -> spec-generated task (use criterion-based verification)
If none match -> General task (use inferred verification)
Each task is executed by the agent-alchemy-sdd:task-executor agent through these phases:
Load context and understand scope before writing code.
.claude/sessions/__live_session__/execution_context.md for learnings from prior tasksTaskGetCLAUDE.md for project conventionsExecute the code changes following project patterns.
Verify implementation against task requirements using the adaptive approach.
Report results and share learnings.
completed via TaskUpdatein_progress for the orchestrator to decide on retry.claude/sessions/__live_session__/context-task-{id}.md (files discovered, patterns learned, issues encountered).claude/sessions/__live_session__/result-task-{id}.md (status, verification summary, files modified, issues) — this is the last file written and signals completion to the orchestratorDONE: [{id}] {subject} - {PASS|PARTIAL|FAIL}Verification adapts based on task type:
| Task Type | Verification Method | Pass Threshold |
|---|---|---|
| spec-generated | Criterion-by-criterion evaluation | All Functional + Tests must pass |
| General | Inferred checklist from description | Core change works + Tests pass |
Critical rule: All Functional criteria must pass for a PASS result. Edge Cases, Error Handling, and Performance failures result in PARTIAL but do not block completion.
Tasks within an execution session share learnings through .claude/sessions/__live_session__/execution_context.md:
execution_context.md, task_log.md, progress.md) use Write (full file replacement) via a read-modify-write pattern, never Edit. This ensures atomic, reliable updates regardless of file size.execution_context.md before launching each wave — all agents in a wave read the same baselinecontext-task-{id}.md instead of the shared file, regardless of max_parallel setting. This eliminates write contention and avoids fragile Edit operations on shared files.result-task-{id}.md (~18 lines) as its very last action. The orchestrator polls for these files and reads them instead of consuming full agent output, reducing context consumption by ~79% per wave.context-task-{id}.md content to the ## Task History section of execution_context.md and deletes the per-task files. Result files for PASS tasks are also deleted; FAIL result files are retained for post-analysis.This enables later tasks to benefit from earlier discoveries and retry attempts to learn from previous failures.
run_in_background: true), returning ~3 lines (task_id + output_file) instead of ~100+ lines of full output. This reduces orchestrator context consumption by ~79% per wave.TaskOutput on each background task_id to reap the process and extract per-task duration_ms and total_tokens usage metadata. If TaskOutput times out, TaskStop force-terminates the stuck agent. This prevents lingering background processes.result-task-{id}.md (~18 lines) as its very last action. The orchestrator polls for these files via poll-for-results.sh in multi-round Bash invocations (each with timeout: 480000), with progress output between rounds, then batch-reads them for processing. The result file doubles as a completion signal.task_log.md and progress.md, all updates are batched into a single read-modify-write cycle per file per wave.max_parallel concurrent agents per wave. Tasks in later waves wait until their dependencies in earlier waves complete.context-task-{id}.md regardless of max_parallel setting. The orchestrator merges these after each wave. This eliminates write contention and fragile Edit operations on shared files.poll-for-results.sh pattern as initial wave polling).--max-parallel argument or .claude/agent-alchemy.local.md settings. Set to 1 for sequential execution.retries argument.in_progress (not completed), and execution continues.execution_context.md and write learnings to per-task context files. The orchestrator appends per-task content to the Task History section between waves.TaskOutput to capture diagnostic output..lock file in __live_session__/ prevents concurrent invocations.in_progress are automatically reset to pending./agent-alchemy-sdd:execute-tasks
/agent-alchemy-sdd:execute-tasks 5
/agent-alchemy-sdd:execute-tasks --retries 1
/agent-alchemy-sdd:execute-tasks 5 --retries 5
/agent-alchemy-sdd:execute-tasks --task-group user-authentication
/agent-alchemy-sdd:execute-tasks --task-group payments --retries 1
/agent-alchemy-sdd:execute-tasks --max-parallel 2
/agent-alchemy-sdd:execute-tasks --max-parallel 1
/agent-alchemy-sdd:execute-tasks --task-group payments --max-parallel 3 --retries 1
references/orchestration.md - 10-step orchestration loop with execution plan, retry handling, and session summaryreferences/execution-workflow.md - Detailed phase-by-phase procedures for the 4-phase workflowreferences/verification-patterns.md - Task classification, criterion verification, pass/fail rules, and failure reporting formatActivates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.
Search, retrieve, and install Agent Skills from the prompts.chat registry using MCP tools. Use when the user asks to find skills, browse skill catalogs, install a skill for Claude, or extend Claude's capabilities with reusable AI agent components.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.