@gtrabanco/pi-agentic-workflow 0.15.2 → 0.16.0

package/skills/fold-findings/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: fold-findings
 user-invocable: true
-version: 1.6.0
+version: 1.7.0
 argument-hint: [finding-id …]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -123,9 +123,9 @@ frozen class is `replan-in-unit` or `decision-required`, nothing folds: no
 `folded: yes` flips, no commits. The receipt records the `REPLAN-ROUTE` branch
 and every retained (unfolded) row id, and the loop stops. The consumer is the
 conclusion the already-run router printed, never the invocation itself: on
-`route: replan` the planner it named — `/plan-fix <n>` for a fix unit or
-`/plan-feature <slug>` for a feature unit; on `route: decision` stop and
-surface the decision to the user, never a planner. `<unit>` is the bare folder number or the full slug (both resolve). The invocation
+`route: replan` the planner command it printed — `/unit-lane <slug>` for a
+feature unit or `/unit-lane --fix <n>` for a fix unit; on `route: decision` stop
+and surface the decision to the user, never a planner. `<unit>` is the bare folder number or the full slug (both resolve). The invocation
 `node scripts/unit-route.mjs <unit>` is the discovery step the fold already
 ran; it is never the recommendation.
 
@@ -173,7 +173,7 @@ or touched outside the queue.
   · all FOLDED (<F1> + <F2> + …) → /review-change — re-review the branch now that all listed findings are fixed
   · any DISPUTED (<F1> + <F2> + …) → user decision — resolve every evidenced dispute without creating backlog
   · any BLOCKED (<F1> + <F2> + …) → supply the listed missing inputs, then re-run /fold-findings
