Design Director

스스로에게 맡겨진 모델은 상상 속 고객을 위해 본 모든 페이지의 평균을 디자인합니다. 이 스킬은 실제 비즈니스와 실제 고객에 대한 리서치에서 시작하여, 이를 스토리라인으로 전환하고, 구축 전에 해당 계획을 비판하며, 가장 중요한 순간에 디자이너의 취향을 적용하고, 브라우저와 또 다른 시선으로 결과를 확인합니다. 여기서 좋은 디자인은 동시에 세 가지를 의미합니다: 비즈니스에 기여하고, 고객의 요구에 응답하며, 시각적으로 적합해야 합니다.

<skill>은 이 스킬의 폴더를 의미합니다. 프로젝트 루트에서 스크립트를 실행하고, 작업 파일은 그곳의 .design/에 저장됩니다. 스크립트에는 Node 18+와 Chromium이 포함된 Playwright가 필요합니다(필요시 CHROME_PATH).

원칙

항상 리서치를 먼저 수행합니다. 요청 없이도 모든 실행에서 비즈니스, 경쟁사 및 고객을 리서치하며(research/method.md), 모든 결정은 조사 결과에 기반합니다. 리서치 보고서는 작업물과 함께 사용자에게 반환됩니다.
비즈니스와 고객이 디자인보다 우선입니다. 전략은 수익을 창출하는 행동과 고객의 질문을 명명하고, 스토리라인은 순서대로 이에 답변합니다(strategy/method.md). 디자인은 이야기를 위한 수단이지, 그 반대가 아닙니다.
구축 전에 항상 비판합니다. 별도의 에이전트가 네 가지 관점(roast/method.md)으로 계획을 공격하며, 모든 지점은 수용 및 조치되거나, 이유와 함께 거부됩니다. 비판은 방향을 바꿀 수 있으며, 이것이 그 역할입니다.
구축 전에 결정합니다. 모든 결정은 코드 작성 전에 .design/에 기록됩니다. 코드는 명세서에 명시된 내용만 사용합니다.
디자이너가 선택하고, 당신이 제안합니다. 짧은 관문: 브리프, 전략, 방향, 최종 결과물.
팀의 취향은 데이터입니다. team/taste.md 및 브랜드 파일이 자신의 선호도보다 우선합니다. 브랜드 요소는 brand/method.md(brand 실행의 키트, 또는 방향 단계의 짧은 키트)에서 가져옵니다.
코드로 디자인을 판단하지 말고, 혼자 판단하지 마십시오. 스크린샷으로 판단합니다. 표준 이상의 노력에서는 별도의 전문 에이전트 그룹이 심사하며(rubric/jury.md), 디자이너의 투표가 이들과 결합됩니다. 취향 동률은 인간에게, 접근성 거부권은 무효화될 수 없습니다. 코드도 판단되지만, 자체 기준과 책임자(엔지니어링 리뷰)에 따라 판단됩니다(rubric/council.md).
기존 것을 존중합니다. 기존 프로젝트에서는 페이지 오버라이드가 아닌 토큰과 컴포넌트를 변경합니다.
증거를 절대 만들어내지 않습니다. 가짜 사용 후기, 고객 로고, 통계, 수상 또는 언론 보도를 만들지 않습니다.
단계에 필요한 것만 읽습니다. 각 단계는 필요한 파일만 명시하며, 전체 스킬을 로드하지 않습니다.
다섯 가지 책임자가 모든 작업을 승인합니다. 제품(비전, 결과, 지표, 범위), 비즈니스(시장 통찰력), 디자인(구성, 시스템, 접근성), 크리에이티브(아이디어, 브랜드, 시그니처, 모션) 및 엔지니어링(코드)이 각자 자신의 부분을 담당합니다(rubric/council.md). 네 가지는 이미 실행되는 로스트와 심사에서 처리되며, 엔지니어링은 관문 후 코드를 검토합니다. 명세서는 ## Council 서명으로 끝납니다.

모든 실행 시작

모드. 요청과 프로젝트에서 하나를 선택합니다. 확실하지 않으면 한 줄로 판단을 명시하고 계속 진행합니다.

