Skill-Details

omd

Applies an existing DESIGN.md to UI rather than defining branding.

ÜbereinstimmungMöglichGeprüft für branding
Quellekwakseongjae/oh-my-designExterne Quelle
Gemeldete Installationen13Nur Popularitätssignal

Vor Nutzung prüfen

Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.

Gespeicherte Quellvorschau

SKILL.md

Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.

---
name: omd
description: Apply a project's DESIGN.md (Google Stitch format + OmD v0.1 brand-philosophy layer) as authoritative brand context when generating or modifying UI. Use whenever the user asks for UI work — new components, styling changes, layout, microcopy, empty/error states, motion — and a DESIGN.md exists at the project root. Also use when the user asks to "apply the brand", "match the design", "follow the design system", or references OmD, DESIGN.md, or the brand explicitly.
---

# OmD — Brand Context for Claude Code

You are about to generate or modify UI for a project that ships a `DESIGN.md` at its root. This file is the brand's authoritative voice. Your job is to consume it correctly and refuse to default to AI-slop patterns.

## Step 1 — Detect

Check for these in order:

1. `./DESIGN.md` at the project root (primary).
2. `./.stitch/DESIGN.md` (Google Stitch's internal location — still valid OmD).
3. `./spec/omd-*.md` if the project ships a custom-versioned spec.

If none exist, stop. Tell the user: *"No DESIGN.md found. Run `npx omd init` to scaffold one, or proceed without brand context (output will be generic)."* Do not invent brand rules.

If a `DESIGN.md` exists, read the whole file before writing a single line of UI. Do not skim.

## Step 2 — Parse

Look at the frontmatter:

```yaml
---
omd: 0.1
brand: <name>
---
```

- **Frontmatter present with `omd:` key** → full OmD file. Sections 10–15 are authoritative.
- **No frontmatter** → Google Stitch base only. Treat sections 1–9 as authoritative; do not invent sections 10–15.

The 15 possible sections:

```
Base (Google Stitch, required)
  1. Visual Theme & Atmosphere      — the "feel" paragraph
  2. Color Palette & Roles          — named + hex, always paired
  3. Typography Rules               — family, scale, tracking, features
  4. Component Stylings             — button, card, input, nav specs
  5. Layout Principles              — spacing scale, grid, radius
  6. Depth & Elevation              — shadow system
  7. Do's and Don'ts                — explicit constraints
  8. Responsive Behavior            — breakpoints, touch targets
  9. Agent Prompt Guide             — quick-ref + example prompts

Brand Philosophy (OmD v0.1)
 10. Voice & Tone                   — microcopy constraints
 11. Brand Narrative                — the "why"
 12. Principles                     — first-principles rules
 13. Personas                       — who this is for
 14. States                         — empty/error/loading patterns
 15. Motion & Easing                — duration + easing tokens
```

## Step 3 — Apply (the contract)

When generating UI, the file's sections act as *constraints*, not suggestions.

### Hard rules

1. **Every color you use MUST appear in section 2.** If you need a color that isn't there, stop and ask. Do not invent hex values. Do not "borrow" a complementary color.
2. **Every font MUST appear in section 3.** Never substitute Inter/Roboto/Arial/system-ui as a fallback — if they aren't in the stack, they aren't allowed.
3. **Component shapes (radius, padding, shadow) MUST come from sections 4–6.** If a radius scale is declared, values outside it are forbidden.
4. **Microcopy MUST match section 10.** If "forbidden phrases" are listed, they are banned. If tone mappings are given, follow them. A button label that violates the voice is wrong even if the component shape is correct.
5. **Empty / error / loading / skeleton states MUST come from section 14.** Do not invent a "No data found 😔" card. Use the declared treatment.
6. **Motion MUST use section 15 tokens.** If durations are named (`motion-fast`, `motion-standard`), wire them to those names — do not hardcode `200ms`.
7. **Principles (section 12) are tiebreakers.** When two valid interpretations compete, the principles decide. They override your defaults.
8. **Do's and Don'ts (section 7) are non-negotiable.** A "Don't" is a hard block.

### Soft rules

- Section 1 (Visual Theme) sets the mood. Use 
Vollständige Quelle auf GitHub lesen (öffnet externe Seite)
Kontext

Verwandte Arbeit