/cc-blueprint:design — 스펙에서 Figma 시안까지

Usage#

/cc-blueprint:design [--spec {path|text}] [--frames "{섹션}/{상태},..."]
                     [--file {figma_url} | --new-file "{name}" [--project {projectId}] [--plan {planKey}]]
                     [--brand {Brand}] [--surface {surface}] [--app {path}]
                     [--direction "{대상} / {핵심 행동} / {톤}"] [--ledger {path}]

Step 0: Preflight (fail-fast)#

rules/coui-library-consumption.md §3 의 규칙 위에서 아래 순서로 실행한다. 쓰기 호출(use_figma)이 있으므로 시작 전에 figma:figma-use 를 로드한다.

1. figma MCP 인증 확인 — 미인증이면 즉시 중단: "인증 후 재실행" 안내 (/mcp → figma). 저작은 쓰기 작업이므로 무인 폴백이 없다 (읽기 전용 추출과 다르다).
2. 새 파일 — --new-file 이면 여기서 figma:figma-create-new-file 로 만든다. 아래 검사는 모두 대상 파일 키가 필요하다(search_design_system 의 fileKey 는 필수 인자).
   • 플랜: create_new_file 은 planKey 가 필수다. --plan 이 없으면 whoami 로 플랜을 읽는다 — 하나면 그것, 여럿이면 중단하고 플랜 목록을 보고한다(--plan 으로 재실행). 추측하지 않고 되묻지도 않는다.
3. CoUI 라이브러리 접근 — get_libraries 에서 이름이 CoUI - Cocode Design System v 로 시작하는 라이브러리를 찾는다. 새 파일에서는 libraries_available_to_add 쪽에만 보일 수 있고 쪽이 나뉘므로 …next_offset 을 끝까지 따라간다 — 마지막 쪽에서도 없으면 중단: 팀 라이브러리 publish 상태 확인 안내. 찾으면 그 키로 한정한 컴포넌트 검색 1건 히트를 확인한다.
4. 세대 · 릴리스 대조 — 기준이 둘이고, 묻는 것이 다르다(rules/coui-library-consumption.md §1 '버전 기준').
   • 스킬 기준 — 라이브러리 컴포넌트 명명이 저장소 루트 coui.version.json 의 coui_skills_basis 세대(bare-widget)와 일치하는지 확인. skew 발견: 진행하되 결과 보고에 "라이브러리 구세대 — coui figma-token-sync 재발행 필요" 명시, 흡수 절차는 skills/coui-library-update 로 라우팅 (저작을 막지 않는다).
   • 앱 기준 (--app 일 때) — cc-pixel-loop:visual-verify 의 figma_compare.py coui --app <앱> --library-components <라이브러리 ref 의 components.json>. 앱이 해석한 CoUI 릴리스(.dart_tool/package_config.json · pubspec.lock)와 라이브러리 사이에서 달라진 컴포넌트(drift)를 결과 보고에 싣는다 — 그 컴포넌트를 놓은 화면은 캔버스가 라이브러리의 모양을, 앱이 자기 릴리스의 모양을 그린다. 저작을 막지 않는다. 앱을 올릴지(cc-coui-upgrade) 라이브러리를 맞출지(skills/coui-library-update)는 보고를 받은 쪽이 정한다. 해석하지 못하면(undetermined:not-resolved — flutter pub get 전) 그 사실을 보고하고 스킬 기준으로만 진행한다.
5. 브랜드 발견 — figma-brand-selection.md §2 의 한정 검색으로 후보 컬렉션을 모은다(새로 발행된 팔레트는 수정 없이 후보가 된다). 게시 후보가 없다는 사실과 라이브러리 접근 실패를 구분한다. 로컬 브랜드를 조회하거나 새 제품 테마를 설계할 수 있다. 결과는 Step 0.5 가 사용한다.
6. 폰트 — Pretendard Regular·Medium·SemiBold·Bold (--new-file 이면 Inter Medium 도) 가 사용 가능한지 listAvailableFontsAsync 로 확인. 없으면 설치 안내 후 중단 (다른 폰트로 대체하지 않는다). 라이브러리 인스턴스를 놓는 모든 스크립트는 놓기 전에 폰트를 로딩한다.

