---
name: code
description: Figma 시안을 프론트엔드 레포의 실제 코드에 반영한다 — 시안이 바뀐 자리를 기존 코드에 최소 수정으로 옮기거나, 시안에만 있고 코드에 없는 화면·상태 변형을 새로 구현한다. 레포의 기존 명명·토큰·상태 관리 관례를 먼저 읽어 덮어쓰지 않고, 수치 대조와 스크린샷 대조를 모두 거친 뒤 브랜치·PR로 낸다. Triggers - "/fig:code", "시안 코드에 반영해줘", "피그마 바뀐 거 앱에 적용", "이 화면 프론트에 구현해줘", "시안대로 코드 고쳐줘", "디자인 변경분 코드에".
allowed-tools: AskUserQuestion, Bash, Read, Write, Edit, Glob, Grep, Skill, mcp__plugin_figma_figma__get_design_context, mcp__plugin_figma_figma__get_screenshot, mcp__plugin_figma_figma__get_metadata, mcp__plugin_figma_figma__get_variable_defs, mcp__plugin_figma_figma__download_assets, mcp__claude-in-chrome__tabs_context_mcp, mcp__claude-in-chrome__navigate, mcp__claude-in-chrome__computer, mcp__claude-in-chrome__browser_batch, mcp__claude-in-chrome__read_console_messages
---

# fig:code — Figma 시안 → 프론트 레포 코드 반영

시안에 그려진 것을 **돌아가는 앱의 코드**로 옮긴다. 대상은 빌드 체계를 갖춘 프론트엔드 레포이고, 산출물은 그 레포의 브랜치와 PR이다.

**핵심 전제 — 시안과 레포는 각각 다른 것의 정본이다.**

| 시안이 정본인 것 | 레포가 정본인 것 |
|---|---|
| 수치·색·간격·문구·배치·상태 변형 | 파일 구조·명명 규칙·상태 관리 방식·토큰 참조 경로 |

이 선을 넘으면 사고가 난다. 시안대로 맞추겠다고 레포 관례를 갈아엎거나, 코드가 편하다고 시안 수치를 임의로 반올림하는 것 둘 다 같은 실패다. **판단이 서지 않으면 반영하지 말고 물어본다.**

## When to invoke

- "시안 바뀐 거 코드에 반영", "피그마대로 고쳐줘", "이 화면 구현해줘"
- 시안에만 있고 코드에 없는 화면·상태 변형을 만들 때
- "/fig:code" 명시 호출

## When NOT to invoke

- 무빌드 단일 HTML 동작 프로토타입 → `/fig:proto`
- 프레임 목록·구조만 파악 → `/fig:read`
- 시안 자체의 구조·흐름·네이밍 검증 → `/fig:lint`
- AS-IS/TO-BE 변경점을 시안에 표기하고 기획 문서에 정리 → `/fig:diff`
- 코드가 아니라 Figma 정본에 반영 → `/fig:sync`
- 코드를 Figma로 올리는 역방향 → `figma:figma-generate-design`

## Inputs

- `figma_url` (필수): figma.com/design/:fileKey/...?node-id=... — 대상 프레임. 없으면 요청.
- `repo` (필수): 대상 레포 경로. 기본은 현재 작업 디렉토리이되, 다른 곳이면 명시 요청.
- 모드 (1단계에서 확정): **변경분 반영** 또는 **신규 구현**. 한 번에 둘이 섞이면 갈라서 순서대로.

---

## Procedure

### 0. 선행 스킬 호출

`get_design_context`를 부르기 전에 `figma:figma-design-to-code`를 먼저 호출한다(그 스킬의 필수 선행 조건). 건너뛰면 시안 읽기가 어긋난다.

### 1. 인터뷰 — 무엇이 되면 끝인지 (CLAUDE.md 1)

착수 전에 아래를 채운다. 못 채운 항목은 추측하지 말고 질문으로 채운다.

