@event4u/agent-config 9.8.0 → 9.10.0

package/dist/agent-src/skills/react-shadcn-ui/reference/registry.md

@@ -1,36 +1,36 @@
 # shadcn registry & namespace reference
 
 > Lazy-loaded by `react-shadcn-ui` ONLY on the registry/MCP path (custom or
-> namespaced registries, or theme-alignment). Not in the always-on skill body —
-> zero token cost on the vanilla `shadcn add` path.
+> namespaced registries, or theme-alignment work). Not part of the always-on
+> skill body — zero token cost on the vanilla `shadcn add` path.
 
 ## `registry-item.json` — the self-describing component unit
 
-Each item is a JSON doc the agent reads before scaffolding — never guesses
-paths, deps, or tokens.
+A registry serves each item as a JSON document the agent reads before
+scaffolding, so it never guesses paths, deps, or tokens.
 
 - `name` — item id.
 - `type` — one of: `registry:ui`, `registry:component`, `registry:block`,
   `registry:hook`, `registry:lib`, `registry:theme`, `registry:style`,
   `registry:page`, `registry:file`, `registry:base`, `registry:item`.
-- `dependencies` / `devDependencies` — npm packages.
-- `registryDependencies` — other items to pull first (the dependency graph):
-  built-in (`"button"`), namespaced (`"@acme/input"`), GitHub
+- `dependencies` / `devDependencies` — npm packages to install.
+- `registryDependencies` — other registry items to pull first (the dependency
+  graph). Forms: built-in (`"button"`), namespaced (`"@acme/input"`), GitHub
   (`"acme/ui/button#v1.2.0"`), URL, or local path.
-- `files[]` — each `{ path, type, target }`; `target` uses the project alias
-  placeholders (`~`, `@ui/`, `@lib/`, `@hooks/`) from `components.json`.
-- `cssVars` — tokens scoped by mode: `theme` (font/radius), `light`, `dark`,
-  OKLCH. **Align to the project's tokens; do not inject the default neutral
-  theme** (anti-slop C1/C5/T7).
-- `css` — raw `@layer` / `@utility` / `@keyframes` / `@plugin`.
+- `files[]` — each `{ path, type, target }`; `target` uses the project's alias
+  placeholders (`~`, `@ui/`, `@lib/`, `@hooks/`) resolved from `components.json`.
+- `cssVars` — design tokens scoped by mode: `theme` (font/radius), `light`,
+  `dark`. Values are OKLCH. **Align these to the project's existing tokens, do
+  not inject the default neutral theme** (anti-slop C1/C5/T7).
+- `css` — raw `@layer` / `@utility` / `@keyframes` / `@plugin` directives.
 
