mandrel 1.59.0 → 1.60.0

package/.agents/workflows/{epic-plan.md → helpers/plan-epic.md}

@@ -4,7 +4,7 @@ description:
   Work Breakdown) for a GitHub Epic.
 ---
 
-# /epic-plan [Epic ID]
+# helpers/plan-epic — Epic planning path (invoked by /plan)
 
 ## Role
 
@@ -14,11 +14,11 @@ Director / Architect
 
 You are the master orchestrator for the v5 Epic-Centric ticketing pipeline. Your
 goal is to transform a high-level Epic into a fully decomposed, ready-to-execute
-backlog of Features and Stories.
+backlog of Stories.
 
-`/epic-plan` is the unified planning entry point. It delegates to the two
-phase helpers — [`helpers/epic-plan-spec.md`](helpers/epic-plan-spec.md) and
-[`helpers/epic-plan-decompose.md`](helpers/epic-plan-decompose.md) — and runs
+`/plan` is the unified planning entry point. It delegates to the two
+phase helpers — [`helpers/epic-plan-spec.md`](epic-plan-spec.md) and
+[`helpers/epic-plan-decompose.md`](epic-plan-decompose.md) — and runs
 both phases sequentially with a human confirmation gate between them. The Epic
 ID is the single positional argument.
 
@@ -34,12 +34,12 @@ artifacts you author.
 - Wait for user validation before migrating to Phase 8 when
   `planningRisk.requiresReview` is true (or the operator passes
   `--force-review`). Low-risk Epics auto-proceed after spec validation.
-  See [SDLC § Adaptive planning risk routing](../docs/SDLC.md#adaptive-planning-risk-routing)
+  See [SDLC § Adaptive planning risk routing](../../docs/SDLC.md#adaptive-planning-risk-routing)
   for the full envelope shape and the planner-selected
   `acceptance::n-a` route.
 - Delegate Phase 7 and Phase 8 to the
-  [`helpers/epic-plan-spec.md`](helpers/epic-plan-spec.md) and
-  [`helpers/epic-plan-decompose.md`](helpers/epic-plan-decompose.md)
+  [`helpers/epic-plan-spec.md`](epic-plan-spec.md) and
+  [`helpers/epic-plan-decompose.md`](epic-plan-decompose.md)
   procedures respectively — they own the Epic lifecycle label transitions and
   the `epic-plan-state` checkpoint. This wrapper must not apply those labels
   directly.
@@ -78,7 +78,7 @@ Phase 5 (Re-Plan Detection).
    to the operator and **STOP**. Do not proceed to Phase 2 until the
    user explicitly confirms the direction. This is the same gate the
    skill's own Phase 3 enforces; surfacing it here makes the wait
-   contract visible to `/epic-plan` callers. When the Phase 1.5 verdict is
+   contract visible to `/plan` callers. When the Phase 1.5 verdict is
    `story` or `borderline`, this stop carries the three-way choice the
    triage gate defines (below) instead of a plain confirm.
 
@@ -87,18 +87,18 @@ Phase 5 (Re-Plan Detection).
 This phase runs **only** on the ideation path, immediately after Phase 1
 produces the sharpened one-pager. It is **skipped entirely** when an Epic ID
 argument was supplied (the existing-Epic path jumps straight to Phase 5), and
-it is **skipped** when `/epic-plan` was entered via a scope-triage handoff from
-[`/story-plan`](story-plan.md) — a handoff is a triage decision already made,
+it is **skipped** when `/plan` was entered via a scope-triage handoff from
+[`/plan`](plan-story.md) — a handoff is a triage decision already made,
 and re-triaging it would re-litigate a settled call (the no-re-triage rule the
 skill states once).
 
 1. **Activate the scope-triage skill**: Read
-   [`<agentRoot>/skills/core/scope-triage/SKILL.md`](../skills/core/scope-triage/SKILL.md)
+   [`<agentRoot>/skills/core/scope-triage/SKILL.md`](../../skills/core/scope-triage/SKILL.md)
    via the `Read` tool (resolve `<agentRoot>` from `project.paths.agentRoot` —
    default `.agents`) and apply its rubric to the Phase 1 one-pager. The skill
    anchors its sizing judgment **by reference** to
    `DELIVERABLE_GRANULARITY_GUIDANCE` / `DEFAULT_TASK_SIZING` in
-   [`ticket-validator-sizing.js`](../scripts/lib/orchestration/ticket-validator-sizing.js)
+   [`ticket-validator-sizing.js`](../../scripts/lib/orchestration/ticket-validator-sizing.js)
    and emits one verdict: `epic` | `story` | `borderline`. The verdict is
    host-LLM judgment — there is **no `--flag`**, no scorer, no schema, and no
    label transition.
@@ -111,9 +111,9 @@ skill states once).
      presents a **three-way operator choice**:
      - **Recommended: single Story** (with the triage rationale) — persist the
        one-pager to a notes file and hand off to
-       `/story-plan --from-notes <path>`, identifying the invocation as a
-       scope-triage handoff so `/story-plan` skips its own gate. Then **exit
-       `/epic-plan`**.
+       `/plan --from-notes <path>`, identifying the invocation as a
+       scope-triage handoff so `/plan` skips its own gate. Then **exit
+       `/plan`**.
      - **Plan as Epic anyway** — ignore the recommendation and continue to
        Phase 2 with the one-pager.
      - **Abort** — stop planning entirely.
@@ -133,7 +133,7 @@ opening a duplicate.
 
 1. **Invoke the duplicate-search module**: Call
    `findSimilarOpenEpics({ onePager, provider })` exported from
-   [`.agents/scripts/lib/duplicate-search.js`](../scripts/lib/duplicate-search.js).
+   [`.agents/scripts/lib/duplicate-search.js`](../../scripts/lib/duplicate-search.js).
    The `provider` is the resolved ticketing provider
    (`provider-factory.js`), and `onePager` is the markdown returned by
    Phase 1.
@@ -142,7 +142,7 @@ opening a duplicate.
    list, render the candidates (id, title, score, URL) and **STOP**. Do
    not proceed to Phase 3 until the user either (a) confirms the new
    Epic is genuinely distinct or (b) chooses to fold the idea into one of
-   the existing Epics, in which case `/epic-plan` exits and the operator
+   the existing Epics, in which case `/plan` exits and the operator
    resumes work on the existing Epic ID.
 
 3. **No-match fast path**: If the module returns `[]`, proceed
@@ -155,9 +155,9 @@ new Epic is genuinely distinct).
 
 1. **Render the body**: Call
    `renderEpicBody({ onePager, template })` exported from
