with one click
design
Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth
Menu
Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth
[OMX] Strict autonomous loop: $deep-interview -> $ralplan -> $ultragoal (+ $team if needed) -> $code-review -> $ultraqa
Socratic deep interview with mathematical ambiguity gating before execution
Parallel execution engine for high-throughput task completion
Run a comprehensive code review
Adversarial dynamic e2e QA workflow - generate hostile scenarios, test, verify, fix, report, and clean up
Self-referential loop until task completion with architect verification
| name | design |
| description | Canonical repo-local DESIGN.md workflow for product, UI/UX, and frontend decision source of truth |
Use $design when product, UI/UX, frontend, or design-system decisions need a durable source of truth in the repository. This skill discovers existing design context, interviews for missing product/design information, and creates or refreshes repo-local DESIGN.md so future UI/UX/frontend work is grounded instead of improvised.
Make repo-local DESIGN.md source of truth and canonical design contract for the current repository:
existing repo evidence -> missing-context interview -> create/refresh DESIGN.md -> use DESIGN.md for UI/UX/frontend decisions.
The output is not a pixel-matching loop and not a one-off visual critique. It is the maintained design brief/checklist that implementation, review, and future visual work should cite.
DESIGN.md created or refreshed before $ralph, a designer lane, or implementation work proceeds.$visual-ralph for that visual-reference implementation loop.$visual-ralph and its built-in visual verdict flow.$visual-ralph$design owns the durable repo design source of truth: product goals, users, IA, visual language, components, accessibility, constraints, and open questions in DESIGN.md.
$visual-ralph owns implementation against an approved generated/static/live-URL visual reference, with screenshot capture, Visual Ralph verdict scoring, and pixel-diff evidence. $visual-ralph may read DESIGN.md, and it may leave design-system artifacts behind, but it does not replace the DESIGN.md discovery/interview/refresh workflow.
If both are needed, run $design first to establish the design contract, then run $visual-ralph only after the visual reference/baseline is approved.
Inspect the repository before writing guidance. Look for:
DESIGN.md, docs/design*, docs/ux*, docs/frontend*, README.md, product specs, PRDs, and issue notes..omx/artifacts/visual-ralph/* references.Record evidence with file paths. Distinguish observed facts from design inferences.
Ask concise questions only when repo evidence cannot answer design-critical context. Prefer one focused round that closes the biggest gaps, such as:
If the user wants autonomous progress or cannot answer, create DESIGN.md with explicit assumptions and open questions instead of blocking.
DESIGN.mdUse the structure below. Preserve useful existing content, remove contradictions, and mark unknowns as open questions. Keep it actionable for implementers and reviewers.
DESIGN.md structure/checklist# Design
## Source of truth
- Status: Draft | Active | Needs refresh
- Last refreshed: YYYY-MM-DD
- Primary product surfaces:
- Evidence reviewed:
## Brand
- Personality:
- Trust signals:
- Avoid:
## Product goals
- Goals:
- Non-goals:
- Success signals:
## Personas and jobs
- Primary personas:
- User jobs:
- Key contexts of use:
## Information architecture
- Primary navigation:
- Core routes/screens:
- Content hierarchy:
## Design principles
- Principle 1:
- Principle 2:
- Tradeoffs:
## Visual language
- Color:
- Typography:
- Spacing/layout rhythm:
- Shape/radius/elevation:
- Motion:
- Imagery/iconography:
## Components
- Existing components to reuse:
- New/changed components:
- Variants and states:
- Token/component ownership:
## Accessibility
- Target standard:
- Keyboard/focus behavior:
- Contrast/readability:
- Screen-reader semantics:
- Reduced motion and sensory considerations:
## Responsive behavior
- Supported breakpoints/devices:
- Layout adaptations:
- Touch/hover differences:
## Interaction states
- Loading:
- Empty:
- Error:
- Success:
- Disabled:
- Offline/slow network, if applicable:
## Content voice
- Tone:
- Terminology:
- Microcopy rules:
## Implementation constraints
- Framework/styling system:
- Design-token constraints:
- Performance constraints:
- Compatibility constraints:
- Test/screenshot expectations:
## Open questions
- [ ] Question / owner / impact
DESIGN.md as the decision contractFor UI/UX/frontend work after the refresh:
DESIGN.md sections before making design choices.DESIGN.md or add an open question before proceeding.DESIGN.md sections, repo evidence, and acceptance criteria.$visual-ralph with the approved reference/baseline and note that DESIGN.md is supporting context, not the visual verdict target.Do not declare the design workflow complete until:
DESIGN.md open questions.DESIGN.md exists at the repo root and contains all required checklist sections.DESIGN.md rather than relying on unstated preferences.$visual-ralph handoff is clearly separated as visual implementation matching, not DESIGN.md governance.Task: {{ARGUMENTS}}