-Scaffold order: read item → install npm `dependencies` → resolve
-`registryDependencies` (recurse) → write `files[]` to alias targets → merge
-`cssVars` into the project token layer (reconcile, don't overwrite).
+Scaffold order: read the item → install npm `dependencies` → resolve
+`registryDependencies` (recurse) → write `files[]` to the alias targets →
+merge `cssVars` into the project's token layer (reconcile, do not overwrite).
 
 ## Namespaced registries
 
-`components.json` maps a namespace → URL template under `registries`:
+`components.json` maps a namespace to a URL template under `registries`:
 
 ```json
 {
@@ -44,16 +44,18 @@ Scaffold order: read item → install npm `dependencies` → resolve
 }
 ```
 
-- Resolution: `@ns/name` → look up `@ns` → substitute `{name}` (+ optional
-  `{style}`). Reference regex: `^(@[a-zA-Z0-9](?:[a-zA-Z0-9-_]*[a-zA-Z0-9])?)\/(.+)$`.
-- Auth registries: per-registry `headers` with `${ENV_VAR}` — never inline a
-  token; read from the environment.
-- Namespace space is **decentralized** — no central collision authority; the
-  `components.json` map is the project's source of truth.
+- Resolution: `@ns/name` → look up `@ns` → substitute `{name}` (and optional
+  `{style}`) into the URL template. The reference resolution regex is
+  `^(@[a-zA-Z0-9](?:[a-zA-Z0-9-_]*[a-zA-Z0-9])?)\/(.+)$`.
+- Auth registries: per-registry `headers` with `${ENV_VAR}` interpolation —
+  never inline a token; read it from the environment.
+- The namespace space is **decentralized** — no central authority resolves
+  collisions; the `components.json` map is the project's source of truth.
 
 ## CLI surface (the agent drives these)
 
-`init` · `add [item|@ns/item]` · `search @ns -q <q>` · `view @ns/item` (inspect
-JSON before install) · `docs [item] --json` · `diff` (drift vs updated
-registry) · `info --json` (project context — see the SKILL handshake) · `build`
-(publish). Inspect with `view` before `add` — evidence before action.
+`init` · `add [item|@ns/item]` · `search @ns -q <q>` · `view @ns/item`
+(inspect JSON before install) · `docs [item] --json` · `diff` (drift vs the
+updated registry) · `info --json` (project context — see the SKILL handshake)
+· `build` (publish a registry). Inspect with `view` before `add` — evidence
+before action.

package/dist/agent-src/skills/readme-writing-package/SKILL.md

@@ -262,8 +262,8 @@ npx <package> init --tools=windsurf         # Windsurf
 Pair the catalog with a separate "Global install" subsection (same flags
 plus `--global`) and an "Other commands" subsection. Reference example:
 [`README.md § Pick specific AIs`](../../../README.md#pick-specific-ais) in
-this repository. Inspiration:
-[`an external reference suite § Installation`](https://github.com/an external reference suite#installation).
+this repository — or any well-structured external skill README that
+lists per-target install commands in a flat catalog.
 
 Use the catalog when the package's primary install action varies by
 platform; use a matrix table (Tool / Rules / Skills / Commands) for

package/dist/agent-src/skills/reasoning-orchestrator/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: reasoning-orchestrator
 description: "Use for multi-step / ambiguous / end-to-end work — refactor a whole module, drive a vague ticket to a verified result, plan+build+verify a migration; coordinates the reasoning chain across skills."
-source: package
 domain: engineering
 status: active
 model_tier: medium
@@ -35,27 +34,28 @@ coordinates); on a standard host run the full chain.
 ## When to use
 
 Scope (eval-calibrated, L6): engage only for **interdependent multi-step** work
-— steps whose ordering/handoffs matter (schema → API → job → UI; staged
-migration; cross-cutting refactor). **Not** for single-turn analysis (explain /
-name / yes-no / pick-X-or-Y / one-shot edit): there the ordered chain is a no-op,
-only adds tokens.
-
-- Interdependent **multi-step** task on a standard host. Analyze the dependency
-  structure (what blocks what) before acting.
-- Work where a missed/out-of-order link (grounding, verification) compounds
+— multiple steps whose ordering and handoffs matter (schema → API → job → UI; a
+staged migration; a cross-cutting refactor). **Not** for single-turn analysis
+(explain / name / yes-no / pick-X-or-Y / one-shot edit): there the ordered chain
+is a no-op and only adds tokens.
+
+- An interdependent **multi-step** task on a standard host. Analyze the
+  dependency structure (what blocks what) before acting.
+- Work where a missed or out-of-order link (grounding, verification) compounds
   downstream.
 
 Do NOT use for trivial / linear / fully-specified tasks **or single-turn
-analysis** (the gate filters these); don't duplicate the work of the skills it
-coordinates.
-
-> **Why scoped (L6, 2026-06-22).** Controlled distributed-vs-orchestrated eval
-> (N=16, independent rater): ordered chain gains **+19.2%** on multi-step,
-> **−1.1%** (no-op) on single-turn. Standard host classifies multi-step vs
-> single-turn at gate time 16/16; misclassification degrades gracefully (wrong
-> arm still functional). Revert trigger = re-run `tests/reasoning-layer-eval`
-> (eval is the telemetry — no-runtime package); RDP flip conditions judged
-> per-mechanism, never univariate aggregate. Evidence:
+analysis** (the gate filters these), and do not let it duplicate the work of the
+skills it coordinates.
+
+> **Why scoped (L6, 2026-06-22).** A controlled distributed-vs-orchestrated eval
+> (N=16, independent rater) found the ordered chain gains **+19.2%** on
+> multi-step work but **−1.1%** (a no-op) on single-turn reasoning. The standard
+> host classifies multi-step vs single-turn at gate time with 16/16 accuracy, and
+> a misclassification degrades gracefully (wrong arm is still functional). The
+> revert trigger is a re-run of `tests/reasoning-layer-eval` (the eval is the
+> telemetry — this is a no-runtime package); RDP flip conditions are judged
+> per-mechanism, never on a univariate aggregate. Evidence:
 > `tests/reasoning-layer-eval/RESULTS-L6-largeN-2026-06-22.md`.
 
 ## When the agent should load this
@@ -81,8 +81,8 @@ Each link **delegates** to the artifact that owns it (no duplication):
 4. **gather** — resolve the load-bearing unknown first
    ([`complexity-first-planning`](../complexity-first-planning/SKILL.md)); dispatch
    independent subtasks async ([`subagent-orchestration` § RDP](../subagent-orchestration/SKILL.md)),
-   settings-gated per [`auto-orchestration-activation`](../../contexts/execution/auto-orchestration-activation.md)
-   (`subagents.enabled`/`auto` + host manifest).
+   auto-triggered by the [`delegation-policy`](../../rules/delegation-policy.md) rule
+   (gates on `subagents.enabled`/`auto` + host manifest).
 5. **audit** — check progress against real tool results
    ([`verify-before-complete`](../../rules/verify-before-complete.md)).
 6. **verify** — fresh-context verifier on the structural-complexity gate
@@ -99,11 +99,11 @@ not exclusivity.
 ## Output
 
 The task's actual deliverable, produced **through the chain** (analysis before
-action — grounding + load-bearing-unknown resolution precede any edit):
+action — grounding and the load-bearing-unknown resolution precede any edit):
 
