Execution agent

flowchart LR
  Triggers@{ shape: bolt, label: "Triggers" }
  ExecutionAgent["Execution agent"]

  Triggers --triggers--> ExecutionAgent

  class Triggers triggersOrange
  class ExecutionAgent executionBlue

  classDef triggersOrange fill:#ffe8d4,stroke:#d66a28,color:#d66a28
  classDef executionBlue fill:#cfe8ff,stroke:#0366d6,color:#0366d6

The Execution agent reads a task spec and implements the code. It handles two scenarios depending on whether the task has a parent feature: tasks under a feature auto-merge to the feature branch; orphan tasks require human review before merging to main.

Type: LLM (Claude)
Script: .autoducks/agents/execution/pre.sh + post.sh

Triggers

Event	Condition
Issue comment	/agents execute on a non-Feature issue
Workflow dispatch	issue_number + base_branch (dispatched by the Wave Orchestrator)

Scenarios

Scenario A — Orphan task

An orphan task has no parent feature issue. The PR targets main and requires human review.

Pre-execution

1. Reacts to the trigger comment with 👀.
2. BASE_BRANCH defaults to the configured base branch (e.g., main). No feature number is extracted.
3. Generates a slug from the issue number and title.
4. Creates a task branch from main: feature/0-issue-{issue_num}-{timestamp}.
5. Writes the issue spec (title + body) to /tmp/task-spec.md.

LLM execution

The agent reads /tmp/task-spec.md and implements the task using Write, Edit, and Bash (local changes only — no git or API calls).

Post-execution

7. assert_changes validates the agent produced changes. On failure: notifies and exits with 😕 reaction.
8. Commits and pushes changes.
9. Creates a PR targeting main titled Task #N: {title} with body fixes #N.
10. No auto-merge — PR requires human review.
11. Reacts with 👍 and posts a comment confirming PR creation.

Scenario B — Feature task

A feature task has a BASE_BRANCH pointing to a feature/* branch. The PR auto-merges.

Pre-execution

1. Reacts to the trigger comment with 👀.
2. Extracts the feature number from BASE_BRANCH via regex feature/([0-9]+).
3. Waits for the feature branch to be visible (handles replication lag after branch creation).
4. Generates a slug and creates a task branch from the feature branch: feature/{feature_num}-issue-{issue_num}-{timestamp}.
5. Writes the issue spec to /tmp/task-spec.md.

LLM execution

Same as Scenario A — reads the spec and implements the code.

Post-execution

7. assert_changes validates changes. On failure: notifies on both the task and parent feature issue.
8. Commits and pushes changes.
9. Creates a PR targeting the feature branch titled Task #N: {title} with body fixes #N.
10. Auto-merges with rebase retry (up to 3 attempts). On merge conflict: rebases onto the feature branch and force-pushes with lease. On persistent failure: notifies and exits.
11. Triggers the wave orchestrator to continue (non-fatal — the PR merge event is the primary trigger).
12. Reacts with 👍 and posts a comment confirming PR creation.

Branch naming

Scenario	Pattern	Example
Orphan task	feature/0-issue-{num}-{timestamp}	feature/0-issue-99-1735000000
Feature task	feature/{feature_num}-issue-{task_num}-{timestamp}	feature/42-issue-43-1735000000

Required permissions

permissions:
  contents: write
  issues: write
  pull-requests: write
  actions: write
  id-token: write

Directive arguments

When triggered by a comment, you can override model settings:

/agents execute --model claude-opus-4-7 --reasoning high

When dispatched by the Wave Orchestrator, WORKER_MODEL and WORKER_REASONING are passed as workflow inputs.

Note

The execution agent only writes code — it cannot push to git or call GitHub APIs. All git and API operations happen in the pre.sh and post.sh wrapper scripts. This keeps the LLM’s blast radius limited to file changes.