LogoSkills

/cc-blueprint:build — Figma 시안에서 화면 코드까지 (데이터레이어 없이)

레지스트리에 등재된 Figma 프레임을 데이터레이어 없는 기능모듈(Page·Widget·BLoC + 도메인 계약 인터페이스 + mock 주입)로 구현해, 위젯북 use_case 등재·상태 4종 골든 스냅샷·검증 체크리스트 통과 기록을 남깁니다. 백엔드가 아직 없는 화면을 기획·디자인 검증 가능한 형태로 먼저 완성할 때, 시안(Figma)이 있고 화면 ...

/cc-blueprint:build — Figma 시안에서 화면 코드까지 (데이터레이어 없이)#

항목내용
실행 명령/cc-blueprint:build
분류cocode design
난이도●●○ 보통
MCP 서버figma

한마디로#

Figma 시안을 주면 실제 앱 화면 코드로 구현하되, 서버·DB 같은 데이터 부분은 만들지 않는 명령입니다. 화면은 "데이터가 이렇게 생겼다"는 계약(인터페이스) 과 가짜 데이터(mock) 위에서 돌아가므로, 백엔드 개발 전에 위젯북 전시장에서 상태별(Default/Loading/Empty/Error)로 눌러보고 피드백을 받을 수 있습니다. 나중에 백엔드가 준비되면 가짜 데이터 자리에 진짜 구현만 끼우면 됩니다(bricks 흡수 용이).

누가·언제 쓰나요#

  • /cc-blueprint:design 으로 시안이 나왔고 화면 코드를 시작할 때
  • 백엔드 일정과 무관하게 화면 먼저 검증(기획·디자인 피드백 루프)하고 싶을 때
  • 화면 모듈을 이후 bricks/kobic 구조로 흡수하기 쉽게 만들고 싶을 때

무엇을 해주나요#

  • Figma 프레임을 읽어 화면 모듈(페이지·위젯·상태 관리)을 CoUI 표준 부품으로 구현합니다
  • 데이터는 계약 인터페이스 + mock 공급자로 대체합니다 — Repository 구현·API·DB 는 만들지 않습니다
  • 화면을 위젯북에 등재하고 상태 스위치(Knob)가 실제로 동작하게 배선합니다
  • 상태별 골든 스냅샷(비주얼 회귀 기준)을 만들어 이후 변경이 화면을 깨면 테스트가 잡아냅니다
  • 끝나면 검증 체크리스트(데이터레이어 0 · 계약+mock · 등재 · 스냅샷)를 통과했는지 스스로 확인합니다

어떻게 쓰나요#

# 레지스트리에 등재된 섹션 하나를 구현
/cc-blueprint:build --frames  " 도서 목록 "   --app {앱 워크스페이스 경로}

# 여러 섹션 일괄 + 대상 feature 워크스페이스 지정
/cc-blueprint:build --frames  " 도서 목록,도서 상세 "   --app apps/unibook --feature store

안에서 무슨 일이 벌어지나요#

  1. 입력 검증 — 프레임이 레지스트리에 등재돼 있는지, (권장) design-self-check L0 = 0 인지 확인합니다.
  2. 시안 읽기 — Figma 에서 레이아웃·토큰·컴포넌트 구성을 추출합니다.
  3. 모듈 스캐폴드 — 페이지·위젯·BLoC + 도메인 계약 + mock 공급자 골격을 만듭니다.
  4. CoUI 구현 — 표준 부품과 토큰으로 화면을 조립합니다.
  5. 위젯북·회귀 배선 — use_case 등재, 상태 Knob, designLink 결합, 골든 스냅샷.
  6. 검증 체크리스트 — 4항목 통과를 확인하고 결과를 보고합니다.
⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Usage#

/cc-blueprint:build --frames  " {섹션}[,{섹션}...] "   --app {path} [--feature {name}] [--surface {surface}]
옵션설명
--frames구현할 섹션(레지스트리 등재분). 상태 프레임은 섹션 단위로 전부 읽는다
--app대상 앱/모노레포 워크스페이스 경로
--featurefeature 모듈 이름 (기본: 섹션이 속한 Page 이름의 snake_case)
--surface레지스트리 3단 대응의 [Surface] (기본: 레지스트리 행에서 읽음)

Step 0: Input Validation#

1. 레지스트리 대조 — --frames 의 각 섹션이 화면 레지스트리에 등재돼 있는가
   (미등재 프레임은 정본이 아니다 — rules/figma-workflow.md §1). 미등재 → 그 섹션 SKIPPED
   +  " /cc-blueprint:design 으로 등재 후 재실행 "   안내.
2. (권장) skills/design-self-check 를 입력 프레임에 적용 — L0 프레임은 구현 입력으로 받지
   않는다(시안 결함을 코드로 복제하는 것을 막는다). L0 발견 시 그 섹션 SKIPPED-BLOCKED
   (blockedBy 시안 재작업).

Step 1: Figma 읽기 (위임)#

figma:figma-design-to-code 스킬을 로드하고 get_design_context 로 섹션의 상태 프레임 전부를 읽는다 — 파라미터 규약·응답 형태는 그 스킬/도구가 SoT.

