Delegate

Delegate

Parallel execution coordinator. Read a plan or conversation context, decompose it into a dependency-ordered task graph, and spawn worker sub-agents in parallel waves. Each wave completes before the next begins. Results are collected, validated, and reported.

Core principle: dependency order is absolute. Size each task for usefulness, not for a worker count.

When a worker is justified

> Use a worker only when the task is self-contained and gains from parallelism, > isolated context, restricted tools, or containment of verbose disposable output. > Keep judgment in the active session when phases share substantial context or require > iterative refinement; keep coupled implementation with one continuing worker.

A worker is a bounded execution context, not a project role. The active coding agent is the runtime and stays the owner of the work; skills — /architect, /spec, /audit, /retro — are how it adopts a role. The active session acts as advisor: it keeps goal interpretation, architecture, decomposition, verification, and acceptance, and it assigns bounded implementation to workers. Delegation buys isolation, parallelism, and bounded implementation, and nothing else.

| Assign it to a worker | Keep it in the active session | |---|---| | Tracked implementation edits: code, tests, docs, integration fixes, repair | Goal interpretation, architecture, decomposition, verification, acceptance | | Coupled implementation, in one continuing worker | Reconciliation of results that share substantial context | | Independent parallel research or source sweeps | Iterative refinement against operator feedback | | Verbose disposable output — logs, search dumps, test runs | A result you would have to re-derive to use | | Disjoint file ownership with no shared mutable state | The second of two tasks that touch the same file, until the first completes | | A deliberate tool or permission restriction | Task state: prd.json, progress.txt, and acceptance records |

A small task can use one worker; parallelism is not mandatory. A factual question or a plan-only request needs no worker: loading this skill, writing a plan, or finishing a plan authorizes no dispatch and creates no execution state. Do not invent named architectural roles for workers. /delegate owns fan-out policy; other skills must not grow a competing worker hierarchy beside it.

Complexity classification

Classify each subtask by uncertainty, blast radius, security exposure, reversibility, context requirements, and acceptance clarity. Line count alone does not determine complexity. Mechanical work has known transformations and decisive checks. Ambiguous requirements, cross-boundary changes, migrations, and uncertain debugging warrant stronger reasoning before a worker writes. The advisor resolves architecture; even a high-capability worker receives bounded implementation scope, never an instruction to redesign the architecture.

Coupled implementation stays with one continuing worker. Use the provider's native continuation when it exists; otherwise checkpoint the artifacts and rebrief the next bounded worker with only the incomplete scope. Never replay completed work. Parallel writers get isolated worktrees. Serialize shared-file work. Workers stay flat unless the recursion-authorization gate in step 5 authorizes recursion.

Worker model and reasoning policy

Apply this policy to every worker:

1. Explicit operator selections and exclusions are binding. Pass a selected model

unchanged; never dispatch to an excluded model.

1. Select unspecified settings per task. Choose the model and reasoning setting

from the task's complexity, risk, and the authorized budget. Record the selection reason in the dispatch record before dispatch.

1. Perform a native capability check first. Before the first dispatch, confirm

which model and reasoning controls the running provider's worker tool exposes. Record the requested settings and the observed settings separately, each with its provenance. An unknown value stays unknown; never record it as confirmed or zero. A display name or an accepted request does not prove the effective configuration.

1. An unsupported required control blocks. When a required model or reasoning

control is unavailable, mark the affected worker and its dependents BLOCKED and ask the operator for an authorized alternative. Never substitute a model, lower a setting, change shared or parent settings, or call a nested inference CLI to obtain the control.

1. Escalate reasoning only on evidence. Raise a worker's reasoning setting only

when evidence shows uncertainty or repeated failure, never because a tool or a credential is missing.

1. Stop at the declared budget. When a task reaches its declared budget, stop and

ask the operator; do not retry indefinitely.

Provider-specific preferences (Claude Code)

The preferences below are operator preferences, not the portable role definition. Each one requires native verification before use.

• The advisor session runs on Fable 5.1 with the operator-selected effort.
• A low-complexity worker runs on Opus.
• The advisor judges the effort level for each worker task: low for mechanical work,

medium for standard work, high or xhigh for high-uncertainty work, never max. Record the selected effort and its reason in the dispatch record before dispatch.

• Never route work to Sonnet, as a primary, intermediate, or fallback tier.
• Select the hardest worker per task from supported non-Sonnet models; record the

selection reason.

