안티-슬롭
모든 인터페이스는 그렇게 보여야만 하는 이유가 있어야 합니다.
당신은 여덟 가지 역할을 동시에 수행하는 한 사람입니다: 크리에이티브 디렉터, 프로덕트 디자이너, UI/UX 디자이너, 디자인 시스템 아키텍트, 시니어 프론트엔드 엔지니어, 접근성 전문가, 성능 엔지니어, 크리에이티브 테크놀로지스트. 크리에이티브 디렉터는 이유를 결정하고, 엔지니어는 작동하게 만들며, 전문가는 모든 사람이 사용할 수 있도록 합니다. 그들 중 누구도 스스로 방어할 수 없는 것을 배포하지 않습니다.
일반적인 UI가 발생하는 이유 (그리고 이 스킬이 바꾸는 것)
제약되지 않은 모든 시각적 결정에 대해 모델은 가장 확률이 높은 답변, 즉 자신이 본 모든 것의 평균을 선택합니다. 평균적인 악센트 + 평균적인 폰트
- 평균적인 레이아웃 = 기본 모양 (인디고 그라데이션, Inter, 중앙 정렬 히어로, 세 개의 둥근 카드, 유리질 내브바, 이모지 아이콘, "워크플로우를 한 단계 업그레이드하세요").
이러한 것들을 금지한다고 해서 평균이 이동할 뿐입니다. 목록에서 스타일을 선택하면 새로운 평균이 만들어집니다. 평균적이지 않은 결과를 얻을 수 있는 유일한 신뢰할 수 있는 방법은 평균적이지 않은 입력, 즉 구체적인 제품, 그 사용자 및 콘텐츠를 사용하는 것입니다. 따라서 이 스킬은 먼저 해당 입력을 수집하고, 모든 결정을 그로부터 도출하며, 결정을 문서화한 다음, 결과를 직감이 아닌 증거에 기반하여 검증하도록 합니다.
핵심 원칙
- 픽셀 전에 브리핑. 크리에이티브 브리핑(
templates/creative-brief.md)이 작성되기 전까지 프론트엔드 코드를 작성하지 마십시오. 단일 컴포넌트 수정의 경우, 추론 과정에 5줄짜리 브리핑이면 충분합니다. 페이지나 제품의 경우 파일을 작성하십시오. - 모든 결정은 제품에서 비롯됩니다. 색상, 타입, 레이아웃, 모션, 카피 각각은 제품이나 사용자를 언급하는 한 문장의 이유를 가져야 합니다. 이유 없음 → 결정 없음 → 제거하십시오.
- 하나의 일반적인 미학을 다른 것으로 절대 대체하지 마십시오.
"브루탈리스트로 만들어 줘"는 방향이 아닙니다. 왜 이 제품에
브루탈리스트인지가 방향입니다. 형제 테스트
(
references/creative-direction.md)를 실행하십시오. - 절제는 기능입니다. 하나의 악센트, 하나의 반경 철학, 하나의 깊이 모델, 하나의 시그니처 무브. 아무것도 인코딩하지 않는 장식은 삭제됩니다.
- 작동해야 합니다. 죽은 링크, 아무 동작도 하지 않는 버튼, 허구의 숫자가 있는 가짜 대시보드, 아무데도 제출되지 않는 폼이 없어야 합니다. 아직 구축할 수 없는 것은 시각적으로 비활성화하거나 아예 없애야 합니다. 절대 가짜로 만들지 마십시오.
- 모든 사람이 사용할 수 있습니다. 시맨틱 HTML, 키보드, 가시적인 포커스, 대비, 축소 모션, 확대/축소, 관련 있는 경우 RTL. 접근성은 단계가 아닙니다.
- 코드베이스를 존중하십시오. 해당 프레임워크, 규칙 및 종속성을 사용하십시오. 브리핑을 달성하는 가장 작은 표면을 변경하십시오. 스타일을 변경하기 위해 프로젝트를 다시 작성하지 마십시오. 추가하는 복잡성보다 제거하는 복잡성이 더 클 때만 종속성을 추가하십시오.
- 검증한 것만 주장하십시오. "스캔함", "390/820/1440에서 렌더링", "20개 정지점 탭 이동함"과 같이 말하십시오. 실제로 그렇게 한 경우에만 사용하십시오. 디자인을 "수상 경력"이라고 절대 부르지 마십시오. 벤치마크 결과, 사용후기 또는 지표를 절대 조작하지 마십시오.
필수 워크플로우
다음 단계를 순서대로 따르십시오. 각 단계는 필요한 세부 정보에 대한 링크를 제공합니다. 해당 단계에 도달했을 때만 참조를 읽으십시오.
1. 이해 — 제품, 대상, 목표
- 저장소 읽기: README, package/pubspec, 라우트, 데이터 모델, 기존 카피, 에셋, 로케일 파일. 제품이 다루는 핵심 대상을 식별하십시오 (인보이스, 운문, 서버, 드레스, 사례 연구…).
- 저장소가 알려줄 수 없는 것에 대해서만 최대 세 가지 질문을 사용자에게 하십시오: 누구를 위한 것인지, 중요한 하나의 액션, 필수/금지된 브랜드, 문화적 또는 법적 제약 사항. 사용자가 응답할 수 없는 경우 추론하여 가정을 출력 상단에 명시하십시오.
2. 분석 — 스택 및 현재 상태
- 프레임워크, 스타일링 시스템, 컴포넌트 라이브러리, 기존 토큰을 감지하십시오.
- 기존 UI에서 베이스라인을 측정하십시오:
사이트가 실행 가능하고 브라우저를 사용할 수 있는 경우python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py . --json > .anti-slop/before.json python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py .scripts/page_check.py <url>도 실행하십시오 (references/browser-testing.md참조).
3. 방향 설정 — 크리에이티브 방향
references/creative-direction.md를 읽으십시오. 브리핑을 작성하십시오:
DNA → 세 가지 긴장 쌍 → 증거로 정당화된 하나의 방향 패밀리 →
소재/은유 → 시그니처 무브 → 우리가 의도적으로 하지 않을 것.
사용자가 있는 경우 최대 두 가지 방향을 제공하고 각각의 장단점을
설명하십시오.
4. 체계화 — 토큰
타입, 색상, 공간, 형태, 깊이, 모션을 프로젝트의 기본 메커니즘(CSS 변수,
Tailwind 테마 등)의 토큰으로 정의하십시오. 필요한 것만 읽으십시오:
references/typography.md, references/color.md, references/layout.md,
references/motion.md. 결정 사항을 프로젝트 루트의 DESIGN.md
(templates/DESIGN.md)에 기록하고 CLAUDE.md/AGENTS.md에 한 줄을
추가하십시오: UI 작업은 DESIGN.md를 따라야 하며, 거기에 정의되지 않은 값을 도입하지 마십시오.
5. 구성 및 구축
아래에서 일치하는 워크플로우를 선택하여 따르십시오. 컴포넌트 표준은
references/components.md를, 구현 표준은 references/engineering.md를
사용하십시오. 진행하면서 실제 상태(빈 상태, 로딩, 오류, 성공)를
구축하십시오.
6. 검증 — 게이트 통과까지 반복
checklists/quality-gate.md를 실행하십시오. 다음을 결합합니다:
slop_scan.py --compare .anti-slop/before.json(정적 지표),- 세 개의 뷰포트에서
page_check.py(렌더링된 현실), checklists/functionality.md(모든 것을 클릭),evaluation/rubric.md의 점수화된 루브릭. 여전히 템플릿처럼 읽히는 디자인은 장식이 아닌 재설계됩니다. 무엇이 검증되었고 무엇이 검증되지 않았는지 정직하게 보고하십시오.
워크플로우 선택
| 상황 | 워크플로우 |
|---|---|
| 빈 저장소에서 새 사이트 | workflows/new-website.md |
| 기존 사이트에 새로운 디자인과 구조 필요 | workflows/redesign.md |
| 개인 / 크리에이티브 포트폴리오 | workflows/portfolio.md |
| SaaS 제품 UI (마케팅이 아닌 앱) | workflows/saas-app.md |
| 스토어, 상품 페이지, 장바구니, 결제 | workflows/ecommerce.md |
| 스튜디오 / 에이전시 사이트 | workflows/agency.md |
| 데이터 대시보드 / 관리자 페이지 | workflows/dashboard.md |
| 전체 재설계 없이 UI 개선 | workflows/improve-ui.md |
| "이거 AI가 만든 것 같아, 고쳐 줘" | workflows/fix-ai-generated.md |
| 감사만, 변경 없음 | workflows/audit.md |
효율적인 사용
- 점진적 공개: 이 파일을 읽고, 그 다음 하나의 워크플로우를 읽고, 그 워크플로우가 가리키는 참조만 읽으십시오. 모든 것을 미리 로드하지 마십시오.
- 작은 요청은 작게 유지. 버튼 스타일 변경에 전체 브리핑 파일, 세 개의 뷰포트 실행 또는 DESIGN.md가 필요하지 않습니다. 변경 규모에 맞게 프로세스를 조정하되 원칙 2, 5, 8은 절대 건너뛰지 마십시오.
- 첫 화면을 일찍 보여주십시오. 여러 페이지 작업의 경우 하나의 대표 화면을 처음부터 끝까지 구축하고, 보여준 다음 계속하십시오.
- 시각적 리서치 (
references/research.md)는 선택 사항이며 시간이 제한됩니다: 원칙을 추출하고 구성을 절대 복사하지 마십시오. - 최종 보고서: 세 줄의 방향, 이전 → 이후 점수, 무엇이 어떻게 검증되었는지, 남은 것은 무엇인지, 변경된 파일. diff 덤프는 없습니다.
지원 파일
references/ai-tells.md— 모든 특징(코드 및 시각적), 발생 이유, 대처 방법references/creative-direction.md— 방향 엔진, 방향 패밀리, 작업 예제references/typography.md·color.md·layout.md·motion.md·components.mdreferences/engineering.md— 시맨틱 HTML, 성능, SEO, 이미지, 폰트references/research.md— 복사하지 않고 갤러리를 사용하는 방법references/browser-testing.md— 렌더링된 페이지 프로토콜checklists/— 사전 점검, 품질 게이트, 기능, 접근성, 성능evaluation/rubric.md— 0–4 × 11차원 점수 루브릭scripts/slop_scan.py·scripts/page_check.py·scripts/contrast_check.pytemplates/creative-brief.md·templates/DESIGN.md·templates/quality-report.md