mandrel 1.92.0 → 1.94.0

package/.agents/skills/skills.index.json

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-07-11T11:32:48.235Z",
+  "generatedAt": "2026-07-13T15:00:10.171Z",
   "generator": "generate-skills-index.js@1",
   "skills": [
     {
@@ -22,16 +22,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "baseline-refresh",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/baseline-refresh/SKILL.md",
-      "description": "Author a refresh commit for any of the unified-baseline snapshots (CRAP, maintainability, dead-exports, lighthouse). Use whenever an intentional code change resets a baseline key (rename, deliberate complexity bump, perf regression with operator sign-off) and the close-validation chain needs the refreshed snapshot to land on the same Story branch as the triggering edit.",
-      "policyCapsuleBullets": 10,
-      "allowedTools": ["Read", "Write", "Bash"],
-      "vendor": null
-    },
     {
       "name": "browser-testing-with-devtools",
       "tier": "core",
@@ -42,43 +32,13 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "ci-cd-and-automation",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/ci-cd-and-automation/SKILL.md",
-      "description": "Automates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
     {
       "name": "code-review-and-quality",
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/code-review-and-quality/SKILL.md",
-      "description": "Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.",
-      "policyCapsuleBullets": 10,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "code-simplification",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/code-simplification/SKILL.md",
-      "description": "Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "context-engineering",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/context-engineering/SKILL.md",
-      "description": "Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.",
-      "policyCapsuleBullets": 9,
+      "description": "Conducts multi-axis code review and runs the disciplined post-green refactor pass. Use before merging any change, when reviewing code written by yourself, another agent, or a human, or when the opt-in `delivery.refactorStage` checkpoint asks for a behaviour-preserving CRAP/duplication pass after the suite is green.",
+      "policyCapsuleBullets": 12,
       "allowedTools": null,
       "vendor": null
     },
@@ -92,16 +52,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "deprecation-and-migration",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/deprecation-and-migration/SKILL.md",
-      "description": "Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.",
-      "policyCapsuleBullets": 10,
-      "allowedTools": null,
-      "vendor": null
-    },
     {
       "name": "diagnose-friction",
       "tier": "core",
@@ -127,7 +77,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-consolidate/SKILL.md",
-      "description": "Run a holistic, pre-persist consolidation pass over the draft Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/plan`, after `epic-plan-decompose-author` writes `temp/epic-<Epic_ID>/tickets.json` and before `epic-plan-decompose.js` validates and persists it. Reconciles the draft against the Tech Spec \"Delivery Slicing\" ceiling via scope-preserving operations only.",
+      "description": "Run a holistic, pre-persist consolidation pass over the draft Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/plan`, after `epic-plan-decompose-author` writes `temp/epic-<Epic_ID>/tickets.json` and before `plan-persist.js` validates and persists it. Reconciles the draft against the Tech Spec \"Delivery Slicing\" ceiling via scope-preserving operations only.",
       "policyCapsuleBullets": 9,
       "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
@@ -137,7 +87,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-decompose-author/SKILL.md",
-      "description": "Author the Story ticket JSON for an Epic from the decomposer authoring context emitted by `epic-plan-decompose.js --emit-context`. Use during Phase 8 of `/plan` when the host LLM needs to write the ticket array before `epic-plan-decompose.js` validates and persists it.",
+      "description": "Author the Story ticket JSON for an Epic from the decomposer authoring context emitted by `plan-context.js --epic <Epic_ID>`. Use during Phase 8 of `/plan` when the host LLM needs to write the ticket array before `plan-persist.js` validates and persists it.",
       "policyCapsuleBullets": 15,
       "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
@@ -147,7 +97,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-premortem/SKILL.md",
-      "description": "Run a fresh-context, code-reading pre-mortem critic over the draft Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/plan`, after `epic-plan-decompose-author` / `epic-plan-consolidate` write `temp/epic-<Epic_ID>/tickets.json` and before `epic-plan-decompose.js` validates and persists it. Reads the sectioned Epic body AND the cited code surfaces, then emits predicted-rework findings before any GitHub write.",
+      "description": "Run a fresh-context, code-reading pre-mortem critic over the draft Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/plan`, after `epic-plan-decompose-author` / `epic-plan-consolidate` write `temp/epic-<Epic_ID>/tickets.json` and before `plan-persist.js` validates and persists it. Reads the sectioned Epic body AND the cited code surfaces, then emits predicted-rework findings before any GitHub write.",
       "policyCapsuleBullets": 7,
       "allowedTools": ["Read", "Write", "Bash", "Grep"],
       "vendor": null
@@ -157,19 +107,19 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-spec-author/SKILL.md",
-      "description": "Author the Tech Spec, Acceptance Table markdown, and risk-verdict JSON for an Epic from the planner authoring context emitted by `epic-plan-spec.js --emit-context`. Use during Phase 7 of `/plan` when the host LLM needs to write the three artifacts before `epic-plan-spec.js` folds them into the Epic body's managed sections.",
+      "description": "Author the Tech Spec, Acceptance Table markdown, and risk-verdict JSON for an Epic from the planner authoring context emitted by `plan-context.js --epic <Epic_ID>`. Use during Phase 7 of `/plan` when the host LLM needs to write the three artifacts before `plan-persist.js` folds them into the Epic body's managed sections.",
       "policyCapsuleBullets": 14,
       "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
     },
     {
-      "name": "frontend-ui-engineering",
+      "name": "gates-and-baselines",
       "tier": "core",
       "category": "core",
-      "path": ".agents/skills/core/frontend-ui-engineering/SKILL.md",
-      "description": "Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.",
+      "path": ".agents/skills/core/gates-and-baselines/SKILL.md",
+      "description": "Governs quality gates and the unified-baseline snapshots. Use when authoring a baseline refresh commit (CRAP, maintainability, dead-exports, lighthouse), when setting up or modifying CI quality gates, or when introducing a new gate that asserts on pre-existing state without turning the integration branch red.",
       "policyCapsuleBullets": 9,
-      "allowedTools": null,
+      "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
     },
     {
@@ -182,16 +132,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "hydrate-context",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/hydrate-context/SKILL.md",
-      "description": "Hydrate a Story ticket into a structured ContextEnvelope (or the legacy `{ prompt }` stdout wrapper). Reads the ticket body, resolves the parent Epic, embeds the sectioned Epic body (acceptance-table section stripped), and assembles named sections with provenance and section-aware elision. Successor to the retired mandrel MCP `context.hydrate` tool.",
-      "policyCapsuleBullets": 7,
-      "allowedTools": ["Read", "Bash"],
-      "vendor": null
-    },
     {
       "name": "idea-refinement",
       "tier": "core",
@@ -202,76 +142,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "incremental-implementation",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/incremental-implementation/SKILL.md",
-      "description": "Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "introducing-a-baseline-gate",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/introducing-a-baseline-gate/SKILL.md",
-      "description": "Land a new CI check that asserts on a body of pre-existing state (doc-drift, lint-vocabulary, dependency-cycle, missing-test-coverage, unused-export). Use when introducing a gate whose first run would surface latent findings — the introducing Story MUST guarantee the gate exits 0 at merge, not just that the cited discrepancies pass.",
-      "policyCapsuleBullets": 6,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "knowledge-transfer",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/knowledge-transfer/SKILL.md",
-      "description": "Verifies that a human operator actually understands a plan or a code change through restate-first probing, a why-ladder, incremental mastery gates, and a persistent comprehension checklist. Use \"explain\", \"walk me through\", \"help me understand\", \"teach me this change/plan\", or \"do I understand this?\" to trigger. Operator-facing and interactive only.",
-      "policyCapsuleBullets": 1,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "mutation-survivor-remediation",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/mutation-survivor-remediation/SKILL.md",
-      "description": "Turn surviving mutants into killed ones. Use after a Stryker mutation run reports a leaky score, when the mutation gate regresses, or when you want to harden a specific module's tests. The mutation-score gate and baseline ratchet live in the mutation baseline kind and `stryker-runner.js`; this skill shows how to read the survivor report, pick targets, and write the test that kills each survivor without inflating the suite.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "performance-optimization",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/performance-optimization/SKILL.md",
-      "description": "Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.",
-      "policyCapsuleBullets": 10,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "planning-and-task-breakdown",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/planning-and-task-breakdown/SKILL.md",
-      "description": "Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "property-based-testing",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/property-based-testing/SKILL.md",
-      "description": "Generative testing of invariants. Use when a unit has properties that should hold across a whole input domain — round-trips, idempotence, ordering, conservation — rather than a handful of hand-picked examples. The test-tier, mocking, and assertion-placement MUSTs live in `.agents/rules/testing-standards.md`; this skill shows how to find properties, pick the right per-stack library, and keep generative tests deterministic and fast.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": null
-    },
     {
       "name": "qa-coverage-mapping",
       "tier": "core",
@@ -282,16 +152,6 @@
       "allowedTools": ["Read", "Bash"],
       "vendor": null
     },
-    {
-      "name": "refactoring-discipline",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/refactoring-discipline/SKILL.md",
-      "description": "Run a post-green refactor pass that lowers CRAP and removes duplication without changing behaviour. Use after tests pass and gates are green, when a function's CRAP score is high but well-covered, or when the same logic is duplicated across files. Pairs with the `refactorer` persona and the opt-in `delivery.refactorStage` checkpoint; complements `core/code-simplification` (clarity) by focusing on the measured CRAP/duplication axes.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
     {
       "name": "scope-triage",
       "tier": "core",
@@ -312,216 +172,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "shipping-and-launch",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/shipping-and-launch/SKILL.md",
-      "description": "Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "spec-driven-development",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/spec-driven-development/SKILL.md",
-      "description": "Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "test-driven-development",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/test-driven-development/SKILL.md",
-      "description": "Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. The non-negotiable test-tier placement, mocking, assertion-placement, and coverage rules live in `.agents/rules/testing-standards.md`; this skill shows how to apply them via the TDD cycle, the Prove-It Pattern, and good-test style.",
-      "policyCapsuleBullets": 10,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "using-agent-skills",
-      "tier": "core",
-      "category": "core",
-      "path": ".agents/skills/core/using-agent-skills/SKILL.md",
-      "description": "Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.",
-      "policyCapsuleBullets": 9,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "monorepo-path-strategist",
-      "tier": "stack",
-      "category": "architecture",
-      "path": ".agents/skills/stack/architecture/monorepo-path-strategist/SKILL.md",
-      "description": "Enforces strict workspace package routing and dependency boundaries. Use when working in a monorepo with workspace aliases (e.g. `@repo/shared/*`, `@repo/ui/*`) and you need to prevent deep relative imports, cross-workspace contamination, or dependencies added at the wrong package.json level.",
-      "policyCapsuleBullets": 5,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "structured-output-zod",
-      "tier": "stack",
-      "category": "architecture",
-      "path": ".agents/skills/stack/architecture/structured-output-zod/SKILL.md",
-      "description": "Validates external and structured data with Zod schemas. Use when accepting untrusted input at API boundaries, validating environment variables on startup, parsing third-party responses, or generating typed shapes via `z.infer`. Parse, don't validate.",
-      "policyCapsuleBullets": 7,
-      "allowedTools": null,
-      "vendor": "zod"
-    },
-    {
-      "name": "subagent-orchestration",
-      "tier": "stack",
-      "category": "architecture",
-      "path": ".agents/skills/stack/architecture/subagent-orchestration/SKILL.md",
-      "description": "Coordinates complex tasks via task-isolated subagents. Use when one objective is too large for a single agent or when independent work streams should run concurrently with minimal context bleed. One objective per subagent; summarize before returning to keep the orchestrator's context window clean. Applies recursively — an orchestrator at any supported nesting depth applies the same policy to its own children.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": null
-    },
-    {
-      "name": "cloudflare-hono-architect",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/cloudflare-hono-architect/SKILL.md",
-      "description": "Prevents Node.js module hallucinations in Cloudflare Worker (V8 isolate) edge environments. Use when writing Hono routes deployed to Workers — prefer Web APIs (Fetch, Web Crypto) over Node built-ins (`fs`, `path`, `child_process`, `crypto`), and access bindings via Hono's `c.env`.",
-      "policyCapsuleBullets": 5,
-      "allowedTools": null,
-      "vendor": "cloudflare"
-    },
-    {
-      "name": "cloudflare-queue-manager",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/cloudflare-queue-manager/SKILL.md",
-      "description": "Ensures idempotent and resilient background job execution on Cloudflare Queues. Use when writing consumer handlers — design for at-least-once delivery, wrap processing in try/catch with `message.retry()`, and order cascading deletes so the database row drops last.",
-      "policyCapsuleBullets": 5,
-      "allowedTools": null,
-      "vendor": "cloudflare"
-    },
-    {
-      "name": "cloudflare-workers",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/cloudflare-workers/SKILL.md",
-      "description": "Builds and deploys high-performance edge logic on Cloudflare Workers. Use when working within Workers' 128MB memory and 5–50ms CPU constraints, integrating KV/R2/D1 storage, or writing Wrangler-managed edge-first request/response code.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "cloudflare"
-    },
-    {
-      "name": "highlevel-crm",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/highlevel-crm/SKILL.md",
-      "description": "Integrates with the HighLevel (GoHighLevel) CRM API v2 and its automation engine. Use when synchronizing data via OAuth 2.0, building custom widgets, handling sub-account `locationId` scoping, or implementing webhook-driven workflows with rate-limit-aware retries.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "highlevel"
-    },
-    {
-      "name": "sqlite-drizzle-expert",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/sqlite-drizzle-expert/SKILL.md",
-      "description": "Enforces SQLite dialect for Drizzle ORM and Turso (libSQL). Use when writing schema or queries with `drizzle-orm/sqlite-core` — avoid PostgreSQL-only types (`serial`, `jsonb`, `uuid`), use `text()` for IDs and dates, and define relations explicitly via the `relations` API.",
-      "policyCapsuleBullets": 5,
-      "allowedTools": null,
-      "vendor": "drizzle"
-    },
-    {
-      "name": "stripe-integration",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/stripe-integration/SKILL.md",
-      "description": "Implements secure Stripe payments and subscription billing. Use when handling card data (PCI compliance via Elements/Checkout), verifying webhook signatures, attaching `idempotencyKey` to mutations, or treating the server-side webhook as the source of truth for entitlement changes.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "stripe"
-    },
-    {
-      "name": "turso-sqlite",
-      "tier": "stack",
-      "category": "backend",
-      "path": ".agents/skills/stack/backend/turso-sqlite/SKILL.md",
-      "description": "Develops with Turso's distributed SQLite (libSQL) platform. Use when working with the `@libsql/client` driver — leverage edge replicas for low-latency reads, route writes to the primary, and use parameterized queries plus a versioned migration tool (drizzle-kit, atlas) for schema changes.",
-      "policyCapsuleBullets": 6,
-      "allowedTools": null,
-      "vendor": "turso"
-    },
-    {
-      "name": "astro-react-island-strategist",
-      "tier": "stack",
-      "category": "frontend",
-      "path": ".agents/skills/stack/frontend/astro-react-island-strategist/SKILL.md",
-      "description": "Maintains strict boundaries between Astro server components and React client islands in hybrid Astro/React workspaces. Use when keeping `.astro` files for static HTML/SEO and `.tsx` for interactive islands — embed React only with explicit `client:*` directives and pass serializable props.",
-      "policyCapsuleBullets": 5,
-      "allowedTools": null,
-      "vendor": "astro"
-    },
-    {
-      "name": "astro",
-      "tier": "stack",
-      "category": "frontend",
-      "path": ".agents/skills/stack/frontend/astro/SKILL.md",
-      "description": "Builds ultra-fast content-driven websites with Astro. Use when defaulting to SSG, opting into SSR only for dynamic data, picking the most restrictive `client:*` hydration directive, leveraging Server Islands (`server:defer`), Astro Actions for type-safe mutations, and the Content Layer with Zod- validated collections.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "astro"
-    },
-    {
-      "name": "expo-react-native-developer",
-      "tier": "stack",
-      "category": "frontend",
-      "path": ".agents/skills/stack/frontend/expo-react-native-developer/SKILL.md",
-      "description": "Prevents DOM element usage in React Native (Expo) workspaces. Use when writing components for Expo apps — `<View>`, `<Text>`, `<TouchableOpacity>` instead of `<div>`/`<span>`/`<p>`, no `window`/`document`, and styling through the project's established solution.",
-      "policyCapsuleBullets": 5,
-      "allowedTools": null,
-      "vendor": "expo"
-    },
-    {
-      "name": "google-analytics-v4",
-      "tier": "stack",
-      "category": "frontend",
-      "path": ".agents/skills/stack/frontend/google-analytics-v4/SKILL.md",
-      "description": "Implements privacy-compliant event tracking with Google Analytics 4. Use when wiring analytics that must comply with GDPR/CCPA via Consent Mode V2 — `snake_case` event names, no PII to GA servers, GTM-driven event firing, and DebugView verification before deploy.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "google"
-    },
-    {
-      "name": "tailwind-v4",
-      "tier": "stack",
-      "category": "frontend",
-      "path": ".agents/skills/stack/frontend/tailwind-v4/SKILL.md",
-      "description": "Implements maintainable styling with Tailwind CSS v4. Use when writing styles in v4 projects — CSS-first configuration via `@theme` blocks (never `tailwind.config.ts/js`), mobile-first breakpoints, full class names (no string interpolation), and no arbitrary `p-[13px]`-style values.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "tailwind"
-    },
-    {
-      "name": "ui-accessibility-engineer",
-      "tier": "stack",
-      "category": "frontend",
-      "path": ".agents/skills/stack/frontend/ui-accessibility-engineer/SKILL.md",
-      "description": "Enforces mobile-first Tailwind CSS and strict WCAG 2.1 AA compliance for user-facing UI. Use when building UI components — utility classes only (no custom CSS or inline `style={{}}`), mobile-first breakpoints, visible focus states, alt text, and 4.5:1 contrast.",
-      "policyCapsuleBullets": 7,
-      "allowedTools": null,
-      "vendor": "tailwind"
-    },
-    {
-      "name": "audit-accessibility",
-      "tier": "stack",
-      "category": "qa",
-      "path": ".agents/skills/stack/qa/audit-accessibility/SKILL.md",
-      "description": "Audits sites and apps for WCAG 2.1 Level AA compliance using automated and manual testing tools. Use when running an accessibility audit or building a remediation plan — semantic HTML, contrast, focus management, keyboard reachability, and axe-core integration in Vitest/Playwright.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": null
-    },
     {
       "name": "gherkin-authoring",
       "tier": "stack",
@@ -532,16 +182,6 @@
       "allowedTools": null,
       "vendor": null
     },
-    {
-      "name": "lighthouse-baseline",
-      "tier": "stack",
-      "category": "qa",
-      "path": ".agents/skills/stack/qa/lighthouse-baseline/SKILL.md",
-      "description": "Codifies the capture-and-check baseline pattern for long-running quality signals (Lighthouse scores, bundle size, p95 latency, runtime memory). Use when wiring a new metric that needs a baseline file, paired :capture / :check npm scripts, a tolerance-bounded gate, and a weekly refresh cadence — the goal is a hard CI signal that ratchets only with intent.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": null
-    },
     {
       "name": "playwright-bdd",
       "tier": "stack",
@@ -591,16 +231,6 @@
       "policyCapsuleBullets": 8,
       "allowedTools": null,
       "vendor": "vitest"
-    },
-    {
-      "name": "backend-security-patterns",
-      "tier": "stack",
-      "category": "security",
-      "path": ".agents/skills/stack/security/backend-security-patterns/SKILL.md",
-      "description": "Combined backend protocols for authentication (Clerk JWT verification) and PII-safe observability. Use when handling auth on the server, verifying Clerk webhooks via `svix`, scoping metadata via `publicMetadata`/ `privateMetadata`, or sanitizing logs to keep emails, tokens, and request bodies out of telemetry.",
-      "policyCapsuleBullets": 8,
-      "allowedTools": null,
-      "vendor": "clerk"
     }
   ]
 }

