devrites 1.19.0

package/pack/.claude/skills/devrites-ux-shape/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: devrites-ux-shape
+description: Plan the UX/UI before any code — produce the feature-level `design-brief.md` (design direction, key states, interaction model, visual-direction probe) the build then targets. Use when `/rite-spec` detects UI, or the user says "shape the UX", "plan the UI before coding", "design direction", "what should this look like", or a UI feature needs its look & flow decided up front. Woven into spec/build, not a separate phase. Not for building (use `devrites-frontend-craft`), polishing a built UI (use `/rite-polish`), or throwaway exploration (use `/rite-prototype`).
+user-invocable: false
+---
+
+# 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`),
+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
+separate phase the user runs.
+
+## When it runs
+- `/rite-spec` invokes it after references-intake when the feature touches UI
+  (`../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.
+- Skip entirely for backend / data / CLI / infra-only features.
+
+## 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.
+  `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
+  supplied. When present they are the **build target**, not inspiration.
+
+## 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
+  media/assets the surface needs.
+- **Anti-goals** — what this must NOT be; the biggest risk of getting it wrong.
+
+## 3. Design direction — the direction set (commit, don't hedge)
+One deliberate visual decision on four fronts, each anchored in an existing reference so
+the call is checkable, not taste:
+- **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-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 /
+  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
+  (not adjectives like "modern" or "clean"), plus the saved `references/` files.
+
+Respect the existing identity (default, ~90%); depart only on an explicit signal.
+
+## 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 /
+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`.
+
+## 5. Key states + interaction model
+List every state the feature needs and what the user must see/feel in each (default,
+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). Canonical
+state list: `../devrites-frontend-craft/reference/shape.md`.
+
+## 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
+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 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)) —
+**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 (`../../rules/afk-hitl.md`):
+- **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
+  `questions.md` entry, and proceed. A direction touching the irreversible-risk list still
+  pauses.
+
+## Output
+```
+UX/UI shaped: <slug>
+Direction: <color strategy> · density <airy|balanced|dense>/motion <minimal|standard|expressive> · "<scene sentence>" · anchors: <ref A, ref B>
+States: <n listed>   Probe: <figma | images | prototype | skipped — no tool>
+Brief: design-brief.md (<compact | full>)
+Gate: <confirmed | awaiting confirmation | AFK-asserted>
+Next: /rite-define (UI slices map to the brief's states) — or /rite-build refines it per slice
+```
+
+## NEVER (ux-shape)
+- 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 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.

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

@@ -0,0 +1,93 @@
+# `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
+against. `devrites-frontend-craft` refines it per slice and appends build-time decisions;
+it is never re-derived from scratch.
+
+Pick the shape by how clear the answers are. **Compact** is the default for a crisp prompt;
+**full** when the surface is ambiguous, multi-screen, or the user asked to shape it as a
+step. Don't pad a clear brief into a long one to look thorough.
+
+## Compact form (default)
+```markdown
+# Design brief: <feature>
+Slug: <kebab>   Shaped: <iso>   Register: brand | product   Fidelity: <sketch|mid-fi|high-fi|production>
+
+- **Building**: <one line — what + who it's for + the primary action>
+- **Direction**: <color strategy> · density <airy|balanced|dense>/motion <minimal|standard|expressive> · "<scene sentence>" · anchors: <ref A, ref B>  (+ references/<file> R-ids)
+- **States**: <the states this surface needs, comma-listed>
+- **Interaction**: <inline / navigated / modal · feedback · entry→completion in a phrase>
+- **Confirm or override?** <the one or two things you still want the user to confirm>
+```
+
+## Full form
+```markdown
+# Design brief: <feature>
+Slug: <kebab>   Shaped: <iso>   Register: brand | product
+
+## 1. Summary
+What this is, who it's for, what it must accomplish (2-3 sentences).
+
+## 2. Primary action
+The single most important thing the user does or understands here. Everything else is secondary.
+
+## 3. Design direction
+- Color strategy: Restrained | Committed | Multi-role | Saturated — why (from the scene, not the category).
+- Calibration: density Airy | Balanced | Dense · motion Minimal | Standard | Expressive — from the scene (`../../devrites-frontend-craft/reference/quality-standards.md` — Calibration).
+- Scene sentence: "<who uses it, where, under what light, in what mood>".
+- Named anchors: <2-3 specific products / brands / objects> + saved references (R-ids → references/<file>).
+- Departure: default (preserve identity) | departing because <explicit signal>.
+
+## 4. Scope  *(task-scoped — not persisted to PRODUCT.md / DESIGN.md)*
+Fidelity · breadth · interactivity · time intent.
+
+## 5. Layout & hierarchy
+What gets emphasis; what's seen 1st / 2nd / 3rd; how information flows. Hierarchy, not CSS.
+
+## 6. Key states
+Every state + what the user needs to see and feel:
+| State | User sees / feels | Notes |
+|---|---|---|
+| default / populated | | |
+| loading | | initial + subsequent |
+| empty | | welcoming + the next action |
+| error | | what happened + how to recover |
+| success | | |
+| disabled / no-permission | | |
+| long-content / overflow / many items | | |
+
+## 7. Interaction model
+Inline vs navigated vs (rarely) modal; optimistic vs pending; focus & keyboard; feedback on
+every action; the flow from entry to completion.
+
+## 8. Content & copy
+Labels, empty/error messages, microcopy in the product's voice. Realistic dynamic ranges.
+For image-led surfaces: required media roles + likely source (project asset / generated /
+SVG-CSS / icon library / accepted omission).
+
+## 9. Responsive & a11y
+Reflow 320→1440 (what stacks / collapses / scrolls); focus order, labels, contrast,
+keyboard, target size. Floor: `../../devrites-frontend-craft/reference/quality-standards.md`.
+
+## 10. Visual-direction probe
+Which probe ran (figma / images / prototype / skipped — no tool), which direction won, what
+changed in the brief because of it. Artifacts saved under `references/`.
+
+## 11. Open questions
+Genuinely unresolved only. If you'd write "Recommend: X", decide X instead.
+
+## Build-time refinements  *(appended by devrites-frontend-craft per slice)*
+- Slice <N>: <decision made while building this surface + why>.
+```
+
+## How downstream phases use it
+- `/rite-define` — UI slices map to the **Key states** + **Interaction model**; each UI
+  slice names which states it covers.
+- `/rite-build` + `devrites-frontend-craft` — build **to** the brief; refine per slice;
+  append refinements above instead of re-deriving.
+- `/rite-prove` + `browser-evidence.md` — verify the built UI against the brief's states +
+  references.
+- `/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/.claude/skills/devrites-ux-shape/reference/visual-direction-probe.md

@@ -0,0 +1,48 @@
+# 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
+DevRites-native answer to "build it according to the design (Figma, images)": show a
+direction, get a reaction, then write the brief.
+
+## When to run (all true)
+- The work is **net-new** or directionally **ambiguous**. An existing surface to match →
+  skip; the supplied references already ARE the target.
+- Fidelity is **mid-fi or higher**. Sketch-only planning → skip.
+- A probe tool is actually 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.
+
+## Pick the probe by what's available (first match)
+1. **Figma reference supplied** → pull design context with the Figma integration (frames,
+   tokens, components, a screenshot of the target). Record what it dictates. A Figma frame
+   that conflicts with the project's design system is a **question for the user**, not a
+   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
+   *direction tests*, not final UI.
+3. **A code-fidelity question** ("which of these layouts actually 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)
+   and read the relevant intent (tone, density, interaction).
+5. **Nothing available** → one-line skip, proceed.
+
+## How to use the result
+- 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.
+- 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
+  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
+  note.

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

@@ -0,0 +1,135 @@
+---
+name: rite
+description: DevRites menu + router. Without args, renders the menu. With a verb (e.g. `spec`, `build`, `review`), dispatches to the matching `rite-<verb>` skill — `/rite spec foo` is equivalent to `/rite-spec foo`. Use when the user types `/rite` or names a phase verb.
+argument-hint: "[verb [args...]]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# /rite — DevRites menu + router
+
+You are the DevRites entry point. Two modes:
+
+- **No args** → render the menu (below), then stop. Do not execute a workflow phase. Do not read `state.md` / run evidence checks / list artifacts — that's `/rite-status`.
+- **Verb arg** → dispatch to the matching `rite-<verb>` skill (see "Dispatch" below). The router is a pass-through: `/rite spec foo` ≡ `/rite-spec foo`; the called skill owns the output.
+
+## Dispatch
+
+If `$ARGUMENTS` starts with a verb in this table, **load the matching skill and execute its workflow** with the remainder of `$ARGUMENTS` as that skill's argument. Try post-install path first, fall back to pre-install:
+
+```bash
+V=<verb>; ARGS="<remaining args>"
+F=.claude/skills/rite-$V/SKILL.md
+[ -f "$F" ] || F=pack/.claude/skills/rite-$V/SKILL.md
+# Then Read "$F" and follow its workflow with $ARGS as that skill's $ARGUMENTS.
+```
+
+| Verb | Equivalent shortcut | Skill |
+|---|---|---|
+| `spec [feature]` | `/rite-spec` | start a feature — investigate + write spec.md |
+| `adopt [area]` | `/rite-adopt` | onboard an existing codebase — reverse-derive spec.md + seed conventions |
+| `temper [--mode]` | `/rite-temper` | optional strategic spec review (scope mode + pre-mortem) before define |
+| `define` | `/rite-define` | turn the spec into plan + task slices |
+| `vet [--cross-model]` | `/rite-vet` | optional engineering plan review (scope · architecture · tests · perf) before build |
+| `plan [mode]` | `/rite-plan` | reshape / reslice / repair an active plan |
+| `build [slice]` | `/rite-build` | implement exactly one vertical slice, then stop |
+| `prove` | `/rite-prove` | full tests + browser proof |
+| `polish [mode]` | `/rite-polish` | code + UI polish |
+| `review [scope]` | `/rite-review` | multi-axis feature review |
+| `seal` | `/rite-seal` | final GO / NO-GO decision |
+| `ship` | `/rite-ship` | type-GO + commit/push/tag, then archive the task |
+| `status [slug]` | `/rite-status` | active feature, next action, evidence |
+| `doctor` | `/rite-doctor` | health check — install integrity, stale ACTIVE, orphaned gates, hook wiring |
+| `use <slug>` | (inline) | switch the active feature — re-point `.devrites/ACTIVE` |
+| `resolve <qid> "<answer>"` | `/rite-resolve` | answer a HITL gate |
+| `prototype [question]` | `/rite-prototype` | throwaway prototype |
+| `handoff [focus]` | `/rite-handoff` | compact chat → handoff doc |
+| `zoom-out` | `/rite-zoom-out` | structural map of unfamiliar code |
+| `pressure-test` | `/rite-pressure-test` | diverge → converge on a rough idea |
+| `autocomplete [idea] [--ship]` | `/rite-autocomplete` | run the whole lifecycle unattended |
+| `quick [change]` | `/rite-quick` | express lane — one small reversible change, build → prove → ship |
+| `frame [task]` | `/rite-frame` | pre-flight goal-reframe + four-failure-mode self-audit for ad-hoc / express work |
+
+The `/rite-<verb>` standalones remain user-invocable as direct shortcuts; both forms hit the same skill. Use whichever reads more naturally — the menu form (`/rite spec`) for discovery, the shortcut (`/rite-spec`) for muscle memory.
+
+`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 workspace is missing, list the slugs under `.devrites/work/` and stop.
+
+Specialist triggers (model-invoked inside the above):
+`devrites-frontend-craft` (UI) · `devrites-browser-proof` (UI verify) ·
+`devrites-source-driven` (uncertain library) · `devrites-doubt` (non-trivial
+decision) · `devrites-api-interface` (cross-boundary) ·
+`devrites-audit <security|perf|simplify>` (single-axis review/polish pass) ·
+`devrites-debug-recovery` (failures). Parallel reviewer fan-out at seal lives
+inline in `/rite-seal` (see its `reference/parallel-dispatch.md`).
+
+## What to output
+
+1. **Verb in `$ARGUMENTS`** → dispatch per the table above. The called skill owns the response.
+2. **No args** → render the menu below, then stop.
+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.
+
+## Gotchas
+- No args → render the menu and stop. Don't execute a phase, read `state.md`, or summarize status — that's `/rite-status`.
+- Unrecognized first token → list the known verbs and stop; never guess which phase the user meant.
+- Pure pass-through: dispatch to the `rite-<verb>` skill and let it own the output; don't do the phase's work in the router.
+
+## Menu
+
+```
+DevRites — disciplined senior-engineer workflow
+                              menu form           direct shortcut
+SPEC          /rite spec               ≡    /rite-spec        investigate deeply → write spec.md
+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
+REPLAN        /rite plan               ≡    /rite-plan        decompose / reslice / repair an active plan
+BUILD         /rite build              ≡    /rite-build       implement exactly one verified vertical slice, then stop
+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
+SEAL          /rite seal               ≡    /rite-seal        final GO / NO-GO decision (no git)
+SHIP          /rite ship               ≡    /rite-ship        type-GO + commit/push/tag, then archive + clear ACTIVE
+STATUS        /rite status             ≡    /rite-status      active feature, next action, evidence, risks
+DOCTOR        /rite doctor             ≡    /rite-doctor      health check — install · stale ACTIVE · orphaned gates · hook wiring
+SWITCH        /rite use <slug>                                re-point .devrites/ACTIVE to another feature (inline)
+RESUME        /rite resolve ...        ≡    /rite-resolve     answer a HITL checkpoint
+AUTO          /rite autocomplete ...   ≡    /rite-autocomplete  run the whole lifecycle unattended (--ship to push)
+QUICK         /rite quick <change>     ≡    /rite-quick       express lane — one small reversible change (escalates if it grows)
+UTILITY       /rite frame | prototype | handoff | zoom-out | pressure-test  (or direct /rite-* shortcuts)
+```
+
+> **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.
+
+## Core operating rules (every DevRites skill enforces)
+
+The minimal version lives in `.claude/rules/core.md`; DevRites skills Read it as
+their first step, and the other rule files load on demand. The rule list:
+
+1. **Right step, right time** — smallest relevant workflow; don't load everything.
+2. **No silent assumptions** — surface material assumptions; ask when the
+   answer changes scope, architecture, data model, UX, security, migration
+   risk, or acceptance.
+3. **No guessing through confusion** — if requirements / code / tests / docs
+   conflict, stop, name the conflict, present options, wait for resolution
+   when the answer changes the product.
+4. **Spec is living, not sacred** — change spec/plan only through the
+   Spec Drift Guard; never code against a known-wrong plan.
+5. **One slice at a time** — `/rite-build` does one slice then stops.
+6. **Evidence over confidence** — tests, builds, runtime, screenshots beat
+   assertions; record commands and output.
+7. **Feature scope only** — review / simplify / polish / security stay within
+   the active feature and touched files.
+8. **Prefer existing conventions** — follow the project's architecture,
+   components, tokens, tests, and commands.
+9. **Verify uncertain facts at the source** — when framework / library
+   behaviour matters and isn't certain, check the docs or source and record it.
+
+Detail in [reference/menu.md](reference/menu.md) when needed.

package/pack/.claude/skills/rite/reference/menu.md

@@ -0,0 +1,32 @@
+# Menu reference
+
+Phase-ordered command reference for `/rite`. Load only if the user wants detail on
+what each command does or how phases connect.
+
+## Phases and commands
+
+| 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). |
+| 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. |
+| 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. |
+| 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. |
+| Status | `/rite-status` | See where the active feature stands. |
+
+## Typical orderings
+
+- **Every feature**: `/rite-spec` (spec) → *(big feature? `/rite-temper` — strategic review)* →
+  `/rite-define` (plan) → `/rite-build` ×N (all slices) → `/rite-prove` (once all built) →
+  `/rite-polish` (always: code + UI if UI) → `/rite-review` → `/rite-seal`.
+- **Drift mid-build**: stop → drift question → `/rite-plan` (repair) → resume build.
+
+## Rules this menu obeys
+
+- `/rite` never edits code or runs a phase workflow.
+- It reads `.devrites/ACTIVE` and `state.md` for status only.
+- It suggests; the user (or Claude, when appropriate) invokes the real skill.

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

@@ -0,0 +1,83 @@
+---
+name: rite-adopt
+description: Bring an EXISTING codebase under DevRites — reverse-derive a `spec.md` of current behavior, placement, and architecture, and seed the project conventions ledger from the idioms the code already follows, then hand off to the lifecycle. Use when the user says "adopt this project", "onboard this codebase", "we already have code", "bring this repo into DevRites", or "reverse-engineer a spec from the existing app". Not for a brand-new feature or idea (use `/rite-spec`), planning an approved spec (`/rite-define`), or just mapping unfamiliar code without onboarding it (`/rite-zoom-out`).
+argument-hint: "[path or area to adopt] [+ what you want to build next]"
+user-invocable: true
+---
+
+# /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
+DevRites lifecycle without hand-writing a spec from nothing. It produces the same
+`spec.md` the rest of the lifecycle expects, plus a head start in the conventions ledger
+so the very first new slice already knows the project's idioms.
+
+Use it once, at the start, to onboard a repo (or a sub-area of one). After it, the normal
+lifecycle (`/rite-temper` → `/rite-define` → `/rite-build` …) takes over.
+
+> **Just want a map, not an onboarding?** `/rite-zoom-out` returns a structural map of
+> unfamiliar code without creating a workspace or ledger. `/rite-adopt` is the heavier move:
+> it *commits the project to the lifecycle*. Pick zoom-out to look, adopt to begin.
+
+## Rules consulted (read on demand from `.claude/rules/`)
+**Step 0:** Read `.claude/rules/core.md` first. Pull `documentation.md` when recording
+the adoption decisions (why-not-what) in `decisions.md`.
+
+## Operating rules (DevRites core)
+- No silent assumptions · prefer the project's existing conventions (you are *documenting*
+  them, not imposing new ones) · ask the human when the adoption scope or the next-build
+  objective is unclear.
+
+## Workflow
+0. **Read `.claude/rules/core.md`**, then run the shared orientation preamble:
+   ```bash
+   P=.claude/skills/devrites-lib/scripts/preamble.sh
+   [ -f "$P" ] || P="${CLAUDE_SKILL_DIR:-}/../devrites-lib/scripts/preamble.sh"
+   [ -f "$P" ] || P=pack/.claude/skills/devrites-lib/scripts/preamble.sh
+   [ -f "$P" ] && bash "$P" || echo "(orientation preamble unavailable on this install — read state.md directly to orient)"
+   ```
+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`
+   gives a fast overview), cross-checked with codegraph + graphify, else standard methods
+   (LSP / Read/Grep/Glob); see `.claude/rules/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,
+   error model, test style) + recurring **gotchas**. Read `PRODUCT.md` / `DESIGN.md` /
+   `CLAUDE.md` / `AGENTS.md` if present.
+3. **Write `spec.md`** via [rite-spec's spec template](../rite-spec/reference/spec-template.md)
+   and create the workspace + set `.devrites/ACTIVE`
+   ([state-workspace](../rite-spec/reference/state-workspace.md)). The spec records the
+   **current behavior as the baseline** and the **next objective** (what adoption is for) with
+   measurable acceptance. Also write `decisions.md`, `assumptions.md`, `questions.md`, and
+   `state.md` (phase: spec).
+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.
+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.
+
+> **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
+> what exists; the *next* feature changes it. See [`anti-patterns`](reference/anti-patterns.md).
+
+## Output
+
+**Footer first** — render the progress footer (`progress.sh`, resolved like the step-0
+preamble). Then:
+```
+Adopted: <slug>
+Baseline: <one-line summary of current behavior>   Placement: <where it lives>
+Next objective: <what we'll build on top>
+Conventions seeded: <n> (commands · idioms · placement · gotchas)
+Next: big / risky? → /rite-temper   ·   straightforward? → /rite-define
+↻ Hygiene: /clear before the next phase (spec.md + decisions.md + the seeded ledger captured). See rules/context-hygiene.md.
+```

package/pack/.claude/skills/rite-adopt/reference/adoption.md

@@ -0,0 +1,58 @@
+# 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
+
+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
+  (where endpoints / components / models / migrations / tests go). Prefer a code-intelligence
+  index if available — codebase-memory-mcp first, cross-checked with codegraph + graphify, else standard methods (LSP / Read/Grep/Glob) (see
+  `../../../rules/tooling.md`) — for structure, callers, and impact.
+- **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
+  http/data-access pattern, the test framework + file layout.
+- **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
+seeds below.
+
+## Seeding the conventions ledger
+
+The deliberate **bootstrap exception** to evidence-gated promotion. Normally a convention is
+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
+  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
+  (raising the band) or, per fresh-observation-wins, contradict it.
+
+```bash
+C=.claude/skills/devrites-lib/scripts/conventions.py
+[ -f "$C" ] || C="${CLAUDE_SKILL_DIR:-}/../devrites-lib/scripts/conventions.py"
+[ -f "$C" ] || C=pack/.claude/skills/devrites-lib/scripts/conventions.py
+SLUG="$(cat .devrites/ACTIVE 2>/dev/null | tr -d '[:space:]')"
+if command -v python3 >/dev/null 2>&1 && [ -f "$C" ]; then
+  python3 "$C" promote --slug "${SLUG}-adopt" \
+    --key test-runner --kind test \
+    --statement "tests run with <runner>, <file layout>" \
+    --evidence "observed during /rite-adopt onboarding (not yet slice-proven)"
+  # …one promote per durable convention the investigation actually observed
+  # (test-runner, build-cmd, error-model, http-client, endpoint-placement, …).
+else
+  echo "(conventions ledger unavailable — python3 or script missing; skipping seed)"
+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
+([`.claude/rules/security.md`](../../../rules/security.md) § Prompt-injection resistance),
+an over-eager seed is self-correcting — but seed conservatively anyway; a wrong seed costs a
+needless contradiction later.

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

@@ -0,0 +1,19 @@
+# /rite-adopt — anti-patterns
+
+Start with the universal table in [`../../../rules/anti-patterns.md`](../../../rules/anti-patterns.md).
+Below are the rationalizations specific to onboarding an existing codebase.
+
+## Adoption-specific rationalizations
+
+| Excuse | Rebuttal |
+|---|---|
+| "I'll improve this messy bit while I document it." | Adoption *documents* what exists; it changes nothing. A cleanup is the *next* feature through the normal lifecycle — recording it as a drive-by here hides the baseline and balloons the diff. |
+| "This looks like the convention, so I'll seed it." | Seed only what the code *actually and consistently* follows. A guessed seed becomes a high-confidence-looking prior that steers the first slice wrong. Observe it in ≥2 places or leave it out. |
+| "I'll spec the ideal architecture, not the current one." | The spec's baseline is *current behavior*. Aspirations go in the next objective, not the baseline — otherwise every later slice drifts against a spec that never matched reality. |
+| "Whole repo in one adopt." | Onboard the area you'll actually work in. A repo-wide adopt produces an unfocused spec and a ledger full of conventions no slice will touch. |
+
+## Red flags
+
+- A seeded convention with no concrete code location behind it.
+- `spec.md` describing behavior the code does **not** currently have (that's the next feature, not the baseline).
+- Editing source during adoption — adoption writes `.devrites/` + the ledger, never project code.