-  · any REPLAN (<F1> + <F2> + …) → /plan-fix <n> or /plan-feature <slug> — the planner appends the proposed phases to the unit's SPEC, the user confirms them, then a fresh /review-plan must pass before /execute-phase on this unit
+  · any REPLAN (<F1> + <F2> + …) → /unit-lane <slug> or /unit-lane --fix <n> — the lane re-runs its plan step, appends the phases to the unit's SPEC; its review step gates before /execute-phase on this unit
   · any DECISION (<F1> + <F2> + …) → stop and surface the decision to the user — a `route: decision` conclusion names no planner, so the unit waits on the user before any plan or code change
 ```
 
@@ -182,8 +182,8 @@ several lines, never joined into one prose line.
 
 Replace placeholders with every actual affected finding ID before printing; never
 print `<F2>`, `…`, or a single representative ID in a live hand-off. Resolve the
-`/plan-fix <n>` / `/plan-feature <slug>` unit argument the same way — never carry
-`<n>` or `<slug>` into a live hand-off.
+`/unit-lane <slug>` / `/unit-lane --fix <n>` unit argument the same way — never
+carry `<slug>` or `<n>` into a live hand-off.
 
 ## Closing-block decision branch (choose one, at emission)
 
@@ -193,7 +193,7 @@ decision to skip.
 
 | Batch state | Branch | `→ Next:` (consumer) |
 |---|---|---|
-| freeze-batch (≥ 1 replan-class row) | `REPLAN-ROUTE` | `/plan-fix <n>` (fix) or `/plan-feature <slug>` (feature) when the router concludes `replan` — user confirms, fresh `/review-plan` passes, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user — the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran) |
+| freeze-batch (≥ 1 replan-class row) | `REPLAN-ROUTE` | `/unit-lane <slug>` (feature) or `/unit-lane --fix <n>` (fix) when the router concludes `replan` — user confirms, the lane's `plan` step appends the phases and its `review` step gates, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user — the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran) |
 | `all-repair-in-place` + docs-only + no folded row severity `high` + prior consumer skip decision | `RE-REVIEW-SKIPPED` | skip — consumer has explicitly decided to skip the re-review |
 | `all-repair-in-place` + docs-only + no folded row severity `high` | `RE-REVIEW-OPTIONAL` | `/review-change` (default, delta mode) — or the consumer's recorded skip decision |
 | empty batch (class `none`) | `RE-REVIEW-OPTIONAL` | `/review-change` by default — safe: the head is unchanged |

package/skills/fold-findings/references/FOLD_PROCESS.md

@@ -43,7 +43,7 @@
 
    | Condition over the taken batch | Batch class | Fold behavior |
    |---|---|---|
-   | ≥ 1 row with frozen class `replan-in-unit` or `decision-required` | `frozen (replan present)` | **freeze-batch** — nothing folds, no `folded: yes` flips, no commits; the receipt records the REPLAN-ROUTE and every retained (unfolded) row id; the loop stops; the consumer is the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran), where `<unit>` is the bare folder number or the full slug (both resolve): on `route: replan` the planner — `/plan-fix <n>` (fix) or `/plan-feature <slug>` (feature) — user confirms, fresh `/review-plan` passes, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user, never a planner |
+   | ≥ 1 row with frozen class `replan-in-unit` or `decision-required` | `frozen (replan present)` | **freeze-batch** — nothing folds, no `folded: yes` flips, no commits; the receipt records the REPLAN-ROUTE and every retained (unfolded) row id; the loop stops; the consumer is the conclusion printed by `node scripts/unit-route.mjs <unit>` (discovery step the fold already ran), where `<unit>` is the bare folder number or the full slug (both resolve): on `route: replan` the planner command the router printed — `/unit-lane <slug>` (feature) or `/unit-lane --fix <n>` (fix) — the lane appends the phases and its `review` step gates, then `/execute-phase` on this unit; on `route: decision` stop and surface the decision to the user, never a planner |
    | all taken rows foldable, none replan-class | `all-repair-in-place` | fold as today (group → fix → gate → commit → flip) |
    | empty queue (zero findings taken) | `none` | receipt only |
 
@@ -58,11 +58,12 @@
    `DISPUTED <evidence → user decision>`; never edit classification or create an
    issue.
 9. **Replan.** If the smallest correct group exceeds a reviewable correction,
-   run `node scripts/unit-route.mjs <unit>` — its `route: replan` line names the
-   planner (`/plan-feature <slug>` or `/plan-fix <n>`) that appends the proposed
+   run `node scripts/unit-route.mjs <unit>` — its `route: replan` line prints the
+   planner command (`/unit-lane <slug>` for a feature, `/unit-lane --fix <n>` for
+   a fix) that appends the proposed
    phases to the unit's SPEC. The `<unit>` argument accepts the bare folder number
-   or the full slug (both resolve). After the user confirms and a fresh
-   `/review-plan <unit>` passes, `/execute-phase <unit>` completes them and ticks
+   or the full slug (both resolve). After the user confirms and the lane's
+   `review` step passes, `/execute-phase <unit>` completes them and ticks
    the rows. When the router concludes `route: decision` instead — a
    `decision-required` row with no replan row — stop and surface the decision to
    the user; no planner runs until the user decides.

package/skills/orchestration-envelope/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: orchestration-envelope
 user-invocable: false
-version: 2.2.0
+version: 2.2.1
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
@@ -36,8 +36,9 @@ copy a second schema here.
   driver appends `renderOutputInstruction(skill)` to that invocation. It has
   the small model-owned fields: outcome, next intent/targets, blockers,
   questions, discoveries, and evidence references.
-- `ship-roadmap` is the conductor, not a worker profile: it keeps its native
-  terminal `SHIP:` banner and is parsed by its own fixed turn contract.
+- `advance` (the companion pi package command) is the conductor, not a worker
+  profile: it runs as deterministic code over the sensor envelope and never
+  emits a worker SkillOutcome.
 - Interactive invocations emit their normal human-readable reports; no driver
   result is required.
 

package/skills/phase-contract/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: phase-contract
 user-invocable: false
-version: 1.0.5
+version: 1.0.6
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
   Internal contract: the single owner of the eight phase-lint rules, the fixed
   PASS/BLOCKED result, and the normalized phase fingerprint. Consumed by
-  plan-feature-scaffold, plan-fix, and execute-phase. Not a menu entry.
+  `execute-phase` and the lane's `plan` step. Not a menu entry.
 ---
 
 # Phase Contract (internal)
@@ -18,8 +18,7 @@ the same rules before any edit. Nothing else may define what a valid phase is.
 
 ## When to use
 
-- `plan-feature-scaffold` — lint every phase of a feature plan before emission.
-- `plan-fix` — lint every phase of a fix SPEC before commit.
+- The lane's `plan` step — lint every phase before emission.
 - `execute-phase` — phase-lint pre-flight guard before editing a phase.
 - Templates store the contract version + fingerprint + lint result, never the
   eight rules (they point here).

package/skills/pre-execution-review/SKILL.md

@@ -1,14 +1,16 @@
 ---
 name: pre-execution-review
 user-invocable: false
-version: 2.5.1
+version: 2.6.0
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
 description: >
   Internal owner of the pre-execution review cycle and the planning ledgers:
   independence, unioned findings, counter-evidence dismissal, no-progress,
   `CONVERGENCE-ANOMALY`, and the evidence/obligation/findings tables. Consumed by
-  `review-spec`, `review-plan`, and the authoring skills. Not a menu entry.
+  `execute-phase`, `review-change`, and the lane's authoring steps for the
+  **planning-ledger shapes and ownership**; the pre-execution verdict owners
+  (`review-spec`/`review-plan`) were retired by feature 61. Not a menu entry.
 ---
 
 # Pre-Execution Review Policy (internal)
@@ -22,15 +24,16 @@ writes nothing, and emits no verdict of its own.
 evidence-grounding  = how an author prepares and self-checks an artifact.
 pre-execution-review = how any pre-execution reviewer judges it, and what the
                        frozen ledgers look like.
-review-spec / review-plan = the only skills that emit a pre-execution verdict.
+lane (design/plan/review steps) = the surviving pre-execution path; feature 61
+                       P8b retired the standalone review-spec / review-plan
+                       verdict skills, so this pack now owns the ledger shapes
+                       the lane and execute-phase consume, not a verdict gate.
 ```
 
 ## When to use
 