package/.agents/workflows/deliver.md

@@ -32,7 +32,7 @@ reference) before routing:
 
 | Input | Route |
 | --- | --- |
-| Exactly one `type::epic` ID | **Epic path** — run [`helpers/deliver-epic.md`](helpers/deliver-epic.md) Phases 1–9 unchanged (single-segment plan; no confirmation prompt). |
+| Exactly one `type::epic` ID | **Epic path** — resolve the Epic's delivery route (see [Epic delivery-route resolution](#epic-delivery-route-resolution) below), then run the selected helper's phases unchanged (single-segment plan; no confirmation prompt). |
 | One or more `type::story` IDs, none carrying an `Epic: #N` reference | **Standalone path** — run [`helpers/deliver-stories.md`](helpers/deliver-stories.md) Phases 0–3 (single-segment plan; no confirmation prompt). |
 | Any combination of ≥1 `type::epic` IDs and ≥0 standalone `type::story` IDs | **Segment plan** — compose and execute the sequential segment plan below. |
 | Any Story carrying an `Epic: #N` reference (alone or mixed into an otherwise-valid set) | **Error**, naming every affected ID and the fix: `Story #<id> belongs to Epic #<n> — run /deliver <n>`. |
@@ -40,6 +40,45 @@ reference) before routing:
 Per-ID classification is unchanged: fetch the `type::*` label and probe the
 body for an `Epic: #N` reference before routing. Never guess a route.
 