-1. **Outcome first** — response leads with the result + its evidence.
-2. **Reasoning stays in notes** — hypotheses / predictions / decisions in the
-   notes file, never dumped into the response.
+1. **Outcome first** — the response leads with the result and its evidence.
+2. **Reasoning stays in notes** — hypotheses / predictions / decisions live in
+   the notes file, never dumped into the response.
 3. **Chain honoured in order** — ground → intent → notes → resolve-hardest-first
    → audit → verify ran as ordered links (with handoffs), not a buffet.
 4. **Verified before "done"** — no completion claim without the verifier link's

package/dist/agent-src/skills/recursive-verification/SKILL.md

@@ -41,6 +41,13 @@ Land a verified result by running a depth-bounded
 the only compute knob, every level budgeted, and the loop default-off
 until a benchmark gate authorises it per host.
 
+> **Disposition (2026-07-28, honest null — TERMINAL).** The recursive-
+> verification benchmark resolved as a published null (no measured lift over
+> single-pass verification; see `docs/benchmark.md`). `verification.recursive`
+> stays default-off bound to that null; scheduled for removal at the next
+> major unless external evidence appears first. This skill is NOT sold as a
+> quality-lift mechanism.
+
 ## The Iron Law
 
 ```

package/dist/agent-src/skills/refine-prompt/SKILL.md

@@ -183,7 +183,7 @@ Before emitting the envelope, run these three scans. Each is a fast pass; failur
 2. **Placeholder / TODO scan** — the rendered envelope contains no `<placeholder>`, `TODO`, `FIXME`, `tbd`, `???`, `XXX` strings. The literal angle-bracket placeholders in the template (`<one sentence …>`, `<bullet>`) must be replaced with concrete text before emission.
 3. **Type / shape consistency** — every named file, module, route, or command in the AC matches the project's existing conventions. If the prompt names `auth.service.ts` but the codebase uses `AuthService.php`, surface the mismatch in *Assumptions* rather than adopting the prompt's spelling.
 
-Source: adapted from an external reference `writing-plans/SKILL.md` § Self-Review (v5.1.0).
+Source: adapted from an external reference.
 
 ## Band-action mapping
 

package/dist/agent-src/skills/refine-ticket/SKILL.md

@@ -18,6 +18,9 @@ workspaces:
   - product
 packs:
   - product-basic
+requires_skills:
+  - validate-feature-fit
+  - threat-modeling
 trust:
   level: professional
 install:
@@ -182,9 +185,9 @@ naming (e.g. `feat/` vs `fix/` vs `refactor/` prefix), and
 risks instead of inventing terms.
 
 The match lists and `require_count` thresholds are owned by
-`detection-map.yml` — edit the map, not this skill. Tests:
-[`tests/scripts/refine_ticket_detect.test.ts`](../../../tests/scripts/refine_ticket_detect.test.ts)
-(DE + EN fixtures, repo-aware + graceful-degrade coverage).
+`detection-map.yml` — edit the map, not this skill (DE + EN fixtures,
+repo-aware + graceful-degrade coverage are regression-locked in this
+package's own test suite).
 
 ### 3. Orchestrate
 
@@ -217,6 +220,16 @@ reviews the ticket through its lens and produces one paragraph:
 Optional: `--personas=+qa` adds the QA persona (edge cases, regression
 risk, test matrix).
 
+Optional: `--user-type=<id>` loads one user-type from `user-types/<id>.md`
+and adds an end-user simulation lens to the persona stack (e.g.
+`--user-type=galabau-field-crew`). User-types compose orthogonally with
+personas — persona = methodology / role lens; user-type = end-user / field
+lens. v1 is CLI-only (no skill-level default; no frontmatter list). The
+user-type voice renders as one paragraph in *Persona voices* labelled
+`**User: <label>**`, citing Daily Workflow, Vocabulary, Operational
+Constraints, and Ticket Red Flags from the loaded user-type. Contract:
+[`docs/contracts/user-type-schema.md`](../../../docs/contracts/user-type-schema.md).
+
 ### 5. Synthesize + close-prompt
 
 Produce the three-section output (template below). After rendering,
@@ -276,7 +289,7 @@ Run these three scans on the rendered output before the close-prompt. Each is a
 
 Self-review is mechanical (gaps, leftovers, naming drift); persona voices and orchestration outputs handle reasoning critique. Both run; neither replaces the other.
 
-Source: adapted from an external reference `writing-plans/SKILL.md` § Self-Review (v5.1.0).
+Source: adapted from an external reference.
 
 ## Close-prompt (mandatory final step)
 
@@ -312,7 +325,11 @@ the session, re-probe on project change.
 
 ## Rubric pass (optional, surfacing-only)
 
-After refinement, run [`judge-artifact-completeness`](../judge-artifact-completeness/SKILL.md) with rubric `ticket-quality-score` to verify DoR readiness — AC, test plan, risk, estimate. Invoke when user asks for DoR check — not automatically.
+After refinement, run
+[`judge-artifact-completeness`](../judge-artifact-completeness/SKILL.md)
+with rubric `ticket-quality-score` to verify DoR readiness — acceptance
+criteria, test plan, risk, and estimate. Invoke when the user asks for a
+DoR check — not automatically on every refinement.
 
 ## Output format
 
@@ -336,6 +353,7 @@ After refinement, run [`judge-artifact-completeness`](../judge-artifact-complete
 - Do NOT duplicate logic from `validate-feature-fit` or `threat-modeling` — orchestrate by reference, cite findings, don't re-derive them.
 - Do NOT skip the close-prompt, even when the ticket looks fine and the user seems eager to move on — the prompt is the contract.
 - Do NOT emit persona voices outside the active set; if the user passed `--personas=+qa`, add QA, otherwise do not.
+- Do NOT emit a user-type voice unless `--user-type=<id>` was passed; loading a user-type proactively (e.g. "this ticket smells like field-crew") is forbidden — the axis is CLI-only in v1.
 
 ## See also
 

package/dist/agent-src/skills/repomix-packer/SKILL.md

@@ -136,6 +136,6 @@ Cite the snapshot path so the consumer skill can read it.
 ## Provenance
 
 - Upstream tool: https://github.com/yamadashy/repomix (MIT).
-- Adopted from: an external reference (MIT, © 2025 an external reference) — wrapper-style adoption, no upstream code vendored.
+- Adopted from: an external reference (internal provenance, redacted) — wrapper-style adoption, no upstream code vendored.
 - Provenance registry: `agents/settings/contexts/skills-provenance.yml` (entry: `repomix`).
 - Iron-Law floor: `non-destructive-by-default`, `missing-tool-handling`, `tool-safety`.

package/dist/agent-src/skills/requesting-code-review/SKILL.md

@@ -96,7 +96,7 @@ reviewer will ask — and that round trip is preventable.
 | **How do I verify it?** | Test plan: commands to run, URLs to hit, expected behavior |
 | **What should I look at first?** | Highlights: "pay attention to X because Y" or "skip Z, it is generated" |
 
-See [`create-pr-description`](../../commands/create-pr-description.md)
+See [`create-pr-description`](../../commands/create-pr/description-only.md)
 for the full structured template, and
 [`conventional-commits-writing`](../conventional-commits-writing/SKILL.md)
 for the title format.
@@ -188,7 +188,7 @@ When handing the review request to the reviewer (PR body, Slack, email):
 * Self-review walkthrough → [`review-changes`](../../commands/review/changes.md)
 * Bringing a stacked branch up to date first →
   [`prepare-for-review`](../../commands/prepare-for-review.md)
-* Writing the PR description → [`create-pr-description`](../../commands/create-pr-description.md)
+* Writing the PR description → [`create-pr-description`](../../commands/create-pr/description-only.md)
 * Actually opening the PR → [`create-pr`](../../commands/create-pr.md)
 * Writing the commits themselves → [`commit`](../../commands/commit.md),
   [`conventional-commits-writing`](../conventional-commits-writing/SKILL.md)

package/dist/agent-src/skills/roadmap-management/SKILL.md

@@ -45,19 +45,23 @@ without it.
 
 ### Archival — preferred sweep, untracked-safe manual fallback
 
-Robust path: `archive_completed_roadmaps --all` — detects complete
-(`count_open == 0`, `count_deferred == 0`), moves to `agents/roadmaps/archive/`
-(`git mv` tracked, plain `mv` untracked / no-commit), rewrites inbound refs,
-regens dashboard. PR-independent.
+The robust path is the `archive_completed_roadmaps --all` sweep: it detects a
+completed roadmap (`count_open == 0`, `count_deferred == 0`), moves it to
+`agents/roadmaps/archive/` — `git mv` in a tracked repo, a plain `mv` in a
+pre-first-commit / untracked one — rewrites inbound refs, and regenerates the
+dashboard. It is **PR-independent**: it does not need `/create-pr` to have run.
 
-**Manual fallback (script not vendored)** — same response, never leave a
-100 %-complete roadmap active because `git mv` failed:
+**Manual fallback — script-less consumer** (the sweep is not vendored). Do it by
+hand, in the same response, and never leave a 100 %-complete roadmap in the
+active tree because `git mv` failed:
 
 1. `mkdir -p agents/roadmaps/archive`.
-2. `git mv agents/roadmaps/<x>.md agents/roadmaps/archive/<x>.md` (tracked); plain
-   `mv` if untracked / no commits.
-3. Rewrite inbound `agents/roadmaps/<x>.md` → `agents/roadmaps/archive/<x>.md`
-   across the tree (working tree, not just index, when untracked).
+2. Move the file — `git mv agents/roadmaps/<x>.md agents/roadmaps/archive/<x>.md`
+   in a tracked repo; a plain `mv` if the file is untracked or the repo has no
+   commits (`git mv` errors there).
+3. Rewrite inbound full-path references `agents/roadmaps/<x>.md` →
+   `agents/roadmaps/archive/<x>.md` across the tree — on the working tree, not
+   just the git index, when untracked.
 4. Regenerate `agents/roadmaps-progress.md`.
 
 ## Procedure: Manage a roadmap
@@ -154,8 +158,8 @@ Every roadmap follows this structure:
 Every roadmap implicitly includes the project's quality pipeline
 (static analysis, autofixes, tests). Whether the agent runs it locally
 at all is gated by `quality.local_auto_run`: `false` or missing (the
-default) → agent never runs the pipeline locally; user runs it
-manually, remote CI on the PR is the authoritative gate (run-end
+default) → the agent never runs the pipeline locally; the user runs it
+manually and remote CI on the PR is the authoritative gate (run-end
 report: *"quality gates delegated to remote CI"*; new-gate carve-out
 steps still run once). When `local_auto_run: true`, **when** the
 pipeline runs during `/roadmap:process-step|phase|full` is controlled
@@ -266,16 +270,16 @@ After the last step of a roadmap is done, check completion status:
 
 3. **Decision rule — `count_open == 0` means the roadmap has no active
    work left. `[x]`, `[-]` are final states. `[~]` deferred items
-   block silent closure — they carry plans user has not consented to drop
-   (enforced by [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)
+   block silent closure — they carry plans the user has not consented
+   to drop (enforced by [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)
    Iron Law 3).**
 
    | count_x | count_open | count_deferred | count_cancelled | Action |
    |---|---|---|---|---|
    | ≥ 1 | 0 | 0 | 0 | **Auto-archive** (silent) — pure completion |
    | ≥ 1 | 0 | 0 | ≥ 1 | **Auto-archive** (silent) — done with explicit drops |
-   | ≥ 1 | 0 | ≥ 1 | ≥ 0 | **STOP — Iron Law 3 flow.** Surface deferred items, present follow-up options, wait. Step 4b. |
-   | 0 | 0 | ≥ 1 | ≥ 0 | **STOP — Iron Law 3 flow.** Scope-drop or deferred-to-later? Same options as 4b. |
+   | ≥ 1 | 0 | ≥ 1 | ≥ 0 | **STOP — Iron Law 3 flow.** Surface deferred items, present follow-up options, wait. See step 4b. |
+   | 0 | 0 | ≥ 1 | ≥ 0 | **STOP — Iron Law 3 flow.** Was this a scope-drop or deferred-to-later? Same options as 4b. |
    | 0 | 0 | 0 | ≥ 1 | **Auto-skip** (silent) — no work, all cancelled |
    | ≥ 0 | ≥ 1 | ≥ 0 | ≥ 0 | **Ask the user** — open work remains (step 4a) |
 
@@ -285,10 +289,10 @@ After the last step of a roadmap is done, check completion status:
    - Skip:    `⏭️  Roadmap skipped → agents/roadmaps/skipped/{filename}`
    - Later:   `🕒  Roadmap parked for later → agents/roadmaps/later/{filename}`
 
-   `[-]` cancelled items remain searchable in archived file — they were
-   explicit drops. `[~]` deferred items, by contrast, may not silently
-   follow file into archive: they represent work user planned and would
-   lose track of. Step 4b is the gate.
+   `[-]` cancelled items remain searchable inside the archived file —
+   they were explicit drops. `[~]` deferred items, by contrast, may
+   not silently follow the file into archive: they represent work the
+   user planned and would lose track of. Step 4b is the gate.
 
 4a. **Open items remain (`count_open ≥ 1`)** → **Ask the user.** Show what's incomplete:
 
@@ -307,22 +311,25 @@ After the last step of a roadmap is done, check completion status:
    > 5. Later — park in later/ (open work is blocked on an external trigger / decision but will resume)
    ```
 
-   Option 4 only appropriate when `count_x == 0` or completed items were
-   trivial (e.g. prerequisites). If user picks 4 despite meaningful work
-   done, confirm once — archive usually right. Picking option 3 does
-   NOT archive immediately — converts open → deferred, re-enters the
+   Option 4 is only appropriate when `count_x == 0` or the completed items were
+   trivial (e.g. prerequisites only). If the user picks 4 despite meaningful work
+   being done, confirm once — archive is usually the right choice. Picking option 3
+   does NOT archive immediately — it converts open → deferred and re-enters the
    `count_deferred > 0` branch, which runs step 4b.
 
-   **Option 5 (Later) — right when open items are real but cannot proceed
-   now** (gated on an external trigger or a decision). Set frontmatter
-   `status: later`, ensure a `Blocked until` / `Trigger` resume line, `git mv`
-   to `agents/roadmaps/later/`, migrate inbound refs to the new path, regen.
-   Open `[ ]` items stay open (not cancelled/deferred) — parked whole, ready to
-   resume when the trigger fires. **Roadmaps with open tasks deferred for later
-   are always moved to `later/`**, never left to rot in the active tree.
+   **Option 5 (Later) is the right choice when the open items are real but
+   cannot proceed now** — gated on an external trigger or a decision. Set the
+   roadmap's frontmatter `status: later`, ensure it carries a `Blocked until` /
+   `Trigger` resume line, `git mv` it to `agents/roadmaps/later/`, migrate any
+   inbound references to the new path, and regenerate the dashboard. The open
+   `[ ]` items stay open (they are not cancelled or deferred) — the roadmap is
+   parked whole, ready to resume when the trigger fires. **Roadmaps with open
+   tasks deferred for later are always moved to `later/`**, never left to rot in
+   the active tree.
 
 4b. **Deferred items present (`count_deferred ≥ 1`, `count_open == 0`)** — Iron Law 3 flow.
