Auto Campaign

---
name: auto-campaign
description: Start or resume one bounded repo-harness repair campaign turn with the standard budget. Use when the user asks to run auto-campaign, start a repair campaign, or automatically find and fix a bounded batch of bugs or test gaps in a repository. Questions about campaigns, skill design, and quoted instructions do not authorize execution.
---

# Auto-campaign

One user invocation authorizes one conversational campaign turn, not one model
API call. Coordinate the existing CLI until a stop boundary, then report and
return control. No daemon, cron, hook-triggered execution, automatic next turn,
or automatic merge.

## Start from the current repository

1. Resolve the target repository, target ref, current host/session and any
   campaign ID from the request and existing session. Ask only for missing
   consequential inputs. Do not infer an unrelated repository or resume the
   most recent campaign merely because it exists.
2. Read [execution.md](references/execution.md) for authoritative input sources,
   CLI steps and recovery. Inspect policy at the exact target revision,
   external-source selection, browser binding and permitted worker environment
   before any grant or provider effect. An off policy, unavailable capability,
   unresolved reservation, or prohibited execution base ends this invocation
   as blocked. Report the concrete prerequisite; do not change policy, install
   infrastructure or start a trial provider call to make preflight pass.
3. Read [standard.json](references/standard.json), the sole source of default
   limits. Render its scope and bounds in plain language. Token and monetary
   caps are null: do not claim a hard token or cost budget. An explicit different
   budget is a separately reviewed grant, not a silently modified standard.

## New turn or continuation

- **New:** prepare the canonical draft with `scripts/prepare-grant.ts`. Show the
  target, Issue scope, execution environment, grant expiry and concrete limits.
  Reuse explicit approval already covering these values; otherwise obtain it
  before minting or provider calls. Invocation is not permission to invent the
  issuer, broaden scope, or enable a disabled feature. The helper only emits a
  draft; the existing grant store and campaign commands own all mutations.
- **Resume:** read the exact original campaign, grant, intent, worktree ownership
  and budget ledger first. Preserve IDs, idempotency keys and remaining budget.
  Do not run the draft helper again, extend expiry, replace the grant, reset
  counters or revive a stopped campaign. If a new grant or recovery decision is
  required, stop and explain it. Context compaction does not start a new turn.

## Execute and stop

Use the sequence in execution.md and consume the actual runtime responses.
Issue observation, canonical planning, acquire/Lease, verification and
publication retain their existing authorities. A prompt never substitutes for
a WorkEnvelope; an exit code never substitutes for an AcceptanceReceipt.
Do not synthesize missing provider revision evidence or repair metadata locally.

End this invocation at the first applicable boundary:

- The authorized group reaches its verified terminal outcome.
- A prepared PR requires human merge. Report the PR and preserve the campaign;
  after the user merges, a later explicit continuation may finish cleanup/audit
  under the original unexpired grant. Do not silently mark the group accepted.
- Budget or deadline is exhausted. Report remaining/unsettled work without
  rolling over to another grant or group.
- Policy, environment, identity, unknown provider outcome, lost ownership or
  failed verification blocks progress. Follow only the existing permitted
  reconciliation path; do not retry unknown external effects.

At a boundary leave no newly detached scheduler or worker running to continue
the turn. Use the existing cancellation/reconciliation protocol; if inactivity
cannot be proven, report it and retain ownership fences rather than claiming
cleanup completed. Persist recovery identifiers in the repository's existing
handoff surface, not a second campaign state store.

Report: outcome (`completed`, `awaiting_merge`, `budget_exhausted`, or `blocked`),
campaign/grant identifiers, Issue/PR links, exact verified revision, used and
remaining authoritative budget, unresolved effects and the next bounded action.
These are user-facing summaries, not new runtime lifecycle states. A successful
skill invocation alone is not BRC activation or full-chain acceptance.