-   [`.agents/scripts/lib/epic-plan-ideation.js`](../scripts/lib/epic-plan-ideation.js).
+   [`.agents/scripts/lib/epic-plan-ideation.js`](../../scripts/lib/epic-plan-ideation.js).
    The `template` argument is the contents of
-   [`.agents/templates/epic-from-idea.md`](../templates/epic-from-idea.md),
+   [`.agents/templates/epic-from-idea.md`](../../templates/epic-from-idea.md),
    which carries the five canonical sections (Context, Goal, Non-Goals,
    Scope, Acceptance Criteria). Sections missing from the one-pager are
    rendered as `_(not specified)_` rather than left as raw `{{token}}`
@@ -180,7 +180,7 @@ new Epic is genuinely distinct).
    **Board membership (Story #3822)**: the provider's `createIssue`
    adds the new Epic to the configured Projects V2 board via the
    shared `addIssueToBoard` helper
-   ([`providers/github/board-add.js`](../scripts/providers/github/board-add.js))
+   ([`providers/github/board-add.js`](../../scripts/providers/github/board-add.js))
    — idempotent, non-fatal (warn-on-error), and a no-op when no
    project number is configured — so the Epic lands on the board
    without relying on GitHub's "Auto-add to project" built-in
@@ -216,13 +216,13 @@ planned.
    > tickets. Do you want to **re-plan**? This will **overwrite the PRD,
    > Tech Spec, and Acceptance Spec in place** (same issue numbers, refreshed
    > bodies, comment history preserved) and **close-and-recreate** all
-   > Feature/Story tickets."
+   > child Story tickets."
 
 3. **If user confirms re-plan**: Pass `--force` to all subsequent script
    invocations. Under `--force`, the three context tickets (PRD, Tech Spec,
    Acceptance Spec) are overwritten in place — their issue numbers, Epic
    sub-issue links, and prior discussion are preserved, and each receives a
-   one-line regeneration audit comment. Feature/Story child tickets are still
+   one-line regeneration audit comment. Child Story tickets are still
    closed and recreated, because a re-decomposition can legitimately produce a
    different ticket set.
 4. **If user declines**: Abort gracefully.
@@ -243,8 +243,8 @@ The advisory runs **only** when **both** hold:
 1. **Phase 5 found no planning artifacts** — the Epic body has no
    `## Planning Artifacts` section linking a PRD / Tech Spec (i.e. Phase 5
    did **not** enter its re-plan branch).
-2. **The Epic has no open Feature/Story children** — no open `type::feature`
-   or `type::story` sub-issues are linked to this Epic.
+2. **The Epic has no open Story children** — no open `type::story`
+   sub-issues are linked to this Epic.
 
 If **either** condition fails, **skip this phase silently** and continue to
 Phase 6. It must **never** fire on the re-plan path: recommending a "downgrade
@@ -256,14 +256,14 @@ triage on the one-pager before the Epic existed.
 ### Triage
 
 1. **Activate the scope-triage skill**: Read
-   [`<agentRoot>/skills/core/scope-triage/SKILL.md`](../skills/core/scope-triage/SKILL.md)
+   [`<agentRoot>/skills/core/scope-triage/SKILL.md`](../../skills/core/scope-triage/SKILL.md)
    via the `Read` tool (resolve `<agentRoot>` from `project.paths.agentRoot` —
    default `.agents`) and apply its rubric to the **Epic body**. The skill is
    artifact-agnostic — it reads the same against an Epic body as against a
    one-pager or a Story draft — and anchors its sizing judgment **by
    reference** to `DELIVERABLE_GRANULARITY_GUIDANCE` / `DEFAULT_TASK_SIZING`
    in
-   [`ticket-validator-sizing.js`](../scripts/lib/orchestration/ticket-validator-sizing.js).
+   [`ticket-validator-sizing.js`](../../scripts/lib/orchestration/ticket-validator-sizing.js).
    It emits one verdict: `epic` | `story` | `borderline`. The verdict is
    host-LLM judgment — there is **no `--flag`**, no scorer, no schema, and no
    label transition behind this gate. Do **not** restate the skill's rubric or
@@ -299,11 +299,11 @@ closes the Epic in its favor, and **every** issue mutation below happens
 1. **Seed a notes file from the Epic body.** Write the Epic's Context / Goal /
    Scope / Acceptance Criteria into a seed file under
    `temp/epic-[Epic_ID]/scope-triage-seed.md` (the `temp/` tree is gitignored).
-   This is the same notes-file shape `/story-plan --from-notes` consumes.
+   This is the same notes-file shape `/plan --from-notes` consumes.
 
-2. **Hand off to `/story-plan --from-notes`.** Invoke
-   [`/story-plan --from-notes temp/epic-[Epic_ID]/scope-triage-seed.md`](story-plan.md),
-   **identifying the invocation as a scope-triage handoff** so `/story-plan`
+2. **Hand off to `/plan --from-notes`.** Invoke
+   [`/plan --from-notes temp/epic-[Epic_ID]/scope-triage-seed.md`](plan-story.md),
+   **identifying the invocation as a scope-triage handoff** so `/plan`
    skips its own escalation gate (the skill's no-re-triage rule — a handoff is
    a settled triage decision, and re-running the gate on the receiving side
    would re-litigate it and risk a ping-pong between the two workflows). The
@@ -311,7 +311,7 @@ closes the Epic in its favor, and **every** issue mutation below happens
    (`Converted from Epic #[Epic_ID] — scope triaged as a standalone Story`) so
    the audit trail is bidirectional.
 
-3. **Close the Epic in favor of the replacement.** Once `/story-plan` has
+3. **Close the Epic in favor of the replacement.** Once `/plan` has
    created the replacement Story (capture its number as `#N`), close the Epic
    with a cross-linking comment:
 
@@ -326,10 +326,10 @@ closes the Epic in its favor, and **every** issue mutation below happens
    give a reviewer the full bidirectional trail.
 
 The conversion mutates two issues (creates the Story, closes the Epic) — both
-behind the single operator confirmation above. After conversion `/epic-plan`
+behind the single operator confirmation above. After conversion `/plan`
 exits: the work now lives on the standalone Story, which the operator delivers
-via [`/single-story-deliver`](helpers/single-story-deliver.md) or
-[`/story-deliver`](story-deliver.md).
+via [`/single-story-deliver`](single-story-deliver.md) or
+[`/deliver`](deliver-stories.md).
 
 ## Phase 6: Epic Clarity Gate
 
@@ -338,7 +338,7 @@ Detection) and the Phase 5.5 story-sized advisory, and before Phase 7
 (PRD, Tech Spec & Acceptance Spec). The gate scores the Epic body
 against the five canonical
 sections from