- **대상 범위** — 어느 프레임·화면, 상태 변형은 어디까지(기본만인지 잠금·오류·빈 상태까지인지)
- **모드** — 변경분 반영인지 신규 구현인지
- **완료 조건** — 검증 가능한 형태로. 예: "A 화면의 간격·토큰이 시안과 일치, B 상태에서 조작 잠금 동작, typecheck 통과"
- **기획 문서 선반영** — 화면 구조나 조작 규칙이 바뀌는 건(신규 화면·상태 추가, 잠금·분기 규칙 변경)이면 기획 문서에 그 결정이 이미 반영돼 있는지 확인한다. 안 돼 있으면 코드가 문서보다 앞서가는 것이므로, 반영은 하되 **그 사실을 6단계 보고에 남긴다.** 수치·색·문구 같은 표현 변경은 해당 없다.

여러 화면이면 시작 전에 순서를 공유한다.

### 2. 레포 관례 파악 (쓰기 전 필수 — 건너뛰지 않는다)

**코드를 한 줄도 고치기 전에** 대상 레포가 어떻게 쓰여 있는지부터 읽는다.

1. 레포 루트의 `CLAUDE.md`·`AGENTS.md`·`README` — 아키텍처와 하지 말아야 할 것
2. **같은 계열 컴포넌트 1~2개를 통째로 열어본다** — 클래스 명명, 상태를 어디서 받는지(전역 스토어인지 로컬인지), 조건부 비활성 처리를 어떤 헬퍼로 하는지
3. 스타일 토큰의 정의 위치 — CSS 변수, theme 파일, 디자인 토큰 패키지 중 무엇인지
4. 검증 명령 — `package.json` scripts에서 typecheck·lint·build·dev 이름 확인

여기서 확인한 방식을 그대로 따른다. 더 나은 방식이 떠올라도 이번 변경에서 바꾸지 않는다(CLAUDE.md 4 — 요청 범위 안에서만).

### 3. 시안 정합 읽기 (읽기 전용, 컨펌 불필요)

- `get_design_context`로 구조·수치·토큰을, `get_screenshot`으로 시각을 함께 받는다. 둘 중 하나만으로는 어긋난다.
- 토큰 이름이 필요하면 `get_variable_defs`. 시안이 변수에 묶여 있으면 **코드도 대응 토큰에 묶는다. hex·px 하드코딩 금지.**
- **라벨·문구는 시안 원문 그대로.** 더 나은 표현이 떠올라도 바꾸지 않는다 — 문구는 기획 문서와 함께 결정된 것이다.
- 이미지·아이콘·일러스트는 코드로 다시 그리지 말고 `download_assets`로 원본을 받아 쓴다. 코드로 흉내 내면 시안에 없는 동작을 발명하게 된다.
- **변경분 모드면 여기서 대조표를 먼저 만든다** — 시안 값과 현재 코드 값을 나란히 놓아, 실제로 바뀐 자리만 추린다.

| 항목 | 시안 | 현재 코드 | 조치 |
|---|---|---|---|
| 카드 안쪽 여백 | 16 | 12 | 수정 |
| 제목 크기 | 14 | 14 | 유지 |

이 표가 곧 작업 목록이자 5단계 검증의 기준이 된다.

### 4. 반영 — 최소 수정

**변경분 모드**
- 대조표에서 "수정"으로 표시된 자리만 고친다. 인접 요소·포맷·주석은 그대로 둔다.
- 한 값이 여러 곳에 퍼져 있으면 정의처 한 곳을 고쳐 전파되게 한다. 호출처를 일일이 고치는 건 관례를 벗어나는 신호다.

**신규 구현 모드**
- 인접한 같은 계열 컴포넌트를 골격으로 삼아 시작한다. 빈 파일에서 새 패턴을 만들지 않는다.
- 상태·잠금·오류 처리는 레포에 이미 있는 헬퍼를 통해서 한다. 같은 판정을 새로 구현하면 두 벌이 되어 갈라진다.
- 상태 변형은 별도 컴포넌트로 복제하지 말고 조건부 표현으로 둔다.