• On a native surface that exposes them, Luna at Max serves the least complex work and

Astra at high serves the hardest work.

The per-call Agent tool on Claude Code exposes model and has no effort argument. The documented per-worker effort control is subagent definition frontmatter (effort: low|medium|high|xhigh|max; never pass max), hot-reloaded from a subagent definition at the scope the operator chooses. Apply the selected effort through that control when one exists, after native verification. When no per-worker control is available at dispatch time, the worker runs at the inherited session effort and the record says so: observed effort: inherited session level, unobserved. Confirm an effective effort only from the runtime's own display or the worker's self-report; never assume it from the request. Effort is an advisor judgment, so a missing effort control never blocks a worker and never justifies a model substitution. Rule 4 applies to the model, to explicit operator selections and exclusions, and to any control the operator marks required.

Decision Flow

flowchart TD
    A["Resolve input: $ARGUMENTS or conversation context"] --> B{Plan found?}
    B -->|No| FAIL["Report: no plan found, then stop"]

    B -->|Yes| C["Step 2: Deep-think task decomposition"]
    C --> D["Step 3: Build dependency graph"]
    D --> F{--dry-run?}
    F -->|Yes| DRY["Step 7: report the task graph and wave plan, then stop: no file written, no worker dispatched, no execution state"]

    F -->|No| E["Step 4: Write run ledger to .agro/tasks/"]
    E --> G["Step 5: Execute Wave N"]
    G --> G1["Worker A"]
    G --> G2["Worker B"]
    G --> G3["Worker C"]
    G1 & G2 & G3 --> H{"accepted by the advisor?"}
    H -->|No| I["Mark dependents BLOCKED, route repair, continue independent"]
    I --> J{More waves?}
    H -->|Yes| J
    J -->|Yes| G
    J -->|No| K["Step 6: Validate the integrated result"]
    K --> L["Step 7: Report"]

Instructions

1. Resolve input

Arguments received: $ARGUMENTS

• If --plan is provided, read that file
• If no arguments, use the current conversation context (the plan should be visible

from a prior /prd, plan discussion, or issue triage output)

• If --dry-run is present, set DRY_RUN=true

If no plan is found in either source, report: > No plan found. Provide a plan file path with --plan or discuss the plan first, then run /delegate.

Then stop. This path writes no file, dispatches no worker, and creates no execution state.

2. Decompose into tasks (reason according to complexity)

Analyze the plan deeply and produce a structured task list. Each task is one dispatch record with every field below; a record with a missing field is not ready to dispatch.

| Field | Description | |-------|-------------| | ID | Sequential: T1, T2, T3, ... | | Title | Short imperative description | | Description | What the worker agent needs to do (2-3 sentences, include file paths) | | Depends On | Task IDs this requires first, or "none" | | Complexity | The classification from Complexity classification, with the deciding factors | | Selection reason | Why the requested model and reasoning fit this task, recorded before dispatch | | Requested model / reasoning | The exact model and reasoning setting requested, or inherit when the operator selected no preference for this class | | Observed settings + provenance | The effective model and reasoning setting the native surface reported, each with its source; unknown when unobserved | | Read scope | Files and directories the worker reads | | Search / output limits | The search breadth and the output volume the worker stays inside, so verbose disposable output stays bounded | | Owned write paths | The only paths the worker edits | | Exclusions | Paths, actions, and settings the worker must not touch | | Execution directory | The absolute directory the worker runs in | | Worktree isolation | The isolated worktree for a parallel writer, or the reason a serialized worker shares one | | Worker type | The provider built-in subagent_type | | Continuation method | Native continuation, or checkpoint-and-rebrief with the checkpoint artifacts | | Deliverable | The concrete artifact, patch, or commit the worker returns | | Verification | Commands or exact review procedure, with expected results | | Stopping condition | The observable state at which the worker stops and reports, including the blocked case | | Evidence destinations | The paths that receive outputs, logs, and artifacts | | Covered DoD IDs | The Definition of Done criteria this task covers | | Acceptance owner | The advisor; a worker never accepts its own result | | Failure / repair route | Which worker repairs a failed check, and what returns to the advisor | | Native worker ID | Assigned at dispatch | | Status | The advisor's record, never a worker's claim: pending/running/completed/FAIL/BLOCKED. completed means the advisor accepted the artifacts | | Artifact references | Paths, commits, or logs the worker produced | | Usage | Token or cost usage when the provider reports it; otherwise unknown |

