devrites 3.0.5 → 3.0.7

package/pack/generated/claude/skills/rite-review/SKILL.md

@@ -5,7 +5,7 @@ argument-hint: "[scope: slice N | feature] [--full]"
 user-invocable: true
 ---
 
-# /rite-review — feature-scoped review
+# /rite-review: feature-scoped review
 
 Senior review of the **active feature scope only**. **Read the active workspace first**;
 if none, tell the user to run `/rite-spec <feature>`.
@@ -19,14 +19,14 @@ if none, tell the user to run `/rite-spec <feature>`.
 
 ## Rules consulted (read on demand from `.claude/skills/devrites-lib/reference/standards/`)
 Pull these via `Read` when the diff demands them:
-- `code-review.md` — small PRs, severity labels, tests-first review focus.
-- `review-checklist.md` — compact pass/fail sweep before reporting the verdict.
-- `principles.md` — declared project invariants (`.devrites/principles.md`); a diff that violates one with no recorded exception is a Critical, blocking finding.
-- `testing.md` — confirm the tests prove the spec, not just pass.
-- `agents.md` — when to fan out to which review subagent.
-- `security.md` — when input / auth / data / integrations / secrets are in scope.
-- `security-checklist.md` — for the same security-sensitive scope, the compact trust-boundary sweep.
-- `performance.md` — only when perf is relevant or a regression risk is visible.
+- `code-review.md`: small PRs, severity labels, tests-first review focus.
+- `review-checklist.md`: compact pass/fail sweep before reporting the verdict.
+- `principles.md`: declared project invariants (`.devrites/principles.md`); a diff that violates one with no recorded exception is a Critical, blocking finding.
+- `testing.md`: confirm the tests prove the spec, not just pass.
+- `agents.md`: when to fan out to which review subagent.
+- `security.md`: when input / auth / data / integrations / secrets are in scope.
+- `security-checklist.md`: for the same security-sensitive scope, the compact trust-boundary sweep.
+- `performance.md`: only when perf is relevant or a regression risk is visible.
 
 ## Operating rules
 - **Feature scope only.** Review touched files + the diff. **NO whole-project refactors,
@@ -34,7 +34,7 @@ Pull these via `Read` when the diff demands them:
   asking. Spec Drift Guard applies.
 - **Reviews the finished product.** `/rite-polish` has already done **code simplification**
   + UI normalize/polish. Review judges; if it reveals a real complexity issue polish
-  missed, flag it as a finding — don't re-run a simplification sweep here.
+  missed, flag it as a finding: don't re-run a simplification sweep here.
 - Findings are labeled (below). Re-prove after any change you make.
 
 ## Workflow
@@ -42,18 +42,18 @@ Pull these via `Read` when the diff demands them:
    on-demand rules above as the diff demands them.
    Then run `devrites-engine preamble` for deterministic workspace orientation.
 1. Read `spec.md`, `tasks.md`, `state.md`, `decisions.md`, `evidence.md`,
-   `touched-files.md`, `.devrites/principles.md` (if present — the binding invariants to score
+   `touched-files.md`, `.devrites/principles.md` (if present: the binding invariants to score
    the diff against), and the `git diff`. For "what would this change break"
-   questions, prefer a code-intelligence index if available — codebase-memory-mcp first,
+   questions, prefer a code-intelligence index if available (codebase-memory-mcp first,
    cross-checked with codegraph + graphify, else standard methods (LSP / Read/Grep/Glob); see
-   `.claude/skills/devrites-lib/reference/standards/tooling.md` — over file reads;
+   `.claude/skills/devrites-lib/reference/standards/tooling.md`) over file reads;
    they answer impact/callers in one call. When a finding hinges on an external library's
    current API, context7 if available can confirm the signature.
-2. **Review tests first** — do they actually prove the acceptance criteria? Missing,
+2. **Review tests first:** do they prove the acceptance criteria? Missing,
    weak, or wrong tests are the first findings.
    **Completion:** every acceptance criterion maps to a proven test or a labeled finding.
 3. **Spec ↔ Code-review split (parallel sub-agents, fresh context).** A change can pass
-   one axis and fail the other — code that follows every project standard but
+   one axis and fail the other: code that follows every project standard but
    implements the wrong thing (Code-review pass, Spec fail), or code that does exactly
    what the spec asked but breaks project conventions (Spec pass, Code-review fail).
    Running them serially in one context lets one mask the other. So:
@@ -74,16 +74,16 @@ Pull these via `Read` when the diff demands them:
        where 20 would do) and the silent-failure bugs (a missing value coerced to 0/''/[],
        a dropped Result/err return, off-by-one / boundary, logic that contradicts the
        comment/docstring/name). Per hunk, check whether working code was deleted that the