Step 2: Module Scaffold — 프레젠테이션 온리 계약#

모듈 구조는 kobic Clean Architecture feature 모듈(cc-bricks 로스터)과 같은 자리·같은 이름을 쓰되, data 레이어 디렉토리를 만들지 않는다:

feature/{location}/{feature_name}/
├── domain/
│   ├── entity/            # 화면이 소비하는 Entity (시안에서 추출한 필드)
│   └── repository/        # ⭐ 계약 인터페이스만 — 구현체 없음
├── presentation/
│   ├── bloc/              # BlocSignal — UseCase 대신 repository 계약을 직접 주입받지 않고
│   │                      #   도메인 UseCase 를 거친다 (cc-flutter:package-layers 준수)
│   ├── page/              # Page 는 BLoC 을 this.bloc 선택 주입으로 받는다 (widgetbook mock 가림 방지)
│   └── widget/
├── mock/                  # ⭐ mock repository 구현 + 시나리오 데이터 (Default/Loading/Empty/Error)
│   └── {feature}_mock_repository.dart
└── {feature}_widgetbook.dart 등 use_case  # feature 소유 (widgetbook-conventions)

bricks 흡수 계약 (이 커맨드의 존재 이유):

  • domain/ 과 presentation/ 은 이후 bricks/kobic data 레이어가 들어와도 변경 0 이어야 한다 — 화면이 mock 을 직접 import 하지 않고, DI 조립부에서만 mock repository 를 계약에 바인딩한다.
  • mock/ 은 data 레이어 도착 시 통째로 삭제 가능해야 한다 (교체 지점이 DI 1곳).
  • Repository 구현·API client·DB(Drift)·캐싱은 생성 금지 — 발견되면 검증 체크리스트 실패.

Step 3: CoUI 구현 (위임)#

  • 변환 패턴: cc-flutter:figma-to-coui (12 Use Case) — 페이지 뼈대·폼·로딩·오버레이 등.
  • 컴포넌트 API 1차 소스: cc-coui:* (컴포넌트 1:1 스킬). 토큰 하드코딩 금지 — 시안의 variable 바인딩을 코드 토큰 체인으로 옮긴다 (Properties/Code Examples 프레임 참조).
  • 상태 표현: Bloc state ↔ 시안의 상태 프레임 1:1 (Default/Loading/Empty/Error — figma-workflow §5 R2 어휘).

Step 4: Widgetbook + Visual Regression (분리 가능한 단계)#

skills/widgetbook-wiring 를 로드해 그 절차(배선 5단계 · 완료 조건 4항목)를 그대로 수행한다 — 기존 화면 소급 등재 시에는 이 Step 만 단독 실행할 수 있다. 규약 SoT(widgetbook-conventions · figma-widgetbook-alignment · golden-test-guide)는 그 스킬이 인용한다.

Step 5: Verification Checklist (완료 선언 조건)#

□ 데이터레이어 0 — data/ 디렉토리·Repository 구현·API client·DB 코드 부재 (grep 검사)
□ 계약 + mock — domain/repository 인터페이스 존재 · mock/ 이 DI 1곳에서만 바인딩
□ use_case 등재 — 섹션마다 1건, 상태 Knob 동작 (Page 자체 BLoC 생성 없음)
□ 골든 스냅샷 — 상태 4종 × 대표 뷰포트 존재, flutter test 통과

체크 실패 항목이 있으면 완료를 선언하지 않고 해당 Step 으로 되돌아간다(섹션당 2회, 이후 실패 보고).

Output#

## 🧩 구현 결과 — {feature}
| 섹션 | 모듈 경로 | use_case | 골든 | 체크리스트 |
|------|-----------|----------|------|------------|
| 도서 목록 | feature/application/store/... | ✅ | 4/4 | PASS |
### mock 시나리오: {n}종 · bricks 흡수 지점: DI {파일}:{줄}
### 다음 단계: /cc-blueprint:sync (Figma↔Widgetbook 대조) · 데이터레이어: cc-bricks / cc-serverpod

Error Handling#

상황행동
레지스트리 미등재 프레임그 섹션 SKIPPED + design 커맨드 안내
입력 프레임 self-check L0그 섹션 SKIPPED-BLOCKED (시안 재작업 선행)
CoUI 에 없는 컴포넌트rules/coui-library-consumption.md §4 판정 질문 — 조합 대체 → 범용이면 CoUI 승격 후보 표시 후 도메인 위젯으로 구현 계속, 도메인 전용이면 도메인 위젯 — 차단 아님
체크리스트 반복 실패(2회)해당 섹션 실패 보고 + 나머지 산출 (전체 중단 금지)
  • cc-flutter:figma-to-coui · cc-coui:* — 구현 패턴·API SoT
  • cc-flutter:widgetbook-conventions · cc-flutter:figma-widgetbook-alignment · cc-flutter:golden-test-guide — Step 4 SoT
  • cc-bricks — 흡수 대상 구조(kobic 로스터)
  • rules/figma-workflow.md · rules/coui-library-consumption.md
  • /cc-blueprint:design (이전 단계) · /cc-blueprint:sync (다음 단계)