do-next-slice

name	do-next-slice
description	Continue the active phase by completing exactly one slice, then stop.
allowed-tools	Bash(python3 scripts/workflow.py:*), Read, Edit, Write, Glob, Grep, Bash, Agent, EnterPlanMode, ExitPlanMode
disable-model-invocation	true

do-next-slice

Run python3 scripts/workflow.py next — it prints the current pointer, so there is no need to re-read works/state.json or works/backlog.md — then read CLAUDE.md, the selected slice folder, and the phase's phase.md: the bounded phase notebook (## Slices generated from slice.json, ## Decisions, ## Doc impact, ## Operator Questions, ## Notes for later slices, ## Now) that carries the phase's state and is your handoff from the last slice. Read docs/current/ sections just in time, only where this slice's work touches them — never the whole doc set up front, and not docs/index.json (version history, not truth). If you are ever unsure of the operator's intent, consult the phase's intent.md (linked from phase.md) — the confirmed record of what was asked. next reports the current stream's active phase: on the default stream it skips phases opted into parallel mode (printing parallel_phases_elsewhere=<P>:<branch> when any exist), and in a phase-branch worktree it sees only that phase (printing a stream= line). Run python3 scripts/workflow.py parallel-status when you need the picture across every stream.

You are the ORCHESTRATOR (main thread): you plan each slice, verify, commit, move workflow state, and talk to the operator. The execution of every slice — decomposition, implementation, fix, and the phase review — is delegated to a slice-executor tier subagent (slice-executor-mid or slice-executor-high; you do not do that slice's work yourself). One exception, and it is narrower than it used to be: a co-work (design) slice runs inline → dispatched → inline. The DesignSync work is never dispatched — the read-back and the SIGNOFF regroup stay on the main thread, because DesignSync is main-thread only and no executor has it — but the mockup build is the one dispatched span inside that slice (slice-executor-high, no DesignSync, built from the round's build-prompt.md). See the design-cowork skill. One slice, then stop.

If next prints WAITING ON OPERATOR (the current slice or phase is pending, shown [~]), STOP: the work is waiting on operator co-work. Report what is needed and do not start, finish, or advance it. Resume only after the operator approves and clears the pending status back to in_progress. When the phase is pending because its operator acceptance gate is open (next also prints acceptance_gate=open and the walkthrough), relay that walkthrough to the operator as-is: it clears with python3 scripts/workflow.py accept-gate <P> --clear [--note "..."], not with set-phase-status. (In parallel mode a pending slice or phase halts only its own stream.) A co-work design slice stops pending twice and the engine cannot tell the two windows apart — both are status: pending on the same slice and both print the same line — so the difference lives entirely in what you report; say which one this is (step 3).

If next prints a hint: line offering python3 scripts/workflow.py parallel-start <P> — a planned phase waiting behind the one in progress — relay it to the operator as a suggestion, never a default, and carry on with this slice unless they opt in. Opting in is theirs to decide, must happen while that phase is still planned, and runs from the default stream; the parallel-phase skill has the full lifecycle.

Work exactly one slice:

1. If the selected slice is todo or ready, run python3 scripts/workflow.py start-slice <slice_id>. (In plan only mode, skip this — the slice is readied, not started; see step 2.)
2. Plan the slice, then persist the plan to this slice's own plan.md.
   • Skip planning for an existing ready ([r]) slice. Its plan.md was operator-approved by an earlier plan only pass, so re-read that plan and phase.md, then dispatch directly (step 3). Re-plan only when concrete visible workspace drift makes the approved plan unsafe or stale.
   • Default is auto. With no mode word (an explicit auto, or "run unattended", means the same), do not enter plan mode: plan inline, Write the complete free-form plan to plan.md, and dispatch immediately. Pull context from phase.md, incorporate any operator note without duplicating intent.md, and never pre-fill another slice's plan. This waives only the approval gate; every safety halt still applies.
   • gate is the operator-approved path. When invoked with gate, call EnterPlanMode, do read-only research and surface clarifications, then call ExitPlanMode to present the readied plan. After approval, copy the exact harness plan file named for this planning session to the slice's plan.md; never glob ~/.claude/plans/ or choose by mtime. First confirm its opening lines match the plan just approved, then copy immediately before another EnterPlanMode can overwrite it. Append slice-local additions after the copied body, never by rewriting it. If Claude Code names no harness plan file, fall back to writing the approved plan verbatim and in full.
   • plan only readies one plan without executing it. Run the same gated planning path even if auto also appears. If the selected slice is already ready, target the next ordered slice that is neither done nor ready. Stop before anything whose plan depends on something that has not landed yet — REVIEW (it depends on the implementation results), P<N>.DECOMP2 (it depends on findings or a design that do not exist yet: a slice's findings, or a design round that has not come back), and a phase's (its is written at its turn, from the round that just landed) — and stop when there is nothing left to ready. After approval, copy the harness plan file (with the same guarded fallback), set the slice to , validate, commit, report what was readied, and STOP without , executor dispatch, or .

When the selected slice is a decomposition (kind: decomposition), it runs the same path as any slice — you plan it, the slice-executor does its job. That job is to create the phase's middle slices: in step 3 the executor runs python3 scripts/workflow.py new-slice --phase <P> --slice <P>.S<n> --name "..." (with --kind, --risk, --order, --depends-on as the plan specifies) to create them as bare folders — never pre-filling their plan.md; each fills its own when it runs — and records the slice breakdown (what each slice covers and why) plus findings in the phase's phase.md, so later slices share that context. Set each middle slice's --risk deliberately — risk selects the executor tier (low → slice-executor-mid, anything else → slice-executor-high), so it is the phase's main cost lever; rate a slice low only when its work is a one-line, or few-line, code edit or docs — anything that writes real code, and anything touching more than one file, is high. When the phase cannot be cut past a point without learning something first, that is what the research kind is for: the executor cuts a research slice (--kind research --risk high — findings-only, no product code, findings landed in phase.md) and a <P>.DECOMP2 ordered after it, instead of guessing at the slices beyond it; DECOMP2 then re-cuts the rest from what was learned. That is DECOMP2's second origin and it is as ordinary as the design one below — usually, not always: a research slice whose findings change nothing about the remaining breakdown needs no re-cut, and a phase genuinely needing a third pass numbers it DECOMP3. Plan the decomposition accordingly; you still verify, finish-slice, and commit as for any slice. When the phase touches product visual design, its shape follows the operator-confirmed style — build-after, design-only or paired, recorded in the phase's intent.md under ## Design Style (read the design-cowork skill). In every style this DECOMP creates the design slice(s) ( — : a design with many items to cover splits into several) and records the — what to build, not how — in . What else it creates is what the style decides: — the groundwork slices plus a second decomposition slice after the last design slice, and ( cuts them once the design has landed, backend first and the design implementation after); — a single pass, → design slice(s) → , the apply phase being a separate phase created at ; — the design/apply pairs as , one apply slice per round and (a bare folder is not pre-planning; each apply plan is written at its turn). If carries no because the phase was created before its visual nature was clear, : suggest a style with a reason, set the slice , and stop — noting that cannot be chosen from inside , since its apply phase needs and the executor may not run it, so that answer goes back to the main thread and .

Declare the phase's operator acceptance gate at the DECOMP boundary. Right after finish-slice <P>.DECOMP, and in the same commit, decide from intent.md and the decomposition whether this phase changes anything the operator can see, then run python3 scripts/workflow.py accept-gate <P> --require (it does — the operator will walk the running product before the review can pass) or python3 scripts/workflow.py accept-gate <P> --waive --note "why nothing operator-visible changes". A phase that ships a mockup takes --require, with no judgment call left in it — the operator opens a running route, which is an operator-visible surface by definition, so a design-only phase can no longer be waived. And when DECOMP had to ask the design style (above), that answer must land before you declare the gate, because the declaration depends on it. There is no default and no declaring by omission: review-phase --verdict pass refuses an undeclared phase and names both flags. Phases created before workspace v32 carry no acceptance block at all and need no declaration.

When the selected slice is a phase review (kind: review), step 3 delegates the review to slice-executor-high like any slice — you do not review it yourself. Plan it so the executor: validates all of the phase's slices together (each slice's validation commands from its plan.md / result.md, plus python3 scripts/workflow.py validate), reviews the phase against its objective, intent.md, and the docs, and — only on a passing review, and only outside parallel mode — consolidates the phase's durable-doc changes (the running "Doc impact" notes in phase.md) into new doc versions. In parallel mode (the phase carries an execution block with mode: "parallel") a passing review consolidates nothing: plan it so the executor verifies the "Doc impact" list is complete and returns doc_versions: none — deferred to post-merge consolidation (parallel mode), and the versions are created on the default stream after the merge — see the parallel-phase skill for that sequence. A non-passing verdict stops the executor before that consolidation and hands the phase back to you: it completes validation and judgment first (so you receive the whole picture in one cycle, not one finding per cycle), then returns the verdict with numbered findings and proposed fix slices instead of doing any pass-only work. The review does not produce a phase explainer — explaining is a separate operation the operator runs, and the executor just reports the fixed pointer explain: not written — run /explain for this phase. On a review slice the executor writes only docs, never source code. When the phase's gate is required: true, plan the review to run the gate stages as well: the executor opens the running product itself in the ## Operator Runtime manifest runtime and spot-checks the phase's headline claims (never passing on other slices' reports alone), walks it once with fresh eyes as a first-time user, re-runs the whole ## Regression Checklist smoke list and appends this phase's headline checks, and routes every ## Operator Questions entry into the walkthrough or into a deferred job for you to file — returning a walkthrough beside the verdict (see the review-phase skill). It returns a review_verdict; you record it and act on it instead of running steps 5–7:

• On pass with a required acceptance gate, do not record the verdict yet. Run python3 scripts/workflow.py accept-gate <P> --open --walkthrough "<the walkthrough the executor returned>" — the phase goes pending — file any deferred jobs the review listed (defer-job ...), run validate, commit, report the walkthrough to the operator, and STOP. When the operator accepts, the gate clears with python3 scripts/workflow.py accept-gate <P> --clear [--note "..."] and the phase returns to in_progress; on that resume the REVIEW slice is still in_progress with its result.md carrying review_verdict: pass and the gate showing cleared_at, so record the pass without re-dispatching the review. If the operator reports failures instead, record python3 scripts/workflow.py review-phase <P> --verdict changes_requested --note "operator-reported: ..." (never refused — it resets the gate), create fix slices from their report, complete them, and re-review from the top. A waived phase, and a legacy phase with no acceptance block, record the verdict straight away as before.
• Record the verdict: python3 scripts/workflow.py review-phase <P> --verdict pass|changes_requested|blocked --reviewer slice-executor-high --note "...", then python3 scripts/workflow.py validate (state integrity — also catches a stale docs/current).
• On pass: review-phase has already marked the phase done and closed the REVIEW slice — no separate finish-slice is needed. The phase stays in active/ — archiving is a separate, manual step, so do not archive now. Archive later, when the operator asks: archive-all once every active phase is done, rotate-backlog to archive just the done phases while others continue, or archive-phase <P> for one phase. If the phase is running in parallel mode, a pass is what opens its integration: run the parallel-phase sequence (parallel-gate <P> → push → gh pr create → CI → gh pr merge --merge → → the deferred doc consolidation → → ), stopping and reporting if the gate is closed; archiving stays blocked until the consolidation is recorded.

Durable-doc versioning happens only at the phase review: the review-slice executor consolidates the phase's "Doc impact" notes (recorded in phase.md by earlier slices) into new versions on a passing review, and reports them in doc_versions; you confirm via validate. In parallel mode that consolidation moves to the serialized post-merge step on the default stream (parallel-merge-finish → doc-new-version per note → parallel-consolidated <P>), because doc versions come from one shared index. Implementation, fix, and decomposition slices never run doc-new-version — when they change durable truth they append a one-line "Doc impact" note to phase.md. Never patch docs/current/*.md or old versions.

Stop after one slice. Do not advance to the next slice in the same turn.