-- `review-spec` / `review-plan` — before the first check and again before any
-  repeat, repair, or synthesis step.
-- `design-feature`, `plan-feature`, `plan-feature-scaffold`, `plan-fix` — when
-  writing the ledgers and when a review comes back failed.
+- The lane's `plan`/`review` steps — when writing the ledgers and when a review
+  comes back failed.
 - Nothing else. Candidate-source review (`review-change`), merge gating
   (`audit-pr`) and execution (`execute-phase`) keep their own contracts; this
   skill adds no authority over them.

package/skills/pre-execution-review/references/POLICY.md

@@ -1,6 +1,14 @@
+## Status (feature 61 P8b)
+
+`review-spec` and `review-plan` are retired and
+absorbed into the lane. This document now governs the **planning-ledger shapes
+and ownership** (`LEDGERS.md`) that `execute-phase` and `review-change` consume;
+the spec/plan review-cycle semantics below are retained for the legacy units
+that still carry those receipts and are not applied by any live skill.
+
 ## The pre-execution review cycle
 
-Both `review-spec` and `review-plan` run this cycle. The stage files add only
+Both `review-spec` and `review-plan` ran this cycle. The stage files added only
 what is specific to their artifact set.
 
 ### 1. Independence
@@ -97,10 +105,11 @@ outside this policy and can never be translated into a PASS.
 
 A **third cycle never** starts without explicit user instruction: after two
 consecutive unconverged cycles the orchestrator's `stop-review-loop-cap` refusal
-stops a further `review-spec`/`review-plan` invocation, names `design-feature` as
+stops a further spec/plan review-cycle invocation, names the lane's `design` step
+as
 the human route, and a PASS resets the count. An unconverged loop ends in the
 `needs-design` verdict where the verdict vocabulary sanctions it (the spec stage)
-and in the refusal plus `design-feature` routing at the plan stage. The guards
+and in the refusal plus the lane's `design` routing at the plan stage. The guards
 above gate **blind re-reviews** — an identical snapshot with the identical
 question — and never a repair performed in response to a persisted verdict: a
 repair turn whose input is a FAIL/NEEDS-DESIGN receipt produces a new snapshot by
@@ -115,9 +124,9 @@ a count and never waives a finding.
 - A PASS earned by dropping a finding to `info`, by narrowing a check, or by
   editing a validator/test to accept the artifact.
 - A silent second cycle, a silent dismissal, or a silent substitute receipt.
-- An automatic forge issue. No route in the pre-execution set — `evidence-grounding`
-  readiness, `review-spec`, `review-plan`, `plan-feature-scaffold`, `plan-fix`,
-  `execute-phase`, `workflow-status`, `ship-roadmap`, `review-change`,
+- An automatic forge issue. No route in the pre-execution set — the lane's
+  `research`/`design`/`plan`/`review` steps, `execute-phase`, `workflow-status`,
+  `advance`, `review-change`,
   `audit-pr` — creates one for a planning gap, and none defers
   an obligation to a future issue: the row stays in the unit's ledger, open, until
   the **user** amends the governing SPEC. A blocker that says "file an issue" is a
@@ -142,8 +151,8 @@ One rule, same shape for every consumer:
   and obligation ledgers, built from the artifacts as they stand today — and leave
   `ACCEPTANCE.md`, `PLAN.md`, `TASKS.md`, the phase commits and any older receipt
   byte-identical. Rewriting an old verdict, its digest, or its date is forgery.
-- **Re-review, then resume.** The adopted unit runs `/review-plan` like any other and
-  `execute-phase` resumes **only** on that current `PLAN-REVIEW-PASS`. A pre-28 unit
+- **Re-review, then resume.** The adopted unit re-runs the lane's `review` step like any other and
+  `execute-phase` resumes **only** on that current verdict. A pre-lane unit
   is never grandfathered in on the strength of its roadmap status.
 - **No retroactive defect.** A missing ledger means the unit predates the gate, not
   that its author was wrong; report it as `legacy`, never as a finding against them.

package/skills/product-audit/SKILL.md

@@ -2,7 +2,7 @@
 name: product-audit
 user-invocable: true
 disable-model-invocation: true
-version: 3.2.1
+version: 3.3.0
 metadata:
   opencode/autoinvoke: false
 argument-hint: <path-or-area> (optional — defaults to the whole product)
@@ -117,7 +117,7 @@ Verdict: <one-line honest health verdict>
   (none — <why>)
 
 ### Roadmap — add
-  - <feature> — from: F<k> — <rationale & opportunity> — route: plan-feature
+  - <feature> — from: F<k> — <rationale & opportunity> — route: /unit-lane --from-issue <n>
   (none — <why>)
 
 ### Roadmap — remove / revise
@@ -126,7 +126,7 @@ Verdict: <one-line honest health verdict>
 
 ### Tooling — register / re-design
   - <skill|MCP> — register in AGENTS.md (Optional review extras): <why> — route: user edits AGENTS.md
-  - <skill|MCP> — would change <feature> scope: <why> — route: /design-feature <slug>
+  - <skill|MCP> — would change <feature> scope: <why> — route: /unit-lane <slug>
   (none — <why>)
 
 ## Manual-verification checklist (what automation can't confirm)
@@ -134,7 +134,7 @@ Verdict: <one-line honest health verdict>
 
 Finding set: F<k> + F<j> + F<m> (print every proposed finding; one finding → F<k>)
 → Next: /triage-issue <id> F<k> F<j> F<m> — classify the complete finding set in one batch (opens the ones that warrant it)
-  · accepted bug/debt → /plan-fix   · accepted capability → /plan-feature
+  · accepted bug/debt → /unit-lane --fix <n>   · accepted capability → /unit-lane --from-issue <n>
   · nothing to act on → the persisted report is the record; move on
 ```
 
@@ -159,12 +159,12 @@ security items to track first").
   order, never a different letter per problem type. Once persisted, ids are
   frozen: a later audit gets a new audit id, never renumbers an old file; cross-audit
   lineage lives only in Delta mappings as `<audit-id> F<k>`, never global slugs or
-  replaced ids. When the user accepts, route: `triage-issue` files/classifies,
-  `plan-feature` adds roadmap work, `plan-fix` scopes a concrete fix.
+  replaced ids. When the user accepts, route: `triage-issue` files/classifies, `/unit-lane`
+  adds roadmap work or scopes a concrete fix.
 - **Never registers tooling or edits `AGENTS.md`.** The tooling sweep proposes a
-  skill/MCP to register, but the user (or a routed `design-feature` run)
+  skill/MCP to register, but the user (or a routed `/unit-lane <slug>` run)
   performs the edit; a scope-affecting discovery routes to
-  `/design-feature <slug>`, which the user approves.
+  `/unit-lane <slug>`, which the user approves.
 - Platform-adaptive: run only applicable axes; always list what you skipped and why.
 - **No silent caps.** If you sampled, prioritized, or time-boxed a dimension, say
   so — never present partial coverage as exhaustive.
@@ -198,10 +198,10 @@ product-audit (whole product, all axes, periodic)
    ├─ composes review-change axes (codebase-wide) + audit-docs (doc coherence)
    ├─ mines feature docs (decisions / known-issues / architecture-notes)
    ├─ sweeps installed skills / connected MCP servers (product-wide, periodic)
-   └─ proposes ─┬─ Issues to open ........ ▶ triage-issue / plan-fix
-                ├─ Roadmap: add .......... ▶ plan-feature
+   └─ proposes ─┬─ Issues to open ........ ▶ triage-issue / unit-lane --fix
+                ├─ Roadmap: add .......... ▶ unit-lane --from-issue
                 ├─ Roadmap: remove/revise  ▶ triage-issue / roadmap edit   (user decides)
-                └─ Tooling: register/re-design ▶ user edits AGENTS.md / design-feature
+                └─ Tooling: register/re-design ▶ user edits AGENTS.md / unit-lane
 ```
 
 - Broader than `review-change` (one change) and `audit-pr` (one PR); subsumes