-       task did not ask to remove. Score the diff against `.devrites/principles.md` — a change
+       task did not ask to remove. Score the diff against `.devrites/principles.md`: a change
        that breaks a declared invariant with no recorded, human-approved exception is a Critical.
        Distinguish hard documented-standard violations from baseline smells; smells are judgment
        calls unless a DevRites or project standard makes them binding."
    - **Do NOT merge or re-rank** their findings. Present them under separate
      `## Spec` and `## Code review` sub-sections in `review.md`. Surface contradictions
      between the axes explicitly (e.g. "Spec axis says complete, Code-review axis says
-     untestable") — `/rite-seal` decides what blocks.
+     untestable"): `/rite-seal` decides what blocks.
 4. **Reconcile, don't re-review.** With the two parallel reports in hand, the inline
-   lead reconciles — it does **not** re-run the code-review axes over correctness /
+   lead reconciles. It does **not** re-run the code-review axes over correctness /
    readability / architecture / maintainability that `devrites-code-reviewer` already
    covered. Stay in scope ([feature-scoped-review](reference/feature-scoped-review.md)).
    Add only what the dispatched agents could not, then resolve overlaps and
@@ -92,13 +92,13 @@ Pull these via `Read` when the diff demands them:
    - **UI feature?** Apply the **UX rubric**
      ([nielsen-heuristics](reference/nielsen-heuristics.md)) and the
      **cognitive-load lens** ([cognitive-load](reference/cognitive-load.md)) on the
-     UX axis — surface heuristics scoring ≤ 2 and any cognitive-load findings
+     UX axis: surface heuristics scoring ≤ 2 and any cognitive-load findings
      (extraneous noise, missing progressive disclosure, vocabulary drift) at the
      appropriate severity.
-5. **Security** — apply `devrites-audit security`
+5. **Security:** apply `devrites-audit security`
    ([security-review](reference/security-review.md)) when user input, auth, data
    storage, external integrations, secrets, or permissions are involved.
-6. **Performance** — apply `devrites-audit perf`
+6. **Performance:** apply `devrites-audit perf`
    ([performance-review](reference/performance-review.md)) only when performance is
    relevant or a regression risk is visible (measure first).
 7. Apply only in-scope fixes; **run verification after changes** (`/rite-prove` logic).
@@ -108,38 +108,38 @@ Pull these via `Read` when the diff demands them:
    devrites-engine review-integrity
    devrites-engine review-fingerprints --write
    ```
-   Exit 1 means an adversarial axis reported nothing and justified nothing — a suspected
+   Exit 1 means an adversarial axis reported nothing and justified nothing: a suspected
    rubber-stamp. Re-run that axis or add its `No-findings:` justification; do not carry a silent
    axis into `/rite-seal` (where it surfaces as an Important).
 
 ## Finding labels
-- **Critical** — must fix before seal (correctness/security/data loss).
-- **Important** — should fix before seal (likely bug, real maintainability risk).
-- **Suggestion** — worth doing, not blocking.
-- **Nit** — trivial/style.
-- **FYI** — context, no action implied.
+- **Critical:** must fix before seal (correctness/security/data loss).
+- **Important:** should fix before seal (likely bug, real maintainability risk).
+- **Suggestion:** worth doing, not blocking.
+- **Nit:** trivial/style.
+- **FYI:** context, no action implied.
 
 **Action decoration (orthogonal to severity).** Also tag each finding with how to act on it:
 `blocking` (fix before seal), `non-blocking` (fix when convenient), or `if-minor` (fix only if the
-change is already small — a pure noise-economics lever). Only a **`blocking` Critical** gates the
+change is already small: a pure noise-economics lever). Only a **`blocking` Critical** gates the
 seal; a `non-blocking` / `if-minor` finding is recorded, not a stop.
 
 ## Confidence + signal-to-noise
-Borrow `/rite-vet`'s discipline so review stays **trusted, not noisy** — a reviewer that posts
+Borrow `/rite-vet`'s discipline so review stays **trusted, not noisy**: a reviewer that posts
 18 comments per PR teaches the team to ignore every one (below ~10% false-positive rate devs
 investigate each finding; past ~30% they label the tool noisy and skip it):
-- **Confidence-band each finding** (1–10) and state the band. A low-confidence finding (≤4)
-  you can't verify against the code is **suppressed** — roll it into one `Suppressed
+- **Confidence-band each finding** (1-10) and state the band. A low-confidence finding (≤4)
+  you can't verify against the code is **suppressed**: roll it into one `Suppressed
   (low-confidence): n` line, never raised as Critical/Important.
 - **Verify before you escalate.** Every Critical/Important quotes the spec line or cites the
-  `file:line` that proves it — no unverified blockers.
+  `file:line` that proves it: no unverified blockers.
 - **Budget the noise.** Roll up trivia ("N style nits") into a single line; tooling already
   catches style. Review's job is correctness + spec fidelity, not a lint dump.
 - **A silent axis is suspicious, not clean.** An adversarial axis that raises nothing must earn
   it: end its `## Spec` / `## Code review` section with a **`No-findings:`** line naming the
   passes it ran (missing/partial/incorrect for spec; edge cases, error paths, the riskiest
   decision, a changed behavior whose test may not cover it for code) and why each came back
-  empty. This is the mirror of confidence-banding — banding kills the false positive, this catches
+  empty. This is the mirror of confidence-banding: banding kills the false positive, this catches
   the false negative ([`code-review.md` § Zero findings is suspicious](../devrites-lib/reference/standards/code-review.md)).
 
 ## Severity orientation (labels, not score)
@@ -149,7 +149,7 @@ FYI` counts. There is no composite number — `/rite-seal` gates on
 `Critical == 0` and on acceptance + drift. Inventing a number invites gaming;
 the labels do the work.
 
-> **Mid-flight discipline.** When tempted to demote a Critical, hide a finding, fix without re-verification, or wander out of scope — see [`anti-patterns`](reference/anti-patterns.md). Load it the moment you reach for the excuse.
+> **Mid-flight discipline.** When tempted to demote a Critical, hide a finding, fix without re-verification, or wander out of scope: see [`anti-patterns`](reference/anti-patterns.md). Load it the moment you reach for the excuse.
 
 ## Output → `review.md`
 

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

@@ -1,4 +1,4 @@
-# rite-review — anti-patterns
+# rite-review: anti-patterns
 
 Load this when standing a non-trivial review decision, when tempted to
 demote severity to hide a finding, or when crossing out of feature scope.
@@ -10,9 +10,9 @@ Pack-wide rationalizations + red flags: see
 
 | Excuse | Rebuttal |
 |---|---|
-| "Polish already cleaned this up; nothing to flag." | Polish finishes; review judges. If review still spots a real issue, flag it — don't re-run polish here. |
+| "Polish already cleaned this up; nothing to flag." | Polish finishes; review judges. If review still spots a real issue, flag it: don't re-run polish here. |
 | "Tests pass, so they're adequate." | Adequacy = do they prove acceptance, including failure / boundary / empty paths? A passing test is not automatically a good test. |
-| "Security audit isn't needed for this feature." | If the feature touches user input, auth, data storage, external integrations, secrets, or permissions — yes it is. |
+| "Security audit isn't needed for this feature." | If the feature touches user input, auth, data storage, external integrations, secrets, or permissions: yes it is. |
 | "I'll just fix everything I find in scope." | Some fixes belong in `/rite-plan` as drift, not as smuggled redesigns inside review. |
 | "Performance is fine without measuring." | No claim without a number or a specified measurement. "Feels fast" is not a finding. |
 
@@ -20,7 +20,7 @@ Pack-wide rationalizations + red flags: see
 
 | Excuse | Rebuttal |
 |---|---|
-| "Demoting a Critical to Important keeps the review clean." | Severity reflects the actual risk to ship — not the review you'd like. |
+| "Demoting a Critical to Important keeps the review clean." | Severity reflects the actual risk to ship, not the review you'd like. |
 | "I won't surface this Critical; user can find it later." | Hidden Criticals are the worst-case play. The seal blocks anyway, and now you've burned trust. |
 
 ## Red Flags

package/pack/generated/claude/skills/rite-review/reference/cognitive-load.md

@@ -1,22 +1,22 @@
-# Cognitive load — a UX review lens
+# Cognitive load: a UX review lens
 
 Cognitive load is the total mental effort the interface demands. Overloaded users
 hesitate, misclick, abandon. Reviewing UI without this lens misses a whole class of
 defects that no a11y checker or perf tool will flag.
 
 DevRites' `/rite-review` uses this reference when the feature touches UI. It is
-descriptive (helps you spot defects) rather than scored — findings raised here
+descriptive (helps you spot defects) rather than scored: findings raised here
 roll up under the UX axis of the multi-axis review with the usual severity labels.
 
 ## Three kinds of load
 
 | Type | Source | Reviewer's job |
 |---|---|---|
-| **Intrinsic** | The task itself — its inherent steps, decisions, and required knowledge. | Can't be eliminated, only **structured**: step the user through it, provide defaults, group related decisions, defer what isn't needed yet. |
-| **Extraneous** | Bad design — friction the task doesn't require: noisy hierarchy, redundant choices, jargon, layout that hides the next step. | **Eliminate it ruthlessly.** It's pure waste, and the easiest class of finding to land. |
-| **Germane** | Effort the user spends *forming a mental model* of the product. | **Invest deliberately.** Consistent flows, shared vocabulary, predictable affordances — anything that lets the user re-use what they already learned. |
+| **Intrinsic** | The task itself: its inherent steps, decisions, and required knowledge. | Can't be eliminated, only **structured**: step the user through it, provide defaults, group related decisions, defer what isn't needed yet. |
+| **Extraneous** | Bad design: friction the task doesn't require: noisy hierarchy, redundant choices, jargon, layout that hides the next step. | **Eliminate it ruthlessly.** It's pure waste, and the easiest class of finding to land. |
+| **Germane** | Effort the user spends *forming a mental model* of the product. | **Invest deliberately.** Consistent flows, shared vocabulary, predictable affordances: anything that lets the user re-use what they already learned. |
 
-A surface can be intrinsic-heavy *and* extraneously-fine — that's a hard task done
+A surface can be intrinsic-heavy *and* extraneously-fine. That's a hard task done
 right. A simple surface that still feels heavy is extraneous load disguised as
 "complexity."
 
@@ -27,46 +27,46 @@ Treat each as a finding when present; classify by load type so the fix is obviou
 ### Extraneous (reduce / remove)
 - **Visual noise** that doesn't earn its place: redundant borders, shadows,
   dividers, gratuitous icons next to every label, colour used decoratively.
-- **Competing primary actions** — two or three buttons of equal weight when one
+- **Competing primary actions:** two or three buttons of equal weight when one
   is clearly the next step.
-- **Jargon and abbreviations** the user doesn't share — names from the codebase
+- **Jargon and abbreviations** the user doesn't share: names from the codebase
   or internal team that leaked into the UI.
 - **Restated headings** (the body of a section repeats the section title in
   long-form).
-- **Decision paralysis** — too many options when one default + a "more options"
+- **Decision paralysis:** too many options when one default + a "more options"
   toggle would do.
-- **Form fields without obvious priority** — required vs optional, primary vs
+- **Form fields without obvious priority:** required vs optional, primary vs
   secondary mixed in a single column with no rhythm.
 - **Premature error messaging** (validation that fires before the user has
   finished typing).
 
 ### Intrinsic (structure, don't try to eliminate)
-- **No progressive disclosure** on a genuinely complex task — every field
+- **No progressive disclosure** on a genuinely complex task: every field
   visible at once because "the user might need it".
-- **No safe defaults** on multi-step flows — the user has to choose at every step
+- **No safe defaults** on multi-step flows: the user has to choose at every step
   even when one path is the obvious answer.
-- **Decisions grouped wrong** — "billing address" sandwiched between two
+- **Decisions grouped wrong:** "billing address" sandwiched between two
   unrelated sections rather than next to "shipping address".
 - **No scaffolding** (no template, no example input, no recently-used value)
   for tasks that have a high blank-page cost.
 
 ### Germane (invest in)
-- **Inconsistent vocabulary** across the feature — same concept named two ways
+- **Inconsistent vocabulary** across the feature: same concept named two ways
   (e.g. "member" in one screen, "user" in the next).
 - **Flow-shape divergence** from neighbouring features (modal where the project
   uses inline; route-change where the project uses an overlay).
-- **Affordances that look interactive but aren't** (and vice versa) — destroys
+- **Affordances that look interactive but aren't** (and vice versa): destroys
   the mental model the user is trying to build.
 
-## Reviewing a flow — three-pass discipline
+## Reviewing a flow: three-pass discipline
 
 1. **First pass: silent.** Walk the flow without reading any explainer copy.
-   Anything that stops you cold without copy is a finding — either extraneous
+   Anything that stops you cold without copy is a finding: either extraneous
    load you can't dismiss, or a germane-load problem (the user is missing a
    mental model the UI assumes).
 2. **Second pass: with copy.** Read every label, helper, and error. Does the
    copy resolve the friction the first pass surfaced, or just paper over it?
-   "Tooltip explaining a confusing button" is rarely the right fix — usually
+   "Tooltip explaining a confusing button" is rarely the right fix: usually
    the button needs a different label.
 3. **Third pass: empty + error.** Run the flow with no data, partial data, and
    the worst inputs (offline / 500 / permission-denied). Most cognitive-load
@@ -81,12 +81,12 @@ doesn't decide the rewrite strategy.
 
 ## What this lens **doesn't** cover
 
-- **Accessibility** — separate axis (WCAG 2.2; see
+- **Accessibility:** separate axis (WCAG 2.2; see
   [`devrites-frontend-craft/reference/quality-standards.md`](../../devrites-frontend-craft/reference/quality-standards.md)).
-- **Performance** — separate axis (Core Web Vitals; see
+- **Performance:** separate axis (Core Web Vitals; see
   [`performance-checklist.md`](performance-checklist.md)).
-- **Code quality** — covered by the simplification audit
+- **Code quality:** covered by the simplification audit
   (`devrites-audit simplify`).
-- **Security** — covered by the security audit (`devrites-audit security`).
+- **Security:** covered by the security audit (`devrites-audit security`).
 
 Cognitive-load findings live on the **UX axis** of the multi-axis review.

package/pack/generated/claude/skills/rite-review/reference/feature-scoped-review.md

@@ -16,8 +16,8 @@ current diff. This is a hard rule, not a guideline.
 - Expand the review into a project audit.
 
 ## When you spot a real problem outside scope
-Record it as an **[FYI] follow-up** in `review.md` (and suggest a separate feature/issue)
-— don't fix it inline. Drive-by changes balloon the diff, dodge their own review, and
+Record it as an **[FYI] follow-up** in `review.md` (and suggest a separate feature/issue).
+Don't fix it inline. Drive-by changes balloon the diff, dodge their own review, and
 mix concerns the seal can't cleanly evaluate.
 
 ## Why scope discipline matters

package/pack/generated/claude/skills/rite-review/reference/five-axis-review.md

@@ -1,9 +1,9 @@
 # Code-review axes
 
-The axes the dispatched `devrites-code-reviewer` applies to the diff (tests first
-— always), under one severity scale (Critical / Important / Suggestion / Nit / FYI).
+The dispatched `devrites-code-reviewer` always checks tests first, then applies the remaining
+axes under one severity scale (Critical / Important / Suggestion / Nit / FYI).
 The `/rite-review` inline lead **reconciles** the returned report against the Spec
-axis — it does not re-run these axes itself. This file is the shared definition of
+axis. It does not re-run these axes itself. This file is the shared definition of
 what "full code-review discipline" covers; use it to judge whether the agent's report
 is complete, and to scope anything the agent could not (e.g. UI-only lenses below).
 
@@ -21,7 +21,7 @@ is complete, and to scope anything the agent could not (e.g. UI-only lenses belo
 - Can the next engineer understand it without the author? Naming, function length,
   nesting depth, comments that explain *why* not *what*.
 - Structural smells: a conditional **bolted onto an unrelated flow** (wants its own
-  helper/state/policy — a design smell, not a nit); **repeated conditionals on the same
+  helper/state/policy: a design smell, not a nit); **repeated conditionals on the same
   shape** (a missing model or dispatcher).
 
 ## 3. Architecture
@@ -31,7 +31,7 @@ is complete, and to scope anything the agent could not (e.g. UI-only lenses belo
   reader must hold; a "cleaner" version that leaves that count unchanged isn't cleaner.
 - Is feature-specific logic **leaking into a shared module** instead of its owning layer?
   Is a **type boundary** left implicit by a gratuitous `any`/cast or a silent fallback?
-- **Name the remedy, not just the smell** — replace a conditional chain with a typed
+- **Name the remedy, not just the smell:** replace a conditional chain with a typed
   dispatcher, separate orchestration from business logic, move feature logic to its owning
   package, delete a pass-through wrapper, split a large file. Prefer the move that removes
   moving pieces over one that re-centralizes the same complexity.
@@ -42,7 +42,7 @@ is complete, and to scope anything the agent could not (e.g. UI-only lenses belo
 
 ## 5. Performance
 - Obvious N+1s, unnecessary work in hot paths, payload sizes. Hand off to
-  `devrites-audit perf` when perf is relevant — **measure before claiming**.
+  `devrites-audit perf` when perf is relevant: **measure before claiming**.
 
 ## 6. Maintainability
 - Tests, docs/comments where needed, no dead code added, no TODOs left, consistent
@@ -54,7 +54,7 @@ is complete, and to scope anything the agent could not (e.g. UI-only lenses belo
 
 ## Sizing & speed
 Prefer reviewing roughly one slice / ~100 lines of meaningful change at a time. Larger
-diffs hide defects — recommend splitting rather than rubber-stamping. Watch **file size,
+diffs hide defects: recommend splitting rather than rubber-stamping. Watch **file size,
 not just diff size**: a small diff that pushes an already-large file further past a healthy
-boundary wants decomposition (extract helpers / split modules) *first* — decompose, then
+boundary wants decomposition (extract helpers / split modules) *first*: decompose, then
 add.

package/pack/generated/claude/skills/rite-review/reference/nielsen-heuristics.md

@@ -1,14 +1,14 @@
-# Nielsen's 10 usability heuristics — DevRites scoring rubric
+# Nielsen's 10 usability heuristics: DevRites scoring rubric
 
 A structured UX rubric for `/rite-review` when the feature touches UI. Score each
-heuristic on a **0–4** scale; the per-heuristic scores feed the UX axis of the
+heuristic on a **0-4** scale; the per-heuristic scores feed the UX axis of the
 multi-axis review and shape the severity labels on UX findings.
 
-**Score honestly.** 4 means *genuinely excellent* — not "good enough", not "no
-findings". 3 is "good with minor gaps". 2 is "partial — significant gaps". 0–1 is a
+**Score honestly.** 4 means *genuinely excellent*, not "good enough", not "no
+findings". 3 is "good with minor gaps". 2 is "partial: significant gaps". 0-1 is a
 Critical / Important.
 
-Heuristics are Jakob Nielsen's 10 (1994, refreshed 2020) — public usability canon,
+Heuristics are Jakob Nielsen's 10 (1994, refreshed 2020): public usability canon,
 referenced by every serious design discipline.
 
 ## 1. Visibility of system status
@@ -25,19 +25,19 @@ Users know what's happening, when, and where.
 
 ## 2. Match between system and the real world
 The UI speaks the user's language and follows real-world conventions.
-- Domain vocabulary the *user* shares — not the team's internal names.
+- Domain vocabulary the *user* shares, not the team's internal names.
 - Familiar metaphors where they help (cart, inbox, draft).
 - Information ordered the way the user thinks about it, not the way the DB stores it.
 
 | 0 | 1 | 2 | 3 | 4 |
 |---|---|---|---|---|
-| Jargon throughout. | Mostly internal vocabulary. | Mixed — some user terms, some internal. | Clear user terms; a couple of leaks. | Reads like the user's own words. |
+| Jargon throughout. | Mostly internal vocabulary. | Mixed: some user terms, some internal. | Clear user terms; a couple of leaks. | Reads like the user's own words. |
 
 ## 3. User control and freedom
 Easy escape, undo, and back-out from any state.
 - Cancel / close / back on every modal, route, and form.
 - Undo on destructive operations (delete, archive, reset).
-- No dead-end states ("Error — refresh the page" with no recovery).
+- No dead-end states ("Error: refresh the page" with no recovery).
 
 | 0 | 1 | 2 | 3 | 4 |
 |---|---|---|---|---|
@@ -74,7 +74,7 @@ Show options; don't force the user to remember them.
 
 | 0 | 1 | 2 | 3 | 4 |
 |---|---|---|---|---|
-| Heavy recall required. | Critical flows demand recall. | Mixed — some visible, some hidden. | Mostly recognition; minor recall asks. | Pure recognition; nothing the user needs is hidden. |
+| Heavy recall required. | Critical flows demand recall. | Mixed: some visible, some hidden. | Mostly recognition; minor recall asks. | Pure recognition; nothing the user needs is hidden. |
 
 ## 7. Flexibility and efficiency of use
 Novices and experts both productive.
@@ -101,8 +101,8 @@ Every element earns its place. No decorative noise.
 Error states are designed, not afterthoughts.
 - Errors named in user language ("Your card was declined") not codes ("Stripe 4002").
 - A concrete next step ("Try a different card" + "Use PayPal instead").
-- Inline location — the error appears next to the field / action that caused it.
-- No blame — the message describes the situation, not the user.
+- Inline location: the error appears next to the field / action that caused it.
+- No blame: the message describes the situation, not the user.
 
 | 0 | 1 | 2 | 3 | 4 |
 |---|---|---|---|---|
@@ -112,7 +112,7 @@ Error states are designed, not afterthoughts.
 Users can find what they need without leaving the surface.
 - Inline hints on novel patterns.
 - Search-friendly help for deeper questions.
-- No help is needed for the common path — and that's documented as a goal.
+- No help is needed for the common path, and that's documented as a goal.
 
 | 0 | 1 | 2 | 3 | 4 |
 |---|---|---|---|---|
@@ -121,8 +121,8 @@ Users can find what they need without leaving the surface.
 ## Reporting
 
 In `/rite-review` output, surface only the heuristics scoring **≤2** as findings,
-plus any 3 with a specific noted gap. Heuristics at 4 are not reported individually
-— they roll up into the UX axis. Heuristics at 3 with no specific gap are not
+plus any 3 with a specific noted gap. Heuristics at 4 are not reported individually.
+They roll up into the UX axis. Heuristics at 3 with no specific gap are not
 reported. Each surfaced finding gets a severity label per `rite-review/SKILL.md`.
 
 The rubric is descriptive, not gating. A score of 2 on aesthetic-minimalist isn't

package/pack/generated/claude/skills/rite-review/reference/performance-checklist.md

@@ -1,37 +1,37 @@
 # Performance checklist (baseline for the perf reviewer)
 
 The minimum baseline `devrites-performance-reviewer` checks against, in feature scope. It
-is a checklist, not a mandate: flag what the diff actually touches or what a measurement
+is a checklist, not a mandate: flag what the diff touches or what a measurement
 flags, never a project-wide sweep. The philosophy lives in
-[`standards/performance.md`](../../devrites-lib/reference/standards/performance.md) (measure first) — this file is the
+[`standards/performance.md`](../../devrites-lib/reference/standards/performance.md) (measure first). This file is the
 concrete what-to-look-for.
 
 ## Core Web Vitals targets
 
 | Metric | Good | Needs work | Poor |
 |---|---|---|---|
-| LCP — Largest Contentful Paint | ≤ 2.5s | ≤ 4.0s | > 4.0s |
-| INP — Interaction to Next Paint | ≤ 200ms | ≤ 500ms | > 500ms |
-| CLS — Cumulative Layout Shift | ≤ 0.1 | ≤ 0.25 | > 0.25 |
+| LCP: Largest Contentful Paint | ≤ 2.5s | ≤ 4.0s | > 4.0s |
+| INP: Interaction to Next Paint | ≤ 200ms | ≤ 500ms | > 500ms |
+| CLS: Cumulative Layout Shift | ≤ 0.1 | ≤ 0.25 | > 0.25 |
 
-A CWV value only counts when it carries a source — `Field (CrUX)`, `Lab (Lighthouse)`, or
+A CWV value only counts when it carries a source: `Field (CrUX)`, `Lab (Lighthouse)`, or
 `Trace (DevTools)`. No source → it's a Source-mode hypothesis, not a measurement.
 
 ## Frontend (only when the feature is UI-facing)
 
 Identify the framework first; apply only its idioms.
 
-- **Images** — modern format (WebP/AVIF); responsive `srcset`/`sizes`; explicit
+- **Images:** modern format (WebP/AVIF); responsive `srcset`/`sizes`; explicit
   `width`/`height` to reserve space (CLS); below-the-fold `loading="lazy"`; the LCP image
   gets `fetchpriority="high"` and is **not** lazy-loaded.
-- **JavaScript** — initial bundle stays small (≈200KB gzipped is the usual line); code-split
+- **JavaScript:** initial bundle stays small (≈200KB gzipped is the usual line); code-split
   routes and heavy features; no blocking script in `<head>` without `defer`/`async`; break
   long tasks (>50ms) so the main thread stays free (the main INP lever); `memo`/`useMemo`/
   `useCallback` only where profiling shows a win, not wrapped over everything.
-- **CSS** — critical CSS not render-blocking; no per-render CSS-in-JS runtime cost in prod.
-- **Fonts** — 2–3 families max; WOFF2; self-hosted where possible; preload the LCP font;
+- **CSS:** critical CSS not render-blocking; no per-render CSS-in-JS runtime cost in prod.
+- **Fonts:** 2-3 families max; WOFF2; self-hosted where possible; preload the LCP font;
   `font-display: swap`; subset with `unicode-range`.
-- **Rendering** — no layout thrashing (batch reads, then writes); animate `transform`/
+- **Rendering:** no layout thrashing (batch reads, then writes); animate `transform`/
   `opacity` only; virtualize long lists; `content-visibility: auto` for off-screen sections;
   don't break bfcache (no `unload` handler, no `Cache-Control: no-store` on HTML).
 
@@ -39,7 +39,7 @@ Identify the framework first; apply only its idioms.
 
 - No N+1 queries; eager-load / join / batch instead.
 - New queries have the indexes they need for their filter/sort columns.
-- List endpoints paginate — never an unbounded `SELECT *`.
+- List endpoints paginate: never an unbounded `SELECT *`.
 - Per-request work that doesn't change per call is cached or hoisted.
 - Responses compressed (gzip/brotli); bulk operations instead of a loop of single calls.
 
@@ -53,9 +53,9 @@ Identify the framework first; apply only its idioms.
 - State duplicated instead of lifted; effects with over-broad deps that re-run needlessly.
 - Sequential `await`s where `Promise.all` / parallel fetch fits.
 - Over-fetching "just in case"; redundant calls a dedup would collapse.
-- Defensive memoization wrapping cheap components — cost with no benefit.
+- Defensive memoization wrapping cheap components: cost with no benefit.
 
-## Modern APIs to consider (one-liners — reach for these, don't gate on them)
+## Modern APIs to consider (one-liners: reach for these, don't gate on them)
 
 `scheduler.yield()` to keep input responsive in long loops · Speculation Rules for
 prefetch/prerender · View Transitions on SPA navigation · Long Animation Frames (LoAF) for

package/pack/generated/claude/skills/rite-review/reference/security-review.md

@@ -9,20 +9,20 @@ This is the **single-sourced OWASP-web checklist** both `/rite-review` and the
 `devrites-security-auditor` agent apply (trust-boundary + the OWASP **LLM** Top 10 live in
 [`standards/security.md`](../../devrites-lib/reference/standards/security.md)). Keep the enumeration here; don't restate it.
 
-- **Injection** — parameterized queries; no string-built SQL/shell/HTML; validate &
+- **Injection:** parameterized queries; no string-built SQL/shell/HTML; validate &
   encode at boundaries.
-- **Broken access control** — every sensitive action checks authz server-side; no
+- **Broken access control:** every sensitive action checks authz server-side; no
   trusting client-supplied IDs/roles; no IDOR.
-- **Auth / session** — secure session handling; no credentials in code/logs; correct
+- **Auth / session:** secure session handling; no credentials in code/logs; correct
   password/token handling.
-- **Sensitive data** — PII/secrets not logged or returned; encryption where required;
+- **Sensitive data:** PII/secrets not logged or returned; encryption where required;
   least data exposed.
-- **SSRF / external calls** — validate/allowlist outbound URLs; timeouts; don't reflect
+- **SSRF / external calls:** validate/allowlist outbound URLs; timeouts; don't reflect
   untrusted input into requests.
-- **Misconfiguration** — safe defaults; debug off; CORS scoped; security headers as the
+- **Misconfiguration:** safe defaults; debug off; CORS scoped; security headers as the
   project uses them.
-- **Vulnerable dependencies** — new/updated deps audited; no known-vuln versions added.
-- **Integrity / deserialization** — don't deserialize untrusted data unsafely.
+- **Vulnerable dependencies:** new/updated deps audited; no known-vuln versions added.
+- **Integrity / deserialization:** don't deserialize untrusted data unsafely.
 
 ## Trust boundary
 Apply the three-tier discipline (untrusted → boundary → trusted) per the canonical rule
@@ -33,5 +33,5 @@ that skips the boundary tier is a finding.
 - Findings labeled Critical/Important/Suggestion. A real auth/data-exposure issue is
   **Critical** → NO-GO until fixed.
 - Secrets management: never commit secrets; use the project's secret mechanism.
-- Don't expand into a project-wide security audit — feature scope. Record out-of-scope
+- Don't expand into a project-wide security audit: feature scope. Record out-of-scope
   risks as follow-ups.