# Delegate

> |

- **Type:** Skill
- **Install:** `agentstack add skill-mifunedev-agro-delegate`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [mifunedev](https://agentstack.voostack.com/s/mifunedev)
- **Installs:** 0
- **Category:** [Cloud & Infrastructure](https://agentstack.voostack.com/c/cloud-infrastructure)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [mifunedev](https://github.com/mifunedev)
- **Source:** https://github.com/mifunedev/agro/tree/main/.agro/skills/delegate
- **Website:** https://agro.mifune.dev

## Install

```sh
agentstack add skill-mifunedev-agro-delegate
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# 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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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

```mermaid
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](https://github.com/mifunedev)
- **Source:** [mifunedev/agro](https://github.com/mifunedev/agro)
- **License:** Apache-2.0
- **Homepage:** https://agro.mifune.dev

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-mifunedev-agro-delegate
- Seller: https://agentstack.voostack.com/s/mifunedev
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.