[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JK629AYG2B1NSSDYQAPWP2":3,"skill-same:01M6JK629AYG2B1NSSDYQAPWP2":189},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":69,"commitSha":70,"skillDirectory":71,"forksCount":72,"repositoryHtmlUrl":73,"repositoryHomepageUrl":6,"ownerHtmlUrl":74,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":75,"install":76,"resources":88},"01M6JK629AYG2B1NSSDYQAPWP2","sell-slice",null,"Sell a customer their slice - the high-touch single-slice delivery loop. Execute one slice from your master checklist as an interactive spine (prep gate · recon · build-plan auth · \u002Fgoal · branch) + Workflow A (produce) + library gate + Workflow B (verify-once). Run me repeatedly, one fresh chat per slice. For autonomous whole-pie baking use \u002Fsell-pie.","steve-piece\u002Fbytheslice","steve-piece","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F190656564?v=4","01M6JK3M1VYSHFKN1PW540DV5H","Steven Light","01M6JK3MDHEWS5WHC4H0RNKTD9",0,"MIT","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"sell","sell slice","slice","baking","deliver","checklist","build","high","chat","interactive","use","touch","for","as","ship","library","master","run","spine","plan","fresh","loop","branch","2026-11-10 10:12:30",false,"---\nname: sell-slice\ndescription: \"Sell a customer their slice - the high-touch single-slice delivery loop. Execute one slice from your master checklist as an interactive spine (prep gate · recon · build-plan auth · \u002Fgoal · branch) + Workflow A (produce) + library gate + Workflow B (verify-once). Run me repeatedly, one fresh chat per slice. For autonomous whole-pie baking use \u002Fsell-pie.\"\nuser-invocable: true\ntriggers: [\"\u002Fbytheslice:sell-slice\", \"\u002Fsell-slice\", \"sell a slice\", \"serve a customer\", \"bake the slice\", \"\u002Fbytheslice:deliver-stage\", \"\u002Fdeliver-stage\", \"deliver the next stage\", \"ship the next slice\", \"work the checklist\"]\n---\n\u003C!-- skills\u002Fsell-slice\u002FSKILL.md -->\n\u003C!-- 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 · \u002Fgoal · branch) wrapping Workflow A (produce - the builder\u002Fimplementer 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. \u002Fbox-it-up is the handoff. For autonomous whole-roadmap baking, \u002Fsell-pie loops one Pie unattended; \u002Fsell-slice is the careful per-slice surface. -->\n\n# \u002Fsell-slice - The High-Touch Single-Slice Delivery Loop\n\nThe 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.\n\n**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.\n\nRun `\u002Fsell-slice` → finish a slice → start a fresh chat → run again. Repeat until every row in `docs\u002Fplans\u002F00_master_checklist.md` is `[x]`. For **autonomous whole-pie baking** (the v5 forefront), see [`\u002Fsell-pie`](..\u002Fsell-pie\u002FSKILL.md) - it loops one Pie unattended and stops at the pie boundary; `\u002Fsell-slice` is the careful, collaborative single-slice surface. For mid-flight feature additions, see [`\u002Fspecial-order`](..\u002Fspecial-order\u002FSKILL.md) (it feeds into `sell-slice`).\n\n---\n\n## Mode detection\n\n`\u002Fsell-slice` is **sequential-only** - it requires a master checklist to know which slice to serve next. If `docs\u002Fplans\u002F00_master_checklist.md` is missing, the skill stops and points the user at [`\u002Fcook-pizzas`](..\u002Fcook-pizzas\u002FSKILL.md) (to generate one) or [`\u002Fspecial-order`](..\u002Fspecial-order\u002FSKILL.md) (to add a slice to an existing project).\n\n`\u002Fsell-slice` works on **both** layouts (dual-read):\n\n- **v5 nested** - `## Pie N` chapters containing `### Slice N.M` deliverables. `\u002Fsell-slice` serves one `### Slice N.M` at a time. (Whole-pie autonomous runs are `\u002Fsell-pie`'s job; `\u002Fsell-slice` stays at one slice even inside a nested checklist.)\n- **v4 \u002F legacy flat** - `## Stage N`. `\u002Fsell-slice` serves one stage at a time, exactly as it did pre-v5. (Unlike `\u002Fsell-pie`, which **refuses** a flat checklist, `\u002Fsell-slice` runs flat projects unchanged - no `--repie` required.)\n\nThroughout 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.\n\nThe 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.\n\n## Subagent Roster\n\nEvery dispatch description (Agent tool `description`, Workflow `label`) starts with `P\u003Cpie> S\u003Cslice> \u003Cstep>:` (for example `P4 S4.2 build: kitchen server`); `\u003Cstep>` is `prep`, `build`, `test`, `verify`, `fix`, `plate`, or `review`.\n\nEach subagent is a **registered plugin agent**; its definition file under `.\u002Fagents\u002F` carries the role prompt plus the `model` \u002F `effort` \u002F 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:\u003Cname>\"}` to `agent()`; direct dispatches use the Agent tool with `subagent_type: \"bytheslice:\u003Cname>\"`. 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`](..\u002Fcook-pizzas\u002Freferences\u002Floop-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.\n\n**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 -- \u003Cpaths>`, 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.\n\n### Core (every slice type)\n\n| Stage | Agent file | Model | Effort | Mode |\n|-------|-----------|-------|--------|------|\n| Recon | [agents\u002Fdiscovery.md](agents\u002Fdiscovery.md) | opus | medium | readonly |\n| Recon | [agents\u002Fchecklist-curator.md](agents\u002Fchecklist-curator.md) | sonnet | medium | readonly |\n| Recon | [agents\u002Frules-loader.md](agents\u002Frules-loader.md) | haiku | low | readonly |\n| Workflow A - produce (backend\u002Ffull-stack\u002Fdb-schema\u002Finfrastructure) | [agents\u002Fimplementer.md](agents\u002Fimplementer.md) (the **builder** - emits the build manifest on these types; `state-illustrator` emits it on `frontend`) | opus | medium | write |\n| Workflow A - per-item review | [agents\u002Fspec-reviewer.md](agents\u002Fspec-reviewer.md) | sonnet | medium | readonly |\n| Workflow A - per-item review | [agents\u002Fquality-reviewer.md](agents\u002Fquality-reviewer.md) | opus | medium | readonly |\n| Workflow B - verify-once (behavior) | [agents\u002Fslice-tester.md](agents\u002Fslice-tester.md) | sonnet | high | write |\n| Workflow B - verify-once (static gates, each once) | [agents\u002Fslice-verifier.md](agents\u002Fslice-verifier.md) | sonnet | high | write |\n| Fix loop (off-context) | [agents\u002Ffix-attempter.md](agents\u002Ffix-attempter.md) | sonnet | high | write |\n| Fix loop (2nd fail) | [agents\u002Fdebug-instrumenter.md](agents\u002Fdebug-instrumenter.md) | sonnet | high | write |\n| Fix loop, UI review findings (`break-ui-runner`, `design-critic`) | [agents\u002Ffrontend\u002Fui-fix-attempter.md](agents\u002Ffrontend\u002Fui-fix-attempter.md) | opus | medium | write |\n\n### Frontend pipeline (Workflow A, `type: frontend`)\n\n| Step | Agent file | Model | Mode |\n|------|-----------|-------|------|\n| UX strategy (first) | [agents\u002Ffrontend\u002Fmodern-ux-expert.md](agents\u002Ffrontend\u002Fmodern-ux-expert.md) | sonnet | write |\n| Layout (serial, after UX strategy returns) | [agents\u002Ffrontend\u002Flayout-architect.md](agents\u002Ffrontend\u002Flayout-architect.md) | sonnet | write |\n| Compose (always; configured registries first, then stock shadcn) | [agents\u002Ffrontend\u002Fblock-composer.md](agents\u002Ffrontend\u002Fblock-composer.md) | sonnet | write |\n| Craft (conditional on gaps) | [agents\u002Ffrontend\u002Fcomponent-crafter.md](agents\u002Ffrontend\u002Fcomponent-crafter.md) | sonnet | write |\n| Library Preview Gate | [agents\u002Ffrontend\u002Flibrary-entry-writer.md](agents\u002Ffrontend\u002Flibrary-entry-writer.md) | sonnet | write |\n| State coverage + dev data switch + **build manifest** emitter on `frontend` (Workflow B entry) | [agents\u002Ffrontend\u002Fstate-illustrator.md](agents\u002Ffrontend\u002Fstate-illustrator.md) | sonnet | write |\n| Worst-case data review (Workflow B 5.1b, data-bound UI only) | [agents\u002Ffrontend\u002Fbreak-ui-runner.md](agents\u002Ffrontend\u002Fbreak-ui-runner.md) | sonnet | readonly on source (writes its report and may extend fixtures) |\n| Design critique of new composite blocks (Library Preview Gate) | [agents\u002Ffrontend\u002Fdesign-critic.md](agents\u002Ffrontend\u002Fdesign-critic.md) | sonnet | readonly (writes its report) |\n\n> **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\u002Fvendor\u002F`](references\u002Fvendor\u002FREADME.md). 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).\n\n> **Behavioral + rendered review is `slice-tester`'s job; static gates are `slice-verifier`'s.** The rendered design-system match and the console\u002Fnetwork checks both run in `slice-tester`'s one behavioral pass.\n\n### Sub-skill dispatches (Workflow A, foundation slice types - legacy v3 projects only)\n\n| Slice `type` | Sub-skill (path) |\n|---|---|\n| `design-system` | [`skills\u002Fset-display-case\u002FSKILL.md`](..\u002Fset-display-case\u002FSKILL.md) |\n| `ci-cd` | [`skills\u002Ffinal-quality-check\u002FSKILL.md`](..\u002Ffinal-quality-check\u002FSKILL.md) |\n| `env-setup` | [`skills\u002Fopen-the-shop\u002FSKILL.md`](..\u002Fopen-the-shop\u002FSKILL.md) |\n\n---\n\n## Preconditions\n\n> 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.\n\n- `docs\u002Fplans\u002F00_master_checklist.md` exists.\n- One or more `docs\u002Fplans\u002Fstage_\u003Cn>_*.md` exist (one slice plan reachable for the active unit).\n- Clean git working tree, OR explicit user OK to proceed dirty.\n- 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\u002Fsession-collisions.md`](references\u002Fsession-collisions.md)).\n- Slice\u002Fstage plan files (`docs\u002Fplans\u002Fstage_*.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.\n\n---\n\n## Project Config\n\nIf `bytheslice.config.json` exists at the project root, the `rules-loader` agent (recon) reads it and returns resolved values. Honor:\n\n- `modelTiers.\u003Cagent>` - overrides the agent file's `model:` for THIS run (`sliceTester`, `sliceVerifier` are the v5 verification tiers).\n- `stages.maxTasksPerStage` - overrides the default cap of 6 (warn if user sets > 8).\n- `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.\n- `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.\n- `quality.tier` *(`\"standard\" | \"lean\" | \"auto\"`, default `\"standard\"`)* - the size of the installed quality line (see `\u002Ffinal-quality-check` \"Quality tier\"). Pass it to `slice-verifier` as given; it resolves `auto` itself.\n- `gates.enforcement` *(always `\"fix\"`)*, `gates.advisory` *(gate classes, default `[]`)*, `gates.declared` *(extra gates, default `[]`)* - **enabled quality gates are binding** ([`references\u002Fquality-gates.md`](references\u002Fquality-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.\n- `flow.autoApproveBuildPlan` *(bool, default `false`)* - when `true`, skip the build-plan authorization stop (**C9** - also **always** auto under the `\u002Fsell-pie` loop).\n- `flow.libraryGate` *(`\"self-critique\" | \"human\" | \"off\"`, default `\"self-critique\"`)* - controls the net-new-component library gate behavior (see Workflow A library gate).\n- `delivery.mode` *(`\"pie-pr\" | \"merge-per-slice\" | \"ship-once\"`, default `\"pie-pr\"`; `\"ship-once\"` is set by `\u002Fpizza-party` and drives `\u002Fsell-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 `\u002Fbox-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\"`.\n- `delivery.sliceBudgetHours` *(number, default `3`; `0` = off)* - the soft wall-clock budget for this slice (see \"Soft time budget\" under HITL Handling).\n- `mcps.*` - declarative MCP availability.\n- `visualReview.tools` - ordered tooling priority passed to `slice-tester`.\n\nSee [`skills\u002Fsetup-shop\u002Freferences\u002Fbytheslice-config-schema.md`](..\u002Fsetup-shop\u002Freferences\u002Fbytheslice-config-schema.md) for the full schema.\n\n---\n\n## Slice-Type Routing\n\nWorkflow A routes the work based on the active slice's `type:` frontmatter:\n\n| `type:` | Workflow A path |\n|---|---|\n| `design-system` | Dispatch the `set-display-case` sub-skill (legacy v3 only). Skip the internal builder. |\n| `ci-cd` | Dispatch the `final-quality-check` sub-skill (legacy v3 only). Skip the internal builder. |\n| `env-setup` | Dispatch the `open-the-shop` sub-skill (legacy v3 only). Skip the internal builder. |\n| `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). |\n| `backend` | Dispatch the internal `implementer` (builder). |\n| `full-stack` | Dispatch the internal `implementer` (covers both UI and API code). |\n| `db-schema` | Dispatch the internal `implementer` with DB context flag. Schema updated FIRST in `db\u002Fschema.sql` (or detected equivalent). |\n| `infrastructure` | Dispatch the internal `implementer`. |\n\nAfter Workflow A, **Workflow B** (verify-once) runs regardless of slice type, type-routed inside `slice-tester` (frontend = rendered + affordance UAT; full-stack\u002Fbackend = seed-and-cleanup data-flow; infrastructure = probe\u002Fharness).\n\n---\n\n## Gate tiers (what runs when)\n\nStatic 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.\n\n| Tier | When | Who runs it | What it runs |\n|---|---|---|---|\n| **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. |\n| **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. |\n| **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\u002Fintegration, 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. |\n| **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. |\n\n- **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.\n- **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.\n- **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.\n- `final-quality-check`'s `local-gates-runner` is a one-time scaffold validation outside this ladder and is unchanged.\n\n---\n\n## Workflow availability (CC-only primitives)\n\n`\u002Fgoal` and `Workflow` (`parallel()` \u002F `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:**\n\n- **`\u002Fgoal` unavailable** → fall back to the manual goal-tracking pattern in [`..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md) (Phase 2.5 below wires this in).\n- **`Workflow` unavailable** → fall back to **in-context dispatch with orchestrator-side manual schema validation** per [`..\u002Fcook-pizzas\u002Freferences\u002Floop-workflow-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Floop-workflow-fallback-pattern.md). Without `Workflow`'s built-in schema enforcement, the orchestrator MUST validate each subagent's structured return against its Appendix-A\u002FB\u002FC schema by hand before consuming it - otherwise enforcement is lost.\n\nThe house phrasing for any Workflow-backed step below is: *\"Run as a `Workflow` (`parallel()` \u002F `pipeline()`); if `Workflow` is unavailable, fall back per `loop-workflow-fallback-pattern.md`.\"*\n\n---\n\n## Workflow\n\nAt 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.\n\nThe skill is an **interactive spine** (Phases 0-3) wrapping two Workflows and one human gate:\n\n- **Spine:** prep gate (Phase 0) · recon (Phase 1) · build-plan auth (Phase 2, auto under loop \u002F `flow.autoApproveBuildPlan`) · `\u002Fgoal` (Phase 2.5) · branch (Phase 3).\n- **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 \u002F parallelize; frontend runs `modern-ux-expert`, then `layout-architect` serial after it.\n- **Library gate** (Phase 4.5, human): net-new-component preview-first approval.\n- **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.\n- **Closeout** (Phase 6).\n\n### Phase 0 - Orientation (interactive spine)\n\n1. Read `docs\u002Fplans\u002F00_master_checklist.md` and every `docs\u002Fplans\u002Fstage_*.md`. Detect the layout (nested `## Pie N` \u002F `### Slice N.M` vs flat `## Stage N`) - dual-read; both are valid.\n2. **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:\n   > *\"Prep step '`\u003Cunchecked line>`' is still pending. Run `\u003Cthe linked command>` first, then come back.\"*\n   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_*` \u002F `stage_2_*` \u002F `stage_3_*` plan files routed through Workflow A (see Legacy path note in Phase 4).\n3. Identify the **active slice**: first slice\u002Fstage with status `Not Started` or `In Progress`, unless the user named one. A slice whose `**Status:**` reads `waiting until \u003CYYYY-MM-DD>: \u003Ccriterion>` 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 `..\u002Fcook-pizzas\u002Freferences\u002Ftemplates.md` \"Calendar-gated criteria\").\n4. 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\u002F.bytheslice-state\u002Frun-log.md` (gitignored); the soft time budget counts from it. Under the `\u002Fsell-pie` loop the conductor already wrote it; do not write a second one.\n4a. **Collision check** ([`references\u002Fsession-collisions.md`](references\u002Fsession-collisions.md)). `git fetch --prune origin`, then `bts_claim { slice: \"N.M\", goal: \"\u003Cone line>\" }` (under the `\u002Fsell-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\" }`.\n5. Detect `\u002Fgoal` and `Workflow` availability (per \"Workflow availability\" above); note the fallback that will apply if either is absent.\n6. Switch to **Plan Mode** before continuing.\n\n### Phase 1 - Reconnaissance (parallel)\n\nDispatch in one batch:\n\n1. `discovery` - codebase recon\n2. `checklist-curator` - slice scoping + checklist diff proposal\n3. `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)\n\nMerge their reports into the Build Plan in Phase 2.\n\n### Phase 2 - Build Plan + User Authorization\n\nPresent a compact plan:\n\n1. Active slice + slice name + slice `type:`\n2. In-scope checklist items with acceptance tests (the slice's **Exit criteria**)\n3. Out-of-scope items being deferred\n4. Touched modules + blast-radius highlights\n5. Sub-skill or pipeline that will run in Workflow A\n6. Branch \u002F worktree name\n7. MCP availability + visual-review tools + resolved `verification.viewports` \u002F `verification.e2e.*`\n8. Forward-reference risks, open questions\n\n**Build-plan authorization (C9 - auto-approve under loop).** End with **one approval batch**: the build-plan question **\"Authorize this build plan? (yes \u002F edits \u002F 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.\n\n**Skip this stop - proceed straight to Phase 2.5 - when EITHER:**\n- this `\u002Fsell-slice` is running **under the `\u002Fsell-pie` loop** (the pie-level autonomy already authorized the run), OR\n- `flow.autoApproveBuildPlan` is `true` in the resolved config.\n\nIn the auto-approve case, log a one-line note instead of stopping: *\"Build plan auto-approved (`\u003Creason: \u002Fsell-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.\n\n**Always provide a recommended answer in available options** when prompting.\n\nIf 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).\n\n### Phase 2.5 - Set slice-completion goal (conditional)\n\nAfter build-plan authorization (or auto-approval) and before Phase 3, the orchestrator considers setting a session-scoped `\u002Fgoal` 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.\n\n**Pre-check - parent goal coordination.** Invoke `\u002Fgoal` with no argument to read the current session-goal state.\n\n- **If a goal is already active**, this skill is running under `\u002Fsell-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.`\n- **If no goal is active**, proceed to set the slice-goal below.\n- **If `\u002Fgoal` is unavailable** (Cursor, workspace-trust not accepted, `disableAllHooks` \u002F `allowManagedHooksOnly`, or any other reason the slash command surfaces), **fall back to the manual goal-tracking pattern** in [`..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md). Do NOT silently continue without a goal - the fallback is \"manual tracking,\" not \"no tracking.\" On activation: (a) WebFetch [`https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fgoal.md`](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fgoal.md) so the canonical evaluator pattern is in context, (b) build the same condition string this phase would have passed to `\u002Fgoal`, (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: *\"`\u002Fgoal` is unavailable (`\u003Creason>`); falling back to manual goal-tracking against the Exit criteria - see [goal-fallback-pattern.md](..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md) for the protocol.\"*\n\n**Goal condition.** The condition is **lifted from the active slice's `**Exit criteria:**` block** - the same block `\u002Fcook-pizzas` (or `\u002Fspecial-order`) wrote when the slice was scaffolded. The Exit-criteria contract (see [`..\u002Fcook-pizzas\u002Freferences\u002Ftemplates.md`](..\u002Fcook-pizzas\u002Freferences\u002Ftemplates.md) → \"Exit-criteria contract\") guarantees every line is transcript-verifiable, binary, and specific to this slice.\n\nBuild the `\u002Fgoal` condition string in this exact order:\n\n1. **Header** - one sentence: `Slice \u003CSLICE_ID> (\u003Cslice name>) at \u003Cslice_file_path> is ready for review locally:`\n2. **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 \u003CSLICE_ID> reads waiting until \u003CYYYY-MM-DD>: \u003Ccriterion>`, so the goal can close without waiting. If the slice is `backend` \u002F `db-schema` \u002F `infrastructure` with zero UI surface (or a pure internal refactor with no rendered-output delta), drop the Library Preview Gate line if present.\n3. **Pipeline-level constraints** - append exactly these three lines:\n   - `master checklist row for slice \u003CSLICE_ID> in docs\u002Fplans\u002F00_master_checklist.md shows Status: Completed`\n   - `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)`\n   - `Pause on any HITL bubble surfaced by the orchestrator (Library Preview Gate, fix-loop exhaustion, prd_ambiguity, external_credentials, destructive_operation, creative_direction)`\n4. **Turn cap** - append: `Stop after 40 turns if not yet complete.`\n\n**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 `\u003Cpath>` is missing transcript-verifiable Exit criteria - `\u002Fgoal` cannot be set with confidence. Re-open `\u002Fcook-pizzas` (or `\u002Fspecial-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.\n\nInvoke `\u002Fgoal \u003Cfull condition string>`. Log: `Slice-completion goal set for slice \u003CSLICE_ID> (lifted N lines from Exit criteria).`\n\n**Clearing the goal:**\n- On normal Phase 6 closeout, the evaluator auto-clears the goal once the condition is met - no action needed.\n- On a HITL bubble where the user abandons the slice (e.g. answers \"cancel\" to a re-dispatch prompt), the orchestrator MUST invoke `\u002Fgoal clear` before returning control.\n- 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.\n\n### Phase 3 - Branch \u002F Worktree Setup\n\n- Branch naming: `feat\u002Fstage-\u003Cn>-\u003Cscope>` | `fix\u002Fstage-\u003Cn>-\u003Cscope>` | `chore\u002Fstage-\u003Cn>-\u003Cscope>` (on a nested checklist, the slice commits land on the **pie branch** when running under `\u002Fsell-pie`; standalone `\u002Fsell-slice` uses the per-slice branch above).\n- Never cut a branch before the Phase 0 collision check came back clean or the operator answered its HITL.\n- Prefer a git worktree per active slice\u002Fpie, cut from the **freshly-fetched `origin\u002Fmain`** (never local `main`, which may be stale): `git fetch origin` then `git worktree add -b feat\u002Fstage-\u003Cn>-\u003Cscope> \u003Cpath> origin\u002Fmain`. Never implement directly on `main`\u002F`master`. Worktree setup, isolation, merge, and cleanup follow [`..\u002Fcook-pizzas\u002Freferences\u002Fgit-worktree-standard.md`](..\u002Fcook-pizzas\u002Freferences\u002Fgit-worktree-standard.md).\n- **Merge-per-slice mode:** the branch is `pie-N-sN.M-\u003Cscope>` (on a flat checklist, `feat\u002Fstage-\u003Cn>-\u003Cscope>`), cut from freshly-fetched `origin\u002Fmain` into its own worktree from the primary checkout (`PRIMARY=$(git worktree list --porcelain | sed -n '1s\u002F^worktree \u002F\u002Fp')`): `git -C \"$PRIMARY\" fetch origin`, then `git -C \"$PRIMARY\" worktree add -b pie-N-sN.M-\u003Cscope> \u003Cpath> origin\u002Fmain`.\n- **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 \u003Ctask name>` (swap `feat` for `fix`\u002F`chore`\u002F`docs` to match the task; on a flat checklist, `feat(stage-N): task K \u003Ctask name>`). The slice closes with one final commit, `feat(pie-N): N.M \u003Cslice 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.\n- In the default `pie-pr` mode per-slice work does **not** open a PR (that is the pie boundary's job, handled by `\u002Fbox-it-up`). Merge-per-slice mode opens the slice's own PR at closeout (Phase 6).\n\n### Phase 4 - Workflow A (produce)\n\nPer the routing table above. **The builder writes the slice + its unit tests and emits the build manifest** (§Appendix A) on `backend` \u002F `full-stack` \u002F `db-schema` \u002F `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).\n\n#### `design-system` \u002F `ci-cd` \u002F `env-setup` - Legacy sub-skill dispatch (v3 projects only)\n\n> **Note:** In v4\u002Fv5, foundation stages (design-system \u002F ci-cd \u002F env-setup) are no longer scaffolded as plan files by `\u002Fcook-pizzas`. New projects run `\u002Fset-display-case`, `\u002Ffinal-quality-check`, and `\u002Fopen-the-shop` directly from the master checklist's Prep section - they don't pass through `\u002Fsell-slice`.\n>\n> This path exists for **legacy v3 projects** whose checklist still has `stage_1_*`, `stage_2_*`, `stage_3_*` plan files. In that case, `\u002Fsell-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: \u003CX>` stage - dispatching `\u002F\u003Cnew-name>` as a sub-skill. v4\u002Fv5 projects skip this routing entirely.\"*\n\nLoad 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.\n\n#### `frontend` - Internal frontend pipeline\n\nRun as a `Workflow`; if `Workflow` is unavailable, fall back per `loop-workflow-fallback-pattern.md`.\n\n1. **`modern-ux-expert`** writes `docs\u002Fux-spec-\u003Cslice>.md` (UX strategy, 2-3 best-in-class references).\n2. **`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.\n3. **`block-composer`** (always first among the compose step) → **registries first**: searches the UI sources resolved by [`references\u002Fui-sources.md`](references\u002Fui-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.\n4. **`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.\n\n**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 `\u003Cname>.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.\n5. **Library Preview Gate (Phase 4.5)** - see below.\n\n**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.\n\nThe 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.\n\n#### `backend` \u002F `full-stack` \u002F `db-schema` \u002F `infrastructure` - Internal builder\n\nRun 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:\n\n1. Dispatch the **implementer** (builder). For `db-schema` and `full-stack` involving DB: schema is updated FIRST in `db\u002Fschema.sql` (or detected equivalent) before any code. The builder returns its build report **and the build manifest**.\n2. Dispatch **`spec-reviewer`** with the builder's output.\n3. Dispatch **`quality-reviewer`** with both prior outputs.\n4. 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\u003Cpie> S\u003Cslice> review: fix \u003Cfinding>`), 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.\n5. Apply the curator's checklist diff for this item: flip `[ ]` → `[x]` only after both reviewers pass AND Workflow B is green for the slice.\n6. **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 -- \u003Cpaths>`, never `-A`), then commit it on the slice branch as `feat(pie-N): N.M task K \u003Ctask 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 \u003Citem-id>` commit. The orchestrator does not flip checklist rows until verification passes.\n\n**Independent items pipeline \u002F 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).\n\n#### Phase 4.5 - Library Preview Gate (human gate - stays)\n\nNon-skippable, preview-first HARD STOP. Behavior is governed by `flow.libraryGate` (default `\"self-critique\"`):\n\n- `\"human\"` - always stop for explicit human approval of net-new components (the full v4 hard gate, below).\n- `\"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.\n- `\"off\"` - skip the gate entirely (sensible only when the design-system Pie front-loaded all component approval).\n\n**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 `\u002Flibrary?tab=\u003Cid>` 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.\n\n**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.\n\nDispatch `library-entry-writer` with one of two **modes** per item:\n- `mode: \"new\"` for every component \u002F block emitted by the compose\u002Fcraft steps → appends a fresh entry: one file under `_entries\u002F\u003Cid>-entry.tsx`, plus one line in `LIBRARY_GROUPS` in `_registry\u002Fregistry.tsx`, rendering the full variants × states matrix.\n- `mode: \"modify\"` for every existing library component whose user-visible surface changed under condition (b) → updates the existing `_entries\u002F\u003Cid>-entry.tsx` in place with the delta, leaving the registry rows alone unless tags or name genuinely changed.\n\nBoth modes render all variants × all states (default \u002F hover \u002F focus \u002F disabled \u002F loading \u002F empty \u002F error \u002F populated) AND wire the source-path copy buttons through `\u003CEntryHeader sourcePath=…>` \u002F `\u003CEntrySection sourcePath=… sourceLines=…>`.\n\n**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`](agents\u002Ffrontend\u002Fdesign-critic.md) with `scope: \"block\"`, the block's `\u002Flibrary?tab=\u003Cid>` URLs (at most 5), the context files (`PRODUCT.md` \u002F `DESIGN.md`, or the design-system rules file) and the evidence folder `.claude\u002F.bytheslice-state\u002Fevidence\u002F\u003CN.M>\u002Fdesign-critique\u002F`. 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\"`.\n\n**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.\n\n**HARD STOP** (when `flow.libraryGate: \"human\"`, or `\"self-critique\"` flagged a concern). Surface a single Phase 4.5 prompt that embeds:\n1. 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\u002FP1 findings and open questions for each composite block, and its report path.\n2. A **clickable preview URL block**, one line per entry, in the form `http:\u002F\u002Flocalhost:\u003Cport>\u002Flibrary?tab=\u003Cid>`, with a 1-line note on what's covered.\n3. The explicit ask:\n   > \"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 `\u003Ccomponent name>` into `\u003Cproduction route>`.\"\n\n**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.\n\n- 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.\n- 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.\n- On **rejected** → remove the entry: delete `_entries\u002F\u003Cid>-entry.tsx` and remove its line from `LIBRARY_GROUPS` in `_registry\u002Fregistry.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.\n- **No production-route imports happen before approval.** `library-entry-writer`'s output contract requires `production_imports_added: 0`.\n\n**Hard rules:**\n- `block-composer` MUST run and report before `component-crafter` is considered. Never skip block composition.\n- 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\u002Fprop changes.\n\n### Phase 5 - Workflow B (verify-once)\n\nRun as a `pipeline()` `Workflow`; if `Workflow` is unavailable, fall back per `loop-workflow-fallback-pattern.md`. **Workflow B replaces v4's Phases 6\u002F7\u002F8** (basic checks + aggregating test review + CI\u002FCD guardrails) with **two agents, each gate run exactly once.**\n\nThe pipeline is **`state-illustrator → break-ui-runner → slice-tester → slice-verifier`**, with an off-context fix loop. `break-ui-runner` runs only on `frontend` \u002F `full-stack` slices with data-bound UI (5.1b):\n\n#### 5.1 - `state-illustrator` (frontend \u002F full-stack with UI only)\n\nDispatch `state-illustrator` to ensure every interactive production surface has loading \u002F empty \u002F error \u002F success states. Skip for `backend` \u002F `db-schema` \u002F `infrastructure` with zero UI delta. (On a pure-backend slice, Workflow B starts at 5.2.)\n\n**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.\n\n- **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.\n- **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.\n- **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.\n\n#### 5.1b - `break-ui-runner` (worst-case data, data-bound UI only)\n\nRun 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.\n\nBoot the dev server (it stays up for 5.2) and dispatch [`break-ui-runner`](agents\u002Ffrontend\u002Fbreak-ui-runner.md) 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\u002F.bytheslice-state\u002Fevidence\u002F\u003CN.M>\u002Fbreak-ui\u002F`. **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.\n\n- **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.\n- **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`.\n- **Fixture writes.** It may extend the fixture modules `state-illustrator` wrote (never a component); stage its `files_changed` like any agent's.\n- **Ledger note.** Record one `bts_note` per run: `break-ui \u003CN.M>: \u003Cbroken>\u002F\u003Cugly>\u002F\u003Cfragile>, report \u003Cpath>`, so the PR evidence section carries it.\n\n#### 5.2 - `slice-tester` (behavioral verification)\n\nBoot the dev server (frontend \u002F full-stack) and dispatch [`slice-tester`](agents\u002Fslice-tester.md). **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\u002Fdesign-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.\n\nPass through the config:\n- **`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\").\n- **`visualReview.tools`** - the ordered browser tooling priority.\n\nThe tester type-routes (frontend = rendered design-system match + per-affordance exercise; full-stack\u002Fbackend = seed-and-cleanup data-flow with success **and** error toasts and the **bidirectional rule** on every surface; infrastructure = probe\u002Fharness). It returns the Appendix-B verdict (per-affordance + transitions + seed outcome).\n\n> **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\u002Fdev), seeds, runs round-trips, runs cleanup in a finally block, and asserts zero residue. The orchestrator never seeds the DB itself.\n\n#### 5.3 - `slice-verifier` (gate tier 3: the full local suite, once)\n\nDispatch [`slice-verifier`](agents\u002Fslice-verifier.md) 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.\n\nIt runs each atomic check once: lint · typecheck · build · unit\u002Fintegration · 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 \u002F 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(` \u002F `use server` \u002F `onClick` \u002F `\u003Cform` \u002F 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.\u003Cname>`. 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.\n\n#### 5.4 - Off-context fix loop\n\nIf `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`](agents\u002Ffrontend\u002Fui-fix-attempter.md)** (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.\n\n**Enabled gates go to the loop, never to the operator** ([`references\u002Fquality-gates.md`](references\u002Fquality-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\u003Cpie> S\u003Cslice> fix: loop \u003Cn>`). The only exits are the ones the rule names: a destructive fix, a missing secret, a new dependency (the approval batch), the cap below.\n\n- 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).\n- 2nd fail → `debug-instrumenter` adds targeted `\u002F\u002F 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.\n- 3rd fail → `fix-attempter` once more with the full evidence: every prior verdict, the instrumentation output, and both earlier patches → re-verify.\n\n**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.\n\n**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 -- \u003Cpaths>`, 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.\n\n**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 `\u002Fbox-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.\n\nThe 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 `\u002F\u002F 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.\n\n**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.\n\n### Phase 6 - Slice Closeout\n\nWhen every in-scope item is `[x]` and Workflow B is green:\n\n1. Flip slice status `In Progress` → `Completed` in `$PLANS\u002F00_master_checklist.md` (the primary checkout's copy when the plans are gitignored, per [`git-worktree-standard.md`, \"Where the plans live\"](..\u002Fcook-pizzas\u002Freferences\u002Fgit-worktree-standard.md); 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 \u003CYYYY-MM-DD>: \u003Ccriterion>` 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 \u003Cslice 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).\n   **The checklist update comes before any PR.** The flip rides in this final commit, before `\u002Fbox-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; `\u002Fbox-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.\n2. 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.\n3. Walk the **Completion Checklist** (below). The slice is not \"ready to ship\" until every box up through §4 is `[x]`.\n4. Report to the user using the **Progress Report Format**, ending with the **Handoff to `\u002Fbox-it-up`** message.\n\n**Merge-per-slice mode (opt-in) does not stop here.** After steps 1-3, push the slice branch and run [`\u002Fbox-it-up`](..\u002Fbox-it-up\u002FSKILL.md)'s **Merge-per-slice closeout** (`--merge-slice`) internally, passing the branch, worktree path, slice id and name: PR `Slice N.M: \u003Cname>`, 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.\n\n**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 [`\u002Fbox-it-up`](..\u002Fbox-it-up\u002FSKILL.md)'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.\n\n#### Handoff to `\u002Fbox-it-up`\n\nEnd your final message with:\n\n> Slice complete on branch `\u003Cbranch>` - Workflow B green (`slice-tester` + `slice-verifier` both `pass`), master checklist updated, task commits and the slice commit pushed, tree clean.\n>\n> **Next:** Review the diff at your pace (visual UAT, manual code review, anything else). When you're ready to ship, run [`\u002Fbytheslice:box-it-up`](..\u002Fbox-it-up\u002FSKILL.md). 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.\n>\n> If CI fails on the pie PR, `\u002Fbox-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.\n\n---\n\n## HITL Handling\n\nIf 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.\n\n**Subagents NEVER prompt the user directly and NEVER call `ask_user_input_v0`.** They set `needs_human: true` + the `hitl_category` \u002F `hitl_question` \u002F `hitl_context` fields; **only the orchestrator** calls `ask_user_input_v0`. This is the v5 contract - the prompting boundary lives at the orchestrator.\n\nWhen 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.\n\n**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.\n\n**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 `\u002Fsell-pie` loop the conductor owns this check.\n\n**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.\n\nThe 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.\n\n---\n\n## Evidence, not proof ledgers\n\n**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:\n\n- the verdict each agent returns (the Appendix A\u002FB\u002FC structured returns);\n- Playwright traces, for failing checks only;\n- the UI review reports under `.claude\u002F.bytheslice-state\u002Fevidence\u002F\u003CN.M>\u002F` (gitignored): `break-ui\u002Freport.md` and `design-critique\u002Freport.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;\n- one 1280px (desktop) and one 768px screenshot per new UI surface;\n- a checklist note of 3 lines or fewer per slice in `docs\u002Fplans\u002F00_master_checklist.md`;\n- one short run log, `.claude\u002F.bytheslice-state\u002Frun-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.\n\nExisting operational state files stay, because they drive behavior rather than prove it: `.claude\u002F.bytheslice-state\u002Fkitchen\u002Factivity.jsonl`, `kitchen\u002Fmerged-pie.json`, `env-check-passed`, and the seed and cleanup pairs under `tests\u002Fseeds\u002F\u003Cslice>\u002F`. The closing-narrative paragraph in commit and PR bodies also stays; the 3-line limit applies to the checklist note only.\n\n**The one sanctioned exception: the Pass mod ledger.** The Pass mod's `.bytheslice\u002Fledger.jsonl` ([`docs\u002Fpass-mod-spec.md`](..\u002F..\u002Fdocs\u002Fpass-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.\n\n---\n\n## Progress Report Format\n\nAfter each item and at slice closeout:\n\n1. Checklist items completed (with file paths)\n2. Files changed (grouped by package\u002Fapp)\n3. Verification results: builder tiers 1-2 (lint \u002F typecheck \u002F unit while coding; the slice's own tests \u002F build \u002F DB tests before each commit), `slice-tester` verdict (per-affordance + transitions + seed\u002Fcleanup 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\n4. Subagent run summary (which roles ran, Workflow A review loops, Workflow B fix-loop activity)\n5. Open risks \u002F 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\"\n6. Next recommended slice\n7. **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.\n\n---\n\n## Hard Constraints\n\n- **Build plan must be authorized** before any producer subagent runs - UNLESS running under the `\u002Fsell-pie` loop or `flow.autoApproveBuildPlan` is `true` (C9), in which case it is auto-approved and logged, not stopped.\n- **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 \u003Cslice 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 `\u002Fbox-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.\n- **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 \u002F type \u002F DB target). Never pass it the builder's reasoning or chat. The tester falsifies; it does not trust.\n- **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`.\n- **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\"`.\n- **Checklist edits only after green gates.** Do not optimistically mark items done - flip `[ ]` → `[x]` only after both reviewers pass AND Workflow B is green.\n- **Subagent prompts live in `.\u002Fagents\u002F*.md`.** This SKILL.md is workflow only - never inline subagent prompts here.\n- **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.\n- **Never modify other slice plan files** during execution. Plans are static; deviations are noted inline in the checklist.\n- **HITL bubbling is mandatory and orchestrator-only.** Subagents set `needs_human` + `hitl_*`; only the orchestrator calls `ask_user_input_v0`.\n- **Always provide a recommended answer in available options** at every elicitation point.\n- **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).\n- **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.\n- **Strip `\u002F\u002F INSTRUMENT` lines** before final commit if `debug-instrumenter` ran.\n- **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.\n- **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.\n- **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.\n- **Session goal is set at most once per slice run, after Phase 2 authorization.** Phase 2.5 enforces the parent-goal pre-check; if `\u002Fsell-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.\n- **`Workflow` \u002F `\u002Fgoal` unavailable → fall back, never drop.** In-context dispatch with orchestrator-side manual schema validation when `Workflow` is absent; manual goal-tracking when `\u002Fgoal` is absent.\n\n---\n\n## Completion Checklist\n\nRun 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 `\u002Fbox-it-up` (pie boundary) and are not this skill's responsibility.\n\n### 1. Plan Tasks Complete\n\n- [ ] Every in-scope checklist item from the active `docs\u002Fplans\u002Fstage_\u003Cn>_*.md` is implemented.\n- [ ] Both `spec-reviewer` and `quality-reviewer` returned `verdict: pass` for each item.\n- [ ] The builder (`implementer`, or `state-illustrator` on `type: frontend`) emitted a complete **build manifest** (§Appendix A) covering every route \u002F affordance \u002F serverAction \u002F transition. A `frontend` slice with an empty manifest is a `prd_ambiguity` HITL, never a pass.\n- [ ] Every task commit landed on a green tier 2 (the task's own tests, build, DB tests when the schema or migrations changed).\n- [ ] `slice-verifier` returned `overall: pass` on its one tier-3 run - lint, typecheck, build, unit\u002Fintegration, e2e (per `verification.e2e`), design-system static grep, CI-integrity, and the manifest under-declaration backstop all clear.\n- [ ] `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.\n- [ ] `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.\n- [ ] 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.\n- [ ] No `[ ]` items remain in the active slice (deferred items moved out-of-scope with a note).\n- [ ] If `debug-instrumenter` ran, every `\u002F\u002F INSTRUMENT` line was stripped before final commit.\n\n### 1a. Library Preview Gate (frontend \u002F full-stack with UI only)\n\nSkip 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.\n\n- [ ] `library-entry-writer` ran the Phase 0 extend-vs-create gate and reported `build_decision` for every dispatched item.\n- [ ] Every component \u002F block delivered in this slice has a `\u002Flibrary?tab=\u003Cid>` entry with all variants and states (default \u002F hover \u002F focus \u002F disabled \u002F loading \u002F empty \u002F error \u002F populated).\n- [ ] Every entry uses `\u003CEntryHeader sourcePath=…>` and `\u003CEntrySection sourcePath=… sourceLines=…>` so the page H1 and every state H3 render a working copy-Markdown-link button.\n- [ ] Every new entry has its line in `LIBRARY_GROUPS` (`_registry\u002Fregistry.tsx`). Modify-case entries leave that line alone unless `name` \u002F `tags` genuinely changed.\n- [ ] Every existing library component whose user-visible surface (props, copy, content, variants, states, or styles) changed in a production route has its `\u002Flibrary?tab=\u003Cid>` entry updated to reflect the change.\n- [ ] Every net-new composite block got a `design-critic` pass (`scope: \"block\"`) whose score, P0\u002FP1 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.\n- [ ] 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).\n- [ ] No component imported into a production route, and no user-visible consumer-side edit committed, without library-first review.\n- [ ] 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.\n\n### 2. Master Checklist Updated\n\n- [ ] Every completed item is flipped `[ ]` → `[x]` in `docs\u002Fplans\u002F00_master_checklist.md`.\n- [ ] Slice status updated (`Not Started` → `In Progress` → `Completed`) to match reality.\n- [ ] Slice-level exit criteria boxes ticked where satisfied.\n- [ ] 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\").\n- [ ] Edits committed on the slice branch (not on `main`).\n\n### 3. Slice Committed and Pushed (ready for review)\n\n- [ ] Branch follows naming: `feat\u002F` | `fix\u002F` | `chore\u002F` + `stage-\u003Cn>-\u003Cscope>` (or the pie branch under `\u002Fsell-pie`).\n- [ ] Every task committed and pushed at its boundary (`feat(pie-N): N.M task K \u003Ctask name>`); the final slice commit `feat(pie-N): N.M \u003Cslice name>` pushed; no untracked or modified file the slice created.\n- [ ] `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.\n- [ ] 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.)\n\n### 4. E2E \u002F behavioral coverage (if applicable)\n\nSkip only if the slice is documentation-only or has zero observable behavior change.\n\n- [ ] New behavior covered by a `@feature`-tagged E2E spec (run\u002Fgated per `verification.e2e.feature`).\n- [ ] Critical existing flows touched by this slice covered by `@regression-core` (per `verification.e2e.regressionCore`).\n- [ ] For data-flow slices, the `slice-tester` persisted the seed + cleanup pair under `tests\u002Fseeds\u002F\u003Cslice>\u002F` for pie-boundary CI reproducibility.\n- [ ] `.github\u002Fworkflows\u002F` feature gates trigger `on: pull_request` (so per-slice pushes stay cheap; CI fires once at the pie PR).\n\n---\n\n### Handed off to `\u002Fbytheslice:box-it-up` - NOT this skill's responsibility\n\nThe following sections live in [`\u002Fbytheslice:box-it-up`](..\u002Fbox-it-up\u002FSKILL.md)'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 `\u002Fbox-it-up --merge-slice` (box-it-up's \"Slice-merge mode\" checklist).\n\n#### 5. PR open + CI green (handled by `\u002Fbox-it-up` at the pie boundary)\n- Pie branch pushed to `origin`; one PR `Pie N` open against `main`; PR URL surfaced.\n- `gh pr checks \u003Cpr> --watch` returned exit 0 on the latest head SHA (CI runs once, at the pie PR).\n- If the auto-fix loop ran, the final attempt cleared green.\n\n#### 6. Merge + Cleanup (handled by `\u002Fbox-it-up` at the pie boundary)\n- Merge authorized at the user gate; PR state is `MERGED` (per-slice commits preserved - rebase or merge-commit, not squash).\n- Local `main` synced with `--ff-only`.\n- Local + remote pie branch deleted.\n- Worktree removed + pruned (one worktree per pie; per slice in merge-per-slice mode), from the primary checkout.\n- `git status --short` empty; fully synced with `origin\u002Fmain`.\n\n---\n\n## Model Override\n\nSubagents use model aliases (`haiku`, `sonnet`, `opus`) that auto-resolve to the latest version per provider. Override the mapping globally with these env vars:\n\n```\nANTHROPIC_DEFAULT_HAIKU_MODEL=\u003Cmodel-id>\nANTHROPIC_DEFAULT_SONNET_MODEL=\u003Cmodel-id>\nANTHROPIC_DEFAULT_OPUS_MODEL=\u003Cmodel-id>\nCLAUDE_CODE_SUBAGENT_MODEL=\u003Cmodel-id>   # overrides all sub-agent tiers at once\n```\n\nPer-agent overrides live in `bytheslice.config.json` → `modelTiers` (`sliceTester`, `sliceVerifier` are the v5 verification tiers). See [`skills\u002Fsetup-shop\u002Freferences\u002Fmodel-tier-guide.md`](..\u002Fsetup-shop\u002Freferences\u002Fmodel-tier-guide.md) for the full tier philosophy and per-provider alias resolution.\n","\u003C!-- skills\u002Fsell-slice\u002FSKILL.md -->\n\u003C!-- 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 · \u002Fgoal · branch) wrapping Workflow A (produce - the builder\u002Fimplementer 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. \u002Fbox-it-up is the handoff. For autonomous whole-roadmap baking, \u002Fsell-pie loops one Pie unattended; \u002Fsell-slice is the careful per-slice surface. -->\n\n# \u002Fsell-slice - The High-Touch Single-Slice Delivery Loop\n\nThe 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.\n\n**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.\n\nRun `\u002Fsell-slice` → finish a slice → start a fresh chat → run again. Repeat until every row in `docs\u002Fplans\u002F00_master_checklist.md` is `[x]`. For **autonomous whole-pie baking** (the v5 forefront), see [`\u002Fsell-pie`](..\u002Fsell-pie\u002FSKILL.md) - it loops one Pie unattended and stops at the pie boundary; `\u002Fsell-slice` is the careful, collaborative single-slice surface. For mid-flight feature additions, see [`\u002Fspecial-order`](..\u002Fspecial-order\u002FSKILL.md) (it feeds into `sell-slice`).\n\n---\n\n## Mode detection\n\n`\u002Fsell-slice` is **sequential-only** - it requires a master checklist to know which slice to serve next. If `docs\u002Fplans\u002F00_master_checklist.md` is missing, the skill stops and points the user at [`\u002Fcook-pizzas`](..\u002Fcook-pizzas\u002FSKILL.md) (to generate one) or [`\u002Fspecial-order`](..\u002Fspecial-order\u002FSKILL.md) (to add a slice to an existing project).\n\n`\u002Fsell-slice` works on **both** layouts (dual-read):\n\n- **v5 nested** - `## Pie N` chapters containing `### Slice N.M` deliverables. `\u002Fsell-slice` serves one `### Slice N.M` at a time. (Whole-pie autonomous runs are `\u002Fsell-pie`'s job; `\u002Fsell-slice` stays at one slice even inside a nested checklist.)\n- **v4 \u002F legacy flat** - `## Stage N`. `\u002Fsell-slice` serves one stage at a time, exactly as it did pre-v5. (Unlike `\u002Fsell-pie`, which **refuses** a flat checklist, `\u002Fsell-slice` runs flat projects unchanged - no `--repie` required.)\n\nThroughout 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.\n\nThe 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.\n\n## Subagent Roster\n\nEvery dispatch description (Agent tool `description`, Workflow `label`) starts with `P\u003Cpie> S\u003Cslice> \u003Cstep>:` (for example `P4 S4.2 build: kitchen server`); `\u003Cstep>` is `prep`, `build`, `test`, `verify`, `fix`, `plate`, or `review`.\n\nEach subagent is a **registered plugin agent**; its definition file under `.\u002Fagents\u002F` carries the role prompt plus the `model` \u002F `effort` \u002F 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:\u003Cname>\"}` to `agent()`; direct dispatches use the Agent tool with `subagent_type: \"bytheslice:\u003Cname>\"`. 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`](..\u002Fcook-pizzas\u002Freferences\u002Floop-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.\n\n**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 -- \u003Cpaths>`, 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.\n\n### Core (every slice type)\n\n| Stage | Agent file | Model | Effort | Mode |\n|-------|-----------|-------|--------|------|\n| Recon | [agents\u002Fdiscovery.md](agents\u002Fdiscovery.md) | opus | medium | readonly |\n| Recon | [agents\u002Fchecklist-curator.md](agents\u002Fchecklist-curator.md) | sonnet | medium | readonly |\n| Recon | [agents\u002Frules-loader.md](agents\u002Frules-loader.md) | haiku | low | readonly |\n| Workflow A - produce (backend\u002Ffull-stack\u002Fdb-schema\u002Finfrastructure) | [agents\u002Fimplementer.md](agents\u002Fimplementer.md) (the **builder** - emits the build manifest on these types; `state-illustrator` emits it on `frontend`) | opus | medium | write |\n| Workflow A - per-item review | [agents\u002Fspec-reviewer.md](agents\u002Fspec-reviewer.md) | sonnet | medium | readonly |\n| Workflow A - per-item review | [agents\u002Fquality-reviewer.md](agents\u002Fquality-reviewer.md) | opus | medium | readonly |\n| Workflow B - verify-once (behavior) | [agents\u002Fslice-tester.md](agents\u002Fslice-tester.md) | sonnet | high | write |\n| Workflow B - verify-once (static gates, each once) | [agents\u002Fslice-verifier.md](agents\u002Fslice-verifier.md) | sonnet | high | write |\n| Fix loop (off-context) | [agents\u002Ffix-attempter.md](agents\u002Ffix-attempter.md) | sonnet | high | write |\n| Fix loop (2nd fail) | [agents\u002Fdebug-instrumenter.md](agents\u002Fdebug-instrumenter.md) | sonnet | high | write |\n| Fix loop, UI review findings (`break-ui-runner`, `design-critic`) | [agents\u002Ffrontend\u002Fui-fix-attempter.md](agents\u002Ffrontend\u002Fui-fix-attempter.md) | opus | medium | write |\n\n### Frontend pipeline (Workflow A, `type: frontend`)\n\n| Step | Agent file | Model | Mode |\n|------|-----------|-------|------|\n| UX strategy (first) | [agents\u002Ffrontend\u002Fmodern-ux-expert.md](agents\u002Ffrontend\u002Fmodern-ux-expert.md) | sonnet | write |\n| Layout (serial, after UX strategy returns) | [agents\u002Ffrontend\u002Flayout-architect.md](agents\u002Ffrontend\u002Flayout-architect.md) | sonnet | write |\n| Compose (always; configured registries first, then stock shadcn) | [agents\u002Ffrontend\u002Fblock-composer.md](agents\u002Ffrontend\u002Fblock-composer.md) | sonnet | write |\n| Craft (conditional on gaps) | [agents\u002Ffrontend\u002Fcomponent-crafter.md](agents\u002Ffrontend\u002Fcomponent-crafter.md) | sonnet | write |\n| Library Preview Gate | [agents\u002Ffrontend\u002Flibrary-entry-writer.md](agents\u002Ffrontend\u002Flibrary-entry-writer.md) | sonnet | write |\n| State coverage + dev data switch + **build manifest** emitter on `frontend` (Workflow B entry) | [agents\u002Ffrontend\u002Fstate-illustrator.md](agents\u002Ffrontend\u002Fstate-illustrator.md) | sonnet | write |\n| Worst-case data review (Workflow B 5.1b, data-bound UI only) | [agents\u002Ffrontend\u002Fbreak-ui-runner.md](agents\u002Ffrontend\u002Fbreak-ui-runner.md) | sonnet | readonly on source (writes its report and may extend fixtures) |\n| Design critique of new composite blocks (Library Preview Gate) | [agents\u002Ffrontend\u002Fdesign-critic.md](agents\u002Ffrontend\u002Fdesign-critic.md) | sonnet | readonly (writes its report) |\n\n> **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\u002Fvendor\u002F`](references\u002Fvendor\u002FREADME.md). 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).\n\n> **Behavioral + rendered review is `slice-tester`'s job; static gates are `slice-verifier`'s.** The rendered design-system match and the console\u002Fnetwork checks both run in `slice-tester`'s one behavioral pass.\n\n### Sub-skill dispatches (Workflow A, foundation slice types - legacy v3 projects only)\n\n| Slice `type` | Sub-skill (path) |\n|---|---|\n| `design-system` | [`skills\u002Fset-display-case\u002FSKILL.md`](..\u002Fset-display-case\u002FSKILL.md) |\n| `ci-cd` | [`skills\u002Ffinal-quality-check\u002FSKILL.md`](..\u002Ffinal-quality-check\u002FSKILL.md) |\n| `env-setup` | [`skills\u002Fopen-the-shop\u002FSKILL.md`](..\u002Fopen-the-shop\u002FSKILL.md) |\n\n---\n\n## Preconditions\n\n> 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.\n\n- `docs\u002Fplans\u002F00_master_checklist.md` exists.\n- One or more `docs\u002Fplans\u002Fstage_\u003Cn>_*.md` exist (one slice plan reachable for the active unit).\n- Clean git working tree, OR explicit user OK to proceed dirty.\n- 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\u002Fsession-collisions.md`](references\u002Fsession-collisions.md)).\n- Slice\u002Fstage plan files (`docs\u002Fplans\u002Fstage_*.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.\n\n---\n\n## Project Config\n\nIf `bytheslice.config.json` exists at the project root, the `rules-loader` agent (recon) reads it and returns resolved values. Honor:\n\n- `modelTiers.\u003Cagent>` - overrides the agent file's `model:` for THIS run (`sliceTester`, `sliceVerifier` are the v5 verification tiers).\n- `stages.maxTasksPerStage` - overrides the default cap of 6 (warn if user sets > 8).\n- `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.\n- `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.\n- `quality.tier` *(`\"standard\" | \"lean\" | \"auto\"`, default `\"standard\"`)* - the size of the installed quality line (see `\u002Ffinal-quality-check` \"Quality tier\"). Pass it to `slice-verifier` as given; it resolves `auto` itself.\n- `gates.enforcement` *(always `\"fix\"`)*, `gates.advisory` *(gate classes, default `[]`)*, `gates.declared` *(extra gates, default `[]`)* - **enabled quality gates are binding** ([`references\u002Fquality-gates.md`](references\u002Fquality-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.\n- `flow.autoApproveBuildPlan` *(bool, default `false`)* - when `true`, skip the build-plan authorization stop (**C9** - also **always** auto under the `\u002Fsell-pie` loop).\n- `flow.libraryGate` *(`\"self-critique\" | \"human\" | \"off\"`, default `\"self-critique\"`)* - controls the net-new-component library gate behavior (see Workflow A library gate).\n- `delivery.mode` *(`\"pie-pr\" | \"merge-per-slice\" | \"ship-once\"`, default `\"pie-pr\"`; `\"ship-once\"` is set by `\u002Fpizza-party` and drives `\u002Fsell-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 `\u002Fbox-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\"`.\n- `delivery.sliceBudgetHours` *(number, default `3`; `0` = off)* - the soft wall-clock budget for this slice (see \"Soft time budget\" under HITL Handling).\n- `mcps.*` - declarative MCP availability.\n- `visualReview.tools` - ordered tooling priority passed to `slice-tester`.\n\nSee [`skills\u002Fsetup-shop\u002Freferences\u002Fbytheslice-config-schema.md`](..\u002Fsetup-shop\u002Freferences\u002Fbytheslice-config-schema.md) for the full schema.\n\n---\n\n## Slice-Type Routing\n\nWorkflow A routes the work based on the active slice's `type:` frontmatter:\n\n| `type:` | Workflow A path |\n|---|---|\n| `design-system` | Dispatch the `set-display-case` sub-skill (legacy v3 only). Skip the internal builder. |\n| `ci-cd` | Dispatch the `final-quality-check` sub-skill (legacy v3 only). Skip the internal builder. |\n| `env-setup` | Dispatch the `open-the-shop` sub-skill (legacy v3 only). Skip the internal builder. |\n| `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). |\n| `backend` | Dispatch the internal `implementer` (builder). |\n| `full-stack` | Dispatch the internal `implementer` (covers both UI and API code). |\n| `db-schema` | Dispatch the internal `implementer` with DB context flag. Schema updated FIRST in `db\u002Fschema.sql` (or detected equivalent). |\n| `infrastructure` | Dispatch the internal `implementer`. |\n\nAfter Workflow A, **Workflow B** (verify-once) runs regardless of slice type, type-routed inside `slice-tester` (frontend = rendered + affordance UAT; full-stack\u002Fbackend = seed-and-cleanup data-flow; infrastructure = probe\u002Fharness).\n\n---\n\n## Gate tiers (what runs when)\n\nStatic 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.\n\n| Tier | When | Who runs it | What it runs |\n|---|---|---|---|\n| **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. |\n| **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. |\n| **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\u002Fintegration, 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. |\n| **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. |\n\n- **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.\n- **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.\n- **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.\n- `final-quality-check`'s `local-gates-runner` is a one-time scaffold validation outside this ladder and is unchanged.\n\n---\n\n## Workflow availability (CC-only primitives)\n\n`\u002Fgoal` and `Workflow` (`parallel()` \u002F `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:**\n\n- **`\u002Fgoal` unavailable** → fall back to the manual goal-tracking pattern in [`..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md) (Phase 2.5 below wires this in).\n- **`Workflow` unavailable** → fall back to **in-context dispatch with orchestrator-side manual schema validation** per [`..\u002Fcook-pizzas\u002Freferences\u002Floop-workflow-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Floop-workflow-fallback-pattern.md). Without `Workflow`'s built-in schema enforcement, the orchestrator MUST validate each subagent's structured return against its Appendix-A\u002FB\u002FC schema by hand before consuming it - otherwise enforcement is lost.\n\nThe house phrasing for any Workflow-backed step below is: *\"Run as a `Workflow` (`parallel()` \u002F `pipeline()`); if `Workflow` is unavailable, fall back per `loop-workflow-fallback-pattern.md`.\"*\n\n---\n\n## Workflow\n\nAt 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.\n\nThe skill is an **interactive spine** (Phases 0-3) wrapping two Workflows and one human gate:\n\n- **Spine:** prep gate (Phase 0) · recon (Phase 1) · build-plan auth (Phase 2, auto under loop \u002F `flow.autoApproveBuildPlan`) · `\u002Fgoal` (Phase 2.5) · branch (Phase 3).\n- **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 \u002F parallelize; frontend runs `modern-ux-expert`, then `layout-architect` serial after it.\n- **Library gate** (Phase 4.5, human): net-new-component preview-first approval.\n- **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.\n- **Closeout** (Phase 6).\n\n### Phase 0 - Orientation (interactive spine)\n\n1. Read `docs\u002Fplans\u002F00_master_checklist.md` and every `docs\u002Fplans\u002Fstage_*.md`. Detect the layout (nested `## Pie N` \u002F `### Slice N.M` vs flat `## Stage N`) - dual-read; both are valid.\n2. **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:\n   > *\"Prep step '`\u003Cunchecked line>`' is still pending. Run `\u003Cthe linked command>` first, then come back.\"*\n   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_*` \u002F `stage_2_*` \u002F `stage_3_*` plan files routed through Workflow A (see Legacy path note in Phase 4).\n3. Identify the **active slice**: first slice\u002Fstage with status `Not Started` or `In Progress`, unless the user named one. A slice whose `**Status:**` reads `waiting until \u003CYYYY-MM-DD>: \u003Ccriterion>` 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 `..\u002Fcook-pizzas\u002Freferences\u002Ftemplates.md` \"Calendar-gated criteria\").\n4. 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\u002F.bytheslice-state\u002Frun-log.md` (gitignored); the soft time budget counts from it. Under the `\u002Fsell-pie` loop the conductor already wrote it; do not write a second one.\n4a. **Collision check** ([`references\u002Fsession-collisions.md`](references\u002Fsession-collisions.md)). `git fetch --prune origin`, then `bts_claim { slice: \"N.M\", goal: \"\u003Cone line>\" }` (under the `\u002Fsell-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\" }`.\n5. Detect `\u002Fgoal` and `Workflow` availability (per \"Workflow availability\" above); note the fallback that will apply if either is absent.\n6. Switch to **Plan Mode** before continuing.\n\n### Phase 1 - Reconnaissance (parallel)\n\nDispatch in one batch:\n\n1. `discovery` - codebase recon\n2. `checklist-curator` - slice scoping + checklist diff proposal\n3. `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)\n\nMerge their reports into the Build Plan in Phase 2.\n\n### Phase 2 - Build Plan + User Authorization\n\nPresent a compact plan:\n\n1. Active slice + slice name + slice `type:`\n2. In-scope checklist items with acceptance tests (the slice's **Exit criteria**)\n3. Out-of-scope items being deferred\n4. Touched modules + blast-radius highlights\n5. Sub-skill or pipeline that will run in Workflow A\n6. Branch \u002F worktree name\n7. MCP availability + visual-review tools + resolved `verification.viewports` \u002F `verification.e2e.*`\n8. Forward-reference risks, open questions\n\n**Build-plan authorization (C9 - auto-approve under loop).** End with **one approval batch**: the build-plan question **\"Authorize this build plan? (yes \u002F edits \u002F 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.\n\n**Skip this stop - proceed straight to Phase 2.5 - when EITHER:**\n- this `\u002Fsell-slice` is running **under the `\u002Fsell-pie` loop** (the pie-level autonomy already authorized the run), OR\n- `flow.autoApproveBuildPlan` is `true` in the resolved config.\n\nIn the auto-approve case, log a one-line note instead of stopping: *\"Build plan auto-approved (`\u003Creason: \u002Fsell-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.\n\n**Always provide a recommended answer in available options** when prompting.\n\nIf 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).\n\n### Phase 2.5 - Set slice-completion goal (conditional)\n\nAfter build-plan authorization (or auto-approval) and before Phase 3, the orchestrator considers setting a session-scoped `\u002Fgoal` 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.\n\n**Pre-check - parent goal coordination.** Invoke `\u002Fgoal` with no argument to read the current session-goal state.\n\n- **If a goal is already active**, this skill is running under `\u002Fsell-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.`\n- **If no goal is active**, proceed to set the slice-goal below.\n- **If `\u002Fgoal` is unavailable** (Cursor, workspace-trust not accepted, `disableAllHooks` \u002F `allowManagedHooksOnly`, or any other reason the slash command surfaces), **fall back to the manual goal-tracking pattern** in [`..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md). Do NOT silently continue without a goal - the fallback is \"manual tracking,\" not \"no tracking.\" On activation: (a) WebFetch [`https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fgoal.md`](https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fgoal.md) so the canonical evaluator pattern is in context, (b) build the same condition string this phase would have passed to `\u002Fgoal`, (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: *\"`\u002Fgoal` is unavailable (`\u003Creason>`); falling back to manual goal-tracking against the Exit criteria - see [goal-fallback-pattern.md](..\u002Fcook-pizzas\u002Freferences\u002Fgoal-fallback-pattern.md) for the protocol.\"*\n\n**Goal condition.** The condition is **lifted from the active slice's `**Exit criteria:**` block** - the same block `\u002Fcook-pizzas` (or `\u002Fspecial-order`) wrote when the slice was scaffolded. The Exit-criteria contract (see [`..\u002Fcook-pizzas\u002Freferences\u002Ftemplates.md`](..\u002Fcook-pizzas\u002Freferences\u002Ftemplates.md) → \"Exit-criteria contract\") guarantees every line is transcript-verifiable, binary, and specific to this slice.\n\nBuild the `\u002Fgoal` condition string in this exact order:\n\n1. **Header** - one sentence: `Slice \u003CSLICE_ID> (\u003Cslice name>) at \u003Cslice_file_path> is ready for review locally:`\n2. **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 \u003CSLICE_ID> reads waiting until \u003CYYYY-MM-DD>: \u003Ccriterion>`, so the goal can close without waiting. If the slice is `backend` \u002F `db-schema` \u002F `infrastructure` with zero UI surface (or a pure internal refactor with no rendered-output delta), drop the Library Preview Gate line if present.\n3. **Pipeline-level constraints** - append exactly these three lines:\n   - `master checklist row for slice \u003CSLICE_ID> in docs\u002Fplans\u002F00_master_checklist.md shows Status: Completed`\n   - `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)`\n   - `Pause on any HITL bubble surfaced by the orchestrator (Library Preview Gate, fix-loop exhaustion, prd_ambiguity, external_credentials, destructive_operation, creative_direction)`\n4. **Turn cap** - append: `Stop after 40 turns if not yet complete.`\n\n**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 `\u003Cpath>` is missing transcript-verifiable Exit criteria - `\u002Fgoal` cannot be set with confidence. Re-open `\u002Fcook-pizzas` (or `\u002Fspecial-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.\n\nInvoke `\u002Fgoal \u003Cfull condition string>`. Log: `Slice-completion goal set for slice \u003CSLICE_ID> (lifted N lines from Exit criteria).`\n\n**Clearing the goal:**\n- On normal Phase 6 closeout, the evaluator auto-clears the goal once the condition is met - no action needed.\n- On a HITL bubble where the user abandons the slice (e.g. answers \"cancel\" to a re-dispatch prompt), the orchestrator MUST invoke `\u002Fgoal clear` before returning control.\n- 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.\n\n### Phase 3 - Branch \u002F Worktree Setup\n\n- Branch naming: `feat\u002Fstage-\u003Cn>-\u003Cscope>` | `fix\u002Fstage-\u003Cn>-\u003Cscope>` | `chore\u002Fstage-\u003Cn>-\u003Cscope>` (on a nested checklist, the slice commits land on the **pie branch** when running under `\u002Fsell-pie`; standalone `\u002Fsell-slice` uses the per-slice branch above).\n- Never cut a branch before the Phase 0 collision check came back clean or the operator answered its HITL.\n- Prefer a git worktree per active slice\u002Fpie, cut from the **freshly-fetched `origin\u002Fmain`** (never local `main`, which may be stale): `git fetch origin` then `git worktree add -b feat\u002Fstage-\u003Cn>-\u003Cscope> \u003Cpath> origin\u002Fmain`. Never implement directly on `main`\u002F`master`. Worktree setup, isolation, merge, and cleanup follow [`..\u002Fcook-pizzas\u002Freferences\u002Fgit-worktree-standard.md`](..\u002Fcook-pizzas\u002Freferences\u002Fgit-worktree-standard.md).\n- **Merge-per-slice mode:** the branch is `pie-N-sN.M-\u003Cscope>` (on a flat checklist, `feat\u002Fstage-\u003Cn>-\u003Cscope>`), cut from freshly-fetched `origin\u002Fmain` into its own worktree from the primary checkout (`PRIMARY=$(git worktree list --porcelain | sed -n '1s\u002F^worktree \u002F\u002Fp')`): `git -C \"$PRIMARY\" fetch origin`, then `git -C \"$PRIMARY\" worktree add -b pie-N-sN.M-\u003Cscope> \u003Cpath> origin\u002Fmain`.\n- **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 \u003Ctask name>` (swap `feat` for `fix`\u002F`chore`\u002F`docs` to match the task; on a flat checklist, `feat(stage-N): task K \u003Ctask name>`). The slice closes with one final commit, `feat(pie-N): N.M \u003Cslice 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.\n- In the default `pie-pr` mode per-slice work does **not** open a PR (that is the pie boundary's job, handled by `\u002Fbox-it-up`). Merge-per-slice mode opens the slice's own PR at closeout (Phase 6).\n\n### Phase 4 - Workflow A (produce)\n\nPer the routing table above. **The builder writes the slice + its unit tests and emits the build manifest** (§Appendix A) on `backend` \u002F `full-stack` \u002F `db-schema` \u002F `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).\n\n#### `design-system` \u002F `ci-cd` \u002F `env-setup` - Legacy sub-skill dispatch (v3 projects only)\n\n> **Note:** In v4\u002Fv5, foundation stages (design-system \u002F ci-cd \u002F env-setup) are no longer scaffolded as plan files by `\u002Fcook-pizzas`. New projects run `\u002Fset-display-case`, `\u002Ffinal-quality-check`, and `\u002Fopen-the-shop` directly from the master checklist's Prep section - they don't pass through `\u002Fsell-slice`.\n>\n> This path exists for **legacy v3 projects** whose checklist still has `stage_1_*`, `stage_2_*`, `stage_3_*` plan files. In that case, `\u002Fsell-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: \u003CX>` stage - dispatching `\u002F\u003Cnew-name>` as a sub-skill. v4\u002Fv5 projects skip this routing entirely.\"*\n\nLoad 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.\n\n#### `frontend` - Internal frontend pipeline\n\nRun as a `Workflow`; if `Workflow` is unavailable, fall back per `loop-workflow-fallback-pattern.md`.\n\n1. **`modern-ux-expert`** writes `docs\u002Fux-spec-\u003Cslice>.md` (UX strategy, 2-3 best-in-class references).\n2. **`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.\n3. **`block-composer`** (always first among the compose step) → **registries first**: searches the UI sources resolved by [`references\u002Fui-sources.md`](references\u002Fui-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.\n4. **`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.\n\n**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 `\u003Cname>.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.\n5. **Library Preview Gate (Phase 4.5)** - see below.\n\n**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.\n\nThe 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.\n\n#### `backend` \u002F `full-stack` \u002F `db-schema` \u002F `infrastructure` - Internal builder\n\nRun 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:\n\n1. Dispatch the **implementer** (builder). For `db-schema` and `full-stack` involving DB: schema is updated FIRST in `db\u002Fschema.sql` (or detected equivalent) before any code. The builder returns its build report **and the build manifest**.\n2. Dispatch **`spec-reviewer`** with the builder's output.\n3. Dispatch **`quality-reviewer`** with both prior outputs.\n4. 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\u003Cpie> S\u003Cslice> review: fix \u003Cfinding>`), 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.\n5. Apply the curator's checklist diff for this item: flip `[ ]` → `[x]` only after both reviewers pass AND Workflow B is green for the slice.\n6. **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 -- \u003Cpaths>`, never `-A`), then commit it on the slice branch as `feat(pie-N): N.M task K \u003Ctask 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 \u003Citem-id>` commit. The orchestrator does not flip checklist rows until verification passes.\n\n**Independent items pipeline \u002F 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).\n\n#### Phase 4.5 - Library Preview Gate (human gate - stays)\n\nNon-skippable, preview-first HARD STOP. Behavior is governed by `flow.libraryGate` (default `\"self-critique\"`):\n\n- `\"human\"` - always stop for explicit human approval of net-new components (the full v4 hard gate, below).\n- `\"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.\n- `\"off\"` - skip the gate entirely (sensible only when the design-system Pie front-loaded all component approval).\n\n**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 `\u002Flibrary?tab=\u003Cid>` 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.\n\n**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.\n\nDispatch `library-entry-writer` with one of two **modes** per item:\n- `mode: \"new\"` for every component \u002F block emitted by the compose\u002Fcraft steps → appends a fresh entry: one file under `_entries\u002F\u003Cid>-entry.tsx`, plus one line in `LIBRARY_GROUPS` in `_registry\u002Fregistry.tsx`, rendering the full variants × states matrix.\n- `mode: \"modify\"` for every existing library component whose user-visible surface changed under condition (b) → updates the existing `_entries\u002F\u003Cid>-entry.tsx` in place with the delta, leaving the registry rows alone unless tags or name genuinely changed.\n\nBoth modes render all variants × all states (default \u002F hover \u002F focus \u002F disabled \u002F loading \u002F empty \u002F error \u002F populated) AND wire the source-path copy buttons through `\u003CEntryHeader sourcePath=…>` \u002F `\u003CEntrySection sourcePath=… sourceLines=…>`.\n\n**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`](agents\u002Ffrontend\u002Fdesign-critic.md) with `scope: \"block\"`, the block's `\u002Flibrary?tab=\u003Cid>` URLs (at most 5), the context files (`PRODUCT.md` \u002F `DESIGN.md`, or the design-system rules file) and the evidence folder `.claude\u002F.bytheslice-state\u002Fevidence\u002F\u003CN.M>\u002Fdesign-critique\u002F`. 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\"`.\n\n**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.\n\n**HARD STOP** (when `flow.libraryGate: \"human\"`, or `\"self-critique\"` flagged a concern). Surface a single Phase 4.5 prompt that embeds:\n1. 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\u002FP1 findings and open questions for each composite block, and its report path.\n2. A **clickable preview URL block**, one line per entry, in the form `http:\u002F\u002Flocalhost:\u003Cport>\u002Flibrary?tab=\u003Cid>`, with a 1-line note on what's covered.\n3. The explicit ask:\n   > \"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 `\u003Ccomponent name>` into `\u003Cproduction route>`.\"\n\n**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.\n\n- 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.\n- 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.\n- On **rejected** → remove the entry: delete `_entries\u002F\u003Cid>-entry.tsx` and remove its line from `LIBRARY_GROUPS` in `_registry\u002Fregistry.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.\n- **No production-route imports happen before approval.** `library-entry-writer`'s output contract requires `production_imports_added: 0`.\n\n**Hard rules:**\n- `block-composer` MUST run and report before `component-crafter` is considered. Never skip block composition.\n- 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\u002Fprop changes.\n\n### Phase 5 - Workflow B (verify-once)\n\nRun as a `pipeline()` `Workflow`; if `Workflow` is unavailable, fall back per `loop-workflow-fallback-pattern.md`. **Workflow B replaces v4's Phases 6\u002F7\u002F8** (basic checks + aggregating test review + CI\u002FCD guardrails) with **two agents, each gate run exactly once.**\n\nThe pipeline is **`state-illustrator → break-ui-runner → slice-tester → slice-verifier`**, with an off-context fix loop. `break-ui-runner` runs only on `frontend` \u002F `full-stack` slices with data-bound UI (5.1b):\n\n#### 5.1 - `state-illustrator` (frontend \u002F full-stack with UI only)\n\nDispatch `state-illustrator` to ensure every interactive production surface has loading \u002F empty \u002F error \u002F success states. Skip for `backend` \u002F `db-schema` \u002F `infrastructure` with zero UI delta. (On a pure-backend slice, Workflow B starts at 5.2.)\n\n**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.\n\n- **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.\n- **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.\n- **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.\n\n#### 5.1b - `break-ui-runner` (worst-case data, data-bound UI only)\n\nRun 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.\n\nBoot the dev server (it stays up for 5.2) and dispatch [`break-ui-runner`](agents\u002Ffrontend\u002Fbreak-ui-runner.md) 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\u002F.bytheslice-state\u002Fevidence\u002F\u003CN.M>\u002Fbreak-ui\u002F`. **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.\n\n- **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.\n- **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`.\n- **Fixture writes.** It may extend the fixture modules `state-illustrator` wrote (never a component); stage its `files_changed` like any agent's.\n- **Ledger note.** Record one `bts_note` per run: `break-ui \u003CN.M>: \u003Cbroken>\u002F\u003Cugly>\u002F\u003Cfragile>, report \u003Cpath>`, so the PR evidence section carries it.\n\n#### 5.2 - `slice-tester` (behavioral verification)\n\nBoot the dev server (frontend \u002F full-stack) and dispatch [`slice-tester`](agents\u002Fslice-tester.md). **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\u002Fdesign-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.\n\nPass through the config:\n- **`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\").\n- **`visualReview.tools`** - the ordered browser tooling priority.\n\nThe tester type-routes (frontend = rendered design-system match + per-affordance exercise; full-stack\u002Fbackend = seed-and-cleanup data-flow with success **and** error toasts and the **bidirectional rule** on every surface; infrastructure = probe\u002Fharness). It returns the Appendix-B verdict (per-affordance + transitions + seed outcome).\n\n> **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\u002Fdev), seeds, runs round-trips, runs cleanup in a finally block, and asserts zero residue. The orchestrator never seeds the DB itself.\n\n#### 5.3 - `slice-verifier` (gate tier 3: the full local suite, once)\n\nDispatch [`slice-verifier`](agents\u002Fslice-verifier.md) 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.\n\nIt runs each atomic check once: lint · typecheck · build · unit\u002Fintegration · 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 \u002F 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(` \u002F `use server` \u002F `onClick` \u002F `\u003Cform` \u002F 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.\u003Cname>`. 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.\n\n#### 5.4 - Off-context fix loop\n\nIf `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`](agents\u002Ffrontend\u002Fui-fix-attempter.md)** (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.\n\n**Enabled gates go to the loop, never to the operator** ([`references\u002Fquality-gates.md`](references\u002Fquality-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\u003Cpie> S\u003Cslice> fix: loop \u003Cn>`). The only exits are the ones the rule names: a destructive fix, a missing secret, a new dependency (the approval batch), the cap below.\n\n- 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).\n- 2nd fail → `debug-instrumenter` adds targeted `\u002F\u002F 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.\n- 3rd fail → `fix-attempter` once more with the full evidence: every prior verdict, the instrumentation output, and both earlier patches → re-verify.\n\n**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.\n\n**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 -- \u003Cpaths>`, 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.\n\n**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 `\u002Fbox-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.\n\nThe 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 `\u002F\u002F 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.\n\n**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.\n\n### Phase 6 - Slice Closeout\n\nWhen every in-scope item is `[x]` and Workflow B is green:\n\n1. Flip slice status `In Progress` → `Completed` in `$PLANS\u002F00_master_checklist.md` (the primary checkout's copy when the plans are gitignored, per [`git-worktree-standard.md`, \"Where the plans live\"](..\u002Fcook-pizzas\u002Freferences\u002Fgit-worktree-standard.md); 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 \u003CYYYY-MM-DD>: \u003Ccriterion>` 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 \u003Cslice 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).\n   **The checklist update comes before any PR.** The flip rides in this final commit, before `\u002Fbox-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; `\u002Fbox-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.\n2. 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.\n3. Walk the **Completion Checklist** (below). The slice is not \"ready to ship\" until every box up through §4 is `[x]`.\n4. Report to the user using the **Progress Report Format**, ending with the **Handoff to `\u002Fbox-it-up`** message.\n\n**Merge-per-slice mode (opt-in) does not stop here.** After steps 1-3, push the slice branch and run [`\u002Fbox-it-up`](..\u002Fbox-it-up\u002FSKILL.md)'s **Merge-per-slice closeout** (`--merge-slice`) internally, passing the branch, worktree path, slice id and name: PR `Slice N.M: \u003Cname>`, 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.\n\n**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 [`\u002Fbox-it-up`](..\u002Fbox-it-up\u002FSKILL.md)'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.\n\n#### Handoff to `\u002Fbox-it-up`\n\nEnd your final message with:\n\n> Slice complete on branch `\u003Cbranch>` - Workflow B green (`slice-tester` + `slice-verifier` both `pass`), master checklist updated, task commits and the slice commit pushed, tree clean.\n>\n> **Next:** Review the diff at your pace (visual UAT, manual code review, anything else). When you're ready to ship, run [`\u002Fbytheslice:box-it-up`](..\u002Fbox-it-up\u002FSKILL.md). 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.\n>\n> If CI fails on the pie PR, `\u002Fbox-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.\n\n---\n\n## HITL Handling\n\nIf 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.\n\n**Subagents NEVER prompt the user directly and NEVER call `ask_user_input_v0`.** They set `needs_human: true` + the `hitl_category` \u002F `hitl_question` \u002F `hitl_context` fields; **only the orchestrator** calls `ask_user_input_v0`. This is the v5 contract - the prompting boundary lives at the orchestrator.\n\nWhen 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.\n\n**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.\n\n**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 `\u002Fsell-pie` loop the conductor owns this check.\n\n**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.\n\nThe 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.\n\n---\n\n## Evidence, not proof ledgers\n\n**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:\n\n- the verdict each agent returns (the Appendix A\u002FB\u002FC structured returns);\n- Playwright traces, for failing checks only;\n- the UI review reports under `.claude\u002F.bytheslice-state\u002Fevidence\u002F\u003CN.M>\u002F` (gitignored): `break-ui\u002Freport.md` and `design-critique\u002Freport.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;\n- one 1280px (desktop) and one 768px screenshot per new UI surface;\n- a checklist note of 3 lines or fewer per slice in `docs\u002Fplans\u002F00_master_checklist.md`;\n- one short run log, `.claude\u002F.bytheslice-state\u002Frun-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.\n\nExisting operational state files stay, because they drive behavior rather than prove it: `.claude\u002F.bytheslice-state\u002Fkitchen\u002Factivity.jsonl`, `kitchen\u002Fmerged-pie.json`, `env-check-passed`, and the seed and cleanup pairs under `tests\u002Fseeds\u002F\u003Cslice>\u002F`. The closing-narrative paragraph in commit and PR bodies also stays; the 3-line limit applies to the checklist note only.\n\n**The one sanctioned exception: the Pass mod ledger.** The Pass mod's `.bytheslice\u002Fledger.jsonl` ([`docs\u002Fpass-mod-spec.md`](..\u002F..\u002Fdocs\u002Fpass-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.\n\n---\n\n## Progress Report Format\n\nAfter each item and at slice closeout:\n\n1. Checklist items completed (with file paths)\n2. Files changed (grouped by package\u002Fapp)\n3. Verification results: builder tiers 1-2 (lint \u002F typecheck \u002F unit while coding; the slice's own tests \u002F build \u002F DB tests before each commit), `slice-tester` verdict (per-affordance + transitions + seed\u002Fcleanup 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\n4. Subagent run summary (which roles ran, Workflow A review loops, Workflow B fix-loop activity)\n5. Open risks \u002F 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\"\n6. Next recommended slice\n7. **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.\n\n---\n\n## Hard Constraints\n\n- **Build plan must be authorized** before any producer subagent runs - UNLESS running under the `\u002Fsell-pie` loop or `flow.autoApproveBuildPlan` is `true` (C9), in which case it is auto-approved and logged, not stopped.\n- **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 \u003Cslice 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 `\u002Fbox-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.\n- **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 \u002F type \u002F DB target). Never pass it the builder's reasoning or chat. The tester falsifies; it does not trust.\n- **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`.\n- **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\"`.\n- **Checklist edits only after green gates.** Do not optimistically mark items done - flip `[ ]` → `[x]` only after both reviewers pass AND Workflow B is green.\n- **Subagent prompts live in `.\u002Fagents\u002F*.md`.** This SKILL.md is workflow only - never inline subagent prompts here.\n- **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.\n- **Never modify other slice plan files** during execution. Plans are static; deviations are noted inline in the checklist.\n- **HITL bubbling is mandatory and orchestrator-only.** Subagents set `needs_human` + `hitl_*`; only the orchestrator calls `ask_user_input_v0`.\n- **Always provide a recommended answer in available options** at every elicitation point.\n- **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).\n- **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.\n- **Strip `\u002F\u002F INSTRUMENT` lines** before final commit if `debug-instrumenter` ran.\n- **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.\n- **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.\n- **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.\n- **Session goal is set at most once per slice run, after Phase 2 authorization.** Phase 2.5 enforces the parent-goal pre-check; if `\u002Fsell-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.\n- **`Workflow` \u002F `\u002Fgoal` unavailable → fall back, never drop.** In-context dispatch with orchestrator-side manual schema validation when `Workflow` is absent; manual goal-tracking when `\u002Fgoal` is absent.\n\n---\n\n## Completion Checklist\n\nRun 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 `\u002Fbox-it-up` (pie boundary) and are not this skill's responsibility.\n\n### 1. Plan Tasks Complete\n\n- [ ] Every in-scope checklist item from the active `docs\u002Fplans\u002Fstage_\u003Cn>_*.md` is implemented.\n- [ ] Both `spec-reviewer` and `quality-reviewer` returned `verdict: pass` for each item.\n- [ ] The builder (`implementer`, or `state-illustrator` on `type: frontend`) emitted a complete **build manifest** (§Appendix A) covering every route \u002F affordance \u002F serverAction \u002F transition. A `frontend` slice with an empty manifest is a `prd_ambiguity` HITL, never a pass.\n- [ ] Every task commit landed on a green tier 2 (the task's own tests, build, DB tests when the schema or migrations changed).\n- [ ] `slice-verifier` returned `overall: pass` on its one tier-3 run - lint, typecheck, build, unit\u002Fintegration, e2e (per `verification.e2e`), design-system static grep, CI-integrity, and the manifest under-declaration backstop all clear.\n- [ ] `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.\n- [ ] `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.\n- [ ] 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.\n- [ ] No `[ ]` items remain in the active slice (deferred items moved out-of-scope with a note).\n- [ ] If `debug-instrumenter` ran, every `\u002F\u002F INSTRUMENT` line was stripped before final commit.\n\n### 1a. Library Preview Gate (frontend \u002F full-stack with UI only)\n\nSkip 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.\n\n- [ ] `library-entry-writer` ran the Phase 0 extend-vs-create gate and reported `build_decision` for every dispatched item.\n- [ ] Every component \u002F block delivered in this slice has a `\u002Flibrary?tab=\u003Cid>` entry with all variants and states (default \u002F hover \u002F focus \u002F disabled \u002F loading \u002F empty \u002F error \u002F populated).\n- [ ] Every entry uses `\u003CEntryHeader sourcePath=…>` and `\u003CEntrySection sourcePath=… sourceLines=…>` so the page H1 and every state H3 render a working copy-Markdown-link button.\n- [ ] Every new entry has its line in `LIBRARY_GROUPS` (`_registry\u002Fregistry.tsx`). Modify-case entries leave that line alone unless `name` \u002F `tags` genuinely changed.\n- [ ] Every existing library component whose user-visible surface (props, copy, content, variants, states, or styles) changed in a production route has its `\u002Flibrary?tab=\u003Cid>` entry updated to reflect the change.\n- [ ] Every net-new composite block got a `design-critic` pass (`scope: \"block\"`) whose score, P0\u002FP1 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.\n- [ ] 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).\n- [ ] No component imported into a production route, and no user-visible consumer-side edit committed, without library-first review.\n- [ ] 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.\n\n### 2. Master Checklist Updated\n\n- [ ] Every completed item is flipped `[ ]` → `[x]` in `docs\u002Fplans\u002F00_master_checklist.md`.\n- [ ] Slice status updated (`Not Started` → `In Progress` → `Completed`) to match reality.\n- [ ] Slice-level exit criteria boxes ticked where satisfied.\n- [ ] 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\").\n- [ ] Edits committed on the slice branch (not on `main`).\n\n### 3. Slice Committed and Pushed (ready for review)\n\n- [ ] Branch follows naming: `feat\u002F` | `fix\u002F` | `chore\u002F` + `stage-\u003Cn>-\u003Cscope>` (or the pie branch under `\u002Fsell-pie`).\n- [ ] Every task committed and pushed at its boundary (`feat(pie-N): N.M task K \u003Ctask name>`); the final slice commit `feat(pie-N): N.M \u003Cslice name>` pushed; no untracked or modified file the slice created.\n- [ ] `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.\n- [ ] 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.)\n\n### 4. E2E \u002F behavioral coverage (if applicable)\n\nSkip only if the slice is documentation-only or has zero observable behavior change.\n\n- [ ] New behavior covered by a `@feature`-tagged E2E spec (run\u002Fgated per `verification.e2e.feature`).\n- [ ] Critical existing flows touched by this slice covered by `@regression-core` (per `verification.e2e.regressionCore`).\n- [ ] For data-flow slices, the `slice-tester` persisted the seed + cleanup pair under `tests\u002Fseeds\u002F\u003Cslice>\u002F` for pie-boundary CI reproducibility.\n- [ ] `.github\u002Fworkflows\u002F` feature gates trigger `on: pull_request` (so per-slice pushes stay cheap; CI fires once at the pie PR).\n\n---\n\n### Handed off to `\u002Fbytheslice:box-it-up` - NOT this skill's responsibility\n\nThe following sections live in [`\u002Fbytheslice:box-it-up`](..\u002Fbox-it-up\u002FSKILL.md)'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 `\u002Fbox-it-up --merge-slice` (box-it-up's \"Slice-merge mode\" checklist).\n\n#### 5. PR open + CI green (handled by `\u002Fbox-it-up` at the pie boundary)\n- Pie branch pushed to `origin`; one PR `Pie N` open against `main`; PR URL surfaced.\n- `gh pr checks \u003Cpr> --watch` returned exit 0 on the latest head SHA (CI runs once, at the pie PR).\n- If the auto-fix loop ran, the final attempt cleared green.\n\n#### 6. Merge + Cleanup (handled by `\u002Fbox-it-up` at the pie boundary)\n- Merge authorized at the user gate; PR state is `MERGED` (per-slice commits preserved - rebase or merge-commit, not squash).\n- Local `main` synced with `--ff-only`.\n- Local + remote pie branch deleted.\n- Worktree removed + pruned (one worktree per pie; per slice in merge-per-slice mode), from the primary checkout.\n- `git status --short` empty; fully synced with `origin\u002Fmain`.\n\n---\n\n## Model Override\n\nSubagents use model aliases (`haiku`, `sonnet`, `opus`) that auto-resolve to the latest version per provider. Override the mapping globally with these env vars:\n\n```\nANTHROPIC_DEFAULT_HAIKU_MODEL=\u003Cmodel-id>\nANTHROPIC_DEFAULT_SONNET_MODEL=\u003Cmodel-id>\nANTHROPIC_DEFAULT_OPUS_MODEL=\u003Cmodel-id>\nCLAUDE_CODE_SUBAGENT_MODEL=\u003Cmodel-id>   # overrides all sub-agent tiers at once\n```\n\nPer-agent overrides live in `bytheslice.config.json` → `modelTiers` (`sliceTester`, `sliceVerifier` are the v5 verification tiers). See [`skills\u002Fsetup-shop\u002Freferences\u002Fmodel-tier-guide.md`](..\u002Fsetup-shop\u002Freferences\u002Fmodel-tier-guide.md) for the full tier philosophy and per-provider alias resolution.\n",{"name":5,"triggers":57,"description":7,"user-invocable":68},[58,59,60,61,62,63,64,65,66,67],"\u002Fbytheslice:sell-slice","\u002Fsell-slice","sell a slice","serve a customer","bake the slice","\u002Fbytheslice:deliver-stage","\u002Fdeliver-stage","deliver the next stage","ship the next slice","work the checklist",true,"main","a877abb24b61dfec2e931454e4590081dfbdbcfc","skills\u002Fsell-slice",1,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice","https:\u002F\u002Fgithub.com\u002Fsteve-piece","2026-11-11 19:22:40",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":68},[78,81,84],{"tool":79,"command":80},"npx","npx skills add steve-piece\u002Fbytheslice --skill sell-slice",{"tool":82,"command":83},"bunx","bunx skills add steve-piece\u002Fbytheslice --skill sell-slice",{"tool":85,"command":86},"pnpm","pnpm dlx skills add steve-piece\u002Fbytheslice --skill sell-slice","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002FSKILL.md",[89,95,99,103,107,111,115,119,123,127,131,135,139,143,147,151,155,159,163,167,171,175,179,183],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"agents\u002Fchecklist-curator.md","REFERENCE","参考文档",3296,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fchecklist-curator.md",{"path":96,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":97,"sourceHtmlUrl":98},"agents\u002Fdebug-instrumenter.md",4441,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fdebug-instrumenter.md",{"path":100,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":101,"sourceHtmlUrl":102},"agents\u002Fdiscovery.md",2568,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fdiscovery.md",{"path":104,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":105,"sourceHtmlUrl":106},"agents\u002Ffix-attempter.md",9812,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffix-attempter.md",{"path":108,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":109,"sourceHtmlUrl":110},"agents\u002Ffrontend\u002Fblock-composer.md",20305,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fblock-composer.md",{"path":112,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":113,"sourceHtmlUrl":114},"agents\u002Ffrontend\u002Fbreak-ui-runner.md",13590,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fbreak-ui-runner.md",{"path":116,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":117,"sourceHtmlUrl":118},"agents\u002Ffrontend\u002Fcomponent-crafter.md",10423,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fcomponent-crafter.md",{"path":120,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":121,"sourceHtmlUrl":122},"agents\u002Ffrontend\u002Fdesign-critic.md",15601,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fdesign-critic.md",{"path":124,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":125,"sourceHtmlUrl":126},"agents\u002Ffrontend\u002Flayout-architect.md",8833,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Flayout-architect.md",{"path":128,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":129,"sourceHtmlUrl":130},"agents\u002Ffrontend\u002Flibrary-entry-writer.md",28640,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Flibrary-entry-writer.md",{"path":132,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":133,"sourceHtmlUrl":134},"agents\u002Ffrontend\u002Fmodern-ux-expert.md",6676,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fmodern-ux-expert.md",{"path":136,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":137,"sourceHtmlUrl":138},"agents\u002Ffrontend\u002Fstate-illustrator.md",16808,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fstate-illustrator.md",{"path":140,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":141,"sourceHtmlUrl":142},"agents\u002Ffrontend\u002Fui-fix-attempter.md",3520,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Ffrontend\u002Fui-fix-attempter.md",{"path":144,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":145,"sourceHtmlUrl":146},"agents\u002Fimplementer.md",15068,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fimplementer.md",{"path":148,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":149,"sourceHtmlUrl":150},"agents\u002Fquality-reviewer.md",4695,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fquality-reviewer.md",{"path":152,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":153,"sourceHtmlUrl":154},"agents\u002Frules-loader.md",6823,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Frules-loader.md",{"path":156,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":157,"sourceHtmlUrl":158},"agents\u002Fslice-tester.md",22442,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fslice-tester.md",{"path":160,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":161,"sourceHtmlUrl":162},"agents\u002Fslice-verifier.md",32889,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fslice-verifier.md",{"path":164,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":165,"sourceHtmlUrl":166},"agents\u002Fspec-reviewer.md",3545,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fagents\u002Fspec-reviewer.md",{"path":168,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":169,"sourceHtmlUrl":170},"references\u002Fquality-gates.md",5711,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Freferences\u002Fquality-gates.md",{"path":172,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":173,"sourceHtmlUrl":174},"references\u002Fsession-collisions.md",4859,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Freferences\u002Fsession-collisions.md",{"path":176,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":177,"sourceHtmlUrl":178},"references\u002Fui-rules.md",7594,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Freferences\u002Fui-rules.md",{"path":180,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":181,"sourceHtmlUrl":182},"references\u002Fui-sources.md",3269,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Freferences\u002Fui-sources.md",{"path":184,"resourceType":185,"resourceTypeDesc":186,"sizeBytes":187,"sourceHtmlUrl":188},"scripts\u002Fverify-frontend-statics.sh","SCRIPT","脚本",22949,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002Fscripts\u002Fverify-frontend-statics.sh",[190,218,243,267,293,318],{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":52},"01M6JK6TG7HJ54TN5XYD8N3QE8","special-order","Cook a slice with the customer's specifications on the spot: add new features mid-flight to an existing project. Auto-detects project type and extends the master checklist with new stages.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fspecial-order\u002FSKILL.md",[],[197,198,199,200,201,202,203,45,204,205,206,207,208,209,210,211,36,212,213,214,215,216,217,31],"special order","app","project","auto","bolt","customer","features","add","opus","feature","custom","true","Existing","type","with","spot","specifications","about","new","request","extend",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":227,"publishedAt":52},"01M6JK6K6SH4N8Q597D3ABRRMR","setup-shop","Start the oven, check ingredients, prep the shop. Bootstrap a new project or configure ByTheSlice in an existing one. First-time install, system-wide config, or per-project setup.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsetup-shop\u002FSKILL.md",[224],{"categoryNo":225,"categoryName":226,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理",[228,229,230,231,198,232,199,233,234,235,236,237,238,239,240,205,241,41,242,208,215],"shop","setup shop","setup","SET","monorepo","time","up","open","configure","create","config","install","start","new project","system",{"skillNo":244,"name":245,"nameZh":6,"description":246,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":247,"categories":248,"keywords":253,"publishedAt":52},"01M6JK6CX6DNV9EE9VH6H3YRD0","set-display-case","Build the display case the pies will sit in, bootstrap your design system: tokens, Tailwind config, design rules, and the operator-only \u002Flibrary preview route. Run once before \u002Fsell-slice; also invocable standalone on any project.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002FSKILL.md",[249,252],{"categoryNo":250,"categoryName":251,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[231,254,255,256,257,199,258,234,259,260,261,262,263,46,238,239,264,265,44,266],"display","case","set display case","standalone","Tailwind","init","design","only","preview","route","operator","design-system","design system",{"skillNo":268,"name":269,"nameZh":6,"description":270,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":271,"categories":272,"keywords":274,"publishedAt":52},"01M6JK5RGMT1ZDVNG9CEHQF61Q","sell-pie","Bake a whole Pie autonomously - the v5 forefront delivery loop. A \u002Floop-driven baker that drives ONE Pie (a coherent chapter, usually 3 to 8 slices) to \"ready for review\" without per-slice prompting; each slice runs the context-separated build→test→verify→fix Workflow, commits + pushes (no PR), and advances; when every slice is [x] it stops at the pie boundary and opens one PR via \u002Fbox-it-up. Refuses flat v4 checklists (points you at \u002Fcook-pizzas --repie). For a continuous-review pie (review=continuous) it runs in high-touch \u002Fsell-slice mode. Opt-in merge-per-slice delivery (delivery.mode, or an explicit autonomous-delivery run instruction) instead gives each slice its own branch, PR and green-CI merge; opt-in ship-once delivery (delivery.mode, set by \u002Fpizza-party) merges each pie into one local ship branch on local gates only and ships one PR at the end. The four blocking HITL categories halt the loop instead of rescheduling (an unattended ship-once run defers the slice instead). Use when the user runs \u002Fsell-pie, says \"sell a pie\", \"bake the pie\", \"run the next pie\", \"loop the pie\", or wants one whole chapter delivered hands-off. For a single careful slice use \u002Fsell-slice; for the whole app end to end use \u002Fpizza-party.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-pie\u002FSKILL.md",[273],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[275,29,231,276,198,277,51,278,279,280,234,281,282,283,261,284,50,285,286,287,33,46,288,289,43,290,291,292],"sell pie","categories","ready","green","mode","end","fix","ci","local","autonomous","workflow","you","review","at","coherent","context","prompting","commits",{"skillNo":294,"name":295,"nameZh":6,"description":296,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":297,"categories":298,"keywords":303,"publishedAt":52},"01M6JK5GSHAXR9EAVBJBACPVGF","pizza-party","Cater a whole app, start to finish: from a short brief to a finished, deployed app with a URL. One interview up front (AskUserQuestion), then no human stops: \u002Fsetup-shop, \u002Fcreate-menu, \u002Fcook-pizzas, the Prep pie, every pie through \u002Fsell-pie in ship-once delivery (all gates local), one PR that ships the app, a deploy to whatever host the operator has authorized (or an artifact or localhost link), and a run record for comparing runs over time. Every decision a sub-skill would normally ask about is decided, recorded in the order ticket, and the run continues. Use when the user runs \u002Fpizza-party, sets a \u002Fgoal to build an app end to end, or says \"build me this app end to end\", \"from scratch to production\", \"pizza party\", \"bake the whole roadmap\" or \"run all pies\".","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fpizza-party\u002FSKILL.md",[299,302],{"categoryNo":300,"categoryName":301,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":225,"categoryName":226,"taxonomyType":26,"taxonomyTypeDesc":27},[304,305,198,306,233,280,307,308,234,309,283,284,310,311,312,313,237,314,315,316,317],"pizza party","party","brief","short","ticket","decision","host","roadmap","URL","ask","me","artifact","human","when",{"skillNo":319,"name":320,"nameZh":6,"description":321,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":322,"categories":323,"keywords":324,"publishedAt":52},"01M6JK5AFA8QZZG9VXSH77P2NF","open-the-shop","Doors unlocked, lights flipped, OPEN sign up - scan environment requirements and verify all external service credentials are populated. The most HITL-heavy prep step; the operator personally stocks the cash drawer. Run once before \u002Fsell-slice; also invocable standalone.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002FSKILL.md",[],[235,228,325,257,326,327,234,328,46,329,264,41,330,331,208,332,333,334,335,336,31],"open the shop","stock","env setup","credentials","line","scan","environment","business","stage","requirements","env","verify"]