subagent-delegation · v1 · 2026-10-11 · sha256 51f6edc3f5038eb3

subagent-delegation v1A

Immutable. This exact content never changes and is served at /api/v1/blob/51f6edc3f5038eb3.

---
name: subagent-delegation
description: Delegate context-heavy or independently valuable work through compact context packets, reusable workers, and a shared validation ledger. Use only when the user explicitly requests subagents or delegation, or when an explicitly invoked orchestration skill requires it; authorization is not a quota.
metadata:
  author: code-dimension
  version: 1.0
---

# Pragmatic Subagent Delegation

Preserve the coordinator's context without increasing total work unnecessarily.
Delegation is useful only when its benefit exceeds context-transfer,
coordination, and review costs.

## Delegation Is Not A Quota

An explicit request to use subagents authorizes delegation but does not require
delegating every phase. Keep a phase with the coordinator unless at least one
of these advantages is concrete:

- an independent review or perspective is required;
- the phase spans enough files, consumers, or subsystems to materially burden
  the coordinator context;
- an independent context line can run in parallel without overlapping files or
  decisions;
- the worker will be reused for several phases sharing the same domain, files,
  decisions, and validation strategy.

Do not delegate status checks, small preflights, checkbox updates, formatting,
single-purpose command execution, integration, archive, final reconciliation,
or work whose handoff costs as much as doing it locally.

Before spawning, record a compact decision: phase, explicit delegation
advantage, context line, worker, and validation owner. Use a full matrix only
when multiple context lines or dependencies make the decision genuinely hard
to follow.

## Context Lines And Phase Grouping

One context line represents a domain or boundary whose artifacts, decisions,
and validation knowledge remain useful. Reuse its worker while that context is
valid.

Consecutive OpenSpec sections or plan phases may be assigned together when
they share files, decisions, and validation and no intermediate decision can
invalidate the next phase. Section numbers are reporting boundaries, not
automatic subagent turns. Stop between phases only for a blocker, required
independent review, unresolved decision, or real dependency.

Create a new worker when the domain, primary file set, ownership boundary, or
validation strategy changes materially. Never use a new worker merely to run
another command over the same context.

## Context Transfer

Use `fork_turns: "none"` by default. Workers share the filesystem and can read
the authoritative files directly; they should not inherit unrelated tool
outputs or prior discussion.

Use `fork_turns: "all"` only when the conversation is short and contains
essential, unrecorded decisions that cannot be summarized safely. State the
reason before spawning. Do not use it after large tool outputs or long task
history. A short bounded fork is acceptable only when its turns were
deliberately prepared as the context packet.

Before the first spawn, read
[the coordination protocol](references/coordination-protocol.md). Send paths
and decisions, not copied file contents. Include authorization and stop
conditions that exist only in conversation.

## Validation Ownership

Every check has one owner. Pass a compact validation ledger between agents and
reuse valid evidence while its inputs remain unchanged. Do not rerun a green
check merely because ownership changed.

- implementer: focused tests, lint, and invariants for its edits;
- reviewer: fresh analysis plus only the representative check needed to test
  an unsupported claim or risk;
- coordinator: missing integration checks and the final full-workspace gate;
- archive/reconciliation: specification, formatting, and diff hygiene only,
  unless code changed after the final code gate.

Documentation-only edits do not invalidate runtime tests. Invalidate a ledger
entry only when a changed input can affect that check.

## Execution

1. Coordinator resolves ambiguity, authorization, and architectural decisions.
2. Assign one context line with an exact objective, allowed files/tasks,
   required context paths, recorded decisions, stop conditions, and validation
   ownership.
3. Prohibit nested delegation unless independently justified and explicitly
   authorized.
4. Treat the worker's edit scope as exclusive until its final checkpoint.
5. Reuse the same worker through compatible phases without resending known
   context.
6. At completion, inspect the focused changed paths and one risk-relevant
   invariant. Do not repeat the worker's valid checks.
7. Coordinator owns integration, archive, registry reconciliation, and final
   reporting.

Parallelize only context lines with no overlapping files, contracts,
decisions, or pending dependencies.

## OpenSpec

The coordinator performs the initial apply workflow and reads every required
`contextFile`. Delegate implementation only after the change and edit boundary
are known. A worker may cover multiple numbered sections under one context
line when the grouping rule above holds, while reporting each section's task
state separately.

Do not delegate canonical synchronization, archive, parent reconciliation, or
the final integrated verification. A checked task is not validation evidence;
the validation ledger is.