스케치
사용자가 디자인 방향을 미리 확인한 후 결정하고 싶을 때 이 스킬을 사용하십시오 — 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 설명과 스크린샷 경로를 반환합니다 — 순수 소스 검사로는 놓치는 레이아웃 버그(예: 조용히 실패한 글꼴 임포트, 무너진 flex 컨테이너)를 잡아냅니다. 각 변형이 올바르게 보일 때까지 수정하고 다시 탐색하십시오.
기본 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", "## 변형: 차분한 편집\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로 설치하십시오.