-[`.agents/templates/epic-from-idea.md`](../templates/epic-from-idea.md)
+[`.agents/templates/epic-from-idea.md`](../../templates/epic-from-idea.md)
 (Context, Goal, Non-Goals, Scope, Acceptance Criteria) and either
 skips fast (when the Epic body is already clear) or drops into a
 refinement loop seeded from the current Epic body. The scorer also
@@ -352,8 +352,8 @@ canonical headings. A `clear` verdict requires **both** ≥ 4 of 5
 sections present **and** the **Acceptance Criteria** section present —
 AC is a required section, not one of the four optional passers, so an
 Epic with no Acceptance Criteria is always `needs-refinement` (it would
-otherwise hard-fail the `/epic-deliver` start gate downstream). See
-[`lib/epic-plan-clarity.js`](../scripts/lib/epic-plan-clarity.js)
+otherwise hard-fail the `/deliver` start gate downstream). See
+[`lib/epic-plan-clarity.js`](../../scripts/lib/epic-plan-clarity.js)
 for the scoring logic.
 
 1. **Score the body**: Run the clarity-check CLI in context-emission
@@ -373,7 +373,7 @@ for the scoring logic.
 
 3. **Needs-refinement path**: When `verdict === 'needs-refinement'`,
    activate the
-   [`core/idea-refinement`](../skills/core/idea-refinement/SKILL.md)
+   [`core/idea-refinement`](../../skills/core/idea-refinement/SKILL.md)
    skill **seeded from the current Epic body** (not a blank seed),
    with `missingOrPlaceholder` as the convergence target. The skill
    runs its three-phase divergent → convergent → sharpen loop and
