×ばつwindow if that's all you have). Over the ~50K target = re-examine later scopes for the same drift; over the 80K ceiling = flag the scope and split whatever remains downstream - `<concerns>` — problems hit or risks for later workers - `<instructions-for-next-agent>`">

---
name: plan-and-execute
description: Plan a task's execution strategy, then run it as a serial chain of fresh subagents passing a shared baton, ending with a verifier. Ingests an upstream artifact (issue/PRD/handoff doc) when present; plans from scratch when not.
disable-model-invocation: true
---
# Plan and execute
Own execution strategy (the *how*), not requirements (the *what/why* — that's upstream in issues/PRDs). Preserve the plan's intent across the chain.
## Plan first
Detect mode:
- **Ingest** — upstream artifact specifies the work (issue, PRD-issue, or `/handoff` doc pointing at one). Read it; plan execution strategy only. Never re-litigate settled scope.
- **Fresh** — no artifact. Plan from scratch.
Then:
- Plan mode on → the plan must name its execution strategy (below).
- Plan mode off → ask if they want it before anything else; suggest nothing until they answer. If no: resolve open questions with AskUserQuestion, then draft a plan under the same rules.
- No execution until the user approves the plan.
## Before executing, ask
- How to split into **sequential scopes**. Default to *more, smaller* scopes — when a scope feels borderline, split it. Budget per scope: **target ~50K tokens, hard ceiling 80K**. The ceiling counts everything a worker must hold — files it reads, the diffs it produces, and its own reasoning/output — not just lines changed. Anything you project over 80K must be split *before* spawning, not discovered mid-run. Order scopes so each builds on the last.
 - Concrete splitting cues — break the scope when it spans more than one of: a new data model + its API surface; production code + its test suite; more than ~3–4 files of net-new logic; a migration + the code that depends on it. Each of these is its own scope.
- Whether to commit once the verifier is clean. If yes: commit from baton summaries; commit only this session's files; if files are pre-staged, ask how to handle; once file count is known, ask single vs multiple commits.
## Pipeline
Orchestrator holds only the plan, scope list, and one-line acks — never work product. Spawn each agent in turn:
1. Ingest artifact (or plan fresh) → decompose into sequential scopes (target ~50K, ceiling 80K each — bias toward smaller) → seed the baton: one `<agent-n-slug>` block per scope, each with `<acceptance>` filled in and the remaining tags as empty placeholders.
2. Per scope, in order, spawn one worker. Each: reads the baton + the diffs named in prior `<anchors>`, does exactly its scope, fills in the empty tags of its own block (never creates a new block), returns one line: `scope <n> done` | `scope <n> incomplete: <what's left>` | `scope <n> blocked: <why>`.
3. Spawn the verifier: for each scope, check the real diff (via `<anchors>`) against its `<acceptance>`; run build + tests; confirm the whole meets `<goal>`. Return pass, or fail with specifics.
On finish: brief summary + baton path.
## Failure branches
- **Incomplete** (worker finds the scope larger than planned and stops partway) → orchestrator splits the remainder into a new scope and continues from there.
- **Blocked** → orchestrator halts the chain — does not spawn the next worker onto a broken diff. Spawn a fix worker or surface to the user.
- **Verifier fails** → orchestrator spawns one fix worker (fresh; reads baton + the failures), then re-verifies. After 2 failed rounds, stop and surface to the user.
## Baton
Shared file passed worker→worker. Write for agents, not humans. Create in TEMP (`mktemp`; PowerShell `New-TemporaryFile`). Lightweight — points to the plan doc for granular instructions, never restates them.
Header `<context>`: `<plan-ref>`, `<goal>` (one line), `<approach>` (one line: the strategic/tonal steer, e.g. "surgical, precedent-driven, mirror #57"; no facts, file lists, or step detail — those live in the plan).
The orchestrator seeds one `<agent-n-slug>` block per scope with `<acceptance>` filled and every other tag present but empty. The worker fills the empty tags in its own block — it never creates a new block:
- `<acceptance>` — checkable done-criteria; orchestrator writes this when seeding; the worker never edits it
- `<summary>`
- `<anchors>` — handles to read real work: touched paths, new/changed signatures, migration IDs, test names
- `<size-vs-plan>` — exactly one word: `smaller` | `as-expected` | `larger` (how the actual work compared to the planned scope; not a t-shirt size, no prose). On `larger`, the orchestrator must shrink every remaining scope before continuing — a `larger` reading means the plan is under-splitting
- `<approx-context-used>` — absolute token estimate, e.g. `~30K`; never a percentage (ambiguous without window size — convert percen×ばつwindow if that's all you have). Over the ~50K target = re-examine later scopes for the same drift; over the 80K ceiling = flag the scope and split whatever remains downstream
- `<concerns>` — problems hit or risks for later workers
- `<instructions-for-next-agent>`