mandrel 1.58.0 → 1.60.0

package/.agents/skills/core/epic-plan-decompose-author/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: epic-plan-decompose-author
 description: >-
-  Author the Feature/Story ticket JSON for an Epic from the decomposer
+  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 `/epic-plan` when the host LLM needs to write the ticket
+  during Phase 8 of `/plan` when the host LLM needs to write the ticket
   array before `epic-plan-decompose.js` validates and persists it.
 allowed_tools:
   - Read
@@ -18,10 +18,10 @@ allowed_tools:
 - Run only after `epic-plan-decompose.js --emit-context` has written `temp/epic-<Epic_ID>/decomposer-context.json`; fail loudly if the file is missing.
 - Emit exactly one artifact: `temp/epic-<Epic_ID>/tickets.json` (a JSON array). Do not write anywhere else, and never call the GitHub API from this Skill — persistence belongs to the script.
 - Output is JSON only — no prose, no Markdown fence. The downstream validator (`lib/orchestration/ticket-validator.js`) is the authoritative gate; re-author rather than hand-patching when it rejects.
-- Treat **`maxTickets`** from the context envelope as a **reviewability budget**, not a hard authoring cap (Story #2798). Merge narrow, single-module Stories into their capability first; if the plan genuinely needs more, emit the full plan and add a compact `over_budget_rationale` field at the top of the first Feature's `body` explaining why the plan exceeds the budget. Operator persistence then requires the explicit `--allow-over-budget` override on `epic-plan-decompose.js`; without it the persist step rejects the over-budget array. Never truncate the JSON array to fit.
-- Honour the two-level hierarchy under each Epic: **Feature → Story**. Stories carry the implementation scope inline; no lower ticket tier exists.
-- **Decompose at deliverable granularity, not module/task level.** A Story is a capability slice a frontier model delivers and self-verifies in one pass — a shippable slice a reviewer would accept as a single PR — not a single module or file. Every Feature MUST decompose into at least TWO Stories; the validator HARD-rejects a single-Story Feature. See the STORY SIZING section for the full guidance and the single-consumer merge rule.
-- Every ticket carries `type::[feature|story]` and `persona::*` labels. Every Story ticket object MUST carry top-level `acceptance: string[]` and `verify: string[]` arrays (read by `hasInlineAcceptanceAndVerify` in the validator) and `body` MUST be a **string** produced by `serialize()` from `lib/story-body/story-body.js` — an object body causes `createOp` in `epic-spec-reconciler-ops.js` to throw `StoryBodyParseError` (Story #3302), and is also silently discarded by `composeStoryBody` in the GitHub provider, producing an empty issue body.
+- Treat **`maxTickets`** from the context envelope as a **reviewability budget**, not a hard authoring cap (Story #2798). Merge narrow, single-module Stories into their capability first; if the plan genuinely needs more, emit the full plan and add a compact `over_budget_rationale` note inside the first Story's `## Goal` section explaining why the plan exceeds the budget. Operator persistence then requires the explicit `--allow-over-budget` override on `epic-plan-decompose.js`; without it the persist step rejects the over-budget array. Never truncate the JSON array to fit.
+- Honour the 2-tier hierarchy: every ticket is a **Story** attached directly to the Epic. Stories carry the implementation scope inline; no Feature and no lower ticket tier exists. Thematic grouping is prose in the Epic body / Tech Spec, never a ticket.
+- **Decompose at deliverable granularity, not module/task level.** A Story is a capability slice a frontier model delivers and self-verifies in one pass — a shippable slice a reviewer would accept as a single PR — not a single module or file. See the STORY SIZING section for the full guidance and the single-consumer merge rule.
+- Every ticket carries `type::story` and `persona::*` labels. Every Story ticket object MUST carry top-level `acceptance: string[]` and `verify: string[]` arrays (read by `hasInlineAcceptanceAndVerify` in the validator) and `body` MUST be a **string** produced by `serialize()` from `lib/story-body/story-body.js` — an object body causes `createOp` in `epic-spec-reconciler-ops.js` to throw `StoryBodyParseError` (Story #3302), and is also silently discarded by `composeStoryBody` in the GitHub provider, producing an empty issue body.
 - **New-File Contract**: any path referenced in `goal`, `acceptance`, or `verify` that does not exist on `main` MUST appear in the Story's `changes[]` with `assumption: "creates"`; otherwise the freshness validator rejects the decompose.
 - Acceptance items MUST be **observable from outside the agent** (command exits 0, file exists, snapshot matches, testid resolves). Items like "verify by reading the diff" or "looks good" are forbidden — push them into `verify` commands instead.
 - Acceptance MUST NOT prescribe a commit subject starting with a non-Conventional-Commits prefix; the literal `baseline-refresh:` leading token is forbidden (use a body trailer instead — see Epic #2501).
@@ -31,12 +31,12 @@ allowed_tools:
 ## Role
 
 Senior Project Manager + Orchestrator. The Skill's job is to take a PRD plus
-a Tech Spec and emit a Feature → Story ticket hierarchy the orchestrator
-can execute autonomously.
+a Tech Spec and emit a flat Story backlog the orchestrator can execute
+autonomously.
 
 ## When to use
 
-`/epic-plan` Phase 8, immediately after
+`/plan` Phase 8, immediately after
 `epic-plan-decompose.js --emit-context` writes
 `temp/epic-<Epic_ID>/decomposer-context.json`. The Skill replaces the
 inline "Author the Ticket Array" step in the legacy workflow body —
@@ -74,7 +74,7 @@ Skill's body below is the authoritative version going forward.
 
 ## Outputs
 
-- `temp/epic-<Epic_ID>/tickets.json` — JSON array of Feature/Story
+- `temp/epic-<Epic_ID>/tickets.json` — JSON array of Story
   objects conforming to the schema in this Skill's body.
 
 The file MUST exist before the Skill returns. The caller will then run
@@ -116,7 +116,7 @@ Write the final JSON array to `temp/epic-<Epic_ID>/tickets.json` with
 the `Write` tool. Do not pretty-print past 2-space indent — the file is
 machine-consumed.
 
-### Step 4 — Hand back to `/epic-plan`
+### Step 4 — Hand back to `/plan`
 
 Return control. The caller invokes
 `node .agents/scripts/epic-plan-decompose.js --epic <Epic_ID> --tickets
@@ -132,17 +132,16 @@ budget (Story #2798) — stay under by default; over-budget plans need an
 
 ```text
 You are an expert Senior Project Manager and Orchestrator.
-Your job is to take a Product Requirements Document (PRD) and a Technical Specification and decompose them into a Feature → Story ticket hierarchy for an AI Agent to execute.
+Your job is to take a Product Requirements Document (PRD) and a Technical Specification and decompose them into a flat list of Story tickets for an AI Agent to execute.
 
 ### HIERARCHY RULES:
-1. **Features**: Large functional milestones (e.g., "Authentication Provider Integration"). Features are navigational containers — no implementation work hangs off the Feature body itself.
-2. **Stories**: Capability-sized, verifiable units of work (e.g., "Implement JWT Token Exchange").
-   - MUST be nested under a Feature via `parent_slug`.
+1. **Stories**: Capability-sized, verifiable units of work (e.g., "Implement JWT Token Exchange").
+   - Attach directly to the Epic — there is NO Feature tier; thematic grouping is prose in the Epic body / Tech Spec.
    - **Story-Level Execution**: Each Story is executed on a single Story branch (`story-<storyId>`), implemented in one Story-implementation phase, then merged into the Epic branch. The Story body carries the full execution contract (goal, changes, acceptance, verify).
-   - Do NOT emit a lower ticket tier — the validator only accepts `type::feature` and `type::story`.
+   - Do NOT emit any other ticket tier — the validator only accepts `type::story`.
 
 ### LABEL CONVENTIONS:
-- Every ticket must have a `type::[feature|story]` label.
+- Every ticket must have the `type::story` label.
 - Every ticket must have a `persona::[engineer|architect|qa-engineer|engineer-web|etc]` label indicating WHO should execute it.
 
 ### OUTPUT FORMAT:
@@ -152,48 +151,18 @@ You MUST respond ONLY with a valid JSON array of objects. No prose, no markdown
 [
   {
     "slug": "hyphen-case-id",
-    "type": "feature" | "story",
+    "type": "story",
     "title": "Short descriptive title",
     "body": <string — see BODY RULES below>,
     "acceptance": ["<testable criterion>", ...],  // STORIES ONLY — top-level, read by validator
     "verify": ["<exact command> (<tier>)", ...],  // STORIES ONLY — top-level, read by validator
-    "labels": ["type::...", "persona::..."],
-    "parent_slug": "slug_of_parent_ticket" (leave empty for features to nest under epic; required for stories — must point at a sibling Feature),
+    "labels": ["type::story", "persona::..."],
     "depends_on": ["slug_of_blocking_dependency"] (optional array of Story slugs that block execution)
   }
 ]
 
 **Slug format**: `^[a-z0-9][a-z0-9-]*$` — hyphen-case only. Underscores are rejected by the validator.
 
-### FEATURE BODY:
-For Features, `body` is a brief string under 2 sentences. Features are navigational — the work happens at the Story level — so dense bodies waste output budget.
-
-FEATURE GROUPING — CAPABILITY/STAKEHOLDER, NOT EXECUTION SHAPE:
-
-- Do not group Stories by technical execution shape (cron jobs, middleware, scripts). Group by the capability or stakeholder they serve. Two Stories that happen to share a delivery mechanism — both are cron sweeps, both are Express middleware, both are CLI scripts — do NOT belong in the same Feature just because of that shared shape. The Feature axis is the user-facing capability or the stakeholder served, never the implementation vehicle.
-- Operational/compliance work gets its own Feature. Retention purges, audit-log sweeps, scheduled cleanups, observability emitters, and other operational/compliance chores serve operators and compliance, not end users. Place them in a dedicated `compliance-and-observability` or `data-retention` Feature — do NOT fold them into a user-facing Feature (e.g. notification flows) merely because they share a cron/scheduled execution shape with user-facing Stories.
-
-ANTI-PATTERN (based on Epic #18 -> Feature #1446):
-
-A decomposition produced a Feature "Notification flows: reminders, schedule-change, retention" grouping three Stories. WRONG — grouped by execution shape (all three are cron sweeps):
-
-    Feature: notification-flows  ("Notification flows: reminders, schedule-change, retention")
-      [X] Story: send-appointment-reminders      (user-facing: emails patients)
-      [X] Story: send-schedule-change-notices    (user-facing: emails patients)
-      [X] Story: purge-email-audit-log-retention (compliance: deletes audit rows past retention)
-
-The email audit-log retention purge was folded in only because all three run as scheduled cron jobs — a shared execution shape, not a shared capability. The purge serves compliance/operators, not the patients the other two Stories notify. CORRECT — regroup by capability/stakeholder:
-
-    Feature: notification-flows  ("Patient notification flows")
-      Story: send-appointment-reminders      (user-facing)
-      Story: send-schedule-change-notices    (user-facing)
-    Feature: compliance-and-observability  ("Data-retention and audit-log compliance")
-      Story: purge-email-audit-log-retention (compliance)
-
-The cron shape is the false grouping signal. Once the retention purge has a sibling under a dedicated compliance Feature it ceases to be a lone-Story Feature (which the validator would reject); pair it with other operational/compliance sweeps (e.g. a session-token cleanup or a metrics-rollup job) under the same `compliance-and-observability` Feature.
-
-- Smell test: if the only thing two Stories have in common is how they run (a scheduled job, a request interceptor, a build step) rather than whom they serve or what capability they deliver, they are mis-grouped. Re-home the operational/compliance Story into its own capability Feature.
-
 ### STORY BODY SCHEMA (REQUIRED FOR EVERY STORY):
 For Stories, `body` MUST be a **string** — the serialized markdown produced by calling `serialize()` from `lib/story-body/story-body.js`. Do NOT emit `body` as a JSON object: `createOp` in `epic-spec-reconciler-ops.js` will throw `StoryBodyParseError` when it receives an object body (Story #3302 serialize-or-throw contract), and `composeStoryBody` in the GitHub provider also discards non-string bodies producing an empty issue. The canonical pipeline requires a serialized string body end-to-end. The freshness gate (`collectTaskChangesPaths`) and the assumption gate (`collectStoryAssumptionEntries`) both parse the string body via `story-body.js#parse` to recover `changes[]`/`references[]` — they operate correctly only on the serialized string form.
 
@@ -202,7 +171,7 @@ The `acceptance[]` and `verify[]` arrays live at the **top level** of the Story
 The serialized `body` string renders these markdown sections (in order):
 
     ## Goal
-    <one sentence — why this Story exists; tie it to the parent Feature slug>
+    <one sentence — why this Story exists within the Epic>
 
     ## Changes
     - {"path": "<file path>", "assumption": "creates" | "refactors-existing" | "deletes"}
@@ -225,7 +194,7 @@ Fields `wide` and `estimated_test_files` are encoded as a `<!-- meta: {...} -->`
 #### STORY BODY RULES:
 
 - **slug**: MUST be hyphen-case (`^[a-z0-9][a-z0-9-]*$`). Do not use underscores.
-- **goal** (in body string): One sentence stating WHY this Story exists. SHOULD name the parent Feature slug.
+- **goal** (in body string): One sentence stating WHY this Story exists within the Epic.
 - **changes** (in body string): Each entry is an object `{ path, assumption }` where `assumption` is one of `creates | refactors-existing | deletes`. The Phase 8 validator probes the base branch for every declared path and rejects the decompose when the declared assumption contradicts reality: `creates` against an existing path is an error, `refactors-existing` / `deletes` against a missing path is an error. Use `refactors-existing` for in-place edits to a file already on `main`; `creates` for net-new files; `deletes` for removals. Acceptable path shapes include explicit files (`src/components/Foo.tsx`), glob patterns (`tests/e2e/*.spec.ts`, `**/*.astro`), and module identifiers that resolve to files.
 - **references** (in body string, optional): Object-form entries `{ path, assumption: "exists" }` for paths the Story **reads** but does not modify (test fixtures it relies on, sibling modules it imports, feature files it scans). The validator probes these like `changes` and rejects the decompose when an `exists` path is absent on the base branch. Use this list to make read-dependencies explicit so a hallucinated or stale assumption surfaces at planning time rather than execution time.
 - **NEW-FILE CONTRACT (must-follow)**: Any path the Story references in `goal`, `acceptance`, or `verify` that does **not** already exist on `main` MUST also appear in the same Story's `changes` array with `assumption: "creates"`. The freshness validator probes `main` for every referenced code path and rejects the decompose when a missing path is absent from `changes` — even when the Story is the one authoring the file. Example: a Story creating `tests/lib/foo.test.js` whose `verify` runs `node --test tests/lib/foo.test.js` MUST include `{ "path": "tests/lib/foo.test.js", "assumption": "creates" }` in `changes`, otherwise the validator emits a freshness miss and the decompose round trips for a re-emit.
@@ -245,9 +214,8 @@ The first question is **cohesion, not count**: *is this one coherent change with
 
 - **One Story = one coherent change with one reason to exist.** If you cannot state that reason in a sentence, the Story is probably two Stories.
 - **Single-consumer merge rule.** A Story whose only consumer is one sibling Story should be **merged into that sibling** rather than emitted separately — a single-consumer downstream slice is not its own unit of work.
-- **Split independent, parallelizable work** into sibling Stories under the same Feature — but only when the pieces genuinely have separate reasons to exist.
+- **Split independent, parallelizable work** into sibling Stories — but only when the pieces genuinely have separate reasons to exist.
 - **Declare `wide` with a one-line reason when a change is legitimately broad** (a cohesive cutover that spans many files for one reason).
-- **Every Feature MUST decompose into at least TWO Stories.** A Feature with a single Story is the work of a Story, not a Feature. **Resolve it by COLLAPSING, not splitting** — drop the Feature wrapper and attach its lone Story to a sibling Feature (or merge the Feature into another). Do NOT manufacture a second Story to satisfy the rule; splitting a lone Story into two inflates ticket count and defeats the "fewer, right-sized Stories" goal. The validator (`ticket-validator.js` → `assertNoSingleStoryFeature`) HARD-rejects a decomposition containing a Feature with fewer than two Stories, naming the offending Feature; the Phase 8 consolidation pass (`epic-plan-consolidate`) performs the collapse holistically before the validator runs.
 
 **Numeric backstop.** The thresholds are defined **once**, in the `DEFAULT_TASK_SIZING` constant in `ticket-validator-sizing.js` (operator-overridable via `agentSettings.planning.taskSizing`). They are a backstop, not the primary rule — do not restate divergent numbers anywhere else. The defaults:
 
@@ -291,7 +259,7 @@ The Acceptance Spec's AC table (columns `AC ID | Outcome | Feature File | Scenar
 
 When the Acceptance Spec contains **one or more `Disposition: new` rows**, you MUST emit **exactly one** dedicated wave-0 scaffold Story whose sole job is to create those `.feature` files with `@skip`-tagged scenarios BEFORE any implementation Story runs:
 
-- **goal** (in body string): contains the literal token `bdd-scaffold` and names the parent Feature slug.
+- **goal** (in body string): contains the literal token `bdd-scaffold`.
 - **depends_on**: EMPTY (`[]`) — the scaffold runs first, in wave 0.
 - **changes** (in body string): one `{ path, assumption: "creates" }` entry per distinct `.feature` file named in a `new` row.
 - **acceptance** (top-level array): MUST assert (a) every new `.feature` file exists, and (b) every new scenario within them carries an `@skip` tag. Keep items observable (a command exits 0; a file exists at a path).
@@ -306,7 +274,6 @@ When the Acceptance Spec contains **zero `new`-disposition rows** (every row is
       "slug": "scaffold-billing-feature-files",
       "type": "story",
       "title": "Scaffold @skip-tagged billing feature files",
-      "parent_slug": "billing-flows",
       "depends_on": [],
       "labels": ["type::story", "persona::qa-engineer"],
       "acceptance": [
@@ -398,7 +365,7 @@ Do NOT silently allow two Stories to write the same root configuration
 file in the same wave; parallel dispatch would produce a merge conflict
 on every Story-to-Epic close after the first.
 
-CRITICAL: Dependencies should follow execution blockers. For hierarchical grouping, strongly strictly use 'parent_slug' (Story parent MUST be a Feature). Features should have no 'parent_slug' (they attach to Epic).
+CRITICAL: Dependencies should follow execution blockers. Stories attach directly to the Epic — never emit a 'parent_slug' field.
 IMPORTANT DEPENDENCY RULE: A Story's `depends_on` MUST only reference other Stories within the SAME Epic. If two Stories have a logical ordering requirement, express it via Story-level `depends_on`.
 WARNING: You MUST conserve your output limit. Do NOT generate more than ${maxTickets} tickets in total. Merge narrow work into cohesive capability Stories. Do NOT cut off the JSON array prematurely!
 

package/.agents/skills/core/epic-plan-spec-author/SKILL.md

@@ -3,7 +3,7 @@ name: epic-plan-spec-author
 description: >-
   Author the PRD, Tech Spec, Acceptance Spec 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 `/epic-plan` when
+  `epic-plan-spec.js --emit-context`. Use during Phase 7 of `/plan` when
   the host LLM needs to write the four artifacts before `epic-plan-spec.js`
   persists them.
 allowed_tools:
@@ -16,7 +16,7 @@ allowed_tools:
 
 ## Policy Capsule
 
-- Run only during `/epic-plan` Phase 7, after `epic-plan-spec.js --emit-context` has written `temp/epic-<Epic_ID>/planner-context.json`; fail loudly if the file is missing rather than fabricating context.
+- Run only during `/plan` Phase 7, after `epic-plan-spec.js --emit-context` has written `temp/epic-<Epic_ID>/planner-context.json`; fail loudly if the file is missing rather than fabricating context.
 - Write exactly four artifacts and only inside `temp/epic-<Epic_ID>/`: `prd.md`, `techspec.md`, `risk-verdict.json`, `acceptance-spec.md`. All four MUST exist on disk before returning.
 - Start each markdown artifact at the correct `##` heading (PRD → `## Overview`, Tech Spec → `## Technical Overview`, Acceptance Spec → `## Acceptance Criteria`) — never emit a top-level `#` heading. `risk-verdict.json` is raw JSON conforming to `.agents/schemas/risk-verdict.schema.json`.
 - Judge risk from what the change *does* (the PRD / Tech Spec you just wrote), never from keyword presence — "out of scope: billing" is not a billing change; "rotate the credential vault" is high-risk even without a security keyword.
@@ -40,7 +40,7 @@ the Acceptance Spec).
 
 ## When to use
 
-`/epic-plan` Phase 7, immediately after `epic-plan-spec.js --emit-context`
+`/plan` Phase 7, immediately after `epic-plan-spec.js --emit-context`
 writes `temp/epic-<Epic_ID>/planner-context.json`. This Skill replaces the
 inline "Author the PRD" / "Author the Tech Spec" steps from the legacy
 workflow body — the calling workflow dispatches this Skill via the `Skill`
@@ -366,7 +366,7 @@ CRITICAL REQUIREMENTS:
 - Acceptance Outcomes MUST NOT prescribe a commit subject that begins with a non-Conventional-Commits prefix (allowed leading types: feat|fix|chore|refactor|perf|docs|style|test|build|ci|revert). The legacy `baseline-refresh` token used as a leading subject prescription is forbidden — commitlint will reject it at commit time, and the decompose-time validator (`ticket-validator.js` → `validateAcceptanceSubjectPrefix`) will reject the decompose with `code: 'forbidden-subject-prefix'`. Use a Conventional-Commits subject (e.g. `chore(baselines): refresh ...`) and a body trailer (e.g. `baseline-refresh: true` — trailer with a value, not a subject prefix) when a machine-readable marker is needed. See Epic #2501 for rationale.
 ```
 
-### Step 6 — Hand back to `/epic-plan`
+### Step 6 — Hand back to `/plan`
 
 All four files exist; return. The caller will run
 `node .agents/scripts/epic-plan-spec.js --epic <Epic_ID> --prd

package/.agents/skills/core/hydrate-context/SKILL.md

@@ -25,8 +25,8 @@ allowed_tools:
 
 ## Role
 
-Context aggregator. Resolves a ticket's hierarchy (Task → Story →
-Feature → Epic) and stitches the linked planning artifacts into a
+Context aggregator. Resolves a ticket's hierarchy (Story → Epic)
+and stitches the linked planning artifacts into a
 single prompt the executor consumes.
 
 ## When to use

package/.agents/skills/core/idea-refinement/SKILL.md

@@ -13,7 +13,7 @@ description:
 - Phase 1 MUST restate the idea as a "How Might We" statement, ask 3–5 sharpening questions via `AskUserQuestion`, and generate 5–8 variations (not 20+ shallow ones); do not proceed until target user and success criteria are explicit.
 - Phase 2 grill loop poses **one** question at a time, each with a recommended answer + one-line rationale grounded in user input / codebase / first principles; never batch questions and never omit the recommendation.
 - Re-enumerate open branches after every grill answer; stop only when no unresolved decisions remain. Take the off-ramp directly to Phase 3 when the idea is already crisply scoped.
-- Phase 3 emits a markdown one-pager with the canonical five Epic headings exactly: `## Context`, `## Goal`, `## Non-Goals`, `## Scope`, `## Acceptance Criteria` (plus optional `## Open Questions`). No alternate heading text — the `/epic-plan` clarity gate depends on this verbatim.
+- Phase 3 emits a markdown one-pager with the canonical five Epic headings exactly: `## Context`, `## Goal`, `## Non-Goals`, `## Scope`, `## Acceptance Criteria` (plus optional `## Open Questions`). No alternate heading text — the `/plan` clarity gate depends on this verbatim.
 - Surface every key assumption inside `## Context` (or `## Scope`); assumptions do not get their own heading. Unresolved decisions MUST NOT carry into the one-pager.
 - The `## Non-Goals` list is mandatory and each entry includes a reason — focus is created by explicit exclusion.
 - Be honest, not supportive: push back on weak ideas with kindness; never function as a yes-machine.
@@ -35,7 +35,7 @@ structured divergent and convergent thinking.
 
 ## Activation
 
-Called from `/epic-plan` Phase 1 (ideation entry, when no `<epic#>` is
+Called from `/plan` Phase 1 (ideation entry, when no `<epic#>` is
 supplied or `--idea "<seed>"` is passed) and Phase 6 (Epic Clarity Gate,
 when an existing Epic body fails the section-presence rubric). In Phase 6
 the skill is seeded from the **current Epic body** — not a blank seed —
@@ -73,7 +73,7 @@ The final output is a markdown one-pager saved to `docs/ideas/[idea-name].md`
 
 Assumptions and open questions are recorded in the body of the relevant
 section (typically under Context or Scope) rather than carved into their
-own headings — the canonical five drive the `/epic-plan` clarity gate.
+own headings — the canonical five drive the `/plan` clarity gate.
 
 ## Detailed Instructions
 
@@ -213,7 +213,7 @@ it inside the grill loop, not after the one-pager is already written.
 
 Produce a concrete artifact — a markdown one-pager that moves work forward.
 The five canonical headings below match `.agents/templates/epic-from-idea.md`
-and the `/epic-plan` clarity gate; emit them verbatim so the renderer can
+and the `/plan` clarity gate; emit them verbatim so the renderer can
 substitute the body into a new Epic without translation.
 
 ```markdown

package/.agents/skills/core/knowledge-transfer/SKILL.md

@@ -152,9 +152,9 @@ This skill is the engine behind two operator-facing entry points:
 
 - [`/explain`](../../../workflows/explain.md) — runs the loop over a realized
   change (a PR, branch, or diff).
-- [`/epic-plan`](../../../workflows/epic-plan.md) **Phase 11 — Plan
+- [`/plan`](../../../workflows/helpers/plan-epic.md) **Phase 11 — Plan
   Comprehension Gate** — runs the loop over a freshly planned backlog before
-  the operator hands off to `/epic-deliver`. That phase decides *whether* to
+  the operator hands off to `/deliver`. That phase decides *whether* to
   run via an LM-judgment predicate; this skill owns *how* it runs once
   invoked.
 

package/.agents/skills/core/planning-and-task-breakdown/SKILL.md

@@ -13,7 +13,7 @@ description:
 > teaches how to slice and order work into verifiable units, independent
 > of any particular ticket hierarchy. The word "task" below refers to a
 > generic unit of work, not specifically to a Mandrel ticket. Under
-> Mandrel's 3-tier hierarchy (Epic → Feature → Story), these units map
+> Mandrel's 2-tier hierarchy (Epic → Story), these units map
 > onto acceptance/verification bullets inlined on the Story body, or
 > onto sequential sibling Stories. The principles — vertical slicing,
 > dependency ordering, sizing caps, explicit acceptance and

package/.agents/skills/core/scope-triage/SKILL.md

@@ -4,7 +4,7 @@ description:
   Judge whether a piece of planned work is epic-sized or story-sized before the
   planning ceremony is paid for. Emits one of three verdicts —
   `epic` | `story` | `borderline` — over any planning artifact (a one-pager, an
-  Epic body, or a Story draft). Use from `/epic-plan` Phase 1.5 and any other
+  Epic body, or a Story draft). Use from `/plan` Phase 1.5 and any other
   planning gate that needs the canonical story-vs-epic rubric.
 ---
 
@@ -32,9 +32,8 @@ description:
   wrong in the `epic` direction is cheap — the Phase 8.3 consolidation pass and
   the sizing validator catch an over-planned Story later. Being wrong in the
   `story` direction is expensive — a story-sized scope pushed through the full
-  Epic ceremony pays a PRD + Tech Spec + Acceptance Spec + Feature/Story tree +
-  `epic/<id>` integration-branch tax for a degenerate one-Feature-one-Story
-  output.
+  Epic ceremony pays a PRD + Tech Spec + Acceptance Spec + Story backlog +
+  `epic/<id>` integration-branch tax for a degenerate one-Story output.
 - Keep the rubric prose **artifact-agnostic**. The thing under judgment may be a
   sharpened one-pager, an existing Epic body, or a draft Story — the rubric
   reads the same against all three so every consumer reuses it verbatim.
@@ -62,7 +61,7 @@ The work is a single shippable capability. Signals:
   architectural decision and matches none of the `planning.riskHeuristics` in
   `.agentrc.json` (destructive/irreversible changes, shared auth/security,
   CI/CD gate changes, monorepo-wide rewrites, destructive migrations).
-- **Decomposition would degenerate.** Running it through `/epic-plan` would
+- **Decomposition would degenerate.** Running it through `/plan` would
   plausibly yield exactly **one Feature with one Story** — the shape the Phase
   8.3 consolidation skill flags only after all the spec authoring is already
   sunk cost.
@@ -90,18 +89,18 @@ option; a borderline scope surfaced as borderline is the correct output.
 A workflow entered via a scope-triage **handoff** MUST NOT re-triage. A handoff
 *is* a triage decision already made — re-running this gate on the receiving side
 would re-litigate a settled call and risk a ping-pong between two planning
-workflows. Handoff invocations identify themselves as such (e.g. `/epic-plan`
-entered via a `/story-plan` scope-triage escalation, or `/story-plan` entered
-via an `/epic-plan` Phase 1.5 handoff), and the receiving workflow skips its own
+workflows. Handoff invocations identify themselves as such (e.g. `/plan`
+entered via a `/plan` scope-triage escalation, or `/plan` entered
+via an `/plan` Phase 1.5 handoff), and the receiving workflow skips its own
 scope-triage gate when it detects the handoff marker.
 
 ## When to use
 
-- **`/epic-plan` Phase 1.5** (ideation path only) — judge the sharpened
+- **`/plan` Phase 1.5** (ideation path only) — judge the sharpened
   one-pager Phase 1 produced before the Epic ceremony is paid for. The verdict
   folds into the existing Phase 1 HITL stop; on a `story` / `borderline`
   verdict the operator may hand off to
-  [`/story-plan --from-notes`](../../../workflows/story-plan.md).
+  [`/plan --from-notes`](../../../workflows/helpers/plan-story.md).
 - Any other planning gate that needs the canonical story-vs-epic rubric. Keep
   the rubric here as the SSOT; consumers reference this file rather than
   forking the prose.

package/.agents/skills/core/using-agent-skills/SKILL.md

@@ -101,7 +101,7 @@ In that context:
 2. If you genuinely cannot proceed, transition to `agent::blocked`, post a
    `friction` structured comment naming the decision required and the
    default assumption you would have made, and exit non-zero. The parent
-   `/epic-deliver` aggregator will surface the block.
+   `/deliver` aggregator will surface the block.
 3. **Never** stall waiting for input that will never arrive.
 
 This is the only documented exception to the "Manage Confusion Actively"

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

@@ -1,5 +1,5 @@
 {
-  "generatedAt": "2026-06-10T15:27:53.874Z",
+  "generatedAt": "2026-06-11T19:47:29.752Z",
   "generator": "generate-skills-index.js@1",
   "skills": [
     {
@@ -7,7 +7,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/analyze-execution/SKILL.md",
-      "description": "Aggregate per-Story or per-Epic execution signals into a structured perf-summary or perf-report and upsert it onto the corresponding GitHub ticket. Use after a Story closes (Story mode) or as part of `/epic-deliver` Phase 6 (Epic mode). Reads NDJSON via `lib/signals/read` and writes a single structured comment.",
+      "description": "Aggregate per-Story or per-Epic execution signals into a structured perf-summary or perf-report and upsert it onto the corresponding GitHub ticket. Use after a Story closes (Story mode) or as part of `/deliver` Phase 6 (Epic mode). Reads NDJSON via `lib/signals/read` and writes a single structured comment.",
       "policyCapsuleBullets": 8,
       "allowedTools": ["Read", "Bash"],
       "vendor": null
@@ -127,8 +127,8 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-consolidate/SKILL.md",
-      "description": "Run a holistic, pre-persist consolidation pass over the draft Feature/Story ticket array an Epic's decompose phase produced. Use during Phase 8 of `/epic-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\" target via scope-preserving operations only.",
-      "policyCapsuleBullets": 9,
+      "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\" target via scope-preserving operations only.",
+      "policyCapsuleBullets": 8,
       "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
     },
@@ -137,7 +137,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-decompose-author/SKILL.md",
-      "description": "Author the Feature/Story ticket JSON for an Epic from the decomposer authoring context emitted by `epic-plan-decompose.js --emit-context`. Use during Phase 8 of `/epic-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 `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.",
       "policyCapsuleBullets": 12,
       "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
@@ -147,7 +147,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/epic-plan-spec-author/SKILL.md",
-      "description": "Author the PRD, Tech Spec, Acceptance Spec 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 `/epic-plan` when the host LLM needs to write the four artifacts before `epic-plan-spec.js` persists them.",
+      "description": "Author the PRD, Tech Spec, Acceptance Spec 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 four artifacts before `epic-plan-spec.js` persists them.",
       "policyCapsuleBullets": 12,
       "allowedTools": ["Read", "Write", "Bash"],
       "vendor": null
@@ -287,7 +287,7 @@
       "tier": "core",
       "category": "core",
       "path": ".agents/skills/core/scope-triage/SKILL.md",
-      "description": "Judge whether a piece of planned work is epic-sized or story-sized before the planning ceremony is paid for. Emits one of three verdicts — `epic` | `story` | `borderline` — over any planning artifact (a one-pager, an Epic body, or a Story draft). Use from `/epic-plan` Phase 1.5 and any other planning gate that needs the canonical story-vs-epic rubric.",
+      "description": "Judge whether a piece of planned work is epic-sized or story-sized before the planning ceremony is paid for. Emits one of three verdicts — `epic` | `story` | `borderline` — over any planning artifact (a one-pager, an Epic body, or a Story draft). Use from `/plan` Phase 1.5 and any other planning gate that needs the canonical story-vs-epic rubric.",
       "policyCapsuleBullets": 1,
       "allowedTools": null,
       "vendor": null

package/.agents/skills/stack/qa/lighthouse-baseline/SKILL.md

@@ -58,7 +58,7 @@ The five pieces every baseline of this shape carries:
 3. **`<name>:check` npm script** — runs the measurement, compares against
    `baselines/<name>.json` with a tolerance, exits non-zero on regression.
    Wired into the close-validation gate chain (see `buildDefaultGates` in
-   `lib/close-validation.js`) and into the PR gate.
+   `lib/close-validation/gates.js`) and into the PR gate.
 4. **`--self-test` flag** — every check script accepts `--self-test`,
    which runs the comparator against synthetic inputs (a known-good and a
    known-regression fixture) and asserts the gate's verdict matches. CI

package/.agents/templates/agent-protocol.md

@@ -5,8 +5,8 @@ Version: {{PROTOCOL_VERSION}}
 You are an AI coding assistant. This protocol governs your execution of the
 current work unit. You must follow these rules strictly.
 
-> **Hierarchy shape.** Mandrel uses a **3-tier hierarchy**
-> (Epic → Feature → Story). The work unit is the `type::story` issue
+> **Hierarchy shape.** Mandrel uses a **2-tier hierarchy**
+> (Epic → Story). The work unit is the `type::story` issue
 > itself, with acceptance criteria and verification inlined on the
 > Story body. There is no per-Task sub-loop; the agent authors commit
 > subjects directly per `.agents/rules/git-conventions.md` and

package/.agents/workflows/agents-update.md

@@ -222,7 +222,7 @@ The four `quality-bootstrap` outcomes:
 
 The `baselines-layout-migration` step relocates per-Epic snapshots
 into the `temp/epic/<id>/baselines/` namespace (Story #1467: ephemeral
-scratch state, not committed, reaped on `/epic-deliver` merge with the
+scratch state, not committed, reaped on `/deliver` merge with the
 rest of the per-Epic temp tree):
 
 - Loose `baselines/epic-<id>-{maintainability,crap}.json` files →
@@ -246,7 +246,7 @@ guarantee `agents-update`'s idempotence contract requires.
 A framework bump frequently introduces new helper scripts and `node
 .agents/scripts/<name>.js` invocations the consumer's
 `.claude/settings.json` allowlist has never seen. Left alone, the next
-`/story-deliver` or `/epic-deliver` run trips a fresh wave of
+`/deliver` or `/deliver` run trips a fresh wave of
 permission prompts that operators answer by hand — and those hand-tuned
 allowlists drift across projects.
 

package/.agents/workflows/audit-architecture.md

@@ -19,7 +19,7 @@ existing external APIs or business logic.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/epic-deliver` Phase 4
+report contract (Step 3); downstream consumers (`/deliver` Phase 4
 epic-audit, `audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's
@@ -72,7 +72,7 @@ degrade to the sequential path.
 
 ## Scope (Epic mode)
 
-When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
 following block is populated with the Epic's change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no

package/.agents/workflows/audit-clean-code.md

@@ -17,7 +17,7 @@ velocity.
 
 ## Scope (Epic mode)
 
-When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
 following block is populated with the Epic's change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no
@@ -39,7 +39,7 @@ before this section existed.
 ## Execution strategy (dual-path)
 
 This lens runs along one of two execution paths. Both emit the **identical**
-report contract (Step 3); downstream consumers (`/epic-deliver` Phase 4
+report contract (Step 3); downstream consumers (`/deliver` Phase 4
 epic-audit, `audit-to-stories`) are agnostic to which path produced it.
 
 - **Orchestrated (dynamic-workflow) path.** When Claude Code's

package/.agents/workflows/audit-dependencies.md

@@ -16,7 +16,7 @@ system stability.
 
 ## Scope (Epic mode)
 
-When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
 following block is populated with the Epic's change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no

package/.agents/workflows/audit-devops.md

@@ -17,7 +17,7 @@ without making any immediate changes.
 
 ## Scope (Epic mode)
 
-When this lens is invoked from `/epic-deliver` Phase 4 (epic-audit), the
+When this lens is invoked from `/deliver` Phase 4 (epic-audit), the
 following block is populated with the Epic's change-set file list.
 Otherwise — for any manual `/audit-<dimension>` invocation — the block
 renders the literal substitution token and you MUST treat it as **no