목적

목적

디자인 시스템 일관성을 가드하고 CLAUDE.project.md의 ## 사용 가능한 컴포넌트 인덱스를 자동 동기화한다. 한 화면에서 시작한 변경이 전 화면을 덮치는 사고를 막는 것이 1순위.

발동 조건

발동

• 디자인 토큰 변경을 의미하는 자연어
  • "이 버튼 좀 더 둥글게", "더 크게", "더 작게"
  • "색 좀 부드럽게", "다른 색으로", "어두운 톤으로"
  • "여백 좁혀줘", "간격 줄여줘"
  • "글씨 키워줘", "본문 폰트 바꿔줘"
• 컴포넌트 변경 감지
  • 신규 컴포넌트 파일 생성 (components/ 하위)
  • 기존 컴포넌트의 props·variant 추가/변경

발동 X

• 단순 문구·레이블 변경 ("이 글자 '확인'으로 바꿔줘")
• 가짜 데이터(mock/) 변경
• 자산(asset/) 추가만 (컴포넌트 변경 없이)
• 미학 결정만(토큰 X) — aesthetic-guard 우선

트리거 충돌 처리 (참고)

토큰 변경 의도("이 색 좀 부드럽게", "둥글기 키워줘") → 이 Skill / 미학 결정·새 컴포넌트 구도·이니셜 박스 회피 → aesthetic-guard / 디자이너 부정 신호 누적·전역 승격 → feedback-curator. 전체 표는 plugin/SCHEMA.md §5.

처리 흐름

1. 변경 분류 — 부분 수정 vs 시스템 변경

변경 대상 파일 위치로 1차 분류:

변경 위치	분류
단일 컴포넌트 파일 내 인라인 클래스/스타일	부분 수정
토큰 정의 파일 (tailwind.config.*, app/globals.css의 CSS variables, theme 파일)	시스템 변경
디자인 시스템 베이스 컴포넌트 (components/ui/*, shadcn 베이스)	시스템 변경 후보 — 사용자 의도 확인 필요

확인 보조: Grep/Glob으로 해당 토큰 또는 컴포넌트가 다른 곳에서도 쓰이는지 사용처 카운트. 2곳 이상이면 시스템 변경으로 가정하고 묻는다.

2. 시스템 변경이면 명시적 동의

AskUserQuestion으로 묻는다. "왜 묻는지" 1줄 + "잘 모르겠어요" 옵션 필수.

질문 패턴:

이 변경은 전체 시스템에 영향을 줄 수 있어요. 같은 색이 다른 화면 N곳에도 쓰이고 있어서요.

• 이 화면만 바꿀게요 (다른 화면은 그대로)
• 전체 시스템에 적용할게요 (이 색 쓰는 다른 화면도 같이 바뀜)
• 잘 모르겠어요 → 기본값: 이 화면만

선택 결과대로 변경 위치 결정:

• 이 화면만 → 해당 컴포넌트 파일 내 인라인 처리 (토큰 정의 파일 X)
• 전체 시스템 → 토큰 정의 파일 수정
• 사용자가 한 사이클 3회 상한(결정 피로 최소화) 넘으면 기본값(부분)으로 자동 진행 + 사후 안내

3. 컴포넌트 인덱스 자동 갱신

신규/변경 컴포넌트 감지 시 CLAUDE.project.md의 ## 사용 가능한 컴포넌트 섹션을 동기화.

라인 형식 — 이름 · 경로 · 핵심 props · variant 한 줄씩:

- `Button` · `components/ui/Button.tsx` · `variant: primary|secondary|ghost`, `size: sm|md|lg` · 기본 액션 버튼

처리 순서:

1. Read CLAUDE.project.md
2. ## 사용 가능한 컴포넌트 섹션 위치 찾기
3. 변경된 컴포넌트 라인 갱신/추가 (Edit)
4. 섹션 부재 시 → 헤더만 만들고 현재 컴포넌트 한 줄로 시작 (첫 일괄 생성은 import-existing 책임)
5. 회전 검사 — append/edit 직후 컴포넌트 표 본문이 디자이너가 한눈에 훑을 만함을 넘었으면 가장 오래된 행들(또는 덜 자주 쓰이는 베이스 외 항목)을 .claude/slot-archive/components.md로 최신 순 append하고 슬롯 표에선 그 행 제거. archive 파일·디렉토리 부재 시 함께 생성. archive는 ./CLAUDE.md @import에 미추가(자동 로드 X — 이슈 #8 해소의 핵심). 첫 archive 생성 시 디자이너에게 1회 안내("자주 안 쓰는 컴포넌트 일부는 .claude/slot-archive/components.md로 옮겨두었어요 — 보고 싶을 때 이전 컴포넌트 목록 보여줘 한 마디면 돼요"), 이후 침묵. 컴포넌트 인덱스는 조회성이라 last-work/share-history보다 더 긴 분량까지 한눈 가독성 유지 가능 — 분량 기준은 갱신 시점 자율(고정 N 박지 X). 정본: plugin/SCHEMA.md §2.3.

3.1 페이지 인덱스 후속 갱신 (pages 슬롯)

신규 페이지 감지 시 CLAUDE.project.md의 ## 사용 가능한 페이지 섹션을 동기화 — import-existing §4.5가 초기 일괄 생성한 결을 후속에서 같은 형식·갱신 절차로 이어받는다. 신규 페이지 감지 신호:

• Glob이 디자이너가 첫 화면 시점에 박은 라우트 파일 추가를 보여주거나
• 사용자 발화에 "새 화면", "프로필 페이지", "랜딩" 등 라우트 생성 의도가 보이거나
• aesthetic-guard/new-service가 페이지 파일을 새로 만든 직후

처리 절차는 §3 컴포넌트와 동일 패턴 (Read → 섹션 위치 → 라인 추가/갱신 → 회전 검사). 라인 형식은 import-existing §4.5.2 그대로 (이름 · 파일 경로 · 라우트 · 역할 1줄). 회전 archive는 .claude/slot-archive/pages.md.

Subagent 위임

없음. 변경 분류·맥락 판단·동의 흐름은 메인 모델에서 직접 한다 (model: inherit).

응답 톤

• 한국어, 비유 보조, 응답 끝 다음 행동 1개 제안 (designer-persona 글로벌 원칙)
• 영향 범위는 1줄로 정량화: "이 색은 다른 3곳에서도 쓰여요"
• 동의 없는 광범위 변경 절대 X (명시 동의)

자가 점검

응답 직전 체크:

• 변경 분류 — 부분 수정(이 화면만) vs 시스템 변경(전 화면 영향) 중 하나
• 시스템 변경 분기는 명시 동의 받기
• 영향 범위 1줄 정량화 ("이 색은 다른 N곳에서도 쓰여요")
• 컴포넌트 인덱스(CLAUDE.project.md §components) 갱신 — 신규/변경 감지 시
• 슬롯 분량 디자이너 한눈에 훑을 만함 초과 시 archive 회전 (정본: SCHEMA.md §2.3)
• 응답 끝 다음 행동 1개 + 트리거 자연어 1개

의존

• 다른 Skill: designer-persona (톤), import-existing (컴포넌트 인덱스 첫 생성), error-translator (변경 적용 실패 시)
• 외부 도구: AskUserQuestion, Read, Edit, Grep/Glob (컴포넌트·토큰 사용처 탐색)