devrites 3.0.4 → 3.0.6

package/pack/generated/codex/skills/devrites-source-driven/SKILL.md

@@ -10,13 +10,13 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here — Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review** — an inline pass shares the calling context and is weaker evidence.
+- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
+- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
 - Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
-- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers — NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
+- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
-# devrites-source-driven — verify, don't guess
+# devrites-source-driven: verify, don't guess
 
 A confident wrong assumption about a library is a bug waiting to ship. When behavior
 matters and isn't certain, check the source of truth.
@@ -29,35 +29,35 @@ matters and isn't certain, check the source of truth.
 - An error message points at framework behavior you don't fully understand.
 
 ## How
-1. **Find the version** the project actually uses (lockfile, manifest) — behavior is
+1. **Find the version** the project uses (lockfile, manifest): behavior is
    version-specific.
 2. **Consult the source of truth**, in order: the installed package's own source/types
    in `node_modules`/gem/site-packages; context7 if available (`resolve-library-id` →
    `query-docs`) for current upstream docs; official docs for *that version*; the project's
    existing usage of the same API.
-3. **Confirm the specific fact** — the signature, the default, the edge behavior — not a
+3. **Confirm the specific fact:** the signature, the default, the edge behavior, not a
    general impression.
 4. **Record it** in `decisions.md` (or `evidence.md`): the fact, the version, and the
    source (path or URL). Future phases trust the record instead of re-checking.
 
 ## Delegate reading legwork bigger than one fact
