figma-apply

/figma-apply

디자이너가 피그마에서 수정한 내용을 현재 design/* 브랜치에 반영하기 위한 커맨드입니다. 브랜치 생성·체크아웃은 /figma-start가 담당하므로, 이 커맨드는 항상 design/* 브랜치 위에서만 동작합니다.

디자이너 응대 원칙

이 커맨드의 사용자는 디자이너다. 개발 용어를 모른다는 전제로 응대한다.

• 기술적 판단을 디자이너에게 묻지 않는다 — 파일 삭제·에셋 생성·코드 수정·빌드 등은 자율적으로 안전하게 결정한다. 디자이너에게 물어도 되는 건 디자인 의도뿐이다 (예: "이 부분 색 바꾸신 게 맞나요?").
• 디자이너에게 보이는 모든 메시지는 비개발자 언어로 쓴다 — 파일명·drawable·reference·gradle 태스크명 등 기술 용어 금지.

사용 예시

/figma-apply https://figma.com/design/xxx?node-id=1-2

실행 순서

1. 인자 파싱 및 컨텍스트 확인

• $ARGUMENTS에서 피그마 URL 추출
• 작업 대상 프로젝트 결정 — 현재 디렉터리가 design/* 브랜치의 git 레포면 그대로 쓴다. 아니면 ~/.design-to-ui/current-project(/figma-start가 기록)를 읽어 그 경로에서 진행한다. 이후 모든 명령은 그 경로 기준(cd/git -C). 디자이너에게 폴더 이동이나 재실행을 요구하지 않는다.
• 그 경로의 브랜치도 design/로 시작하지 않고, 기록도 없으면 에러: "/figma-start <dev_pr_link> 를 먼저 실행해주세요."

2. 피그마 변경 적용

• figma-diff-apply 스킬에 위임 — 변경점 식별 및 최소 코드 수정 수행

3. 빌드 검증

코드 편집은 figma-diff-apply(Section 2)의 책임이고, 이 단계는 빌드 게이트만 담당한다 — 이 커맨드는 직접 코드를 수정하지 않는다.

• 코드 수정 완료 후 전체 빌드 실행 — 리소스 머지·패키징까지 포함(Android Gradle이면 assemble{Variant}Debug 수준, 프로젝트 표준 debug 빌드). 출력은 tail 등으로 에러만 추려 읽어 컨텍스트를 가볍게 유지.
  • ⚠️ compileKotlin/compile* 같은 부분 컴파일 검사로 대체 금지 — 신규 에셋·drawable 누락, 리소스 병합 오류 등은 전체 빌드에서만 드러난다.
• 빌드 성공 → 4번 "빌드 성공 시"로 분기.
• 빌드 실패 → 빌드 에러 출력을 figma-diff-apply 스킬에 다시 위임해 수정한다(에러 분석·코드 편집은 스킬이 담당 — 스킬은 이미 들고 있는 design_context·편집 원칙을 그대로 재사용). 스킬이 수정을 반환하면 재빌드. 최대 3회 반복.
  • 3회 내 성공 → 4번 "빌드 성공 시"
  • 3회 모두 실패(또는 스킬이 모호로 수정 불가 보고) → 4번 "빌드 실패 시"

4. 결과 처리

빌드 성공/실패 한 갈림길에서 커밋 규약·안내 메시지가 함께 분기된다.

빌드 성공 시

• 커밋 제목(첫 줄)은 정확히 이 형식으로 쓴다(다른 표현으로 대체 금지): design: figma-apply {한 줄 변경 요약}
  • {한 줄 변경 요약}은 디자이너 프롬프트에서 뽑은 사람이 읽을 수 있는 한 줄 변경 내용(예: 오늘의 뉴스 타이틀 컬러 캘린더 위젯과 통일).
• 커밋 본문 = 디자이너가 입력한 프롬프트 전문 + 빈 줄 + figma-diff-apply가 출력한 변경 테이블 (+ "영향 범위"가 있으면 함께) — 2개+ Fragment에 영향 가는 변경이 있으면 그 목록이 커밋 본문에 남아 개발자가 git log로 확인 (피그마 링크는 프롬프트 안에 있으므로 자연스럽게 포함됨)
• git push -u origin HEAD
• 디자이너에게 안내: