sell-slice

<!-- skills/sell-slice/SKILL.md --> <!-- The high-touch single-slice delivery loop. Pizza-shop framing: pull one pie off the rack, run it through the line, slice and serve to one customer. v5 shape: an interactive spine (prep gate · recon · build-plan auth · /goal · branch) wrapping Workflow A (produce - the builder/implementer emits the build manifest; on type frontend no implementer runs and state-illustrator emits it at the Workflow B entry) + a human library gate + Workflow B (verify-once = state-illustrator → break-ui-runner → slice-tester → slice-verifier, with an off-context fix loop). Each static gate runs exactly once. /box-it-up is the handoff. For autonomous whole-roadmap baking, /sell-pie loops one Pie unattended; /sell-slice is the careful per-slice surface. -->

/sell-slice - The High-Touch Single-Slice Delivery Loop

The agent loading this skill is the orchestrator for one slice of the master checklist. It reads plans, scopes the slice, dispatches subagents through Workflow A (produce) and Workflow B (verify-once), merges their structured returns, and gates the slice on real verification before it is committed locally.

The orchestrator does not write production code itself. Every heavy step is a subagent or a sub-skill. The orchestrator routes structured artifacts; it never grades its own output.

Run /sell-slice → finish a slice → start a fresh chat → run again. Repeat until every row in docs/plans/00_master_checklist.md is [x]. For autonomous whole-pie baking (the v5 forefront), see /sell-pie - it loops one Pie unattended and stops at the pie boundary; /sell-slice is the careful, collaborative single-slice surface. For mid-flight feature additions, see /special-order (it feeds into sell-slice).

---

Mode detection

/sell-slice is sequential-only - it requires a master checklist to know which slice to serve next. If docs/plans/00_master_checklist.md is missing, the skill stops and points the user at /cook-pizzas (to generate one) or /special-order (to add a slice to an existing project).

/sell-slice works on both layouts (dual-read):

• v5 nested - ## Pie N chapters containing ### Slice N.M deliverables. /sell-slice serves one ### Slice N.M at a time. (Whole-pie autonomous runs are /sell-pie's job; /sell-slice stays at one slice even inside a nested checklist.)
• v4 / legacy flat - ## Stage N. /sell-slice serves one stage at a time, exactly as it did pre-v5. (Unlike /sell-pie, which refuses a flat checklist, /sell-slice runs flat projects unchanged - no --repie required.)

Throughout this skill, "slice" means the active unit of work - a ### Slice N.M on a nested checklist or a ## Stage N on a flat one.

The Phase 0 Prep-section precondition further requires every ## Prep checkbox to be [x] before any feature slice can run. See Phase 0 for the helpful-error message.

Subagent Roster

Every dispatch description (Agent tool description, Workflow label) starts with P<pie> S<slice> <step>: (for example P4 S4.2 build: kitchen server); <step> is prep, build, test, verify, fix, plate, or review.

Each subagent is a registered plugin agent; its definition file under ./agents/ carries the role prompt plus the model / effort / tool allowlist, all enforced by the platform (the roster columns below are contract, not decoration). Dispatch by type, never by pasting the file: Workflow steps pass {agentType: "bytheslice:<name>"} to agent(); direct dispatches use the Agent tool with subagent_type: "bytheslice:<name>". The prompt you pass carries ONLY the slice-specific inputs (plans, manifest, Exit criteria, paths); the platform loads the definition itself. Fallback (Cursor, or any host without plugin-agent registration): Read the file and dispatch it per loop-workflow-fallback-pattern.md "Agent shape on the fallback path": its frontmatter goes first as a header (model tier and effort, the normalized tool allowlist, the read-only line for an agent without write tools, the no-git-writes line), then its body, then the inputs; log one self-check line per dispatch in the run log.

Only the orchestrator writes to git, on the registered and the fallback path alike, and that includes git add. implementer, fix-attempter, debug-instrumenter and library-entry-writer never stage, commit or push; they return files_changed. At every commit point the orchestrator stage exactly the paths agents returned in files_changed (plus the checklist when it changed) with git add -- <paths>, never git add -A or git add .; check git status --short shows nothing unexpected (an unexpected file is reported, not swept in); then commit and push.

Core (every slice type)

Stage	Agent file	Model	Effort	Mode
Recon	agents/discovery.md	opus	medium	readonly
Recon	agents/checklist-curator.md	sonnet	medium	readonly
Recon	agents/rules-loader.md	haiku	low	readonly
Workflow A - produce (backend/full-stack/db-schema/infrastructure)	agents/implementer.md (the builder - emits the build manifest on these types; state-illustrator emits it on frontend)	opus	medium	write
Workflow A - per-item review	agents/spec-reviewer.md	sonnet	medium	readonly
Workflow A - per-item review	agents/quality-reviewer.md	opus	medium	readonly
Workflow B - verify-once (behavior)	agents/slice-tester.md	sonnet	high	write
Workflow B - verify-once (static gates, each once)	agents/slice-verifier.md	sonnet	high	write
Fix loop (off-context)	agents/fix-attempter.md	sonnet	high	write
Fix loop (2nd fail)	agents/debug-instrumenter.md	sonnet	high	write
Fix loop, UI review findings (break-ui-runner, design-critic)	agents/frontend/ui-fix-attempter.md	opus	medium	write

Frontend pipeline (Workflow A, type: frontend)

Step	Agent file	Model	Mode
UX strategy (first)	agents/frontend/modern-ux-expert.md	sonnet	write
Layout (serial, after UX strategy returns)	agents/frontend/layout-architect.md	sonnet	write
Compose (always; configured registries first, then stock shadcn)	agents/frontend/block-composer.md	sonnet	write
Craft (conditional on gaps)	agents/frontend/component-crafter.md	sonnet	write
Library Preview Gate	agents/frontend/library-entry-writer.md	sonnet	write
State coverage + dev data switch + build manifest emitter on frontend (Workflow B entry)	agents/frontend/state-illustrator.md	sonnet	write
Worst-case data review (Workflow B 5.1b, data-bound UI only)	agents/frontend/break-ui-runner.md	sonnet	readonly on source (writes its report and may extend fixtures)
Design critique of new composite blocks (Library Preview Gate)	agents/frontend/design-critic.md	sonnet	readonly (writes its report)

UI review skills. break-ui-runner and design-critic wrap two vendored third-party skills (break-ui and the impeccable critique), copied verbatim at pinned commits under references/vendor/. Both are review agents on sonnet that return structured findings {id, severity, surface, problem, proposedFix, files} and a markdown report with screenshots in the slice's evidence folder. Neither gates a merge on its own: their findings go through the existing verdict, fix-loop and HITL flow. design-critic never runs the impeccable launcher or any binary (operator approval through a HITL is the only way it ever runs).

Behavioral + rendered review is slice-tester's job; static gates are slice-verifier's. The rendered design-system match and the console/network checks both run in slice-tester's one behavioral pass.

Sub-skill dispatches (Workflow A, foundation slice types - legacy v3 projects only)

Slice type	Sub-skill (path)
design-system	skills/set-display-case/SKILL.md
ci-cd	skills/final-quality-check/SKILL.md
env-setup	skills/open-the-shop/SKILL.md

---

Preconditions

This skill checks the three preconditions below inline at the start, via tools. If one fails, raise the problem to the operator as a question with a recommended next step, never a refusal: a missing master checklist means asking (AskUserQuestion, Accept or Decline) whether to set up ByTheSlice; a dirty tree means asking whether to proceed dirty; an incomplete Prep section is handled in Phase 0. Never narrate passing checks in chat. No ByTheSlice hook blocks a prompt.

• docs/plans/00_master_checklist.md exists.
• One or more docs/plans/stage_<n>_*.md exist (one slice plan reachable for the active unit).
• Clean git working tree, OR explicit user OK to proceed dirty.
• No other session, branch or open PR is on the slice: checked in Phase 0 step 4a with bts_claim, before any branch is cut. Other work is a blocking destructive_operation HITL (references/session-collisions.md).
• Slice/stage plan files (docs/plans/stage_*.md) stay static during this skill: with the Pass mod loaded, a plan write draws a plan-write-during-bake warning. Nothing blocks. Production wiring waits for the Phase 4.5 approval; no hook enforces it.

---

Project Config

If bytheslice.config.json exists at the project root, the rules-loader agent (recon) reads it and returns resolved values. Honor:

• modelTiers.<agent> - overrides the agent file's model: for THIS run (sliceTester, sliceVerifier are the v5 verification tiers).
• stages.maxTasksPerStage - overrides the default cap of 6 (warn if user sets > 8).
• verification.viewports (int[], default [375, 768, 1280]) - the widths slice-tester renders frontend slices at (C7); it screenshots only at 768 and 1280. Pass this to slice-tester instead of any hardcoded viewport list.
• verification.e2e.{feature,regressionCore,visual} (each "always" | "critical-only" | "off") - threshold-gates which e2e suites slice-verifier runs by tag (C10). Pass the resolved values to slice-verifier together with quality.tier and delivery.mode, which can override them: under quality.tier: lean the only e2e gate is test:e2e:smoke; under delivery.mode: "ship-once" the verifier runs every command the generated CI workflows run (ci.yml, plus e2e.yml under the standard tier, in full) and the thresholds do not apply.
• quality.tier ("standard" | "lean" | "auto", default "standard") - the size of the installed quality line (see /final-quality-check "Quality tier"). Pass it to slice-verifier as given; it resolves auto itself.
• gates.enforcement (always "fix"), gates.advisory (gate classes, default []), gates.declared (extra gates, default []) - enabled quality gates are binding (references/quality-gates.md): a failing one goes to the 5.4 fix loop without asking, including when its root cause is a shared design token or a file the slice only consumes. Pass all three to slice-tester, slice-verifier, break-ui-runner, design-critic and the fixers. Only a class in gates.advisory is reported instead of fixed.
• flow.autoApproveBuildPlan (bool, default false) - when true, skip the build-plan authorization stop (C9 - also always auto under the /sell-pie loop).
• flow.libraryGate ("self-critique" | "human" | "off", default "self-critique") - controls the net-new-component library gate behavior (see Workflow A library gate).
• delivery.mode ("pie-pr" | "merge-per-slice" | "ship-once", default "pie-pr"; "ship-once" is set by /pizza-party and drives /sell-pie, so here it only changes the slice-verifier command source) - picks the closeout. "pie-pr" stops at "slice committed, ready for review" and hands off to /box-it-up; "merge-per-slice" runs the slice's own PR, CI and green-CI merge itself (Phase 6). An explicit autonomous-delivery run instruction ("merge this slice", "deliver it to main without me") selects merge-per-slice for that run and wins over the config in either direction. A slice in a review: continuous pie always uses "pie-pr".
• delivery.sliceBudgetHours (number, default 3; 0 = off) - the soft wall-clock budget for this slice (see "Soft time budget" under HITL Handling).
• mcps.* - declarative MCP availability.
• visualReview.tools - ordered tooling priority passed to slice-tester.

See skills/setup-shop/references/bytheslice-config-schema.md for the full schema.

---

Slice-Type Routing

Workflow A routes the work based on the active slice's type: frontmatter:

type:	Workflow A path
design-system	Dispatch the set-display-case sub-skill (legacy v3 only). Skip the internal builder.
ci-cd	Dispatch the final-quality-check sub-skill (legacy v3 only). Skip the internal builder.
env-setup	Dispatch the open-the-shop sub-skill (legacy v3 only). Skip the internal builder.
frontend	Run the internal frontend pipeline (modern-ux-expert → layout-architect → block-composer → component-crafter → library gate, each step serial). No implementer runs on this path, so state-illustrator emits the build manifest at the Workflow B entry (Phase 5.1).
backend	Dispatch the internal implementer (builder).
full-stack	Dispatch the internal implementer (covers both UI and API code).
db-schema	Dispatch the internal implementer with DB context flag. Schema updated FIRST in db/schema.sql (or detected equivalent).
infrastructure	Dispatch the internal implementer.

After Workflow A, Workflow B (verify-once) runs regardless of slice type, type-routed inside slice-tester (frontend = rendered + affordance UAT; full-stack/backend = seed-and-cleanup data-flow; infrastructure = probe/harness).

---

Gate tiers (what runs when)

Static gates run in four tiers, each at the cheapest point that catches its class of failure. Nothing in a slice demands the full gate ladder per task or per commit.

Tier	When	Who runs it	What it runs
1. While coding	Continuously, as each task is written	implementer (and fix-attempter on its own patch)	Lint on the changed files; the whole-project incremental typecheck (tsc cannot scope to files, so run it incrementally, e.g. tsc --noEmit --incremental); the colocated unit tests of the changed files.
2. Before each commit	At every task boundary, before the conductor commits	implementer, as its last step before returning files_changed; the husky pre-push hook re-runs the generic part on push	The slice's own tests named in its stage file; the build; DB tests only when the diff touches the schema or migrations.
3. Once at slice end	After Workflow A, before the slice's final commit and before any PR	slice-verifier	The full local suite, one time: lint, typecheck, build, unit/integration, e2e by tag (per verification.e2e; under quality.tier: lean, test:e2e:smoke only; under delivery.mode: "ship-once", every command the generated ci.yml and, at the standard tier, e2e.yml run), design-system static grep, CI-integrity, manifest backstop.
4. At the PR	When a PR opens (the pie PR by default; the slice PR in merge-per-slice mode)	CI	The full suite: @regression-core, @visual, audit, schema drift, design-system-compliance, plus everything above.

• The conductor commits a task only on a green tier 2. A red tier 2 goes back to the builder; it never lands in a commit. Bypassing the pre-push hook with --no-verify is never the answer: a red hook is fixed, not skipped.
• Tier 3 runs once per slice. Tier 1 and 2 results are narrower in scope and never substitute for it. After a fix, slice-verifier re-runs only the gates that fix could change (Phase 5.4); the full suite never runs again for that slice.
• Tier 4 belongs to CI. Exit criteria and checklist rows never demand a CI-only check (@regression-core, @visual, audit, db-schema-drift, the design-system-compliance workflow) per slice; those gate the PR.
• final-quality-check's local-gates-runner is a one-time scaffold validation outside this ladder and is unchanged.

---

Workflow availability (CC-only primitives)

/goal and Workflow (parallel() / pipeline()) are Claude-Code-only primitives. Detect availability up front; if either is absent (Cursor, disableAllHooks, workspace-trust not accepted, or any other reason the primitive surfaces), fall back - do not silently drop the logic:

• /goal unavailable → fall back to the manual goal-tracking pattern in ../cook-pizzas/references/goal-fallback-pattern.md (Phase 2.5 below wires this in).
• Workflow unavailable → fall back to in-context dispatch with orchestrator-side manual schema validation per ../cook-pizzas/references/loop-workflow-fallback-pattern.md. Without Workflow's built-in schema enforcement, the orchestrator MUST validate each subagent's structured return against its Appendix-A/B/C schema by hand before consuming it - otherwise enforcement is lost.

The house phrasing for any Workflow-backed step below is: "Run as a Workflow (parallel() / pipeline()); if Workflow is unavailable, fall back per loop-workflow-fallback-pattern.md."

---

Workflow

At every phase boundary, if the bts_status tool is available call it instead of re-reading the checklist; if it is not, read the checklist as before.

The skill is an interactive spine (Phases 0-3) wrapping two Workflows and one human gate:

• Spine: prep gate (Phase 0) · recon (Phase 1) · build-plan auth (Phase 2, auto under loop / flow.autoApproveBuildPlan) · /goal (Phase 2.5) · branch (Phase 3).
• Workflow A - produce (Phase 4): build the slice + its unit tests; the implementer emits the build manifest (on type: frontend no implementer runs, and state-illustrator emits it at Phase 5.1). Backend items pipeline / parallelize; frontend runs modern-ux-expert, then layout-architect serial after it.
• Library gate (Phase 4.5, human): net-new-component preview-first approval.
• Workflow B - verify-once (Phase 5): state-illustrator → break-ui-runner (data-bound UI only) → slice-tester → slice-verifier, each static check exactly once, with an off-context fix loop. On frontend, state-illustrator also emits the build manifest the other two consume.
• Closeout (Phase 6).

Phase 0 - Orientation (interactive spine)