@@ -381,9 +381,9 @@ for the scoring logic.
 
 4. **Re-render the body**: Call
    `renderEpicBody({ onePager, template })` from
-   [`lib/epic-plan-ideation.js`](../scripts/lib/epic-plan-ideation.js)
+   [`lib/epic-plan-ideation.js`](../../scripts/lib/epic-plan-ideation.js)
    (the same helper Phase 3 uses), passing the contents of
-   [`.agents/templates/epic-from-idea.md`](../templates/epic-from-idea.md).
+   [`.agents/templates/epic-from-idea.md`](../../templates/epic-from-idea.md).
    Write the result to `temp/epic-[Epic_ID]/clarity-update.md`.
 
 5. **HITL stop — confirm the diff**: Display the diff between the
@@ -421,11 +421,11 @@ for the scoring logic.
 > `lib/orchestration/epic-plan-lease-guard.js`). The lease rides the Epic's
 > single assignee: the operator (`github.operatorHandle` in `.agentrc.json`)
 > claims the Epic for the duration of the plan. The guard **fails closed**:
-> `/epic-plan` emits no `story.heartbeat` during its run (heartbeats are a
+> `/plan` emits no `story.heartbeat` during its run (heartbeats are a
 > delivery-time signal), so there is no live-heartbeat source to judge a
 > concurrent plan's liveness from. Any **foreign assignee** is therefore
 > treated as a live claim — the persist half **exits non-zero and names the
-> current owner**, so two `/epic-plan` runs cannot drive the same Epic
+> current owner**, so two `/plan` runs cannot drive the same Epic
 > concurrently. Pass **`--steal`** to forcibly transfer a foreign claim once
 > you have confirmed the other run is dead. An **unassigned** Epic, or one
 > **already held by this operator**, is taken (or re-affirmed) silently. The
@@ -448,14 +448,14 @@ for the scoring logic.
 > (`context::acceptance-spec`). The Acceptance Spec captures the
 > stable-ID acceptance criteria table (`| AC ID | Outcome | Feature
 > File | Scenario | Disposition |`) that drives close-time
-> reconciliation during `/epic-deliver` Phase 6. Operators may opt out
+> reconciliation during `/deliver` Phase 6. Operators may opt out
 > for refactor-only or docs-only Epics by applying the
 > `acceptance::n-a` label to the Epic ticket — when present, the
 > `epic-plan-spec-author` skill skips the Acceptance Spec output and
 > the runtime gates (start gate, finalize reconciler) honour the
 > waiver — the spec ticket itself need not be authored or approved when
 > the waiver is set. See [SDLC § Acceptance Spec — the third planning
-> context ticket](../docs/SDLC.md#acceptance-spec--the-third-planning-context-ticket)
+> context ticket](../../docs/SDLC.md#acceptance-spec--the-third-planning-context-ticket)
 > for the full lifecycle.
 
 <!-- separator: adjacent blockquotes -->
@@ -475,7 +475,7 @@ for the scoring logic.
 > **Durability.** The per-Epic tree is durable across runs: only the
 > wrapper scripts perform intra-phase cleanup of files they wrote in
 > the same invocation (see
-> [`lib/plan-phase-cleanup.js`](../scripts/lib/plan-phase-cleanup.js)).
+> [`lib/plan-phase-cleanup.js`](../../scripts/lib/plan-phase-cleanup.js)).
 > Nothing else garbage-collects the tree, so cross-Epic artifacts —
 > retros, perf reports, signals, manifests — accumulate until an
 > operator explicitly removes them.
@@ -489,7 +489,7 @@ for the scoring logic.
    ```
 
 2. **Activate the `epic-plan-spec-author` skill**: Read
-   [`<agentRoot>/skills/core/epic-plan-spec-author/SKILL.md`](../skills/core/epic-plan-spec-author/SKILL.md)
+   [`<agentRoot>/skills/core/epic-plan-spec-author/SKILL.md`](../../skills/core/epic-plan-spec-author/SKILL.md)
    via the `Read` tool (resolve `<agentRoot>` from
    `project.paths.agentRoot` — default `.agents`) and execute its
    procedure with `[Epic_ID]` as input. The skill reads
@@ -532,8 +532,8 @@ for the scoring logic.
 
    # Re-planning (--force overwrites the three context tickets IN PLACE —
    # same PRD / Tech Spec / Acceptance Spec issue numbers, refreshed bodies,
-   # tickets kept open, one regeneration audit comment each. Feature/Story
-   # child tickets are still close-and-recreate at decomposition time.)
+   # tickets kept open, one regeneration audit comment each. Child Story
+   # tickets are still close-and-recreate at decomposition time.)
    node .agents/scripts/epic-plan-spec.js --epic [Epic_ID] \
      --prd temp/epic-[Epic_ID]/prd.md \
      --techspec temp/epic-[Epic_ID]/techspec.md \
@@ -560,7 +560,7 @@ for the scoring logic.
        PRD, Tech Spec, and Acceptance Spec on GitHub. Approval is the
        user's verbal OK in this session — the three context tickets stay
        **open** through delivery and are closed automatically by
-       `/epic-deliver` when the Epic PR opens. Do NOT proceed
+       `/deliver` when the Epic PR opens. Do NOT proceed
        to decomposition until the user confirms the plan is accurate.
      - **Low risk** (`requiresReview === false` and no `--force-review`):
        Emit the auto-proceed message from the persist stdout
@@ -571,7 +571,7 @@ for the scoring logic.
 
 5. **Tech Spec freshness check (advisory)**: After the Tech Spec issue
    is created, `epic-plan-spec.js` runs
-   [`validateSpecFreshness`](../scripts/lib/orchestration/spec-freshness.js)
+   [`validateSpecFreshness`](../../scripts/lib/orchestration/spec-freshness.js)
    against the authored Tech Spec body, probing every cited path-shape
    reference (backticked paths, `// header` lines in code blocks, and
    inline mentions of paths under `.agents/`, `src/`, `lib/`, `app/`,
@@ -598,11 +598,11 @@ for the scoring logic.
 6. **BDD scenario cross-reference (advisory)**: When the project has
    adopted BDD, `epic-plan-spec.js` populates the planner-context
    envelope with `bddScenarios` — the output of
-   [`scanBddScenarios`](../scripts/lib/bdd-scenario-scanner.js) over
+   [`scanBddScenarios`](../../scripts/lib/bdd-scenario-scanner.js) over
    the canonical feature roots resolved by
-   [`resolveFeatureRoots`](../scripts/lib/bdd-runner-detect.js)
+   [`resolveFeatureRoots`](../../scripts/lib/bdd-runner-detect.js)
    (`tests/features`, `features`, `test/features`). The Acceptance
-   Engineer step in the [`epic-plan-spec-author`](../skills/core/epic-plan-spec-author/SKILL.md)
+   Engineer step in the [`epic-plan-spec-author`](../../skills/core/epic-plan-spec-author/SKILL.md)
    skill scores each planned AC against the scenario index via
    `findBestScenarioMatch`; when an existing scenario covers an AC's
    outcome, the AC's `Scenario` column is annotated with `<file>:L<line>`
@@ -615,7 +615,7 @@ for the scoring logic.
 7. **Cleanup**: The wrapper script (`epic-plan-spec.js`) deletes the Phase 7
    temp files automatically on success — no operator action required. The
    cleanup contract lives in
-   [`lib/plan-phase-cleanup.js`](../scripts/lib/plan-phase-cleanup.js).
+   [`lib/plan-phase-cleanup.js`](../../scripts/lib/plan-phase-cleanup.js).
    **Run the Phase 7.5 spec-validate gate (below) on
    `temp/epic-[Epic_ID]/techspec.md` *before* this cleanup deletes the file** —
    the gate reads the authored spec from temp.
@@ -631,7 +631,7 @@ for the scoring logic.
 
 **Why this gate exists.** Phase 8.3 (Holistic Consolidation) reconciles the
 draft ticket array against the Tech Spec's `## Delivery Slicing` section, which
-the [`epic-plan-decompose-author`](../skills/core/epic-plan-decompose-author/SKILL.md)
+the [`epic-plan-decompose-author`](../../skills/core/epic-plan-decompose-author/SKILL.md)
 skill uses as the capability-boundary anchor (see Phase 8 step 2 below). When
 the authored Tech Spec omits that section, the consolidation pass runs against a
 void and produces groupings that reflect **technical shape** (e.g. cron jobs
@@ -651,7 +651,7 @@ node .agents/scripts/epic-plan-spec-validate.js \
   insensitive; the gate also accepts the variant `## Delivery slicing` and the
   shorthand `## Slicing`). Continue to Phase 8.
 - **Exit non-zero** — the required section is missing. The gate is implemented
-  by [`lib/orchestration/spec-section-validator.js`](../scripts/lib/orchestration/spec-section-validator.js)
+  by [`lib/orchestration/spec-section-validator.js`](../../scripts/lib/orchestration/spec-section-validator.js)
   and prints an operator-visible message naming the missing section and the two
   recovery paths:
 
@@ -680,20 +680,20 @@ node .agents/scripts/epic-plan-spec-validate.js \
 
 > **Open-children guard (workflow guard).** Before persisting the breakdown,
 > `epic-plan-decompose.js` refuses to run when the Epic **already has open
-> Feature/Story children**, unless `--force` (close + recreate the tree) or
+> Story children**, unless `--force` (close + recreate the tree) or
 > `--resume` (continue a partial persist) is set. This stops a re-run from
-> stacking a duplicate Feature/Story tree on top of an existing one — the
+> stacking a duplicate Story set on top of an existing one — the
 > phase exits non-zero and lists the open children. Once persist completes,
 > the Epic-lease acquired in Phase 7 is **released** (best-effort; a release
 > failure never fails decompose).
 
 <!-- separator: adjacent blockquotes -->
 
-> **Hierarchy.** The decomposer emits an Epic → Feature → Story tree.
+> **Hierarchy.** The decomposer emits a flat Story backlog under the Epic.
 > Acceptance criteria and verification steps are inlined on each Story
 > body (`acceptance[]` / `verify[]` fields) and resolved against the
 > Acceptance Spec context ticket at close time. See
-> [`.agents/instructions.md` § 5.D](../instructions.md) for the full
+> [`.agents/instructions.md` § 5.D](../../instructions.md) for the full
 > contract.
 
 1. **Gather Decomposition Context**:
@@ -703,7 +703,7 @@ node .agents/scripts/epic-plan-spec-validate.js \
    ```
 
 2. **Activate the `epic-plan-decompose-author` skill**: Read
-   [`<agentRoot>/skills/core/epic-plan-decompose-author/SKILL.md`](../skills/core/epic-plan-decompose-author/SKILL.md)
+   [`<agentRoot>/skills/core/epic-plan-decompose-author/SKILL.md`](../../skills/core/epic-plan-decompose-author/SKILL.md)
    via the `Read` tool (resolve `<agentRoot>` from
    `project.paths.agentRoot` — default `.agents`) and execute its
    procedure with `[Epic_ID]` as input. The skill reads
@@ -732,17 +732,17 @@ node .agents/scripts/epic-plan-spec-validate.js \
 3. **Phase 8.3 — Holistic Consolidation (HITL diff gate)**: After the
    draft `temp/epic-[Epic_ID]/tickets.json` exists and **before** the persist
    call below, activate the
-   [`epic-plan-consolidate`](../skills/core/epic-plan-consolidate/SKILL.md)
+   [`epic-plan-consolidate`](../../skills/core/epic-plan-consolidate/SKILL.md)
    skill with `[Epic_ID]` as input. This is a **separate critic pass with
    fresh context** (not a self-review appended to the author skill): it reads
    the draft array plus the PRD / Tech Spec, reconciles the draft against the
    Tech Spec `## Delivery Slicing` target, and emits a **consolidated**
    `tickets.json` plus a human-readable
    `temp/epic-[Epic_ID]/consolidation-report.md`. Its operations are
-   scope-preserving only — **merge Stories, collapse single-Story Features
-   into siblings, re-parent, rewire `depends_on`** — and it MUST NOT add scope
-   or invent tickets; it resolves single-Story Features by **collapsing**
-   them, never by splitting a lone Story. It runs **before** the deterministic
+   scope-preserving only — **merge sibling Stories and rewire
+   `depends_on`** — and it MUST NOT add scope or invent tickets; it
+   consolidates fragmented slices by merging them into a cohesive Story,
+   never by splitting one. It runs **before** the deterministic
    validator (step 4), so the validator re-checks its output and the critic
    cannot emit an invalid plan.
 
@@ -754,7 +754,7 @@ node .agents/scripts/epic-plan-spec-validate.js \
 
 4. **Persist to GitHub**: Run the decompose CLI's persist half. It
    validates the ticket array (`validateAndNormalizeTickets`), creates
-   the Feature/Story issues, flips the Epic to `agent::ready`, and
+   the Story issues, flips the Epic to `agent::ready`, and
    writes the `epic-plan-state` checkpoint.
 
    ```bash
@@ -771,7 +771,7 @@ node .agents/scripts/epic-plan-spec-validate.js \
    - Hierarchy completeness, dependency-DAG acyclicity, and `risk::high`
      labelling are deterministic invariants enforced by
      `validateAndNormalizeTickets` in
-     [`lib/orchestration/ticket-validator.js`](../scripts/lib/orchestration/ticket-validator.js);
+     [`lib/orchestration/ticket-validator.js`](../../scripts/lib/orchestration/ticket-validator.js);
      its output during decomposition is the canonical proof — no manual
      re-check needed.
    - **File-assumption gate (Story #2636)**: Each Story's `body.changes`
@@ -810,13 +810,12 @@ node .agents/scripts/epic-plan-spec-validate.js \
 
 6. **Audit**:
    - Check the Epic's comment thread to ensure the backlog summary was posted.
-   - Verify that at least one `type::feature` and `type::story` issue
-     was created.
+   - Verify that at least one `type::story` issue was created.
 
 7. **Cleanup**: The wrapper script (`epic-plan-decompose.js`) deletes the
    Phase 8 temp files automatically on success — no operator action required.
    The cleanup contract lives in
-   [`lib/plan-phase-cleanup.js`](../scripts/lib/plan-phase-cleanup.js).
+   [`lib/plan-phase-cleanup.js`](../../scripts/lib/plan-phase-cleanup.js).
 
 ## Phase 9: Execution Roadmap (Story Dispatch)
 
@@ -835,19 +834,19 @@ node .agents/scripts/epic-plan-spec-validate.js \
    > **Manifest persistence (v5.9.0):** the dispatcher also posts the manifest
    > as a `dispatch-manifest` structured comment on the Epic (idempotent —
    > re-runs replace the prior comment). That comment is the source of truth for
-   > the Wave Completeness Gate in `/epic-deliver` Step 0.5 and for any external
+   > the Wave Completeness Gate in `/deliver` Step 0.5 and for any external
    > wave-tracking tooling.
 
 3. **Handoff**: Provide the user with the recommended next step:
 
-   > "Planning is complete. Run `/epic-deliver #[Epic ID]` to start the wave
-   > loop, or pick a single Story from Wave 0 and run `/story-deliver #[Story
+   > "Planning is complete. Run `/deliver #[Epic ID]` to start the wave
+   > loop, or pick a single Story from Wave 0 and run `/deliver #[Story
    > ID]` to drive it directly."
 
 ## Phase 10: Readiness Health Check
 
 Run the post-plan health check to validate the backlog before handing off to
-`/epic-deliver`. The default mode runs only the cheap checks
+`/deliver`. The default mode runs only the cheap checks
 (config + git remote) and targets sub-2-second turnaround. The script itself
 always exits 0; the structured JSON on stdout reports findings.
 
@@ -899,7 +898,7 @@ triaged it (e.g. a known `origin` outage during a maintenance window).
 ## Phase 11: Plan Comprehension Gate
 
 An **opt-in, advisory** gate that offers the operator a guided walkthrough of
-the freshly planned backlog before they hand off to `/epic-deliver`. The plan
+the freshly planned backlog before they hand off to `/deliver`. The plan
 is the moment the operator authorizes an autonomous fan-out of subagents — this
 phase exists so they can *understand and endorse* the approach while it is
 still free to change, not after the code lands.
@@ -931,15 +930,15 @@ forcing the walkthrough.
 ### 2. Run the walkthrough (when offered and accepted)
 
 Activate the
-[`core/knowledge-transfer`](../skills/core/knowledge-transfer/SKILL.md) skill
+[`core/knowledge-transfer`](../../skills/core/knowledge-transfer/SKILL.md) skill
 with the **plan** as the subject — the Epic body, the linked PRD / Tech Spec
-context tickets, the decomposition (Features/Stories with inline
+context tickets, the decomposition (Stories with inline
 `acceptance[]` / `verify[]`), and the Phase 9 wave roadmap. The skill owns the
 method (restate-first, the why-ladder, mastery gates, depth levels, optional
 quizzing, the persistent `temp/comprehension-*.md` checklist).
 
 **Interruptible at every checkpoint.** Each step MUST offer an explicit
-"I'm good — proceed to `/epic-deliver`" exit. The instant the operator takes
+"I'm good — proceed to `/deliver`" exit. The instant the operator takes
 it, stop the walkthrough and advance to Phase 12. Never trap the operator in
 the loop.
 
@@ -957,7 +956,7 @@ condition.
      the notification script:
 
    ```bash
-   node .agents/scripts/notify.js [Epic_ID] "Planning complete, review tickets. Backlog decomposition complete. Epic is ready for /epic-deliver." --action
+   node .agents/scripts/notify.js [Epic_ID] "Planning complete, review tickets. Backlog decomposition complete. Epic is ready for /deliver." --action
    ```
 
 ## Troubleshooting
@@ -965,9 +964,10 @@ condition.
 - If `epic-plan-spec.js --emit-context` fails, confirm the Epic exists and
   has a body with enough initial context.
 - If `epic-plan-decompose.js` rejects the tickets file, re-read the
-  validator's error message — the most common causes are a Story with no
-  `parent_slug`, a Story whose `parent_slug` does not point at a Feature, or a
-  dependency cycle in the Story `depends_on` graph.
+  validator's error message — the most common causes are a ticket whose
+  `type` is not `story`, a Story missing its inline `acceptance[]` /
+  `verify[]` contract, or a dependency cycle in the Story `depends_on`
+  graph.
 - If decomposition persisted the tickets but the Epic is not on `agent::ready`,
   you likely called `runDecomposePhase` from `epic-plan-decompose.js`
   directly without completing the persist flow — only the CLI surface