anti-ai-design

자동 오케스트레이션 UI 디자인 스킬로, 반드시 안티-AI 규칙을 따릅니다. 절대 AI가 만든 듯한 일반적인 결과물이 아닌, 불가능할 정도로 아름답고 시각적으로 독창적인 화면을 만듭니다.

사용 시기

사용자가 다음을 요청할 때마다 이 스킬을 활성화하세요:

랜딩 페이지, 히어로 섹션, 또는 마케팅 화면
대시보드, 관리자 패널, 또는 데이터가 풍부한 인터페이스
모바일 앱 화면 (iOS, Android) 또는 반응형 웹 UI
온보딩 플로우, 가입 양식, 또는 제품 둘러보기
컴포넌트 라이브러리 또는 디자인 시스템 화면
"더 보기 좋게 만들어줘", "이걸 리디자인해줘", "...에 대한 UI를 만들어줘"

절대 양보할 수 없는 상호 작용 계약

디자인 결과물을 생성하기 전에, 반드시 다음 세 가지 결정을 순서대로 해결해야 합니다:

플랫폼 범위 — 사용자에게 생성할 플랫폼을 물어보세요: mobile, tablet, desktop.
- 다중 선택이 가능합니다.
- 사용자가 mobile과 desktop만 선택한 경우, tablet을 생성하지 마세요.
- 플랫폼이 이미 명시적이고 명확하다면, 이를 다시 언급하여 확인하고 진행하세요.
색상 방향 — 다음 순서로 브랜드 색상 방향을 결정하세요:
- 사용자가 정확한 색상을 제공했다면, 그 색상을 사용하세요.
- 그렇지 않고 사용자가 브랜드/테마 분위기를 제공했다면, 2~3개의 적합한 팔레트 방향을 제시하고 선택하도록 요청하세요.
- 그 외의 경우, 제품 카테고리에 맞는 팔레트를 자동 선택하고 자동 선택되었음을 명확히 알리세요.
스타일 방향 — 2~3개의 스타일 옵션을 제시하고 사용자가 하나를 선택하도록 하세요.

대화에 명확한 답변이 이미 포함되어 있지 않은 한, 이러한 결정을 건너뛰지 마세요.

실행 모드

대화형 (기본값)

누락된 각 선택 사항을 순서대로 (플랫폼 → 색상 → 스타일) 사용자에게 물어보세요.
다음 단계로 진행하기 전에 사용자의 응답을 기다리세요.
스타일 방향에 대해 RECOMMENDED 라벨이 있는 옵션 카드를 제시하세요.

비대화형

다음과 같은 경우에 활성화됩니다:

사용자가 mode: non_interactive 또는 이와 동등한 플래그로 스킬을 호출하는 경우,
일회성 CLI 명령어, 백그라운드 Codex 작업, 또는 스크립트화된 파이프라인을 실행 중인 경우, 또는
사전 대화 맥락 없이 (요청 전 대화 턴 없이) 프롬프트를 제공하는 경우.

자동 선택 규칙 (순서대로 적용):

플랫폼 — 명시되지 않은 경우 기본값은 desktop입니다. 모바일 우선 신호(모바일 앱 설명, React Native 언급, "phone" 맥락)가 있는 경우 기본값은 mobile입니다.
색상 방향 — 대안을 제시하지 않고 감지된 프로젝트 유형에 가장 적합한 팔레트를 선택하세요.
스타일 방향 — 이 프로젝트 맥락에 적합한 2~3개의 후보 스타일 중에서 RECOMMENDED로 표시될 스타일을 선택하세요. 옵션 카드를 제시하지 마세요.

생성 전 필수 출력 헤더 (비대화형 전용):

자동 선택:
- 플랫폼: [선택된 플랫폼(들)]
- 팔레트: [팔레트 이름] — 기본 [16진수 값]
- 스타일: [스타일 이름] — [한 문장 분위기]
번들 생성을 진행합니다.

명확한 질문을 하지 마세요. 옵션 카드를 제시하지 마세요. 헤더 이후 바로 3단계로 진행하세요.

출력 계약 — 단일 HTML 파일이 아닌 CJX 번들

기본 출력은 단일 느슨한 HTML 파일이 아닌 프로젝트의 번들 디렉토리입니다.

<앱-슬러그>-design/
  html/
    landing-page.html
    mobile-<화면>.html
    tablet-<화면>.html
    desktop-<화면>.html
  css/
    foundation.css
    shared.css
    landing-page.css
    mobile-<화면>.css
    tablet-<화면>.css
    desktop-<화면>.css
  js/
    app.js
    landing-page.js
    mobile-<화면>.js
    tablet-<화면>.js
    desktop-<화면>.js