절차·판정은 전부 rules/figma-direction.md — 여기는 실행 순서만 적는다.

서비스가 하우스 스타일이면(기본 — 하우스 스타일: 없음 을 적은 서비스만 아니다, rules/figma-direction.md §D2 에서 판정) 1번 전에 cc-designer:coui-product-style 의 SKILL.md 를 읽는다 — 1번의 톤은 사람이 정한 톤이 없으면 그 스킬의 하우스 무드로 채우고 묻지 않으며, 1번에서 고유 요소 셋(§D1 ⑤)을 함께 정한다. 2번의 레버는 기본값을 §D2 「하우스 스타일」 값으로 미리 채우고, 사람이 정한 톤이 열린층(밀도 · 형태 · 재질 · 서체 역할)을 덮어쓰라고 하면 그 이유와 함께 덮어쓴다 — 추론한 톤으로는 덮어쓰지 않고, 깊이 · 강조 면적은 고정이다. 셸 · 알림 · 상태는 그 스킬의 references 를 따르고, 문구는 서비스의 말투 문서가 있으면 그것이 먼저다.

1. 방향(§D1) — --direction · 스펙 · (대화형) 저작 전 한 번 묻기 · (무인) 추론 순으로 대상 · 핵심 행동 · 톤을 정한다. 추론한 칸은 보고 첫 줄과 DDR(low)에 남는다. 결정 정보(§D1 ④)는 묻지 않고 정한 핵심 행동과 스펙에서 뽑는다 — 사실마다 형태 · 값 · 출처를 적고 결정 화면을 정한다. 대화형이면 위 질문에 뽑은 목록을 같이 보인다. 유도한 값은 DDR(입력 · 계산 · 결과). 하우스 스타일 서비스는 고유 요소 셋(§D1 ⑤)과 그 요소를 맡을 화면도 정해 보고에 싣는다 — 크리틱(Step 4)이 그린 화면에서 같은 요소를 대는지 대조한다.
2. 레버(§D2) — 톤에서 위계 · 구성 단위 · 밀도 · 깊이 · 강조 면적과 형태 · 재질(라이브러리에 Semantic/ Surface 가 있을 때 — 서페이스 스타일 모드) · 테마 밀도(Semantic/ Dimension 에 밀도 모드가 있을 때)를 정하고, 브랜드 컬렉션/스타일로 직접 표현하는 서체·형태·재질·밀도의 값과 코드 지원 gap까지 DDR 한 건으로 남긴다.
3. 장부 비교(§D4) — --ledger 가 있으면 최근 다섯 제품과 비교한다. 미달이면 여기서 레버를 바꾸고, 바꾸지 않으면 사유와 함께 L1 로 보고한다. 없으면 '장부 없음'.

시작할 때 cc-designer:coui-product-style과 references/brand-theme-workflow.md를 읽는다. 전체 테마의 모든 속성을 설계하고 필요한 컴포넌트·variant/size/state·부모 슬롯·인스턴스만 override한다. 다음 팔레트 선택은 그 일부다. 로컬 변수와 텍스트/효과 스타일도 허용한다. Step 1에서 전체 화면 목록을 확보하고 Step 2에서 대표 화면을 먼저 렌더·검증한 뒤 전체로 확장한다. 대표 화면 검증은 자동 품질 단계이며 사용자가 요청하지 않은 승인 중단점을 추가하지 않는다.

절차·판정·입력별 처리는 전부 rules/figma-brand-selection.md — 여기는 실행 순서만 적는다. --brand {Brand}·컬렉션이 이미 고정된 파일에서 어느 단계를 건너뛰는지도 그 문서의 입력 표를 따른다.

