designpaca 초기 구현 — 스킬 · 설치 CLI · 배포 파이프라인

웹 디자인 파이프라인 스킬과 이를 5개 에이전트에 설치하는 CLI 를 담은 모노레포.

스킬 (packages/skill)
- SKILL.md 261줄 + 참조 문서 16개 3,349줄. progressive disclosure 로
  본문은 절차와 인덱스만, 지식은 references/ 로 분리
- 0~6단계 파이프라인. 규모에 따라 전체·연장·국소 세 경로로 분기
- 하드 게이트 12개는 grep·카운트로 검증 가능한 것만. 취향 판단은 제외
- 미학 프리셋 5종, AI 슬롭 지문 목록, 한글 조판 규칙,
  SVG 필터·three.js·인터랙티브 모션·HTML-in-Canvas 실전 지침

설치 CLI (packages/cli, packages/core)
- npx designpaca 온보딩 TUI. Claude Code · Codex · Cursor · Windsurf · AGENTS.md
- 매니페스트에 설치 시점 해시를 기록해 사용자가 고친 파일은 update 가 건너뛴다
- 타깃별로 본문의 references/ 경로를 실제 설치 위치로 재작성
- AGENTS.md 는 항상 로드되므로 본문 대신 303자 포인터만 주입
- Windsurf 는 12,000자 상한 초과 시 설치를 차단

배포 (build/ci, .forgejo/workflows)
- 태그 v* → 검사·테스트·빌드 → npmjs 배포 + Forgejo 레지스트리 미러
  → draft 릴리스 → Cloudflare Pages. 재실행 멱등

근거 (research/)
- 약 250개 웹 소스 조사 결과와 도그푸딩 검증 2건. 스킬의 모든 수치는 여기서 나온다

테스트 22개 통과 (core 16 · cli 6)
This commit is contained in:
Yun Chan 2026-08-20 10:48:00 +09:00
commit 8808c672dc
135 changed files with 38838 additions and 0 deletions

View file