-   Archive **blocked** until user resolves deferrals. Surface plan and ask:
+   The archive is **blocked** until the user resolves the deferrals. Surface
+   the plan and ask:
 
    ```
    📋 Roadmap closure check — deferred items must resolve before archive:
@@ -336,56 +343,57 @@ After the last step of a roadmap is done, check completion status:
 
    > 1. Spawn follow-up roadmap as DRAFT
    >    → agents/roadmaps/road-to-{auto-slug}.md, status: draft,
-   >      parent_roadmap: {this-slug}. Hidden from dashboard until you
-   >      flip status to "ready".
+   >      parent_roadmap: {this-slug}. Hidden from the dashboard until
+   >      you flip status to "ready".
    > 2. Spawn follow-up roadmap as READY (with blocked-until note)
    >    → status: ready (default), parent_roadmap: {this-slug}, plus
-   >      `> Blocked until <condition>` line in body. Visible in
-   >      dashboard; execution waits on condition.
+   >      a `> Blocked until <condition>` line in the body. Visible
+   >      in the dashboard; execution waits on the condition.
    > 3. Keep deferred items in this archive — confirm "no follow-up"
-   >    intentional drop. Items stay searchable in archive/.
+   >    is an intentional drop. Items stay searchable in archive/.
    > 4. Restore selected items to [ ] — finish them here before archive.
    > 5. Convert selected items to [-] cancelled — drop with rationale.
    ```
 
