Oma Design

oma-design

Scheduling

Goal

Design specialist that defines, creates, and validates project design systems. DESIGN.md is the central artifact — all design work revolves around it.

Intent signature

• User asks for design system, DESIGN.md, visual direction, typography, color, motion, accessibility, anti-pattern review, or component guidance.
• User needs design decisions before frontend implementation or wants UI quality audited from a design perspective.

When to use

• Defining or revising a project design system
• Creating or auditing DESIGN.md
• Selecting typography, color, layout, motion, or component direction
• Reviewing UI work for responsive behavior, accessibility, and visual quality
• Using optional vendor inspiration from Stitch MCP or getdesign

When NOT to use

• Implementing frontend components or application UI -> use oma-frontend
• Planning product scope or task breakdown -> use oma-pm
• Backend, database, infrastructure, or mobile implementation -> use the relevant specialist skill
• General quality/security review outside visual, interaction, and accessibility concerns -> use oma-qa

Expected inputs

• Product, brand, audience, platform, and UI/design problem
• Existing .design-context.md, DESIGN.md, screenshots, references, or component constraints
• Accessibility, responsive, language, and implementation constraints

Expected outputs

• Design direction, revised DESIGN.md, audit findings, component guidance, or handoff notes
• Responsive-first, WCAG-aware design recommendations
• Optional vendor seed attribution when getdesign is used

Dependencies

• .design-context.md and DESIGN.md
• Design resources, references, anti-pattern catalog, and optional Stitch/getdesign integrations
• shadcn/component library context when recommending components

Control-flow features

• Branches by missing context, CJK language support, vendor seed availability, and anti-pattern audit results
• May read/write design docs and call optional design/vendor tooling
• Requires user confirmation before generation when multiple directions exist

Structural Flow

Entry

1. Check .design-context.md; if missing, run setup before design work.
2. Identify target audience, platform, content language, and design artifact.
3. Decide whether vendor inspiration or Stitch integration is relevant.

Scenes

1. PREPARE: Load design context and constraints.
2. ACQUIRE: Extract existing design signals, references, and anti-pattern risks.
3. REASON: Propose directions, typography, color, layout, motion, and accessibility choices.
4. ACT: Generate or revise DESIGN.md and related guidance.
5. VERIFY: Audit responsive behavior, WCAG, Nielsen heuristics, and AI-slop patterns.
6. FINALIZE: Handoff design decisions and attribution where required.

Transitions

• If .design-context.md is missing, create it before continuing.
• If CJK support is needed, prioritize CJK-ready fonts.
• If vendor seed fetch fails, choose retry, continue without seed, or abort.
• If anti-patterns appear, surface alternatives before finalizing.

Failure and recovery

• If design context is insufficient, ask for one focused clarification or propose assumptions.
• If vendor inspiration is unavailable, continue with local design synthesis.
• If accessibility checks fail, revise before handoff.

Exit

• Success: design artifact is project-specific, responsive-first, accessible, and audit-ready.
• Partial success: missing context, vendor failure, or open design decision is explicit.

Logical Operations

Actions

Tools and instruments

• Design references, anti-pattern catalog, checklist, Stitch integration, getdesign fetcher
• shadcn CLI recommendations when component guidance is needed

Canonical workflow path

1. Check `.design-context.md`; create it if missing.
2. Produce 2-3 design directions and get confirmation.
3. Generate or revise `DESIGN.md`, then run the design checklist.

Optional vendor seed discovery:

bunx getdesign@latest list

Resource scope

Preconditions

• Target design problem and artifact are identifiable.
• Design context exists or setup can create it.

Effects and side effects

• May create or modify DESIGN.md and design context artifacts.
• May fetch vendor seed material and append MIT attribution.
• Does not implement frontend code directly.

Guardrails

1. Check .design-context.md before any design work. If missing, run Phase 1 (Setup) to create it.
2. System font stack as default (system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif). Add custom fonts only with project justification.
3. If the service supports CJK languages (ko/ja/zh): prioritize CJK-ready fonts (Pretendard Variable > Noto Sans CJK > system-ui fallback). If latin-only: choose fonts appropriate for the target audience.
4. Enforce anti-patterns strictly — reject AI slop. See resources/anti-patterns.md.
5. Name colors semantically with hex values: "Deep Ocean Navy (#1a2332)" not "dark blue".
6. Recommend components with install commands (shadcn CLI).
7. ALL output must be responsive-first (mobile layout as default, enhance upward).
8. WCAG AA minimum for all designs. Respect prefers-reduced-motion.
9. Stitch MCP is optional — all phases work without it.
10. Present 2-3 design directions and get user confirmation before generating.

Anti-Pattern Quick Reference

Typography

• DON'T: Default to custom Google Fonts when system fonts suffice
• DON'T: Use Inter/Geist alone without considering project context
• DON'T: Load 3+ font families without justification
• DON'T: Body text below 16px on mobile
• DO: System font stack first, custom fonts for brand identity only
• DO: Test CJK at every size (line-height 1.7-1.8)