두 모드 공통으로, 시안에 없는 동작(호버 효과, 애니메이션, 자동 저장 등)을 임의로 넣지 않는다.

### 5. 검증 — 셋 다 필수

하나라도 건너뛰면 반영이 끝난 것이 아니다.

**급하다는 이유로 줄이지 않는다.** 시간이 없을 때 줄일 것은 반영 범위(항목을 나눠 뒤로 미루기)이지 검증이 아니다. 특히 스크린샷 대조를 "육안으로 갈음"하는 건 축소다 — 시안 이미지와 실제 화면을 같은 배율로 나란히 놓는 것까지가 이 단계다. 검증을 건너뛰고 낸 반영은 어긋난 채로 남고, 되돌리는 비용이 검증 비용보다 항상 크다.

1. **기계 검증** — 2단계에서 확인한 typecheck·lint·build를 돌린다. 경고는 새로 생긴 것만 본다(기존 경고와 구분).
2. **브라우저 실제 동작** — dev 서버를 띄우고 대상 화면을 직접 조작한다. 콘솔 오류 0을 확인한다. 상태 변형이 범위면 그 상태를 실제로 만들어 본다.
3. **시안 대조 (수치 + 스크린샷 둘 다)**
   - 3단계 대조표의 각 행을 실제 결과와 맞춰 "조치" 열을 채운다.
   - 시안 스크린샷과 브라우저 스크린샷을 같은 배율로 놓고 눈으로 비교한다. 수치만으로는 누락(빠진 요소·잘못된 순서)을 못 잡고, 스크린샷만으로는 미세한 값 차이를 못 잡는다.

어긋난 게 남으면 고치고 다시 검증한다. **고치지 못한 것은 조용히 넘기지 말고 보고에 남긴다.**

### 6. 미리보기 → go → 브랜치·PR (CLAUDE.md 5 — 외부 쓰기)

원격에 올리기 전 **반드시** 사용자 확인을 받는다.

미리보기에 담을 것:
- 대상 레포·브랜치명
- 파일별 변경 요약(추가·수정·삭제)
- 대조표 최종본(무엇을 맞췄는지)
- 검증 결과(기계 검증·브라우저·스크린샷 대조)
- 반영하지 못한 것과 사유

"이대로 진행할까요? (go / 수정사항)"으로 닫는다. go를 받은 뒤에만 브랜치를 따서 커밋·push하고 PR을 연다. **미리보기에 없던 것을 실행 단계에서 끼워넣지 않는다.**

PR 본문에는 시안 링크, 반영 범위, 검증 방법, 남은 것을 적는다.

---

## Constraints

- **시안 수치를 임의로 조정하지 않는다.** 코드에서 표현하기 까다로워도 그대로 넣거나, 안 되면 이유를 들어 물어본다. 반올림·근사는 시안이 정본이라는 전제를 깬다.
- **레포 관례를 리팩터링하지 않는다.** 더 나은 구조가 보여도 이번 변경에서는 알려만 준다.
- **시안과 코드가 모순되면 멈춘다.** 어느 쪽이 최신인지는 사람이 안다. 한쪽을 임의로 정본 삼아 반영하면 조용히 갈라진다.
- **문구·라벨은 원문 유지.** 오타로 보여도 고치지 말고 알린다 — 기획 문서와 맞춰진 값일 수 있다.
- 시안 자체가 어긋나 보이면(누락 상태, 겹친 요소) 반영을 멈추고 `/fig:lint`로 넘긴다.

## Notes

- 대조표는 버리지 않는다. PR 본문에 넣으면 리뷰어가 "무엇을 왜 바꿨는지"를 코드 diff 없이 안다.
- 프로젝트 고유 제약(파일 plan·폰트 한계·토큰 라이브러리 성격 등)은 이 문서에 적지 말고 메모리에서 확인한다.
- 한 화면이 크면 카드·영역 단위로 쪼개 3~5단계를 반복한다. 한 번에 많이 고치면 어디서 어긋났는지 좁히기 어렵다.