designpaca/research/skills/02-prompt-techniques.md

02. 검증된 프롬프트 기법 카탈로그

작성일: 2026-08-20 각 기법은 무엇을 / 왜 효과적인지 / 실제 예문 3요소로 정리한다. 예문은 전부 실제 스킬·시스템 프롬프트에서 가져온 원문이며 출처를 병기한다.

---

A. 발동과 컨텍스트 관리

기법 1. Description = 용도 + 트리거 + 배제조건 (3-part description)

무엇을 description 필드를 세 부분으로 구성한다. (1) 무엇을 하는가, (2) 어떤 요청에서 발동하는가(사용자가 실제 칠 법한 문구 포함), (3) 어떤 요청에서는 발동하지 않는가.

왜 효과적인지 description은 스킬 선택의 유일한 근거다. Anthropic 공식 문서:

"The description is critical for skill selection: Claude uses it to choose the right Skill from potentially 100+ available Skills." — Skill authoring best practices

그리고 실패 모드가 두 방향이다. skill-creator는 과소 발동을 지적한다:

"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'."

Claude Code 문서는 과잉 발동 대책을 별도로 제시한다:

"Skill triggers too often — If Claude uses your skill when you don't want it: 1. Make the description more specific"

배제조건을 description에 넣으면 두 방향을 동시에 잡는다. 로컬 스킬 중 이 기법을 쓰는 것은 codex-image와 refactor-governance 둘뿐인데, 둘 다 오탐이 잦은 도메인이라는 공통점이 있다.

실제 예문

description: AI 비트맵 이미지(일러스트·컨셉아트·텍스처·스프라이트·목업·컷아웃) 생성·편집이
  필요할 때 사용. "이미지 생성해", "이미지 만들어", "일러스트 만들어", "그림 그려줘",
  "generate an image", "create an illustration" 같은 요청에 자동으로 트리거.
  벡터/SVG/코드 네이티브 아이콘이나 로고 시스템 확장에는 쓰지 않는다.

출처: C:\Users\encep\.claude\skills\codex-image\SKILL.md

description: Evidence-gated refactoring and design-debt governance for coding agents.
  Use when planning or executing refactors involving dead code, ... or any change that
  must preserve behavior while improving structure.
  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.

출처: C:\Users\encep\.codex-litellm\skills\refactor-governance\SKILL.md

---

기법 2. 3인칭 서술 + "Use when" 시작

무엇을 description을 1인칭("I can help you...")이나 2인칭("You can use this to...")이 아닌 3인칭 동사로 시작한다. obra/superpowers는 한발 더 나가 "Use when"으로 시작하라고 규정한다.

왜 효과적인지 description은 시스템 프롬프트에 그대로 주입된다. 시점이 뒤섞이면 모델이 그것을 "지시"가 아니라 "인용"으로 읽는다. Anthropic이 경고 박스로 강조한 몇 안 되는 항목 중 하나다.

Always write in third person. The description is injected into the system prompt, and inconsistent point-of-view can cause discovery problems.

• Good: "Processes Excel files and generates reports"
• Avoid: "I can help you process Excel files"
• Avoid: "You can use this to process Excel files" — Skill authoring best practices

obra/superpowers의 규칙은 더 강하다:

description: max 1024 chars total, third-person, starts with "Use when..." Description must state triggering conditions only—never summarize workflow "Use when..." format prevents agents from taking workflow shortcuts

마지막 문장이 미묘하지만 중요하다. description에 워크플로 요약을 넣으면 모델이 본문을 읽지 않고 description만 보고 대충 처리하려 든다.

실제 예문

# 나쁨 (워크플로 요약이 들어감)
description: This skill reads the brief, picks a palette, generates a design plan,
  then writes the HTML.

# 좋음 (트리거 조건만)
description: Use when building or reshaping web UI - landing pages, portfolios,
  marketing sites, product pages, or redesigns - and the visual result matters.

---

기법 3. Progressive Disclosure 3계층 (인덱스 + 참조 파일)

