| name | design-diversity |
| description | Claude가 산출하는 PPT·웹사이트 디자인의 천편일률 문제를 해결하는 '디자인 팩 카탈로그' 제작 오케스트레이터. 공개 디자인 시스템·비주얼 스타일을 수집·증류해, Claude Code에 복붙하면 그 스타일이 재현되는 디자인 팩 (prompt.md + tokens.json + preview.png + meta.yaml)을 만들고, baseline 대조로 다양성을 검증한 뒤 GitHub 공개 레포 + 카탈로그 웹사이트로 발행한다. 7인 에이전트 팀(소싱·스키마·PPT집필·웹집필·렌더·다양성QA·발행)을 파이프라인으로 조율한다. 트리거 — "디자인 다양성", "디자인 팩", "디자인 팩 카탈로그", "디자인 시스템 카탈로그", "PPT 디자인 다양화", "웹 디자인 팩", "프롬프트형 디자인 시스템", "Claude 디자인 천편일률", "디자인 팩 만들어줘". 후속 작업 — "팩 추가", "PPT 팩 N개 더", "웹 팩 추가", "특정 팩만 다시", "다양성 검증 다시", "팩 재집필", "스키마 변경", "카탈로그 사이트 재배포", "레포 갱신", "재실행"도 모두 이 스킬로 처리한다. 단순 PPT 1건 제작은 korean-premium-deck, 단순 웹사이트 1건은 frontend-design을 사용한다. |
Design Diversity — 디자인 팩 카탈로그 오케스트레이터
공개 디자인 시스템을 수집·증류해 Claude Code 복붙용 '디자인 팩' 카탈로그를 만들고, 다양성을 검증한 뒤 GitHub + 웹사이트로 발행하는 7인 에이전트 팀을 조율한다.
핵심 산출물 (확정 규격)
각 디자인 팩 = design-packs/{slug}/ 안의 4개 파일:
prompt.md — Claude Code에 복붙하는 자기완결적 디자인 지시문 (SSOT 사용처)tokens.json — 머신리더블 디자인 토큰 (color/type/spacing/motion)preview.png — 실제 샘플 렌더meta.yaml — 카테고리·스타일 계열·출처·라이선스
규격 정의는 design-pack-schema 스킬이 SSOT다. 1차 출범 규모 = PPT 20 + 웹 20 = 40팩.
실행 모드
에이전트 팀 (단일 팀 7인, 작업 의존성으로 파이프라인 표현). 팀원은 SendMessage로 직접 조율, 산출물은 _workspace/ 및 design-packs/ 파일로 공유, 진행은 TaskCreate/TaskUpdate로 추적. 모든 Agent 호출은 model: "opus".
| 에이전트 | 역할 | 주 스킬 |
|---|
| design-scout | 공개 디자인 시스템·스타일 후보 소싱 | design-sourcing |
| pack-architect | 스키마 SSOT·카탈로그 인덱스·다양성 게이트 | design-pack-schema |
| ppt-pack-curator | PPT 트랙 팩 집필 | ppt-design-idioms, design-pack-schema |
| web-pack-curator | 웹 트랙 팩 집필 | web-design-idioms, design-pack-schema |
| sample-renderer | 팩 적용 샘플 + baseline 렌더 | sample-rendering |
| diversity-qa | baseline 시각 대조·다양성 점수·반려 | diversity-scoring |
| catalog-publisher | GitHub 레포 + 카탈로그 사이트 발행 | catalog-publishing |
Phase 0: 컨텍스트 확인
작업 시작 전 _workspace/와 catalog.json 존재를 확인해 실행 모드를 정한다.
- 초기 실행 —
catalog.json 없음 → 전체 파이프라인 (Phase 1~5).
- 후속 — 팩 추가 —
catalog.json 있음 + "팩 N개 추가" → Phase 1(빈 축만 소싱) → 2~5를 신규 슬러그에만 적용. 기존 팩 보존.
- 후속 — 부분 재실행 — "특정 팩만 다시", "다양성 검증 다시" → 해당 슬러그·해당 Phase만 재호출. 시작 전 기존
_workspace/를 _workspace_prev/로 백업.
- 후속 — 스키마/사이트만 — "스키마 변경"→ pack-architect 단독 + 마이그레이션 보고. "사이트 재배포"→ catalog-publisher 단독.
부분 재실행 시 어느 Phase부터 도는지 사용자에게 1줄로 알리고 진행한다.
Phase 1: 소싱 (design-scout)
TeamCreate로 7인 팀을 만든 뒤, design-scout에 PPT·웹 두 트랙을 할당한다.
- 출력:
_workspace/01_scout_candidates-ppt.json, _workspace/01_scout_candidates-web.json.
- 후보는 목표치(트랙당 20)보다 ~20% 많게. 후보끼리 시각적으로 충분히 구별돼야 한다.
Phase 2: 스키마 락 + 팩 집필 (pack-architect → 두 curator 병렬)
- pack-architect가
design-pack-schema를 확인·잠그고, 후보를 다양성 매트릭스로 솎아 _workspace/02_architect_selected.json + 초기 catalog.json 생성.
- ppt-pack-curator와 web-pack-curator가 병렬로 각 트랙 팩을 집필 →
design-packs/{slug}/prompt.md + tokens.json + meta.yaml.
- pack-architect가 산출물 포맷·라이선스·중복을 검수. 위반 슬러그는 반려·재집필(최대 2회).
대규모(40팩)이므로 트랙별로 5팩씩 배치 집필을 권장 — 배치마다 Phase 3 검증을 이어 돌려 피드백을 빨리 받는다.
Phase 3: 렌더 + 다양성 검증 루프 (sample-renderer → diversity-qa)
각 팩(또는 배치)에 대해:
- sample-renderer가 동일 더미 콘텐츠로 팩 적용 샘플 + 트랙 baseline을 렌더 →
design-packs/{slug}/preview.png.
- diversity-qa가 baseline과 시각 대조 →
_workspace/04_qa_scorecard.json.
reject 판정 → 사유의 축을 담은 채로 담당 curator에 재집필 요청 → 재렌더 → 재검증 (팩당 최대 2회).- 2회 후에도 미달이면
escalate — 발행하되 사이트에서 draft 배지.
전체 종료 시 diversity-qa가 팩 간 유사도 매트릭스(_workspace/04_qa_diversity-matrix.md)를 작성, 쌍둥이 팩은 pack-architect가 통합·재정의.
Phase 4: 발행 (catalog-publisher)
- 통과 팩 +
catalog.json으로 GitHub 레포 구조화: README.md, CONTRIBUTING.md, LICENSE, design-packs/.
site/에 Next.js 15 카탈로그 웹사이트 빌드 — 갤러리·필터·prompt.md 원클릭 복사.- 자체 QA(빌드·카드 렌더·복사 동작·모바일) 후 Vercel preview 배포.
- production 배포는 사용자 명시 승인 후. preview URL을 먼저 보고한다.
Phase 5: 피드백 (Phase 7 진화)
발행 후 사용자에게 개선점·팀 구성 피드백 기회를 제공한다. 피드백 유형별 반영 대상은 harness:harness Phase 7-2 표를 따르고, 변경은 프로젝트 CLAUDE.md 변경 이력에 기록한다.
데이터 전달 프로토콜
- 태스크 기반(
TaskCreate) — 파이프라인 의존성·진행 추적.
- 파일 기반 — 중간 산출물은
_workspace/{phase}_{agent}_{artifact}, 최종 팩은 design-packs/{slug}/, 인덱스는 루트 catalog.json. _workspace/는 감사용으로 보존.
- 메시지 기반(
SendMessage) — 반려 사유·재소싱 요청 등 실시간 조율.
에러 핸들링
- 에이전트 실패 → 1회 재시도. 재실패 시 해당 산출물 없이 진행하고 최종 보고에 누락을 명시.
- 후보 부족 → design-scout 재소싱 1회, 그래도 부족하면 가능한 수로 진행 + 빈 축 보고.
- 팩 2회 반려 후 미달 →
escalate(삭제 금지, draft로 발행).
- 라이선스 모호 → 팩을 드롭하지 말고
license: unclear로 표시, pack-architect가 1차 출처 확인.
- 렌더 실패 →
render_failed 표시 후 사람 판단에 위임, 발행에서 자동 제외하지 않음.
테스트 시나리오
정상 흐름: "디자인 팩 카탈로그 만들어줘" → Phase 0(초기) → 소싱 40+α 후보 → 스키마 락 + 40팩 병렬 집필 → 렌더·검증 루프(반려분 재집필) → 레포 + 사이트 발행 → preview URL 보고 → production 승인 대기.
후속 흐름: "PPT 레트로 팩 5개 더 추가해줘" → Phase 0(팩 추가) → scout가 레트로 축만 소싱 → ppt-curator만 5팩 집필 → 렌더·검증 → catalog.json·사이트에 5카드 증분 반영.
에러 흐름: diversity-qa가 어떤 팩을 2회 반려 → escalate 처리 → 사이트에 draft 배지로 노출 → 최종 보고에 escalate 목록 명시.