1. 브리프(§1) — 매칭 입력이자 Step 2 의 구성·강조 판단 지침이다. 방향 · 결정 정보 · 구성 지침 · 카드 깊이 · 강조 면적 칸은 Step 0.4 의 결과를 옮기고, 색 방향은 그다음에 톤과 키워드에서 정한다.
2. 특성화(§3) — brand-catalog.figma.js 에 Step 0 항목 5 의 key 를 넣어 실행한다. 손으로 쓴 브랜드 설명은 쓰지 않는다.
3. 순위·확정(§4) — 순위 1 을 자동으로 쓰고 보고에 상위 3개 후보와 이유를 싣는다. 색상군이 안 맞으면 보고에 팔레트 요청 한 줄(§5).
4. 바인딩(§6) — 선정 결과(컬렉션 이름·id · Light 모드 id · 색 슬롯 key)를 DDR 1건으로 남겨 모든 저작자에게 넘긴다 — 병렬 저작이어도 선정은 한 번이다. 모드 고정·재바인딩은 Step 1.7·Step 2 가 brand-bind.figma.js 로 마지막에 한다(순서·이유는 consumption §7). 컬렉션 혼합은 self-check L0.

• --spec 텍스트를 화면(섹션) 목록으로 분해 — 섹션 1개 = 화면 1개 (rules/figma-workflow.md §2). 스펙에 화면 id(PRD 의 A-01 등)가 있으면 그 id 가 단위다 — 묶거나 대표만 고르지 않는다.
• 화면마다 상태 축 확정: 기본 4종(Default/Loading/Empty/Error — Default 는 예외 없이 필수) 전부 — 빠진 상태는 사유와 함께 L1 부채(figma-workflow §4). 스펙에 없는 상태 처리 방식은 cc-designer:design-decision 으로 확정하고 DDR 기록.
• 산출 2종 (저작 계획):

• 결정 화면(§D1 ④ — 핵심 행동 흐름의 첫 화면 · 핵심 행동을 일으키는 CTA 가 있는 화면)은 추적표 그 행에 표시한다 — self-check 9번이 결정 행을 그 프레임에서 찾는다.
• 체크리스트 행은 값과 형태로 적는다 — '도착 예정'처럼 주제만 적으면 대조가 주제의 존재만 보고 형태(날짜인지 기간인지)를 보지 못한다. 결정 행의 출처가 유도면 출처 칸에 그 DDR 을 적는다(slop-tells §S7 과의 경계 — figma-direction §D1 ④).
• 스펙 문구는 저작 메모를 뺀 글자로 적고, 뺀 메모는 스펙 수정 제안 목록에 따로 적는다(composition-patterns §C10 ①).
• 확인 방법: 스펙 화면 수 = 추적표 행 수. 사유 없이 빠진 화면이 없어야 한다.
• 수치 항목을 라이브러리 부품이 표현하지 못하면 체크리스트에 표시해 두고 rules/coui-library-consumption.md §8 로 처리한다 — 조용히 줄이지 않는다.

새 파일에는 화면 저작 전에 표준 표지(5슬롯 · 1280×720)를 깐다. 표를 해석해 그리지 않고 cover.figma.js 를 실행한다 — 슬롯 좌표·스타일의 유일한 정의는 그 파일의 상수다(스타일을 고칠 때도 그 파일만 고친다).

절차 (Step 2 와 같은 스킬 위임 — figma:figma-use 로드 필수):
1. 폰트 — Step 0 항목 6 에서 확인한 것. 하나라도 없으면 레시피가 throw 한다.
2. 레시피 전체를 use_figma 에 실행 — 바꾸는 곳은 PARAMS 블록뿐이다:
   kind·appName 은 `--new-file` 이름에서 정한다(`App`/`Console` 단어 · 앞부분 대문자). company·track 은 요청이 준 값을 쓰고,
   없으면 레시피 기본값을 쓴 뒤 보고에 그 사실을 적는다. 나머지는 레시피 기본값.
3. 반환값의 check 에서 false 인 항목은 보고에 그대로 싣는다.
4. 썸네일 — figma.setFileThumbnailNodeAsync 는 use_figma 에서 지원되지 않는다.
   "표지 프레임 우클릭 → Set as thumbnail" 수동 안내를 결과에 남긴다 (비차단).

표지는 화면이 아니다 — 레지스트리에 등재하지 않고 self-check 대상도 아니다(Cover 페이지는 rules/figma-workflow.md §1 의 대조 대상 밖).

절차·판정은 rules/figma-direction.md §D3 — 여기는 실행 순서만 적는다.

