Delegation is useful when a task has an independent input and a reviewable output. More agents do not automatically mean more progress when they compete for the same files or simulator.

Bounded task → Independent execution → Evidence report → Main-agent integration
  1. 1Bounded task
  2. 2Independent execution
  3. 3Evidence report
  4. 4Main-agent integration

Work through the example

Give the reviewer a diff and an acceptance question. Keep the main agent responsible for resolving disagreements.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

4. Writing the delegation prompt

A subagent starts cold. This is the failure mode that makes delegation look useless: an under-specified prompt produces a confident, irrelevant report.

Every delegation prompt carries:

  1. The goal, as an outcome rather than an activity.
  2. The context it cannot see — decisions already made, constraints, the relevant file paths you already found.
  3. The boundary — what is explicitly out of scope.
  4. The return format — what you need back, and in what shape.
### WEAK
"Look at the networking code."

### STRONG
"Find every place that constructs a URLRequest in Sources/, and report which
ones set an Authorization header and which do not.

Context: we are adding a shared auth interceptor and need to know what would
be duplicated. The APIClient at Sources/Data/APIClient.swift:44 is already
known — I need the ones outside it.

Out of scope: test targets, and anything under Vendor/.

Return: a table of file:line, the endpoint, and whether it sets auth."

The Out of scope line matters more than it looks. Without it, subagents reliably expand the task.

Acceptance and failure review

Checkpoint What to inspect If it does not match
Bounded task Confirm the input and environment Preserve the failure and return to this step
Independent execution Inspect the intermediate artifact Preserve the failure and return to this step
Evidence report Run the focused check Preserve the failure and return to this step
Main-agent integration Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

The repository's available roles are not proof that every role improves every task.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Coordinating parallel coding work with isolated checkouts