/unit-lane

name: unit-lane
user-invocable: true
version: 1.1.0
argument-hint: <NN-slug | "<idea>"> [--retriage] | --fix <issue-number> | --from-issue <issue-number>
description: >
  One-shot lane conductor for a delivery unit: triage, implement, evidence, and
  close in a single document. Triggers: "unit-lane", "run the lane",
  "work on this feature/fix", "build this unit".

Unit Lane — Adaptive Conductor

One document, adaptive steps. The lane reads a closed catalog, triages which steps a unit needs, executes them in order, and commits at each gate. Replaces: design-feature, plan-feature, review-spec, review-plan.

Turn contract

Tick every box before ending the turn; an unchecked box means the turn is not done:

✓ Triage ran (bun scripts/unit-route.mjs --triage <slug>) and its block pasted
  verbatim into the unit doc's Evidence section as the authoritative step list
✓ Unit doc exists at docs/features/<NN>-<slug>/SPEC.md (created from template
  if new, with all mandatory sections filled or n/a)
✓ Guard ran (bun scripts/diff-guard.mjs --base <ref>) after each implement step;
  on BREACH: re-triage or record exception, never shrink the diff
✓ Unit doc's Evidence rows updated (command → exit/digest → output → verified-by)
  and Progress log updated (dated entry) before every commit
✓ → Next: block printed as the absolute last output

When to use

• A known unit slug: `unit-lane <NN-slug>`
• A raw idea (no slug yet): `unit-lane "<idea description>"`
• A tracked fix issue (no fix folder yet): `unit-lane --fix <issue-number>`
• A tracked roadmap feature issue (no feature folder yet): `unit-lane --from-issue <issue-number>`
• Force re-triage: `unit-lane <NN-slug> --retriage`

Both `--fix <n>` and `--from-issue <n>` are the exact forms `scripts/unit-route.mjs` prints for a tracked issue with no unit folder (`route: plan-from-issue`) — never invent a different spelling.

Step 0 — Discover the project

Per the agent guide's **Workflow conventions** + **documentation map**, then read `docs/features/_TEMPLATE/SPEC.md` (the unit doc template). If the unit folder exists, read its current `SPEC.md` to avoid overwriting.

Process

1. Resolve or create the unit doc

If the unit folder already exists, read its `SPEC.md` and continue. Otherwise create it from the tree the unit belongs to:

| Invocation | Folder | Template | Index to register | |---|---|---|---| | `<NN-slug>` / `"<idea>"` | `docs/features/<NN>-<slug>/` | `docs/features/_TEMPLATE/SPEC.md` | `docs/features/ROADMAP.md` | | `--fix <issue-number>` | `docs/fix/<issue-number>-<topic>/` | `docs/fix/_TEMPLATE/SPEC.md` | `docs/fix/README.md` | | `--from-issue <issue-number>` | `docs/features/<NN>-<slug>/` | `docs/features/_TEMPLATE/SPEC.md` | `docs/features/ROADMAP.md` (row links `#<issue-number>`) |

For `--fix`/`--from-issue`, read the tracked issue in the forge first and keep its number; the folder name carries it (`fix/<issue-number>-<topic>`). Fill objective, why, user outcome, and non-goals from the invocation (or the issue). Acceptance criteria are induced from user scenarios — **ask-don't-infer**; if the request is too vague, STOP and ask the user with concrete options. See [the unit doc template](references/STEPS.md) for section order.

2. Triage — read the catalog, never re-derive

Run `bun scripts/unit-route.mjs --triage <slug>` (or `<NN>` for numeric). PASTE its stdout block **verbatim** into the unit doc's Evidence section header under a `## Triaged steps` heading. This block is authoritative. The model never re-derives, reorders, or invents steps — it executes only what the catalog says.

3. Execute triaged steps in order

For each step the triage returned, follow its reference file. Execute **one step per turn-commit**:

1. Read the step's reference — for example: [research](references/RESEARCH.md), [design](references/DESIGN.md), [plan](references/PLAN.md), [implement](references/IMPLEMENT.md), [tests](references/TESTS.md), [evidence](references/EVIDENCE.md), [review](references/REVIEW.md), [docs](references/DOCS.md), [release](references/RELEASE.md) — only the ones the triage demands). 2. Perform the step's checklist items. 3. Write/update evidence in the unit doc. 4. Update the Progress log with a dated entry. 5. Commit with a conventional commit message. 6. For implement steps, run the diff guard (step 4 below).

4. Diff-size guard (after each implement step)

Run `bun scripts/diff-guard.mjs --base <last-reviewed-ref> --unit <NN>`. Paste the output verbatim. On **BREACH**: stop, re-triage the unit, or record an exception. **Anti-gaming: NEVER shrink a diff by deleting comments, blank lines, docs or tests.** If the unit cannot fit the budget, record the exception and stop.

5. Update evidence and progress

Before every commit:

• **Evidence rows**: One row per AC satisfied — `| AC | command | exit/digest |

output (≤2 lines) | verified-by |`

• **Progress log**: `YYYY-MM-DD HH:MM — <what was done> → <commit sha> — next:

<what is next>`

6. Close the unit

When all triaged steps are done, run the review pack axis summary, update the unit doc's status, and print the closing block.

Guardrails

**Allowed:**

• Only the triaged steps listed by the catalog
• Changes scoped to the acceptance criteria
• Documentation updates in docs/ and template/
• Conventional commit messages per the project's Workflow conventions

**Forbidden:**

• Never expand scope beyond what Non-goals define — findings discovered during

implementation never widen the unit

• Never invent an acceptance criterion — ask the user with concrete options
• Never skip a triaged step silently — every step the catalog demands must run
• Findings never authorize scope growth — record them, route to their owner
• Never commit red (test failure) — fix or replan, never silence tests
• Never alter a triaged step's order

Relationship to other skills

`unit-lane` absorbed the retired fixed-pipeline skills (design-