1. 대상 화면 — Step 1 추적표에서 진입 화면과 핵심 행동(Step 0.4) 흐름의 첫 화면을 고른다(최대 두 화면).
2. 안 — 화면마다 2–3안을 _explore 페이지의 섹션 방향 — {화면} 에 Mobile Default 하나씩 그린다. 그리는 규칙은 Step 2 와 같다 (라이브러리 인스턴스 · 선택 컬렉션 · brand-bind 마지막). 안끼리 위계 · 구성 단위 · 밀도 · 내비 구조 중 두 축 이상 다르다(운영 셸과 밀도를 고정한 경우 위계 · 구성 단위 둘 다 다르다 — §D3 ②). 결정 화면의 안은 모두 결정 정보를 그린다(§D3 ②).
3. 고르기 — 대화형이면 한 번 묻고(권고안 먼저), 무인이면 §D3 ④ 의 기준으로 고른다. 고른 안 · 이유 · 버린 안을 DDR 한 건으로 남긴다.
4. 넘기기 — 고른 안의 구조를 Step 1.7 · Step 2 에 넘긴다. 버린 안은 지우지 않는다.

건너뛰기(§D3 — --frames 증분 · 스펙이 구조를 못박음 · 고른 방향의 DDR 이 이미 있음)는 사유를 보고에 남긴다. _explore 는 self-check 대상이 아니다.

선택한 방향으로 각 surface의 진입·핵심 행동·가장 조밀한 대표 화면을 실제 크기로 렌더링한다. 같은 화면이면 합친다. Step 4의 독립 크리틱을 먼저 수행하고 수정한 스크린샷을 재검토한다. 토큰 바인딩 성공이나 L0=0만으로 이 단계를 통과하지 않는다. 대표 화면의 정보 위계·데이터 표현· 주 행동·타이포가 읽히는지 확인한 후에만 공통 템플릿을 확정하고 나머지 화면을 확장한다. 검토 시각·화면 ID·이미지·발견/수정 목록을 남긴다. 확장은 모든 화면을 같은 구성으로 복제하는 뜻이 아니다. 일정은 시간축, 추이는 그래프, 기록은 날짜/개체 관계처럼 실제 작업에 맞게 조합한다. 기존 방향 DDR이 있어도 새로 저작하는 대표 화면의 렌더 검토는 생략하지 않는다.

여러 화면에 같은 역할로 나오는 요소는 화면 저작 전에 한 번 정한다. 한 저작자가 순차로 해도 순서는 같다. 만드는 방법은 rules/figma-composition-patterns.md §C4(공통 셸)·§C5(표)·§C8(이미지 자리).

1. 목록 — Step 1 추적표에서 2개 이상 화면(추적표 행)에 같은 역할로 나오는 요소는 모두 뽑는다 — 한 화면의 상태 프레임은 한 번으로 센다. 새로 만드는 것뿐 아니라 라이브러리 부품을
   그대로 쓸 때도 조정자가 변형·크기·아이콘·색을 한 번 정해 DDR 한 줄로 넘긴다 — 값마다 적용 방법(속성 이름·슬롯 경로)까지 적는다.
2. 조정자 1명이 먼저 만든다(새 부품만) — 900 components 페이지에 도메인 전용이면 `{domain}/{Component}`, 범용이면 `promote/{Component}`
   (consumption §4 판정), 컴포넌트로 못 만드는 골격은 같은 페이지의 템플릿 프레임. 페이지 저작자는 그 페이지에 아무것도 남기지 않는다(템플릿은 같은 호출 안에서 복제해 자기 섹션으로 옮긴다).
   Step 0.5 항목 4 의 바인딩(brand-bind 의 FRAMES 에 컴포넌트·템플릿 id 를 준다)까지 끝낸 상태로 완성한다.
3. 배리어 — 목록이 전부 만들어지거나 정해지고 properties 로 변주(Tone·표시 여부 등)가 확인된 뒤에만 페이지 저작자를 시작한다.
   저작자에게 컴포넌트 key/node id 와 properties 목록(또는 정한 값)을 넘긴다.
