Builds and maintains a DESIGN.md brief from existing screens, documentation, and components. It records product goals, visual rules, accessibility, and implementation constraints so future interface decisions have a shared reference.
Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth
Review the instructions the agent will receive before you install.
Use $design to discover product and UI evidence, close only design-critical context gaps, and create or refresh the repository’s durable DESIGN.md contract. It is a maintained design brief, not a pixel-matching loop or one-off critique.
Shared operating, delegation, state, hook, team, cancellation, and verification invariants live in templates/AGENTS.md. Follow that source instead of duplicating its rules here.
Do not use it for visual-reference implementation matching (use $visual-ralph), screenshot comparison alone, or backend/infrastructure work without user-facing design impact.
$visual-ralph$design owns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions in DESIGN.md. $visual-ralph owns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run $design first when both are needed; DESIGN.md supports but does not replace the visual verdict target.
Inspect and cite existing DESIGN.md, design/UX/frontend docs, README/specs/issues, routes/pages/layouts/components/stories, theme and token files, assets, screenshots/mockups, Storybook or Playwright baselines, and accessibility/responsive/i18n/platform constraints. Separate observations from inferences; note absent evidence.
Ask concise questions only for gaps the repository cannot resolve: users/jobs, goals/non-goals, brand personality and forbidden aesthetics, primary flows, accessibility/device/browser targets, or unavailable assets/references. If answers are unavailable, record explicit assumptions and open questions rather than blocking.
DESIGN.mdPreserve useful content, remove contradictions, mark unknowns, and keep decisions actionable. The root file must contain these sections:
Status (Draft | Active | Needs refresh), date, product surfaces, evidence reviewed.
Personality, trust signals, avoid.
Goals, non-goals, success signals.
Primary personas, user jobs, contexts of use.
Navigation, routes/screens, content hierarchy.
Principles and tradeoffs.
Color, typography, spacing, shape/elevation, motion, imagery/iconography.
Existing/new components, variants/states, token ownership.
Target standard, keyboard/focus, contrast, semantics, reduced motion/sensory concerns.
Breakpoints/devices, layout adaptations, touch/hover differences.
Loading, empty, error, success, disabled, offline/slow network where applicable.
Tone, terminology, microcopy rules.
Framework/styling, tokens, performance, compatibility, test/screenshot expectations.
[ ] question, owner, and impact.
Before UI decisions, cite relevant DESIGN.md sections, reuse documented components/tokens, and update the file or add an open question when implementation exposes a contradiction. Do not invent a parallel design-system layer.
For normal frontend work, provide the relevant sections, repo evidence, and acceptance criteria. For visual-reference, image, or live-URL matching, hand off to $visual-ralph with the approved baseline and identify DESIGN.md as supporting context only.
Complete only when design docs/assets/components/screenshots were inspected or noted absent; missing context is answered, assumed, or listed; root DESIGN.md contains every required section; recommendations cite it; and any Visual Ralph handoff is clearly separated from design governance.
Task: {{ARGUMENTS}}
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Clean up working code by identifying duplication, dead code, unnecessary layers, and error paths that hide failures. Preserve behavior with targeted tests, simplify the requested files in stages, and report verification results and remaining risks.
Investigate repository behavior, architecture, or possible causes without changing files. Trace relevant code and supporting material, then rank explanations by evidence and confidence, with concrete file references and clear distinctions between observations, conclusions, and unresolved questions.
Ask Claude or Gemini through a locally installed command-line tool for focused questions, reviews, brainstorming, or second opinions. Save the prompt, original response, summary, and next steps in a reusable Markdown file.
Take an idea or issue through requirements clarification, reviewed planning, implementation, and verification. Supervise all stages in one recoverable OMX workflow, preserving artifacts and progress so work can resume or return to planning when findings require changes.
Run a persistent research workflow with a defined goal and explicit acceptance checks. It saves progress and finishes only when a recorded result passes either a validation script or an architect review of the research output.
Find the replacement for a research command removed in OMX 0.21. This migration notice directs existing autoresearch-goal usage to $autoresearch, the canonical research loop that requires validation before proceeding.