+## Epic delivery-route resolution
+
+Every `type::epic` segment resolves to one of two delivery shapes before its
+helper runs. The routing is a pure function of the Epic's labels, its
+`epic-plan-state` checkpoint, and the config kill-switch — implemented in
+[`lib/orchestration/deliver-route.js`](../scripts/lib/orchestration/deliver-route.js)
+(`resolveEpicDeliveryRoute(epic, checkpoint, config)`), mirroring how the
+code-review depth resolver reads `planningRisk`/`decompose` off the same
+checkpoint. Fetch the Epic's labels and read its `epic-plan-state` structured
+comment, then apply the precedence (highest wins):
+
+1. **Kill-switch — overrides all.** `delivery.routing.singleDelivery === false`
+   (default `true`, read via `getDeliveryRouting`) forces **fan-out** for
+   *every* Epic, even a single-marked one. This is the instant, per-consumer
+   global revert that ships before the default flips — no code rollback, no
+   re-plan.
+2. **Single marker → single route.** The `delivery::single` label (primary)
+   **or** `decompose.shape === "single"` on the checkpoint (secondary). A
+   spec-only plan authored no Story tree; its `## Delivery Slicing` table is
+   the audit trail.
+3. **No marker → fan-out.** A legacy Epic (no marker, an authored Story tree)
+   or a genuinely-wide DAG. Deliver-time width only *advises* — it never
+   reroutes a single-marked Epic (that would orphan a tree that does not
+   exist; re-route = re-plan).
+
+**Route dispatch.**
+
+- **`fan-out`** → run [`helpers/deliver-epic.md`](helpers/deliver-epic.md)
+  Phases 1–9 unchanged (the wave loop fanning out per-Story sub-agents).
+- **`single`** → run
+  [`helpers/deliver-epic-single.md`](helpers/deliver-epic-single.md) (the
+  live flip, M4-B): a one-worktree in-session slice walk (prepare `--single` →
+  ordered `## Delivery Slicing` walk on `epic/<id>` → per-AC-cluster
+  acceptance critics) that **reuses `helpers/deliver-epic.md` Phases 3–9
+  byte-for-byte** for the merge tail. This is now the **default** shape for a
+  single-marked Epic. The kill-switch (`delivery.routing.singleDelivery=false`)
+  still forces this verdict back to `fan-out` — an instant global revert with
+  no code rollback.
+
 ## Segment plan (mixed / multi-Epic input)
 
 When the supplied IDs span more than one Epic, or mix Epics with standalone