4. 페이지 저작자 — 인스턴스만 놓고 properties 로 변주한다. 자기 페이지에서 같은 요소를 새로 만들지 않는다.
   필요한 변주가 없으면 만들지 말고 조정자에게 요청한다.

확인 방법: 공통 요소 목록의 각 요소가 컴포넌트(또는 템플릿) 1개 또는 DDR 의 한 값으로 귀결되고, 화면 프레임들의 해당 요소가 모두 그 인스턴스(mainComponent 동일)·템플릿 복제(구조·바인딩 동일)·그 값 중 하나다. 어긋나면 Step 4 의 화면 간 일관성 검사(self-check 10번)가 잡는다.

Figma Plugin API 사용법은 여기 없다 — 반드시 아래 스킬을 로드해 그 규칙대로 실행한다:

1. Skill(figma:figma-use)             — use_figma 호출 전 필수 (모든 쓰기)
2. Skill(figma:figma-generate-design) — 페이지/뷰 조립 워크플로우 (컴포넌트 발견→임포트→섹션별 조립)
3. (--new-file 시) Skill(figma:figma-create-new-file) — Step 0 에서 호출됨

이 커맨드가 위 스킬에 추가로 강제하는 것만 적는다:

• CoUI 라이브러리 인스턴스를 우선 재사용한다. 부족한 표현은 제품 컴포넌트 조합·스타일 또는 라이브러리 확장으로 구현한다. 로컬 변수·스타일을 허용하며 코드 대응을 기록한다.
• 색·간격·타이포·표면은 Step 0.5의 전체 테마와 등록된 컴포넌트/슬롯/인스턴스 토큰·스타일에 연결한다. 화면 고유 값의 역할과 범위를 DDR에 기록한다.
• 상태·크기·종류는 인스턴스 component property(Variant=/Size=/State=/Enabled=) 전환으로.
• 인스턴스 안쪽을 만져도 되는 범위(검증된 연산과 새 속성 검증 방법)는 consumption §7, 스펙과 부품이 충돌하면 §8 — 둘 다 detach·프리미티브 흉내로 풀지 않는다.
• 공통 요소는 Step 1.7 산출을 인스턴스로 놓는다. 새로 만들지 않는다.
• 모든 화면은 Step 0.4 의 레버와 Step 1.6 에서 고른 안의 구조(위계 · 구성 단위 · 밀도 · 내비 구조)를 따른다. 고른 안은 복제해 그 섹션의 Mobile-Default 로 시작해도 된다.
• 결정 화면에는 결정 정보(Step 0.4)를 브리프에 적은 형태로 그린다 — 값이 '수치 확인 필요'인 사실도 자리는 그린다.
• 한글이 든 글자의 줄바꿈 자리는 저작이 정한다 — 글자와 폭이 다 정해진 뒤, brand-bind 앞에 keep-all.figma.js 를 페이지마다 한 번(slop-tells §S11). 그 뒤 글자나 폭이 바뀌면 MODE = 'rewrap' 으로 다시 돈다. 손으로 정하는 줄 나눔(문장 · 구 경계)은 LF 로 넣는다.
• brand-bind.figma.js 는 페이지마다 마지막에 한 번 — Step 0.5 항목 4. 형태 · 재질 레버를 골랐으면 같은 실행의 SURFACE 로, 테마 밀도를 골랐으면 DENSITY 로 그 모드를 고정한다.
• 부품을 놓은 뒤 조립 패턴은 rules/figma-composition-patterns.md 의 해당 절.
• 글자·숫자 자리(샘플 문구·값)는 같은 문서 §C10 — 스펙 문구는 저작 메모를 빼고 그리고, 지표 수치는 스펙 체크리스트에 있는 것만, 목록에는 길이가 다른 값과 경계값을 섞고, 흔한 가명·더미·부품 기본 문구는 남기지 않고, 값이나 구절을 대시·가운뎃점으로 잇지 않는다.

