autonomous-delivery

Files (4)

• LICENSE
• README.md
• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Autonomous delivery

**Organize the work, then keep improving how it is organized.** An intelligent,
balanced outer agent holds the user's intent and coordinates sessions. Those
sessions may do bounded work themselves or orchestrate a workstream with its own
workers. The useful shape depends on the task, codebase, risks, and evidence;
there is no universal roster, pipeline, or agent count.

Optimize for **verified useful outcomes per unit of time and effort**, not raw
agent activity. Quality and throughput are joint goals. Better task boundaries,
context, feedback, and verification often improve both by preventing rework;
confirm that with evidence and make real tradeoffs explicit. Do not buy apparent
speed by weakening the required outcome.

## The adaptive pattern

```text
User intent, constraints, and authority
                  |
         Balanced outer coordinator
                  |
       Task-appropriate workstreams
          /                  \
   Direct worker       Local orchestrator
                            |
                      Focused workers
                  |
       Evidence, integration, feedback
                  |
     Reflect and reshape the organization
```

This illustrates possible relationships, not mandatory levels. A coordinator can
also do useful work directly. A worker can become a local orchestrator when a
workstream needs it; an unnecessary layer can collapse back into direct work.
Use hierarchy to contain complexity, not to reproduce an org chart.

The outer agent needs enough judgment to decompose, challenge assumptions, and
integrate results, while staying economical about detail. Keep the global goal,
interfaces, important decisions, resource use, and acceptance in its context;
let local owners retain deep implementation or domain context. Select models and
tools for the work and the user's preferences, not a fixed "best model" hierarchy.
A difficult design decision might benefit from a stronger reasoning reviewer;
a routine bounded transformation might not.

## Balance intelligence, reasoning depth, and execution speed

Use an intelligent orchestrator with strong reasoning and broad enough context
to hold the objective, challenge assumptions, choose boundaries, and integrate
evidence. Pair it with **faster but still capable workers** for well-scoped
implementation, tests, bounded research, and repetitive operations. Fast does not
mean disposable or incapable; a worker must meet the same correctness bar.

Spend the strongest available reasoning where judgment has the highest leverage:
critical design decisions, concurrency or persistence invariants, difficult bugs,
contradictory evidence, repeated failed approaches, and consequential unblocking.
A local orchestrator or a focused expert consultation can handle that depth;
the outer coordinator need not absorb every implementation detail.

| Work | Model-selection bias |
|---|---|
| Overall decomposition, priorities, acceptance and integration | Strong reasoning, reliable synthesis and sufficient context |
| Bounded implementation with a clear contract and tests | Fast, capable coding model |
| Straightforward evidence gathering or routine validation | Efficient model with the necessary tools and fidelity |
| Hard diagnosis, high-risk design review, unresolved ambiguity | Strongest suitable reasoning model and supported reasoning effort |

Choose actual models and reasoning settings within the user's preferences,
availability and shared budget. Do not hard-code one permanent model pairing,
assume a label guarantees quality, or silently override explicit selections.
Model capability, reasoning effort and context size are different choices.
Increasing all three for every call is not a strategy.

Escalate when a concrete uncertainty or failed approach warrants it, not after an
arbitrary number of minutes. Give the stronger model the failing case, relevant
code, attempted explanations and exact unresolved decision. Return its conclusion
to the existing implementation owner rather than restarting the whole workstream.
Once the uncertainty is resolved, use faster execution again where appropriate.
Judge the balance by verified outcomes, rework, latency and total cost, including
handoffs and review, rather than token price or response speed alone.

## Start with a working understanding, not a ceremony

Establish the requested outcome and what would demonstrate it. Find the relevant
code, documents, existing sessions, conventions, dependencies, and constraints.
Distinguish confirmed requirements from assumptions. Identify what actions are
authorized and what data or shared state could be affected.

Choose an initial organization that makes useful progress with what is known.
For a small change or a tightly coupled investigation, one agent is often right.
For independent work or substantial separate context, use session orchestration.
For a broad workstream whose local decisions would overload the outer agent,
delegate an outcome to a local orchestrator.

Do not require every uncertainty to be resolved before starting. Investigate
high-impact unknowns early, begin independent work where safe, and revise the
plan as evidence arrives. Ask the user only when the answer changes scope,
authority, or a consequential choice that cannot reasonably be inferred.

## Delegate outcomes and decision boundaries

A useful assignment conveys the relevant user intent, expected result, owned
scope, dependencies, important context, authority, and how to demonstrate success.
State what the recipient can decide and what should come back for resolution.
Keep it sufficient to work independently, not an exhaustive copy of the parent
conversation or a rigid form to fill in.

For example:

> Own the client side of this protocol change. Preserve existing callers.
> Coordinate the UI and compatibility work if they benefit from separate
> owners. The server workstream owns the wire contract; agree on it before
> depending on a change. Return the implementation, relevant compatibility
> evidence, and unresolved interface decisions. Local edits and tests are in
> scope; publishing is not.

A local orchestrator receives responsibility for its outcome, not permission
to multiply agents without purpose. Any delegation remains within the parent's
scope, authorization, and shared resource budget. Pass down applicable session,
concurrency, cost, and time limits and whether further delegation is in scope.

From BumpyClock/agent-templates, MIT.

More from BumpyClock/agent-templates