菜单
디자인 결정을 discuss 스타일로 점진 구체화한다. LLM이 widget부터 조립하지 않고 디자이너의 사고 순서(Job → Content → Priority → Hierarchy → Component)를 따르도록 강제한다. 한 번에 완성하지 않고 매 턴 이해도 🔴🟡🟢을 갱신하며 13 결정을 채운다. Blueprint/구현 단계 앞에 위치하며 "디자인 사고", "화면 brief", "시각 의사결정", "/design-think" 등 시각 결정 필요 시 사용. /blueprint → /go 파이프라인의 선행 스킬.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Refactor frontend source trees so layer/slice/segment(role) hierarchy stays clear. Treat FSD names such as shared/entities/features/widgets/app as examples, not as the required target. Use when the user asks to reorganize src, separate app-owned code from reusable packages, remove layer smells, or clarify 책임 경계.
요청이 모호하거나 '왜 하는지'부터 정리가 필요할 때 사용. /discuss, $discuss, 숨은 의도 정렬, 전략 선택, 실행 전 확인 요청, 프로젝트 작업과 개인 도구 작업의 범위 분리가 필요할 때 사용한다. TOC 13요소와 FRT 게이트로 이해도를 순서대로 올린 뒤 goal로 실행 가능한 액션 플랜을 만든다. 질문만 던지는 소크라틱 대화가 아니라, AI가 먼저 범위 안 맥락을 조사하고 추론한 뒤 판단과 근거를 밝히고 필요한 갭 질문만 얹는다.
Use when the user invokes /doubt or $doubt, asks Codex to deliberately reduce unnecessary complexity before introducing a new concept, component, flag, type, file, branch, workflow, document, or procedure, or requests cleanup/review after implementation. Triggers include "이거 다 필요해?", "정리 좀 해줘", "새로 만들어야 할까?", "불필요한 거 없나?", "코드 줄여줘", "why do we need this?", or any review where existence, fit, volume, and efficiency should be challenged before adding or keeping structure.
Use when refactoring frontend entity folders, FSD feature/entity boundaries, exported type names, prefix alignment, or cohesive entity/viewModel/value-object props so files and UI interfaces are grouped by real domain or UI concepts instead of role labels, generic names, or shredded field props. Trigger on requests such as entities 응집도, 접두어 정렬, 인터페이스 중심 폴더링, FSD 위치 점검, feature/entity 경계 리팩토링, props drill, entity shredding, viewModel props, 엔티티를 그대로 넘기기.
파일이나 기능의 개방-폐쇄 원칙(OCP)을 점검하고 리팩토링한다. "OCP", "/ocp", "개방 폐쇄", "switch 너무 많다", "if 분기 정리", "분기 흩어짐", "선언적 맵", "registry", "descriptor", "새 타입/variant 추가마다 여러 곳 수정" 같은 요청에서 사용한다. 열린 집합의 분기가 여러 소비자에 산재해 동반 변경 지점이 2곳 이상인지 분석하고, 확장 시 기존 코드 수정 지점을 0~1곳으로 줄이는 구조를 설계·전환한다.
사용자 발화를 액면 그대로 수행하지 않고 숨은 조사 의도, 배경, 목표를 먼저 추론한 뒤 비교 대상의 범주와 피어셋을 잠그고, 내부 맥락을 감사하고 standard, best practice, de facto, frontier trend를 비교해 읽히는 reference narrative를 만든다. "reference", "레퍼런스", "BP 찾아줘", "best practice", "사실상 표준", "de facto", "요즘 트렌드", "최근 시도", "업계는 어떻게 해", "표준 뭐야", "research", "리서치", "/reference", "/research"처럼 외부 수렴 흐름을 알고 싶을 때 사용한다. 단순 링크 목록이나 표 보고서가 아니라, 소스를 대신 읽고 같은 범주의 BP/de facto와 얼마나 가까운지, 결이 얼마나 비슷한지, 차이가 있다면 더 가까운 유사 레퍼런스는 무엇인지 문단 중심으로 설명하고 필요한 근거 표는 appendix로 내린다.
| name | design-think |
| description | 디자인 결정을 discuss 스타일로 점진 구체화한다. LLM이 widget부터 조립하지 않고 디자이너의 사고 순서(Job → Content → Priority → Hierarchy → Component)를 따르도록 강제한다. 한 번에 완성하지 않고 매 턴 이해도 🔴🟡🟢을 갱신하며 13 결정을 채운다. Blueprint/구현 단계 앞에 위치하며 "디자인 사고", "화면 brief", "시각 의사결정", "/design-think" 등 시각 결정 필요 시 사용. /blueprint → /go 파이프라인의 선행 스킬. |
design-think 시작 시 memory/MEMORY.md와 src/styles/DESIGN.md(있으면)를 읽어 기존 맥락·축 컨벤션을 로드한다. 인자로 화면명이 오면 해당 화면의 discuss/inbox 메모가 있는지 docs/ 최근 3일 검색.
너는 디자인 파트너다. 사용자가 "Gmail 만들어줘" 할 때 바로 widget 조립부터 들어가면 14개쯤 품질 결함이 난다(실증). 이 스킬은 widget 이전에 Job · Priority · Content · Hierarchy를 먼저 결정한 뒤 조립에 넘긴다.
핵심 원칙 (이 프로젝트 고유):
1. Job ┐
2. User & Context ├── WHY (사용자 쪽)
3. Content ┘
4. Priority ┐
5. Scan Pattern ├── WHAT (정보 쪽)
6. Layout ┘
7. Hierarchy ┐
8. Component ├── HOW (시각 쪽)
9. States ┘
10. Interaction ┐
11. Density ├── POLISH
12. Contract ┘
13. Critique ← pre-mortem
| # | 요소 | 질문 | 산출 예시 |
|---|---|---|---|
| 1 | Job | 사용자가 이 화면에서 3초 안에 뭘 결정/수행하려는가? | "훑어서 열 메일 결정" / "즉시 답장" |
| 2 | Context | 누가 어떤 상황에서? 디바이스·시간 압박·빈도·입력 방식 | "데스크탑 · 키보드 위주 · 1일 50회" |
| 3 | Content Inventory | 실데이터 형상 측정 (글자 수·개수·줄 수·range) | sender 6–20자 / subject 10–80자 / preview 30–120자 / label 0–3개 · 2–8자 |
| 4 | Information Priority | 1st/2nd/3rd gaze 분류 (역피라미드 3층) | 1st=sender, 2nd=subject+unread, 3rd=preview·date·attach·label |
| 5 | Scan Pattern | 어떻게 읽게 할 것인가 (F / Z / list-row / grid) | list-row: 왼→오 수평 스캔, 세로 12px 리듬 |
| 6 | Layout Skeleton | 구획·면적 분배 (영역별 역할) | 3-pane 18%/35%/47% · topbar 64px fix · footer pagination |
| 7 | Visual Hierarchy Spec | 대비 전략 — size / weight / color / bg / space 4~5 레벨 | L1 page 22/600 · L2 label 14/500 · L3 body 14/400 · L4 caption 12/400-dim · unread=bg delta 4.5 + weight+100 |
| 8 | Component Choice | 영역별 패턴 → CATALOG 매핑 | sidebar=NavList · list=ListBox+MailListItem(composite) · detail header=PanelHeader+Avatar+Badge |
| 9 | States | empty / loading / error / selected / disabled 시각 | empty="메일 없음" illustration · loading=Skeleton 3 row · selected=bg-raised + ring |
| 10 | Interaction | hover / focus / press / disabled 변화 | hover=bg-delta 2% · focus=ring accent · press=scale 0.98 |
| 11 | Density / Responsive | comfortable/compact · breakpoint | comfortable 48px row / compact 36px · ≥1280 3-pane · <1280 2-pane |
| 12 | Visual Contract | 정량 검증 (회귀 방지 규칙) | chip no-truncation · star opacity>0.5 · textStyle fontSize 단조 · unread Δcontrast ≥ 4.5 |
| 13 | Critique (Pre-mortem) | 실패 시나리오 · squint / scan / contrast test | squint: 1st gaze 식별 가능? · scan: 리듬 유지? · contrast: 배경-글씨 4.5:1? |
매 턴 아래 표를 갱신해 출력한다.
판정 기준:
출력 알고리즘 (discuss와 동일):
for el in elements[1..13]:
content = summarize(el)
pct = assess(content) # 숫자 먼저
level = classify(pct)
print(el, content, pct, level)
if level == 🔴 and el.index <= 12:
break # 첫 갭에서 멈춤 (13 Critique은 12 이후만)
각 결정마다 "제 제안: X. 이유: [근거]."를 먼저 던지고 사용자가 다른 판단이면 덮어쓰게 한다. 빈 질문 금지.
근거 우선순위: 0. 프로젝트 규약 (CLAUDE.md · DESIGN.md · rolePreset · feedback memory)
사용자가 결정 못 할 때 "모르면 이거" default를 제시한다. 디자이너가 초안을 뽑듯이.
예:
한 턴에 13개 다 채우지 않는다. 채운 만큼 산출 md에 append. 다음 턴에 계속.
각 그룹 🟢 시 "여기서 멈추고 Blueprint 넘길까?" 전환 제안 가능. 사용자가 원하면 중간 단계에서 종료.
결정 7(Hierarchy) 단계에서 ax 축 선택을 명시한다. 예:
textStyle: 'page' (22/600)surface: 'display' + textStyle: 'label' (weight+100)surface: 'raised' + focus ring이게 이 스킬의 핵심 가치 — 디자인 결정이 바로 축 조합으로 번역됨. LLM이 widget 쓸 때 이 매핑을 들고 간다.
결정 12(Contract)는 결정 4/7에서 유도된다:
대화 중 판정 기준을 다 Contract로 변환. 이게 회귀 방지 인프라.
점진 누적 파일:
docs/YYYY/YYYY-MM/YYYY-MM-DD/{slug}DesignThink.md
frontmatter:
---
id: {slug}DesignThink
type: decision
slug: {slug}DesignThink
title: {화면명} Design Think
tags: [design-think, ux, ui]
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: open | consumed
layer: design
---
본문 구조:
# {화면명} Design Think
## 1. Job
...
## 2. User & Context
...
## 3. Content Inventory
...
## 4. Information Priority
...
(진행된 만큼만 섹션 존재. 미정은 생략)
## Visual Contract (결정 12)
- [ ] rule 1
- [ ] rule 2
## Axis Mapping
| 결정 | ax 축 |
|---|---|
| L1 title | textStyle: 'page' |
| unread | surface: 'display' + textStyle: 'label' |
같은 파일에 반복 append. updated 필드 갱신.
→ /blueprint 전환: 결정 1~6 (WHY+WHAT) 전부 🟢 · 결정 7 (Hierarchy) 🟡 이상 — Blueprint는 6부터 시작하지만 7이 있어야 Phase 3 컴포넌트 선택이 자동 됨.
→ /go 전환: 18 전부 🟢 · 912 🟡 이상 — 구현 시 States/Contract가 누락 없게.
중단 OK: 사용자가 "여기까지" 하면 중단. 저장된 섹션만 남기고 종료. 다음 세션에 /design-think {slug} 로 이어가기.
결정 1~6 🟢, 7 🟡
제 판단: /blueprint 전환. 이유: Blueprint Phase 3 (부품 매칭)에 Hierarchy L1~L4 spec과 Priority 매트릭스가 feed 가능 상태.
Axis 매핑 미리 박힘:
| 결정 | 축 |
|---|---|
| L1 page title | textStyle:'page' |
| unread row | surface:'display' + textStyle:'label' |
| ...
진행할까요? 아니면 7~9를 더 채울까요?
| 기법 | 언제 |
|---|---|
| Squint Test | Hierarchy 검증. 눈을 가늘게 떴을 때 1st gaze가 여전히 식별되는가 |
| 5-second Test | Job 검증. 5초 보고 "뭐하는 화면이야?"에 답할 수 있는가 |
| Content-first Sizing | Content 단계. 데이터 실측 → 너비 먼저 결정 |
| Inverse Pyramid | Priority 단계. 역피라미드 3층으로 강제 |
| Gestalt (근접·유사·연속) | Layout 단계. 관련 요소 근접 배치 |
| WCAG Contrast | Hierarchy 단계. 모든 텍스트 ≥ 4.5:1 (large text 3:1) |
| Pre-mortem | Critique 단계. "이게 실패한다면 왜?" |
| Reference Audit (브랜드 말고 기능만) | 비슷한 앱 3개가 공통으로 하는 패턴 → 업계 합의 |
⛔ AI가 임의 종료 판단하지 않는다.