• 프레임 네이밍: rules/figma-workflow.md §2 표 그대로 ({플랫폼}-{상태}, 예 Web-Empty — 같은 섹션 안 왼쪽 Mobile · 오른쪽 Web).
• 페이지·섹션: 페이지는 번호 오름차순으로 만들고, 섹션을 먼저 만든 뒤 그 안에 프레임을 짓는다(figma-generate-design 규칙). 섹션 크기·프레임 좌표는 figma:figma-use 규칙대로 하고 여백·간격 값은 자유다(figma-workflow §5 R4). 프레임에는 description 이 없다 — 메모는 레지스트리 note·DDR(rules/figma-workflow.md §4 L2).
• 레지스트리 등재: 3단 대응(Project/Page/Section ↔ [Surface]/Feature/UseCase)으로 화면 레지스트리에 행 추가 — 계약·위치는 cc-flutter:figma-widgetbook-alignment 가 SoT. 요청에 레지스트리 파일이 지정되지 않았으면 파일을 쓰지 않고 행(surface · feature · usecase_name · figma_page · figma_node)을 보고에만 싣는다. 코드 쪽 use_case 가 아직 없으면 코드 칸을 —(미구현: /cc-blueprint:build 대상) 으로 남긴다.
• 보고: 섹션별 프레임 node URL 목록 (이후 /cc-blueprint:build 의 입력이 된다).

Step 1 추적표의 이동 칸을 클릭 흐름으로 연결한다 — prototype-links.figma.js 를 페이지마다 use_figma 로, PARAMS 에 간선 목록을 채운다(클릭 ON_CLICK → 이동 NAVIGATE, 뒤로 가기는 BACK). 간선은 이동 목록이 아니라 화면에 그려진 이동 요소(다른 화면으로 가는 버튼·행·탭 항목·뒤로가기 화살표) 전부에서 뽑고, 이동 목록은 빠진 간선을 대조하는 데 쓴다. 현재 화면을 가리키는 선택 탭·내비 항목·역할 전환 조각은 이동 요소도 이동 목록의 행도 아니므로 미연결 목록에 싣지 않는다. 탭바 항목이 가리키는 화면에 뒤로가기가 그려져 있으면 간선이 아니라 §C4 위반이다 — 지운다.

• 출발은 실제로 눌리는 인스턴스(버튼·행·카드)에 건다 — 인스턴스 루트와 안쪽 중첩 자식 모두 걸린다. 스펙의 '카드' 같은 말을 실제 노드 이름·id 로 옮기는 일은 저작이 끝난 프레임에서 읽어 채운다.
• 도착 프레임이 먼저 있어야 한다. 같은 페이지의 프레임만 다룬다 — 도착은 같은 플랫폼의 Default 프레임이고, 출발은 상태 프레임(Empty·Error)에 그려진 이동 요소도 포함한다. 다른 페이지로 가는 이동(예: 하단 탭바)은 불가하다 — 시도하지 않고 미연결 목록에 사유와 남긴다.
• 못 건 간선은 레시피가 사유와 함께 skipped 로 돌려준다 — 미연결 목록에 그대로 싣는다(그 사유가 self-check L1 사유다).
• 시작점 — 페이지마다 진입 화면(스펙이 여정을 나눠 적었으면 여정마다 하나)을 flowStartingPoints 로 지정하고 이름을 명시한다(여정의 한글 명사구, 예 진료 예약). 간선이 0 이어도 지정한다.
• 확인 — 새 호출에서 반응을 다시 읽어 개수·도착지를 목록과 대조하고, 시작점에서 도달할 수 없는 Default 프레임(들어오는 간선 0)을 찾는다 — 스펙이 진입 경로를 안 적은 화면이다. 내용 구조가 하나로 정하면(목록 카드 → 상세) 그 간선을 걸고 DDR 에 적고, 아니면 없는 UI 를 새로 그리지 않고 미연결 목록에 「진입 경로 없음 — 스펙 확인」으로 싣는다.
• 이동 정보가 정말 없을 때만 간선을 건너뛰고 보고에 「프로토타입 미연결 — 이동 정보 없음」 한 줄.

1. self-check — skills/design-self-check 를 저작 결과 전체에 적용한다(Cover 제외). 입력: 프레임 URL · 선정 브랜드 컬렉션(Step 0.5) · Step 1 산출(결정 화면 표시 · 결정 행 포함) · Step 3.5 미연결 목록 (스펙 충실도·결정 정보·브랜드 순도·프로토타입 링크 검사의 기준) · 브리프의 '강조 면적' 칸(기본이거나 비었으면 레시피 기본값 — 슬롭 지문 검사의 기준).

