devrites 3.0.4 → 3.0.6

package/pack/.claude/skills/rite-customize/SKILL.md

@@ -6,7 +6,7 @@ user-invocable: true
 disable-model-invocation: true
 ---
 
-# /rite-customize — guided project customization
+# /rite-customize: guided project customization
 
 Create, list, validate, or scaffold one project-local DevRites customization without forking the pack.
 
@@ -63,5 +63,5 @@ Record: <path(s)>
 ## Gotchas
 
 - **Do not fork by accident.** If a reviewer override is enough, do not create a copied reviewer agent.
-- **Do not weaken gates.** “Ignore”, “waive”, “lower severity”, or “skip type-GO” means rewrite the customization or refuse it.
+- **Do not weaken gates.** "Ignore", "waive", "lower severity", or "skip type-GO" means rewrite the customization or refuse it.
 - **Do not invent an extension surface.** If the user wants behavior outside DevRites' extension contract, say what the contract supports and stop.

package/pack/.claude/skills/rite-define/SKILL.md

@@ -5,7 +5,7 @@ argument-hint: "[feature-slug]"
 user-invocable: true
 ---
 
-# /rite-define — plan from the spec
+# /rite-define: plan from the spec
 
 Read the active feature's `spec.md` and turn it into a buildable workspace: feature
 architecture, approach, a dependency-ordered set of **vertical slices**, traceability, and
@@ -15,10 +15,10 @@ spec, architecture, plan, tasks, and traceability keeps each file small and phas
 
 ## Rules consulted (read on demand from `.claude/skills/devrites-lib/reference/standards/`)
 Pull these via `Read` when shaping the plan:
-- `development-workflow.md` — small batches, trunk-always-green, definition of done.
-- `principles.md` — the project invariants (`.devrites/principles.md`) the chosen approach must conform to.
-- `documentation.md` — record plan-time decisions and rationale.
-- `../workspace-artifact-schema.md` — artifact purposes, budgets, IDs, and read triggers.
+- `development-workflow.md`: small batches, trunk-always-green, definition of done.
+- `principles.md`: the project invariants (`.devrites/principles.md`) the chosen approach must conform to.
+- `documentation.md`: record plan-time decisions and rationale.
+- `../workspace-artifact-schema.md`: artifact purposes, budgets, IDs, and read triggers.
 
 ## Operating rules
 - **Requires a readied spec.** Read the active workspace first; if `.devrites/ACTIVE` is empty,
@@ -31,8 +31,8 @@ Pull these via `Read` when shaping the plan:
   be deepened right there with a technique from
   [`elicitation.md`](../devrites-lib/reference/standards/elicitation.md) (Tournament for two viable
   designs, Delphi for the estimate) before it hardens into slices.
-- **Slice count is derived, never dictated.** The number of slices falls out of the work
-  — one per independently-shippable increment, sized by `slicing.md`, every acceptance
+- **Slice count is derived, never dictated.** The number of slices falls out of the work.
+  One per independently-shippable increment, sized by `slicing.md`, every acceptance
   criterion mapped to ≥1 slice. A user-named count is a hint at most: slice logically and,
   if your honest count differs, present it and why. Never pad or compress to hit a figure.
   (`.devrites/AFK` `max_slices` is a separate AFK iteration budget, not the decomposition.)
@@ -42,8 +42,8 @@ Pull these via `Read` when shaping the plan:
   integration branch plus a final verify slice.
 
 ## Workflow
-0. **Read `.claude/skills/devrites-lib/reference/standards/core.md`** — the always-on operating rules and anti-rationalizations.
-   Then **run the shared orientation preamble** — it confirms the active feature and which
+0. **Read `.claude/skills/devrites-lib/reference/standards/core.md`:** the always-on operating rules and anti-rationalizations.
+   Then **run the shared orientation preamble**. It confirms the active feature and which
    artifacts exist (it prints `state.md`, the artifacts present, the run mode, and the
    open-question tally):
    ```bash
@@ -53,12 +53,12 @@ Pull these via `Read` when shaping the plan:
    ```
    If there is no active workspace, no `spec.md`, `spec-skeleton` blocks, or its readiness gate hasn't passed →
    **STOP** and tell the user to run `/rite-spec <feature>` first.
