워크플로우 가이드
제품 기획, Figma 디자인, 화면 구현, 개발과 검증까지 하려는 일에 맞는 시작점
만들려는 결과를 기준으로 시작점을 고르세요. 스킬은 작업 방법을 담은 문서이고, 명령은 여러 단계를 시작하는 진입점입니다. 아래 슬래시 명령은 터미널이 아닌 AI 채팅에 입력합니다. Codex처럼 Claude 전용 명령을 등록하지 않는 환경에서는 같은 이름의 스킬을 지정해 요청하세요. OpenCode 명령 이름은 대표 명령에서 확인할 수 있습니다.
어디서 시작할까요?#
| 지금 필요한 결과 | 시작점 | 확인할 산출물 |
|---|---|---|
| 아이디어에서 실행 가능한 제품까지 | 제품 제작 자동화 | PRD, Figma, 프로젝트, 화면과 배포 기록 |
| 제품의 요구사항과 개발 계획 | 제품 기획 | PRD, 기술 명세, 동작 시나리오 |
| Figma 시안과 구현 화면 | Blueprint | 화면 레지스트리, 기능모듈, Widgetbook, 대조 결과 |
| 기존 제품의 기능 개발·수정 | 개발 사이클 | 이슈, 변경 코드, 검사 결과, PR |
| 코드 품질·실행 중인 앱 진단 | 코드 리뷰 · Inspector | 문제 목록, 재현·진단 근거 |
| 화면 문구·공개 콘텐츠 개선 | 제품 라이팅 | 실제 기능에 맞는 문구와 반영·검증 결과 |
도구를 고르기 어렵다면 cocode-compass 스킬에 하려는 일을 설명하고,
추천한 진입점과 필요한 플러그인을 확인하세요. 설치와 첫 실행부터 시작해도 됩니다.
아이디어에서 제품까지#
cc-product-auto는 요구사항과 기획 파일을 받아 PRD → CoUI Figma 디자인 → 프로젝트 조립 → 화면 개발 → 웹 배포로 이어갑니다. 진행 상태와 증거를 남기므로 중단된 작업을 다시 이어갈 수 있습니다.
/cc-product-auto:run "만들려는 서비스와 사용자를 설명해줘" --files ./brief.pdf
/cc-product-auto:status --run-dir ./runs/my-product
/cc-product-auto:resume --run-dir ./runs/my-product
./brief.pdf와 ./runs/my-product는 예시 경로입니다. 실제 기획 파일과 실행 폴더로 바꾸세요.
Figma·GitHub 권한, SDK와 프로젝트 생성 도구가 필요합니다. 실행 전 점검 결과에 따라 준비하세요.
프리뷰와 실제 API 연결 모드는 요구사항에 맞게 선택하며, 배포 URL과 런타임 확인 기록으로 결과를 확인합니다.
기획 단계만 정리하고 싶다면 cc-product를 사용하세요. 조사·요구사항·계획·디자인·개발·출시를 단계별로 다룹니다.
Figma에서 화면 코드까지#
cc-blueprint의 세 명령은 서로 다른 결과를 만듭니다.
- design: 확정된 기획을 CoUI 라이브러리 인스턴스로 조립해 Figma 시안과 화면 레지스트리를 만듭니다.
- build: 등록된 프레임을 화면 모듈로 구현하고 Widgetbook·골든 스냅샷·Figma 대조 결과를 남깁니다.
- sync: Figma 레지스트리와 Widgetbook을 대조해 누락되거나 어긋난 화면과 재작업 목록을 찾습니다.
/cc-blueprint:design
/cc-blueprint:build
/cc-blueprint:sync
이미 시안이 있으면 build에서 시작합니다. 화면만 검증하는 단계에서는 mock과 도메인 계약을 사용하고,
백엔드 연결은 별도 작업으로 진행합니다. 구현된 화면의 픽셀 수렴은 cc-pixel-loop,
공용 라이브러리 동기화는 cc-coui-sync,
앱의 CoUI 버전 갱신은 cc-coui-upgrade를 확인하세요.
디자인 토큰과 컴포넌트 API는 CoUI 문서, 디자인 판단 기준은 cc-designer에서 찾을 수 있습니다.
기존 제품의 개발 작업#
cc-dev는 자연어 작업 요청을 이슈·구현·검사·PR로 연결합니다.
go는 작업 계획을 정리하는 원스톱 진입점이고, 이미 있는 작업 카드로 시작할 때는 run을 사용할 수 있습니다.
/cc-dev:go "검색 결과가 없을 때 안내 화면을 추가해줘"
/cc-dev:run 1234
1234는 실제 작업 카드 번호로 바꾸세요. 저장소·이슈 도구 접근 권한과
프로젝트의 빌드·검사 환경을 먼저 준비합니다. 계획·승인·병합 조건은 각 명령의 최신 절차를 따릅니다.
새 Flutter 기능의 뼈대가 필요하면 feature:create를 참고하세요.
코드와 실행 결과 검증#
코드 리뷰, 테스트 생성, 실행 중인 앱 진단은 각각 확인하는 대상이 다릅니다.
| 확인하려는 것 | 도구 | 사용 시점 |
|---|---|---|
| 코드의 구조·보안·성능·테스트 누락 | cc-quality | 변경 코드를 검토할 때 |
| 단위·BLoC·위젯·BDD 테스트 | cc-flutter:test | 요구한 동작을 검사하는 코드를 만들 때 |
| 실행 중인 앱의 상태·네트워크·UI | cc-inspector | 실제 앱의 증상을 진단할 때 |
| 탐색에서 E2E 시나리오와 Patrol까지 | cc-e2e | 사용자 흐름을 자동 검사로 고정할 때 |
| 렌더된 화면과 Figma의 차이 | cc-pixel-loop | 디자인과 구현 화면을 대조할 때 |
| 앱 내부의 동작과 도구 | cc-marionette · cc-mcp-toolkit | 실행 중인 Flutter 앱을 조작·검사할 때 |
/cc-quality:review
/cc-inspector:inspector "로그인 이후 화면 이동이 멈춰"런타임 도구는 실행 중인 앱과 해당 MCP 연결이 필요합니다. 코드 검사 통과와 실제 화면·배포 검증은 각각의 증거를 확인하세요.
필요한 기능만 더하기#
- 앱·웹 개발: Flutter, Jaspr, CoUI, 브릭과 프로젝트 생성
- 서버·인프라: Serverpod, ClickHouse, AWS
- 제품 문구·운영: 라이팅, 국제화, 용역 정산, NotebookLM
- 프레임워크 지식: Flutter 레퍼런스, Serverpod 레퍼런스
설치 안내에서 경량 프리셋이나 개별 플러그인을 고르고, 전체 카탈로그에서 사용 조건과 상세 문서를 확인하세요.