• L0 발견 → 그 자리에서 재작업 (보고로 미루지 않는다) — 예산·채택 조건은 design-self-check 「재작업 예산」.
• L1/L2 와 판단·불가 표지는 판정표와 함께 보고에 싣는다. self-check 의 PASS 는 항목 3 뒤에 확정한다.
• 하우스 스타일 서비스는(rules/figma-direction.md §D2) self-check 뒤에 cc-designer:coui-product-style 의 references/figma-file.md 7절 다크 확인을 한다 — 화면 프레임마다 색 컬렉션 모드를 Dark 로 바꿔 보고 Light 로 되돌린 뒤, 그 프레임에 brand-bind.figma.js 를 다시 돌려 pinnedAll 이 true 인지 읽는다(self-check 는 이미 끝났으므로 되돌림이 빠져도 아무 검사가 잡지 않는다). 다크에서 고친 곳이 있으면 self-check 를 다시 돌리고 재작업 1회로 센다. 다크는 상태 프레임이 아니다.

2. 품질 평가 — rules/figma-quality-rubric.md 의 필수 크리틱 단계. 판정 (wireframe-level / needs-polish / shippable)과 지적 처리는 rubric 이 SoT 다(결정 정보 누락을 어느 렌즈에서든 P1 로 올리는 것 포함). 크리틱 입력의 브리프에는 결정 정보 줄과 결정 화면이 들어간다. L0/L1/L2 게이트에 섞지 않는다. rubric 이 재작업을 지시하면 끝난 뒤 self-check 를 다시 돌려 재작업이 L0 을 만들지 않았는지 본다. 3. 라이브러리 결함 이슈 — self-check 의 L1 과 품질 평가의 P1 ⓐ 로 목격한 CoUI 결함을 한 번에 처리한다. 결함 1종 = 1건, 절차·본문 항목·모드는 rules/coui-library-consumption.md §6 이 SoT 다. 병렬 저작이면 각 저작자가 올리지 않고 취합 담당이 합산 뒤 한 번에 처리한다(중복 방지). 외부 저장소에 쓰는 행위는 허용이 명시된 때만 한다.

4. 축 기록 · 장부 갱신 — rules/figma-direction.md §D4 '갱신'. 실제로 그려진 값(변주안에서 고른 구조 포함)으로 축 기록을 다시 쓰고, 장부가 쓸 수 있는 로컬 파일이면 갱신한다. 다른 저장소의 장부는 쓰기 허용이 명시된 때만 쓰고, 아니면 더할 줄을 보고에 싣는다.

5. 보고 — Output 형식. 첫 줄은 방향이다 — 추론한 칸이 있으면 그 사실을 맨 앞에 둔다. DDR 목록(결정문·근거 사다리 등급·신뢰도)을 마지막에 첨부한다. DDR 은 보고에 남는다(코드 scope 가 있으면 .claude/docs/{scope}/ 에도). 단계별 소요도 적는다 — 단계마다 시작 시각을 적어 두었다가 분 단위로 뺀다(어디서 시간이 드는지 다음 실행과 비교하려는 기록이라 대략이면 된다). 방향 = Step 0–1(프리플라이트 · 방향 · 브랜드 · 분해) · 변주안 = Step 1.6 · 저작 = Step 1.5 · 1.7 · 2 · 3 · 3.5 · self-check = 항목 1 · 크리틱 = 항목 2 의 크리틱 · 재작업 = L0 · P1 재작업과 그 재검사.

Output#