-1. **Read the spec** — `spec.md` (objective, requirements, acceptance, **placement**,
+1. **Read the spec:** `spec.md` (objective, requirements, acceptance, **placement**,
    design references, gaps/decisions), plus `references.md`, `decisions.md`,
    `assumptions.md`, **`strategy.md` if present** (the scope mode, deferred / out-of-scope
-   register, and pre-mortem risks from `/rite-temper` — cut slices to mitigate the top risks
+   register, and pre-mortem risks from `/rite-temper`: cut slices to mitigate the top risks
    and respect the IN/OUT line; map coverage against the **hardened** spec), and
-   **`design-brief.md` if the feature touches UI** (the UX/UI contract `/rite-spec` shaped —
+   **`design-brief.md` if the feature touches UI** (the UX/UI contract `/rite-spec` shaped:
    its key states, interaction model, and proof targets drive how UI slices are cut). If a blocking
    `[NEEDS CLARIFICATION]` remains, stop → `/rite-spec`.
 2. **Decide the architecture + approach** (the HOW the spec deliberately omitted): write
@@ -69,14 +69,14 @@ Pull these via `Read` when shaping the plan:
    `.claude/skills/devrites-lib/reference/standards/tooling.md`) for structure/impact; for the current API or behaviour of
    an external library/framework the architecture will rely on, consult context7 if available.
    Record significant options in `decisions.md` as `DEC-###` ADR entries.
-   **Deep-modules check** — while sketching the major modules, look for opportunities
+   **Deep-modules check**, while sketching the major modules, look for opportunities
    to extract a **deep module**: a small, stable interface that hides a meaningful chunk
-   of behavior, and is therefore independently testable. A *shallow* module — interface
-   nearly as complex as its implementation — earns nothing; either deepen it or delete
+   of behavior, and is therefore independently testable. A *shallow* module (interface
+   nearly as complex as its implementation) earns nothing; either deepen it or delete
    it. Where a slice will produce a deep module, confirm with the user which deep
    modules they want unit-tested in isolation (this informs the slice's "Tests to
    write/run" field).
-3. **Slice into vertical tasks** — each delivers one observable capability end-to-end and
+3. **Slice into vertical tasks:** each delivers one observable capability end-to-end and
    is verifiable on its own; the **count emerges from the work, not a target number**;
    first slice = thinnest useful end-to-end path; order by dependency (risk-first within a
    tier). For a broad mechanical refactor, use expand → migrate batches → contract instead
@@ -86,21 +86,21 @@ Pull these via `Read` when shaping the plan:
    and **Browser proof required** (UI), and whether it's **fullstack** (FE+BE → contract
    first, see `devrites-frontend-craft/reference/fullstack.md`). **For UI slices, name which
    of `design-brief.md`'s key states + interaction the slice delivers, and give it a binary
-   **Visual acceptance** target (state × viewport × input + target R-id/brief rule)** — so
+   **Visual acceptance** target (state × viewport × input + target R-id/brief rule)**, so
    the design contract maps onto slices, not just acceptance criteria.
-4. **Map coverage** — every `AC-###` spec acceptance criterion maps to ≥1 `SLICE-###`
+4. **Map coverage:** every `AC-###` spec acceptance criterion maps to ≥1 `SLICE-###`
    (`rite-spec/reference/acceptance-criteria.md`); no orphaned criteria, no slice without a
    criterion. Lift covered/backstop `Edge Coverage` rows and resolved `Prohibitions (must-NOT)`
    rows into `traceability.md` and `test-plan.md`; unresolved rows go to `assumptions.md` with
    their gate/owner.
-4a. **Parallel-lane sanity check** — after drafting `tasks.md` but before asking for plan
+4a. **Parallel-lane sanity check**: after drafting `tasks.md` but before asking for plan
    approval, run the advisory lane planner:
    ```bash
    devrites-engine lanes plan "$(cat .devrites/ACTIVE 2>/dev/null)"
    ```
    Use it to spot independent read-only/review lanes and dependency mistakes, but do not
    weaken DevRites' default of one production-write slice at a time.
-4b. **Persist the traceability matrix** — write `traceability.md` (`AC/REQ ID → slice(s) →
+4b. **Persist the traceability matrix**: write `traceability.md` (`AC/REQ ID → slice(s) →
    test/proof → evidence ID → touched files → status`), the living map `/rite-prove` and
    `/rite-seal` walk. Generate it with `devrites-engine coverage` when available, then save/rename
    the output as `traceability.md`, or write the table by hand from the same inputs if the
@@ -109,17 +109,17 @@ Pull these via `Read` when shaping the plan:
    S="$(cat .devrites/ACTIVE 2>/dev/null)"
    devrites-engine coverage "$S" > ".devrites/work/$S/traceability.md"
    ```
-5. **Complexity & deviations gate** — justify anything off DevRites defaults (new dep,
+5. **Complexity & deviations gate:** justify anything off DevRites defaults (new dep,
    extra abstraction, second design system) in the plan; if you can't justify it, simplify.
    **Principles conformance:** read `.devrites/principles.md` (if present) and confirm the
    approach honors every declared invariant. A plan that conflicts with one is not "a deviation
-   to justify away" — either reshape the approach to conform, or, when the conflict is genuine and
+   to justify away": either reshape the approach to conform, or, when the conflict is genuine and
    intended, route it through the Spec Drift Guard plus a recorded decision and a scoped principle
    exception a human approves. Never ready a plan that silently violates an invariant. (Re-scored
    as a blocking gate at `/rite-vet`; no file → none declared → nothing to check.)
 6. **Write** `architecture.md`, `plan.md`, `tasks.md`, and `traceability.md`; update
    `state.md` (phase: plan → next `/rite-vet`).
-6a. **Cross-artifact gate — now that `tasks.md` exists.** Run the deterministic
+6a. **Cross-artifact gate: now that `tasks.md` exists.** Run the deterministic
    spec↔tasks coverage/consistency check; any non-zero result blocks plan readiness:
    ```bash
    S="$(cat .devrites/ACTIVE 2>/dev/null)"
@@ -141,11 +141,11 @@ Use the canonical slice grammar in
 Every slice must satisfy that complete field set; phase-specific gate details live in
 [`reference/gates.md`](reference/gates.md).
 
-> **Mid-flight discipline.** When tempted to skip vertical slicing, coverage mapping, or dependency-order discipline — see [`anti-patterns`](reference/anti-patterns.md) (Common Rationalizations + Red Flags). Load it the moment you reach for the excuse.
+> **Mid-flight discipline.** When tempted to skip vertical slicing, coverage mapping, or dependency-order discipline: see [`anti-patterns`](reference/anti-patterns.md) (Common Rationalizations + Red Flags). Load it the moment you reach for the excuse.
 
 ## Output
 
-**Progress first** — run `devrites-engine progress`, then use the shared completion reply contract
+**Progress first**: run `devrites-engine progress`, then use the shared completion reply contract
 ([`devrites-lib/reference/reply-contract.md`](../devrites-lib/reference/reply-contract.md)).
 Default success shape:
 ```

package/pack/.claude/skills/rite-define/reference/anti-patterns.md

@@ -1,4 +1,4 @@
-# rite-define — anti-patterns
+# rite-define: anti-patterns
 
 Load this when standing a non-trivial planning decision in `/rite-define`,
 or when the agent feels reluctance toward vertical slicing or coverage
@@ -10,16 +10,16 @@ Pack-wide rationalizations + red flags: see [standards/anti-patterns.md](../../d
 
 | Excuse | Rebuttal |
 |---|---|
-| "Spec is good enough; just start coding." | Plan separates HOW from WHAT for a reason — missed HOW shows up as drift at slice 3. |
-| "One big slice is fine, the work is all related." | If slice 1 isn't shippable on its own, you're not slicing vertically — you're staging waterfall in disguise. |
-| "Tests can come at build time, not in tasks." | Every slice's `Tests to write/run` line is the contract that proves its acceptance — leave it blank, lose the contract. |
+| "Spec is good enough; just start coding." | Plan separates HOW from WHAT for a reason: missed HOW shows up as drift at slice 3. |
+| "One big slice is fine, the work is all related." | If slice 1 isn't shippable on its own, you're not slicing vertically. You're staging waterfall in disguise. |
+| "Tests can come at build time, not in tasks." | Every slice's `Tests to write/run` line is the contract that proves its acceptance: leave it blank, lose the contract. |
 | "Backend + frontend belong in one slice." | Fullstack goes contract-first: split the contract, then build a thin vertical slice that crosses both layers. |
 | "I can skip mapping every spec criterion." | An unmapped criterion is one nobody will build. Coverage isn't bureaucracy. |
 
 ## Red Flags
 
 - A slice with no acceptance criterion link back to `spec.md`.
-- A slice whose name contains "and" — two capabilities smuggled into one slice (the "and" test, [slicing](../../rite-plan/reference/slicing.md)).
+- A slice whose name contains "and": two capabilities smuggled into one slice (the "and" test, [slicing](../../rite-plan/reference/slicing.md)).
 - No first slice that's end-to-end thin (every slice depends on infra that doesn't exist yet).
 - A new dependency added without rationale in `decisions.md`.
 - A slice that doesn't list "Existing to reuse / extend" (you didn't search).

package/pack/.claude/skills/rite-define/reference/gates.md

@@ -1,4 +1,4 @@
-# Gate taxonomy — advisory · validating · blocking · escalating
+# Gate taxonomy: advisory · validating · blocking · escalating
 
 DevRites uses a four-gate model for HITL pauses, adapted from the regulated-agentic-workflow
 governance pattern. Picking the right gate for each `Mode: HITL` slice is the difference
@@ -22,29 +22,29 @@ audit / future record / FYI.
 **Example:** "We picked option A from the prototype's verdict but option B is also viable.
 Recording the choice for posterity."
 
-**SLA:** `none` — there is no waiting time because nothing is waiting.
+**SLA:** `none`. There is no waiting time because nothing is waiting.
 
 ### validating
 
 **Stakes:** medium. The slice can be built but should not merge before a human signs off.
-Async — the human reviews when they get to it, but the loop does not stall.
+Async: the human reviews when they get to it, but the loop does not stall.
 
 **Behavior:** in HITL mode, `/rite-build` pauses on this gate and writes
 `Awaiting human` to `state.md`. In AFK mode with `allow_gates: [advisory, validating]`,
 `/rite-build` builds the slice but marks it `built (pending review)` and writes the
 validating question; the feature does not seal until the entry is resolved. An open
-`gate: validating` entry is **merge-blocking by definition** — a slice marked
+`gate: validating` entry is **merge-blocking by definition**: a slice marked
 `built (pending review)` is not done, and seal is a NO-GO while it stands open.
 
 **Example:** "Schema migration adds a non-null column with a default. Backfill plan is
 recorded; reviewer should confirm the default is the right one for archived rows."
 
-**SLA:** `4h` — the work continues but the validating queue should drain within hours,
+**SLA:** `4h`: the work continues but the validating queue should drain within hours,
 not days.
 
 ### blocking
 
-**Stakes:** high. The slice cannot proceed safely without the answer. Synchronous —
+**Stakes:** high. The slice cannot proceed safely without the answer. Synchronous:
 the loop stops.
 
 **Behavior:** **always pauses regardless of `.devrites/AFK` config.** `/rite-build`
@@ -59,7 +59,7 @@ STOPs. The slice is not built until `/rite-resolve` lands.
 - Tests / types / lint are red and the agent cannot tell whether the slice's contract is
   wrong or the failing code is.
 
-**SLA:** `15m` — synchronous gates demand fast turnaround; otherwise treat the work as
+**SLA:** `15m`: synchronous gates demand fast turnaround; otherwise treat the work as
 genuinely blocked and re-plan around it.
 
 ### escalating
@@ -71,11 +71,11 @@ needs to route to a specialist (legal, security, principal engineer, designer-of
 `route:` field naming the specialist tag. `/rite-status` shows it under a separate
 "Escalating" line so it doesn't compete with synchronous blockers for the same reviewer.
 
-**Example:** "Slice introduces a contract with an external partner — needs legal review
+**Example:** "Slice introduces a contract with an external partner: needs legal review
 of the data-sharing language."
 
-**SLA:** `24h` — specialist routing implies the SLA is loose; if it needs to be tight,
-it's actually `blocking`.
+**SLA:** `24h`: specialist routing implies the SLA is loose; if it needs to be tight,
+it's `blocking`.
 
 ## Picking the gate
 
@@ -95,7 +95,7 @@ Apply this decision tree per HITL slice:
 
 | Gate | SLA | Synchronous? |
 |---|---|---|
-| advisory | `none` | — (does not pause) |
+| advisory | `none` |: (does not pause) |
 | validating | `4h` | no (async; build continues, merge blocks) |
 | blocking | `15m` | yes |
 | escalating | `24h` | yes, but to a specialist |
@@ -118,11 +118,11 @@ defaults and the always-pause rules:
 | `[advisory, validating, blocking]` | log + proceed | build + queue | log + proceed* | pause |
 
 \* but **never** for destructive migrations, auth/authz boundary changes, public API
-breaks, or red tests/types/lint — those always pause. See
+breaks, or red tests/types/lint. Those always pause. See
 [`.claude/skills/devrites-lib/reference/standards/afk-hitl.md`](../../devrites-lib/reference/standards/afk-hitl.md) for the irreversible-risk
 list.
 
-`escalating` is never in `allow_gates` — specialist routing is not something AFK can
+`escalating` is never in `allow_gates`: specialist routing is not something AFK can
 shortcut.
 
 ## Anti-patterns

package/pack/.claude/skills/rite-define/reference/plan-template.md

@@ -1,6 +1,6 @@
 # `plan.md` template
 
-Write **how** to build what `spec.md` defines. The plan is **living, not sacred** —
+Write **how** to build what `spec.md` defines. The plan is **living, not sacred**:
 `/rite-plan` repairs it when reality disagrees. This is where technology choices live
 (they're banned from the spec).
 

package/pack/.claude/skills/rite-doctor/SKILL.md

@@ -5,11 +5,11 @@ argument-hint: "[--code | --reindex]"
 user-invocable: true
 ---
 
-# /rite-doctor — health check
+# /rite-doctor: health check
 
 The on-demand deep report. The same checks run **silently at session start** (the orient
-hook surfaces issues only when there are any); `/rite-doctor` runs them **verbosely** —
-printing every check, pass or fail — so you can inspect health even when nothing is broken.
+hook surfaces issues only when there are any); `/rite-doctor` runs them **verbosely**:
+printing every check, pass or fail, so you can inspect health even when nothing is broken.
 It covers version drift, Claude Code wiring, optional Codex mirrors/hooks, stale host artifacts, and missing install markers when those files are present. With `--code`, it also runs the read-only project code-health dashboard (`devrites-engine health`).
 It also reports an in-progress git merge/rebase and points to `git-workflow.md`'s conflict
 recovery playbook.
@@ -21,7 +21,7 @@ It is **read-only**: it never edits the workspace, never advances a phase, never
    ```bash
    devrites-engine doctor --verbose; echo "doctor rc=$?"
    ```
-1a. **Surface the learnings nudge** — point the user at `/rite-learn` when a pattern recurs across
+1a. **Surface the learnings nudge**: point the user at `/rite-learn` when a pattern recurs across
    shipped features (read-only; silent when there's nothing to say):
    ```bash
    devrites-engine learnings nudge
@@ -30,18 +30,18 @@ It is **read-only**: it never edits the workspace, never advances a phase, never
    ```bash
    devrites-engine health; echo "health rc=$?"
    ```
-1c. **Validate project extensions + overrides** (read-only — report, don't sync). A user rite/
+1c. **Validate project extensions + overrides** (read-only: report, don't sync). A user rite/
    reviewer under `.devrites/extensions/` is held to the same schema as the shipped pack; a
    reviewer override under `.devrites/overrides/` may add emphasis but never relax a gate:
    ```bash
    devrites-engine extensions validate; echo "extensions rc=$?"
    devrites-engine overrides validate;  echo "overrides rc=$?"
    ```
-   - **extensions rc=1** — an extension is malformed (missing frontmatter, empty, duplicate name).
+   - **extensions rc=1:** an extension is malformed (missing frontmatter, empty, duplicate name).
      Fix the named file; once valid, the user mirrors it into the harness with
      `devrites-engine extensions sync`.
-   - **overrides rc=1** — an override reads like it waives a gate. That is the one thing overrides
-     must not do — hand the user the offending file to rewrite as added emphasis, not a waiver.
+   - **overrides rc=1:** an override reads like it waives a gate. That is the one thing overrides
+     must not do: hand the user the offending file to rewrite as added emphasis, not a waiver.
 1d. **Refresh indexes only when `$ARGUMENTS` includes `--reindex`.** Load and execute
    `devrites-refresh-indexes`; report its synchronous refresh result, then continue the
    diagnostic. This changes optional indexes, never project source or DevRites state.
@@ -51,12 +51,12 @@ It is **read-only**: it never edits the workspace, never advances a phase, never
    `/rite-resolve <qid>`; an incomplete install → reinstall). If the output includes
    `git-state: merge in progress` or `git-state: rebase in progress`, make the next action the
    `git-workflow.md` merge-conflict recovery playbook.
-3. **Do not fix anything yourself** — doctor is diagnostic. Hand the user the fix command.
+3. **Do not fix anything yourself:** doctor is diagnostic. Hand the user the fix command.
    **Completion:** exactly one highest-priority fix command is reported and no source/workspace file changed.
 
 ## Gotchas
-- Read-only — never write the workspace or advance a phase (that's the lifecycle skills' job).
-- It diagnoses **DevRites** health, not the user's application — code bugs go to
+- Read-only: never write the workspace or advance a phase (that's the lifecycle skills' job).
+- It diagnoses **DevRites** health, not the user's application: code bugs go to
   `devrites-debug-recovery`; feature progress goes to `/rite-status`.
 - Healthy is the common case; say so plainly and stop. Don't invent issues.
 

package/pack/.claude/skills/rite-dogfood/SKILL.md

@@ -6,7 +6,7 @@ user-invocable: true
 disable-model-invocation: true
 ---
 
-# /rite-dogfood — diff-scoped browser QA
+# /rite-dogfood: diff-scoped browser QA
 
 Dogfood what changed as a user journey. This complements `/rite-prove`: prove checks acceptance; dogfood finds journey breaks and paper cuts.
 
@@ -46,4 +46,4 @@ required, use `Stopped / blocked` or `Awaiting human`; do not recommend `/rite-p
 ## Gotchas
 - A page list is not a journey map; draw the flow first.
 - A screenshot path is not proof; open it and describe what changed.
-- Do not “fix” ambiguous UX intent just to clear the matrix.
+- Do not "fix" ambiguous UX intent just to clear the matrix.

package/pack/.claude/skills/rite-explain/SKILL.md

@@ -1,24 +1,24 @@
 ---
 name: rite-explain
 description: User-invoked explainer that teaches one concept, diff, idea, or recent-work recap with an optional retrieval check-in.
-argument-hint: "[a concept | a diff ref | an idea | \"what did I do this week?\"] — or bare to be asked"
+argument-hint: "[a concept | a diff ref | an idea | \"what did I do this week?\"], or bare to be asked"
 user-invocable: true
 disable-model-invocation: true
 ---
 
-# /rite-explain — the human half of the learning loop
+# /rite-explain: the human half of the learning loop
 
 Agent-driven development removed the learning that writing code by hand used to give the
 developer. When the agent writes the code, the human stops absorbing the codebase. `/rite-explain`
-is the replacement: it teaches the developer **one** thing well — a concept, a change, an idea, or
-a window of their own recent work — so they keep learning while the agents do the writing. For a
+is the replacement: it teaches the developer **one** thing well (a concept, a change, an idea, or
+a window of their own recent work) so they keep learning while the agents do the writing. For a
 specific change, it can instead write a **walkthrough**: a human review guide organized by concern,
 risk stops, and manual observations.
 
 This is the **complement of [`/rite-learn`](../rite-learn/SKILL.md)**, and the two together are
-the whole compounding story. `/rite-learn` teaches the **repo** — it promotes recurring lessons
-into rules and principles the next feature reads. `/rite-explain` teaches the **person** — the
-mental model the next feature needs a human to actually hold. A team that only runs `/rite-learn`
+the whole compounding story. `/rite-learn` teaches the **repo**. It promotes recurring lessons
+into rules and principles the next feature reads. `/rite-explain` teaches the **person**: the
+mental model the next feature needs a human to hold. A team that only runs `/rite-learn`
 compounds a codebase whose own maintainers understand it less each week. Run both.
 
 Read-only against source. It reads artifacts and code; it writes exactly one explainer file to
@@ -26,9 +26,9 @@ Read-only against source. It reads artifacts and code; it writes exactly one exp
 
 ## Who the explainer is for
 
-The developer, personally. Dense, technical, one voice — no audience adaptation, no "for
+The developer, personally. Dense, technical, one voice: no audience adaptation, no "for
 beginners" softening, no executive summary. It is a display artifact: no embedded quizzes or
-widgets — the check-in (below) happens live in the session, where an answer can actually be
+widgets: the check-in (below) happens live in the session, where an answer can be
 graded. If the user asked for prep for a meeting or a teammate, it preps **them** to explain the
 thing; it does not produce the deck.
 
@@ -36,10 +36,10 @@ thing; it does not produce the deck.
 
 Dispatch by task shape, per [`devrites-lib/reference/model-tiers.md`](../devrites-lib/reference/model-tiers.md):
 
-- **extraction tier** — the work-recap scout and any repo-profiling: search-and-quote, run under a
+- **extraction tier:** the work-recap scout and any repo-profiling: search-and-quote, run under a
   read budget, write findings to the run's scratch dossier, return only a gist.
-- **ceiling tier** — the explainer composition and the check-in reasoning. These run inline in the
-  orchestrator's own model; nothing is dispatched down. Teaching quality is the whole product — do
+- **ceiling tier:** the explainer composition and the check-in reasoning. These run inline in the
+  orchestrator's own model; nothing is dispatched down. Teaching quality is the whole product: do
   not cheapen it.
 
 The degradation rule in that file applies: no per-agent model control → run the scout inline under
@@ -47,26 +47,26 @@ the same budget.
 
 ## Workflow
 
-### 1. Classify the input — load the intake reference
+### 1. Classify the input: load the intake reference
 
 The four input shapes (concept · diff · idea · work-recap) each ground and compose differently,
 and each drives a different check-in. Diff inputs also branch into explainer vs walkthrough
 composition. Getting the shape wrong wastes the whole artifact.
 
-**Load [`reference/intake.md`](reference/intake.md) now** — it owns the classification rules, the
+**Load [`reference/intake.md`](reference/intake.md) now**. It owns the classification rules, the
 `diff:` / `since:` / `output:` token table, the concept-vs-diff tiebreak, and the check-in
 mechanics per shape. Do not improvise classification from this file; the detail lives there so this
 one stays legible, and skipping it means guessing the shape.
 
 **Bare invocation** (no input): ask **one** blocking question (`AskUserQuestion` when the harness
-has it, else the harness's blocking-question tool — `request_user_input` on Codex) — "What should I
-explain?" — offering "a recap of my recent work in this repo" as a shortcut option alongside free
+has it, else the harness's blocking-question tool: `request_user_input` on Codex). "What should I
+explain?": offering "a recap of my recent work in this repo" as a shortcut option alongside free
 text. Never emit a default explainer unprompted.
 
 ### 2. Ground
 
 Match grounding to the shape (full rules in the intake reference). DevRites gives you grounding for
-free — prefer it over re-deriving:
+free: prefer it over re-deriving:
 
 - A **diff** or **recap** → the workspace and archive: `seal.md`, `evidence.md`, `decisions.md`,
   `traceability.md`, the shipped `.devrites/archive/<slug>/`, and `git log` / `git diff`.
@@ -93,13 +93,13 @@ Otherwise write one dense artifact at `$RUN_DIR/explainer.md`. It must **teach**
    teach the highest-leverage slice and say what you cut.
    **Completion:** the first two lines state one takeaway and any deferred topics.
 2. **Build the model, don't list facts.** Start from what the developer already knows in *this*
-   codebase and move to the new thing. Concrete before abstract — a real symbol, file, or line
+   codebase and move to the new thing. Concrete before abstract: a real symbol, file, or line
    from the grounding beats a generic example every time.
    **Completion:** the explanation connects a known project anchor to the new model without a fact dump.
 3. **Show the load-bearing detail.** Quote the actual diff hunk, the real function, the specific
-   config — with `file:line` pointers so the developer can go read it.
+   config, with `file:line` pointers so the developer can go read it.
 4. **Visual where it earns it.** A small diagram, a before/after, or a worked trace when the shape
-   is spatial or sequential. Not decoration — only when it carries the idea faster than prose.
+   is spatial or sequential. Not decoration: only when it carries the idea faster than prose.
    **Completion:** the visual carries a named relationship faster than prose, or this branch is explicitly skipped.
 5. **Human voice.** Follow [`prose-style.md`](../devrites-lib/reference/standards/prose-style.md):
    no throat-clearing, no false-binary contrast, no marketing adjectives. One senior engineer
@@ -108,7 +108,7 @@ Otherwise write one dense artifact at `$RUN_DIR/explainer.md`. It must **teach**
 ### 4. Offer the check-in (optional, active recall)
 
 Retention comes from *retrieving*, not re-reading. After the explainer, offer one check-in via the
-harness's blocking-question tool (`AskUserQuestion`, or `request_user_input` on Codex) — the user
+harness's blocking-question tool (`AskUserQuestion`, or `request_user_input` on Codex): the user
 answers **first**, then you confirm or correct. The shape sets the
 form (mechanics in the intake reference):
 
@@ -126,7 +126,7 @@ not force it; offer once.
   rest as "next time".
 - **Ground it or don't claim it.** A concept explainer with no `file:line` or real example is a
   Wikipedia paragraph. If it has footprint in this repo, quote the repo.
-- **Not a review.** `/rite-explain` never judges the code or files findings — that is `/rite-review`.
+- **Not a review.** `/rite-explain` never judges the code or files findings, that is `/rite-review`.
   It explains what *is*, adversarially neutral.
 - **Not `/rite-learn`.** It writes to `.devrites/explainers/`, never to `learnings.md`,
   `principles.md`, or any rule file. Teaching the human is not promoting a repo rule.

package/pack/.claude/skills/rite-explain/reference/intake.md

@@ -1,4 +1,4 @@
-# rite-explain intake — classify the input, then ground and check-in by shape
+# rite-explain intake: classify the input, then ground and check-in by shape
 
 Owned by `/rite-explain`. Loaded at Phase 1 because the four input shapes ground, compose, and
 check-in differently, and this detail would bloat the SKILL if inlined. This file is the single
@@ -9,11 +9,11 @@ source for classification; the SKILL improvises none of it.
 | Shape | The input is… | Grounds in | Composes as | Check-in |
 |---|---|---|---|---|
 | **concept** | a named idea / pattern / technology ("explain optimistic locking", "how does our gate engine work") | this repo's footprint of the concept (codegraph first) + external sources only if they sharpen it | build the mental model from a known part of *this* codebase outward | **checked exercise** |
-| **diff** | a specific change — a ref, a slice, a PR, "this diff" | `git diff` / the hunks + `decisions.md` + `seal.md` for the *why* + `touched-files.md` `Review trail` when present | explainer, or **walkthrough** when the user asks to review/approve/checkpoint the change | **predict-then-reveal** |
+| **diff** | a specific change: a ref, a slice, a PR, "this diff" | `git diff` / the hunks + `decisions.md` + `seal.md` for the *why* + `touched-files.md` `Review trail` when present | explainer, or **walkthrough** when the user asks to review/approve/checkpoint the change | **predict-then-reveal** |
 | **idea** | a hypothesis or "what if" with no code yet | the user's framing + prior art (external, date-weighted; year is 2026) | steelman the idea, name its hinge and its failure mode | **checked exercise** |
 | **recap** | a time window of the user's own work ("what did I ship this week") | the shipped archive + `git log`/`git diff` over the window + `evidence.md` | narrate what changed and what was learned, ranked by leverage | **predict-then-reveal** |
 
-## Token overrides — explicit beats inferred
+## Token overrides: explicit beats inferred
 
 If the user's input carries any of these tokens, they **override** shape inference:
 
@@ -30,20 +30,20 @@ use the diff shape with walkthrough composition.
 
 ## Tiebreaks
 
-- **concept vs diff** — if the input names both a concept *and* a specific change ("explain how
+- **concept vs diff:** if the input names both a concept *and* a specific change ("explain how
   this diff does optimistic locking"), it is a **diff** explainer that teaches the concept through
   the change. Ground in the diff; use the concept as the model to build.
-- **idea vs concept** — if the thing exists in the codebase or the wider world already, it is a
+- **idea vs concept:** if the thing exists in the codebase or the wider world already, it is a
   **concept** (teach what is). If it is a proposal not yet built, it is an **idea** (teach whether
   it holds).
-- **conflict** — a token and the prose disagree (`diff:` set but the text asks to explain a
+- **conflict:** a token and the prose disagree (`diff:` set but the text asks to explain a
   concept) → the token wins for shape; honor the prose for emphasis. State the resolution in one
   line at the top of the explainer.
 
 ## Check-in mechanics
 
 Retention comes from retrieval. Offer exactly one check-in via the harness's blocking-question tool
-(`AskUserQuestion`, or `request_user_input` on Codex); the user answers **before** any reveal. Grade honestly — a wrong prediction that gets corrected teaches more than a
+(`AskUserQuestion`, or `request_user_input` on Codex); the user answers **before** any reveal. Grade honestly: a wrong prediction that gets corrected teaches more than a
 confirmed one, so do not lead the witness.
 
 ## Walkthrough composition (diff only)
@@ -51,26 +51,26 @@ confirmed one, so do not lead the witness.
 A walkthrough is for human review, not retention. Write it under the normal run directory as
 `walkthrough.md` and include:
 
-1. **Intent** — one sentence naming what the change is for, grounded in `spec.md` / `decisions.md` when available.
-2. **Scope** — files changed, modules touched, and boundary crossings.
-3. **Concern walkthrough** — group `path:line` stops by design intent, not file order. Prefer the existing `touched-files.md` `Review trail`; generate one from the diff only when absent.
-4. **Risk stops** — 2–5 highest-blast-radius places to inspect, tagged `[auth]`, `[data]`, `[schema]`, `[public API]`, `[migration]`, `[ui]`, `[perf]`, or `[test]` where relevant.
-5. **Manual observations** — 2–5 concrete ways a human can observe the change working. If there is no user-visible behavior, say so and name the automated evidence instead.
-6. **Decision options** — approve / rework / ask for a targeted review, each with the next command.
+1. **Intent:** one sentence naming what the change is for, grounded in `spec.md` / `decisions.md` when available.
+2. **Scope:** files changed, modules touched, and boundary crossings.
+3. **Concern walkthrough:** group `path:line` stops by design intent, not file order. Prefer the existing `touched-files.md` `Review trail`; generate one from the diff only when absent.
+4. **Risk stops:** 2-5 highest-blast-radius places to inspect, tagged `[auth]`, `[data]`, `[schema]`, `[public API]`, `[migration]`, `[ui]`, `[perf]`, or `[test]` where relevant.
+5. **Manual observations:** 2-5 concrete ways a human can observe the change working. If there is no user-visible behavior, say so and name the automated evidence instead.
+6. **Decision options:** approve / rework / ask for a targeted review, each with the next command.
 
 Completion criterion: every concern has at least one clickable repo-relative `path:line` stop, or the walkthrough states why the change has no source stops.
 
 ### Predict-then-reveal (diff / recap)
 
 1. Pick the single most load-bearing hunk or decision in the explainer.
-2. Ask the user to predict: "what does this change do?" / "why was `<decision>` made here?" —
-   offer 2–4 plausible options where one is the real answer and the distractors are *reasonable*
+2. Ask the user to predict: "what does this change do?" / "why was `<decision>` made here?":
+   offer 2-4 plausible options where one is the real answer and the distractors are *reasonable*
    (a distractor no one would pick teaches nothing).
 3. On answer, reveal: confirm or correct, pointing at the exact `file:line` that settles it.
 
 ### Checked exercise (concept / idea)
 
-1. Pose one small problem the developer solves using the model just taught — "given `<situation>`,
+1. Pose one small problem the developer solves using the model just taught: "given `<situation>`,
    what would `<mechanism>` do?" or "where would this break?".
 2. Let them answer, then grade against the taught model: name what they got right, correct what
    they missed, and cite the part of the explainer (or the repo) that covers it.