git:20261101.cb769e1 to git:20261101.b825530

---

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

- [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.