## 🎨 저작 결과 — {파일명}
방향: 대상 {…} · 핵심 행동 {…} · 톤 {…} — 출처 {--direction | 스펙 | 답변 | 추론함: {칸} — 틀리면 --direction 으로 다시}
브랜드: {선정 Brand} · 라이브러리 세대: {일치|skew} · 앱의 CoUI: {패키지 버전 · 커밋 | --app 없음} · 라이브러리와 달라진 컴포넌트 {n}
| PRD 화면 | 섹션 | 프레임 | node URL | self-check |
|----------|------|--------|----------|------------|
| A-01 | 상품 목록 | 4 (Default/Loading/Empty/Error) | figma.com/...?node-id=... | L0 0 · L1 1 · 보류 0 |
### 브랜드 — 선정 {Brand} (방식: {자동(순위 1) | 지정}) · 후보 {1위 · 2위 · 3위 — 각 한 줄 이유} · 브리프 {성격 · 키워드 3 · 카드 깊이 · 강조 면적} · 순도 스캔: 미해결 바인딩 {n} · 등록된 override {범위}
### 팔레트 요청 — (색상군 불일치일 때만 — rules/figma-brand-selection.md §5) 한 줄 · 대비 미달 브랜드·수치(§3)
### 레지스트리 등재 행 — Step 3 형식  (레지스트리 파일이 지정되지 않았을 때)
### 커버리지 — 스펙 화면 {n} 중 저작 {m} · 미저작 {k}: {id — 사유}
### 결정 정보 — {결정 화면}: {사실 → 값(형태) · 스펙 인용 | 유도(DDR n) | 샘플 | 수치 확인 필요} · 그려짐 {n}/{m} · 빠짐: {사실 — 사유(known-gap)}  (figma-direction §D1 ④)
### 스펙 수치 대조 — 충족 {n}/{m}(값의 형태까지) · 불충족: {항목 — 사유 (라이브러리 제약이면 이슈/초안 · 만료 조건)}
### 스펙 수정 제안 — {스펙 위치}: 저작 메모 '{…}' 를 빼고 그림 — 문구 확정 필요 | 문구 제안 '{…}'(slop-tells §S10) | 값 필요 — '수치 확인 필요' {n}곳  (composition-patterns §C10 ① · ③)
### 공통 요소 — {요소 → 컴포넌트/템플릿 node 또는 정한 값}  (저작을 나눈 경우)
### 프로토타입 — 연결 {n} · 미연결 {k}: {사유} · 플로우 시작점: {이름}
### 고유 요소 — 약속 {요소 셋 → 담당 화면} · 그려짐 {n}/3 · 크리틱 대조: {일치 | 못 댄 것: {요소}}  (하우스 스타일 서비스 · figma-direction §D1 ⑤)
### 레버 — 하우스 스타일 {coui-product-style[ · 덮어씀: {레버=값 — 톤에서 나온 이유} …] | 없음} · 위계 {…} · 구성 단위 {…} · 밀도 {…} · 깊이 {…} · 강조 면적 {…} · 테마/override: 형태 {…} · 서체 역할 {…} · 재질 {…}  (figma-direction.md §D2)
### 변주안 — {화면}: 가 · {…} / 나 · {…} / 다 · {…} → {선택} — {이유} · 다른 축 {…}  (건너뜀이면 사유)  (§D3)
### 축 기록 — {JSON 한 줄} · 장부 비교: {n}개 중 미달 {m} — {레버 변경 | L1 사유} | 장부 없음 · 갱신: {씀 | 보고에만}  (§D4)
### 품질 판정 — {wireframe-level | needs-polish | shippable} · 주요 지적 {…}  (figma-quality-rubric.md)
### 라이브러리 결함 — 등록 {n} (URL) · 초안 대기 {n} (경로)
### 소요 — 방향 {분} · 변주안 {분} · 저작 {분} · self-check {분} · 크리틱 {분} · 재작업 {분} · 합 {분} (use_figma {n}회)
### 디자인 결정 (DDR n건)
### 수동 단계 — (--new-file) 표지 프레임 우클릭 → Set as thumbnail
### 다음 단계: /cc-blueprint:build --frames {...}

Error Handling#

Related#

• figma:figma-use · figma:figma-generate-design · figma:figma-create-new-file — 실행 계층 (위임)
• skills/design-self-check — Step 4 판정기
• skills/coui-library-update — 프리플라이트 skew 발견 시 흡수 절차
• /cc-blueprint:build — 저작 결과를 화면 코드로 (다음 단계)
• cc-designer:design-decision — DDR 프로토콜