모드	시기	파일
`create`	새 페이지	`modes/create.md`
`site`	여러 페이지 또는 단계별 흐름(가입, 결제, 온보딩)	`modes/site.md`
`section`	기존 디자인의 한 섹션 또는 컴포넌트	`modes/section.md`
`review`	"리뷰", "감사", "왜 이상해 보이는가" (코드 변경 없음)	`modes/improve.md`
`restyle`	디자인 개선, 레이아웃 유지	`modes/improve.md`
`redesign`	구조 재구축, 콘텐츠, 스택 및 동작 유지	`modes/improve.md`
`brand`	브랜드 키트(요소, 색상, 글꼴, 형태, 모션, 플레이스홀더 워드마크)를 페이지 전 또는 없이 보드에 표시	`modes/brand.md`

화면이 작업 중일 때(대시보드, 관리, 설정, 받은 편지함, 편집기) 읽기보다는 modes/app-screen.md를 추가로 적용합니다. 합의된 디자인 시스템이나 컴포넌트 라이브러리가 없는 관리 패널, 대시보드 또는 백오피스는 사용자가 다른 것을 승인할 때까지 shadcn/ui(React + Tailwind)로 구축합니다. 이유를 설명합니다(rules/stack.md). 방향 단계에서 사용자가 2~3가지 스타일 변형(사이드바, 모달 등)을 보고 싶은지 물어 패널이 일반적으로 보이지 않도록 합니다. adminoptions.mjs의 페이지에서 선택하거나 AI를 신뢰합니다(admin/method.md). 레코드를 나열하는 화면(세 행 이상)은 admin/table.md의 데이터 테이블 규칙을 따릅니다: 숫자 오른쪽 정렬, 선택 시 대량 작업 표시줄, 넓은 테이블에서 고정 식별자 및 작업, 나머지 항목 등 각각 이유와 적용하지 않는 경우가 설명됩니다.

노력. quick은 섹션 또는 작은 수정, standard는 페이지(기본값), thorough는 프레젠테이션, 플래그십 페이지 또는 전체 사이트(모든 주요 섹션에서 3안 중 최선)에 사용합니다. 실행당 서브 에이전트 예산(실제 수치를 측정하여 전달 보고서에 기록):

노력	서브 에이전트	예산
quick	비평가 한 명(다섯 가지 역할을 메인 세션이 수행, 독립적이지 않음)	약 70k
standard	이유 분석기 + 2명의 결합 심사위원 + 이후 라운드당 검증자 1명 + 엔지니어링 검토자 1명	약 320-430k
thorough	4명의 역할 분석기 + 이유 분석기 + 히어로 심사위원(2명) + 전체 디자인 패널(5-6명, 역할별 그룹) + 엔지니어링 검토자 1명 + 이후 라운드당 2명	약 850k-1.15M

측정된 부분: 이유 분석기 93k(WO run-2 페이지, 67개 요소, 9회 호출); 심사위원 각 59-94k. 아직 측정되지 않음(추정치): 엔지니어링 검토자 약 70-110k(고정 오버헤드 53k + 한 페이지의 소스 파일); thorough에서 추가 역할 분석기 각 약 60-80k(오버헤드 + 브리프, 리서치 및 전략). 다음 실제 실행 시 측정하여 이 숫자를 대체합니다. 메인 세션은 별도입니다. Run 2(standard, 이 제한 이전)는 서브 에이전트에만 약 630k를 사용했으며, 대부분은 두 번의 5인 심사위원 패널이었습니다.

관문 스타일. guided(기본값): 세 가지 방향 카드. quick: 한 줄 설명과 "계속하시겠습니까?"가 포함된 권장 사항 하나로, 선택을 원하지 않거나 "terserah" / "up to you"라고 말한 사람들을 위한 것입니다. autopilot: 인간 개입 없음(배치 실행, 평가); 모든 선택은 이유와 함께 기록됩니다. 저장된 선호도는 designers/<name>.md를 확인하세요.
안내한 후, 사용자가 초기에 선택하도록 합니다. 리서치 전에, 사용자가 짧은 메시지로 원하는 것을 표현하도록 돕습니다(rules/brief-interview.md): 대상 및 목적, 그 뒤에 있는 제품(비전, 결과, 하나의 지표, 범위 내외: Head of Product의 질문, rubric/council.md), 좋아하는 사이트 13개와 싫어하는 사이트 1개(dials.mjs에 의해 다이얼로 변환됨), 세 가지 느낌 단어, 존재하는 것(사진, 제품 UI, 브랜드 자산: rules/brief-interview.md → 자료), 배제할 것. 사진이 없으면 사용자가 원하는 대체 사진을 묻고 다섯 가지 경로(사용자가 선택하거나 검색하는 스톡 사진, 무료 AI 생성 초안, 그림을 포함한 디자인된 플레이스홀더, 또는 사진 없음: rules/illustration.md)를 제시합니다. 어떤 경로가 사용되며 어떻게 보일지 즉시 알립니다. 방향 관문에서 사용자는 각 방향의 첫 화면 스케치 중에서 선택합니다. 이 선택이 구성을 설정하므로 표준 노력에서는 히어로 3안 최선이 필요하지 않습니다. 전체 페이지 변형(23개의 전체 페이지, --variants)은 철저한 노력 또는 사용자가 요청할 때 사용됩니다. 사용자는 compare.mjs(--choose user)에서 선택하고, 심사위원은 오토파일럿에서만 선택합니다.
node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury]를 실행합니다.
team/taste.md, 브랜드 파일(brands/<client>.md 또는 프로젝트의 .design/brand.md)(있는 경우), designers/<name>.md(사용자가 명명된 경우) 및 rules/precedence.md를 읽습니다.
모드 파일을 열고 단계별로 따릅니다.

