Claude Code 스킬로 Figma-to-Code 퍼블리싱 파이프라인 만들기

┌─────────────────────────────────────────────┐
│  오케스트레이터 (사용자가 직접 호출)              │
│  figma-to-code-tailwind, publish-qa 등        │
│  → 다른 스킬을 순차 호출, /tmp 캐싱 관리         │
├─────────────────────────────────────────────┤
│  실행 스킬 (오케스트레이터가 호출)               │
│  figma-fetch, figma-publish-tailwind 등       │
│  → 실제 작업 수행 (API 호출, 코드 생성)          │
├─────────────────────────────────────────────┤
│  초기 세팅 스킬 (프로젝트 시작 시 1회)           │
│  token-to-tailwind, token-to-chakra           │
│  → 토큰 변환, 독립 실행                        │
└─────────────────────────────────────────────┘

오케스트레이터 (메인 컨텍스트)
├── PHASE 0: figma-fetch → /tmp/figma-spec-cache.md 저장
├── PHASE 1: figma-icons, figma-images
├── PHASE 1.5: 섹션 분할 → /tmp/figma-spec-section-*.md
└── PHASE 2: 섹션별 서브에이전트 spawn (독립 컨텍스트)
    ├── Agent 1: Header 섹션 (자기 스펙만 로드)
    ├── Agent 2: Content 섹션
    └── Agent 3: Footer 섹션

[공유 컨텍스트 ~15%] + [섹션 스펙 ~15%] + [스킬 규칙 ~20%] + [구현 ~50%]
= 충분한 여유

# PHASE 0에서 저장
/tmp/figma-spec-cache.md        # 전체 디자인 스펙
 
# PHASE 1.5에서 분할
/tmp/figma-spec-shared.md       # 공유 컨텍스트 (토큰, 자산, 구조)
/tmp/figma-spec-section-1-header.md
/tmp/figma-spec-section-2-content.md
/tmp/figma-spec-section-3-footer.md
 
# publish-qa에서 저장
/tmp/publish-qa-step1.md        # 디자인 QA 결과
/tmp/publish-qa-step2.md        # 리팩토링 결과
/tmp/publish-qa-step3.md        # 엣지케이스 결과

# PRE: 작업 시작 전
rm -f /tmp/figma-spec-cache.md /tmp/figma-spec-section-*.md
 
# POST: 작업 완료 후
rm -f /tmp/figma-spec-cache.md /tmp/figma-spec-section-*.md

publish-qa (오케스트레이터)
├── PRE: /tmp/publish-qa-step*.md 캐시 정리
├── STEP 1: 서브에이전트 → /design-qa       → /tmp/publish-qa-step1.md
├── STEP 2: 서브에이전트 → /publish-refactor → /tmp/publish-qa-step2.md
├── STEP 3: 서브에이전트 → /edge-case-test   → /tmp/publish-qa-step3.md (조건부)
├── STEP 4: 메인 → pnpm build (가벼움)
└── POST: 캐시 정리 + 최종 보고

PRE:     /tmp 캐시 정리
PHASE 0: /figma-fetch → 노드 분석 + 스펙 → /tmp/figma-spec-cache.md
PHASE 1: /figma-icons, /figma-images → 자산 처리 (조건부)
PHASE 1.5: 섹션 분할 판단
PHASE 2: 서브에이전트 → /figma-publish-tailwind
PHASE 3: 통합 검증 (페이지 조립 + type-check)
POST:    캐시 정리

단일 서브에이전트에 전체 위임:
  STEP 0: URL 파싱 + 프로젝트 구조 확인
  STEP 1: 브레이크포인트별 get_design_context 개별 조회
  STEP 2: 섹션별 브레이크포인트 차이 비교 테이블
  STEP 3: 토큰 역색인 빌드
  STEP 4: 자산 처리
  STEP 5: 반응형 구현 설계서
  STEP 6: Tailwind 반응형 코드 구현 (md:, lg: 접두사)
  STEP 7: pnpm type-check

/responsive-publish-tailwind <설명> URL([base, md|null, lg|null]) --page src/app/path

❌ "grey.6 정도 되겠지" → 실제는 grey.7
❌ "pre-body-3이겠지" → 실제는 pre-heading-5 (16px/700은 heading)
❌ "border-grey-3이겠지" → 실제는 border.basic.2 (같은 hex라도 컨텍스트가 다름)

// 1. VariableID → 시맨틱 토큰 (색상)
semanticById["VariableID:4021:1253"] = { token: "border-basic-2", value: "#cfd2d5" }
 
// 2. VariableID → 원시 색상
rawById["VariableID:100:50"] = { name: "grey-50", value: "#f9f9fa" }
 
// 3. fontSize/fontWeight → textStyle 토큰
textStyleIndex["14/600"] = "pre-body-5"
textStyleIndex["24/700"] = "pre-heading-2"

token.json → CSS Variables (globals.css) + tailwind.config.ts 확장

/* globals.css */
:root {
  --color-grey-50: #f9f9fa;
  --color-accent-yellow1: #fef2e3;
}
.dark {
  --color-accent-yellow1: #322304;
}

// tailwind.config.ts
colors: {
  grey: { 50: 'var(--color-grey-50)' },
  accent: { yellow1: 'var(--color-accent-yellow1)' },
}

token.json → Chakra theme 객체 (colors, semanticTokens, textStyles)