무엇을 SKILL.md 본문은 절차와 인덱스만 담고, 지식 본체는 references/*.md로 분리한다. 본문에서 "이 파일은 무엇에 답하는지"를 표로 명시한다.

왜 효과적인지 스킬은 발동되면 세션 내내 컨텍스트에 상주한다.

"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 skills docs

그리고 컴팩션 시 잘린다.

"When the conversation is summarized to free context, Claude Code re-attaches the most recent invocation of each skill after the summary, keeping the first 5,000 tokens of each. Re-attached skills share a combined budget of 25,000 tokens." — Claude Code skills docs

반면 참조 파일은 읽기 전까지 0토큰이다.

"No context penalty for large files: Reference files, data, or documentation don't consume context tokens until actually read" — Skill authoring best practices

핵심 수치: 본문 500줄 이하, 참조 깊이 1단계, 참조 파일 100줄 초과 시 목차 포함.

"Keep references one level deep from SKILL.md. All reference files should link directly from SKILL.md to ensure Claude reads complete files when needed." "Claude may partially read files when they're referenced from other referenced files. When encountering nested references, Claude might use commands like head -100 to preview content rather than reading entire files, resulting in incomplete information."

실제 예문 — dataviz의 인덱스 표 (빌트인 스킬, Skill 도구로 확인)

## Reference files

| File | What it answers |
|------|-----------------|
| `references/choosing-a-form.md` | Which chart type / is it even a chart? |
| `references/color-formula.md` | The four jobs, the six checks, snap-to-passing |
| `references/marks-and-anatomy.md` | Mark specs, spacers, labels, figures, hero number |
| `references/interaction.md` | Tooltips & hover, filters & time ranges |
| `references/components.md` | The pieces a chart is made of |
| `references/anti-patterns.md` | **What goes wrong — check every chart against this** |
| `references/palette.md` | **The reference palette instance** |
| `scripts/validate_palette.js` | Runnable six-checks validator (run it; don't eyeball) |

---

기법 4. 인덱스-후-선택 (Index-then-pick), 절대 사전 로드 금지

무엇을 카탈로그형 지식(테마 20개, 레이아웃 21개, 컴포넌트 아키타입 22개)은 인덱스 파일 하나 + 항목별 개별 파일로 쪼갠다. 인덱스만 읽고 하나를 고른 다음, 선택한 파일만 로드한다.

왜 효과적인지 카탈로그를 통째로 로드하면 진짜 정보(고른 것)가 노이즈(고르지 않은 20개)에 묻힌다. 그리고 토큰이 20배 든다. Hallmark가 이 패턴을 가장 엄격하게 구현했다.

실제 예문

Step 2: Macrostructure First

Before theme, pick one of 21 named macrostructures from references/macrostructures.md index. Load ONLY that one per-macro file (e.g., 05-workbench.md). Never load the whole catalogue.

Step 3: Load Visual Rulesets

Always-load (eager): Genre file from Step 1 (1–2 files) Index-then-pick (never pre-load): macrostructures.md → load only the picked per-macro file; component-cookbook.md → load only the picked archetype files (5–7 typical) Load conditionally (be honest—do not pre-load "for safety"):

• microinteractions.md — if page has any interactive element
• responsive.md — if mobile is in scope
• hero-enrichment.md — only after image-need check At Step 7 only: slop-test.md — post-emit check (not pre-emit reference) — Nutlope/hallmark skills/hallmark/SKILL.md

"be honest—do not pre-load 'for safety'" 이 한 마디가 실제로 필요하다. 모델은 안전빵으로 전부 읽으려는 경향이 있다.

---

기법 5. 가장 중요한 규칙을 파일 최상단에 (HARD RULE 선두 배치)

무엇을 모델의 기본 동작과 정면으로 충돌하는 규칙 하나를, 제목·개요·역할 부여보다 먼저 배치하고 별도 섹션으로 만든다.

왜 효과적인지 두 가지 이유. (1) 컴팩션 시 앞 5,000토큰만 살아남으므로 물리적으로 앞에 있어야 생존한다. (2) 긴 문서에서 후반부 지시는 초반 지시보다 준수율이 낮다 (lost-in-the-middle).

design-taste-frontend는 이걸 반대로 했다. AI Tells가 §9(약 600줄 지점), Pre-Flight가 §14(약 910줄 지점)에 있다. 컴팩션 한 번이면 둘 다 사라진다.

실제 예문

---
name: imagegen-frontend-web
description: ...
---

# HARD OUTPUT RULE — READ FIRST

**Generate one separate horizontal image PER section. Always. No exceptions.**

- 1 section requested -> 1 image
- 8 sections requested -> 8 images
- "landing page" with no count -> default to 6 sections -> 6 images

Each image is one section, generated as its own image call. Never combine multiple
sections into one frame. Never return a single tall image that contains the whole page.

**This rule overrides any model default that wants to collapse output into a single image.**

---

# HERO COMPOSITION BIAS — READ FIRST
...

출처: C:\Users\encep\.agents\skills\imagegen-frontend-web\SKILL.md (1~24번째 줄)

마지막 문장 "This rule overrides any model default"가 핵심이다. 규칙이 모델 기본값과 싸운다는 사실을 명시하면 준수율이 올라간다.

---

B. 브리프 해석과 방향 결정

기법 6. Design Read — 코드 전에 한 줄 선언

무엇을 코드를 쓰기 전에 "이 브리프를 무엇으로 읽었는지"를 정해진 문장 틀로 한 줄 출력하게 한다.

왜 효과적인지 LLM이 나쁜 디자인을 내는 첫 번째 원인은 미학이 아니라 브리프를 안 읽는 것이다. 한 줄 선언은 (1) 모델이 스스로 방향을 확정하게 하고, (2) 사용자가 즉시 교정할 수 있는 지점을 만들며, (3) 이후 모든 규칙이 참조할 앵커가 된다.

실제 예문

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>."

Example reads:

• "Reading this as: B2B SaaS landing for technical buyers, with a Linear-style minimalist language, leaning toward Tailwind utilities + Geist + restrained motion."
• "Reading this as: solo designer portfolio for hiring managers, with an editorial / kinetic-type language, leaning toward native CSS + scroll-driven animation + custom typography."
• "Reading this as: redesign of a public-sector service site, with a trust-first language, leaning toward GOV.UK Frontend or USWDS." — design-taste-frontend §0.B

틀 + 예시 3개의 조합이 중요하다. 틀만 주면 모델이 빈칸을 애매하게 채운다.

---

기법 7. 질문은 정확히 하나만

무엇을 브리프가 모호할 때 질문을 여러 개 묶어 던지지 못하게 하고, 정확히 하나만, 그것도 답이 실제로 결과를 바꿀 때만 하게 한다.

왜 효과적인지 질문 폭탄은 사용자 이탈을 부른다. 반대로 질문 없이 추측하면 잘못된 방향으로 전체를 만든다. "하나만" 제약이 이 둘 사이의 실용적 균형점이다.

실제 예문

0.C If the brief is ambiguous, ask one question, do not guess

Ask exactly one clarifying question - never a multi-question dump - and only when the design read genuinely diverges. Example: "Should this feel closer to Linear-clean or Awwwards-experimental?"

If you can confidently infer from context, do not ask. Just declare the design read and proceed. — design-taste-frontend §0.C

Hallmark는 반대 접근인데 이유가 있다. 3개 필드를 항상 묻되, 답이 없으면 추론하고 공개한다:

Step 1: Design-Context Gate

Always ask three fields (even on short briefs):

• Audience: Who uses this? What do they care about?
• Use case: What's the single action the page should drive?
• Tone: Pick an extreme—editorial, brutalist, soft, utilitarian, luxury, playful, technical, austere. (Not "clean and modern.")

Wait for one answer. If the user says "go ahead" or doesn't engage, infer and disclose—one sentence stating what you picked, so the user can redirect. — Hallmark SKILL.md

"Pick an extreme ... (Not 'clean and modern.')" — 사용자가 무의미한 답을 하는 것까지 막는다.

---

기법 8. 다이얼 시스템 (수치화된 미학 축)

무엇을 미학을 2~3개의 1-10 정수 축으로 환원하고, (a) 브리프 키워드 → 다이얼 값 매핑 표, (b) 축 값별 구체적 CSS 정의, (c) 다이얼로 게이팅되는 조건부 규칙을 함께 제공한다.

왜 효과적인지 "세련되게"는 검증 불가능하지만 "VARIANCE 8"은 검증 가능하다. 그리고 다이얼이 있으면 규칙에 조건을 걸 수 있다. if VARIANCE > 4 then no centered hero처럼. 이는 200개의 무조건 규칙보다 훨씬 적은 토큰으로 더 많은 상황을 커버한다.

실제 예문 (3요소 전부)

축 정의:

* **`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

브리프 → 다이얼 매핑:

Signal	VARIANCE	MOTION	DENSITY
"minimalist / clean / calm / editorial / Linear-style"	5-6	3-4	2-3
"premium consumer / Apple-y / luxury / brand"	7-8	5-7	3-4
"playful / wild / Dribbble / Awwwards / experimental"	9-10	8-10	3-4
"trust-first / public-sector / regulated / accessibility-critical"	3-4	2-3	4-5

축 값의 구체적 정의:

DESIGN_VARIANCE (Level 1-10)

• 1-3 (Predictable): Symmetrical CSS Grid (12-col, equal fr-units), equal paddings, centered alignment.
• 4-7 (Offset): margin-top: -2rem overlaps, varied image aspect ratios (4:3 next to 16:9), left-aligned headers over center-aligned data.
• 8-10 (Asymmetric): Masonry layouts, CSS Grid with fractional units (grid-template-columns: 2fr 1fr 1fr), massive empty zones (padding-left: 20vw).

게이팅:

ANTI-CENTER BIAS: Centered Hero / H1 sections are avoided when DESIGN_VARIANCE > 4. Perpetual Micro-Interactions: Use when MOTION_INTENSITY > 5 AND the section actively benefits from motion. For VISUAL_DENSITY > 7: generic card containers are banned.

자기 일관성:

"Motion claimed, motion shown." If MOTION_INTENSITY > 4, the page must actually move: entry transitions on hero, scroll-reveal on key sections, hover physics on CTAs, at minimum. 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.

출처: design-taste-frontend §1, §4.3, §5, §7

주의: image-to-code는 다이얼을 9개로 늘렸다. 인지 부하 대비 효과가 떨어진다. 3개가 적정선이다.

---

기법 9. 브리프 → 실제 디자인 시스템 매핑

무엇을 "이 브리프는 CSS를 발명할 게 아니라 공식 디자인 시스템 패키지를 써야 한다"를 판단하는 표를 준다. 그리고 실제 설치 명령어와 공식 문서 URL을 부록에 담는다.

왜 효과적인지 모델의 가장 큰 낭비는 이미 존재하는 것을 즉흥 재발명하는 것이다. 엔터프라이즈 대시보드에 커스텀 CSS를 짜는 것보다 Carbon을 설치하는 게 낫다. 그리고 모델은 패키지명·설치 명령·API를 환각한다. 실제 명령어를 스킬에 박아두면 그게 사라진다.

실제 예문

2.A When to reach for a real design system (use official packages)

Brief reads as…	Reach for	Why
Microsoft / enterprise SaaS / dashboards	@fluentui/react-components	Official Fluent UI, Microsoft tokens, accessibility done
Google-ish UI, Material-flavored product	@material/web + Material 3 tokens	Official, theme-able via Material Theming
IBM-style B2B / enterprise analytics	@carbon/react + @carbon/styles	Official Carbon, mature data-density patterns
Shopify app surfaces	polaris.js web components	Required for Shopify admin UI
Atlassian / Jira-style product	@atlaskit/* + @atlaskit/tokens	Official Atlassian DS

Do not invent CSS for things that have an official package. Do not pretend an aesthetic trend is an official system. — design-taste-frontend §2.A

그리고 부록 서문:

The sections below are vendored reference content. They give the agent real install commands, real canonical doc links, and real working starter snippets for each design system named in Section 2. Use them to ground decisions in production reality, not training-data fiction. — design-taste-frontend, Appendices 서문

부록 C는 특히 정직하다. "Apple Liquid Glass"에 대해 무엇이 공식이고 무엇이 아닌지를 나눠 적는다(### What is official / ### What is NOT official / ### Safer web approximation skeleton). 트렌드 용어를 스펙인 것처럼 다루지 않는 규율이다.

---

C. 반복·기본값 회피

기법 10. 기본값을 이름 붙여 지목하기 (Named default attractors)

무엇을 금지 목록을 나열하는 대신, 현재 AI가 수렴하는 구체적 룩을 이름과 hex로 지목하고, "이건 선택이 아니라 기본값이니 자유가 주어진 축에 이걸 쓰지 마라"고 말한다.

왜 효과적인지 "generic하게 만들지 마라"는 실행 불가능한 지시다. "#F4F1EA 크림 배경 + 고대비 세리프 + 테라코타 액센트 조합은 기본값이다"는 실행 가능한 지시다. 그리고 목록 100개보다 명명된 3개가 기억에 남는다.

실제 예문 (Anthropic 공식, 가장 밀도 높은 버전)

For calibration: 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. — anthropic-agent-skills frontend-design/SKILL.md

artifact-design(빌트인)의 확장판:

warm cream (#F4F1EA) with a serif display and terracotta accent; near-black with a lone acid-green or vermilion pop; broadsheet hairline rules with dense columns; 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.

hex 단위 명명의 극단적 버전 (design-taste-frontend §4.2):

Backgrounds: #f5f1ea, #f7f5f1, #fbf8f1, #efeae0, #ece6db, #faf7f1, #e8dfcb Accents: #b08947, #b6553a, #9a2436, #9c6e2a, #bc7c3a, #7d5621 Text: #1a1714, #1a1814, #1b1814

Every premium-consumer site you have ever shipped uses this exact palette. The brand becomes invisible.

마지막 문장이 이유(why)다. "촌스럽다"가 아니라 **"브랜드가 안 보이게 된다"**는 것이 진짜 손해다.

---

기법 11. 조합 변형 엔진 (Combinatorial Variation Engine)

무엇을 디자인을 독립적인 축 N개로 분해하고, 각 축마다 옵션 목록을 준다. 매 실행마다 축별로 하나씩 고르게 하고, **"페이지 전체에서 최소 X개의 서로 다른 앵커가 나타나야 한다"**는 분산 제약을 건다.

왜 효과적인지 모델은 옵션 목록의 첫 항목을 고르는 편향이 있다. 하지만 축을 여러 개로 쪼개면 조합 수가 곱셈으로 늘어나서, 각 축에서 편향이 있어도 최종 조합은 달라진다. 그리고 "축 안에서 하나"보다 "축들의 조합"이 사고 단위로 더 자연스럽다.

실제 예문

축과 옵션 (imagegen-frontend-web §2):

### Composition Anchor (per-section)
Each section picks 1 anchor; **across the site at least 3 different anchors must appear**;
vary the hero so the page does not open on the AI default.
- Centered statement
- Top-left lead, support bottom-right
- Bottom-left text over background image
- Bottom-right CTA cluster
- Left-third caption + right-two-thirds visual (classic — use sparingly, never twice in a row)
- Right-third caption + left-two-thirds visual (inverted classic)
- Centered low (text in lower 40% over hero image)
- Off-grid editorial offset
- Stacked center
- Image-as-canvas with text overlaid in a clean safe area

### Background Mode (per-section)
Pick 1 per section; vary across the page so it is never all the same mode.
**Be confident with backgrounds — they are a primary tool, not a risk.**
- Solid surface with inline asset
- Full-bleed image background with tonal overlay
- Duotone treated image (two-color photo treatment, palette-locked)
- Micro-noise gradient over solid
- Color-blocked diptych (two flat fields meeting, modernist)
- ...

### Hero Scale (per-page)
Pick 1 — must match brand mood:
- Giant Statement Hero
- Mid Editorial Hero
- Mini Minimalist Hero (tiny logo + short statement + thin CTA, almost no image)
**Mini does not mean weak — it means confident restraint.**

주목할 두 축은 아예 서사 층위다:

### Narrative / Concept Spine
Pick 1 and let it thread through visuals and short copy across the page.
- Artifact / collectible — proof, specimen, treasured object framing
- Journey / pilgrimage — directional flow, waypoint sections, roadmap feeling
- Tool / precision instrument — machined detail, calibrated UI, tactile controls
- Living system / garden — organic growth metaphor, branching layout
- Stage / spotlight — theatrical contrast, performer + audience framing
- Archive / dossier — indexed rows, captions, understated authority

### Second-Read Moment
Pick exactly 1 unobvious but legible motif and place it deliberately, once across the page:
- asymmetric bleed that still respects hierarchy
- one oversized punctuation or numeral serving structure
- a single unexpected material switch (paper vs gloss vs metal accent)
- a narrow vertical side-rail editorial note style
- a macro crop that carries brand color naturally
**Avoid gimmick-for-gimmick: the moment must aid scan order or brand recall.**

출처: imagegen-frontend-web/SKILL.md §2

"Second-Read Moment: pick exactly 1" — Anthropic 공식의 "Spend your boldness in one place"와 같은 원칙을 구현 가능한 형태로 만든 것.

---

기법 12. 프로젝트 로그 파일로 세션 간 다양성 강제

무엇을 디자인 선택(매크로구조, 테마, 액센트 색상 대역)을 프로젝트 루트의 JSON 로그에 기록하고, 다음 실행 때 그 로그를 읽어 최근 3~5개와 다른 것을 고르게 한다. 그리고 산출물 CSS 첫 줄에 선택을 스탬프로 남긴다.

왜 효과적인지 "이전 프로젝트와 다르게 하라"는 상태 없이는 실행 불가능한 지시다. design-taste-frontend가 이 지시를 세 군데(세리프 회전, 팔레트 회전, Pre-Flight 체크)에 넣었지만 전부 작동하지 않는다. 모델은 이전 세션을 기억 못 한다.

Hallmark가 이 문제를 파일시스템으로 푼다. 이것은 "AI 슬롭"의 정의를 개별 페이지 품질이 아니라 "출력들 사이의 구조적 지문 반복"으로 재정의한 결과다.

실제 예문

로그 쓰기:

Project memory (required): Update (or create) .hallmark/log.json at project root. Append new entry at the front:

{ "date": "YYYY-MM-DD", "macrostructure": "<name>", "theme": "<name>",
  "enrichment": "<E# or 'none'>", "brief": "<one-line summary>" }

Custom entries add "theme": "custom" and "theme_axes": "<paper-band> / <display-style> / <accent-hue>". Trim to last 20 entries.

로그 읽기:

Step 2.5: Check Project Memory

If .hallmark/log.json exists, read the last 3–5 entries. Use the log to inform diversification: your picks must not match recent macrostructures or themes. State the rotation in plain text: "Last 5 builds: [list]. Bento Grid used 2 of 5—picking from [exclusion set]. I'll go with [pick]."

CSS 스탬프:

Stamping (required): First non-empty CSS line MUST be:

/* Hallmark · macrostructure: <name> · tone: <tone> · anchor hue: <hue> */