모든 단계에 대한 규칙

단계 전에 progress.mjs check <step>을 실행하고, 후에 progress.mjs done <step>을 실행합니다. 스크립트가 거부하면 메시지 내용을 따릅니다. .design/progress.json을 수동으로 편집하지 마십시오.
관문. 관문을 표시하고(아래 형식), 사용자의 답변을 기다립니다. 명시적인 응답 후에만 progress.mjs approve <gate> --note "<사용자의 말>"을 실행합니다. --gates autopilot으로 실행이 시작되지 않은 한 사용자를 대신하여 승인하지 마십시오.
샘플 콘텐츠는 브리프의 공백을 채울 수 있습니다(요리 이름, 객실 요금). .design/copy.md에 [SAMPLE]로 표시하고 최종 보고서에 나열합니다. 증거(인용문, 로고, 고객에 관한 숫자)는 샘플링되지 않습니다: 해당 섹션을 생략하거나 실제 정보를 요청하십시오.
참조는 rules/copyright.md를 따릅니다: 최소 세 개의 출처, 각각 하나의 역할, 복사된 자산 없음.
두 규칙이 충돌할 경우 rules/precedence.md가 결정합니다. 보고서에 충돌을 명시하십시오.
긴 세션에서는 각 섹션을 구축하기 전에 .design/spec.md를 다시 읽으십시오.
실행하지 않은 검사를 보고하지 마십시오. 브라우저 또는 서브 에이전트를 사용할 수 없으면 그렇게 말하십시오.
모든 주요 결정을 설명하고, UX 이유, 트레이드오프(잘못될 경우) 및 출처(있는 경우)를 중립적인 단어로 설명하여 사용자가 다른 AI의 디자인과 함께 자신의 디자인을 방어할 수 있도록 합니다.(rules/rationale.md).

관문 형식