@@ -221,5 +221,4 @@ product-audit (whole product, all axes, periodic)
   with the next incremental audit id, and printed in chat.
 - Nothing else was fixed, filed, or changed — the user decides what to act on.
 - The **closing `→ Next:` block is printed** — typically a batch
-  `/triage-issue <id> F<k> …` for the proposed issues, then `/plan-feature` /
-  `/plan-fix` for the accepted work.
+  `/triage-issue <id> F<k> …` for the proposed issues, then `/unit-lane` for the accepted work.

package/skills/product-audit/references/AUDIT_PROCESS.md

@@ -32,7 +32,7 @@ step (2–5). Each item ends with exactly one fallback; never pick another one m
    inventory freshness**: cross-check `docs/CAPABILITIES.md` against the code —
    roles, permissions, or cross-cutting subsystems present in the code but
    missing from the inventory (or vice versa) are a Process & docs finding
-   (`design-feature`'s Integration closure is only as good as this file). If
+   (`unit-lane`'s design step Integration closure is only as good as this file). If
    the project has no inventory file, propose seeding it from the template —
    a finding, never an auto-fix.
 4. **Mine accumulated suggestions** — read every feature folder's `decisions.md`,

package/skills/resolve-repository-state/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: resolve-repository-state
 user-invocable: true
-version: 1.2.1
+version: 1.2.2
 argument-hint: <contradiction-id>
 description: >
   Resolve an explicit Normalized Repository State contradiction. This is the
@@ -74,7 +74,6 @@ If human input is required:
 Otherwise:
 
 → Next: resume the interrupted workflow named by `Reported by` — continue from the resolved snapshot
-  · planning was interrupted → /plan-feature <slug>
+  · planning was interrupted → /unit-lane <slug>
   · implementation was interrupted → /execute-phase <NN>
-    (only while its `PLAN-REVIEW-PASS` is still current → else /review-plan <NN>)
   · review, audit, or status was interrupted → rerun that same skill

package/skills/review-change/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-change
 user-invocable: true
-version: 3.7.1
+version: 3.8.0
 argument-hint: <path-or-glob> [--adversarial N] [--synthesize]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -42,8 +42,8 @@ finding.
 ## Review-end turn boundary
 
 On `REVIEW-FAIL` or `NEEDS-DECISION`, this skill **ends at the report**: it
-never invokes `/fold-findings`, `/execute-phase`, `/plan-feature`,
-`/design-feature` or `/triage-issue` — those are separate user-initiated invocations,
+never invokes `/fold-findings`, `/execute-phase`, `/unit-lane` or
+`/triage-issue` — those are separate user-initiated invocations,
 run in a fresh turn (a programmatic outer driver may compose the same
 sequence in-turn, per `REVIEW_PROCESS.md`). The review's only mutations are the
 ledger commit (persist step 11) and, on `REVIEW-PASS` with a PR, the

package/skills/review-change/references/ADVERSARIAL_RECOMMENDATION.md

@@ -23,7 +23,7 @@ model identity, so this skill never tries; it states the condition in prose
 and lets the human (or the orchestrator that knows which model is running)
 judge it.
 
-**N ladder (fixed).** `N=2` is the default (the `ship-roadmap` floor). Bump to
+**N ladder (fixed).** `N=2` is the default (the `advance` floor). Bump to
 `N=3` when either holds: the change has a security/auth surface, or all
 available reviewers share one model family (the third reviewer buys back some
 of the decorrelation a single family can't provide). `N>3` is **explicitly

package/skills/review-change/references/ADVERSARIAL_SETUP.md

@@ -11,7 +11,7 @@ fused table.
 no message (today's default). `--adversarial` passed **without** a valid N
 (no number given, or a number `< 2`) → usage error: state that `--adversarial`
 needs an integer N≥2 and fall back to the single-reviewer path — never
-silently run 1. `ship-roadmap`'s hard floor always passes `N=2`.
+silently run 1. `advance`'s hard floor always passes `N=2`.
 
 **Why N reviewers.** A single adversarial, context-clean reviewer (see the
 turn-contract box) decorrelates some blind spots; running N independent

package/skills/review-change/references/OUTPUT_AND_GUARDRAILS.md

@@ -22,16 +22,16 @@ lost, and none becomes reviewer-created backlog (D3):
 
 - **fix-now** → persisted to the unit's `review-findings.md` fold ledger, then
   routed to the current phase's fold cycle (`/fold-findings`, invoked after this review ends)
-  — never a tracked issue, never `plan-fix`. Classification honors
+  — never a tracked issue, never a standalone replan. Classification honors
   `review-implementation`'s **current-unit contract**: in-scope defects are
   always fix-now / replan-in-unit — never a postpone/tradeoff/wontfix/new-issue
   escape.
 - **fix-now / `replan-in-unit`** (too large to fold as-is) → keeps its fix-now
   class and ledger row; run `node scripts/unit-route.mjs <unit>` — its
-  `route: replan` line names the planner (`/plan-feature <unit>` for a feature,
-  `/plan-fix <n>` for a fix). The planner re-cuts the plan on this branch, the
-  user confirms the appended SPEC phase(s), a fresh `/review-plan <unit>` passes,
-  and only then `execute-phase` runs them.
+  `route: replan` line prints the planner command (`/unit-lane <unit>` for a
+  feature, `/unit-lane --fix <n>` for a fix). The lane re-runs its plan step on
+  this branch, the user confirms the appended SPEC phase(s), its review step
+  gates, and only then `execute-phase` runs them.
 - **fix-now / `decision-required`** → stop and surface the decision to the user;
   the unit blocks until decided. No issue is created.
 - **proposal** (independent future capability) → batched in the report with a

package/skills/review-change/references/PERSIST_AND_DECIDE.md

@@ -126,13 +126,14 @@ exact command tokens.
      third cycle never starts without an explicit user instruction)
      · /audit-pr → only after the table is clean (not yet — findings open)
       · any finding routed replan-in-unit or owned by plan? → `node
-        scripts/unit-route.mjs <unit>` prints `route: replan` and names the
-        planner (`/plan-feature <unit>` for a feature, `/plan-fix <n>` for a fix);
-        the planner re-cuts the plan on this branch, a fresh `/review-plan <unit>`
-        passes, then `/execute-phase <unit>` (yes: list the finding ids; no: omit
+        scripts/unit-route.mjs <unit>` prints `route: replan` and the planner
+        command (`/unit-lane <unit>` for a feature, `/unit-lane --fix <n>` for a
+        fix); the lane re-runs its plan step on this branch, its review step
+        gates, then `/execute-phase <unit>` (yes: list the finding ids; no: omit
         this line)
-      · any finding owned by product? → /design-feature <unit>, then /review-spec
-        <unit> (yes: list the ids; no: omit this line)
+      · any finding owned by product? → /unit-lane <unit> — the lane's design
+        step repairs the half, its review step re-judges it (yes: list the ids;
+        no: omit this line)
       · independent proposals → present to the user; only the user routes them
         to /triage-issue
      · adversarial recommendation checklist fired AND this run was

package/skills/review-implementation/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: review-implementation
 user-invocable: false
-version: 1.9.0
+version: 1.10.0
 argument-hint: <path-or-glob>
 allowed-tools: Read, Grep, Glob, Bash, WebFetch
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"

package/skills/review-implementation/references/CLASSIFY.md

@@ -85,7 +85,7 @@ in-scope capability complete (D2: complete capabilities, not short unit
 duration). Current-unit work has **only blocking outcomes**:
 
 - **fix-now** — it can fold directly. It is NEVER a tracked issue and NEVER
-  routes to `plan-fix`: it folds into the current unit's open phase (AC 12).
+  routes to a standalone replan: it folds into the current unit's open phase (AC 12).
 - **replan-in-unit** — it needs additional user-confirmed phases (see *Large
   in-scope fix-now → replan, never downgrade* below).
 - **decision-required** — a new product/architecture decision is unavoidable.
@@ -109,11 +109,12 @@ the user routes a proposal to `triage-issue`.
 An in-scope fix-now too large to fold as-is (multi-file redesign, or evidence
 the unit should have been split) keeps its **fix-now** class — size is never a
 reason to downgrade. Set its `Route` to **`replan-in-unit`**: run
-`node scripts/unit-route.mjs <unit>` — its `route: replan` line names the planner
-(`/plan-feature <unit>` or `/plan-fix <n>`) — and the unit's SPEC `## Phases`
-ledger gets one or more new phases covering the work, on the SAME branch, a fresh
-`/review-plan <unit>` passing before `execute-phase` runs them. It never routes to
-`plan-fix` for a new unit or a new issue (AC 12). Placement
+`node scripts/unit-route.mjs <unit>` — its `route: replan` line prints the
+planner command (`/unit-lane <unit>` for a feature, `/unit-lane --fix <n>` for a
+fix) — and the unit's SPEC `## Phases`
+ledger gets one or more new phases covering the work, on the SAME branch, the
+lane's own `review` step passing before `execute-phase` runs them. It never routes to
+a standalone planner for a new unit or a new issue (AC 12). Placement
 depends on whether the final `Hardening & PR` phase has already run:
 
 - **Hardening not yet executed** → insert the new phase(s) BEFORE it; the
@@ -150,10 +151,11 @@ your domains):
 ## Routing (what each class feeds)
 
 - **fix-now** → fold directly into the current unit's open phase; never a
-  tracked issue, never `plan-fix` (AC 12).
+  tracked issue, never a standalone planner (AC 12).
 - **fix-now / `replan-in-unit`** → `node scripts/unit-route.mjs <unit>` prints
-  `route: replan`; the planner it names re-cuts the SPEC `## Phases` ledger
-  (user confirms), a fresh `/review-plan <unit>` passes, then `execute-phase`
+  `route: replan`; the planner command it prints re-cuts the SPEC `## Phases`
+  ledger
+  (user confirms), the lane's `review` step gates, then `execute-phase`
   runs the new phases — never a downgrade, never a tracked issue (AC 12).
 - **fix-now / `decision-required`** → stop and surface the decision; the unit
   blocks until the user decides. No issue is created.
@@ -172,8 +174,8 @@ finding in its `Route` cell.
 | Owning stage | Hand-off | Never |
 |---|---|---|
 | `source` | fold locally: `/fold-findings`, then re-run `/review-change` on the changed HEAD | — |
-| `plan` | run `node scripts/unit-route.mjs <unit>` → `route: replan`; the planning author re-cuts the artifact (SPEC `## Phases`, an obligation row, an acceptance mapping, a ledger) on the same branch with the user's confirmation, then a **fresh `/review-plan <unit>`** precedes `execute-phase` | fold it in code and leave the plan describing the old build |
-| `product` | `/design-feature <unit>` repairs the half, then `/review-spec <unit>` re-judges it | patch the product claim into agreement in code |
+| `plan` | run `node scripts/unit-route.mjs <unit>` → `route: replan`; the planning author re-cuts the artifact (SPEC `## Phases`, an obligation row, an acceptance mapping, a ledger) on the same branch with the user's confirmation, then the lane's **`review` step** precedes `execute-phase` | fold it in code and leave the plan describing the old build |
+| `product` | `/unit-lane <unit>` repairs the half through its `design` step, its `review` step re-judges it | patch the product claim into agreement in code |
 | `environment` / `runtime` | the existing retry/`BLOCKED` paths | translate into a PASS, or an issue |
 
 - `fix-now` with a `plan` or `product` owner keeps its severity but is **not**

package/skills/triage-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: triage-issue
 user-invocable: true
-version: 2.8.0
+version: 2.9.0
 argument-hint: <issue-number> [more issue numbers…] | <audit-id> F<k> [F<j>…] | --prioritize-now <unit> F<k> [F<j>…]
 author: "Gabriel Trabanco <1969593+gtrabanco@users.noreply.github.com>"
 license: MIT
@@ -106,20 +106,21 @@ classification, label ownership, and persisted-output contracts do not change.
 ## Relationship to other skills
 
 ```
-                 ┌─ fix-now ─────────▶ plan-fix ─▶ execute-phase --fix
+                 ┌─ fix-now ─────────▶ /unit-lane --fix <n> ─▶ the lane's implement step
                  ├─ fix-in-unit ─────▶ execute-phase <NN> P<k> (fold into phase)
 triage-issue ────┤                    or fold-findings (ledger row)
-                 │                    or unit-route → plan-feature / plan-fix (replan)
-                 ├─ promote ─────────▶ plan-feature (router → from-issue)
+                 │                    or unit-route <unit> → /unit-lane <unit> (replan)
+                 ├─ promote ─────────▶ /unit-lane --from-issue <n> (feature from issue)
                  ├─ postpone ────────▶ dated comment, leave open
                  └─ wontfix ─────────▶ propose close
 ```
 
 In review-finding mode, `replan-in-unit` runs `node scripts/unit-route.mjs
-<unit>`: its `route: replan` line names the planner (`/plan-feature` for a
-feature, `/plan-fix` for a fix), with new `P<n>` phases appended to the same
-unit and a fresh `/review-plan` before execution. The user manually runs those
-phases; this skill never implements them.
+<unit>`: its `route: replan` line prints the planner command — `/unit-lane
+<unit>` for a feature, `/unit-lane --fix <n>` for a fix — which re-runs the
+lane's `plan` catalog step and appends new `P<n>` phases to the same unit. The
+lane's own `review` step is the gate before execution. The user manually runs
+those phases; this skill never implements them.
 
 ## Done when
 
@@ -136,8 +137,8 @@ phases; this skill never implements them.
 
   Batch:
   → Next: apply every verdict: #<n1> → <command> + #<n2> → <command> + #<n3> → <command>
-    · fix-now → /plan-fix <n>   · promote → /plan-feature <n>
-    · fix-in-unit → /execute-phase <NN> P<k> or /fold-findings — never /plan-fix
+    · fix-now → /unit-lane --fix <n>   · promote → /unit-lane --from-issue <n>
+    · fix-in-unit → /execute-phase <NN> P<k> or /fold-findings — never a new planner skill
     · postpone → dated comment, leave open   · wontfix → propose close
     · same inconsistency across several issues → /product-audit (a recurring pattern,
       not isolated tickets — sweep the product rather than triaging one by one)

package/skills/triage-issue/references/ISSUE_PROCESS.md

@@ -25,12 +25,11 @@
        append a provenance-marked row to the unit's `review-findings.md` (see
        *Ledger-append mechanism* below).
      - *changes the unit's shape* → **incremental replan** on the same unit:
-       name the exact command — `design-feature <slug> "<instruction>"`
-       (product half, upsert) for a product-shape change, `plan-feature
-       <slug>` (re-run, engineering half) for an engineering-shape change, or
-       a user-approved, dated `## Amendments` entry per #66's mechanism (fix
-       units). Never write "replan if needed" — always name which of the
-       three applies and why.
+       name the exact command — `/unit-lane <slug>` (the lane re-reads the
+       SPEC, re-triages, and re-runs its `design`/`plan` catalog steps) — or a
+       user-approved, dated `## Amendments` entry per #66's mechanism (fix
+       units). Never write "replan if needed" — always name which applies and
+       why.
      - *born as an un-amended descope of an unmerged unit* →
        **scope-bleed restore**: the route is restore-the-criterion-in-the-unit
        (no matching `## Amendments` entry); the issue closes as
@@ -38,13 +37,15 @@
    - No candidate matched → fall through to today's four-verdict
      classification below, unchanged.
 4. **Classify** into one of:
-   - **fix-now** — defect or trigger met → route to `plan-fix` then
-     `execute-phase --fix`; add the entry to the fix index. **High severity** →
+   - **fix-now** — defect or trigger met → route to `/unit-lane --fix <n>`
+     (creates the fix unit and triages it; the lane's `implement` step runs
+     it); add the entry to the fix index. **High severity** →
      apply the urgency label per *Urgency label vocabulary* above (`urgent` by
      default; `fix-next` when the call is "queue it next" rather than "maybe
      interrupt now" — see that section's table). Non-high severity → no label.
-   - **promote-to-feature** — really new capability → route to `plan-feature`
-     (the router handles the issue path). Apply the `promoted` disposition
+   - **promote-to-feature** — really new capability → route to
+     `/unit-lane --from-issue <n>` (creates the feature unit from the issue and
+     triages it). Apply the `promoted` disposition
      label per *Disposition label vocabulary* above.
    - **postpone** — valid but trigger unmet → leave open; post a **dated
      re-confirmation** comment stating what you checked and why it stays

package/skills/triage-issue/references/LABELS.md

@@ -2,7 +2,7 @@
 
 This skill is the **sole owner and sole writer** of the workflow's urgency
 labels. No other skill defines, spells, or applies them — `workflow-status`
-only *reads* them (labels-only, presence-only) and `ship-roadmap` only
+only *reads* them (labels-only, presence-only) and `advance` only
 *consumes* what `workflow-status` reports.
 
 | Label | Color | Meaning |
@@ -38,8 +38,8 @@ verdict — never a separate, silent step:
    landing).
 
 A **fix-now + non-high** severity verdict routes normally (fix index +
-`plan-fix`) but applies **no** label — only high severity reaches the urgent
-tier.
+`/unit-lane --fix <n>`) but applies **no** label — only high severity reaches
+the urgent tier.
 
 ## Disposition label vocabulary (owned here)