---
name: design-craft
description: Use when producing ANY design artifact (UI/web/app screens, design systems, internal tools, wireframes) — turns "framework knowledge" into expert-grade output by forcing a constraint layer (product brief → concrete references → tokens with boundaries → decision logic → explicit don'ts) instead of letting the model fill silence with generic averages.
---

# Design Craft — 전문가급 디자인 산출물의 운영 표준

## 왜 이 스킬이 필요한가 (핵심 진단)

프레임워크를 "안다"고 좋은 디자인이 나오지 않는다. LLM에게 *서술*(무엇처럼 보이나)만 주면 **빈 추론층을 인터넷-평균 값으로 채운다** — "modern/clean/minimal"이라는 말에 묶인 가장 흔한 레퍼런스로 수렴해 generic해진다.

전문가는 값이 아니라 **제약(constraint)**을 준다: *무엇이 허용/금지되고, 언제 A vs B인가.* "잘 고른 8개 규칙이 토큰 2배보다 나쁜 산출을 더 막는다."

> **불변식: 제약 > 묘사.** 침묵을 남기지 마라 — 남긴 침묵은 모델이 generic으로 채운다.

## 절차 (design-brief를 먼저 세운다 — `org-os/06-agent-work/design-brief-spec.yaml`)

순서를 지켜라. brief가 언제나 먼저다(미학은 마지막).

### 1. Brief (필수·최상단)
2–3문장으로: **무엇을** 만드나 / **누가** 쓰나(맥락) / 이 산출물이 **반드시 달성할 것**(성공조건). 이게 하류의 모든 결정을 규정한다. 미학을 묻기 전에 "이 인터페이스가 푸는 문제"부터 확정하라.

### 2. References — 형용사가 아니라 구체 신호 (독창성은 여기서 나온다)
- **"modern / clean / minimal / sleek / beautiful" 금지.** 이런 형용사는 인터넷 평균 = generic 유발이다.
- 구체 대상 **3–6개**(20개 산만보다 6개 집중). 각각 *나르는 신호*를 명명:
  - ❌ "Linear처럼 modern하게"
  - ✅ "Linear — 13px base·4px grid·단일 accent color·낮은 채도 회색 계열·2px 라운드"
- 신호는 텍스처·밀도·간격·색 규율·표기에서 읽어라(장면이 아니라). 순수한 레퍼런스 하나가 모호한 무드보드 열 개보다 낫다(모델은 혼합 신호를 평균낸다).

### 3. Tokens — 값 + 의도 + 경계
각 토큰은 값만이 아니라 *언제 쓰고 무엇에 절대 안 쓰는지*까지:
```
primary: #1B4DFF
  intent: CTA·active state 표시
  boundary: 배경/장식으로 금지 · 화면당 1회 · 두 번 쓰고 싶으면 레이아웃을 의심하라
```
경계 없는 토큰은 실전에서 일관성을 무너뜨린다.

### 4. Decisions — 판단로직 (언제 A vs B)
컴포넌트가 *어떻게 보이나*가 아니라 *언제 쓰나*를 규정한다:
- "card vs list row? → 3필드 초과이고 독립 액션이 있으면 card, 아니면 list row"
이 결정층이 실전 일관성을 만든다.

### 5. Don'ts — 명시적 anti-pattern (최소 5개, 8이면 이상적)
시스템이 *절대* 하지 않는 것을 이름 붙여라:
- "gradient 금지" / "status color는 의미 전용 — 장식으로 금지" / "에러는 색 단독 금지, 항상 텍스트+색" …

## Anti-generic self-check (산출 직전 필수)

- [ ] 내 산출물을 "modern/clean/minimal"로 설명할 수 있나? → **그렇다면 generic이다.** 명명된 레퍼런스와 그 구체 신호로 다시 앵커하라.
- [ ] 모든 토큰에 경계(Don't)가 있나?
- [ ] 컴포넌트마다 "언제 이걸 vs 대안"의 판단로직이 있나?
- [ ] Don'ts가 5개 이상인가?
- [ ] brief의 성공조건으로 이 디자인을 반증할 수 있나?

## 역할별 강조점

- **DES-PROD**(제품): 문제→저니→product trio 검증. 브리프의 성공조건이 미학보다 앞.
- **DES-PLATFORM**(디자인시스템): 토큰=계약. 값+의도+경계가 핵심 산출. Atomic Design + Code Connect.
- **DES-INTERNAL**(내부툴): 운영자·워크플로우·처리시간이 성공조건. 파괴적 액션 가드 등 금지규칙.
- **DOC-VISUAL**(다이어그램): 시각 산출은 `diagram-craft` 스킬을 따른다(D2 우선, Mermaid 폴백).

## 근거 (E3)
- DESIGN.md 해부(제약>묘사, 토큰 경계, 8규칙): https://processtopixels.substack.com/p/writing-a-designmd-file-claude-can
- 461+ DESIGN.md 라이브러리: https://github.com/VoltAgent/awesome-design-md
- 형용사가 아니라 레퍼런스 신호: https://stensyl.ai/blog/reference-images-ai-style-consistency
- 모호한 프롬프트가 generic을 만든다: https://www.nngroup.com/articles/vague-prototyping/