-When the question is an *area*, not a fact — surveying a library's API surface, an unfamiliar
-subsystem's docs, a migration guide — dispatch a **background agent** instead of reading inline:
+When the question is an *area*, not a fact (surveying a library's API surface, an unfamiliar
+subsystem's docs, a migration guide) dispatch a **background agent** instead of reading inline:
 it investigates against the same source-of-truth order above, cites each claim (path or URL +
 version), and writes one note to the active workspace's `references/` directory, linked from
 `references.md`. You keep working while it reads; later phases trust the cited note. The inline
 flow above stays the path for confirming a single fact.
 
 ## Rules
-- Prefer the **installed** source over remembered docs — it can't be out of date.
+- Prefer the **installed** source over remembered docs. It can't be out of date.
 - Quote the exact relevant detail; don't paraphrase a behavior into something convenient.
-- If the doc/source contradicts the plan, that's a **Spec Drift Guard** event — stop and
+- If the doc/source contradicts the plan, that's a **Spec Drift Guard** event: stop and
   handle it.
 - Don't rabbit-hole: confirm the one fact you need, record it, return.
 
 ## Re-fetching is cheap (and still fresh)
 Fetching the same doc URL twice costs almost nothing: on Claude Code a WebFetch is transparently
-cached per project and, on reuse, revalidated against the origin — the cached reading is replayed **only**
+cached per project and, on reuse, revalidated against the origin: the cached reading is replayed **only**
 when the server confirms the page is unchanged (HTTP 304). A 304 is a fresh verification, not a
 memory read, so citing a revalidated page is as sound as re-fetching it. Fetch freely; don't
 skip a check to save a round trip. (Mechanism: the `devrites-source-cache` hooks; off via

package/pack/generated/codex/skills/devrites-ux-shape/SKILL.md

@@ -10,16 +10,16 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here — Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review** — an inline pass shares the calling context and is weaker evidence.
+- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
+- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
 - Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
-- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers — NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
+- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
-# devrites-ux-shape — plan the UX/UI before code
+# devrites-ux-shape: plan the UX/UI before code
 
 Decide what the UI *is* and how it should look and behave **before** code, and write it to
-the feature's `design-brief.md` — the contract the build (`devrites-frontend-craft`),
+the feature's `design-brief.md`: the contract the build (`devrites-frontend-craft`),
 polish, and seal all check against. This is "shape before code" raised to a **feature-level
 artifact**: produced once at spec time, refined per slice. It is **woven into the
 lifecycle** (`$rite-spec` calls it when UI is detected; `$rite-build` refines it), not a
@@ -30,59 +30,59 @@ separate phase the user runs.
   (`../rite-build/reference/frontend-trigger.md`). Output: `design-brief.md` + a
   confirmation pause.
 - `$rite-build` / `devrites-frontend-craft` read the brief as the **build target** and
-  refine it for the slice's surface — they don't re-derive it.
+  refine it for the slice's surface. They don't re-derive it.
 - Skip entirely for backend / data / CLI / infra-only features.
 
-## 1. Foundation — discover, don't impose
+## 1. Foundation: discover, don't impose
 Reuse what's there first. Read the design system + register and any references the spec
 gathered:
 - Design system + register (tokens, components, type, spacing, neighbors; brand-vs-product)
   → `../devrites-frontend-craft/reference/design-references.md`.
-- `PRODUCT.md` / `DESIGN.md` / `CLAUDE.md` if present — anchors that reduce questions.
+- `PRODUCT.md` / `DESIGN.md` / `CLAUDE.md` if present: anchors that reduce questions.
   `DESIGN.md` is the project's **rolled-up design memory** (tokens, calibration baseline,
   proven component behaviors) earlier features sealed via `../rite-ship/reference/design-memory.md`;
-  treat it as the inherited system — read it before re-discovering, depart only on signal.
-- `references.md` + `references/` — the screenshots / Figma / video / links the human
+  treat it as the inherited system: read it before re-discovering, depart only on signal.
+- `references.md` + `references/`: the screenshots / Figma / video / links the human
   supplied. Honor each recorded role: **target** = fidelity contract, **constraint** =
   required rule, **inspiration** = extract only the cited principle.
 
-## 2. Discovery — one round, assert-then-confirm
-Understand the feature deeply enough to make excellent design calls — **no code, no
+## 2. Discovery: one round, assert-then-confirm
+Understand the feature deeply enough to make excellent design calls: **no code, no
 markup**. Use the `devrites-interview` cadence: 2-3 questions per round, best-guess
 attached, stop when answers converge. One round is the default; add a second only for
 material gaps. When `PRODUCT.md` + the spec already pin an answer, **assert it and ask to
-confirm** ("reads as Restrained — confirm?"), don't offer a four-option menu. Cover:
-- **Purpose & user** — who, in what state of mind (rushed / exploring / anxious / focused).
-- **Content & data** — realistic ranges (0 / typical / many), dynamic content, real
+confirm** ("reads as Restrained: confirm?"), don't offer a four-option menu. Cover:
+- **Purpose & user:** who, in what state of mind (rushed / exploring / anxious / focused).
+- **Content & data:** realistic ranges (0 / typical / many), dynamic content, real
   media/assets the surface needs.
-- **Preserve + anti-goals** — identity, IA, behavior, content voice, SEO/analytics hooks,
+- **Preserve + anti-goals:** identity, IA, behavior, content voice, SEO/analytics hooks,
   existing accessibility wins, or assets that must survive; what this must NOT become;
   the biggest risk of getting it wrong.
 
-## 3. Design direction — the direction set (commit, don't hedge)
+## 3. Design direction: the direction set (commit, don't hedge)
 One deliberate visual decision on five fronts, each anchored in an existing reference so
 the call is checkable, not taste:
-- **Scene sentence** — who / where / ambient light / mood, per
+- **Scene sentence:** who / where / ambient light / mood, per
   `../devrites-frontend-craft/reference/design-references.md`. Forces dark-vs-light and
   tone from the scene, not the category.
-- **Color strategy** — Restrained / Committed / Multi-role / Saturated, per the
+- **Color strategy:** Restrained / Committed / Multi-role / Saturated, per the
   color-commitment table in `../devrites-frontend-craft/reference/quality-standards.md`.
   Pick from the scene; register doesn't decide it.
-- **Calibration** — density (Airy / Balanced / Dense) and motion (Minimal / Standard /
+- **Calibration:** density (Airy / Balanced / Dense) and motion (Minimal / Standard /
   Expressive), per the calibration table in the same quality-standards file. Set both from
   the scene so the build targets a calibration, not a guess (a 2am SRE → Dense + Minimal; a
   launch hero → Airy + Expressive).
-- **Named anchor references** — 2-3 *specific* products / brands / objects to steer toward
+- **Named anchor references:** 2-3 *specific* products / brands / objects to steer toward
   (not adjectives like "modern" or "clean"), plus the saved `references/` files.
-- **Visual thesis** — the focal point and hierarchy in one sentence, plus one memorable
+- **Visual thesis:** the focal point and hierarchy in one sentence, plus one memorable
   move (or `none — system continuity`) and the obvious-but-wrong direction rejected. This
   creates intentional distinction without forcing novelty into product UI.
 
 Respect the existing identity (default, ~90%); depart only on an explicit signal.
 
-## 4. Scope — task-scoped, never persisted
+## 4. Scope: task-scoped, never persisted
 Name the output target so sketch-vs-ship isn't guessed: **fidelity** (sketch / mid-fi /
-high-fi / production — DevRites default is production), **breadth** (one screen / a flow /
+high-fi / production. DevRites default is production), **breadth** (one screen / a flow /
 a surface), **interactivity**, **time intent**. These ride in the brief only; they do not
 change the project's design system, and never get written to `PRODUCT.md` / `DESIGN.md`.
 
@@ -91,33 +91,33 @@ List every state the feature needs and what the user must see/feel in each (defa
 loading initial+subsequent, empty→next-action, error→recovery, success, disabled/
 no-permission, long-content/overflow), the information hierarchy (what's seen 1st / 2nd /
 3rd; primary action unmistakable), responsive reflow, a11y must-haves, and the interaction
-model (inline vs navigated vs — rarely — modal; optimistic vs pending; feedback). Name the
+model (inline vs navigated vs (rarely) modal; optimistic vs pending; feedback). Name the
 representative states, viewports, input modes, and target R-ids that will prove the result;
 "looks polished" is not a proof target. Canonical state list:
 `../devrites-frontend-craft/reference/shape.md`.
 
-## 6. Visual-direction probe — capability-gated
+## 6. Visual-direction probe: capability-gated
 When the work is net-new or directionally ambiguous and fidelity ≥ mid-fi, pressure-test
-the lane with something concrete instead of words — pull Figma context, generate image
+the lane with something concrete instead of words: pull Figma context, generate image
 probes, screenshot reference sites, or route a code-fidelity question to `$rite-prototype`.
 **Capability-gated**: announce the skip in one line if no tool is available. Flow:
 [reference/visual-direction-probe.md](reference/visual-direction-probe.md).
 
 ## 7. AI-slop pre-check
 Run the two-altitude category-reflex check (`../rite-polish/reference/anti-ai-slop.md`) on
-the chosen direction *before* writing the brief — if the palette/theme is guessable from
+the chosen direction *before* writing the brief, if the palette/theme is guessable from
 the category, rework the scene sentence and color strategy. Cheaper to catch the slop in
 the brief than in the build.
 
 ## 8. Write the brief + gate
-Write `design-brief.md` ([reference/brief-template.md](reference/brief-template.md)) —
+Write `design-brief.md` ([reference/brief-template.md](reference/brief-template.md)):
 **compact** (3-5 bullets) when discovery was crisp, **full** when the surface is ambiguous
 or multi-screen. Don't pad a clear brief to look thorough; don't skip the pause to look
 fast. Then honor the run mode (`../devrites-lib/reference/standards/afk-hitl.md`):
-- **HITL** — present the brief and **STOP for explicit confirmation**. The pause is the
+- **HITL:** present the brief and **STOP for explicit confirmation**. The pause is the
   point: shape ends at the user's "go", not at your own certainty. Disagreement → revisit
   the relevant discovery question.
-- **AFK** — assert the best-guess direction, record it in `decisions.md` + an advisory
+- **AFK:** assert the best-guess direction, record it in `decisions.md` + an advisory
   `questions.md` entry, and proceed. A direction touching the irreversible-risk list still
   pauses.
 
@@ -136,11 +136,11 @@ Next: $rite-define (UI slices map to the brief's states) — or $rite-build refi
 ```
 
 ## NEVER (ux-shape)
-- Never write code, markup, or a component here — produce the thinking, not the UI.
+- Never write code, markup, or a component here: produce the thinking, not the UI.
 - Never finalize the brief without naming the **primary action** and the **full state set**
   (not just the happy path).
-- Never decide visual direction by taste when the project has a system — discover first.
-- Never treat an **inspiration** reference as a fidelity target — honor its recorded role.
-- Never skip the HITL confirmation pause "because the brief is obviously right" — ask once,
+- Never decide visual direction by taste when the project has a system: discover first.
+- Never treat an **inspiration** reference as a fidelity target: honor its recorded role.
+- Never skip the HITL confirmation pause "because the brief is obviously right": ask once,
   wait.
-- Never re-derive the brief from scratch in `$rite-build` — refine the existing one.
+- Never re-derive the brief from scratch in `$rite-build`: refine the existing one.

package/pack/generated/codex/skills/devrites-ux-shape/reference/brief-template.md

@@ -1,4 +1,4 @@
-# `design-brief.md` template — the UX/UI contract
+# `design-brief.md` template: the UX/UI contract
 
 The feature-level design decision, produced **before** code by `devrites-ux-shape` (at
 `$rite-spec` when UI is detected) and the **target** the build, polish, and seal check
@@ -97,12 +97,12 @@ Genuinely unresolved only. If you'd write "Recommend: X", decide X instead.
 ```
 
 ## How downstream phases use it
-- `$rite-define` — UI slices map to the **Key states**, **Interaction model**, and **Proof
+- `$rite-define`: UI slices map to the **Key states**, **Interaction model**, and **Proof
   targets**; each UI slice names the visual acceptance it proves.
-- `$rite-build` + `devrites-frontend-craft` — build **to** the brief; refine per slice;
+- `$rite-build` + `devrites-frontend-craft`: build **to** the brief; refine per slice;
   append refinements above instead of re-deriving.
-- `$rite-prove` + `browser-evidence.md` — render the proof targets, compare against the
+- `$rite-prove` + `browser-evidence.md`: render the proof targets, compare against the
   brief + target references, and close material deltas.
-- `$rite-polish` — Phase 4 reads the brief so polish honors the agreed direction.
-- `$rite-seal` + `devrites-frontend-reviewer` — check the UI matches the brief (states
+- `$rite-polish`: Phase 4 reads the brief so polish honors the agreed direction.
+- `$rite-seal` + `devrites-frontend-reviewer`: check the UI matches the brief (states
   covered, direction held, references matched).

package/pack/generated/codex/skills/devrites-ux-shape/reference/visual-direction-probe.md

@@ -1,7 +1,7 @@
-# Visual-direction probe — test the lane before the brief locks
+# Visual-direction probe: test the lane before the brief locks
 
 Before finalizing `design-brief.md`, pressure-test the visual direction with something
-concrete instead of words — *when it will actually clarify the brief*. This is the
+concrete instead of words, *when it will clarify the brief*. This is the
 DevRites-native answer to "build it according to the design (Figma, images)": show a
 direction, get a reaction, then write the brief.
 
@@ -9,7 +9,7 @@ direction, get a reaction, then write the brief.
 - The work is **net-new** or directionally **ambiguous**. An existing surface or an
   approved reference classified **target** already fixes the direction → skip.
 - Fidelity is **mid-fi or higher**. Sketch-only planning → skip.
-- A probe tool is actually available (below). **Capability-gated** — never ask the user to
+- A probe tool is available (below). **Capability-gated**: never ask the user to
   install APIs or tooling. If none is available, **announce the skip in one line** and
   proceed to the brief. The one-line announcement is required; it forces a conscious choice
   instead of letting the step quietly evaporate.
@@ -21,10 +21,10 @@ direction, get a reaction, then write the brief.
    silent choice.
 2. **Native image generation available** (Figma Make, an image-gen MCP, computer-use, or
    similar) → generate **2-4 distinct direction probes** from the discovery answers (color
-   strategy, scene sentence, anchors). They must differ in **primary direction** —
-   hierarchy, density, typographic voice, topology — not just palette tweaks. Treat them as
+   strategy, scene sentence, anchors). They must differ in **primary direction**:
+   hierarchy, density, typographic voice, topology, not just palette tweaks. Treat them as
    *direction tests*, not final UI.
-3. **A code-fidelity question** ("which of these layouts actually works in our stack") →
+3. **A code-fidelity question** ("which of these layouts works in our stack") →
    route to **`$rite-prototype`** (2-4 real UI variations on one throwaway route). Prototype
    is DevRites' existing tool for this; don't rebuild it here.
 4. **Reference sites / links only** → screenshot them (`devrites-browser-proof` tooling)
@@ -35,14 +35,14 @@ direction, get a reaction, then write the brief.
 - Ask which direction feels closest, what's off, what carries forward. Don't treat
   generated imagery as final UX, copy, or accessibility behavior.
 - If the probe reveals a mismatch, revise the **discovery inputs** (scene sentence, color
-  strategy, anchors) *before* writing the brief — that's the whole point of probing.
+  strategy, anchors) *before* writing the brief. That's the whole point of probing.
 - Save probe artifacts (generated images, Figma exports, screenshots) into
   `.devrites/work/<slug>/references/`, index them in `references.md` with what each shows,
   and note the winning direction in the brief's **Visual-direction probe** section.
 
 ## Limits
 - Don't skip discovery because image generation is available.
-- Don't run a probe for a minor refinement of existing work — it's for shaping a new
+- Don't run a probe for a minor refinement of existing work. It's for shaping a new
   surface or a big directional choice.
-- Don't block the brief on a slow or failing tool — try once, then skip with the one-line
+- Don't block the brief on a slow or failing tool: try once, then skip with the one-line
   note.

package/pack/generated/codex/skills/rite/SKILL.md

@@ -12,17 +12,17 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here — Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review** — an inline pass shares the calling context and is weaker evidence.
+- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
+- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
 - Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
-- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers — NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
+- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
-# $rite — DevRites menu + router
+# $rite: DevRites menu + router
 
 You are the DevRites entry point. Two modes:
 
-- **No args** → run `devrites-engine first-task`, render one recommended-start line above the menu, then stop. Do not execute a phase or read `state.md` — status is `$rite-status`.
+- **No args** → run `devrites-engine first-task`, render one recommended-start line above the menu, then stop. Do not execute a phase or read `state.md`: status is `$rite-status`.
 - **Verb arg** → pass-through dispatch to the matching `rite-<verb>` skill (`$rite spec foo` ≡ `$rite-spec foo`); the called skill owns the output.
 
 When the user asks which rite fits, load [`devrites-lib/reference/intent-map.md`](../devrites-lib/reference/intent-map.md).
@@ -75,19 +75,17 @@ What each verb does lives once, in the Menu below; this table is the dispatch ma
 | `quick [change]` | `$rite-quick` |
 | `frame [task]` | `$rite-frame` |
 
-Both forms hit the same skill — the menu form for discovery, the `/rite-<verb>` shortcut for muscle memory.
+Both forms hit the same skill: the menu form for discovery, the `/rite-<verb>` shortcut for muscle memory.
 
-`use <slug>` is handled **inline** — there is no `rite-use` skill. Confirm
+`use <slug>` is handled **inline**. There is no `rite-use` skill. Confirm
 `.devrites/work/<slug>/` exists, then re-point `.devrites/ACTIVE` to `<slug>` and report
-the now-active feature. It is cheap context-switching only — no re-spec, no phase run. If
+the now-active feature. It is cheap context-switching only: no re-spec, no phase run. If
 the workspace is missing, list the slugs under `.devrites/work/` and stop.
 
-`guide` is also inline — a first-feature walkthrough that teaches the lifecycle by running
-it. Agree on one **real, genuinely small** change, then dispatch the normal phases in order
-(spec → define → build → prove → seal → ship). Per phase, exactly two narration beats:
-before, what it will decide; after, what it wrote in `.devrites/work/<slug>/` and why. Walk
-every phase — the small change is what makes the full ceremony affordable to watch. Pause
-at each boundary for the user's go-ahead. Teach without lecturing.
+`guide` is an inline first-feature walkthrough. Agree on one **real, genuinely small**
+change, then run spec → temper → define → vet → build → prove → polish → review → seal →
+ship. Before each phase, say what it decides; after, name what it wrote and why. Pause at
+every boundary. Teach without lecturing.
 
 Specialist triggers (model-invoked inside the above):
 `devrites-frontend-craft` (UI) · `devrites-browser-proof` (UI verify) ·
@@ -106,7 +104,7 @@ Called phase skills own the shared completion reply contract
 1. **Verb in `$ARGUMENTS`** → dispatch per the table above.
 2. **No args** → menu mode, as above.
 3. **Unrecognized first token** → tell the user the known verbs and stop. Don't guess.
-4. **No active feature** and the user asked "where am I" or named no verb → point at `$rite spec <feature>` (or `$rite-spec`). Don't summarize state yourself — `$rite status` (or `$rite-status`) owns that.
+4. **No active feature** and the user asked "where am I" or named no verb → point at `$rite spec <feature>` (or `$rite-spec`). Don't summarize state yourself: `$rite status` (or `$rite-status`) owns that.
 
 ## Menu
 
@@ -118,9 +116,10 @@ SPEC          $rite spec               ≡    $rite-spec        investigate deep
 ADOPT         $rite adopt              ≡    $rite-adopt       onboard existing code → reverse-derive spec.md + seed conventions
 TEMPER        $rite temper             ≡    $rite-temper      optional — strategic review: scope mode + pre-mortem, harden the spec
 PLAN          $rite define             ≡    $rite-define      turn the spec into plan + task slices + state
-VET           $rite vet                ≡    $rite-vet         optional — engineering plan review: scope · architecture · tests · perf, harden the plan
+VET           $rite vet                ≡    $rite-vet         mandatory every plan — light/full engineering review by stakes
 REPLAN        $rite plan               ≡    $rite-plan        decompose / reslice / repair an active plan
 BUILD         $rite build              ≡    $rite-build       implement exactly one verified vertical slice, then stop
+CONVERGE      $rite converge           ≡    $rite-converge    recovery — append work needed to meet intent
 PROVE         $rite prove              ≡    $rite-prove       tests + build + runtime + browser evidence
 POLISH        $rite polish             ≡    $rite-polish      code polish always; UI normalize + polish if UI
 REVIEW        $rite review             ≡    $rite-review      feature-scoped multi-axis review
@@ -145,7 +144,7 @@ UTILITY       $rite frame | prototype | handoff | zoom-out | pressure-test  (or
 > **Small one-off change?** A typo, copy tweak, config bump, or one-function fix → **`$rite-quick`**
 > (express lane: one contract → build → prove → ship, no full workspace). It escalates to
 > `$rite-spec` the instant the change grows past small / reversible / unambiguous. The full
-> lifecycle above is for real features — don't pay its ceremony for a one-off.
+> lifecycle above is for real features: don't pay its ceremony for a one-off.
 
 ## Core operating rules (every DevRites skill enforces)
 

package/pack/generated/codex/skills/rite/reference/menu.md

@@ -7,30 +7,30 @@ what each command does or how phases connect.
 
 | Phase | Command | Use when |
 |---|---|---|
-| Spec | `$rite-spec <feature>` | **Start here.** Investigate deeply → write spec.md. Asks you with options; gathers any design references you attach (optional). |
-| Adopt | `$rite-adopt` | Onboard an existing codebase instead of starting fresh — reverse-derive spec.md + seed the conventions ledger. |
-| Temper | `$rite-temper` | _Optional, before define._ Strategic review of the spec — scope mode (expand/selective/hold-rigor/reduce) + pre-mortem; hardens the spec. Best on big/risky features; mandatory in `$rite-autocomplete`. |
+| Spec | `$rite-spec <feature>` | **New feature.** Investigate deeply → write spec.md. Asks with options; gathers attached design references (optional). |
+| Adopt | `$rite-adopt` | Onboard an existing codebase instead of starting fresh: reverse-derive spec.md + seed the conventions ledger. |
+| Temper | `$rite-temper` | _Optional, before define._ Strategic review of the spec: scope mode (expand/selective/hold-rigor/reduce) + pre-mortem; hardens the spec. Best on big/risky features; mandatory in `$rite-autocomplete`. |
 | Plan | `$rite-define` | Turn the approved spec into plan + vertical task slices + state. |
-| Vet | `$rite-vet` | _Optional, before build._ Engineering review of the plan — scope · architecture · tests · perf; hardens the plan. Best on big/risky features; mandatory in `$rite-autocomplete`. |
+| Vet | `$rite-vet` | _Required before build._ Review every plan: scope · architecture · tests · perf; light for simple/reversible, full for high stakes. |
 | Re-plan | `$rite-plan` | The active plan is too big, wrong, stale, ambiguous, or blocked. |
 | Build | `$rite-build` | Implement the next single vertical slice. Stops after one slice. |
-| Converge | `$rite-converge` | _Recovery._ Code drifted from / falls short of intent (resumed cold, adopted, stalled build) — assess live code vs spec/plan/tasks and append the remaining work as new slices for `$rite-build`. |
+| Converge | `$rite-converge` | _Recovery._ Code drifted from / falls short of intent (resumed cold, adopted, stalled build): assess live code vs spec/plan/tasks and append the remaining work as new slices for `$rite-build`. |
 | Prove | `$rite-prove` | Prove the current scope: tests, build, runtime, browser evidence. |
 | Polish | `$rite-polish` | Code polish always; UI normalize + ship-quality polish if UI is in scope. Modes: `bolder/quieter/distill/harden/normalize-only`. |
 | Review | `$rite-review` | Feature-scoped review before sealing. |
 | Seal | `$rite-seal` | Final GO / NO-GO decision (no git). |
 | Ship | `$rite-ship` | Type-GO → commit/push/tag, then archive the task + clear ACTIVE. |
 | Status | `$rite-status` | See where the active feature stands. |
-| Doctor | `$rite-doctor` | Health check — install integrity, stale ACTIVE, orphaned gates, hook wiring, merge/rebase state. |
+| Doctor | `$rite-doctor` | Health check: install integrity, stale ACTIVE, orphaned gates, hook wiring, merge/rebase state. |
 | Learn | `$rite-learn` | Review the captured learning ledger → promote recurring lessons to project rules / principles. |
 
 ## Typical orderings
 
-- **Every feature**: `$rite-spec` (spec) → *(big feature? `$rite-temper` — strategic review)* →
-  `$rite-define` (plan) → *(big feature? `$rite-vet` — engineering review)* →
+- **Every feature**: `$rite-spec` (spec) → *(big feature? `$rite-temper`: strategic review)* →
+  `$rite-define` (plan) → `$rite-vet` (engineering review; light or full) →
   `$rite-build` ×N (all slices) → `$rite-prove` (once all built) →
   `$rite-polish` (always: code + UI if UI) → `$rite-review` → `$rite-seal` → `$rite-ship`.
-- **Existing codebase**: `$rite-adopt` (onboard → spec.md + conventions) → continue at `$rite-define`.
+- **Existing codebase**: `$rite-adopt` → `$rite-define` → `$rite-vet` → build.
 - **Drift mid-build**: stop → drift question → `$rite-plan` (repair) → resume build.
 - **Resumed / adopted / stalled**: `$rite-converge` (assess live code vs intent → append the
   remaining slices) → `$rite-build` ×N → continue at `$rite-prove`.
@@ -38,5 +38,5 @@ what each command does or how phases connect.
 ## Rules this menu obeys
 
 - `$rite` never edits code or runs a phase workflow.
-- It reads `.devrites/ACTIVE` and `state.md` for status only.
+- Menu mode runs `devrites-engine first-task`; `$rite-status` owns workspace status.
 - It suggests; the user (or Claude, when appropriate) invokes the real skill.

package/pack/generated/codex/skills/rite-adopt/SKILL.md

@@ -11,13 +11,13 @@ This is the Codex mirror of a DevRites skill. In Codex:
 
 - Load DevRites engineering standards from `.agents/skills/devrites-lib/reference/standards/`. Read `.agents/skills/devrites-lib/reference/standards/core.md` before workflow work, then load the other `.agents/skills/devrites-lib/reference/standards/*.md` files exactly when this skill asks for them.
 - Use the installed `devrites-engine` binary as the canonical runtime helper surface for orientation, gates, and state mutation.
-- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here — Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
-- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review** — an inline pass shares the calling context and is weaker evidence.
+- When this skill asks for a DevRites specialist or writer agent, **explicitly** spawn the matching Codex custom agent from `.codex/agents/devrites-*.toml` through Codex subagents (`spawn_agent`), then wait for its result and reconcile it as the skill instructs. Do not do the review inline just because the instruction to spawn is embedded here: Codex under-fires embedded spawn/skill instructions (openai/codex #23496), so treat the spawn as required, not optional.
+- The independence of a fresh-context subagent is the point. If Codex genuinely cannot spawn subagents in the current surface, run the documented inline fallback and **label the result an inline fallback, not an independent review**: an inline pass shares the calling context and is weaker evidence.
 - Codex project hooks are installed in `.codex/hooks.json`. Review and trust them with `/hooks` before relying on hook enforcement.
-- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers — NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
+- When this skill asks a HITL question via `AskUserQuestion`: Codex's equivalent (`request_user_input`) exists only in Plan mode. Outside Plan mode, render the option set as a plain numbered list in chat and **end the turn** so the human answers: NEVER silently pick an option yourself; auto-picking is AFK's contract, gated by the `.devrites/AFK` sentinel.
 
 
-# $rite-adopt — brownfield on-ramp
+# $rite-adopt: brownfield on-ramp
 
 The **reverse** of `$rite-spec`. `$rite-spec` goes idea → spec; `$rite-adopt` goes
 **existing code → spec + seeded conventions**, so an already-built project can enter the
@@ -45,14 +45,14 @@ upholds invariants worth proposing as project principles (step 4a).
 ## Workflow
 0. **Read `.agents/skills/devrites-lib/reference/standards/core.md`**, then run
    `devrites-engine preamble` for deterministic workspace orientation.
-1. **Scope the adoption** (`$ARGUMENTS`). Which repo or sub-area is being onboarded, and —
-   if stated — what the user wants to build *next* on top of it. If the next-build objective
+1. **Scope the adoption** (`$ARGUMENTS`). Which repo or sub-area is being onboarded, and:
+   if stated: what the user wants to build *next* on top of it. If the next-build objective
    is missing, ask once (it shapes the spec's acceptance); if the area is ambiguous, confirm
    before investigating the whole tree.
-2. **Reverse-investigate the existing code** — the durable shape of the project. Use a
-   code-intelligence index if available — codebase-memory-mcp first (its `get_architecture`
+2. **Reverse-investigate the existing code:** the durable shape of the project. Use a
+   code-intelligence index if available (codebase-memory-mcp first (its `get_architecture`
    gives a fast overview), cross-checked with codegraph + graphify, else standard methods
-   (LSP / Read/Grep/Glob); see `.agents/skills/devrites-lib/reference/standards/tooling.md` — for
+   (LSP / Read/Grep/Glob); see `.agents/skills/devrites-lib/reference/standards/tooling.md`) for
    structure, callers, and impact. Capture, per [adoption](reference/adoption.md): **current
    behavior**, **architecture + placement** (layers, seams, where each kind of thing lives),
    the **commands** (test / build / typecheck / lint), and the **idioms** (naming, layering,
@@ -67,7 +67,7 @@ upholds invariants worth proposing as project principles (step 4a).
 3a. **Seed the capability ledger** from the baseline. If the reverse-derived `spec.md` carries
    structured `### Requirement:` blocks, fold them into the living
    `.devrites/specs/<capability>/spec.md` ledger so the project's *current* proven behavior is on
-   record before the first new feature — the ledger the next `$rite-spec` writes deltas against
+   record before the first new feature: the ledger the next `$rite-spec` writes deltas against
    ([ledger.md](../rite-ship/reference/ledger.md)). A flat baseline folds as all-ADDED into the
    feature slug's capability; tag capabilities in the spec first if you want finer granularity.
    ```bash
@@ -75,34 +75,33 @@ upholds invariants worth proposing as project principles (step 4a).
    devrites-engine ledger sync .devrites/work/<slug>   # seed
    ```
    Skip when the baseline records no structured requirements (nothing to seed).
-4. **Seed the conventions ledger** from what the investigation *observed* —
+4. **Seed the conventions ledger** from what the investigation *observed*:
    [adoption § seeding](reference/adoption.md). This is the deliberate bootstrap exception to
    evidence-gated promotion: the seeds start at the base band and are provenance-tagged as
    onboarding observations, not sealed-slice proofs, so real slices later corroborate or
    (fresh-wins) contradict them.
    **Completion:** every seed names observed evidence, provenance, and the base band.
 4a. **Propose candidate principles** (human-ratified; optional). Where the investigation found an
-   invariant the code *consistently and deliberately* upholds — money always in integer cents, PII
-   always redacted from logs, every v1 endpoint preserved — surface it as a **candidate
+   invariant the code *consistently and deliberately* upholds (money always in integer cents, PII
+   always redacted from logs, every v1 endpoint preserved) surface it as a **candidate
    principle**, not a seeded convention. Principles are prescriptive and gating, so they are
    **ratified by the human, never auto-seeded** the way conventions are: present the candidates via
    `AskUserQuestion` with the evidence (where the code upholds it), and write the ones the human
    ratifies to `.devrites/principles.md` with a dated Governance entry
-   ([`principles.md`](../devrites-lib/reference/standards/principles.md)). Propose, don't impose — an unratified candidate
-   stays a convention, not a gate. Skip cleanly when nothing rises to an invariant (common — a
+   ([`principles.md`](../devrites-lib/reference/standards/principles.md)). Propose, don't impose: an unratified candidate
+   stays a convention, not a gate. Skip cleanly when nothing rises to an invariant (common: a
    fresh adopt may declare zero principles, and that's valid).
-5. **Hand off.** The project is now in the lifecycle with a spec and a head-start ledger.
-   Point the user at `$rite-temper` (big/risky) or `$rite-define` (straightforward) — do not
-   plan or build here.
+5. **Hand off.** Spec and ledger are ready. Next: `$rite-temper` if big/risky,
+   else `$rite-define`; every plan then runs `$rite-vet` before build. Do not plan/build here.
    **Completion:** one next rite is reported and no plan or application code was written.
 
-> **Mid-flight discipline.** Don't invent conventions the code doesn't actually follow, don't
-> seed an idiom you only assumed, and don't expand scope into a rewrite — adoption documents
+> **Mid-flight discipline.** Don't invent conventions the code doesn't follow, don't
+> seed an idiom you only assumed, and don't expand scope into a rewrite: adoption documents
 > what exists; the *next* feature changes it. See [`anti-patterns`](reference/anti-patterns.md).
 
 ## 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/generated/codex/skills/rite-adopt/reference/adoption.md

@@ -1,22 +1,22 @@
-# Adoption — reverse-investigate + seed (the on-ramp contract)
+# Adoption: reverse-investigate + seed (the on-ramp contract)
 
 Loaded on demand by `$rite-adopt`. Two jobs: document what the code already does (so the
 lifecycle has a spec), and seed the conventions ledger (so the first slice knows the idioms).
 
-## Reverse-investigation — what to capture
+## Reverse-investigation: what to capture
 
 Document the **durable shape** of the project, not a line-by-line tour:
 
-- **Current behavior** — what the adopted area does today, from the user's perspective.
-- **Architecture + placement** — the layers and seams; where each kind of thing lives
+- **Current behavior:** what the adopted area does today, from the user's perspective.
+- **Architecture + placement:** the layers and seams; where each kind of thing lives
   (where endpoints / components / models / migrations / tests go). Prefer a code-intelligence
   index if available (see `../../devrites-lib/reference/standards/tooling.md`) for
   structure, callers, and impact.
-- **Commands** — the real test / build / typecheck / lint commands (run or read them; don't
+- **Commands:** the real test / build / typecheck / lint commands (run or read them; don't
   guess). Verify uncertain framework facts at the source.
-- **Idioms** — naming + casing, layering, the error model, the result/exception style, the
+- **Idioms:** naming + casing, layering, the error model, the result/exception style, the
   http/data-access pattern, the test framework + file layout.
-- **Gotchas** — non-obvious constraints the code encodes (ordering requirements, "don't call
+- **Gotchas:** non-obvious constraints the code encodes (ordering requirements, "don't call
   X before Y", a framework quirk).
 
 This feeds `spec.md` (current behavior as the baseline + the next objective) and the ledger
@@ -28,7 +28,7 @@ The deliberate **bootstrap exception** to evidence-gated promotion. Normally a c
 promoted only when a *sealed slice proved it* (`$rite-seal`); adoption seeds from **observed
 existing code** so the first slice isn't blind. Keep the seeds honest:
 
-- Seed only what the code **actually and consistently** follows — not an aspiration, not a
+- Seed only what the code **and consistently** follows, not an aspiration, not a
   one-off, not something you assumed.
 - Each seed starts at the base band (one corroboration) and is provenance-tagged as an
   onboarding observation, **not** a sealed-slice proof. Real slices later corroborate it
@@ -51,5 +51,5 @@ fi
 The `-adopt` suffix on the slug marks the provenance as onboarding. Because the ledger is
 read at orient as a *prior* and the live code always overrides it
 ([`.agents/skills/devrites-lib/reference/standards/security.md`](../../devrites-lib/reference/standards/security.md) § Prompt-injection resistance),
-an over-eager seed is self-correcting — but seed conservatively anyway; a wrong seed costs a
+an over-eager seed is self-correcting, but seed conservatively anyway; a wrong seed costs a
 needless contradiction later.