번들 규칙

html/ 디렉토리에는 생성된 각 화면/플랫폼 조합당 하나의 HTML 파일이 포함됩니다.
css/foundation.css에는 고정된 디자인 토큰만 포함됩니다.
css/shared.css에는 공유 프리미티브, 유틸리티, 모션, 유리 레시피, 포커스 상태 및 공통 레이아웃 패턴이 포함됩니다.
화면별 CSS는 화면별 파일로 이동합니다.
js/app.js에는 공유 UI 도우미, 상태 토글, 모의 데이터 처리 및 접근성에 안전한 상호 작용이 포함됩니다.
화면별 JS는 필요한 경우에만 화면별 파일로 이동합니다.
사용자가 나중에 단일 파일 내보내기를 요청하면 독립형 HTML 내보내기를 추가로 제공할 수 있지만, 기본 계약은 CJX 번들입니다.

플랫폼 파일 명명 규칙

랜딩 페이지는 의미를 유지합니다: landing-page.html, landing-page.css, landing-page.js
앱 화면은 플랫폼 접두사를 사용합니다:
- mobile-<화면>.html
- tablet-<화면>.html
- desktop-<화면>.html
선택된 플랫폼에 대해서만 파일을 생성합니다.
사용자가 mobile과 desktop을 선택한 경우, 출력 번들에 tablet-* 파일이 포함되어서는 안 됩니다.

하나의 반응형 HTML 대신 별도 파일을 사용하는 이유

기본적으로 별도의 플랫폼 파일을 사용하는 이유는 다음과 같습니다:

각 플랫폼은 IA, 탐색, 밀도 및 CTA 배치가 실질적으로 다를 수 있습니다.
각 대상이 분리되어 있으면 검토 및 전달이 더 쉽습니다.
화면 의도가 명시적일 때 CJX 검증이 더 명확합니다.
데스크톱/태블릿/모바일은 종종 다른 중단점뿐만 아니라 다른 계층 구조가 필요합니다.

사용자가 명시적으로 단일 파일 전달을 요청하는 경우에만 단일 반응형 HTML이 허용됩니다.

하위 스킬 라우팅

현재 단계에 필요한 참조 파일만 로드하세요. 한 번에 모든 파일을 로드하지 마세요.

작업	로드	세부 사항
디자인 스타일 / 아트 방향 선택	`references/design-styles-catalog.md`	11개 카테고리의 36가지 스타일
트렌드 / 아트 팩 선택	`references/design-trends.md`	6가지 트렌드, 3가지 아트 방향 팩
디자인 레시피 적용	`references/design-recipes-catalog.md`	15가지 완전한 디자인 레시피
플랫폼 레이아웃 규칙 적용	`references/platform-rules.md`	모바일/iOS 26/데스크톱/태블릿 규칙
기초 토큰 고정 및 주입	`references/foundation-tokens.md`	토큰 고정 지침 및 형식
반경 문법 + 중첩 계층 구조 적용	`references/radius-choreography.md`	의미론적 반경 역할, 중첩 표면 규칙, 스타일군 반경 문법
UX / 고객 여정 규칙 적용	`references/ux-guidelines.md`	UX 적용, CJX 패턴
모션 안무 + 상호 작용 의도 적용	`references/motion-choreography.md`	모션 목적, 호버 정책, 상태 전환, 플랫폼 모션 규칙
번들 자산 소유권 + 매니페스트 감사 적용	`references/output-bundle-rules.md`	공유-대-화면 자산 규칙, 매니페스트, 자체 감사
출력 번들 생성	`references/output-template.md`	번들 구조, HTML 템플릿, 파일 계약

자동 오케스트레이션 흐름

다음 단계를 순서대로 실행하세요. 각 단계에는 조건부 로직이 있습니다. 정확히 따르세요.

1단계 — 맥락 감지

대화와 첨부된 파일에서 프로젝트 이름, 기존 브랜드 색상, 글꼴, 기술 스택, 대상 플랫폼 및 화면 목적을 스캔합니다.
프로젝트 유형을 다음 중 하나로 분류합니다: SaaS 제품 · 전자상거래 · 모바일 앱 · 포트폴리오 · 대시보드 · 마케팅 사이트 · 기타.
요청된 화면을 추출하고 개수를 셉니다.
플랫폼 범위를 mobile, tablet, desktop 중 하나 이상으로 결정합니다.
플랫폼 범위가 누락되었거나 모호한 경우: 다중 선택 옵션과 함께 정확히 하나의 플랫폼 선택 질문을 합니다:

모바일
태블릿
데스크톱

사용자가 이미 플랫폼을 지정한 경우, 다시 묻지 말고 정확히 그대로 유지합니다.
프로젝트에서 발견된 기존 브랜드 토큰(색상, 글꼴, 간격 척도)을 기록합니다. 이후 토큰 고정에 사용됩니다.
프로젝트 유형에 따라 색상 구성표 우선순위를 결정합니다:

다크 모드 우선 (다크가 기본 캔버스이고 라이트는 선택적 재정의):

대시보드 · 관리자 패널 · 데이터 중심 SaaS · 핀테크 · 개발자 도구 · 분석 · 모니터링 · 암호화폐/웹3 · 미디어/스트리밍 · 게임

라이트 모드 우선 (라이트가 기본 캔버스이고 다크는 선택적 재정의):

전자상거래 · 마케팅 사이트 · 포트폴리오 · 헬스케어 · 교육 · 식음료 · 라이프스타일

프로젝트 유형이 모호하거나 두 목록에 모두 맞지 않는 경우, 기본값은 라이트 모드 우선으로 하고 다크 모드를 추가 기능으로 제공합니다.

이 결정을 color_scheme_priority: dark_first | light_first로 전달합니다. 2단계 팔레트 옵션과 4단계 토큰 고정은 이 우선순위를 반영해야 합니다.

2단계 — 색상 + 디자인 방향

스타일 선택 전에 색상 방향을 결정합니다.
사용자가 명시적인 팔레트를 제공하지 않은 경우, 제품 카테고리에 맞고 1단계의 color_scheme_priority를 반영하는 2~3개의 팔레트 방향을 제시합니다:

dark_first 프로젝트의 경우: 다크 팔레트 옵션(예: OLED 다크-럭셔리, 일렉트릭 슬레이트, 딥 네이비)으로 시작하고, 라이트 옵션은 마지막 선택으로만 포함합니다.
light_first 프로젝트의 경우: 라이트 팔레트 옵션(예: 커머스 웜-에너지, 트러스트 쿨-뉴트럴)으로 시작하고, 브랜드에 맞는 경우에만 다크 옵션을 포함합니다.
사용자에게 하나를 선택하도록 요청합니다.

사용자가 선택을 거부하면, 가장 적합한 팔레트를 자동 선택하고 그 이유를 한 문장으로 설명합니다.
references/design-styles-catalog.md를 로드합니다.
카탈로그에서 프로젝트 유형, 선택된 팔레트 및 맥락에 가장 잘 맞는 2~3개의 스타일을 선택합니다.
각 선택된 스타일에 대해 다음 형식으로 옵션 카드를 생성합니다:

[N]. **스타일 이름** — RECOMMENDED (해당하는 경우)
분위기: [한 문장 분위기/무드]
주요 미적 특징: [3가지 정의적인 시각적 특성]

최적의 적합성을 기준으로 정확히 하나의 옵션을 RECOMMENDED로 표시합니다.
번호가 매겨진 목록을 사용자에게 제시하고 선택하도록 요청합니다. 진행하기 전에 응답을 기다리세요.
사용자가 목록에 없는 다른 스타일을 요청하면 수용하고 진행합니다.

3단계 — 번들 생성

선택된 플랫폼에 대해 references/platform-rules.md를 로드합니다.
CJX 번들 형식을 위해 references/output-template.md를 로드합니다.
자산 소유권, 공유 클래스 배치, 매니페스트 및 번들 자체 감사를 위해 references/output-bundle-rules.md를 로드합니다.
CSS를 작성하기 전에 반경 문법, 중첩 표면 계층 구조 및 역할 기반 곡률을 결정하기 위해 references/radius-choreography.md를 로드합니다.
최종 출력을 생성할 때 상태 완전성이 필수이므로 references/ux-guidelines.md를 로드합니다.
아래의 모든 안티-AI 디자인 규칙을 적용합니다.
각 선택된 플랫폼에 대해 별도로 플랫폼 규칙을 적용합니다.
컴포넌트 CSS를 작성하기 전에 선택된 스타일 방향에 대한 반경 문법을 결정합니다:

필요한 경우 필(pill)과 함께 2~4개의 기본 반경 계층을 선택합니다.
이를 의미론적 역할(shell, surface, inset, control, tight, pill)에 매핑합니다.
번들 전체에서 문법을 일관되게 유지합니다.
동일한 재료의 중첩 표면은 곡률이 점차 감소하도록 합니다.

다음을 포함하는 번들 디렉토리를 생성합니다:

html/
css/
js/
manifest.json