1. Read docs/plans/00_master_checklist.md and every docs/plans/stage_*.md. Detect the layout (nested ## Pie N / ### Slice N.M vs flat ## Stage N) - dual-read; both are valid.
2. Prep-section precondition. If the master checklist has a ## Prep section, verify every Prep checkbox is [x] before any feature slice can run. If any Prep box is [ ], STOP and surface a helpful message:

   "Prep step '<unchecked line>' is still pending. Run <the linked command> first, then come back." This precondition does NOT apply to legacy projects that pre-date the Prep section - those keep the v3 behavior where foundation stages live as stage_1_* / stage_2_* / stage_3_* plan files routed through Workflow A (see Legacy path note in Phase 4).

3. Identify the active slice: first slice/stage with status Not Started or In Progress, unless the user named one. A slice whose **Status:** reads waiting until <YYYY-MM-DD>: <criterion> is skipped while that date is ahead (and so is any slice that depends_on it); once the date arrives it is the active slice, and the run only checks the date-gated criterion and closes it out (see ../cook-pizzas/references/templates.md "Calendar-gated criteria").
4. Confirm git state: git status --short, git rev-parse --abbrev-ref HEAD. Append the slice's start line (slice id, start time) to the run log .claude/.bytheslice-state/run-log.md (gitignored); the soft time budget counts from it. Under the /sell-pie loop the conductor already wrote it; do not write a second one. 4a. Collision check (references/session-collisions.md). git fetch --prune origin, then bts_claim { slice: "N.M", goal: "<one line>" } (under the /sell-pie loop the conductor already claimed it; do not claim twice). If it lists other work (another session's claim or rows, commits naming the slice on another branch or worktree, an open PR for the slice or its pie, a delivery-mode mismatch), cut no branch and write no code: raise a blocking destructive_operation HITL with those facts and stop. On the operator's go-ahead call bts_claim { slice: "N.M", over: true }; otherwise bts_claim { slice: "N.M", release: "abandoned" }.
5. Detect /goal and Workflow availability (per "Workflow availability" above); note the fallback that will apply if either is absent.
6. Switch to Plan Mode before continuing.

Phase 1 - Reconnaissance (parallel)

Dispatch in one batch:

1. discovery - codebase recon
2. checklist-curator - slice scoping + checklist diff proposal
3. rules-loader - project rules file + bytheslice.config.json resolution (returns the resolved verification.*, flow.*, review.default and delivery.* values that Workflow B, the build-plan and library gates, and the closeout consume)

Merge their reports into the Build Plan in Phase 2.

Phase 2 - Build Plan + User Authorization

Present a compact plan:

1. Active slice + slice name + slice type:
2. In-scope checklist items with acceptance tests (the slice's Exit criteria)
3. Out-of-scope items being deferred
4. Touched modules + blast-radius highlights
5. Sub-skill or pipeline that will run in Workflow A
6. Branch / worktree name
7. MCP availability + visual-review tools + resolved verification.viewports / verification.e2e.*
8. Forward-reference risks, open questions

Build-plan authorization (C9 - auto-approve under loop). End with one approval batch: the build-plan question "Authorize this build plan? (yes / edits / cancel)" plus every other approval this slice needs that is already known (see "Batched approvals" under HITL Handling), each a separate short question with a recommended answer. Wait for the answers. Workflow A does not start until the user says yes to the plan.

Skip this stop - proceed straight to Phase 2.5 - when EITHER:

• this /sell-slice is running under the /sell-pie loop (the pie-level autonomy already authorized the run), OR
• flow.autoApproveBuildPlan is true in the resolved config.

In the auto-approve case, log a one-line note instead of stopping: "Build plan auto-approved (<reason: /sell-pie loop | flow.autoApproveBuildPlan>); proceeding to Workflow A." - then continue. The plan is still rendered for the record; only the human stop is skipped. If the slice needs any other approval, the batch still goes out, minus the build-plan question; with nothing else to approve, there is no stop.

Always provide a recommended answer in available options when prompting.

If discovery surfaced ambiguous symbol locations, ask the user to clarify before re-dispatching, or proceed with their blessing (unless auto-approving, in which case proceed with the discovery default and note the assumption).

Phase 2.5 - Set slice-completion goal (conditional)

After build-plan authorization (or auto-approval) and before Phase 3, the orchestrator considers setting a session-scoped /goal for this slice. The goal's prompt-based Stop hook keeps the orchestrator moving through Workflow A → library gate → Workflow B → closeout without per-turn user re-prompting; HITL gates (Library Preview HARD STOP in Phase 4.5, the off-context fix loop in Workflow B) still end turns naturally and the evaluator returns "not yet" until they resolve.

Pre-check - parent goal coordination. Invoke /goal with no argument to read the current session-goal state.

• If a goal is already active, this skill is running under /sell-pie (or another wrapper). The parent goal subsumes the per-slice condition. Skip the slice-goal set and continue to Phase 3. Log: Parent session goal active (sell-pie); sell-slice will not set its own.
• If no goal is active, proceed to set the slice-goal below.
• If /goal is unavailable (Cursor, workspace-trust not accepted, disableAllHooks / allowManagedHooksOnly, or any other reason the slash command surfaces), fall back to the manual goal-tracking pattern in ../cook-pizzas/references/goal-fallback-pattern.md. Do NOT silently continue without a goal - the fallback is "manual tracking," not "no tracking." On activation: (a) WebFetch https://code.claude.com/docs/en/goal.md so the canonical evaluator pattern is in context, (b) build the same condition string this phase would have passed to /goal, (c) self-evaluate against the transcript after each phase completion (Workflow A → library gate → Workflow B → closeout), (d) surface a one-line progress note periodically. Log up front: "/goal is unavailable (<reason>); falling back to manual goal-tracking against the Exit criteria - see goal-fallback-pattern.md for the protocol."

Goal condition. The condition is lifted from the active slice's **Exit criteria:** block - the same block /cook-pizzas (or /special-order) wrote when the slice was scaffolded. The Exit-criteria contract (see ../cook-pizzas/references/templates.md → "Exit-criteria contract") guarantees every line is transcript-verifiable, binary, and specific to this slice.

Build the /goal condition string in this exact order:

1. Header - one sentence: Slice <SLICE_ID> (<slice name>) at <slice_file_path> is ready for review locally:
2. Lifted Exit criteria - copy every bullet from the slice's **Exit criteria:** block verbatim, preserving order. A (date-gated, on or after YYYY-MM-DD) line whose date is still ahead is replaced by master checklist Status line for slice <SLICE_ID> reads waiting until <YYYY-MM-DD>: <criterion>, so the goal can close without waiting. If the slice is backend / db-schema / infrastructure with zero UI surface (or a pure internal refactor with no rendered-output delta), drop the Library Preview Gate line if present.
3. Pipeline-level constraints - append exactly these three lines:
   • master checklist row for slice <SLICE_ID> in docs/plans/00_master_checklist.md shows Status: Completed
   • working tree clean on the slice branch: every task commit and the final slice commit pushed, no untracked or modified file the slice created; no PR opened (default mode)
   • Pause on any HITL bubble surfaced by the orchestrator (Library Preview Gate, fix-loop exhaustion, prd_ambiguity, external_credentials, destructive_operation, creative_direction)
4. Turn cap - append: Stop after 40 turns if not yet complete.

Missing Exit criteria block. If the slice file does NOT have a well-formed **Exit criteria:** block (or it contains vague non-transcript-verifiable lines like "tests pass" or "looks good"), do not invent one. Surface as prd_ambiguity HITL: "The slice plan at <path> is missing transcript-verifiable Exit criteria - /goal cannot be set with confidence. Re-open /cook-pizzas (or /special-order) to regenerate the slice with proper exit criteria per the contract, then re-authorize this build plan." If the user explicitly chooses to skip, proceed without a goal and continue phase-by-phase under manual prompting.

Invoke /goal <full condition string>. Log: Slice-completion goal set for slice <SLICE_ID> (lifted N lines from Exit criteria).

Clearing the goal:

• On normal Phase 6 closeout, the evaluator auto-clears the goal once the condition is met - no action needed.
• On a HITL bubble where the user abandons the slice (e.g. answers "cancel" to a re-dispatch prompt), the orchestrator MUST invoke /goal clear before returning control.
• On fix-loop exhaustion in Workflow B, the orchestrator bubbles HITL with full evidence - the goal stays active so the loop resumes if the user resolves it. Only clear the goal if the user explicitly abandons the slice.

Phase 3 - Branch / Worktree Setup

• Branch naming: feat/stage-<n>-<scope> | fix/stage-<n>-<scope> | chore/stage-<n>-<scope> (on a nested checklist, the slice commits land on the pie branch when running under /sell-pie; standalone /sell-slice uses the per-slice branch above).
• Never cut a branch before the Phase 0 collision check came back clean or the operator answered its HITL.
• Prefer a git worktree per active slice/pie, cut from the freshly-fetched origin/main (never local main, which may be stale): git fetch origin then git worktree add -b feat/stage-<n>-<scope> <path> origin/main. Never implement directly on main/master. Worktree setup, isolation, merge, and cleanup follow ../cook-pizzas/references/git-worktree-standard.md.
• Merge-per-slice mode: the branch is pie-N-sN.M-<scope> (on a flat checklist, feat/stage-<n>-<scope>), cut from freshly-fetched origin/main into its own worktree from the primary checkout (PRIMARY=$(git worktree list --porcelain | sed -n '1s/^worktree //p')): git -C "$PRIMARY" fetch origin, then git -C "$PRIMARY" worktree add -b pie-N-sN.M-<scope> <path> origin/main.
• Clean tree at every task boundary. Each ### Task K in the slice plan ends with a commit and a push: feat(pie-N): N.M task K <task name> (swap feat for fix/chore/docs to match the task; on a flat checklist, feat(stage-N): task K <task name>). The slice closes with one final commit, feat(pie-N): N.M <slice name>, carrying the checklist flip and any fix-loop patches. One slice per PR boundary, task commits inside. A slice may not end with an untracked or modified file it created.
• In the default pie-pr mode per-slice work does not open a PR (that is the pie boundary's job, handled by /box-it-up). Merge-per-slice mode opens the slice's own PR at closeout (Phase 6).

Phase 4 - Workflow A (produce)

Per the routing table above. The builder writes the slice + its unit tests and emits the build manifest (§Appendix A) on backend / full-stack / db-schema / infrastructure; on frontend no implementer runs and state-illustrator emits it at Phase 5.1. The builder runs gate tiers 1 and 2 only (see "Gate tiers"), does not behaviorally review its own work, and does not run the e2e suites (tier 3 is the slice-verifier's).

design-system / ci-cd / env-setup - Legacy sub-skill dispatch (v3 projects only)

Note: In v4/v5, foundation stages (design-system / ci-cd / env-setup) are no longer scaffolded as plan files by /cook-pizzas. New projects run /set-display-case, /final-quality-check, and /open-the-shop directly from the master checklist's Prep section - they don't pass through /sell-slice.

This path exists for legacy v3 projects whose checklist still has stage_1_*, stage_2_*, stage_3_* plan files. In that case, /sell-slice loads the corresponding foundation skill end-to-end as a sub-skill, records the artifacts, and proceeds to Workflow B. One-line note to the user: "Detected legacy type: <X> stage - dispatching /<new-name> as a sub-skill. v4/v5 projects skip this routing entirely."

Load the corresponding sub-skill SKILL.md and follow it end-to-end. The sub-skill returns the structured contract; the orchestrator records the artifacts and proceeds to Workflow B.

frontend - Internal frontend pipeline

Run as a Workflow; if Workflow is unavailable, fall back per loop-workflow-fallback-pattern.md.

1. modern-ux-expert writes docs/ux-spec-<slice>.md (UX strategy, 2-3 best-in-class references).
2. layout-architect, serial, only after step 1 returns: writes the route files and layout components, then appends ## Breakpoint Plan to the same spec. The two are not parallel. layout-architect reads the spec in full before it starts and appends to it at the end, so dispatched together its read finds no file and the two writes race; treating the pair as independent was the bug. If the spec is missing, layout-architect returns needs_human (prd_ambiguity) rather than designing from the PRD alone.
3. block-composer (always first among the compose step) → registries first: searches the UI sources resolved by references/ui-sources.md: the operator's own registry preferences (ui.registries in config or defaults, then components.json registries), else the healthy registries of the public shadcn registry directory, then stock shadcn, preferring a page over a block over a component, and installs every item that fits before anything is hand-written; reports ui_coverage_percent and registry_sources (which registry and item covered each surface). With no operator preference it uses the directory; with ui.useDirectory: false too, stock shadcn only.
4. component-crafter (only if block-composer reports gaps) → token-only custom components, built on the primitives already installed and the configured registry's token vocabulary; never hand-rolls a primitive a registry offers.

Pass ui.registries, ui.registryFirst, ui.useDirectory and ui.directoryTop from the resolved config to block-composer and component-crafter. Registry blocks are presentational and may ship a <name>.mock.ts sidecar: on a frontend slice block-composer moves its data behind the block's props and deletes the mock; a later slice that brings the real data source wires it through those same props. 5. Library Preview Gate (Phase 4.5) - see below.

Pass the slice's Exit criteria verbatim in every frontend producer's input contract: the steps above, library-entry-writer at Phase 4.5 and state-illustrator at Phase 5.1. Withholding the builder's reasoning from the tester is the point of context separation; withholding the shared standard from the builder never was. The slice-tester input list does not change.

The frontend producers do not write the four UI states or behaviorally verify - state-illustrator (Workflow B entry) fills the states and slice-tester does the rendered + affordance review. None of them emits the build manifest either. state-illustrator is the last step of the frontend path and its manifest emitter (Phase 5.1): it runs last, reads every implemented file in full, and derives the manifest from the files on disk.

backend / full-stack / db-schema / infrastructure - Internal builder

Run as a Workflow (pipeline() per item; independent items may parallel()); if Workflow is unavailable, fall back per loop-workflow-fallback-pattern.md. For each in-scope checklist item, in dependency order:

1. Dispatch the implementer (builder). For db-schema and full-stack involving DB: schema is updated FIRST in db/schema.sql (or detected equivalent) before any code. The builder returns its build report and the build manifest.
2. Dispatch spec-reviewer with the builder's output.
3. Dispatch quality-reviewer with both prior outputs.
4. If either reviewer returns verdict: fail, send findings back to a fresh builder dispatch and re-review. Repeat until both pass. A review fix is Workflow A work: label its dispatch with the review step (P<pie> S<slice> review: fix <finding>), never fix, including when a small one goes to fix-attempter. It counts against no fix cap; the 3 local fix loops start at Workflow B's first failing verdict.
5. Apply the curator's checklist diff for this item: flip [ ] → [x] only after both reviewers pass AND Workflow B is green for the slice.
6. Task boundary: commit + push (orchestrator only). Once the item's task clears both reviewers and the builder reported a green tier 2 (the task's own tests, build, and DB tests when the diff touched the schema or migrations), stage the builder's files_changed selectively (git add -- <paths>, never -A), then commit it on the slice branch as feat(pie-N): N.M task K <task name> and push, so the tree is clean before the next task starts. A DB-schema change lands first as its own chore(db): update schema for <item-id> commit. The orchestrator does not flip checklist rows until verification passes.

Independent items pipeline / parallelize. Items with no data dependency on each other may run as parallel() builder dispatches; dependent items chain in a pipeline(). Merge the per-item manifests into one slice manifest before Workflow B (the slice-level manifest is what slice-tester and slice-verifier consume).

Phase 4.5 - Library Preview Gate (human gate - stays)

Non-skippable, preview-first HARD STOP. Behavior is governed by flow.libraryGate (default "self-critique"):

• "human" - always stop for explicit human approval of net-new components (the full v4 hard gate, below).
• "self-critique" (default) - the agent self-reviews net-new components against the design system and proceeds without a human stop unless it flags a concern (then it surfaces the self-critique block + preview URLs and stops). Net-new components and consumer-side edits to user-visible surfaces still always route through library-entry-writer; only the unconditional human stop relaxes.
• "off" - skip the gate entirely (sensible only when the design-system Pie front-loaded all component approval).

Trigger. The gate fires whenever a slice (a) authors a new component or block, OR (b) modifies any user-visible surface of an existing library component (props, copy, content, variants, states, or styles) as it appears in a production route. In the modify case, the existing /library?tab=<id> entry must be updated to reflect the change and re-approved before the production-route edit lands. Pure internal refactors with no rendered-output delta are exempt.

Phase 0 - Should we even build this? library-entry-writer runs the extend-vs-create gate first. If it returns phase_0.build_decision: extend_existing or inline_in_consumer, stop and surface the recommendation (creative_direction HITL). The orchestrator pivots the slice scope before any new entry is written.

Dispatch library-entry-writer with one of two modes per item:

• mode: "new" for every component / block emitted by the compose/craft steps → appends a fresh entry: one file under _entries/<id>-entry.tsx, plus one line in LIBRARY_GROUPS in _registry/registry.tsx, rendering the full variants × states matrix.
• mode: "modify" for every existing library component whose user-visible surface changed under condition (b) → updates the existing _entries/<id>-entry.tsx in place with the delta, leaving the registry rows alone unless tags or name genuinely changed.

Both modes render all variants × all states (default / hover / focus / disabled / loading / empty / error / populated) AND wire the source-path copy buttons through <EntryHeader sourcePath=…> / <EntrySection sourcePath=… sourceLines=…>.

Design critique of new composite blocks. When the gate covers a net-new composite block (a section composed of several components: a table with toolbar, a card grid, a form section, a panel; not a single primitive like a button or badge), dispatch design-critic with scope: "block", the block's /library?tab=<id> URLs (at most 5), the context files (PRODUCT.md / DESIGN.md, or the design-system rules file) and the evidence folder .claude/.bytheslice-state/evidence/<N.M>/design-critique/. Fold its result into the self-critique block, per entry: the score line, P0 and P1 findings verbatim, and its open_questions. A P0 or P1 heuristic finding counts as a flagged concern, so in "self-critique" mode the gate stops for the operator instead of proceeding; P2 and P3 findings are listed and do not stop it. A finding tagged with a gate (a measured accessibility or design-system failure) and not marked advisory: true is not a concern for the operator: send it to component-crafter as a revision, with the finding as its note and no human stop, and re-run the critic in mode: "recheck" on that block (the finding counts as resolved only when it comes back fixed), inside the 2 revision loops below; one still failing after them is the third-round HITL, naming the gate as still failing. An advisory: true finding (its class is in gates.advisory) is listed in the self-critique block as an advisory warning and changes nothing: no revision, no stop. On revision, component-crafter gets the critic's findings the operator kept, and the re-run of 4.5 re-dispatches the critic. Skip the critique for single primitives, for modify-mode entries with no layout change, and when flow.libraryGate is "off".

Discover the dev port before surfacing URLs. Check in order: lsof -i -P | grep LISTEN | grep node (already-serving ports), package.json scripts.dev declared port, framework-specific port hints (next.config.js, proxy.ts). If still ambiguous, ask the user.

HARD STOP (when flow.libraryGate: "human", or "self-critique" flagged a concern). Surface a single Phase 4.5 prompt that embeds:

1. The self-critique block from library-entry-writer's output contract - skipped states, untested edge cases, close-but-not-exact tokens, untested compositions - verbatim, per entry, with the design-critic score, P0/P1 findings and open questions for each composite block, and its report path.
2. A clickable preview URL block, one line per entry, in the form http://localhost:<port>/library?tab=<id>, with a 1-line note on what's covered.
3. The explicit ask:

   "Library is updated. Self-critique above, preview URLs below. Click through, leave comments on anything that needs changing, and tell me whether each entry is approved, needs revision, or should be rejected before I wire <component name> into <production route>."

Do not start production wiring until the user explicitly approves (in "human" mode) or the self-critique cleared without concern (in "self-critique" mode). The cost asymmetry (rewriting a story file vs. rewriting story file + routes + server actions + types + tests) is what makes the gate worth enforcing.

• On approved → import the component from the library into the production route(s) named by the slice spec (or, in the modify case, land the consumer-route edit). The library entry files from the writer's files_changed are staged selectively and committed with their task at its boundary. Continue to Workflow B.
• On revision → re-dispatch component-crafter with the user's notes, then re-run 4.5 for the revised component (fresh self-critique). Cap at 2 revision loops; on the 3rd round, surface as creative_direction HITL and stop.
• On rejected → remove the entry: delete _entries/<id>-entry.tsx and remove its line from LIBRARY_GROUPS in _registry/registry.tsx (the single grouped registry set-display-case scaffolds). Surface as creative_direction HITL. Nothing from a rejected entry is wired into a production route.
• No production-route imports happen before approval. library-entry-writer's output contract requires production_imports_added: 0.

Hard rules:

• block-composer MUST run and report before component-crafter is considered. Never skip block composition.
• The library gate is non-skippable for net-new components AND for consumer-side edits to a user-visible surface of an existing library component. Library-first applies even to single-component slices and to "small" copy/prop changes.

Phase 5 - Workflow B (verify-once)

Run as a pipeline() Workflow; if Workflow is unavailable, fall back per loop-workflow-fallback-pattern.md. Workflow B replaces v4's Phases 6/7/8 (basic checks + aggregating test review + CI/CD guardrails) with two agents, each gate run exactly once.

The pipeline is state-illustrator → break-ui-runner → slice-tester → slice-verifier, with an off-context fix loop. break-ui-runner runs only on frontend / full-stack slices with data-bound UI (5.1b):

5.1 - state-illustrator (frontend / full-stack with UI only)

Dispatch state-illustrator to ensure every interactive production surface has loading / empty / error / success states. Skip for backend / db-schema / infrastructure with zero UI delta. (On a pure-backend slice, Workflow B starts at 5.2.)

On type: frontend this dispatch also emits the build manifest. Pass the slice id, the slice type and the implemented-files list, and take build_manifest off its return as the slice manifest for 5.2 and 5.3. It is one emission, not a second opinion: state-illustrator derives it from the files on disk, and slice-verifier re-derives its own count from the diff at 5.3, independently. The manifest stays in the conversation (no file holds it); stage the state files from its files_changed like any agent's.

• Fallback, mode: "manifest-only". When the build plan lists zero interactive surfaces for a frontend slice (a static route, a display-only page), there are no states to fill, but 5.2 and 5.3 still need a manifest. Dispatch state-illustrator with mode: "manifest-only": it skips the state work and returns build_manifest alone (routes and components declared, affordances empty). If its summary says the files on disk are not display-only, re-dispatch it in full mode.
• On full-stack, the implementer already emitted the manifest in Phase 4. state-illustrator fills states and returns only the affordances and transitions it added (or null); merge them into the implementer's manifest before 5.2, or the backstop at 5.3 counts them in the diff and reports an under-declaration the builder never caused.
• A frontend slice never reaches 5.2 without a manifest. If state-illustrator returns needs_human, or returns complete with an empty build_manifest, raise it as a prd_ambiguity HITL instead of running the tester against nothing. It is an operator question, not a fix-loop failure: it consumes none of the 3 local fix loops.

5.1b - break-ui-runner (worst-case data, data-bound UI only)

Run it when the slice is frontend or full-stack and renders variable data: tables, lists, cards, badges, avatars, breadcrumbs, counts. Skip it when the slice has no data-bound UI (state-illustrator returned data_switch: null) and say so in the Progress Report.

Boot the dev server (it stays up for 5.2) and dispatch break-ui-runner with the slice id and type, the build manifest from 5.1, state-illustrator's data_switch, the dev-server URL and the evidence folder .claude/.bytheslice-state/evidence/<N.M>/break-ui/. Context separation holds here too: never the builder's reasoning or chat. It measures every data-bound surface under ?data=demo|worst|empty|one|many at 1440, 768 and 390 wide with DOM reads, labels any check it inferred rather than ran (200% zoom, dark mode, RTL), and returns findings plus a report path.

• Routing. Broken and Ugly findings join the fix loop (5.4) as fix_targets, alongside any from 5.2 and 5.3; break-ui-runner has no counter of its own. Fragile findings and its "Decisions for you" are non-forcing warnings: list them in the Progress Report, and the default recommendation stands unless the operator overrides it. A finding tagged with a gate is never among them: it is at least Ugly and joins the fix loop (one marked advisory: true is listed as an advisory warning instead). It never sets the slice's verdict by itself.
• Report fallback. When its report_written is false (the host refused a subagent file write), write its report_markdown to report_path yourself, unchanged. The same holds for design-critic.
• Fixture writes. It may extend the fixture modules state-illustrator wrote (never a component); stage its files_changed like any agent's.
• Ledger note. Record one bts_note per run: break-ui <N.M>: <broken>/<ugly>/<fragile>, report <path>, so the PR evidence section carries it.

5.2 - slice-tester (behavioral verification)

Boot the dev server (frontend / full-stack) and dispatch slice-tester. Context-separation rule (absolute): pass the tester only the build manifest (on frontend, the one state-illustrator returned at 5.1; otherwise the implementer's) + the slice's Exit criteria + the design-system path (docs/design-system.md) + the dev-server URL + the slice type + the DB target. Never pass the builder's context, reasoning, or chat - the tester must falsify the manifest's claims, not trust the builder's narrative.

Pass through the config:

• verification.viewports (C7) - the widths the tester renders frontend slices at. Do not hardcode a viewport list; use the resolved config (default [375, 768, 1280]). Screenshots are taken only at 768 and 1280, one of each per new UI surface (see "Evidence, not proof ledgers").
• visualReview.tools - the ordered browser tooling priority.

The tester type-routes (frontend = rendered design-system match + per-affordance exercise; full-stack/backend = seed-and-cleanup data-flow with success and error toasts and the bidirectional rule on every surface; infrastructure = probe/harness). It returns the Appendix-B verdict (per-affordance + transitions + seed outcome).

Seed-and-cleanup is the tester's. It writes the cleanup script first, runs the non-prod guard (blocks + bubbles destructive_operation if the DB target is not demonstrably local/dev), seeds, runs round-trips, runs cleanup in a finally block, and asserts zero residue. The orchestrator never seeds the DB itself.

5.3 - slice-verifier (gate tier 3: the full local suite, once)

Dispatch slice-verifier with the slice diff (branch + base SHA), the build manifest (on frontend, state-illustrator's), the resolved verification.e2e.* thresholds (C10), quality.tier (standard | lean | auto) and delivery.mode (pie-pr | merge-per-slice | ship-once), the package manager + script names, the workflow inventory, and the slice type. This first pass is tier 3: the full local suite, one time. The builder's tier 1 and 2 results are narrower in scope and do not substitute for it.

It runs each atomic check once: lint · typecheck · build · unit/integration · e2e by tag (threshold-gated per verification.e2e - C10; lean: test:e2e:smoke only; ship-once: the generated CI workflows' commands, in full) · design-system static grep (raw values / non-token, plus the bundled verify-frontend-statics.sh sub-check under the same key - the static check only; the rendered match is the tester's) · CI-integrity (no existing gate weakened) · and the manifest under-declaration backstop (§1.4 - independently greps the diff for action( / use server / onClick / <form / route-file additions and fails if the manifest under-counts). It returns the Appendix-C verdict. Its statics findings fail design_system (E1 to E3) or a11y_static (E4, E5) and arrive as fix_targets like any gate failure, and each gates.declared command runs once as declared.<name>. Its warnings array holds only findings of a class the operator marked advisory and a statics run that could not resolve a token catalog: it never fails the slice and never enters the fix loop; list it in the Progress Report as advisory. On a frontend slice a declared total of zero is needs_human (prd_ambiguity), never pass: raise it as a HITL, not a fix-loop failure, so it consumes none of the 3 local fix loops.

5.4 - Off-context fix loop

If slice-tester.overall == fail OR slice-verifier.overall == fail OR break-ui-runner returned any Broken or Ugly finding, route the union of their fix_targets to the fixer off-context, without asking the operator first (the fixer gets the failing verdict + evidence, not the tester's or builder's full chat). When any fix target comes from break-ui-runner or design-critic, that loop's fixer is ui-fix-attempter (the same role, registered on opus) in place of fix-attempter, handling the whole union; the review agents themselves stay on sonnet. After the fix, re-dispatch break-ui-runner with mode: "recheck", its prior findings and the fix's files_changed; it re-measures only the surfaces those findings name.

Enabled gates go to the loop, never to the operator (references/quality-gates.md). Every fix_targets entry from a failing enabled gate (lint, typecheck, build, tests, e2e, design_system, a11y_static, declared.*, an a11y.* key, the rendered design-system match, a gate-tagged review finding) is routed here as is. Do not pause to ask whether to fix it, do not split it off as a follow-up, and do not drop it because its root cause is a shared design token, a global stylesheet or a file the slice only consumes: the fixer patches the cause where it lives. Each Workflow B fix dispatch carries the fix step in its label (P<pie> S<slice> fix: loop <n>). The only exits are the ones the rule names: a destructive fix, a missing secret, a new dependency (the approval batch), the cap below.

• 1st fail → fix-attempter with the failing verdict(s) + evidence → re-run only the failed half (re-dispatch slice-tester if a behavioral check failed; re-dispatch slice-verifier with its prior verdict and the fix's files_changed). Re-verification hard rule: slice-verifier carries every green check forward and re-runs only the gates the fix patch could change, chosen by the verifier from the fix diff, and lists each in its rerun: [{gate, reason}] field. The full suite never re-runs after any fix (1st, 2nd or 3rd).
• 2nd fail → debug-instrumenter adds targeted // INSTRUMENT logging and the failing check runs once to capture that output (evidence capture, not a verify) → fix-attempter with the richer evidence → re-verify.
• 3rd fail → fix-attempter once more with the full evidence: every prior verdict, the instrumentation output, and both earlier patches → re-verify.

Bail on a repeated error signature. Build each failing verdict's signature from its first fix_targets entry: normalize(first_error_line) + " | " + file + " | " + check_key, where check_key is the verdict key that failed (typecheck, an affordance, a11y.focus_visible) and normalize strips line and column numbers, absolute path prefixes and timestamps. It is a plain string held in this conversation and compared by string equality, never hashed and never written to a file. Pass the signature the last patch aimed at to fix-attempter as previous_signature (null on loop 1). Before starting loop 2 or 3 (before debug-instrumenter on loop 2), compare the new failure's signature with that one: if they are equal, the identical failure already survived a fix, so do not start another loop. Stop and bubble HITL (needs_human, bail_reason: repeated_signature) with the full evidence. fix-attempter runs the same comparison as a backstop and returns bail_reason: repeated_signature without patching. A bail uses up the loop it stopped; it never resets or extends the cap.

Revert a patch that regresses a green gate. After each re-verify, check for a regression before comparing signatures: a gate or tester check that was pass before the last patch and is fail after it. If there is one, restore that patch before any new fix is attempted, and do it yourself (the fixers run no git command): put the paths in the patch's files_changed back to the last commit (git restore --source=HEAD -- <paths>, deleting any file the patch created). Fix-loop patches stay uncommitted until the loop is green, so this is the usual case; a patch already committed is reverted with a new commit at the task boundary instead. An earlier loop's uncommitted patch on the same paths goes back with it. The next fix-attempter dispatch gets the regressed gates and every restored path, with previous_signature: null, because after the restore the failure it hands over is the pre-patch one, not a survivor of a fix. A revert refunds no loop.

Fix cap (hard, non-overridable): 3 local fix loops. A loop is one fix dispatch plus its re-verify, exactly the three above. Still failing after the 3rd loop → stop and bubble HITL with the full evidence (the goal stays active so the loop resumes if the user resolves it). The local counter is per slice and separate from the CI counter (3 ci-fix-attempter rounds per PR, owned by /box-it-up Phase 3a); neither borrows from the other. Run instructions never raise the cap: "continue until verified", "never stop", "fully automated" and similar wording do not grant attempts. Only the operator's explicit reply at the HITL can grant more (for example "two more loops"); each granted loop follows the same rules, and the full suite still never re-runs.

The fixers make no git writes: fix-attempter and debug-instrumenter return files_changed, and the orchestrator keeps the union for the final commit. After green, if debug-instrumenter ran, strip // INSTRUMENT lines. Fix-loop patches stay uncommitted until the loop is green; they land, instrumentation already stripped, in the slice's final commit (Phase 6), so no instrumentation ever reaches a commit.

Both verdicts must be pass (or a half legitimately skipped for the slice type) before the slice is considered verified. Do not flip the slice's checklist rows or proceed to closeout until then.

Phase 6 - Slice Closeout

When every in-scope item is [x] and Workflow B is green:

1. Flip slice status In Progress → Completed in $PLANS/00_master_checklist.md (the primary checkout's copy when the plans are gitignored, per git-worktree-standard.md, "Where the plans live"; in merge-per-slice mode with gitignored plans, make this flip only after the closeout reports the merge) (or, when the only unmet line is a date-gated criterion whose date is ahead, set **Status:** waiting until <YYYY-MM-DD>: <criterion> and leave the row [ ]; the slice stays open and a run on or after that date closes it), then make the slice's final commit on the slice branch, feat(pie-N): N.M <slice name> (closing narrative in the body for UI slices), carrying the flip and any fix-loop patches, and push it. Stage selectively: the checklist plus the fixers' files_changed, never git add -A. The conductor also stages state-illustrator's files_changed (the state files it wrote at 5.1). The checklist update comes before any PR. The flip rides in this final commit, before /box-it-up (or the merge-per-slice closeout) opens a PR. A later round on the same slice (client feedback, a review follow-up, a CI fix) updates the slice's **Status:** line in the same commit as the change, never in a separate cleanup after the PR; /box-it-up Phase 1 step 5 reconciles it once more before gh pr create, and the gh pr create hook warns when a slice-related branch leaves the checklist unchanged.
2. Confirm the slice branch has every commit it needs and the working tree is clean: git status --short empty, with no untracked or modified file the slice created. A leftover file is either committed with the slice (it belongs to it) or reported as a blocker; never leave it behind.
3. Walk the Completion Checklist (below). The slice is not "ready to ship" until every box up through §4 is [x].
4. Report to the user using the Progress Report Format, ending with the Handoff to /box-it-up message.

Merge-per-slice mode (opt-in) does not stop here. After steps 1-3, push the slice branch and run /box-it-up's Merge-per-slice closeout (--merge-slice) internally, passing the branch, worktree path, slice id and name: PR Slice N.M: <name>, CI, up to 3 ci-fix-attempter rounds (still red halts with a HITL; the slice is never skipped or merged red), merge on green with a merge commit, then cleanup from the primary checkout (pull --ff-only, worktree remove, branch -d, remote delete, worktree prune). No merge approval is asked; report the merged PR in one notice instead of the handoff below. If this was the pie's last slice, the closeout writes the kitchen merge record once.

Default pie-pr mode: this skill stops here - at "slice committed and pushed, ready for review." It pushes the slice branch at every task boundary and at the final commit, but does NOT open a PR, watch CI, merge, or clean up. That's /box-it-up's job - re-scoped in v5 to the pie boundary (per-slice = commit + push only; PR + CI + merge happen once at pie completion). Running standalone, this hand-off is intentionally separated so you can run a manual visual UAT, do a local code review, or rebase against fresh main before deciding to ship.

Handoff to /box-it-up

End your final message with:

Slice complete on branch <branch> - Workflow B green (slice-tester + slice-verifier both pass), master checklist updated, task commits and the slice commit pushed, tree clean.

Next: Review the diff at your pace (visual UAT, manual code review, anything else). When you're ready to ship, run /bytheslice:box-it-up. Per-slice it commits + pushes only; at the pie boundary it opens one PR Pie N, runs CI once, pauses for your merge approval, then merges (preserving per-slice commits) + syncs main + cleans up the branch and worktree.

If CI fails on the pie PR, /box-it-up's ci-fix-attempter applies targeted fixes for up to 3 attempts before bubbling to you - so the hand-off is genuinely "review and walk away" if you want it.

---

HITL Handling

If any subagent or sub-skill returns needs_human: true, the orchestrator pauses and uses ask_user_input_v0 to prompt the user. The answer is appended to the relevant context (PRD Section 6 for prd_ambiguity, project rules for credentials, etc.), then the dispatch is repeated.

Subagents NEVER prompt the user directly and NEVER call ask_user_input_v0. They set needs_human: true + the hitl_category / hitl_question / hitl_context fields; only the orchestrator calls ask_user_input_v0. This is the v5 contract - the prompting boundary lives at the orchestrator.

When raising a HITL and the bts_hitl tool is available, also call it; when the operator answers, call it again with the answer ({ id, answer }). It records the question, shows it in the Pass inbox and notifies; it never waits, so the stop-and-ask flow above still does.

Batched approvals. Collect every approval the slice needs (the build plan, migrations to apply, live data loads, size exceptions to the task or file cap, terms or licences to accept, credentials to supply) into one batch of short questions: one decision per question, each with a recommended answer. Ask the batch once, at slice start or at the first point all of them are known; never drip them one at a time across the slice. An approval that only surfaces later joins the next batch instead of stopping the slice on its own. Exception: the Library Preview gate (Phase 4.5) stays its own mid-slice stop, because it needs built output to review. Unforeseeable blocking events (fix cap exhausted, the slice-tester's non-prod guard, a rejected push) still stop when they happen.

Soft time budget. The slice has a soft wall-clock budget, delivery.sliceBudgetHours (default 3; 0 turns it off). It counts from the slice's start line in the run log, includes CI time (the merge-per-slice closeout waits on CI inside the slice), and excludes time spent waiting on the operator: the orchestrator writes each HITL ask and its answer to the run log and subtracts those windows. Check the elapsed time whenever an agent returns. When the budget is hit, never interrupt a running agent: let the current agent finish, then stop with one prd_ambiguity check-in carrying the slice's progress (tasks committed, gates green, fix loops used), the current blocker, and two options: extend (adds another sliceBudgetHours; recommended when the slice advanced since the last check-in) or stop (the slice stays In Progress with its task commits pushed; the next run resumes it). The budget is soft: it never fails a slice and never raises or lowers the fix cap. Under the /sell-pie loop the conductor owns this check.

A failing enabled gate is never a HITL. It is a fix target (5.4). Never raise one as creative_direction, prd_ambiguity or a batched approval, never ask "fix it or defer it?", and never report it as out of slice scope, app-wide or the operator's call. It reaches the operator only as the cap-exhaustion HITL, with the gate named as still failing after 3 loops, or when its fix is destructive or needs a secret. A gate class the operator listed in gates.advisory is reported as a warning instead.

The four blocking HITL categories halt the slice (they are not auto-resolvable): prd_ambiguity, external_credentials, destructive_operation (most commonly the slice-tester's non-prod guard blocking a seed), creative_direction (library gate). Any project-specific categories from hitl.additionalCategories surface the same way.

---

Evidence, not proof ledgers

No proof ledgers. No agent and no conductor writes artifact hashes, source freezes, fingerprint files, leases, or per-step proof files. The evidence a slice may leave is exactly:

• the verdict each agent returns (the Appendix A/B/C structured returns);
• Playwright traces, for failing checks only;
• the UI review reports under .claude/.bytheslice-state/evidence/<N.M>/ (gitignored): break-ui/report.md and design-critique/report.md, each with its own screenshots (break-ui: demo and worst at 1440 and 390 per surface, plus one per finding the measurement alone does not show; design-critic: 1440 and 390 per critiqued surface). They are review reports, not proof files, and their counts reach the PR through one bts_note each;
• one 1280px (desktop) and one 768px screenshot per new UI surface;
• a checklist note of 3 lines or fewer per slice in docs/plans/00_master_checklist.md;
• one short run log, .claude/.bytheslice-state/run-log.md (gitignored): slice start lines, HITL ask and answer times, one self-check line per dispatched agent, and slice PR and merge lines in merge-per-slice mode.

Existing operational state files stay, because they drive behavior rather than prove it: .claude/.bytheslice-state/kitchen/activity.jsonl, kitchen/merged-pie.json, env-check-passed, and the seed and cleanup pairs under tests/seeds/<slice>/. The closing-narrative paragraph in commit and PR bodies also stays; the 3-line limit applies to the checklist note only.

The one sanctioned exception: the Pass mod ledger. The Pass mod's .bytheslice/ledger.jsonl (docs/pass-mod-spec.md) is the single sanctioned completion record that tracks project progression over time. It is not a per-step proof file, and this rule does not ban it.

---

Progress Report Format

After each item and at slice closeout:

1. Checklist items completed (with file paths)
2. Files changed (grouped by package/app)
3. Verification results: builder tiers 1-2 (lint / typecheck / unit while coding; the slice's own tests / build / DB tests before each commit), slice-tester verdict (per-affordance + transitions + seed/cleanup outcome), slice-verifier verdict (each static gate + declared gates + manifest backstop counts + its advisory warnings, listed as advisory), break-ui-runner counts by severity with its report path, Fragile findings and decisions (or why it was skipped), and the design-critic score per composite block when the library gate ran
4. Subagent run summary (which roles ran, Workflow A review loops, Workflow B fix-loop activity)
5. Open risks / blockers. Never a failing enabled gate: by closeout every enabled gate passed (the slice is not complete otherwise), and a gate still failing after the fix cap is reported as that cap-exhaustion HITL, not as a risk, a follow-up or "your call"
6. Next recommended slice
7. Closing-narrative paragraph (UI-touching slices only) - one paragraph telling the design story: what was built · why this shape over alternatives (one or two trade-offs) · what was deliberately left out · what reviewers should pay attention to. The PR body lifts this paragraph verbatim. Without it, future readers reverse-engineer the design from the diff.

---

Hard Constraints

• Build plan must be authorized before any producer subagent runs - UNLESS running under the /sell-pie loop or flow.autoApproveBuildPlan is true (C9), in which case it is auto-approved and logged, not stopped.
• One slice per PR boundary, task commits inside; per-slice work opens no PR (default pie-pr mode). Every ### Task K ends with a commit + push; the slice ends with one feat(pie-N): N.M <slice name> commit and a clean tree. Never bundle multiple checklist items unless the user explicitly approves it in Phase 2. The PR is opened at the pie boundary by /box-it-up. Exception: merge-per-slice mode opens, CI-checks and merges the slice's own PR at closeout, with a merge commit and no per-slice merge approval.
• Context separation is absolute. The slice-tester receives ONLY the build manifest (the implementer's, or state-illustrator's on frontend) + Exit criteria + design-system path (+ dev URL / type / DB target). Never pass it the builder's reasoning or chat. The tester falsifies; it does not trust.
• Gates run by tier (see "Gate tiers"); the full local suite runs once per slice (C5). Tier 1 while coding, tier 2 before each commit, tier 3 once at slice end in slice-verifier, tier 4 in CI at the PR. Never demand the full ladder per task or per commit, and never bypass the pre-push hook with --no-verify.
• Viewports come from verification.viewports (C7); e2e thresholds from verification.e2e (C10). Never hardcode a viewport list or run an e2e suite the config gated "off".
• Checklist edits only after green gates. Do not optimistically mark items done - flip [ ] → [x] only after both reviewers pass AND Workflow B is green.
• Subagent prompts live in ./agents/*.md. This SKILL.md is workflow only - never inline subagent prompts here.
• Only the orchestrator makes git writes, git add included, on the registered and fallback paths alike. Agents return files_changed; the orchestrator stages those paths selectively, commits and pushes.
• Never modify other slice plan files during execution. Plans are static; deviations are noted inline in the checklist.
• HITL bubbling is mandatory and orchestrator-only. Subagents set needs_human + hitl_*; only the orchestrator calls ask_user_input_v0.
• Always provide a recommended answer in available options at every elicitation point.
• Workflow B gates the output summary. No "slice complete" report until both slice-tester and slice-verifier return pass (or a half is legitimately skipped for the slice type).
• Enabled quality gates are binding (gates.enforcement: "fix"). A failing enabled gate goes to the 5.4 fix loop without asking, root cause fixed where it lives (a shared token, a file the slice only consumes). It is never a HITL, never creative_direction, never a follow-up, never "out of slice scope" or "your call" in any report; only the operator's gates.advisory list turns a class into warnings.
• Strip // INSTRUMENT lines before final commit if debug-instrumenter ran.
• No proof ledgers. Never write artifact hashes, source freezes, fingerprint files, leases, or per-step proof files; the allowed evidence is listed in "Evidence, not proof ledgers". The Pass mod ledger is the one sanctioned exception.
• Fix cap: 3 local fix loops, 3 CI fix rounds, separate counters, non-overridable. No run instruction ("continue until verified", "never stop", "fully automated") raises either cap; only the operator's explicit reply at the HITL grants more attempts.
• The slice time budget is soft. At delivery.sliceBudgetHours the orchestrator lets the current agent finish, then checks in once (prd_ambiguity: extend or stop). It never kills an agent, fails a slice, or touches the fix cap.
• Session goal is set at most once per slice run, after Phase 2 authorization. Phase 2.5 enforces the parent-goal pre-check; if /sell-pie already set a pie-level goal, the slice-level goal is skipped. Never overwrite an active parent goal with a narrower slice-level condition.
• Workflow / /goal unavailable → fall back, never drop. In-context dispatch with orchestrator-side manual schema validation when Workflow is absent; manual goal-tracking when /goal is absent.

---

Completion Checklist

Run at the end of every slice. Do not report the slice "ready to ship" until every box up through §4 is [x]. Sections §5 (PR + CI) and §6 (cleanup) belong to /box-it-up (pie boundary) and are not this skill's responsibility.

1. Plan Tasks Complete

• [ ] Every in-scope checklist item from the active docs/plans/stage_<n>_*.md is implemented.
• [ ] Both spec-reviewer and quality-reviewer returned verdict: pass for each item.
• [ ] The builder (implementer, or state-illustrator on type: frontend) emitted a complete build manifest (§Appendix A) covering every route / affordance / serverAction / transition. A frontend slice with an empty manifest is a prd_ambiguity HITL, never a pass.
• [ ] Every task commit landed on a green tier 2 (the task's own tests, build, DB tests when the schema or migrations changed).
• [ ] slice-verifier returned overall: pass on its one tier-3 run - lint, typecheck, build, unit/integration, e2e (per verification.e2e), design-system static grep, CI-integrity, and the manifest under-declaration backstop all clear.
• [ ] break-ui-runner ran on every data-bound surface (or was skipped with a reason on a slice with no data-bound UI), its Broken and Ugly findings are fixed and re-checked, and its Fragile findings and decisions are listed.
• [ ] slice-tester returned overall: pass - every declared affordance exercised, every transition confirmed both directions on every surface, and (for data-flow slices) the seed cleaned up with zero residue.
• [ ] Every enabled gate passed, its failures fixed through the 5.4 loop (shared tokens and consumed files included); none was reported as a decision, a follow-up or out of scope, and only gates.advisory classes appear as warnings.
• [ ] No [ ] items remain in the active slice (deferred items moved out-of-scope with a note).
• [ ] If debug-instrumenter ran, every // INSTRUMENT line was stripped before final commit.

1a. Library Preview Gate (frontend / full-stack with UI only)

Skip only if the slice is type: backend, db-schema, or infrastructure with zero UI changes, OR the slice is a pure internal refactor with no rendered-output delta in any production route.

• [ ] library-entry-writer ran the Phase 0 extend-vs-create gate and reported build_decision for every dispatched item.
• [ ] Every component / block delivered in this slice has a /library?tab=<id> entry with all variants and states (default / hover / focus / disabled / loading / empty / error / populated).
• [ ] Every entry uses <EntryHeader sourcePath=…> and <EntrySection sourcePath=… sourceLines=…> so the page H1 and every state H3 render a working copy-Markdown-link button.
• [ ] Every new entry has its line in LIBRARY_GROUPS (_registry/registry.tsx). Modify-case entries leave that line alone unless name / tags genuinely changed.
• [ ] Every existing library component whose user-visible surface (props, copy, content, variants, states, or styles) changed in a production route has its /library?tab=<id> entry updated to reflect the change.
• [ ] Every net-new composite block got a design-critic pass (scope: "block") whose score, P0/P1 findings and open questions were embedded in the self-critique block; a P0 or P1 heuristic finding stopped the gate for the operator, a gate finding went to component-crafter without a stop, and an advisory: true finding was only listed.
• [ ] Library gate resolved per flow.libraryGate: in "human" mode the Phase 4.5 prompt embedded the self-critique block AND clickable preview URLs and the user approved before any production-route import; in "self-critique" mode the agent cleared its self-critique (or stopped on a flagged concern).
• [ ] No component imported into a production route, and no user-visible consumer-side edit committed, without library-first review.
• [ ] Closing-narrative paragraph (what was built · why this shape · what was left out · what reviewers should pay attention to) drafted for the PR description in §3 below.

2. Master Checklist Updated

• [ ] Every completed item is flipped [ ] → [x] in docs/plans/00_master_checklist.md.
• [ ] Slice status updated (Not Started → In Progress → Completed) to match reality.
• [ ] Slice-level exit criteria boxes ticked where satisfied.
• [ ] Inline notes added next to any item whose scope deviated from the plan (3 lines or fewer for the slice; see "Evidence, not proof ledgers").
• [ ] Edits committed on the slice branch (not on main).

3. Slice Committed and Pushed (ready for review)

• [ ] Branch follows naming: feat/ | fix/ | chore/ + stage-<n>-<scope> (or the pie branch under /sell-pie).
• [ ] Every task committed and pushed at its boundary (feat(pie-N): N.M task K <task name>); the final slice commit feat(pie-N): N.M <slice name> pushed; no untracked or modified file the slice created.
• [ ] slice-verifier returned verdict: pass, including its CI-integrity check (no existing workflow gate weakened) and the e2e coverage the pie-boundary CI will gate on.
• [ ] One slice per PR boundary, task commits inside. No bundling unless the user authorized it in Phase 2. (Default mode: commit + push; no PR yet.)

4. E2E / behavioral coverage (if applicable)

Skip only if the slice is documentation-only or has zero observable behavior change.

• [ ] New behavior covered by a @feature-tagged E2E spec (run/gated per verification.e2e.feature).
• [ ] Critical existing flows touched by this slice covered by @regression-core (per verification.e2e.regressionCore).
• [ ] For data-flow slices, the slice-tester persisted the seed + cleanup pair under tests/seeds/<slice>/ for pie-boundary CI reproducibility.
• [ ] .github/workflows/ feature gates trigger on: pull_request (so per-slice pushes stay cheap; CI fires once at the pie PR).

---

Handed off to /bytheslice:box-it-up - NOT this skill's responsibility

The following sections live in /bytheslice:box-it-up's Completion Checklist (now pie-scoped). They are listed here for cross-reference only; in the default pie-pr mode this skill does not run them. In merge-per-slice mode this skill runs the slice-scoped equivalent itself through /box-it-up --merge-slice (box-it-up's "Slice-merge mode" checklist).

5. PR open + CI green (handled by /box-it-up at the pie boundary)

• Pie branch pushed to origin; one PR Pie N open against main; PR URL surfaced.
• gh pr checks <pr> --watch returned exit 0 on the latest head SHA (CI runs once, at the pie PR).
• If the auto-fix loop ran, the final attempt cleared green.

6. Merge + Cleanup (handled by /box-it-up at the pie boundary)

• Merge authorized at the user gate; PR state is MERGED (per-slice commits preserved - rebase or merge-commit, not squash).
• Local main synced with --ff-only.
• Local + remote pie branch deleted.
• Worktree removed + pruned (one worktree per pie; per slice in merge-per-slice mode), from the primary checkout.
• git status --short empty; fully synced with origin/main.

---

Model Override

Subagents use model aliases (haiku, sonnet, opus) that auto-resolve to the latest version per provider. Override the mapping globally with these env vars:

ANTHROPIC_DEFAULT_HAIKU_MODEL=<model-id>
ANTHROPIC_DEFAULT_SONNET_MODEL=<model-id>
ANTHROPIC_DEFAULT_OPUS_MODEL=<model-id>
CLAUDE_CODE_SUBAGENT_MODEL=<model-id>   # overrides all sub-agent tiers at once

Per-agent overrides live in bytheslice.config.json → modelTiers (sliceTester, sliceVerifier are the v5 verification tiers). See skills/setup-shop/references/model-tier-guide.md for the full tier philosophy and per-provider alias resolution.