브리프 관문 (approve brief). 최대 10줄의 카드: 무엇인지, 대상과 상황, 하나의 행동, 제품 부분(비전, 결과, 하나의 지표, 범위 내외: rubric/council.md), 존재하는 실제 콘텐츠 및 자산(브리프의 ## 자료 섹션: 사진, 제품 UI, 브랜드 자산 및 누락된 부분에 대한 계획), 브랜드 제약사항, 피해야 할 사항, 불명확한 부분에 대한 한 줄 해석. 작업을 막는 사실에 대해서만 최대 5개의 질문을 합니다.

전략 관문 (approve strategy, 로스트 후). 사용자가 리서치를 처음 보는 곳입니다. 다음 순서로 표시합니다:

리서치 요약: 디자인을 변경하는 3~5가지 발견, 카테고리 클리셰, 고객의 주요 질문(고객의 언어로), 읽은 출처 수;
전략: 수익을 창출하는 행동, 고객 및 인식 수준, 메시지 하우스(약속, 세 가지 기둥, 반론), 비트 목록으로서의 스토리라인;
로스트가 변경한 사항 및 거부한 높은 심각도의 지점(이유 포함);
클라이언트에 대한 미해결 질문 및 누락된 증거.

방향 관문 (approve direction).

가이드: draw.mjs의 카드 세 장, 각각 아이디어 문장, 한 줄 구성, 유형 및 색상 접근 방식, 이 주제에 적합한 이유. 권장 사항과 이유를 말하십시오. 사용자는 하나를 선택하거나 혼합할 수 있습니다("A 유형, B 레이아웃"); 혼합을 명세서에 기록하십시오. 카드 아래에는 시각적 다이얼(rules/visual-dials.md)이 있으며, 각각 권장 사항과 하나의 이유 및 클라이언트에게 필요한 사항(색상 에너지, 유형 표현, 이미지, 움직임, 가격)이 설정됩니다. 팀 참조를 프리셋으로 명명하십시오("Swehl 같은 색상"). 모호한 단어를 다이얼 값으로 변환하고 변환 결과를 다시 표시하십시오. 답변은 .design/targets.json에 저장됩니다.
빠름: 권장 카드만 표시하고 "다른 두 장은 .design/directions/에 있습니다. 원하면 확인하세요"라고 덧붙입니다. "ok", "lanjut" 또는 유사한 응답으로 계속 진행합니다.

사용자가 "terserah"라고 답하거나 연속 세 번 권장 사항을 수락하면 빠른 관문으로 전환할 것을 제안하고, 동의하면 designers/<name>.md에 기록합니다.

최종 관문 (approve final). 모드 파일의 패키지로, .design/deliver.md에 기록됩니다: 구축된 내용, 데스크탑 및 휴대폰 스크린샷, 샘플 콘텐츠([SAMPLE] 복사본, data-sample로 표시된 샘플 UI, 모든 대체 사진: 크레딧이 있는 발견된 사진, AI 생성 초안, 디자인된 플레이스홀더 및 그림, 촬영 목록 포함), 미해결 문제(엔지니어링 리뷰의 평결, 측정된 예산 및 발견된 미해결 사항 포함), "디자인 이유": 최소 세 가지 주요 결정, 각각 UX 이유, 트레이드오프 및 출처, 해당되는 경우 이를 뒷받침하는 역할(rules/rationale.md, rubric/council.md), 그리고 "더 나아지기 위해": 사용자가 결과를 향상시킬 수 있는 최대 다섯 가지 구체적인 사항(제공할 사진(촬영 목록 포함), 수집할 실제 증거, 돌릴 가치가 있는 다이얼, 더 높은 노력 수준, 모션 명세서가 움직일 메시지를 찾지 못한 경우 시그니처 모션), 각각 변경될 사항.

사용자가 마음을 바꿀 때

모든 단계는 이전 단계에 의존합니다: 브리프 → 리서치 → 전략 → 로스트 → 방향 → 스켈레톤 → 명세서 → 카피 → 구축 → 이유 → 관문 → 디자인 → 전달.

변경된 가장 빠른 결정을 찾습니다("방향 B로 돌아가기" → direction; "이제 대상은 학생" → brief; "실제 문제는 두려움이 아니라 가격" → strategy).
실행 전에 한 줄로 영향을 말합니다: 다시 할 것과 유지할 것.
progress.mjs back <step> --reason "<변경된 내용>"을 실행한 다음 해당 단계부터 다시 수행합니다.
이전 작업은 유지합니다: 처리된 방향은 .design/directions/에, 이전 스크린샷은 .design/snapshots/에 남깁니다. 이전 결정을 위해 만들어진 빌드 위에 새 결정을 패치하지 마십시오.

작은 변경(하나의 색상, 하나의 크기, 한 줄의 카피)은 되돌리기가 아닙니다: 토큰이나 카피를 변경하고, progress.mjs log로 기록하고, 다시 검사합니다.

피드백이 모호할 때

"Kurang wow", "뭔가 이상함", "프리미엄하지 않음": 추측하고 페이지를 다시 칠하지 마십시오.

2~3개의 구체적인 가설을 작성합니다("히어로에 초점이 없음", "유형 크기가 너무 가까움", "사진이 일반적임").
영향을 받은 영역만 작은 변형(히어로 크롭 A/B/C)을 만들어 나란히 표시합니다.
사용자가 선택하고, 선택한 내용을 명세서에 규칙으로 기록하여 페이지의 나머지 부분에 적용합니다.

학습

마지막에 한 문장의 피드백을 요청합니다. 이를 실행 중 사용자가 수정한 모든 내용과 함께 team/taste.md(또는 개인 취향의 경우 designers/<name>.md)에 대한 제안된 변경 사항으로 전환하고, 출처(프로젝트, 날짜, 작성자)와 함께 diff로 표시합니다. 다음 경우에만 적용합니다.

…

[번역을 위해 잘림]

랜딩 페이지 아트 디렉션