omd

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
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