다양성 축 정의:

Theme diversification (mandatory): Two consecutive themes must differ on at least one axis:

• Paper band — dark (L < 30%) / mid (30–85%) / light (> 85%)
• Display style — high-contrast-serif, roman-serif, classical-serif, geometric-sans, grotesk-sans, rounded-sans, mono, display-condensed, display-heavy, risograph-bold
• Accent hue — warm (10–60°) / cool (200–300°) / neutral / chromatic-other

State your pick in plain text before writing code: "Macrostructure: . Theme: . Differs on: ."

출처: Nutlope/hallmark skills/hallmark/SKILL.md

그리고 실패를 이름 붙여 anti-pattern으로 등록했다:

Default-attractor sameness

Two consecutive Hallmark outputs in the same project use the same macrostructure. ... The page looks redesigned only because copy changed. Why it fails. Hallmark's whole point is that two pages for two briefs feel like different sites, not colour-swaps of one template. Repeating a macrostructure across outputs is the structural fingerprint of templating, which is the AI tell Hallmark exists to defeat. — Hallmark references/anti-patterns.md

자기 스킬의 최빈 실패까지 anti-pattern으로 등록한 사례:

Specimen fall-through

... This is the single most-repeated Hallmark output, and it's the reason the skill felt like it had one shape. Fix. The Specimen macrostructure is one of twenty-one in macrostructures.md, not a default. If the brief is vague, pick from the first ten in that file. Reach for Specimen only when the brief explicitly says "editorial", "specimen sheet", "type foundry".

---

기법 13. 명시적 선택 출력 강제 (Declare-your-pick)

무엇을 모델이 무언가를 골랐으면 코드를 쓰기 전에 평문으로 그 선택을 선언하게 한다.

왜 효과적인지 선택을 말로 뱉으면 (a) 실제로 선택 행위가 일어나고, (b) 이후 출력이 그 선언과 일관되게 나오며, (c) 사용자가 코드가 나오기 전에 교정할 수 있다. gpt-taste의 "가짜 Python RNG"도 결국 이 효과를 노린 것이다 (난수는 가짜지만 선언은 진짜다).

실제 예문 3종

Hallmark (평문 선언):

State your pick in plain text before writing code: "Macrostructure: . Theme: . Differs on: ." ... Load ONLY the picked archetype files. State both picks: "Nav: N5 Floating pill. Footer: Ft5 Statement."

Hallmark (프리뷰 블록):

**Hallmark · v1.1.0**

- **Macrostructure** · <name>
- **Theme** · <name> (or custom: <vibe> · OKLCH values · fonts)
- **Enrichment** · <E# + tier, or "none">
- **Sections** · <section names separated by ·>
- **Motion** · <primitives separated by ·, or "none">
- **Slop test** · <N / 58 pass/fail>
- **Diversification** · <axes that differ from prior run>

gpt-taste (구조화된 사전 계획 블록):

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: Confirm the page contains Navigation, Attention (Hero), Interest (Bento), Desire (GSAP), Action (Footer).
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 and grid-flow-dense is applied.
5. Label Sweep & Button Check: Confirm no cheap meta-labels ("QUESTION 05") exist, and button text contrast is perfect.

Anthropic 공식 (토큰 시스템 4요소):

First, brainstorm a short design plan based on the human's design brief: create a compact token system with color, type, layout, and signature. Color: describe the palette as 4–6 named hex values. Type: the typefaces for 2+ roles (a characterful display face that's used with restraint, a complementary body face, and a utility face for captions or data if needed). Layout: a layout concept, using one-sentence prose descriptions and ASCII wireframes to ideate and compare. Signature: the single unique element this page will be remembered by.

주의점: Anthropic 공식은 이걸 사용자에게 다 보여주지 말라고 한다.

"Try to do a lot of this planning and iteration in your thinking, and only show ideas to the user when you have higher confidence it'll delight them."

---

D. 검증과 게이트

기법 14. 기계적으로 셀 수 있는 규칙 (Countable rules)

무엇을 주관적 품질 판단을 정수 카운트 비교로 번역한다. 그리고 세는 방법까지 명시한다.

왜 효과적인지 "eyebrow를 남용하지 마라"는 준수 여부를 확인할 수 없다. "uppercase tracking 인스턴스 수 ≤ ceil(섹션수/3)"은 확인할 수 있다. 그리고 확인할 수 있는 규칙만이 실제로 지켜진다.

실제 예문 (원문 그대로)