-   Picks 1 or 2 → see "Spawn follow-up from deferred items" below.
-   Picks 3, 4, or 5 → apply the change in this roadmap; re-evaluate
-   the decision table; archive when gate clears.
+   Picks 1 or 2 → see "Spawn follow-up from deferred items" procedure below.
+   Picks 3, 4, or 5 → apply the change in this roadmap; re-evaluate the
+   decision table; archive when the gate clears.
 
 ### Spawn follow-up from deferred items (procedure)
 
-When user picks option 1 or 2 in step 4b:
+When the user picks option 1 or 2 in step 4b:
 
-1. **Derive slug.** Default `<parent-slug>-followup` (e.g. `road-to-x.md`
-   → `road-to-x-followup.md`). User-supplied slug in picker → use that.
-   Avoid collisions with `agents/roadmaps/` (active + `archive/` + `skipped/`).
+1. **Derive the slug.** Default `<parent-slug>-followup` (e.g.
+   `road-to-x.md` → `road-to-x-followup.md`). If a user-supplied
+   slug was given in the picker, use that. Avoid collisions with
+   `agents/roadmaps/` (active + `archive/` + `skipped/`).
 
-2. **Write new file** at `agents/roadmaps/<slug>.md`:
+2. **Write the new file** at `agents/roadmaps/<slug>.md`:
 
    ```markdown
    ---
-   complexity: lightweight            # bump if parent was structural
+   complexity: lightweight            # bump if the parent was structural
    status: draft                      # option 1; omit for option 2 (= ready)
    parent_roadmap: <parent-slug>      # back-link to source
    ---
 
    # Roadmap: Follow-up to <parent-title>
 
-   > <One sentence stating carried-over outcome.>
+   > <One sentence stating the carried-over outcome.>
 
    ## Context
 
    This roadmap collects items deferred from
    [`agents/roadmaps/archive/<parent-slug>.md`](archive/<parent-slug>.md).
-   See parent's archive entry for original rationale.
+   See the parent's archive entry for the original rationale.
 
    ## Prerequisites
 
-   - [ ] Read `AGENTS.md` and parent archive entry.
+   - [ ] Read `AGENTS.md` and the parent archive entry.
    {parent prerequisites still relevant, copied verbatim}
 
    <!-- Option 2 only — body note, NOT a frontmatter key: -->
-   > Blocked until <condition>. Execution starts when condition clears.
+   > Blocked until <condition>. Execution starts when the condition clears.
 
    ## Phase 1: <name carried from parent>
 
@@ -394,25 +402,26 @@ When user picks option 1 or 2 in step 4b:
 
    ## Acceptance Criteria
 
-   - [ ] {restate or adjust per deferred scope}
+   - [ ] {restate or adjust per the deferred scope}
    - [ ] All quality gates pass — see `quality-tools`.
    ```
 