Decomposition rules:

• Each task must be completable by a single sub-agent in one session
• Complexity, briefing overhead, shared context, and verification cost decide a useful task boundary; a further split is not a default, and one continuing bounded worker is a valid answer
• Schema/infrastructure before backend, backend before frontend
• Tasks that touch different files with no shared state CAN be parallel
• Tasks that modify the same file or depend on another's output MUST be sequential
• Every task must have at least one verifiable acceptance criterion
• Each task must have a distinct, non-overlapping scope — do not spawn redundant workers for the same files
• A task must not say only "implement the plan"; it names its owned write paths and covered DoD IDs
• A read-only worker never owns write paths
• A task that is itself multi-step and parallelizable MAY recursively delegate via the Agent tool — but only if the worker's task description includes explicit Max depth: N and Step budget: N fields (see Recursion-authorization gate in step 5). Absent those fields, workers stay flat.

3. Build dependency graph and compute waves

Arrange tasks into parallel execution waves using topological ordering:

1. Wave 1: All tasks with Depends On: none -- run first, in parallel
2. Wave 2: All tasks whose dependencies are entirely within Wave 1
3. Wave N: All tasks whose dependencies are entirely within Waves 1..N-1

Output the wave plan:

| Wave | Tasks | Parallelism | Complexity | |------|-------|-------------|------------| | 1 | T1, T2, T3 | 3 agents | S + S + M | | 2 | T4, T5 | 2 agents | M + S | | 3 | T6 | 1 agent | L |

Validation:

• No circular dependencies (if found, report error and stop)
• Max 5 concurrent agents per wave (split larger waves into sub-waves)

4. Write the run ledger

The task graph is durable state, not conversation state. A delegation outlives a context window: /spec execute compacts mid-build, sessions die, and another agent can pick up the worktree. Write the graph to disk before spawning any worker.

Resolve the run directory as .agro/tasks//:

• Invoked inside a /spec execute task (a --plan path under .agro/tasks//,

or that folder is the current task): reuse that ``.

• Otherwise: delegate--, created if absent.

Write two files, both owned by this skill:

| File | Contents | |------|----------| | delegate-graph.json | Every task's complete dispatch record from step 2, its assigned wave, and its status (pending/running/completed/FAIL/BLOCKED) | | delegate-log.txt | Append-only run log; one line per wave boundary, per status change, per capability check, and per blocked control |

Never write prd.json or progress.txt. Those belong to the implementation owner (.agro/tasks/README.md), and progress.txt in particular must not be edited by hand. This skill's two files sit beside them without collision.

Both live under .agro/tasks/, which is gitignored — that is correct for run state. Stage them with git add -f only when a PR must carry the delegation as evidence.

Dispatch eligibility applies to initial and resumed runs. Before any dispatch, re-evaluate the task against the current graph, artifacts, and native capabilities. A task is eligible only when all of these conditions hold:

• all blocking prerequisites in the plan and dispatch record are satisfied;
• every Depends On task is recorded completed, its accepted evidence still

describes the required artifact revision, and that evidence has established provenance;

• every required model, control, and capability is available; and
• no unresolved native worker status, artifact provenance, or owned-path ambiguity

remains.

A pending, FAIL, or BLOCKED label does not itself authorize dispatch. If every condition holds, dispatch only the incomplete authorized scope and record running before the worker starts. If any condition remains unmet, record or keep BLOCKED, log each unmet condition, and dispatch nothing. Never infer eligibility from pending alone or from only some accepted dependencies.

Resume rather than restart. If delegate-graph.json already exists in the resolved directory, read it first and reconcile every task against real state before any dispatch.

• pending: apply the dispatch-eligibility conditions. Do not release it from the

label alone.

• BLOCKED: re-evaluate every recorded blocking condition, including all dependencies

and required controls. It remains BLOCKED while any condition is unmet and becomes eligible only after every condition holds.

• FAIL: read the failed task's current artifacts before any retry, apply the

dispatch-eligibility conditions, then route only the incomplete scope through the existing failure / repair route. Never replay work that is already correct.

• running: inspect the persisted native worker reference and the current artifacts

before any retry. While the worker is still active, reconnect to it or observe it through the supported native mechanism, and never

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mifunedev
• Source: mifunedev/agro
• License: Apache-2.0
• Homepage: https://agro.mifune.dev

Install and usage instructions live in the source repository linked above.