Files
company-haness/.claude/skills/design-craft/SKILL.md
T

4.5 KiB
Raw Blame History

name, description
name description
design-craft 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 (필수·최상단)

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

2. References — 형용사가 아니라 구체 신호 (독창성은 여기서 나온다)

  • "modern / clean / minimal / sleek / beautiful" 금지. 이런 형용사는 인터넷 평균 = generic 유발이다.
  • 구체 대상 36개(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)