필요한 각 화면/플랫폼 조합에 대해 하나의 HTML/CSS/JS 트리오를 생성합니다.
요청된 화면과 선택된 플랫폼에 대해서만 생성합니다.
랜딩 페이지는 동일한 파일이 잘 작동하는 경우 플랫폼 간 의미를 유지할 수 있지만, 레이아웃이 플랫폼별로 의미 있게 변경되는 경우 플랫폼별 랜딩 변형도 생성합니다.
모든 HTML 파일은 다음을 수행해야 합니다:

../css/foundation.css 참조
../css/shared.css 참조
해당 화면 CSS 파일 참조
공유 ../js/app.js 참조
필요한 경우 해당 화면 JS 파일 참조
모든 주요 구조적 요소에 data-ai-id 사용
맥락에 맞는 현실적인 텍스트 사용 — 절대 로렘 입숨(lorem ipsum) 사용 금지

생성된 모든 앱 화면은 ux-guidelines.md의 네 가지 UX 상태를 포함하거나 명시적으로 처리해야 합니다:

로딩
빈 상태
오류
성공

이러한 상태는 메인 캔버스에 표시되거나 JS 컨트롤을 통해 전환 가능한 모의 상태로 구현될 수 있지만, 제공된 번들에 존재해야 합니다.
기본 표시 상태를 의도적으로 결정합니다:

생성기 화면은 사용자가 명시적으로 미리 로드된/데모 준비가 된 성공 캔버스를 요청하지 않는 한 기본값을 empty로 설정해야 합니다.
결과/검토 화면은 내러티브가 명시적으로 다른 상태를 먼저 요구하지 않는 한 기본값을 success로 설정해야 합니다.
생성기 화면이 사용자가 입력을 제공하거나 로드하기 전에 완료된 출력을 암시하도록 절대 허용하지 마십시오.

생성기, 결과, 대시보드 및 양식 중심 화면에 유틸리티 화면 현실성 규칙을 적용합니다:

화려함보다 신뢰, 가독성 및 정렬에 최적화합니다.
기본 양식, 상태 캔버스, 결과 보드 및 CTA 그룹을 안정적인 일반 흐름 레이아웃으로 유지합니다.
유틸리티 화면의 기본 구조로 겹치거나 절대 위치가 지정된 콘텐츠 베어링 카드를 사용하지 마십시오.
장식적 비대칭성을 부차적으로 유지하여 작업 명확성이나 CTA 검색 가능성을 약화시키지 않도록 합니다.
유틸리티 화면의 히어로 타이포그래피가 연극적인 줄바꿈에 의존하는 대신 대상 뷰포트에서 신뢰할 수 있게 읽히도록 합니다.

출력이 완료되었다고 선언하기 전에 references/output-bundle-rules.md에서 번들 자체 감사를 실행합니다:

2개 이상의 HTML 파일에서 재사용된 모든 선택기를 shared.css로 이동합니다.
어떤 페이지도 올바르게 렌더링하기 위해 형제 페이지 CSS 파일에 의존하지 않는지 확인합니다.
참조된 모든 자산이 존재하는지 확인합니다.
manifest.json이 생성된 파일과 정확히 일치하는지 확인합니다.
선택되지 않은 플랫폼에 대한 파일이 없는지 확인합니다.
반경 계층 구조가 선택된 의미론적 문법을 따르고 중첩된 표면이 동일한 반경 레이어로 평평해지지 않는지 확인합니다.
유틸리티 화면이 대상 뷰포트에서 레이아웃 현실성 감사를 통과하는지 확인합니다.

4단계 — 기초 토큰 고정

첫 번째 승인된 화면을 생성한 후, 정확한 토큰 값을 css/foundation.css로 추출합니다.
색상/타이포그래피/모션뿐만 아니라 번들에 대한 의미론적 반경 문법도 고정합니다.
다음 정확한 형식을 사용합니다:

/* 고정된 기초 토큰 — 수정 금지 */
:root {
  --color-primary: <정확한 값>;
  --color-secondary: <정확한 값>;
  --color-accent: <정확한 값>;
  --color-bg: <정확한 값>;
  --color-surface: <정확한 값>;
  --color-text: <정확한 값>;
  --color-text-muted: <정확한 값>;
  --font-heading: <정확한 글꼴 스택>;
  --font-body: <정확한 글꼴 스택>;
  --space-base: <정확한 값>;
  --radius-1: <정확한 값>;
  --radius-2: <정확한 값>;
  --radius-3: <정확한 값>;
  --radius-4: <정확한 값>;
  --radi

…

anti-ai-design — 36스타일 UI 게이트(AI 크롬 차단)