@@ -54,9 +93,13 @@ Stories, the router composes a **segment plan** and executes the segments
    Phase 7.0 base-sync then integrates those merges naturally instead of
    the Epic PR opening behind base.
 2. **Epic segments in input order**: each `type::epic` ID forms its own
-   segment, delivered via
-   [`helpers/deliver-epic.md`](helpers/deliver-epic.md) Phases 1–9
-   unchanged.
+   segment. Resolve its delivery route (see [Epic delivery-route
+   resolution](#epic-delivery-route-resolution)) and run the selected helper
+   unchanged — the `fan-out` route dispatches
+   [`helpers/deliver-epic.md`](helpers/deliver-epic.md) Phases 1–9, the
+   `single` route dispatches
+   [`helpers/deliver-epic-single.md`](helpers/deliver-epic-single.md) (which
+   reuses that helper's Phases 3–9 for the merge tail).
 
 Sequential execution is a deliberate design decision: the Epic path assumes
 a single main checkout (prepare's checkout guard, Phase 7.0

package/.agents/workflows/helpers/acceptance-self-eval.md

@@ -33,20 +33,45 @@ per-criterion, mid-delivery, and evaluates the actual work product.
 ## Per round
 
 1. **Eval pass (fresh context, independent of the author).** Run a **separate
-   critic pass** — a fresh-context sub-agent (`Agent` tool,
-   `subagent_type: general-purpose`), *not* a continuation of your implementing
-   turn — so the evaluator does not grade its own homework.
+   critic pass** — a fresh-context sub-agent (`Agent` tool), *not* a
+   continuation of your implementing turn — so the evaluator does not grade its
+   own homework.
 
-   > **Inline-critic fallback (nesting-absent harness).** Dispatching the
-   > critic as a nested `Agent` is the preferred shape — it gives genuine
-   > fresh-context isolation — and works on any harness that carries `Agent`
-   > into sub-agents (Claude Code ≥ 2.1.202; see
-   > [#2870](https://github.com/dsj1984/mandrel/issues/2870)). This eval loop
-   > itself runs inside a Story delivery sub-agent, so the nested critic sits
-   > at nesting depth 2. If the host does **not** support nested `Agent`
-   > dispatch at that depth — the tool is absent, or a spawn attempt returns
-   > an unsupported-capability error — do **not** stall the Story. Fall back
-   > to authoring the verdict **inline**: in a deliberately scoped,
+   > **Sub-agent type + risk-routed ceremony (Epic #4478, M7-B).** When
+   > `delivery.routing.roleScopedAgents` is enabled (the **default**), dispatch
+   > the critic with `subagent_type: acceptance-critic` — it boots on the
+   > role-scoped [`acceptance-critic`](../../agents/acceptance-critic.md) context
+   > (its own system prompt, no `CLAUDE.md` @-closure) that carries the
+   > maker-blind invariant and the verdict schema standalone. When the
+   > kill-switch is **off** (`roleScopedAgents: false`), fall back to
+   > `subagent_type: general-purpose`.
+   >
+   > **Whether to spawn fresh at all is risk-routed** (mirrors the risk →
+   > review-depth and risk → audit-lens routers). Resolve it per cluster with
+   > `resolveCeremonyForRisk` from
+   > [`ceremony-routing.js`](../../scripts/lib/orchestration/ceremony-routing.js)
+   > using the Epic's `planningRisk.overallLevel` and
+   > `delivery.routing.freshCriticSampleRate`:
+   > **`high`/`medium` risk → `fresh`** (spawn the critic); **`low` risk →
+   > `inline`** (the contract-identical inline fallback below), **except** the
+   > `freshCriticSampleRate` fraction of low-risk clusters the sampling floor
+   > forces `fresh` so low risk never means zero independent checking; **missing
+   > / unknown risk → `fresh` + full ceremony** (fail-safe). This chooses
+   > fresh-vs-inline **per cluster only — it never changes the cluster count**.
+   >
+   > **Inline-critic path (low-risk-routed OR nesting-absent harness).** The
+   > verdict is authored **inline** whenever the risk router above resolves to
+   > `inline` (a low-risk cluster not caught by the sampling floor), and also as
+   > a **fallback** on any harness that cannot spawn the fresh critic.
+   > Dispatching the critic as a nested `Agent` is the fresh-context shape and
+   > works on any harness that carries `Agent` into sub-agents (Claude Code ≥
+   > 2.1.202; see [#2870](https://github.com/dsj1984/mandrel/issues/2870)). This
+   > eval loop itself runs inside a Story delivery sub-agent, so the nested
+   > critic sits at nesting depth 2. If the host does **not** support nested
+   > `Agent` dispatch at that depth — the tool is absent, or a spawn attempt
+   > returns an unsupported-capability error — do **not** stall the Story
+   > regardless of the risk verdict. Author the verdict **inline**: in a
+   > deliberately scoped,
    > self-critical pass (re-read only the diff, the `acceptance[]` /
    > `verify[]` arrays, and the `verify[]` command output — treat the
    > implementation reasoning as untrusted and score against the criteria