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
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
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}}
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
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.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.