• EYEBROW RESTRAINT (mandatory, the #1 violated rule in production tests). An "eyebrow" is the small uppercase wide-tracking label sitting above a section headline (e.g. FOUR COLORWAYS, SELECTED WORK, THE HARDWARE). Typical CSS signature: text-[11px] uppercase tracking-[0.18em], font-mono text-[10.5px] uppercase tracking-[0.22em]. Every AI-built site puts an eyebrow above EVERY section header, producing the same templated rhythm. 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.
  • What to do instead of an eyebrow: drop it entirely. The headline alone is enough. If you need to categorize a section, the section's location on the page already categorizes it; no label needed. — design-taste-frontend §4.7

이 규칙이 4요소를 모두 갖췄다: (1) 대상을 정의(무엇이 eyebrow인지), (2) CSS 시그니처로 식별 방법 제공, (3) 정수 비교 공식, (4) 대안 제시.

다른 카운트 규칙들:

• ZIGZAG ALTERNATION CAP (mandatory). ... 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 (mandatory). ... Two or more marquees on the same page reads as lazy filler.
• BENTO CELL COUNT RULE (mandatory): A bento grid has EXACTLY as many cells as you have content for. 3 items → 3 cells. 5 items → 5 cells. If your grid has an empty cell in the middle or at the end, you planned wrong.
• Section-Layout-Repetition Ban. Once you use a layout family for a section, that family can appear at most ONCE on the page. 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. If you cannot describe the value-prop in 20 words of subtext, the value-prop is unclear, not the rule too tight.
• HERO STACK DISCIPLINE (max 4 text elements).
• Navigation height cap: 80px max desktop, default 64-72px.
• Max 3 lines of quote body. Never 6. — design-taste-frontend §4.7, §4.10

Hallmark의 카운트 게이트:

23. Does the accent colour cover more than ~5 % of any single viewport?
24. Is any prose container's max-width outside the 45–75 ch range?
25. Does the page use more than three distinct font-family families?
26. Is the outlier face used in more than two slots on the page?
27. Hero fit. (a) Is padding-block-end ≥ 1.3× padding-block-start? (b) On 1280×800, can essential content be seen without scrolling?

v0(Vercel)의 카운트 규칙:

"ALWAYS use exactly 3-5 colors total." / "NEVER exceed 5 total colors without explicit user permission." "ALWAYS limit to maximum 2 font families total." "Use line-height between 1.4-1.6 for body text" — v0 Prompts and Tools/Prompt.txt

---

기법 15. 예/아니오 게이트 목록 (Slop test)

무엇을 출력 후 실행하는 질문형 검사 목록을 만든다. 모든 질문의 정답이 "아니오"가 되도록 설계하고, 하나라도 "예"면 수정하게 한다. 특히 심각한 항목에는 Auto-fail 표시를 붙인다.

왜 효과적인지 체크박스 목록("- [ ] X를 했는가")은 모델이 무비판적으로 전부 체크하는 경향이 있다. 질문형("X가 있는가?")은 실제 검사 행위를 요구한다. 그리고 "모든 답이 아니오여야 한다"는 균일한 방향성이 검사를 빠르고 오류 없게 만든다.

실제 예문 (Hallmark 58 게이트 중 일부, 원문)

Visual

1. Is the display font Inter, Roboto, Open Sans, Poppins, Lato, or a system default?
2. Is there a purple-to-blue gradient anywhere — including background-clip: text gradient headline?
3. Is there a 3-equal-column card grid with icon-above-heading tiles?
4. Is any card nested inside another card?
5. Is any card using a thick coloured left/right side-stripe border?
6. Hero shape — centred-everything. Is the hero min-height: 100vh with everything centred, OR are all elements stacked on the same centred axis? Auto-fail.
7. Is pure #000 or pure #fff used as a base colour anywhere?

Microinteractions

10. Is transition-all (or transition: all) used anywhere?
11. Is hover:scale-105 (or any uniform hover-scale) applied across multiple unrelated elements?
12. Are bouncy / overshoot easings used on UI state changes — buttons, modals, tooltips?
13. Does any element have more than one hover effect at the same time?
14. Are you animating width, height, top, left, margin, or padding anywhere?
15. Does the focus ring transition into existence (fade in)?
16. Is there a celebratory success toast for an action whose effect the user can already see?
17. Are tooltip hover-delay and focus-delay equal?
18. Is auto-rotating content lacking pause-on-hover-and-focus?

Layout-Safety Gates

34. Does the page horizontally scroll on any viewport between 320 px and 1920 px?
35. Are interactive bars explicitly vertically centered via align-items: center?

Contrast & Readability

41. The contrast failures that ship most often. Fail on button text ≈ button fill / --color-accent-ink missing or unused / dark-section ink-on-ink.

Mobile-Responsiveness — The Non-Negotiables

50. Image-bearing grid track without minmax(0, 1fr). Does any grid-template-columns render an <img> inside a plain 1fr track?
51. Display headers without long-word wrap. Does any display-size text lack overflow-wrap: anywhere; min-width: 0?
52. Section eyebrow / tag beside the heading. Does any section render an eyebrow on the same horizontal row as the heading? Auto-fail.
53. All-caps display heads with line-height < 1.0.
54. Sticky element at top: 0 below a sticky page-level nav. Are there two sticky-at-top-0 elements on the page? Auto-fail.

---

If any answer is yes, fix it. Do not ship slop. — Nutlope/hallmark references/slop-test.md

게이트 50, 51, 56은 특히 주목할 만하다. 이건 미학 규칙이 아니라 실제 렌더링 버그의 원인이 되는 CSS 패턴이다. 1fr 트랙 안의 <img>가 트랙을 넘치게 만드는 문제, 긴 단어가 있는 display 텍스트가 오버플로하는 문제, sticky 두 개가 겹치는 문제 — 전부 모델이 반복적으로 만드는 실제 버그다.

---

기법 16. 6축 자기 채점 (Pre-emit self-critique)

무엇을 이진 게이트와 별도로, 정성적 6축에 각각 1-5점을 매기고 전 축이 3점 이상이어야 출력하게 한다. 그리고 점수를 산출물에 스탬프로 남긴다.

왜 효과적인지 이진 게이트는 "특정 실수를 안 했는가"만 잡는다. "전체가 좋은가"는 못 잡는다. 축을 이름 붙여 나누면 모델이 각 축에 대해 별도로 생각한다.

실제 예문 (원문)

Pre-Emit Self-Critique (Six Axes)

#	Axis	What You're Scoring
A	Philosophy	Is there a clear why — a position the page is taking? Or is it just a layout?
B	Hierarchy	Can a reader tell, in 2 seconds, what's primary, secondary, tertiary? Or is everything the same weight?
C	Execution	Are the details (rule weight, accent footprint, text-wrap, focus rings, contrast) all in spec, or is there sloppiness?
D	Specificity	Does this look like this brief — or does it look like a generic "page that could be anyone"?
E	Restraint	Have you removed everything that isn't earning its place? Decoration, redundancy, padding-for-padding's-sake?
F	Variety	Does this output share a structural fingerprint with a previous Hallmark output in the project?

Score output on Philosophy, Hierarchy, Execution, Specificity, Restraint, Variety (all ≥3). Stamp scores in artifact. — Nutlope/hallmark

축 D("Does this look like this brief")가 Anthropic 공식의 자기 검증과 같은 것을 묻는다:

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 — frontend-design/SKILL.md

"비슷한 프롬프트를 머릿속으로 돌려보고 같은 곳에 도착하는지 확인하라" — 일반성 테스트의 가장 간명한 표현이다.

---

기법 17. 실행 가능한 검증 스크립트 번들

무엇을 계산으로 검증 가능한 항목은 모델 판단에 맡기지 않고 스크립트로 검사한다. 스킬에 스크립트를 번들하고, "눈으로 보지 말고 돌려라"라고 명시한다.

왜 효과적인지 색맹 안전성(ΔE), 대비비(WCAG), 명도 대역 같은 것은 계산 문제지 취향 문제가 아니다. 모델이 계산하면 틀린다. 스크립트가 계산하면 안 틀린다. 그리고 스크립트 실행은 토큰을 거의 안 쓴다(출력만 소비).

"Scripts executed efficiently: Utility scripts can be executed through bash without loading their full contents into context. Only the script's output consumes tokens" — Skill authoring best practices

실제 예문 (dataviz, 빌트인)

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.

3. VALIDATE the palette — run the script, don't reason about ΔE. node scripts/validate_palette.js "<hex,hex,…>" --mode light ... It returns pass/fail on the lightness band, chroma floor, adjacent-pair CVD separation, the normal-vision floor, and contrast. Fix anything that FAILs before continuing. Re-run for --mode dark with that mode's surface.

• Run the validator before shipping any categorical palette. CVD ΔE ≥ 8 is the target (OKLab ×100); 6–8 is a floor that is legal ONLY with secondary encoding. A normal-vision floor below 15 is a hard FAIL.

그리고 스크립트가 못 잡는 것을 정직하게 명시한다:

7. 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.

Anthropic 공식이 스크립트 번들을 권하는 이유:

Benefits of utility scripts: More reliable than generated code / Save tokens / Save time / Ensure consistency across uses

그리고 언제 스크립트를 만들어야 하는지 신호까지 준다:

Look for repeated work across test cases. Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts. If all 3 test cases resulted in the subagent writing a create_docx.py or a build_chart.py, that's a strong signal the skill should bundle that script. — skill-creator

---

기법 18. 절차 순서를 이유와 함께 못 박기

무엇을 단계 순서를 정하고, 왜 그 순서인지 한 문장으로 설명한다.

왜 효과적인지 "1,2,3 순서로 하라"는 지켜지지 않는다. "3번을 먼저 하면 X가 망가진다"는 지켜진다. 이유가 있는 순서는 모델이 스스로 재구성할 수 있다.

실제 예문

The procedure — do these in order

Color comes LAST. Most bad charts pick colors first.

1. Pick the form. What is the data's job — magnitude, identity, polarity, a single headline, change-over-time? The job picks the chart type, and sometimes the answer is not a chart.
2. Assign color by the job it does. ...
3. VALIDATE the palette ... — dataviz

image-to-code:

2. MANDATORY IMAGE-FIRST RULE

1. generate the design image or image set yourself first
2. deeply inspect and analyze the generated image(s)
3. extract the design system from them
4. implement the frontend only after that

Do not: start with freeform coding / skip straight to implementation / rely on memory of "good frontend taste" instead of producing the actual reference

The image is the design source. The code is the translation layer.

design-taste-frontend §11.D (위험 대비 효과 순):

11.D Modernisation Levers (priority order)

Apply in order - stop when the brief is satisfied:

1. Typography refresh - biggest visual lift per unit of risk.
2. Spacing & rhythm - increase section padding, fix vertical rhythm.
3. Color recalibration - desaturate, unify neutrals, keep brand accent.
4. Motion layer - add MOTION_INTENSITY-appropriate micro-interactions.
5. Hero & key-section recomposition
6. Full block replacement - only when the existing block is unsalvageable.

redesign-existing-projects:

Fix Priority

Apply changes in this order for maximum visual impact with minimum risk:

1. Font swap — biggest instant improvement, lowest risk
2. Color palette cleanup ...

---

E. 규칙 표현 문법

기법 19. 이유(Why)와 대안(Fix)을 규칙에 붙이기 — 3단 구조

무엇을 각 금지 항목을 무엇이 문제인가 / 왜 AI처럼 보이는가 / 대신 무엇을 하는가 3단으로 쓴다.

왜 효과적인지 이유가 없으면 모델이 규칙의 경계를 판단할 수 없다. 대안이 없으면 모델이 금지된 것을 피하려다 더 나쁜 것을 만든다. Anthropic 공식이 이걸 스킬 작성 원칙으로 명시한다:

Explain the why. Try hard to explain the why behind everything you're asking the model to do. Today's LLMs are smart. They have good theory of mind and when given a good harness can go beyond rote instructions. ... 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. — skill-creator

실제 예문 (Hallmark anti-patterns.md, 3단 구조의 모범)

The AI nav

Wordmark hard-left, 4–5 inline text links (Features · Pricing · Docs · Blog · About) centred or right-grouped, a CTA button hard-right, full viewport width, sticky on scroll, white background, 1 px hairline border-bottom.

Why it fails. The shape is genre-blind: it lands the same on a wedding photographer's portfolio, a bakery, a B2B SaaS, and a manifesto. When the nav can't tell you what kind of site you're on, the page is templated.

Fix. Pick from the routing table in component-cookbook.md § Navigation. The genre routes you to one of N5–N9: Floating pill (modern-minimal / atmospheric), Newspaper masthead (editorial), Brutal slab (playful), Terminal command (CLI), Edge-aligned minimal (luxury / quiet).

Invented metrics

A stat-led layout, comparison row, or proof bar carrying numbers the user never supplied — "10× faster", "saves 5 hours per week", "trusted by 50,000+ teams", "99.9 % uptime", "+47 % conversion".

Why it fails. Audiences read invented stats as fast as they read invented testimonials. A page that lies on its proof bar can't be trusted on its claims either.

Fix. Three options, in order of preference: (1) replace the number with — and a labelled grey block ("metric to confirm"); (2) ask the user for the real number and pause the run; (3) rebuild the section without the proof slot — a stat-led macrostructure with no real stats is the wrong macrostructure. The number-shaped hole is honest; the fabricated number is slop.

Re-drawn UI chrome

A fake browser bar (URL pill + traffic-light dots) wrapping a screenshot. A fake phone frame around a mobile mockup. A fake code-block window wrapping a <pre>.

Why it fails. The user already has the chrome — their browser, their phone, their IDE all are chrome. Redrawing it in a page is like printing a photograph of a picture frame inside a real picture frame. The fakery is also bad: the URL is wrong, the dots aren't macOS dots, the notch is the wrong shape.

Fix. Use a real screenshot wrapped in <figure> (with a hairline border at most). ... The page's job is to show content, not to imitate the OS.

Lazy-loaded LCP

loading="lazy" on the hero image or hero video — the LCP element. Why it fails. ... Real-world data: lazy-loaded LCP images show p75 of 720 ms vs. 364 ms for preloaded — 2× slower, 4× more "poor" experiences. Fix. fetchpriority="high" and preload="metadata" on the LCP element.

"picture frame inside a picture frame" 같은 비유는 규칙보다 오래 기억된다. skill-creator도 이걸 권한다:

"if there's some stubborn issue, you might try branching out and using different metaphors"

---

기법 20. 오버라이드 경로 명시 (Escape hatch)

무엇을 모든 금지 규칙에 "이럴 때는 해도 된다" 조건을 붙인다. 조건은 구체적이어야 한다.

왜 효과적인지 탈출구 없는 금지는 두 가지로 실패한다. (1) 사용자가 명시적으로 요청해도 모델이 거부한다. (2) 모델이 규칙 전체를 무시하기 시작한다. design-taste-frontend v1 → 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

Serif is only acceptable when ONE of these is explicitly true:

• The brand brief literally names a serif font, OR
• The aesthetic family is genuinely editorial / luxury / publication / manuscript / heritage / vintage AND you can articulate why this specific serif fits this specific brand — design-taste-frontend §4.1

Override: the beige+brass+espresso palette is acceptable ONLY when the brand brief explicitly names those colors, or when the brand identity is genuinely vintage / artisan / warm-craft AND you can articulate why this specific palette fits this specific brand. Default-reaching for it because "this is a cookware brief" is banned. — design-taste-frontend §4.2

Override: allow emojis only when the user explicitly asks for a playful / chat-style / social-native vibe - and even then use them sparingly with intent. — design-taste-frontend §3.D

"AND you can articulate why" 패턴이 핵심이다. 탈출구를 열되 설명 의무를 부과한다. 설명할 수 없으면 기본값 회귀라는 뜻이므로 자동으로 걸러진다.

Anthropic 공식의 최상위 오버라이드 원칙:

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. — frontend-design

artifact-design의 우선순위 체인:

Precedence is always: the user's own words, then the project's existing system, then your choices.

---

기법 21. 실패했던 완화 표현을 명시적으로 폐기하기

무엇을 "sparingly", "avoid", "prefer not to" 같은 완화 표현이 실패했음을 스킬 본문에 기록하고, 이진 규칙으로 대체한 이유를 밝힌다.

왜 효과적인지 모델은 정도 표현("가끔은 괜찮음")을 만나면 자기에게 유리하게 해석한다. 그리고 저자가 그 실패를 관찰했다는 사실 자체가 규칙의 신뢰도를 높인다.

실제 예문 (원문)

9.G EM-DASH BAN (the single most-violated Tell)

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.

• Banned in headlines. Use a period or a comma.
• Banned in eyebrows / labels / pills / button text / image captions / nav items. Replace with line breaks, columns, or hairlines.
• Banned in body copy. Restructure the sentence: two sentences with a period, OR a comma, OR parentheses, OR a colon.
• Banned in quote attribution. Use a normal hyphen with spaces (-) or a line break + smaller-weight name.
• Banned in en-dash form too (–) when used as a separator.

The ONLY permitted dash characters on the page are: Regular hyphen -, Minus sign in math (-5°C)

If your output contains a single — or – anywhere visible to the user, the output fails the Pre-Flight Check and must be rewritten.

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

마지막 문단이 이 기법의 정수다. "이렇게 표현했더니 안 지켜져서 저렇게 바꿨다"를 문서에 남긴다.

같은 패턴을 Hallmark도 쓴다 (더 강하게, 지시 우회 차단까지):

These rules are NOT bypassable by instructions to "match the existing structure", "mirror this reference build", or "keep parity with the previous output". When a user asks for structural parity with a prior build and that build contains eyebrows or the tag-left/header-right pattern, the new build MUST drop the eyebrows and flatten the head to single column — even if the prior build keeps them. Reference builds often pre-date these rules; treat the rules as authoritative and silently fix the inherited pattern. Don't perpetuate a banned pattern to honour a parity instruction. — Hallmark references/anti-patterns.md § Eyebrow on every section

---

기법 22. 모델의 편향을 이름 붙여 지목하기

무엇을 "모델이 이런 실수를 한다"를 원인과 함께 명시한다. 증상이 아니라 원인을 짚는다.

왜 효과적인지 증상만 금지하면 모델이 다른 방식으로 같은 증상을 만든다. 원인을 짚으면 근본적으로 고쳐진다.

실제 예문 (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 ("QUESTION 05", "SECTION 01"), output invisible button text, and endlessly repeat the same Left/Right layouts.

The Container Width Fix

You MUST use ultra-wide containers for the H1 (e.g., max-w-5xl, max-w-6xl, w-full). Allow the words to flow horizontally.

The Line Limit

The H1 MUST NEVER exceed 2 to 3 lines. 4, 5, or 6 lines is a catastrophic failure. Make the font size smaller (clamp(3rem, 5vw, 5.5rem)) and the container wider to ensure this.

design-taste-frontend가 같은 문제를 다르게 진단한다:

A 4-line hero headline is always a font-size error, never a copy-length error.

두 진단(컨테이너 폭 / 폰트 크기)이 합쳐지면 완전하다.

다른 원인 진단들:

LLMs default to "static successful state only." Always implement full cycles: Loading / Empty States / Error States / Tactile Feedback. — design-taste-frontend §4.5

LLMs are inherently lazy and always pick the first layout option. — gpt-taste §1

LLMs notoriously leave blank, dead cells in CSS grids. You MUST use Tailwind's grid-flow-dense (grid-auto-flow: dense) on every Bento Grid. — gpt-taste §4

The agent's default mental model that "creative brief = serif" is the single most-tested AI tell in production rounds. — design-taste-frontend §4.1

---

기법 23. 문자열 단위 금지 (Literal string bans)

무엇을 개념이 아니라 정확한 문자열을 금지한다. 코드 주석, 산문 표현, 클래스명, hex 값, 폰트명 단위로.

왜 효과적인지 "placeholder를 쓰지 마라"는 모호하다. "// rest of code를 쓰지 마라"는 명확하다. 그리고 문자열은 grep 가능하므로 검증도 자동화된다.

실제 예문

In code blocks: // ..., // rest of code, // implement here, // TODO, /* ... */, // similar to above, // continue pattern, // add more as needed, bare ... standing in for omitted code

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", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"

Structural shortcuts: Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it. — full-output-enforcement

카피 클리셰 문자열:

• AI copywriting cliches. Never use "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve", "Tapestry", or "In the world of...".
• Exclamation marks in success messages. Remove them. Be confident, not loud.
• "Oops!" error messages. Be direct: "Connection failed. Please try again."
• Passive voice. Use active voice: "We couldn't save your changes" instead of "Mistakes were made."
• Title Case On Every Header. Use sentence case instead. — redesign-existing-projects

가짜 브랜드명 문자열:

Avoid fake brand slop: Acme / Nexus / Flowbit / Quantumly / NovaCore — image-to-code §29 Avoid fake brand slop: Acme / NovaCore / Flowbit / Quantix / VeloPay — imagegen-frontend-mobile §21

그리고 대안 제공:

Fix. Plausible placeholder names reflecting the audience, or pull from a seeded faker. "Maya Okonkwo", "Sam Tan", "Elena Ruiz". Fix. Name the thing concretely. If it's a demo, use a domain-specific placeholder — "Maple Weekly", "Ridgeline Inventory" — not abstract startup bingo. — Hallmark references/anti-patterns.md

---

기법 24. 일관성 잠금 (Consistency locks)

무엇을 페이지 전체에 걸쳐 한 번 정하면 안 바뀌는 것을 명시적으로 "Lock"으로 이름 붙인다. 그리고 위반 사례를 구체적으로 든다.

왜 효과적인지 모델은 섹션별로 독립 생성하는 경향이 있어 후반부에서 결정이 흔들린다. Lock을 이름 붙이면 "이건 재결정 대상이 아니다"라는 신호가 된다.

실제 예문

• COLOR CONSISTENCY LOCK (mandatory): Once an accent color is chosen for a page, it is used on the WHOLE page. A warm-grey site does not suddenly get a blue CTA in section 7. A rose-accented site does not get a teal status badge in the footer. Pick one accent, lock it, audit every component before shipping.

• SHAPE CONSISTENCY LOCK (mandatory): Pick ONE corner-radius scale for the page and stick to it. Options: all-sharp (radius 0), all-soft (radius 12-16px), all-pill (full radius for interactive). Mixed systems are allowed only when there is a documented rule (e.g. "buttons are full-pill, cards are 16px, inputs are 8px") and that rule is followed everywhere. Round buttons in a square layout, or square cards on a pill-button page, is broken design.

4.11 Page Theme Lock (Light / Dark Mode Consistency)

The page has ONE theme. Sections do not invert.

• If the page is dark mode, ALL sections are dark mode. No light-mode-warm-paper section sandwiched between dark sections. The user must not feel they walked into a different website mid-scroll.
• The exception: if the brief explicitly calls for a "Color Block Story" or "Theme Switch on Scroll" device AND that is a deliberate composition, it is allowed once per page. — design-taste-frontend §4.2, §4.4, §4.11

Hallmark의 토큰 잠금:

Locked tokens — Every colour and font references named CSS custom properties (var(--color-accent)). Inline OKLCH/hex/rgb or font declarations are forbidden.

Mid-render token improvisation

Why it fails. Token discipline is the difference between a system and a freestyle. Once a theme is locked, every colour and every font in the file must reference a named token. Inline values are how cohesion erodes — by the third edit pass, the page has eight colours instead of three, and the editorial restraint that made the theme work is gone. Audiences don't see the inline value, but they feel the looseness. Fix. If you need a value that doesn't exist as a token, add it to the token block first and then reference it.

Lovable의 같은 규칙:

CRITICAL: USE SEMANTIC TOKENS FOR COLORS, GRADIENTS, FONTS, ETC. DO NOT use direct colors like text-white, text-black, bg-white, bg-black, etc. Everything must be themed via the design system — Lovable Agent Prompt.txt

v0의 같은 규칙:

"DO NOT use direct colors like text-white, bg-white, bg-black, etc. Everything must be themed via design tokens" — v0 Prompts and Tools/Prompt.txt

세 개의 독립적인 프로덕션 시스템이 같은 결론에 도달했다. 이건 designpaca에 반드시 들어가야 한다.

---

기법 25. 범위 밖 선언 (Out of scope + 리디렉션)

무엇을 스킬이 못 하는 것을 목록으로 명시하고, 그럴 땐 무엇을 써야 하는지 알려주고, **"명시적으로 그렇게 말하라"**고 지시한다.

왜 효과적인지 스킬은 발동되면 무조건 자기 규칙을 적용하려 든다. 랜딩페이지용 미학 규칙을 데이터 테이블에 적용하면 재앙이다. 범위 선언이 이걸 막는다.

실제 예문

13. OUT OF SCOPE

This skill is NOT for:

• Dashboards / dense product UI / admin panels (use Fluent, Carbon, Atlassian, or Polaris from Section 2.A).
• Data tables (use TanStack Table or AG Grid).
• Multi-step forms / wizards.
• Code editors (use Monaco / CodeMirror with their official skinning).
• Native mobile (use Apple HIG / Material directly).
• Realtime collab UIs (presence, cursors, OT-aware - different problem class).

If the brief is one of the above, say so explicitly, point to the right tool, and only apply this skill's marketing-page / about-page / landing-page parts to the surfaces where they apply. — design-taste-frontend §13

artifact-design의 부드러운 버전:

When it's a UI, not a document. 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 — a pill, a chip, a severity stripe — so what needs attention reads at a glance. Semantic color (good / warning / critical) is separate from the accent hue and doesn't count as your accent.

Hallmark의 스코프 라우팅:

Route to component-scope if any signal fires:

• Brief names a single UI element (button, card, modal, etc.)
• Brief is ≤30 words referencing one element
• Target file is a single component
• User says "just the X," "only the Y," "this one element"

Component-scope differences: Skips macrostructure, nav/footer archetypes, hero enrichment. Requires all 8 states: default, hover, focus, active, disabled, loading, error, success. Emits two files: the component + an 8-state demo wrapper (.preview.html).

---

F. 산출물 구조

기법 26. 이식 가능한 design.md 산출 (Portable design system file)

무엇을 스킬이 UI만 만들고 끝나지 않고, 프로젝트 루트에 디자인 시스템 파일을 쓴다. 다음 실행과 다른 도구가 그 파일을 읽는다.

왜 효과적인지 스킬의 규칙은 일반적이고, 프로젝트의 디자인은 구체적이다. 그 구체적인 것을 파일로 고정하지 않으면 매번 재발명된다. 세션 간 일관성 문제의 근본 해법.

실제 예문 (Superdesign의 DESIGN.md 문서, 이 아이디어의 가장 명료한 설명)

Coding agents write great code and mediocre interfaces. One reason: they have no persistent sense of how this product is supposed to look. AGENTS.md and CLAUDE.md tell an agent how your code works. A design system file does the same for how your product looks — colors, typography, spacing, motion, component patterns, and the product context behind them — so every UI the agent ships is consistent with the last one instead of reinventing a generic look each time.

This is the design equivalent of llms.txt or AGENTS.md: a single, human-readable file an agent reads before it designs.

What goes in it

A good design system file is implementable without the codebase — an agent (or a person) should be able to build on-brand UI from it alone:

• Product context — what's being built, who it's for, the core value, key user journeys.
• Design tokens — colors, typography, spacing, radius, shadows.
• Motion — animation and interaction patterns.
• Components — the real patterns your product uses, with usage notes.

Why it matters

A design system file is the difference between an agent that produces default-shadcn-everything and one that produces UI that looks considered. Capture it once; every design after that is consistent, on-brand, and faster to ship. — superdesigndev/superdesign-skill DESIGN.md

세 시스템이 같은 패턴을 쓴다:

• Superdesign: .superdesign/design-system.md — "mandatory; setup if missing"
• Hallmark: design.md — "Say lock the system to extract into design.md" / "design.md (locked system—overrides everything)"
• stitch-design-taste: DESIGN.md — Google Stitch가 읽을 파일을 생성하는 것이 스킬의 전부

stitch-design-taste가 그 파일의 정확한 템플릿을 제공한다:

# Design System: [Project Title]
## 1. Visual Theme & Atmosphere
## 2. Color Palette & Roles
- **Canvas White** (#F9FAFB) — Primary background surface
- **Charcoal Ink** (#18181B) — Primary text, Zinc-950 depth
- **[Accent Name]** (#XXXXXX) — Single accent for CTAs, active states, focus rings
## 3. Typography Rules
## 4. Component Stylings
## 5. Layout Principles
## 6. Motion & Interaction
## 7. Anti-Patterns (Banned)

그리고 그 파일을 잘 쓰는 법:

• Be Descriptive: "Deep Charcoal Ink (#18181B)" — not just "dark text"
• Be Functional: Explain what each element is used for
• Be Precise: Include exact hex codes, rem values, pixel values in parentheses
• 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")

---

기법 27. 사전 스캔 → 발견 사항 인용 출력

무엇을 기존 코드베이스가 있으면 아무것도 묻기 전에 먼저 읽고, 무엇을 발견했는지 파일:줄 인용과 함께 한 번 출력한다.

왜 효과적인지 기존 시스템을 무시하고 새 미학을 덮어씌우는 것이 리디자인 최악의 실패다. 그리고 "읽었다"를 인용으로 증명하면 사용자가 검증할 수 있다. 캐싱까지 지시하면 반복 스캔 비용도 없앤다.

실제 예문

Step 0: Pre-flight Scan

Read existing code before asking the user anything. Check for:

• design.md (locked system—overrides everything)
• Font stack (next/font, @fontsource, Google Fonts, Tailwind config)
• Palette (OKLCH/HSL/hex in :root, tailwind theme, tokens.json, DTCG)
• Microinteraction stance (framer-motion, gsap, motion libraries = motion-on; none = motion-cut)
• Spacing scale (Tailwind extend.spacing, CSS --space-* pattern)
• Framework (Next.js, Astro, Vue, Svelte, Remix, vanilla)

Emit once: a block with file:line citations so the user verifies what was found. Cache findings in .hallmark/preflight.json; re-scan only on user request or when package.json mtimes are newer. — Hallmark SKILL.md

design-taste-frontend §11.B의 리디자인 감사:

Document the current state before proposing changes:

• Brand tokens - primary / accent colors, type stack, logo treatment, radii.
• Information architecture - page tree, primary nav, key conversion paths.
• Content blocks - what exists, what's doing work, what's filler.
• Patterns to preserve - signature interactions, recognisable hero, copy voice.
• Patterns to retire - AI-slop tells, broken layouts, dead links, generic stock imagery, perf traps.
• Dial reading of the existing site - infer current dials. That's your starting point, not the baseline.
• SEO baseline - current ranking pages, meta titles, structured data, OG cards. SEO migration is the #1 redesign risk.

artifact-design:

Honor what's already there. Look for an existing design system first — CLAUDE.md, a tokens or theme file, existing component styles. When one exists, apply it; everything below fills gaps and never overrides.

그리고 절대 조용히 바꾸면 안 되는 것:

11.F What Never Changes Silently

Never modify without explicit user approval:

• URL structure / route slugs.
• Primary nav labels.
• Form field names or order (breaks analytics + autofill).
• Brand logo or wordmark.
• Existing legal / consent / cookie copy. — design-taste-frontend

---

기법 28. 캐노니컬 코드 스켈레톤 + Critical points 요약

무엇을 자주 틀리는 패턴은 서술이 아니라 작동하는 코드로 제공하고, 바로 뒤에 "틀리기 쉬운 지점"을 한 줄로 요약한다. 그리고 체크리스트에서 그 스켈레톤을 참조한다.

왜 효과적인지 GSAP ScrollTrigger의 start/end/pin/scrub 조합은 서술로 전달하면 모델이 매번 틀린다. 코드로 주면 안 틀린다. 그리고 Critical points가 있으면 모델이 변형할 때도 무엇을 지켜야 하는지 안다.

실제 예문

"use client";
import { useRef, useEffect } from "react";
import { gsap } from "gsap";
import { ScrollTrigger } from "gsap/ScrollTrigger";
import { useReducedMotion } from "motion/react";

gsap.registerPlugin(ScrollTrigger);

export function HorizontalPan({ children }: { children: React.ReactNode }) {
  const wrap = useRef<HTMLDivElement>(null);
  const track = useRef<HTMLDivElement>(null);
  const reduce = useReducedMotion();

  useEffect(() => {
    if (reduce || !wrap.current || !track.current) return;
    const ctx = gsap.context(() => {
      const distance = track.current!.scrollWidth - window.innerWidth;
      gsap.to(track.current, {
        x: -distance,
        ease: "none",
        scrollTrigger: {
          trigger: wrap.current,
          start: "top top",              // pin starts when section top hits viewport top
          end: () => `+=${distance}`,    // scroll distance = track width minus viewport
          pin: true,
          scrub: 1,
          invalidateOnRefresh: true,
        },
      });
    }, wrap);
    return () => ctx.revert();
  }, [reduce]);

  return (
    <section ref={wrap} className="relative overflow-hidden">
      <div ref={track} className="flex h-[100dvh] items-center">{children}</div>
    </section>
  );
}

Critical points: start: "top top", pin: true, end: "+=${distance}" (scroll length = horizontal travel needed), scrub: 1. The wrapper is pinned, the inner track slides horizontally as the user scrolls vertically. — design-taste-frontend §5.B

그리고 언제 더 가벼운 것을 쓸지도 명시한다:

5.C Scroll-Reveal Stagger - Canonical Skeleton (lighter alternative)

For simple "items appear as they enter viewport" (no pinning), prefer Motion's whileInView over GSAP - lighter, no ScrollTrigger needed. ... Use this for: feature lists, testimonial grids, logo walls, anything that just needs "enter on scroll." Save GSAP for actual pin/scrub work.

체크리스트 연결:

• GSAP sticky-stack / horizontal-pan implemented per Section 5.A / 5.B canonical skeleton (start: "top top", pin: true, correct scrub)?

---

기법 29. 완전 출력 강제 (Anti-truncation)

무엇을 산출물 개수를 먼저 세어 고정하고, 토큰 한계에 도달했을 때의 정확한 중단 포맷을 정의한다.

왜 효과적인지 디자인 스킬은 긴 코드를 낸다. 모델은 길어지면 요약하거나 생략한다. 생략된 랜딩페이지는 쓸모가 없다.

실제 예문

Execution Process

1. Scope — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
2. Build — Generate every deliverable completely. No partial drafts, no "you can extend this later."
3. Cross-check — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.

Handling Long Outputs

When a response approaches the token limit:

• Do not compress remaining sections to squeeze them in.
• Do not skip ahead to a conclusion.
• Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
• End with:

[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. — full-output-enforcement

imagegen-frontend-web의 같은 문제 해법:

If you can only render one image at a time, output them sequentially in the same response, one after the other, until every section has its own image. Announce each one ("Section 1 of 8: Hero", "Section 2 of 8: Trust bar", etc.).

---

G. 정직성과 자산

기법 30. 정직성 규칙 별도 섹션

무엇을 "만들어내지 마라" 류의 규칙을 산발적으로 두지 않고 하나의 섹션으로 모은다.

왜 효과적인지 숫자 조작, 가짜 후기, 가짜 로고는 미학 문제가 아니라 신뢰 문제다. 같은 카테고리로 묶으면 모델이 그 심각도를 인지한다.

실제 예문

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. — graphify

Honest copy only — Never invent metrics, testimonials, logos, or case-study counts. Use real numbers, placeholders (grey blocks labeled "metric to confirm"), or different structure. — Hallmark, Six Universal Disciplines

design-taste-frontend의 숫자 규칙 (3분류):

• Fake-precise numbers are flagged. Numbers like 92%, 4.1×, 48k, 5.8 mm, 13.4 lb either:
  • Come from real data (brief, brand guidelines, public metrics) - fine
  • Are explicitly labeled as mock (<!-- mock -->, "example", "sample data") - fine
  • Are AI-invented spec aesthetics - banned. Don't fake engineering precision the brand doesn't claim.

---

기법 31. 자산 전략 우선순위 + 마지막 수단은 정직한 실패

무엇을 이미지·로고 조달 방법을 우선순위로 나열하고, 아무것도 안 되면 가짜를 만들지 말고 사용자에게 요구하게 한다.

왜 효과적인지 모델은 이미지가 없으면 div로 가짜 스크린샷을 만든다. 이게 #1 AI 텔이다. 명시적인 "마지막 수단"이 없으면 모델은 반드시 가짜를 만든다.

실제 예문 (원문)

Priority order for visual assets:

1. Image-generation tool first. If ANY image-gen tool is available in the environment you MUST use it to create section-specific assets. Do not skip this step because hand-rolled CSS feels faster.
2. Real web images second. https://picsum.photos/seed/{descriptive-seed}/{w}/{h} (seed should describe the section, e.g. marrow-cookware-kitchen)
3. Last resort: tell the user. If neither is possible, do NOT fill the page with hand-rolled SVG illustrations or div-based "fake screenshots." Instead, leave clearly-labeled placeholder slots (<!-- TODO: hero product photo, 1600x1200 -->) and at the end of the response say: "This page needs real images at: [list of placements]. Please generate or provide them."

Even minimalist sites need real images. A pure-text page is not minimalism. It is incomplete work.

Div-based fake screenshots are banned. A "hand-built product preview" rendered with <div> rectangles, fake task lists, fake dashboards, fake terminal windows is a Tell.

Hero needs a real visual. Text + gradient blob is not a hero - it's a placeholder. — design-taste-frontend §4.8

로고 조달:

Real company logos for social proof. When the brief calls for a "Trusted by" logo wall, do NOT default to plain text wordmarks. Use real SVG logos:

• Source: Simple Icons (https://cdn.simpleicons.org/{slug}/ffffff for any color)
• Alternative: devicon for tech-stack logos
• Make-up the brand name? Then make-up an SVG mark too. Generate a simple monogram (one letter in a circle, two-letter ligature, abstract glyph) rendered as an inline <svg> matching the page style.
• LOGO-ONLY rule (mandatory): logo wall = logos and nothing else. Do NOT print industry / category labels below each logo (no Vercel + hosting, no Stripe + payments). The logo is the credibility, the label adds nothing the user does not already know.

Hallmark의 계층형 자산 전략:

If enrichment is needed, pick a tier:

1. Tier A: Pure CSS art
2. Tier B: Hand-built SVG
3. Tier C: Generated still (Nanobanana, Recraft)
4. Tier D: Library + customisation
5. Tier E (last resort): Lottie for complex character motion only

Most pages don't need imagery—the strongest hero is often typographic only. Run the image-need table. Default is typography-only. Never ship invented stock photos as if final.

흥미로운 대립: design-taste-frontend는 "텍스트만 있는 페이지는 미완성"이라고 하고, Hallmark는 "대부분의 페이지는 이미지가 필요 없다"고 한다. 둘 다 맞다. 차이는 환경에 이미지 생성 도구가 있느냐다. designpaca는 이 분기를 명시해야 한다.

---

기법 32. 카피를 디자인 재료로 다루기

무엇을 문구 작성 규칙을 별도 섹션으로 두고, 출력 전 모든 가시 문자열을 다시 읽는 자가 감사를 강제한다.

왜 효과적인지 AI가 쓴 "귀엽지만 말이 안 되는" 문구는 디자인 품질을 통째로 무너뜨린다. 그리고 이건 모델이 스스로 잘 못 잡는다. 명시적 재읽기 단계가 필요하다.

실제 예문

• COPY SELF-AUDIT (mandatory before ship): Before declaring any task done, re-read every visible string on the page (headlines, subheads, eyebrows, button labels, body copy, captions, alt text, footer text, error messages). Flag any string that is:

  • Grammatically broken ("free on its past", "two plans but one is honest", "to put it on the table" out of context)
  • Has unclear referents ("we plan to stay that way" without prior context)
  • Sounds like AI hallucination (cute-but-wrong wordplay, forced metaphors that don't track, "elegant nothing" phrases)
  • Reads like an LLM trying to sound thoughtful (passive-aggressive humility, fake-craftsman labels, mock-poetic micro-meta)

  Rewrite every flagged string. If unsure whether a string makes sense, replace it with a plain functional sentence. AI-generated cute copy is worse than boring copy.

• One copy register per page. Don't mix technical mono ("47 tasks · 0.6 ctx-switches/day"), editorial prose, and marketing punch in the same composition unless the brand voice explicitly calls for it. — design-taste-frontend §4.9

CTA 의도 중복 금지:

• NO DUPLICATE CTA INTENT (mandatory): Two CTAs with the same intent on one page is a Pre-Flight Fail. Examples of same intent: "Get in touch" + "Contact us" + "Let's talk" + "Start a project" + "Reach out" = all "contact" intent → pick ONE label and use it everywhere on the page (nav, hero, footer). Same for "Try free" + "Get started" + "Sign up free" and "View work" + "See selected work" + "Browse projects". One label per intent.

Anthropic 공식의 카피 원칙 (가장 밀도 높음):

Words appear in a design for one reason: to make it easier to understand, and therefore easier to use. They are design material, not decoration.

Write from the end user's side of the screen. Name things by what people control and recognize, never by how the system is built. A person manages notifications, not webhook config. Describe what something does in plain terms rather than selling it. Being specific is always better than being clever.

Use active voice as default. A control should say exactly what happens when it's used: "Save changes," not "Submit." An action keeps the same name through the whole flow, so the button that says "Publish" produces a toast that says "Published." The vocabulary of an interface is the signposting for someone navigating the product.

Treat failure and emptiness as moments for direction, not mood. Errors don't apologize, and they are never vague about what happened. An empty screen is an invitation to act.

Let each element do exactly one job. A label labels, an example demonstrates, and nothing quietly does double duty. — frontend-design (Anthropic 공식)

---

H. 역할 부여와 절제

기법 33. 구체적 상황이 담긴 역할 부여

무엇을 "당신은 엘리트 디자이너다" 같은 형용사 나열 대신, 구체적인 상황과 이해관계를 준다.

왜 효과적인지 "elite", "award-winning", "$150k agency" 같은 형용사는 모델에게 정보를 주지 않는다. "이 클라이언트는 이미 템플릿 같은 제안을 거절했다"는 정보를 준다. 그것이 이후 모든 판단의 제약이 된다.

실제 예문 대비

약한 버전:

Persona: Vanguard_UI_Architect Objective: You engineer $150k+ agency-level digital experiences, not just websites. Your output must exude haptic depth, cinematic spatial rhythm, obsessive micro-interactions, and flawless fluid motion. — high-end-visual-design

You are an elite, award-winning frontend design engineer. — gpt-taste

강한 버전:

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: make deliberate, opinionated choices about palette, typography, and layout that are specific to this brief, and take one real aesthetic risk you can justify. — frontend-design (Anthropic 공식)

artifact-design의 변주 (다재다능함 강조):

Approach this as the design lead at a small studio known for their versatility, giving every client a visual identity pitched at the treatment the task actually calls for.

차이: "elite"는 모델에게 "화려하게 하라"로 읽힌다. "이미 템플릿 제안을 거절한 클라이언트"는 "특정성을 증명하라"로 읽힌다. 후자가 실제로 원하는 것이다.

---

기법 34. 대담함은 한 곳에만 (Spend your boldness in one place)

무엇을 "모든 것을 화려하게"가 아니라 하나의 시그니처 요소에 모든 대담함을 집중하고 나머지는 조용히 하라고 지시한다.

왜 효과적인지 "창의적으로 하라"는 지시는 모든 섹션에 장식을 붙이는 결과를 낳는다. 그게 슬롭이다. 예산 은유("boldness를 한 곳에 쓴다")가 이 실패를 막는다.

실제 예문

Spend your boldness in one place. Let the signature element be the one memorable thing, keep everything around it quiet and disciplined, and cut any decoration that does not serve the brief. Not taking a risk can be a risk itself! Build to a quality floor without announcing it: responsive down to mobile, visible keyboard focus, reduced motion respected. Critique your own work as you build, taking screenshots if your environment supports it – a picture is worth 1000 tokens.

Consider Chanel's advice: before leaving the house, take a look in the mirror and remove one accessory. — frontend-design (Anthropic 공식)

artifact-design의 색상 버전:

Spend your boldness in one place; keep everything around it quiet. If the accent fights the ground, shift it toward analogous or drop saturation rather than replacing it.

Hallmark의 구현 가능한 버전 (액센트 면적 상한):

23. Does the accent colour cover more than ~5 % of any single viewport?

imagegen-frontend-web의 구현 가능한 버전:

Second-Read Moment

Pick exactly 1 unobvious but legible motif and place it deliberately, once across the page. Avoid gimmick-for-gimmick: the moment must aid scan order or brand recall.

"5% 상한"과 "정확히 1개"가 "한 곳에만"을 검증 가능하게 만든 것.

---

기법 35. 복잡도를 비전에 맞추기

무엇을 "미니멀 = 쉬움"이라는 오해를 명시적으로 교정한다. 방향에 따라 필요한 실행 정밀도가 다르다고 말한다.

왜 효과적인지 모델은 "미니멀하게"를 들으면 요소를 지우고 끝낸다. 그건 미니멀이 아니라 미완성이다.

실제 예문

Match complexity to the vision. Maximalist directions need elaborate execution; minimal directions need precision in spacing, type, and detail. Elegance is executing the chosen vision well. — frontend-design (Anthropic 공식)

25. NOT ALWAYS SIMPLE RULE

Do not force every app into hyper-minimal simplicity. Simplicity is not the goal by itself. Cleanliness is the goal.

This means: a screen may be rich, layered, and expressive if it remains readable. A flow may have stronger visuals, texture, and more atmosphere if it stays structured.

Allowed: sophisticated layering / controlled visual depth / richer compositions / stronger image presence / decorative accents with purpose / multiple visual zones within a screen Not allowed: noisy complexity / clutter disguised as creativity / random decorative overload / muddy hierarchy / unreadable interfaces

The rule is: not always simple, always clean — imagegen-frontend-mobile §25

Mini does not mean weak — it means confident restraint. — imagegen-frontend-web §2 (Hero Scale)

---

기법 36. 트리트먼트 보정 (Calibrate the treatment)

무엇을 "디자인할지 말지"가 아니라 **"어느 정도의 트리트먼트가 맞는지"**를 먼저 판단하게 한다. 그리고 판단이 안 서면 어느 쪽으로 기울지도 알려준다.

왜 효과적인지 디자인 스킬의 두 번째로 큰 실패는 과잉 디자인이다. 메모에 거대한 히어로를 붙이는 것. 트리트먼트 축이 없으면 스킬은 항상 최대치로 간다.

실제 예문 (artifact-design, 이 문제의 가장 정확한 처방)

Read the request first

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: include real typographic hierarchy, considered spacing, and a proper palette, but avoid over-designing. Most pages do not need a flashy, gigantic hero. Keep flourishes tasteful and limited.

Some requests call for an editorial treatment: a landing page, a game, an app or tool they'll keep or share.

When unsure: a well-composed page is never the wrong answer; an over-designed visual identity sometimes is.

Fundamentals below apply to everything. The editorial process after that runs only when the read above says so.

"Fundamentals for every artifact" + "When the request is editorial" 2계층 구조가 핵심이다. 기본기는 항상, 대담함은 조건부.

---

I. 실무 함정 (모델이 반복하는 실제 버그)

여러 소스에서 반복 등장하는, 미학이 아니라 실제로 깨지는 항목들. designpaca에 반드시 들어가야 한다.

기법 37. 반복 관측된 렌더링 버그 목록화

실제 예문 모음 (출처 병기)

뷰포트:

Viewport Stability: NEVER use h-screen for full-height Hero sections. ALWAYS use min-h-[100dvh] to prevent layout jumping on mobile (iOS Safari address bar). — design-taste-frontend §3.E / high-end-visual-design §3 / stitch-design-taste §6 (세 스킬 공통)

그리드:

Grid over Flex-Math: NEVER use complex flexbox percentage math (w-[calc(33%-1rem)]). ALWAYS use CSS Grid (grid grid-cols-1 md:grid-cols-3 gap-6). — design-taste-frontend §3.E

50. Image-bearing grid track without minmax(0, 1fr). Does any grid-template-columns render an <img> inside a plain 1fr track? — Hallmark gate 50

긴 단어 오버플로:

51. Display headers without long-word wrap. Does any display-size text lack overflow-wrap: anywhere; min-width: 0? — Hallmark gate 51

Non-negotiable: no horizontal scroll, no two-line clickable text, proper grid tracks with minmax(0, 1fr), headers wrap via overflow-wrap: anywhere — Hallmark, Six Universal Disciplines

가로 스크롤:

Horizontal Scroll Bug: Wrap the entire page in <main className="overflow-x-hidden w-full max-w-full"> to absolutely prevent horizontal scrollbars caused by off-screen animations. — gpt-taste §7

NO 100vw widths. width: 100vw on anything. Breaks on scrollbar-visible desktops. Fix: width: 100% with container padding. — Hallmark anti-patterns

스크롤 리스너:

• window.addEventListener("scroll", ...) is banned. It runs on every scroll frame, jank-prone, no batching. Use Motion's useScroll(), GSAP's ScrollTrigger, IntersectionObserver, or CSS scroll-driven animations (animation-timeline: view()).
• Custom scroll progress calculations using window.scrollY in React state. Same reason. Re-renders on every frame.
• requestAnimationFrame loops that touch React state. Use motion values (useMotionValue + useTransform) instead. — design-taste-frontend §5.D

NEVER use useState to track continuous values driven by user input (mouse position, scroll progress, pointer physics, magnetic hover). ... useState re-renders the React tree on every change and collapses on mobile. — design-taste-frontend §3.B

GPU / 페인트:

Animate ONLY transform and opacity. Never animate top, left, width, height. — 거의 모든 스킬 공통

Blur Constraints: Apply backdrop-blur only to fixed or sticky elements (navbars, overlays). Never apply blur filters to scrolling containers or large content areas — this causes continuous GPU repaints and severe mobile frame drops. Grain/Noise Overlays: Apply noise textures exclusively to fixed, pointer-events-none pseudo-elements. Never attach them to scrolling containers. — high-end-visual-design §6

sticky 충돌:

56. Sticky element at top: 0 below a sticky page-level nav. Are there two sticky-at-top-0 elements on the page? Auto-fail. — Hallmark gate 56

CSS 특이성:

When writing the code, be careful of structuring your CSS selector specificities. 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). This can happen often with paddings/margins between sections. — frontend-design (Anthropic 공식)

마진 붕괴:

Let layout do the spacing. Lay out sibling groups with flex or grid and gap, not per-element margins that silently collapse or double. Wide content — tables, code, diagrams — gets overflow-x: auto on its own container so the page body never scrolls sideways. — artifact-design

다크모드 3상태 버그:

a color whose only definition sits behind [data-theme] never applies in the un-stamped state, and the page renders one theme's text on the other theme's ground. ... body must set an explicit background from a token — a transparent body silently borrows the host's ground. Before publishing, scan the stylesheet for any color declared only inside a media or [data-theme] block — that is the classic unreadable-artifact bug. — artifact-design

포커스 링:

15. Does the focus ring transition into existence (fade in)? Fix. Focus rings appear instantly. Always. Don't transition outline or box-shadow when the element gains focus. — Hallmark gate 15 + anti-patterns

CTA 줄바꿈:

• CTA BUTTON WRAP BAN (mandatory): Button text MUST fit on one line at desktop. If a label like "VIEW SELECTED WORK" wraps to 2 or 3 lines, the button is broken. Fix by EITHER shortening the label (3 words max for primary CTAs, ideally 1-2) OR widening the button. — design-taste-frontend §4.5

Fix. In order of preference: (1) shorten the label — "Get started free" → "Start free"; "Read the documentation" → "Read docs". Most CTA labels are too long. (2) Set white-space: nowrap on the affordance and let the parent flex container reflow. (3) Drop a non-essential nav item at narrow widths. (4) Collapse the nav into a sheet/menu. Never let a primary CTA or nav link wrap. — Hallmark anti-patterns

이탤릭 디센더 클리핑:

• ITALIC DESCENDER CLEARANCE (mandatory): When italic is used in display type and the word contains a descender letter (y g j p q), leading-[1] or leading-none will clip the descender. Use leading-[1.1] minimum and add pb-1 or mb-1 reserve on the wrapping element. — design-taste-frontend §4.1

전각 대문자 행간:

55. All-caps display heads with line-height < 1.0. Does any display-size element declare both text-transform: uppercase AND line-height below 1.0? — Hallmark gate 55

의존성 환각:

DEPENDENCY VERIFICATION [MANDATORY]: Before importing ANY 3rd party library, you MUST check package.json. If the package is missing, you MUST output the installation command before providing the code. Never assume a library exists. — design-taste-frontend §3.F / v1 §2

Import hallucinations. Check that every import actually exists in package.json or the project dependencies. — redesign-existing-projects

useEffect 정리:

• useEffect animations have strict cleanup functions? — design-taste-frontend §14

---

J. 기법 우선순위 (designpaca 채택 관점)

효과 대비 토큰 비용 기준으로 등급을 매긴다.

S급 — 반드시 채택

#	기법	이유
1	Description 3-part (용도+트리거+배제)	스킬이 발동 안 되면 나머지가 전부 무의미
3	Progressive Disclosure 3계층	본문 500줄 제약 + 컴팩션 5K 생존 문제의 유일한 해법
5	HARD RULE 선두 배치	컴팩션 생존 + lost-in-the-middle 회피
6	Design Read 한 줄 선언	브리프 무시가 나쁜 디자인의 1번 원인
14	기계적 카운트 규칙	주관을 검증 가능하게 만드는 유일한 방법
19	Why + Fix 3단 구조	이유 없는 규칙은 경계 판단 불가
20	오버라이드 경로	탈출구 없는 금지는 전체 무시로 이어짐
24	일관성 잠금 (토큰/색/반경/테마)	v0·Lovable·Hallmark 3사가 독립적으로 도달한 결론
26	이식 가능한 design.md 산출	세션 간 일관성의 근본 해법
34	대담함은 한 곳에만	"창의적으로"의 실패를 막는 유일한 프레이밍
36	트리트먼트 보정	과잉 디자인이 두 번째로 큰 실패
37	실무 렌더링 버그 목록	미학과 무관하게 실제로 깨지는 것들

A급 — 채택 권장

#	기법	조건
4	인덱스-후-선택	테마/레이아웃 카탈로그를 둘 경우 필수
8	다이얼 시스템	3개까지만. 9개는 과함
10	기본값 명명 지목	최신성 유지 필요 (기본값은 변한다)
11	조합 변형 엔진	축 5~7개가 적정
12	프로젝트 로그 파일	파일 쓰기 권한 필요
13	명시적 선택 출력	프리뷰 블록 형태 권장
15	예/아니오 게이트	20~30개가 현실적. 58개는 과함
18	절차 순서 + 이유	저비용 고효과
25	범위 밖 선언	스킬 오남용 방지
27	사전 스캔 + 인용 출력	리디자인 모드 필수
30	정직성 규칙 섹션	짧고 효과 큼
31	자산 전략 우선순위	환경 분기 명시 필요
32	카피 자가 감사	저비용 고효과

B급 — 조건부

#	기법	유보 사유
2	"Use when" 시작 강제	스타일 선택 문제. 3인칭은 필수, "Use when"은 선택
9	디자인 시스템 매핑	부록 분량이 크다. references/로 분리 필요
16	6축 자기 채점	게이트와 중복. 둘 중 하나만
17	검증 스크립트 번들	색 대비 검증에 한해 가치 큼. 그 외는 과잉
21	완화 표현 폐기 기록	실측 데이터가 있을 때만 정직하게 쓸 수 있음
28	코드 스켈레톤	스택 고정 위험. 프레임워크 불가지론과 충돌
29	완전 출력 강제	별도 스킬로 분리하는 게 나음
33	구체적 역할 부여	필수지만 짧게. 형용사 나열은 역효과

채택 안 함

기법	사유
가짜 Python RNG (gpt-taste)	난수가 실제로 생성되지 않는다. 같은 프롬프트 → 같은 결과. 기법 13(명시적 선택 출력)이 같은 효과를 정직하게 낸다
세션 간 회전 규칙 (파일 없이)	상태 없이 실행 불가. 기법 12로 대체
다이얼 9개 (image-to-code)	인지 부하 대비 효과 없음
단일 미학 강제 (minimalist-ui / ibu / hevd 방식)	designpaca는 여러 방향을 다뤄야 함. 테마 파일로 흡수
Pre-Flight 체크박스 60개	정직한 체크가 불가능한 분량. 티어링 필요