---
name: use-design-md
description: Pull a Korean brand's published design.md from the ko-design-md catalog (getdesign.kr) and apply its design language — colors, typography, spacing, radius, components, do's & don'ts — to the UI you are building in the CURRENT project. Use this skill whenever the user wants to build or restyle UI in the *style of* a catalogued Korean service — phrases like "토스 디자인으로 만들어줘", "당근 스타일로 이 화면 다시 꾸며줘", "getdesign 카탈로그에서 배민 디자인 가져와서 적용", "KRDS 톤으로 폼 잡아줘", "make this look like Toss", "use the Karrot design system here", or "/use-design-md". Works in ANY repository — it fetches over the network, no local catalog needed. Do NOT use this to ADD a brand to the catalog or edit catalog entries — that is the separate `design-md` producer skill, which only runs inside the ko-design-md repo. If the requested brand isn't in the catalog, say so plainly rather than inventing a design.md.
---

# use-design-md — consumer skill for the ko/design.md catalog

## Mental model

The ko-design-md catalog (https://getdesign.kr) publishes one `design.md` per Korean
service — a compact, machine-readable description of that brand's visual language:
colors in OKLCH, typography, spacing, radius, signature components, and do's & don'ts.
This skill is the **consumer** side: it pulls the right entry and uses it as the design
brief for UI work in **whatever project you are currently in**.

It does three things, in order:

1. **Discover** — resolve the brand the user named to a catalog `slug`.
2. **Fetch** — download that entry's raw `design.md` (and, if useful, its token sidecar).
3. **Apply** — translate that design language into the current project's styling system.

## This skill vs. `design-md` (don't mix them up)

- **`use-design-md` (this skill)** — CONSUME an existing entry. Runs in any repo.
  "Make my dashboard look like Toss", "apply Karrot's style to this screen".
- **`design-md` (the other skill)** — PRODUCE a new entry, adding a brand to the catalog.
  Only runs inside the ko-design-md repo.

If the user wants to *add* or *edit* a catalog entry, stop and point them at `design-md`.
That is a different job in a different place.

## Step 1 — Discover: resolve the brand to a slug

Fetch the catalog index (llms.txt format, ~one line per entry):

```
curl -s https://getdesign.kr/llms.txt
```

Each entry line looks like:

```
- [토스](https://getdesign.kr/services/toss/llms.txt): finance — <tagline>
```

Match the user's mention to a slug. The user may say a Korean name ("토스", "당근"), an
English name ("Toss", "Karrot"), a design-system name ("SEED Design", "Vapor UI"), or the
slug itself ("seed-design"). Match against the link text (name) AND the slug in the URL;
the tagline often names the design system, which helps disambiguate.

Outcomes:
- **One clear match** → take its slug, go to Step 2.
- **Several plausible matches** → ask which one with `AskUserQuestion`.
- **No match** → the brand isn't in the catalog. Tell the user plainly, optionally list a
  few catalogued brands in the nearest category, and mention that *adding* it is a
  separate job (the `design-md` skill, inside the ko-design-md repo). Do not fabricate a
  design.md for an uncatalogued brand — that defeats the point of citing a real source.

See `references/endpoints.md` for the full endpoint map and fallbacks.

## Step 2 — Fetch the design.md (and tokens if needed)

Fetch the raw entry:

```
curl -s https://getdesign.kr/services/<slug>/llms.txt
```

**Use `curl` (Bash), not WebFetch, for the entry.** WebFetch summarizes and transforms
content through a model, which silently drops exact token values — an OKLCH triple, a
13px spacing step, a specific weight. The whole reason to pull from the catalog is
fidelity to the brand's *real* numbers, so fetch the bytes verbatim. WebFetch is an
acceptable last resort only when Bash/curl is genuinely unavailable.

If you need tokens as structured data (e.g. to generate a Tailwind theme or a CSS
variable block programmatically), also fetch the sidecar from GitHub raw — there is no
getdesign.kr endpoint for it yet:

```
curl -s https://raw.githubusercontent.com/CaesiumY/ko-design-md/main/services/<slug>.tokens.json
```

Read the design.md fully before applying anything. The prose carries intent — the do's &
don'ts, the voice — that the token JSON alone doesn't capture.

## Step 3 — Apply to the current project

This is the real work, and it's project-specific. Read `references/apply-guide.md` and
follow it. In short:

1. **Detect the target styling system first** (Tailwind config, CSS custom properties,
   CSS-in-JS, plain CSS) before changing anything.
2. **Map tokens onto that system** rather than pasting raw values everywhere — change
   them at the source so the whole surface moves together.
3. **Honor the Do's & Don'ts.** They're the brand's guardrails, not decoration.
4. For a large or structural change, design it first before coding (in Claude Code:
   `superpowers:brainstorming`; in other agents, an equivalent brainstorming step);
   for a small restyle, just go.
5. **Verify** the result (preview/screenshot, or the project's tests) before claiming
   done — evidence before assertions (in Claude Code: `superpowers:verification-before-completion`).

## Scope guardrails

- Don't gate on the current repo — this skill is meant to run anywhere.
- Don't invent values absent from the fetched design.md. If the user wants something the
  brand's tokens don't cover, say so and propose a reasonable extension marked as *your*
  inference, not the brand's spec.
- The catalog covers Korean services. A brand that isn't listed simply isn't available
  here — be honest about that instead of approximating from memory.
- Stay vendor-neutral: borrow the visual language, not the source design system's own name.
  Never surface the system's name (`Vapor UI`, `SEED Design`, …), its package names, or its
  class prefixes in the UI you generate — use the user's own product naming. See
  `references/apply-guide.md` §6.