Delegate

Use sub-agents when they can do focused work in parallel while the parent keeps architectural judgment, integration, and final verification.

Keep vs Delegate

Keep in the parent:

• Understanding the user's actual request and constraints
• Architecture, security, product, and release-risk decisions
• Cross-module integration
• Final review, test interpretation, and user-facing summary

Delegate to sub-agents:

• Read-only exploration over a bounded file set
• Mechanical edits with a clear file ownership boundary
• Focused test or lint runs
• Boilerplate generation from an explicit spec
• Independent checks that can run while parent work continues

Do not delegate tiny one-step tasks, ambiguous product decisions, destructive operations without a clear acceptance criterion, or final verification.

Launch Focused Work

Use agent for a focused child run. Launch independent children together so they can run in parallel.

Prefer provider-neutral model_strength over hardcoded model ids. Children inherit the active model by default (model_strength: "same"), including type: "scout", so pass model_strength: "faster" explicitly to get the cheaper same-family sibling for read-only exploration:

{
  "name": "config_audit",
  "prompt": "Inspect crates/tui/src/config.rs and crates/tui/src/settings.rs for duplicate model-default logic. Return file/line findings only; do not edit files.",
  "type": "scout",
  "model_strength": "faster",
  "cwd": "."
}

For code changes, give the child a precise write boundary and tell it not to revert unrelated edits. Keep implementation children capable with model_strength: "same":

{
  "name": "docs_patch",
  "prompt": "Update only docs/configuration.md to document the new [statusline] keys. Match the surrounding style. Do not edit other files.",
  "type": "builder",
  "model_strength": "same",
  "cwd": "."
}

Use fork_context: true only when the child genuinely needs the current conversation prefix. Leave it omitted for fresh, narrower context.

Evaluate and Verify

Sub-agent outputs are self-reports. Re-check material claims before relying on them:

• Read changed files directly.
• Run the relevant tests locally.
• Inspect unexpected diffs before committing.
• Verify externally visible or destructive claims against source data.

Prompt Shape

A good delegation prompt includes:

• The exact task
• Files or modules owned by the child
• Files or behavior the child must not touch
• Expected output format
• Acceptance criteria

Weak prompt:

Fix the settings bug.

Strong prompt:

Own only crates/tui/src/settings.rs and its tests. Preserve existing config key names. Add a regression test showing that provider-specific API key changes do not restart provider onboarding. Return the changed paths and test command output.