-3. **In parent roadmap** (still in working tree), append a line at
-   bottom (above any final `---`):
+3. **In the parent roadmap** (still in the working tree), append a
+   line at the bottom (above any final `---`):
 
    ```
    <!-- Deferred items migrated to agents/roadmaps/<followup-slug>.md on YYYY-MM-DD -->
    ```
 
-   Do **not** delete `[~]` lines — keep visible in archived parent so
-   trail stays grep-able. Follow-up carries forward executable copy.
+   Do **not** delete the `[~]` lines — keep them visible in the
+   archived parent so the trail stays grep-able. The follow-up
+   carries forward the executable copy.
 
-4. **Regenerate dashboard.** Follow-up appears (draft hidden, ready
-   visible) and parent — once moved — drops off.
+4. **Regenerate the dashboard.** The follow-up appears (draft hidden,
+   ready visible) and the parent — once moved — drops off.
 
-5. **Archive parent** (`git mv` → `archive/`) and regen one more time
-   per [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)
+5. **Archive the parent** (`git mv` → `archive/`) and regen one
+   more time per [`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md)
    Iron Laws 1 + 3.
 
 5. **Move the file** with `git mv` so history is preserved:
@@ -472,18 +481,23 @@ The dashboard is a **read-only snapshot**. Do not edit it by hand — regenerate
 
 ### Blockers on the dashboard
 
-Overview table's `Blocker` column counts each roadmap's open
-`## Blockers` entries (or legacy `> Blocked until` note), links to
-per-roadmap breakdown, which lists every open blocker with owner,
-blocked scope, full instructions. Authoring shape:
+The overview table's `Blocker` column counts each roadmap's open
+`## Blockers` entries (or the legacy `> Blocked until` note) and links
+to the per-roadmap breakdown, which lists every open blocker with
+owner, blocked scope, and full instructions. Authoring shape:
 [`templates/roadmaps.md` rule 20](../../agent-src/templates/roadmaps.md);
 authoring guidance: [`roadmap-writing § 5b`](../roadmap-writing/SKILL.md).
-Clearing a blocker flips `Status: resolved`, regenerates dashboard in
-same reply — same cadence as a checkbox flip.
+Clearing a blocker flips its `Status: resolved` and regenerates the
+dashboard in the same reply, same cadence as a checkbox flip.
 
 ## Rubric pass (optional, surfacing-only)
 
-After producing roadmap, run [`judge-artifact-completeness`](../judge-artifact-completeness/SKILL.md) with rubric `roadmap-score` to surface missing dimensions (risk, tests, migration, maintainability). Score is a recommendation; never blocks shipping. Invoke only when user wants completeness check — not by default.
+After producing a roadmap, run
+[`judge-artifact-completeness`](../judge-artifact-completeness/SKILL.md)
+with rubric `roadmap-score` to surface missing dimensions (risk, tests per
+step, migration, maintainability). The score is a recommendation; it never
+blocks the roadmap from shipping. Invoke only when the user wants a
+completeness check — not on every roadmap creation by default.
 
 ## Output format