Sketch
사용자가 하나의 디자인 방향을 확정하기 전에 디자인 방향을 먼저 보고 싶어할 때 이 스킬을 사용하세요 — UI/UX 아이디어를 일회성 HTML 목업으로 탐색하는 것입니다. 목표는 2~3개의 대화형 변형을 생성하여 사용자가 시각적 방향을 나란히 비교할 수 있도록 하는 것이지, 배포 가능한 코드를 만드는 것이 아닙니다.
사용자가 다음과 같은 말을 할 때 이 스킬을 불러오세요: "이 화면 스케치해줘", "X가 어떻게 보일지 보여줘", "레이아웃 A와 B를 비교해줘", "이 UI에 대한 2~3가지 버전을 줘", "몇 가지 변형을 보고 싶어", "만들기 전에 목업을 해줘".
사용하지 말아야 할 때
- 사용자가 프로덕션 컴포넌트를 원할 때 —
claude-design을 사용하거나 제대로 빌드하세요 - 사용자가 정교한 일회성 HTML 아티팩트(랜딩 페이지, 덱)를 원할 때 —
claude-design - 사용자가 다이어그램을 원할 때 —
excalidraw,architecture-diagram - 디자인이 이미 확정되었을 때 — 그냥 빌드하세요
전체 GSD 시스템이 설치된 경우
gsd-sketch가 형제 스킬로 나타난다면 (npx get-shit-done-cc --hermes로 설치), 전체 워크플로우를 위해 **gsd-sketch**를 우선 사용하세요: MANIFEST가 있는 영구적 .planning/sketches/, 프론티어 모드 분석, 과거 스케치 간 일관성 감사, GSD의 나머지 부분과의 통합. 이 스킬은 독립형 경량 버전입니다 — 상태 관리 없이 일회성 스케치를 위한 것입니다.
핵심 방법
수집 → 변형 → 대결 → 승자 선택 (또는 반복)
1. 수집 (사용자가 이미 충분히 정보를 줬다면 건너뛰세요)
변형을 생성하기 전에 세 가지를 물어보세요 — 한 번에 하나씩, 한꺼번에 묻지 마세요:
- 느낌. "이게 어떤 느낌이어야 할까요? 형용사, 감정, 분위기." — *"차분한, 편집적인, Linear 같은"*이 *"미니멀"*보다 더 많은 정보를 줍니다.
- 참고 자료. "상상하시는 느낌을 포착한 앱, 사이트, 제품이 있나요?" — 실제 참고 자료가 추상적인 설명보다 낫습니다.
- 핵심 동작. "이 화면에서 사용자가 하는 가장 중요한 단일 동작은 무엇인가요?" — 변형들은 모두 이것을 잘 처리해야 합니다. 그렇지 않으면 장식에 불과합니다.
각 질문에 대해 다음 질문 전에 간단히 답변을 되돌려주세요. 사용자가 이미 세 가지를 모두 먼저 제공했다면 바로 변형으로 건너뛰세요.
2. 변형 (2~3개, 절대 1개, 드물게 4개 이상)
한 번에 2~3개의 변형을 만드세요. 각 변형은 완전하고 독립적인 HTML 파일입니다. 변형을 설명하지 말고 만드세요. 요점은 비교입니다.
각 변형은 서로 다른 디자인 입장을 취해야 하며, 단순히 픽셀 값만 달라서는 안 됩니다. 세 가지 좋은 변형 축:
- 밀도: 조밀함 / 여유로움 / 초조밀 (대조되는 두 극단 선택)
- 강조: 콘텐츠 우선 / 액션 우선 / 도구 우선
- 미학: 편집적 / 실용적 / 유쾌함
- 레이아웃: 단일 칼럼 / 사이드바 / 분할 창
- 기반: 카드 기반 / 콘텐츠 중심 / 문서 스타일
하나의 축을 선택하고 그로부터 분기하세요. 강조 색상만 다른 두 변형은 낭비입니다 — 사용자가 구분할 수 없습니다.
변형 이름: 입장을 설명하되 숫자는 사용하지 마세요.
sketches/
├── 001-calm-editorial/
│ ├── index.html
│ └── README.md
├── 001-utilitarian-dense/
│ ├── index.html
│ └── README.md
└── 001-playful-split/
├── index.html
└── README.md
3. 실제 HTML로 만들기
각 변형은 단일 자체 포함 HTML 파일입니다:
- 인라인
<style>— 빌드 단계 없음, 외부 CSS 없음 - 시스템 폰트 또는
<link>를 통한 하나의 Google Font - CDN을 통한 Tailwind (
<script src="https://cdn.tailwindcss.com"></script>) 가능 - 현실적인 가짜 콘텐츠 — 실제 문장, 실제 이름, "Lorem ipsum" 사용 금지
- 대화형: 링크 클릭 가능, 호버 실제 적용, 최소 하나의 상태 전환(열기/닫기, 필터, 토글). 정적인 이미지는 엉성한 애니메이션보다 더 나쁜 스파이크입니다.
브라우저에서 열어보세요. 깨져 보이면 사용자에게 보여주기 전에 수정하세요.
시각적으로 변형 확인 — Hermes의 브라우저 도구를 사용하세요. HTML만 작성하고 렌더링을 기대하지 마세요. 각 변형을 불러와서 살펴보세요:
browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="레이아웃이 깔끔하고 읽기 쉬운가요? 눈에 띄는 버그가 있나요 (텍스트 겹침, 스타일 없는 요소, 깨진 이미지)?")
browser_vision은 페이지에 실제로 있는 내용에 대한 AI 설명과 스크린샷 경로를 반환합니다 — 순수 소스 검사로는 놓칠 수 있는 레이아웃 버그(예: 폰트 임포트가 조용히 실패, 플렉스 컨테이너 붕괴)를 잡아냅니다. 각 변형이 올바르게 보일 때까지 수정하고 다시 탐색하세요.
빠른 시작을 위한 기본 CSS 리셋 + 시스템 폰트 스택:
<style>
* { box-sizing: border-box; margin: 0; padding: 0; }
body {
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
"Helvetica Neue", Arial, sans-serif;
-webkit-font-smoothing: antialiased;
color: #1a1a1a;
background: #fafafa;
line-height: 1.5;
}
</style>
4. 변형 README
각 변형의 README.md는 다음 질문에 답합니다:
## 변형: {입장 이름}
### 디자인 입장
이 변형을 이끄는 원칙을 한 문장으로.
### 핵심 선택
- 레이아웃: ...
- 타이포그래피: ...
- 색상: ...
- 상호작용: ...
### 트레이드오프
- 강점: ...
- 약점: ...
### 최적 대상
- 이 변형이 실제로 서비스하는 사용자 또는 사용 사례 종류
5. 대결
모든 변형이 완성되면 비교표로 제시하세요. 단순히 나열하지 말고 의견을 제시하세요:
## 홈 화면에 대한 세 가지 접근
| 차원 | 차분한 편집적 | 실용적 조밀 | 유쾌한 분할 |
|-----------|----------------|-------------------|---------------|
| 밀도 | 낮음 | 높음 | 중간 |
| 주요 액션 가시성 | 낮음 | 높음 | 중간 |
| 스캔 용이성 | 높음 | 중간 | 낮음 |
| 느낌 | 차분하고 신뢰감 | 날카롭고 도구적 | 매력적이고 활기참 |
**내 의견:** 파워 유저에게는 실용적 조밀, 콘텐츠 중심 사용자에게는 차분한 편집적. 유쾌한 분할이 가장 약함 — 둘 다 시도하다가 어느 것에도 전념하지 못함.
사용자가 승자를 선택하거나, 두 개를 결합하여 하이브리드를 만들거나, 다른 라운드를 요청하게 하세요.
테마 지정 (프로젝트에 시각적 아이덴티티가 있을 때)
사용자에게 기존 테마(색상, 폰트, 토큰)가 있다면 공유 토큰을 sketches/themes/tokens.css에 넣고 각 변형에서 @import하세요. 토큰은 최소한으로 유지하세요:
/* sketches/themes/tokens.css */
:root {
--color-bg: #fafafa;
--color-fg: #1a1a1a;
--color-accent: #0066ff;
--color-muted: #666;
--radius: 8px;
--font-display: "Inter", sans-serif;
--font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}
일회성 스케치를 지나치게 토큰화하지 마세요 — 보통 세 가지 색상과 하나의 폰트면 충분합니다.
상호작용 기준
사용자가 다음을 할 수 있을 때 스케치는 충분히 대화형입니다:
- 기본 액션을 클릭하면 눈에 띄는 일이 발생함 (상태 변경, 모달, 토스트, 탐색 흉내)
- 의미 있는 상태 전환 하나를 볼 수 있음 (리스트 필터, 모드 토글, 패널 열기/닫기)
- 인식 가능한 어포던스에 호버 가능 (버튼, 행, 탭)
그 이상은 일회성에 과도한 엔지니어링입니다. 그 이하는 스크린샷입니다.
프론티어 모드 (다음에 무엇을 스케치할지 선택)
이미 스케치가 존재하고 사용자가 "다음에 무엇을 스케치할까요?"라고 물으면:
- 일관성 격차 — 서로 다른 스케치의 두 승리 변형이 아직 결합되지 않은 독립적 선택을 함
- 스케치되지 않은 화면 — 언급되었지만 탐색되지 않음
- 상태 커버리지 — 해피 패스는 스케치되었지만, 빈/로딩/에러/1000개 항목 상태는 없음
- 반응형 격차 — 하나의 뷰포트에서 검증됨; 모바일/초광각에서 유지되는가?
- 상호작용 패턴 — 정적 레이아웃은 있음; 전환, 드래그, 스크롤 동작은 없음
2~4개의 이름 있는 후보를 제안하세요. 사용자가 선택하게 하세요.
출력
- 레포지토리 루트에
sketches/(또는 사용자가 GSD 규칙을 사용한다면.planning/sketches/) 생성 - 변형당 하나의 하위 디렉토리:
NNN-stance-name/index.html+README.md - 사용자에게 여는 방법 알려주기: macOS에서는
open sketches/001-calm-editorial/index.html, Linux에서는xdg-open, Windows에서는start - 변형은 일회성으로 유지하세요 — 보존할 필요를 느낀 스케치는 에셋으로 큐레이션하지 말고 실제 프로젝트 코드로 승격해야 합니다
하나의 변형에 대한 일반적인 도구 시퀀스:
terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="이게 어떻게 보이나요? 명백한 레이아웃 문제가 있나요?")
각 변형에 대해 반복한 후 비교표를 제시하세요.
저작자 표시
GSD (Get Shit Done) 프로젝트의 /gsd-sketch 워크플로우에서 수정됨 — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). 전체 GSD 시스템은 영구적 스케치 상태, 테마/변형 패턴 참조, 일관성 감사 워크플로우를 제공합니다. npx get-shit-done-cc --hermes --global로 설치하세요.