@ -0,0 +1,750 @@
# 01. 로컬 설치 스킬 전수 해부
작성일: 2026-08-20
조사 방법: 각 `SKILL.md` 파일을 실제로 읽고 분석. 빌트인 스킬은 Skill 도구로 로드해 본문을 직접 확인.
원문 인용은 모두 `>` 또는 따옴표로 표기하고 출처 경로를 병기한다.
---
## 0. 조사 범위와 확인 결과
### 실제로 읽은 파일
| 스킬 | 경로 | 바이트 | 줄 수 |
|---|---|---|---|
| design-taste-frontend | `C:\Users\encep\.agents\skills\design-taste-frontend\SKILL.md` | 88,459 | 1,206 |
| design-taste-frontend-v1 | `C:\Users\encep\.agents\skills\design-taste-frontend-v1\SKILL.md` | 21,421 | 226 |
| high-end-visual-design | `C:\Users\encep\.agents\skills\high-end-visual-design\SKILL.md` | 10,659 | - |
| minimalist-ui | `C:\Users\encep\.agents\skills\minimalist-ui\SKILL.md` | 7,986 | - |
| industrial-brutalist-ui | `C:\Users\encep\.agents\skills\industrial-brutalist-ui\SKILL.md` | 8,548 | - |
| gpt-taste | `C:\Users\encep\.agents\skills\gpt-taste\SKILL.md` | 7,931 | - |
| imagegen-frontend-web | `C:\Users\encep\.agents\skills\imagegen-frontend-web\SKILL.md` | 37,841 | 987 |
| imagegen-frontend-mobile | `C:\Users\encep\.agents\skills\imagegen-frontend-mobile\SKILL.md` | 41,791 | 1,465 |
| image-to-code | `C:\Users\encep\.agents\skills\image-to-code\SKILL.md` | 37,670 | 1,228 |
| redesign-existing-projects | `C:\Users\encep\.agents\skills\redesign-existing-projects\SKILL.md` | 15,238 | - |
| stitch-design-taste | `C:\Users\encep\.agents\skills\stitch-design-taste\SKILL.md` (+ `DESIGN.md` 12,174) | 12,035 | - |
| brandkit | `C:\Users\encep\.agents\skills\brandkit\SKILL.md` | 16,790 | 798 |
| full-output-enforcement | `C:\Users\encep\.agents\skills\full-output-enforcement\SKILL.md` | 2,641 | - |
| graphify | `C:\Users\encep\.claude\skills\graphify\SKILL.md` | 51,297 | 1,242 |
| frontend-design (공식) | `C:\Users\encep\.claude\plugins\marketplaces\anthropic-agent-skills\skills\frontend-design\SKILL.md` | - | - |
| skill-creator (공식) | `...\anthropic-agent-skills\skills\skill-creator\SKILL.md` | - | 486 |
| artifact-design (빌트인) | 파일 없음. Skill 도구로 본문 로드해 확인 | - | - |
| dataviz (빌트인) | SKILL.md 파일 없음. `references/`·`scripts/`만 디스크에 추출됨 | - | - |
### 확인 못한 것
- **`artifact-design` / `dataviz` / `artifact-diagramming` / `artifact-capabilities`의 SKILL.md 원본 파일**: Claude Code 바이너리에 임베드되어 있어 파일시스템에서 찾지 못했다. `find`로 전 사용자 디렉터리를 훑었으나 없음. 다만 **Skill 도구로 호출하면 본문이 컨텍스트에 로드되므로 내용은 직접 읽었다.** dataviz는 `C:\Users\encep\AppData\Local\Temp\claude\bundled-skills\2.1.235\a44f7fbb33676b5b8599b1fc53d4b74e\dataviz\` 아래에 `references/*.md` 7개와 `scripts/validate_palette.{js,py}`가 실제로 추출되어 있다.
- **`.agents/skills` 전체에서 `references/` 서브디렉터리를 가진 디자인 스킬은 0개.** 유일하게 `object-separation`(디자인 스킬 아님)만 `references/model-notes.md`를 가진다. 즉 **로컬에 설치된 커뮤니티 디자인 스킬은 전부 단일 파일 SKILL.md 구조**다. 이는 뒤에서 다룰 핵심 발견이다.
---
## 1. 프론트매터 구조 비교표
| 스킬 | `name` | `description` | 그 외 필드 | 설명 길이(문자) |
|---|---|---|---|---|
| design-taste-frontend | O | O | 없음 | 약 230 |
| design-taste-frontend-v1 | O | O | 없음 | 약 210 |
| high-end-visual-design | O | O | 없음 | 약 175 |
| minimalist-ui | O | O | 없음 | 약 125 |
| industrial-brutalist-ui | O | O | 없음 | 약 250 |
| gpt-taste | O | O | 없음 | 약 300 |
| imagegen-frontend-web | O | O | 없음 | 약 620 |
| imagegen-frontend-mobile | O | O | 없음 | 약 610 |
| image-to-code | O | O | 없음 | 약 500 |
| redesign-existing-projects | O | O | 없음 | 약 190 |
| stitch-design-taste | O | O | 없음 | 약 195 |
| brandkit | O | O | 없음 | 약 440 |
| full-output-enforcement | O | O | 없음 | 약 190 |
| graphify | O | O | **`trigger: /graphify`** | 약 200 |
| codex-image | O | O (한국어) | 없음 | 약 350 |
| frontend-design (공식) | O | O | **`license: Complete terms in LICENSE.txt`** | 약 175 |
| skill-creator (공식) | O | O | 없음 | 약 240 |
| canvas-design (공식) | O | O | `license` | 약 230 |
| algorithmic-art (공식) | O | O | `license` | 약 260 |
| web-artifacts-builder (공식) | O | O | `license` | 약 240 |
| discernment-nudge (공식) | O | O (YAML 블록 스칼라 `>`) | `license` | 매우 김 |
### 발견 1: 프론트매터는 사실상 `name` + `description` 2개뿐
**13개 커뮤니티 디자인 스킬 전부 `name``description`만 쓴다.** `allowed-tools`, `disable-model-invocation`, `paths`, `metadata`, `context: fork` 같은 Claude Code 확장 필드를 쓰는 디자인 스킬은 한 개도 없었다. 이유는 명확하다. 이 스킬들은 Claude Code 전용이 아니라 Codex·Cursor 등에서도 돌아가야 하는 "휴대용" 스킬이고, Agent Skills 오픈 스펙이 허용하는 필드는 6개(`name`, `description`, `license`, `compatibility`, `metadata`, `allowed-tools`)뿐이기 때문이다.
### 발견 2: `trigger:` 는 스펙에 없는 필드다
`graphify`의 프론트매터:
```yaml
---
name: graphify
description: "any input (code, docs, papers, images, videos) to knowledge graph. Use when user asks any question about a codebase, documents, or project content - especially if graphify-out/ exists, treat the question as a /graphify query."
trigger: /graphify
---
```
출처: `C:\Users\encep\.claude\skills\graphify\SKILL.md`
`trigger`는 Agent Skills 스펙에도 Claude Code 프론트매터 레퍼런스에도 없다. Claude Code는 알 수 없는 키를 무시하지만, **claude.ai 업로드나 `package_skill.py` 패키징 시에는 하드 에러**가 난다. designpaca에서 절대 흉내내면 안 되는 패턴이다. (03-format-specs.md 참조)
### 발견 3: 디렉터리명이 곧 커맨드명
`.claude/skills/graphify/`에 있으면 `/graphify`, `.agents/skills/design-taste-frontend/`에 있으면 그 이름이 커맨드가 된다. 프론트매터 `name`은 개인/프로젝트 스킬에서는 **표시 라벨일 뿐이고 커맨드명을 바꾸지 못한다.** 플러그인 스킬에서만 `name`이 커맨드의 마지막 세그먼트를 결정한다.
---
## 2. description 작성 기법 분류
로컬 스킬들의 description을 4가지 패턴으로 분류할 수 있다.
### 패턴 A: 도메인 선언형 (짧음, 트리거 정확도 낮음)
> `description: Clean editorial-style interfaces. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.`
> — minimalist-ui
"무엇을 하는가"만 있고 "언제 쓰는가"가 없다. 사용자가 "미니멀한 랜딩 만들어줘"라고 해도 트리거될지 불확실하다. **Anthropic 공식 베스트 프랙티스가 명시적으로 지적하는 실패 유형이다.**
### 패턴 B: 용도 명시형 (권장)
> `description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated. Real design systems when applicable, audit-first on redesigns, strict pre-flight check.`
> — design-taste-frontend
"landing pages, portfolios, and redesigns"라는 **구체적 용도 키워드**가 앞쪽에 있다. 이것이 매칭의 핵심이다.
### 패턴 C: 배제 조건 포함형 (가장 정교함)
> `description: ... Codex CLI 내장 image_gen 도구(gpt-image-2 = "imagegen2")를 ChatGPT 구독 인증으로 호출하며 OpenAI API 키가 필요 없다. **벡터/SVG/코드 네이티브 아이콘이나 로고 시스템 확장에는 쓰지 않는다.**`
> — codex-image (강조는 필자)
**"이럴 땐 쓰지 마라"를 description에 적는다.** 과잉 트리거를 막는 유일하게 검증된 방법. `refactor-governance`도 같은 기법을 쓴다:
> `Read-only lookup, investigation, explanation, or answering questions about the code is NOT a trigger — the gated workflow applies only when a file will be changed.`
### 패턴 D: 리터럴 발화 나열형 (한국어 스킬에서 특히 효과적)
> `"이미지 생성해", "이미지 만들어", "일러스트 만들어", "그림 그려줘", "이미지를 생성", "generate an image", "create an illustration", "Codex로 이미지 만들어" 같은 요청에 자동으로 트리거.`
> — codex-image
**사용자가 실제로 타이핑할 문장을 그대로 박아넣는다.** 다국어 환경에서 특히 중요하다. designpaca가 한국어 사용자용이라면 이 기법은 필수다.
### 패턴 E: description 안에 규칙을 넣는 반칙형
> `description: ... CRITICAL OUTPUT RULE — generate ONE separate horizontal image FOR EVERY section. A landing page with 8 sections produces 8 images. Never compress multiple sections into one image. ...`
> — imagegen-frontend-web (약 620자)
description에 **본문 규칙을 밀어넣는다.** 이유: description은 항상 컨텍스트에 있으므로 본문이 로드되기 전에도 모델이 그 규칙을 본다. 하지만 대가가 크다.
- Claude Code는 `description` + `when_to_use` 합쳐 **1,536자에서 잘라낸다.**
- 스킬 목록 전체가 예산(기본 컨텍스트 윈도의 1%)을 넘으면 **설명이 더 짧게 잘린다.**
- Agent Skills 스펙 상한은 1,024자.
620자짜리 description은 스킬이 몇 개 없을 때만 안전하다. designpaca는 이 사용자의 환경(스킬 20개 이상)에서 돌아야 하므로 **200~350자 범위가 현실적 상한**이다.
---
## 3. 본문 분량·구조 비교표
| 스킬 | 줄 수 | 섹션 수 | 구조 | 코드 예시 | references 분리 |
|---|---|---|---|---|---|
| design-taste-frontend | 1,206 | 15 + 부록 3 | 번호 섹션 + 표 + 체크리스트 + 부록 | 3개 캐노니컬 TSX 스켈레톤 | 없음 (부록으로 인라인) |
| design-taste-frontend-v1 | 226 | 10 | 번호 섹션 | 없음 (클래스명만) | 없음 |
| high-end-visual-design | ~200 | 8 | 번호 섹션 + 최종 체크리스트 | 없음 (Tailwind 클래스 인라인) | 없음 |
| minimalist-ui | ~120 | 8 | 번호 섹션 | 없음 (hex/CSS 값 인라인) | 없음 |
| industrial-brutalist-ui | ~130 | 8 | 번호 섹션 + 아키타입 분기 | CSS 스니펫 2개 | 없음 |
| gpt-taste | ~110 | 8 | 번호 섹션 + `<design_plan>` 게이트 | JSX 한 줄 예시 | 없음 |
| imagegen-frontend-web | 987 | 13+ | **HARD RULE 선두 배치** + 조합 엔진 | 없음 (이미지 스킬) | 없음 |
| imagegen-frontend-mobile | 1,465 | 37 | 번호 규칙 나열 + 카테고리 바이어스 | 없음 | 없음 |
| image-to-code | 1,228 | 38 | 번호 규칙 나열 + 예시 해석 | 없음 | 없음 |
| redesign-existing-projects | ~180 | 감사 카테고리 8 + 업그레이드 4 | **"문제 → 고치는 법" 페어 나열** | 없음 | 없음 |
| stitch-design-taste | ~300 | 9 + 출력 템플릿 | **메타 스킬** (DESIGN.md를 생성) | 출력 템플릿 마크다운 | `DESIGN.md` 동봉 |
| brandkit | 798 | 20+ | 시각 모드 8종 + 프롬프트 템플릿 | 프롬프트 템플릿 | 없음 |
| full-output-enforcement | ~60 | 5 | 금지 목록 + 프로세스 | 중단 마커 포맷 | 없음 |
| frontend-design (공식) | ~40 | 6 | **산문(prose)** | 없음 | 없음 |
| skill-creator (공식) | 486 | 20+ | 워크플로 + JSON 스키마 | JSON/bash | `references/schemas.md`, `agents/*.md`, `scripts/*.py` |
| dataviz (빌트인) | ~80 | 5 | **인덱스 + 절차 7단계** | 없음 | `references/` 7개 + `scripts/` 2개 |
### 발견 4: 커뮤니티 디자인 스킬은 전부 단일 파일, 공식 스킬만 분리
Anthropic 공식 스킬(skill-creator, dataviz, canvas-design, algorithmic-art)은 `references/`, `scripts/`, `assets/`를 쓴다. 커뮤니티 디자인 스킬 13개는 **하나도 안 쓴다.** design-taste-frontend는 88KB 단일 파일이다.
이게 왜 문제인가. Anthropic 공식 가이드는 이렇게 말한다:
> "Keep SKILL.md body under 500 lines for optimal performance"
> — Skill authoring best practices
> "Note that the agent will load this entire file once it's decided to activate a skill. Consider splitting longer `SKILL.md` content into referenced files."
> — Agent Skills Specification
design-taste-frontend는 1,206줄. 발동되는 순간 **약 22,000토큰이 컨텍스트에 영구 상주한다.** Claude Code 문서:
> "When you or Claude invoke a skill, the rendered `SKILL.md` content enters the conversation as a single message and stays there for the rest of the session."
게다가 자동 컴팩션 시:
> "Claude Code re-attaches the most recent invocation of each skill after the summary, keeping the first 5,000 tokens of each."
**88KB 스킬의 앞 5,000토큰만 살아남는다.** design-taste-frontend에서 5,000토큰이면 Section 0~4.2 정도까지다. **가장 중요한 Section 9 (AI TELLS)와 Section 14 (PRE-FLIGHT CHECK)는 컴팩션 후 사라진다.**
이것이 designpaca 설계에서 가장 중요한 구조적 교훈이다.
### 발견 5: 자기 자신의 구조를 명시하지만 구현은 없는 "계약" 섹션
design-taste-frontend Section 12는 블록 라이브러리 스키마를 정의해놓고:
> **Status:** schema defined here. Blocks will be added iteratively. Do not freelance new blocks without following this schema.
그리고 파일 위치를 `skills/taste-skill/blocks/hero/asymmetric-split.md` 등으로 지정하는데, **실제로 그 디렉터리는 존재하지 않는다.** 존재하지 않는 파일을 가리키는 것은 모델을 혼란시킨다. 좋은 아이디어(progressive disclosure로 가는 길)를 절반만 실행한 사례다.
---
## 4. 프롬프트 기법 상세 비교
### 4.1 금지 규칙 표현법
세 가지 계보가 뚜렷하게 갈린다.
#### 계보 A: 절대 금지형 (커뮤니티 디자인 스킬 대부분)
> **NO em-dash (`—`) as a design element OR anywhere else.** ... **Em-dash (`—`) is COMPLETELY banned.** It is the LLM's signature stylistic crutch and it is the #1 visual Tell in production tests. **There is no "limited use" allowance, no "natural language frequency" allowance, no "in body copy is fine" allowance. None.**
> ...
> This rule is non-negotiable. **The agent has historically ignored em-dash limits when phrased as "use sparingly." The phrasing here is binary: zero em-dashes.**
> — design-taste-frontend §9.G
이 마지막 문장이 핵심이다. **저자는 "sparingly"라는 표현이 실패했음을 관찰하고 이진 규칙으로 바꿨다.** 그리고 그 이유를 스킬 안에 기록해뒀다. 이것이 이 문서 전체에서 가장 잘 쓰인 문장이다.
#### 계보 B: 조건부 오버라이드형 (design-taste-frontend의 대부분 + 유일하게 v2에만 있음)
> **THE LILA RULE:** The "AI Purple / Blue glow" aesthetic is **discouraged as a default**. ...
> **Override:** if the brand or brief explicitly asks for purple / violet / lila, embrace it. But execute with intent: consistent palette, harmonised neutrals, restrained gradients. Not generic AI gradient slop.
> — design-taste-frontend §4.2
v1은 같은 규칙을 이렇게 썼다:
> **THE LILA BAN:** The "AI Purple/Blue" aesthetic is **strictly BANNED**.
> — design-taste-frontend-v1 §3 Rule 2
**v1 → v2에서 "BAN"이 "discouraged as a default + Override"로 바뀌었다.** v2 문서 최상단이 이 철학을 선언한다:
> Every rule below is **contextual**. None of it fires automatically. First read the brief, then pull only what fits.
이것이 v1과 v2의 근본적 차이이며, designpaca가 채택해야 할 방향이다.
#### 계보 C: 이유 설명형 (Anthropic 공식)
> Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. ... **If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag** — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.
> — skill-creator, "Improving the skill" §3
**공식 가이드와 커뮤니티 디자인 스킬이 정면으로 충돌한다.** 이 긴장은 실재하며, designpaca는 입장을 정해야 한다. 필자의 판단은 05-recommendations.md에 정리했다.
### 4.2 다이얼(Dial) 시스템
design-taste-frontend / v1 / image-to-code / imagegen-* 가 모두 공유하는 발명품.
```
* **`DESIGN_VARIANCE: 8`** - 1 = Perfect Symmetry, 10 = Artsy Chaos
* **`MOTION_INTENSITY: 6`** - 1 = Static, 10 = Cinematic / Physics
* **`VISUAL_DENSITY: 4`** - 1 = Art Gallery / Airy, 10 = Cockpit / Packed Data
```
핵심 3요소:
1. **레벨별 구체적 CSS 정의** (§7): `8-10 (Asymmetric): Masonry layouts, CSS Grid with fractional units (grid-template-columns: 2fr 1fr 1fr), massive empty zones (padding-left: 20vw)`
2. **브리프 → 다이얼 매핑 표** (§1.A): "minimalist / clean / calm / editorial / Linear-style" → VARIANCE 5-6, MOTION 3-4, DENSITY 2-3
3. **다이얼로 게이팅되는 규칙**: `Centered Hero sections are avoided when DESIGN_VARIANCE > 4`, `Use when MOTION_INTENSITY > 5`
그리고 자기 일관성 검증 규칙:
> **"Motion claimed, motion shown."** If `MOTION_INTENSITY > 4`, the page must actually move ... A static page that claims `MOTION_INTENSITY: 7` is broken. Conversely, if you cannot ship working motion in the available scope, drop the dial to 3 and ship a clean static page.
또한 별칭 금지:
> Cross-references throughout this document refer to these exact variable names - **never invent aliases like `LAYOUT_VARIANCE` or `ANIM_LEVEL`.**
image-to-code는 다이얼을 9개로 늘렸다: `DESIGN_VARIANCE, VISUAL_DENSITY, ART_DIRECTION, IMPLEMENTATION_CLARITY, IMAGE_USAGE_PRIORITY, SPACING_GENEROSITY, ANALYSIS_PRECISION, IMAGE_GENERATION_EAGERNESS, UI_SIMPLICITY_DISCIPLINE`. 9개는 과하다. 3개가 인지 부하 대비 효과가 가장 좋다.
### 4.3 게이트(Gate) 패턴
출력 전에 반드시 통과해야 하는 관문.
**gpt-taste — `<design_plan>` 강제 출력:**
> ## 8. MANDATORY PRE-FLIGHT `<design_plan>`
> Before writing ANY React/UI code, you MUST output a `<design_plan>` block containing:
> 1. **Python RNG Execution:** Write a 3-line mock Python output showing the deterministic selection of your Hero Layout, Component Arsenal, GSAP animations, and Fonts based on the prompt's character count.
> 2. **AIDA Check:** ...
> 3. **Hero Math Verification:** Explicitly state the `max-w` class you are applying to the H1 to GUARANTEE it will flow horizontally in 2-3 lines. ...
> 4. **Bento Density Verification:** Prove mathematically that your grid columns and rows leave zero empty spaces ...
> 5. **Label Sweep & Button Check:** ...
> Only output the UI code after this rigorous verification is complete.
**design-taste-frontend — Design Read 한 줄 선언:**
> ### 0.B Output a one-line "Design Read" before generating
> Before any code, state in one line: **"Reading this as: \<page kind> for \<audience>, with a \<vibe> language, leaning toward \<design system or aesthetic family>."**
**high-end-visual-design — 실행 순서 5단계:**
> 1. **[SILENT THOUGHT]** Roll the Variance Engine (Section 3). ...
> 2. **[SCAFFOLD]** ... 3. **[ARCHITECT]** ... 4. **[CHOREOGRAPH]** ... 5. **[OUTPUT]** ...
### 4.4 기계적으로 검증 가능한 규칙
가장 강력한 발명. **"세어서 확인할 수 있는" 규칙**을 만든다.
> * **EYEBROW RESTRAINT (mandatory, the #1 violated rule in production tests).** ... Hard rule:
> - **Maximum 1 eyebrow per 3 sections.** Hero counts as 1. So a page with 9 sections may use at most 3 eyebrows total.
> - If section A has an eyebrow, the next 2 sections cannot have one.
> - **Pre-Flight Check is mechanical:** count instances of `uppercase tracking` (or similar small-caps mono labels above headlines) across all section components. **If count > ceil(sectionCount / 3), the output fails.**
> — design-taste-frontend §4.7
다른 기계적 규칙들:
- `ZIGZAG ALTERNATION CAP`: "Max 2 sections in a row with this image+text-split pattern. The 3rd consecutive image+text split is a Pre-Flight Fail."
- `MARQUEE MAX-ONE-PER-PAGE`
- `BENTO CELL COUNT RULE`: "A bento grid has EXACTLY as many cells as you have content for. 3 items → 3 cells"
- `Section-Layout-Repetition Ban`: "A landing page with 8 sections must use at least 4 different layout families."
- `Hero MUST fit in the initial viewport`: "headline max 2 lines on desktop, subtext max **20 words** AND max 3-4 lines"
- `HERO STACK DISCIPLINE (max 4 text elements)`
- gpt-taste: "The H1 MUST NEVER exceed 2 to 3 lines. 4, 5, or 6 lines is a catastrophic failure."
**주관적 취향 판단("세련되게")을 세는 규칙으로 번역한 것.** 이게 anti-slop 스킬의 진짜 기술이다.
### 4.5 조건부 발동 ("contextual" 규칙)
> ## 5. CONTEXT-AWARE PROACTIVITY
> These are tools, not defaults. Use them when the design read calls for them. **None of these fire automatically.**
> * **Liquid Glass / Glassmorphism:** Appropriate for premium consumer, Apple-adjacent, luxury brand, or media-overlay vibes. **Inappropriate for dashboards, public-sector, or "boring B2B."**
> — design-taste-frontend §5
그리고 모션 정당화 요구:
> * **MOTION MUST BE MOTIVATED (mandatory).** Before adding any animation, ask: "what does this animation communicate?" Valid answers: hierarchy, storytelling, feedback, state transition. **Invalid answer: "it looked cool".** GSAP everywhere because GSAP is available is amateur. ... **If you cannot articulate the reason in one sentence, drop the animation.**
### 4.6 랜덤화 / 반복 회피 장치
같은 결과물이 반복되는 것을 막는 세 가지 접근.
**gpt-taste — 가짜 Python RNG:**
> ## 1. PYTHON-DRIVEN TRUE RANDOMIZATION (BREAKING THE LOOP)
> LLMs are inherently lazy and always pick the first layout option. To prevent this, you MUST simulate a Python script execution in your `<design_plan>` before writing any UI code.
> Use a deterministic seed (e.g., character count of the user prompt modulo math) to simulate `random.choice()` and strictly select: 1 Hero Architecture, 1 Typography Stack, 3 Unique Component Architectures, 2 Advanced GSAP Paradigms.
> **You are forbidden from defaulting to the same UI twice.**
**high-end-visual-design — Variance Engine:**
> ## 3. THE CREATIVE VARIANCE ENGINE
> Before writing code, silently "roll the dice" and select ONE combination from the following archetypes ...
> ### A. Vibe & Texture Archetypes (Pick 1) — Ethereal Glass / Editorial Luxury / Soft Structuralism
> ### B. Layout Archetypes (Pick 1) — The Asymmetrical Bento / The Z-Axis Cascade / The Editorial Split
**design-taste-frontend — 세션 간 회전 규칙 (파일 없이):**
> **Palette-rotation rule:** if the previous premium-consumer project you generated used the beige+brass family, this one MUST use a different family. Do not ship the same warm-craft palette twice in a row.
> **Serif discipline**: ... Different serif from your previous project?
**이 세 번째 방식은 작동하지 않는다.** 모델은 이전 세션을 기억하지 못한다. "이전 프로젝트와 다르게"는 상태 저장 없이는 실현 불가능한 지시다. (Hallmark가 `.hallmark/log.json`으로 이 문제를 푼 것과 대조된다 → 02-prompt-techniques.md 기법 12)
### 4.7 코드 스켈레톤 제공
design-taste-frontend만 실제 작동 코드를 담는다. §5.A/5.B/5.C에 GSAP Sticky-Stack, Horizontal-Pan, Motion whileInView 스켈레톤 3개. 각각 뒤에 "Critical points"를 한 줄로 요약:
> Critical points: `start: "top top"`, `pin: true`, every card except the last is pinned, the scale/opacity transform is driven by the NEXT card's scroll trigger (so previous card shrinks as next one arrives).
그리고 Pre-Flight에서 이를 참조:
> - [ ] **GSAP sticky-stack / horizontal-pan** implemented per Section 5.A / 5.B canonical skeleton (`start: "top top"`, `pin: true`, correct scrub)?
이건 잘한 설계다. **"이렇게 하라"가 아니라 "이 코드를 써라"**이므로 재현성이 높다.
---
## 5. AI 슬롭 방지 장치 원문 목록
designpaca가 참조해야 할 실제 금지 항목들. 출처를 정확히 표기한다.
### 5.1 design-taste-frontend §9.F "Production-Test Tells (banned outright)"
이 섹션 서문:
> These patterns came out of real LLM-generated landing-page tests. They are the signatures the model defaults to when it tries to "look designed."
**히어로/상단:**
- `NO version labels in the hero.``V0.6`, `v2.0`, `BETA`, `INVITE-ONLY PREVIEW`, `EARLY ACCESS`, `ALPHA`
- `NO "Brand · No. 01"-style sub-eyebrows.` — "Marrow · No. 01 · The 6-quart" 타입
**섹션 번호·마이크로 라벨:**
- `NO section-number eyebrows.``00 / INDEX`, `001 · Capabilities`, `002 · Featured commission`, `06 · how it works`, `05 · The honest table`
- `NO 01 / 4-style pagination on images or bento tiles.` — "If the user can count, they don't need the label."
- `NO "Index of Work, 2018 - 2026"-style range labels`
**구분자·점:**
- `The middle-dot (·) is rationed. Maximum 1 per line in metadata strips.`
- `NO decorative colored status dots on every list/nav/badge.`
**대시·타이포 장식:**
- `NO em-dash (—) as a design element OR anywhere else.`
- `NO <br>-broken-and-italicized headlines` — "for thirty\<br\>*years.*"
- `NO vertical rotated text` — "INDEX OF WORK, 2018 - 2026" 90도 회전
- `NO crosshair / hairline grid lines as decoration.`
**가짜 제품 프리뷰:**
- `NO div-based fake product UI in the hero` — "It is the #1 LLM-design Tell."
- `NO fake version footers` — "v0.6.2-rc.1", "last sync 4s ago · main"
**마케팅 카피 텔:**
- `NO "Quietly in use at" / "Quietly trusted by"`
- `NO "From the field" / "Field notes" / "Currently on the bench" / "On our desks" style poetic labels` — "Reads as performative-craftsman."
- `NO "We respect the French ones"-style mock-humble industry-references`
- `NO weather / locale strips` — "LIS 14:23 · 18°C"
- `NO micro-meta-sentences under eyebrows.` — 예: *"Each of these is a feature we ship today, not a roadmap promise. The list will stay short on purpose."*
- `NO generic step labels.` — "Stage 1 / Stage 2 / Stage 3", "Phase 01 / Phase 02 / Phase 03", "Pass One / Pass Two / Pass Three"
**필·라벨·버전 스탬프:**
- `NO pills/labels/tags overlaid on images.`
- `NO photo-credit captions as decoration.``Field study no. 12 · Ines Caetano`, `Plate 03 · House archive`, `Frame XII · 35mm`
- `NO version footers on marketing pages.``v1.4.2`, `Build 0048`
- `NO "Reservation 412 of 800"-style live-stock counters`
**장식 텍스트 스트립:**
- `NO decoration text strip at hero bottom.``BRAND. MOTION. SPATIAL.`, `TYPE / FORM / MOTION`, `DESIGN · BUILD · SHIP`, `ESTD. 2018 · LISBON · ...`
- `NO floating top-right sub-text in section headings.`
**리스트·구분선·스코어:**
- `NO border-t + border-b on every row of a long list / spec table.`
- `NO scoring/progress bars with filled background tracks as comparison visuals.`
**로케일·시간·스크롤 큐:**
- `Locale / city-name / time / weather strips are banned for 99% of briefs.`
- `Scroll cues are banned.``Scroll`, `↓ scroll`, `Scroll to explore`, 애니메이션 마우스휠 아이콘. 이유가 훌륭하다: *"If the user has not scrolled yet, they are looking at the hero. They know what scroll is. The bottom of the viewport does not need a label."*
- `ZERO decorative status dots by default.`
### 5.2 design-taste-frontend §4.2 프리미엄 소비재 팔레트 금지 (hex 단위)
> **PREMIUM-CONSUMER PALETTE BAN (mandatory, second-most-recurring AI-tell):**
> - Backgrounds: `#f5f1ea`, `#f7f5f1`, `#fbf8f1`, `#efeae0`, `#ece6db`, `#faf7f1`, `#e8dfcb` (all "warm paper / cream / chalk / bone")
> - Accents: `#b08947`, `#b6553a`, `#9a2436`, `#9c6e2a`, `#bc7c3a`, `#7d5621` (all "brass / clay / oxblood / ochre")
> - Text: `#1a1714`, `#1a1814`, `#1b1814` (all "espresso / warm near-black")
>
> This palette is BANNED as the default reach for premium-consumer briefs. **Every premium-consumer site you have ever shipped uses this exact palette. The brand becomes invisible.**
그리고 대안을 회전 목록으로 제공한다: Cold Luxury / Forest / Black and Tan / Cobalt + Cream / Terracotta + Slate / Olive + Brick + Paper / Pure monochrome + single saturated pop.
**hex 코드 단위로 금지한 것은 로컬 스킬 중 이것뿐이다.** 매우 구체적이고 검증 가능하다.
### 5.3 design-taste-frontend §4.1 세리프 금지
> * **SERIF DISCIPLINE (VERY DISCOURAGED AS DEFAULT):**
> * "It feels creative / premium / editorial" is NOT a reason to reach for serif. **The agent's default mental model that "creative brief = serif" is the single most-tested AI tell in production rounds.**
> * **Specifically BANNED as defaults:** `Fraunces` and `Instrument_Serif` (the two LLM-favorite display serifs).
> * **EMPHASIS RULE:** ... Do NOT inject a random serif word into a sans headline (or vice versa) just to add visual interest. **Mixed-family emphasis is amateur.**
### 5.4 image-to-code §29 ANTI-AI-SLOP RULES
카테고리 5개로 분류한 것이 특징:
> ### Layout slop
> - one giant unreadable collage / endless centered sections / identical card rows repeated section after section / cloned left-text/right-image blocks / fake complexity without hierarchy / decorative empty space with no purpose / **cards-inside-cards-inside-cards** / giant rounded wrapper sections around everything / overcompartmentalized dashboard framing
>
> ### Visual slop
> - default purple/blue AI gradients / too many glowing edges / floating blobs everywhere / glassmorphism stacked without reason / random futuristic details with no structure / over-rendered noise that hides the layout
>
> ### Typography slop
> - giant heading + weak tiny subcopy / too many font moods / awkward line breaks / lazy all-caps everywhere / generic gradient headline tricks
>
> ### Content slop
> Avoid generic filler vibes like: unleash / elevate / revolutionize / next-gen / seamless / transformative platform
> Avoid fake brand slop: Acme / Nexus / Flowbit / Quantumly / NovaCore
> Avoid fake complexity slop: pseudo-enterprise control labels / decorative system markers / filler status microcopy / **fake operator / runtime / orchestration jargon unless truly central to the brand**
>
> ### Density slop
> - over-packed sections / card overload / tiny spacing between major sections / visually exhausting walls of content
### 5.5 imagegen-frontend-mobile §21 MOBILE ANTI-AI-TELLS
모바일 특화 목록. 특히:
> ### Layout AI tells
> - fake chart dashboard spam / repeated stat cards with no product reason / **a homepage that looks like 12 widgets fighting for attention** / cloned screens in a flow / giant empty cards with weak content / **phone-shaped websites instead of app screens**
>
> ### UI clutter tells
> - too many pills / too many badges / too many tiny labels / fake system markers / meaningless avatar rows / random chart inserts / **decorative toggles with no product meaning**
### 5.6 minimalist-ui §2 Absolute Negative Constraints
> - DO NOT use the "Inter", "Roboto", or "Open Sans" typefaces.
> - DO NOT use generic, thin-line icon libraries like "Lucide", "Feather", or standard "Heroicons".
> - DO NOT use Tailwind's default heavy drop shadows (`shadow-md`, `shadow-lg`, `shadow-xl`).
> - DO NOT use primary colored backgrounds for large elements or sections.
> - DO NOT use gradients, neon colors, or 3D glassmorphism (beyond subtle navbar blurs).
> - DO NOT use `rounded-full` (pill shapes) for large containers, cards, or primary buttons.
> - DO NOT use emojis anywhere in code, markup, text content, headings, or alt text.
> - DO NOT use generic placeholder names like "John Doe", "Acme Corp", or "Lorem Ipsum".
> - DO NOT use AI copywriting clichés: "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve".
### 5.7 high-end-visual-design §2 "ABSOLUTE ZERO" DIRECTIVE
> If your generated code includes ANY of the following, **the design instantly fails**:
> - **Banned Fonts:** Inter, Roboto, Arial, Open Sans, Helvetica.
> - **Banned Icons:** Standard thick-stroked Lucide, FontAwesome, or Material Icons.
> - **Banned Borders & Shadows:** Generic 1px solid gray borders. Harsh, dark drop shadows (`shadow-md`, `rgba(0,0,0,0.3)`).
> - **Banned Layouts:** Edge-to-edge sticky navbars glued to the top. Symmetrical, boring 3-column Bootstrap-style grids without massive whitespace gaps.
> - **Banned Motion:** Standard `linear` or `ease-in-out` transitions. Instant state changes without interpolation.
### 5.8 stitch-design-taste §9 Anti-Patterns (AI Tells)
DESIGN.md 산출물에 넣을 목록으로 규정:
> - No emojis anywhere / No `Inter` font / No generic serif fonts / No pure black (`#000000`) / No neon/outer glow shadows / No oversaturated accents / No excessive gradient text on large headers / No custom mouse cursors / No overlapping elements / No 3-column equal card layouts / No generic names ("John Doe", "Acme", "Nexus") / **No fake round numbers (`99.99%`, `50%`)** / No AI copywriting clichés / **No filler UI text: "Scroll to explore", "Swipe down", scroll arrows, bouncing chevrons** / No broken Unsplash links / No centered Hero sections (for high-variance projects)
### 5.9 gpt-taste §7 The Meta-Label Ban
> **The Meta-Label Ban:** BANNED FOREVER are labels like "SECTION 01", "SECTION 04", "QUESTION 05", "ABOUT US". Remove them entirely. **They look cheap and unprofessional.**
### 5.10 frontend-design (Anthropic 공식) — 3대 기본값 지목
공식 스킬은 금지 목록 대신 "현재 AI 디자인이 수렴하는 세 가지 룩"을 이름 붙여 지목한다:
> AI-generated design right now clusters around three looks: (1) a warm cream background (near #F4F1EA) with a high-contrast serif display and a terracotta accent; (2) a near-black background with a single bright acid-green or vermilion accent; (3) a broadsheet-style layout with hairline rules, zero border-radius, and dense newspaper-like columns. **All three are legitimate for some briefs, but they are defaults rather than choices, and they appear regardless of subject.** Where the brief pins down a visual direction, follow it exactly — the brief's own words always win, including when it asks for one of these looks. **Where it leaves an axis free, don't spend that freedom on one of these defaults.**
artifact-design(빌트인)은 여기에 더 붙인다:
> a purple-to-blue gradient hero on white; Inter or Space Grotesk as the "safe" face; emoji as section markers; everything centered; `rounded-lg` everywhere; accent bar/rail on rounded cards.
**"Where it leaves an axis free, don't spend that freedom on one of these defaults."** 이 한 문장이 커뮤니티 스킬의 200줄짜리 금지 목록과 같은 일을 한다. 표현 밀도의 차이가 극적이다.
### 5.11 브랜드킷 — 이미지 도메인 anti-generic
> # ANTI-GENERIC RULES
> Never make: random floating icons / generic startup gradients / overdesigned logos / meaningless blobs / messy layout collages / fake tiny UI / inconsistent logo marks / too many colors / cheap neon / stock-template brand boards / corporate PowerPoint slides / soulless SaaS dashboards
>
> **Make the design quieter, sharper, and more intentional.**
레퍼런스 사용 규칙도 훌륭하다:
> Do not copy: exact logo / exact brand name / exact composition / exact slogan / unique visual asset
> **Use references as quality training, not as templates.**
---
## 6. 스킬별 강점·약점
### design-taste-frontend (v2)
**잘하는 것**
- **브리프 추론 우선(§0)**: 유일하게 "먼저 읽고 나중에 만들라"를 1번 섹션에 놓았다. 나머지 스킬은 전부 미학을 먼저 선언한다.
- **조건부 규칙 철학**: "Every rule below is contextual. None of it fires automatically."
- **기계적 검증 규칙**: eyebrow 카운트, zigzag 캡, bento 셀 카운트 등 세서 확인 가능
- **실제 디자인 시스템 매핑(§2.A)**: Fluent / Material / Carbon / Polaris / Atlaskit / Primer / GOV.UK / USWDS를 브리프 유형에 매핑하고 부록에 실제 설치 명령어와 공식 문서 링크를 담았다. **"AI가 CSS를 즉흥 발명하는 것"을 막는 가장 실용적인 장치.**
- **범위 밖 선언(§13)**: "This skill is NOT for: Dashboards / Data tables / Multi-step forms / Code editors / Native mobile / Realtime collab UIs" 그리고 "If the brief is one of the above, **say so explicitly**, point to the right tool"
- **리디자인 프로토콜(§11)**: 모드 감지 → 감사 → 보존 규칙 → 현대화 레버 우선순위 → 결정 트리. SEO 마이그레이션을 "#1 redesign risk"로 지목한 것이 실전적이다.
- **오버라이드 경로**: 거의 모든 금지 규칙에 명시적 탈출구가 있다
**못하는 것**
- **88KB / 1,206줄**: 공식 권고(500줄)의 2.4배. 발동 시 약 22K 토큰 상주, 컴팩션 시 앞 5K만 생존 → **가장 중요한 §9와 §14가 날아간다**
- **references/ 분리 0**: 부록 A/B/C(설치 명령, 공식 문서 링크, Liquid Glass 근사법)는 명백히 참조 파일로 뺐어야 한다
- **Pre-Flight 체크박스 60개**: 매번 60개를 전부 정직하게 체크하는 것은 비현실적이다. 순위나 티어가 없다
- **§12 블록 라이브러리가 유령**: 존재하지 않는 파일 경로를 지시한다
- **세션 간 회전 규칙이 작동 불가**: "different serif from your previous project"는 상태 저장 없이는 실행 불가
- **`gsap` 의존**: §5.A/5.B가 GSAP 전제. §3.A는 Motion(framer-motion)을 기본으로 선언 → 스택 이중화
- **Next.js/React/Tailwind 고정**: Vue, Svelte, Astro, 바닐라 HTML에 대한 언급이 §3.A에 없다
### design-taste-frontend-v1
**잘하는 것**: 226줄로 짧다. 다이얼 시스템의 원형. §9 "Motion-Engine Bento Paradigm"의 5-카드 아키타입은 구체적이고 재현 가능하다.
**못하는 것**: 브리프 추론이 없다. 모든 규칙이 무조건 발동한다. "LILA BAN", "strictly BANNED"만 있고 오버라이드가 없다. 히어로 규율, eyebrow 규율, 카피 자가 감사가 전부 없다. 실전 테스트에서 나온 텔 목록(§9.F)이 없다.
### high-end-visual-design
**잘하는 것**
- **Double-Bezel(Doppelrand) 기법**이 구체적이다: 외곽 셸 `p-1.5 rounded-[2rem] ring-1 ring-black/5` + 내부 코어 `rounded-[calc(2rem-0.375rem)]` + `shadow-[inset_0_1px_1px_rgba(255,255,255,0.15)]`. **동심원 반경 계산까지 지시한다.**
- **Button-in-Button 화살표 패턴**: 재현 가능한 시그니처
- 각 레이아웃 아키타입마다 **모바일 붕괴 규칙을 함께 적었다** ("Mobile Collapse: Remove all rotations and negative-margin overlaps below 768px. Overlapping elements cause touch-target conflicts on mobile.")
- 성능 가드레일(§6)이 이유와 함께 적혀 있다: "Never apply blur filters to scrolling containers or large content areas — this causes continuous GPU repaints and severe mobile frame drops."
**못하는 것**: 브리프 읽기 없음. Awwwards 미학 하나만 강제한다. B2B, 공공, 접근성 우선 브리프에 재앙적이다. `rounded-[2rem]` squircle과 glass가 모든 프로젝트에 강요된다.
### minimalist-ui / industrial-brutalist-ui
**잘하는 것**
- **미학 하나에 완전히 커밋한다.** 그래서 hex 값, 폰트명, border 값까지 구체적으로 지정할 수 있다 (`border: 1px solid #EAEAEA`, `#FDEBEC` / 텍스트 `#9F2F2D`)
- industrial-brutalist는 **모드 선택을 강제한다**: "Pick ONE per project and commit to it. **Do not alternate or mix both modes within the same interface.**" 그리고 팔레트도: "Choose ONE substrate palette per project... **Never mix light and dark substrates within the same interface.**"
- industrial-brutalist §8.1의 그리드 기법이 영리하다: "Utilize `display: grid; gap: 1px;` with contrasting parent/child background colors to generate mathematically perfect, razor-thin dividing lines without complex border declarations."
- 시맨틱 태그 지시: `<data>`, `<samp>`, `<kbd>`, `<output>`, `<dl>`
**못하는 것**: 스타일 스킬이지 디자인 스킬이 아니다. 브리프를 읽지 않는다. designpaca가 여러 미학을 다루려면 이건 "테마 파일"로 흡수되어야 할 형태다.
### gpt-taste
**잘하는 것**
- **모델의 실패를 이름 붙여 지목한다**: "Standard LLMs possess severe statistical biases: they generate massive 6-line wrapped headings **by using narrow containers**, leave ugly empty gaps in bento grids, use cheap meta-labels, output invisible button text, and endlessly repeat the same Left/Right layouts."
- **원인까지 짚는다**: 6줄 헤드라인의 원인이 "좁은 컨테이너"임을 지적하고 해법을 준다 ("You MUST use ultra-wide containers for the H1 (`max-w-5xl`, `max-w-6xl`, `w-full`)")
- `grid-flow-dense` 지시: bento 빈칸 문제의 실제 CSS 해법
- 버튼 대비 체크: "Dark background = white text. Light background = dark text. Invisible text is a failure."
**못하는 것**: "Python RNG 시뮬레이션"은 인지적 연극이다. 모델은 진짜 난수를 못 만든다. 프롬프트 문자 수 모듈로는 같은 프롬프트에 항상 같은 결과를 준다. 다만 **"선택했음을 명시적으로 출력하게 만드는" 효과**는 실재한다. GSAP 강제(§5)는 React 외 스택에서 무의미하다.
### imagegen-frontend-web / mobile
**잘하는 것**
- **HARD OUTPUT RULE을 파일 최상단에 배치**하고 그 자체로 별도 섹션을 만들었다. "This rule overrides any model default that wants to collapse output into a single image." 모델 기본 동작과 충돌하는 규칙임을 인지하고 명시적으로 이긴다고 선언한다.
- **조합 변형 엔진(Combinatorial Variation Engine)**: Theme Paradigm / Background Character / Typography Character / Hero Architecture / Section System / Signature Component Set / Motion-Implied Language / Composition Anchor / Background Mode / CTA Variation / Hero Scale / Narrative Spine / Second-Read Moment. **축별로 옵션을 나열하고 "섹션마다 하나씩 고르되 페이지 전체에서 최소 3개 앵커가 등장해야 한다"는 분산 규칙을 준다.**
- **가장 흔한 기본값을 명시적으로 강등**: "The default **left-text / right-image hero is the most overused AI pattern**. It is allowed, but **it should not be your first instinct**." 그리고 대안 10개를 나열한다.
- mobile §25 "NOT ALWAYS SIMPLE RULE": "Simplicity is not the goal by itself. **Cleanliness is the goal.** ... The rule is: not always simple, always clean." 미니멀리즘 과잉 편향을 교정한다.
- mobile §35 QUALITY CHECK 27문항이 자문 형식이다: "**Were too few screens generated out of laziness?**"
**못하는 것**: 987줄 / 1,465줄. 이미지 생성 도구 없는 환경에서는 대부분 무용지물. 규칙 번호가 37개까지 가면서 서로 중복된다.
### image-to-code
**잘하는 것**: "이미지 먼저, 코드는 번역 레이어"라는 강한 워크플로 선언 ("The image is the design source. The code is the translation layer."). §21~§25 추출 규칙(텍스트/타이포/스페이싱/컴포넌트/컬러)이 명확하다. §33 기본 섹션 팩(4/8/12) 제공.
**못하는 것**: 이미지 생성 도구 없으면 전체가 죽는다. 1,228줄. 다이얼 9개는 과하다.
### redesign-existing-projects
**잘하는 것**
- **구조가 다른 스킬과 완전히 다르다.** 미학 선언이 아니라 **"문제 → 고치는 법" 페어 나열**이다:
> - **Buttons not bottom-aligned in card groups.** When cards have different content lengths, CTAs end up at random heights. Pin buttons to the bottom of each card so they form a clean horizontal line regardless of content above.
- **"AI가 빼먹는 것" 섹션**이 독보적이다: 법적 링크, 뒤로가기, 404 페이지, 폼 검증, skip-to-content 링크, 쿠키 동의
- **광학적 정렬** 같은 미묘한 항목이 있다: "Mathematical alignment that looks optically wrong. Centering by the math doesn't always look centered to the eye. Icons next to text, play buttons in circles, or text in buttons often need 1-2px optical adjustments."
- **수정 우선순위**가 위험 대비 효과 순이다: "1. Font swap — biggest instant improvement, lowest risk"
- **스택 불가지론**: "Work with the existing tech stack. Do not migrate frameworks or styling libraries."
**못하는 것**: 감사 항목 100개 이상을 나열만 하고 우선순위 티어가 없다(우선순위는 마지막 7단계뿐). 다이얼이나 브리프 추론이 없다.
### stitch-design-taste
**잘하는 것**: **메타 스킬이다.** 자기가 디자인하지 않고 `DESIGN.md`를 생성해서 다른 도구(Google Stitch)가 읽게 한다. 출력 템플릿을 마크다운 코드블록으로 정확히 제시한다. Best Practices / Tips / Common Pitfalls 3단 구성이 좋다:
> - **Be Descriptive:** "Deep Charcoal Ink (#18181B)" — not just "dark text"
> - **Be Opinionated:** This is not a neutral template — it enforces a specific, premium aesthetic
> - Common Pitfall: "Using technical jargon without translation ("rounded-xl" instead of "generously rounded corners")"
**못하는 것**: Stitch 전용. 하지만 **"휴대용 design.md를 산출한다"는 아이디어 자체는 designpaca가 반드시 훔쳐야 한다.** (Superdesign의 `.superdesign/design-system.md`, Hallmark의 `design.md`도 같은 패턴)
### brandkit
**잘하는 것**: 로고 컨셉 방법론 5종(Monogram+Meaning / Product Action / Metaphor Fusion / Negative Space / Construction Geometry)을 구체적으로 나눈다. 시각 모드 8종에 각각 팔레트·타이포·이미지 방향이 붙는다. 텍스트 절제 규칙이 이미지 생성 맥락에서 정확하다("Text should be large enough and sparse enough to render well"). 태그라인 좋은 예/나쁜 예를 실제 문장으로 준다.
**못하는 것**: 웹 디자인 스킬이 아니다.
### full-output-enforcement
**잘하는 것**: 60줄로 한 가지 문제(잘림)만 판다. **금지 패턴을 문자열 단위로 나열한다**:
> **In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...`
> **In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", ...
그리고 **한계 도달 시의 행동을 정의한다**:
> `[PAUSED — X of Y complete. Send "continue" to resume from: next section name]`
> On "continue", pick up exactly where you stopped. No recap, no repetition.
**"Scope → Build → Cross-check"** 3단계에서 "Count how many distinct deliverables are expected. **Lock that number.**"가 핵심.
**못하는 것**: 디자인 스킬이 아니다. 하지만 designpaca가 여러 섹션을 한 번에 출력해야 할 때 이 기법을 흡수해야 한다.
### graphify
**잘하는 것**: 스킬이 아니라 **CLI 파이프라인 실행 매뉴얼**이다. Usage 블록에 커맨드 20여 개를 나열하고, Step 1~9를 순서대로 실행하게 한다. 각 스텝에 실제 Python/bash 코드가 있다. 그리고:
> ## Honesty Rules
> - Never invent an edge. If unsure, use AMBIGUOUS.
> - Never skip the corpus check warning.
> - Always show token cost in the report.
> - Never hide cohesion scores behind symbols - show the raw number.
> - Never run HTML viz on a graph with more than 5,000 nodes without warning the user.
**"Honesty Rules"라는 별도 섹션**은 좋은 패턴이다. designpaca에도 "이미지가 없으면 없다고 말하라", "가짜 지표를 만들지 말라" 류의 정직성 규칙 섹션이 필요하다.
**못하는 것**: `trigger:` 비표준 필드 사용. 1,242줄.
### frontend-design (Anthropic 공식)
**잘하는 것**
- **약 40줄. 산문. 금지 목록 거의 없음.** 그런데 효과가 있다.
- **역할 부여가 구체적이다**: "Approach this as the design lead at a small studio known for giving every client a visual identity that could not be mistaken for anyone else's. **This client has already rejected proposals that felt templated**, and is paying for a distinctive point of view"
- **주제에 뿌리내리기**: "The subject's own world, its materials, instruments, artifacts, and vernacular, is where distinctive choices come from."
- **2패스 프로세스**: 계획(토큰 시스템 4요소: Color 4-6 hex / Type 2+ roles / Layout ASCII 와이어프레임 / Signature) → **계획을 브리프에 대조 검토** → 코드
- **자기 검증 방법이 영리하다**: "if any part of it reads like the generic default you would produce for any similar page (**work through a similar prompt to see if you arrive somewhere similar**) rather than a choice made for this specific brief — revise that part, say what you changed and why."
- **절제의 원칙**: "**Spend your boldness in one place.** Let the signature element be the one memorable thing, keep everything around it quiet and disciplined... Consider Chanel's advice: before leaving the house, take a look in the mirror and **remove one accessory**."
- **위험 감수도 리스크임을 짚는다**: "Not taking a risk can be a risk itself!"
- **카피 작성 지침을 디자인의 일부로 다룬다**: "Words appear in a design for one reason: to make it easier to understand... They are design material, not decoration." / "A person manages notifications, not webhook config." / "An action keeps the same name through the whole flow, so the button that says 'Publish' produces a toast that says 'Published.'"
- **CSS 실무 함정 하나만 콕 집는다**: "It's easy to generate CSS classes that cancel each other out (especially with a type-based selector like `.section` and a element-based selector like `.cta`)"
**못하는 것**: 구체적 CSS 값, 폰트명 후보, 팔레트가 전혀 없다. 초보 모델이나 저사양 모델에서는 "무엇을 해야 할지" 감이 안 잡힐 수 있다. 검증 가능한 게이트가 없다.
### artifact-design (빌트인, Skill 도구로 확인)
**잘하는 것**
- **"디자인할지 말지"가 아니라 "어떤 트리트먼트인지"를 먼저 정하게 한다**: "Calibrate treatment, not whether to design. A doc deserves the same craft as a landing page — what changes is the treatment that craft is delivered in."
- **유틸리티 트리트먼트를 명시적으로 인정한다**: "Many requests call for a more utilitarian treatment: a plan, a memo, a demo. Make it polished... but avoid over-designing. **Most pages do not need a flashy, gigantic hero.**"
- **판단 기준 한 줄**: "When unsure: a well-composed page is never the wrong answer; an over-designed visual identity sometimes is."
- **우선순위 체인**: "Precedence is always: the user's own words, then the project's existing system, then your choices."
- **기존 시스템 존중을 1번에 놓았다**: "Look for an existing design system first — CLAUDE.md, a tokens or theme file, existing component styles."
- **뉴트럴 선택 원칙**: "A pure mid-grey reads as unconsidered; **a grey with a slight hue bias toward the page's accent reads as chosen.** ... the point is that the neutral was picked, not inherited."
- **다크모드를 3상태로 정확히 다룬다** (`data-theme` 스탬프 있음/없음 + `prefers-color-scheme`), 그리고 실패 모드를 이름 붙인다: "scan the stylesheet for any color declared only inside a media or `[data-theme]` block — **that is the classic unreadable-artifact bug.**"
- **레이아웃 스페이싱 원칙 한 줄**: "Lay out sibling groups with flex or grid and `gap`, not per-element margins that silently collapse or double."
- **"UI일 때는 다르다"를 분리**: "A dashboard or tool is scanned and operated, not read top-to-bottom, so the craft shifts from typography to information design. **Surface the summary before the detail; encode state in form as well as number.**"
**못하는 것**: Artifact 런타임 전용 제약(CSP, 폰트 호스트)이 섞여 있어 그대로 이식 불가.
### dataviz (빌트인)
**잘하는 것**
- **절차를 순서로 못 박고 이유를 준다**: "Color comes LAST. Most bad charts pick colors first."
- **"계산 가능한 것은 계산하라"**: "The single most important habit: **the color part is computable, so compute it.** Never eyeball whether a palette is colorblind-safe — run `scripts/validate_palette.js`."
- **실행 가능한 검증기를 번들한다** (`scripts/validate_palette.js`, `.py`) — 스킬이 취향 판단을 스크립트로 외주 주는 유일한 사례
- **디자인 시스템 불가지론**: "The method is invariant; only these parameters change per system." 그리고 파라미터 표를 준다 (Ramps / Categorical theme / Sequential hue / Diverging pair / Status palette / Texture fill / Surfaces / Filter controls)
- **완전한 progressive disclosure**: SKILL.md ~80줄 + `references/` 7개 + `scripts/` 2개. 본문은 **인덱스 + 절차**만 담고, 각 참조 파일이 무엇에 답하는지 표로 정리한다.
- **anti-patterns.md를 별도 파일로 두고 "모든 차트를 이것과 대조하라"고 지시**한다. 각 항목이 `❌ 무엇 / Why it misleads / ✅ Do instead` 3단이다. **실제 사례까지 적는다**: "Real example: an 'Adoption' chart plotting Users (030k) against Sessions (0800k) — a reviewer flagged it as looking 'hallucinated.'"
- **마지막에 눈으로 확인하라고 한다**: "Render it and look at it. The validator checks color, not layout — open or screenshot the output and eyeball it for label collisions, geometry, and overflow before calling it done."
**못하는 것**: 차트 전용.
### skill-creator (Anthropic 공식)
designpaca 설계에 가장 직접적으로 적용되는 스킬. 핵심 인용:
> - **description**: ... Note: currently Claude has a tendency to "undertrigger" skills -- to not use them when they'd be useful. To combat this, please **make the skill descriptions a little bit "pushy"**.
> - Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next.
> - Prefer using the imperative form in instructions.
> - **Writing Style**: Try to explain to the model why things are important **in lieu of heavy-handed musty MUSTs**. Use theory of mind and try to make the skill general and not super-narrow to specific examples.
> - **Generalize from the feedback.** ... if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working.
> - **Keep the prompt lean.** Remove things that aren't pulling their weight.
> - **Look for repeated work across test cases.** ... that's a strong signal the skill should bundle that script.
> - **How skill triggering works**: Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like "read this PDF" may not trigger a skill even if the description matches perfectly.
description 최적화 평가 쿼리 작성 가이드도 중요하다:
> Bad: `"Format this data"`, `"Extract text from PDF"`, `"Create a chart"`
> Good: `"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage..."`
> The key thing to avoid: **don't make should-not-trigger queries obviously irrelevant.** "Write a fibonacci function" as a negative test for a PDF skill is too easy — it doesn't test anything. **The negative cases should be genuinely tricky.**
---
## 7. 종합 매트릭스
| 기법 | dtf(v2) | dtf-v1 | hevd | min-ui | ibu | gpt-taste | ig-web | i2c | redesign | stitch | frontend-design(공식) | artifact-design | dataviz |
|---|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| 브리프 추론 우선 | O | X | X | X | X | X | 부분 | 부분 | 부분 | O | O | O | O |
| 다이얼 시스템 | O | O | X | X | X | X | O | O | X | O | X | X | X |
| 금지 목록(하드 밴) | O | O | O | O | O | O | O | O | O | O | X | 부분 | 부분 |
| 조건부 오버라이드 | O | X | X | X | 부분 | X | X | X | X | X | O | O | 부분 |
| 기계적 카운트 규칙 | O | X | X | X | X | O | O | X | X | X | X | X | O |
| 출력 전 게이트/체크리스트 | O | O | O | X | X | O | O | O | X | X | O | X | O |
| 랜덤/변형 엔진 | 부분 | X | O | X | X | O | O | O | X | X | X | X | X |
| 코드 스켈레톤 | O | X | X | X | 부분 | 부분 | X | X | X | X | X | X | X |
| references/ 분리 | X | X | X | X | X | X | X | X | X | 부분 | X | X | O |
| 범위 밖 선언 | O | X | X | X | X | X | X | X | X | X | X | 부분 | 부분 |
| 실행 가능 검증기 | X | X | X | X | X | X | X | X | X | X | X | X | O |
| 산출물로 design.md | X | X | X | X | X | X | X | X | X | O | X | X | X |
| 이유(why) 서술 | 부분 | X | 부분 | X | X | O | 부분 | X | O | X | O | O | O |
| 접근성 규칙 | O | X | X | X | X | 부분 | X | X | O | O | 부분 | O | O |
| 카피/문구 규율 | O | X | X | 부분 | X | O | 부분 | O | O | O | O | O | X |
| 500줄 이하 | X | O | O | O | O | O | X | X | O | O | O | O | O |
약어: dtf = design-taste-frontend, hevd = high-end-visual-design, min-ui = minimalist-ui, ibu = industrial-brutalist-ui, ig-web = imagegen-frontend-web, i2c = image-to-code
---
## 8. 로컬 조사에서 나온 핵심 결론 5가지
1. **커뮤니티 디자인 스킬은 전부 단일 파일이고, 이게 최대 약점이다.** 13개 중 references/ 를 쓴 스킬은 0개. 반면 Anthropic 공식 dataviz는 SKILL.md 80줄 + references 7개 + scripts 2개로 같은 밀도의 지식을 1/10 토큰으로 상주시킨다.
2. **"공식 스타일"과 "커뮤니티 스타일"은 정반대 방향이다.** 공식(frontend-design, artifact-design)은 40줄 산문에 이유 중심. 커뮤니티(design-taste-frontend)는 1,206줄에 금지 목록 중심. 둘 다 효과가 있고, 둘 다 결점이 있다. designpaca는 이 두 계보를 계층으로 분리해서 합쳐야 한다(공식 스타일을 SKILL.md 본문에, 커뮤니티 스타일을 references/에).
3. **가장 강력한 발명은 "기계적으로 셀 수 있는 규칙"이다.** eyebrow ≤ ceil(sections/3), zigzag ≤ 2연속, bento 셀 = 콘텐츠 개수, 히어로 헤드라인 ≤ 2줄, 서브텍스트 ≤ 20단어, 마퀴 ≤ 1개. 주관적 취향을 카운트로 번역하면 검증 가능해진다.
4. **세션 간 다양성 규칙은 상태 저장 없이는 실패한다.** design-taste-frontend의 "different serif from your previous project"는 실행 불가능한 지시다. designpaca는 프로젝트 루트에 로그 파일을 쓰는 방식으로 이 문제를 풀어야 한다.
5. **컨텍스트 수명 관리가 설계 제약이다.** 스킬은 발동 후 세션 내내 상주하고, 컴팩션 시 앞 5,000토큰만 재부착된다. 따라서 **가장 중요한 규칙은 파일 앞쪽에 있어야 한다.** design-taste-frontend는 이걸 정반대로 했다(AI Tells가 §9, Pre-Flight가 §14). imagegen-frontend-web이 HARD OUTPUT RULE을 6번째 줄에 놓은 것이 옳다.