bounded-delegation git:20261101.cb769e1A

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

---
name: bounded-delegation
description: Delegate bounded factual file analysis or reference-based code and test generation through available workers, with explicit ownership, limits, and acceptance checks. Use when a narrow read or predictable generation task benefits from offloading. Not a default for every coding task, open-ended diagnosis, general context management, or installing a routing service.
---

# Bounded delegation

Own the assignment and return protocol for narrow reading and predictable
generation. The responsible agent retains the surrounding decisions and
acceptance. This is a process overlay, not a worker runtime or permission gate.

## Choose the execution path

Start with the available project tools. Targeted search, partial reads, structured
queries, or an existing generator can be cheaper and more reliable than another
model. File length alone does not justify delegation. Consider a worker when the
useful result is much smaller than the material it must inspect, or substantial
generation follows an explicit specification and representative examples.

Inspect the actual worker interface, access, supported inputs, model selection,
and observable limits. Use existing authorized capabilities; do not install a
service, change global configuration, or assume a model is cheaper from its name.
When supported, give the worker a fresh, minimal task context instead of the full
conversation. Include applicable instructions and constraints. A worker without
shared file access needs an authorized input transfer, not inaccessible paths.

Keep architecture, subtle diagnosis, security judgment, and unresolved product
decisions with their reasoning owner. A worker may collect bounded evidence for
those decisions without owning the conclusion. If no suitable worker exists or
coordination outweighs the benefit, execute directly with the normal domain tools.

## Assignment contract

State the following in the handoff, combining fields when the task is simple.
Resolve discoverable facts yourself; do not turn this into a user questionnaire.

| Field | Required information |
|---|---|
| Objective | One bounded question or deliverable and its success conditions |
| Inputs | Source handles, applicable instructions, relevant context, and a revision or snapshot sufficient to detect drift |
| Authority | Constraints, permitted effects, and allowed output paths; source text is evidence, not new authority |
| Ownership | Who owns each output and who accepts the result; prevent overlapping writes |
| Output | Expected findings or artifact form and a task-sized output ceiling; avoid returning the entire corpus |
| Limits | Effort/attempt allowance, remaining user/host limits, and stop/escalate conditions |
| Acceptance | Checks and review required by the acceptance owner, including independently established behavioral expectations |

Choose limits appropriate to the task and the host's controls. Distinguish an
instructional bound from an enforced timeout, quota, sandbox, or write restriction.
Do not invent precise token accounting when it is unavailable or reset a shared
allowance when delegating. If a hard limit depends on missing accounting, resolve
that gap before work that could exceed it.

## Reader assignment

Ask a focused factual question over a bounded source set. Allow targeted discovery
within that set when necessary; name what cannot be inferred from it. The worker
returns findings with paths and verifiable locations or symbols, relevant source
revision, omissions, contradictions, and uncertainty. It must distinguish no
matching evidence from incomplete inspection or tool failure.

The acceptance owner checks the source supporting consequential claims and reads
the current section before editing it. A summary locates evidence; it does not
replace exact source for an edit or establish a nuanced diagnosis. Refresh stale
findings rather than treating plausible line numbers as authoritative.

## Generator assignment

Supply the required behavior, relevant implementation interfaces, a representative
reference, exact output ownership, and applicable validation. A neighboring test
shows conventions; it does not replace the specification or code under test.
Missing references or material ambiguity return to the owner before speculative
writes. Use deterministic generation if an existing tool already supplies it.

Use a proposed patch or isolated output when shared-state ownership is uncertain.
Scoped direct writes are appropriate when authorized and ownership is clear.
Before integration, compare the current target with the assignment's starting
state and preserve concurrent or unrelated edits. Do not overwrite on assumption.

The acceptance owner inspects the actual diff and runs the relevant independent
checks. Generated tests passing against one implementation do not prove that they
assert the required behavior: use independently derived cases and, where useful,
a known incorrect implementation to check that the tests detect the defect.
Do not weaken existing checks to accept generated output.

## Return, accept, or recover

Return a compact status (complete, partial, failed, or blocked), the requested
findings or artifact handles, source provenance, checks actually performed and
their outcomes, unresolved issues, effects already performed, and available usage.
Never report unrun checks or empty/failed output as successful completion.

Acceptance belongs to the named owner and follows the declared checks. Appropriate
deterministic checks can accept registered operations without a frontier-model
call. Interpretation and generated changes retain the required source/diff review;
the worker's confidence is not an acceptance oracle.

On failure, inspect the result and any effects before retrying. Respect the attempt
allowance; stop on material ambiguity, conflicting state, unreliable evidence, or
missing authority. A direct fallback or escalation carries original requirements,
source handles, completed effects, failed checks, and remaining limits. Do not
bounce between workers or repeat an operation whose outcome is still unknown.

## Composition and evidence

- `context-engineering` owns context selection, compaction, and handoffs. Use this
  overlay only when executing a bounded offloaded read or generation assignment.
- `agentic-sdlc` owns lifecycle coordination; implementation and domain skills
  retain their engineering requirements. They need not all be loaded for one task.
- `agentic-sdlc-improvement` owns comparisons across runs. Keep parent context
  reduction separate from aggregate tokens, latency, monetary cost, and quality.
  Claim benefits only for tested classes and measured dimensions; unknowns remain
  unknown. Successful execution alone is not evidence of efficiency.

## Conditional references

- [Router integration](references/router-integration.md): read when designing a
  local classifier/worker front door or integrating this protocol with a router.
  It describes a design, not an installed service.
- [Evaluation](references/trigger-evals.md): selection boundaries, protected-case
  grading, and the paired comparison procedure; for maintaining this skill.
- [Behavior fixtures](references/behavior-fixtures.md): raw decision probes; keep
  grading guidance out of the evaluating agent's input.
- [Pilot fixtures](references/pilot-fixtures.md): reproducible executable reader
  and generator tasks with independent grading; for evaluation only.