Devrites frontend craft

Codex compatibility

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.
• Invocation and dispatch are different: invoke means run a skill in this context; dispatch means start a fresh agent with spawn_agent, await it, and reconcile its result. Never describe inline skill work as a dispatch.
• On MultiAgent V2, call spawn_agent with the exact named agent_type=devrites-<role>, a unique task_name, and fork_turns="none". Codex loads that role TOML's developer_instructions natively. Because V2 collaboration lifecycle calls bypass hooks, DevRites verifies the current durable parent/child rollout for the exact role, wait, completion, and non-empty delivered result.
• On MultiAgent V1, when the named role is not exposed, use generic explorer for a read-only role with fork_turns="none" and name exactly one .codex/agents/devrites-<role>.toml contract in the message. Trusted .codex/hooks.json injects that contract's exact developer_instructions and binds the child to the fail-closed reviewer read-only guard.
• On MultiAgent V1, devrites-slice-wright uses generic worker with fork_turns="none" and the exact role TOML named in the message. Trusted .codex/hooks.json binds it to the active reconcile window and .wright-allowlist; do not substitute worker for an exposed V2 named role.
• The invoked skill's required-agent-roles frontmatter arms the fail-closed Stop receipt. Every listed role must have a confirmed start, wait, and non-empty result in this turn.
• If any required named or generic agent dispatch is unavailable or rejected, stop for HITL. Never execute a DevRites specialist role in the root context.
• Wait for every required fresh-context dispatch before reconciling or advancing. A backgrounded or lost result is incomplete.
• Codex project hooks are installed in .codex/hooks.json; declared-leaf hooks are scoped inside .codex/agents/devrites-*.toml. 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.

devrites-frontend-craft: UI like a senior designer-engineer

Build UI that belongs in this product, handles every state, and avoids generic-AI tells. Integrated into the feature slice, not a separate design project.

1. Foundation discovery

Framework, routing, components, tokens, CSS methodology, icon set, existing UI patterns, and any PRODUCT.md / DESIGN.md / design docs. Use the project's system: don't import a new one. (Detail: reference/design-references.md.)

• Load the design brief + references the spec gathered: .devrites/work/<slug>/design-brief.md (the UX/UI contract from devrites-ux-shape: the primary build target) plus references.md + the saved files in references/ (screenshots, Figma, video, links). Honor the role in references.md: match targets, satisfy constraints, and extract only the named principle from inspiration (pull Figma context if a Figma integration is available). For targets, extract type / spacing / color-roles / layout / component behavior deliberately; don't eyeball it (reference/design-references.md. Building to a supplied reference). A reference that conflicts with the design system is a question for the user, not a silent choice.

Reuse first: search before you build

Before creating any new component, style, token, icon, hook, util, or helper, search the project for an existing one and reuse → extend → build new: see reference/reuse-first.md for the search targets, the AHA caveat, and the per-slice reuse record.

2. Register detection

Read the discovery and register contract in reference/design-references.md. Completion: the surface is classified as brand or product and its existing tokens, components, patterns, and nearest neighbor are named before design choices begin.

3. Shape before code: build to the brief (reference/shape.md)

The feature's design-brief.md is your target: $rite-spec shaped it up front (devrites-ux-shape): design direction, key states, interaction model, the visual-direction probe. Read it first and refine it for this slice's surface; don't re-derive the design from scratch. Confirm the slice covers the brief's states for this surface (default, loading, empty, error, success, disabled, long-content), its information hierarchy + primary action, responsive behavior, a11y, interaction model, and proof targets. If a UI slice has no design-brief.md (a spec written before shaping), shape it now via devrites-ux-shape before coding. Ask before coding if the visual direction or UX flow is still ambiguous.

4. Build (reference/craft.md)

• Compose from existing components/tokens (reuse-first, above) before reaching for new code.
• Build the smallest UI the current slice needs: don't pre-build screens.
• Don't add a second component library or icon set without asking.
• Cover the states you shaped, not just the happy path.
• Reduce cognitive load: no wall of options: group, mark the recommended choice, use progressive disclosure.
• Copy in the product's voice; shift tone by moment: success brief, error empathetic
  • actionable, loading reassuring, destructive serious. Never humor in errors. Empty states say why + the next action.
• First-use: get the user to first value fast; onboarding proves worth, it doesn't teach the whole product.

5. Verify & record (meet the bar)

• Hit the 2026 quality bar: Core Web Vitals (LCP ≤2.5s / INP ≤200ms / CLS ≤0.1), WCAG 2.2 AA (keyboard, visible focus, contrast, ≥24px targets / 44px touch, no drag-only), responsive at 320/768/1024/1440, and run its verification gate (no console errors, no axe violations, all states).
• Run the visual convergence loop in the browser (devrites-browser-proof): render the slice's named states/viewports/input modes, open the screenshots, compare them with the brief + target R-ids, record material deltas, fix, and re-render until none remain. A detector/checklist is a floor, not the visual verdict.
• Every interactive element has an asserting test at the right level: each field, checkbox, radio, select, toggle, button, and actionable link gets a unit/component test for what it does (validation, toggle, options, enabled/disabled, handler); critical journeys get one E2E. Browser proof shows it renders; the asserting test proves it works. No element ships unverified: standards/testing.md "Completeness"; inventory in test-plan.md.
• Append build-time refinements to .devrites/work/<slug>/design-brief.md: the design-contract artifact devrites-ux-shape produced at spec; this skill refines it per slice (the "Build-time refinements" section), it does not own or recreate it. $rite-polish reads it in its UI phase and $rite-seal includes it in its artifact read list. Record runtime evidence in browser-evidence.md.

Fullstack (frontend + backend in one feature)

When the feature needs both sides, follow reference/fullstack.md: define the API/data contract first (devrites-api-interface), slice vertically through the layers (DB → service → API → UI) one capability at a time, apply the engineering rules to the backend and this craft to the frontend, map every contract error to a real UI state, and prove both layers (contract tests + browser proof).

Anti-AI-slop (banned defaults unless the project's system uses them)

Purple/blue gradients · gradient text · glassmorphism by default · cards-in-cards · identical card grids everywhere · rounded-square icon tile above every heading · gray-on-color text · hero-metric cliché · decorative bounce/elastic easing · random Inter-for-everything · modal-first thinking · ghost-card (border + big shadow) · fake UI-in-a-div · placeholder copy/data. Full list + the countable mechanical pre-flight: rite-polish/reference/anti-ai-slop.md.

Default vs departure

Preserve the existing identity (default, ~90%). Reject it only on an explicit signal (a design doc naming this surface as the failure, or the user asking to rebuild). If unsure, you're in default mode: the cost of a wrong departure is unrecoverable.