菜单
스크린샷(UI·HUD·이펙트·경쟁작)을 Vision 모델로 분석해 UI 구조·컬러 팔레트·구현 가이드를 만든다. 사용자가 화면 이미지를 첨부하거나 경쟁작 화면 분석을 요청할 때 사용한다.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | screenshot-analyze |
| description | 스크린샷(UI·HUD·이펙트·경쟁작)을 Vision 모델로 분석해 UI 구조·컬러 팔레트·구현 가이드를 만든다. 사용자가 화면 이미지를 첨부하거나 경쟁작 화면 분석을 요청할 때 사용한다. |
| context | fork |
| model | sonnet |
역할: 당신은 게임/웹/앱 스크린샷을 Gemini Vision으로 분석하여 UI 구조와 구현 가이드를 생성하는 시각 분석 전문가입니다. 컨텍스트: 정적 이미지(게임 UI, HUD, 이펙트 프레임, 경쟁작, 구현 검증) 분석이 필요할 때 호출됩니다. 출력: UI 구조·컬러 팔레트·구현 가이드를 5개 필수 요소로 구성된 마크다운 분석 보고서로 반환합니다.
스크린샷(게임/웹/앱)을 분석하여 UI 구조, 컬러 팔레트, 구현 가이드를 생성한다.
| 도구 | 입력 | 분석 대상 | 출력 |
|---|---|---|---|
/video-reference-guide | 동영상 (mp4/mov/YouTube) | 타이밍, 연출 시퀀스, 모션 | 타임스탬프별 연출 테이블 |
| 이 스킬 | 정적 이미지 (png/jpg/클립보드) | 레이아웃, 컬러, 컴포넌트 구조, 아이콘 | UI/레이아웃 분석 테이블 |
/yt | YouTube (음성) | 강좌, 튜토리얼 내용 | 트랜스크립트 요약 |
| 유형 | 분석 포커스 | 출력 형태 |
|---|---|---|
| UI 레이아웃 | 화면 구성, 계층, 여백, 정렬 | Canvas 구조 테이블 + Anchor 가이드 |
| HUD 디자인 | 게임 중 표시 요소, 위치, 크기 | Safe Area 분석 + 정보 밀도 평가 |
| 아이콘/에셋 | 아이콘 스타일, 크기, 컬러 팔레트 | 아트 디렉션 + Sprite 규격 |
| 이펙트 프레임 | 정지 상태 이펙트 분석 | 파티클 방향, 블렌딩 모드, 레이어 |
| 경쟁작 비교 | A사 vs B사 동일 화면 비교 | 레이아웃 차이, UX 패턴 비교표 |
| 구현 검증 | 구현 스크린샷 vs 레퍼런스 비교 | 일치도 점수 + 개선 항목 |
| 스타일 추출 | 5-10개 에셋에서 공통 스타일 추출 | style-guide.md 자동 생성 |
| 일관성 검증 | 다수 에셋의 크로스 에셋 일관성 | 일관성 점수 + 불일치 에셋 식별 |
사용자가 아래 중 하나를 제공한다:
/clip 스킬로 캡처 후 전달출력 첫 줄에 모드와 플랫폼을 선언한다:
**분석 모드**: [기본 모드 / Task Doc 모드 / 시안 분석 모드 / 구현 검증 모드 / 컴포넌트 추출 모드]
**플랫폼**: [Game (Unity) / Web (HTML/CSS) / App (Mobile Native)]
모드 판별:
├─ `--extract` 플래그 또는 "분리해줘 / 추출해줘 / 컴포넌트 뽑아줘" 언급 → 컴포넌트 추출 모드
├─ `--mockup` 옵션 또는 _assets/ 경로의 우리 시안 → 시안 분석 모드 (확정값)
├─ Element Task Doc 작성 중 → Task Doc 모드 (추정값)
├─ 구현 검증 (레퍼런스 vs 구현 비교) → 구현 검증 모드
└─ 그 외 (경쟁작, 일반 참고) → 기본 모드 (추정값)
플랫폼 자동 감지:
├─ GodBlade 프로젝트 컨텍스트 또는 사용자 명시 → Game (Unity)
├─ Portfolio 프로젝트 컨텍스트 또는 웹사이트 URL → Web (HTML/CSS)
├─ 앱스토어 스크린샷 또는 모바일 UI → App (Mobile Native)
└─ 판단 불가 → 이미지 내용으로 추정 (브라우저 크롬 → Web, 게임 HUD → Game)
입력 추출:
- IMAGE_PATH: 이미지 경로 (여러 장이면 공백 구분)
- ANALYSIS_TYPE: 분석 유형 (기본: "UI 레이아웃")
- REF_NAME: 레퍼런스 이름 (파일명 또는 사용자 지정)
- PLATFORM: 플랫폼 (자동 감지 또는 사용자 지정)
- EXTRACT_MODE: 컴포넌트 추출 모드 여부 (true/false)
핵심 원칙: MUST 출력 형식을 Gemini 프롬프트에 직접 포함한다. 스킬 문서의 출력 규격과 Gemini에 보내는 프롬프트가 일치해야 한다.
모델:
--extract모드 →GEMINI_MODEL=gemini-3.1-pro-preview고정 (정밀도 최우선) 기본 분석 →gemini-3.5-flash(기존 유지)
모든 분석 유형에 공통으로 포함되는 분해 규칙 블록:
## 분해 규칙 (필수 — 모든 분석에 적용)
1. 모든 시각 요소를 "고유 컴포넌트" 단위로 분해한다
2. 같은 디자인의 요소가 N개 반복되면 → 고유 컴포넌트 1개 + "반복: N개" 표기
3. 서로 다른 디자인의 요소가 N개면 → 각각 별도 고유 컴포넌트로 분해
4. 배경, 버튼, 텍스트, 아이콘, 구분선, 컨테이너, 이미지를 모두 분해
5. 요소가 서로 겹쳐(overlap) 있어도 각각 독립 컴포넌트로 분해 — Z-order(레이어 순서) 표기
6. 반투명 오버레이, 그림자, 글로우 등 시각 효과도 별도 컴포넌트로 분해
7. 모든 색상은 #RRGGBB Hex로 표기 (자연어 색상명만 쓰면 FAIL)
## 필수 출력 형식 (3개 테이블 + 1트리 + 1가이드)
### 1. 컴포넌트 분해 테이블
| # | 컴포넌트명 | 타입 | 반복 | Z순서 | 크기 (비율) | 색상 (Hex) | 텍스트 | 구현 노트 |
> 타입: Background, Container, Button, Text, Icon, Image, Divider, Overlay, Effect, ScrollView
> 겹치는 요소도 각각 분리. Z순서로 레이어 표기.
### 2. 컬러 팔레트 (최소 3색)
| # | 용도 | Hex | 사용 컴포넌트 | 토큰명 |
> 토큰명: --color-{용도}, --space-{크기}, --font-{레벨} 패턴
### 3. Prefab 계층 트리
Canvas (Screen Space - Overlay)
├── [컴포넌트] ([타입]) — [색상], [Anchor]
└── ...
> 컴포넌트 분해 테이블의 모든 요소가 트리에 포함되어야 함
### 4. 구현 가이드
- Canvas 설정 추정
- 주요 Anchor/Layout 추정
- 주의사항 (추정값에 (추정) 태그)
분석 유형별 프롬프트 (위 공통 블록 + 아래 유형별 지시):
UI 레이아웃 분석 (기본) — 플랫폼별 분기:
Game (Unity):
다음 스크린샷의 UI를 개별 컴포넌트로 분해해주세요.
{공통 분해 규칙 블록}
+ Unity UGUI 구현 방법(Canvas 설정, Layout Group, Anchor)을 구현 가이드에 포함해주세요.
Web (HTML/CSS):
다음 스크린샷의 UI를 개별 컴포넌트로 분해해주세요.
{공통 분해 규칙 블록}
+ 구현 가이드에 아래를 포함해주세요:
- HTML 시맨틱 태그 구조 (header, nav, main, section, aside, footer)
- CSS 레이아웃 방식 (Flexbox/Grid 추천)
- 반응형 breakpoint 추정 (mobile/tablet/desktop)
- Tailwind CSS 유틸리티 클래스 제안
- React 컴포넌트 분리 제안
App (Mobile Native):
다음 스크린샷의 UI를 개별 컴포넌트로 분해해주세요.
{공통 분해 규칙 블록}
+ 구현 가이드에 아래를 포함해주세요:
- 네비게이션 패턴 (Tab Bar, Drawer, Stack)
- Safe Area / Status Bar 처리
- 터치 타겟 크기 (최소 44pt)
- 플랫폼 디자인 가이드라인 준수 여부 (HIG/Material)
HUD 분석:
다음 게임 스크린샷에서 HUD(Head-Up Display) 요소를 분석해주세요.
{공통 분해 규칙 블록}
추가 요구:
- 각 HUD 요소의 Safe Area 기준 위치
- 가독성 평가 (대비 비율, 폰트 크기 추정)
- Unity Canvas Scaler 설정과 Anchor Preset 제안
아이콘/에셋 분석:
다음 스크린샷에서 아이콘과 시각 에셋을 분석해주세요.
{공통 분해 규칙 블록}
추가 요구:
- 아이콘 스타일(플랫/스큐어모픽/아웃라인)
- 크기 규격(px 추정)
- 아트 디렉션 키워드
- Sprite Atlas 구성 제안
이펙트 프레임 분석:
다음 스크린샷에서 시각 이펙트(파티클, 글로우, 블러 등)를 분석해주세요.
{공통 분해 규칙 블록}
추가 요구:
- 이펙트 방향, 블렌딩 모드(추정), 강도
- Unity Particle System 또는 Shader Graph 재현 방법
경쟁작 비교:
다음 스크린샷들을 비교 분석해주세요.
{공통 분해 규칙 블록}
추가 요구:
- 레이아웃 구조, 정보 배치, 컬러 사용, UX 패턴의 차이점과 공통점
- 각 접근법의 장단점 평가
구현 검증:
다음 두 스크린샷을 비교해주세요.
첫 번째는 레퍼런스(목표), 두 번째는 실제 구현 결과입니다.
비교 항목:
1. 레이아웃 일치도 (위치, 크기, 비율)
2. 컬러/스타일 일치도
3. 누락된 요소
4. 추가된 요소 (의도적 변경인지 누락인지)
5. 전체 완성도 점수 (1-10)
6. 개선 필요 항목
출력 형식:
| 항목 | 레퍼런스 | 구현 | 일치도 | 비고 |
컴포넌트 추출 모드 전용 — bbox JSON 추가 지시 블록 (--extract 시 공통 분해 규칙 블록 뒤에 추가):
## 컴포넌트 추출 JSON (필수)
분석 결과 마지막에 아래 형식의 JSON 코드블록을 반드시 포함하라.
규칙:
1. bbox는 이미지 전체 크기 대비 정규화 좌표 (0.0~1.0)
2. bbox는 반드시 컴포넌트를 완전히 포함해야 한다 — 엣지 클리핑(잘림) 절대 금지
3. 인접한 다른 컴포넌트 영역을 침범하지 않는다 (형제 컴포넌트 겹침 최소화)
4. Background 타입은 반드시 {"x":0,"y":0,"w":1.0,"h":1.0}
5. id는 타입 접두어 사용: bg_*, btn_*, icon_*, overlay_*, text_*, img_*
6. 최대 50개 고유 컴포넌트
```json
{
"components": [
{
"id": "bg_main",
"name": "메인 배경",
"type": "Background",
"bbox": {"x": 0.0, "y": 0.0, "w": 1.0, "h": 1.0},
"z_order": 0
},
{
"id": "btn_attack",
"name": "공격 버튼",
"type": "Button",
"bbox": {"x": 0.72, "y": 0.80, "w": 0.20, "h": 0.08},
"z_order": 3
},
{
"id": "icon_hp",
"name": "HP 아이콘",
"type": "Icon",
"bbox": {"x": 0.05, "y": 0.04, "w": 0.06, "h": 0.06},
"z_order": 2
}
]
}
**컴포넌트 추출 모드 — Agent Teams 실행 구조**:
[오케스트레이터 — Sonnet]
Pass 1 (병렬): ├─ [Analyzer Agent × N] (gemini-3.1-pro-preview) │ → 이미지 N장 동시 분석, 각각 초안 bbox JSON 생성 └─ [OverlapDetector] (내부 처리) → bbox 취합 후 형제 IoU 사전 검사
Pass 2 — 정밀 검증 (병렬, CRITICAL): └─ [Verifier Agent × M] (gemini-3.1-pro-preview) → 각 초안 bbox 크롭을 Gemini 재전송 → 질문: "이 컴포넌트가 완전히 포함됐는가? 잘린 부분이 있는가?" → 잘림 감지 시: 확장 방향(상/하/좌/우) + 확장량(px) 반환 → bbox 보정
병렬 실행: ├─ [Extractor Agent] (Sonnet) → 보정 bbox → extract-components.py 실행 └─ [Evaluator Agent] (내부) → 루브릭 5항목 자기평가
### Step 3: 분석 실행
`analyze-screenshot.sh`를 호출하여 Gemini Vision API 분석을 실행한다.
**단일 이미지 분석:**
```bash
bash ~/.claude/scripts/analyze-screenshot.sh \
"{IMAGE_PATH}" \
"docs/assets/screenshot-refs/{YYYY-MM-DD}-{REF_NAME}-analysis.md" \
"{Step 2에서 조립한 전체 프롬프트 — 공통 블록 포함}"
멀티 이미지 비교 분석 (경쟁작 비교, 구현 검증):
bash ~/.claude/scripts/analyze-screenshot.sh \
"{IMAGE1_PATH}" \
"docs/assets/screenshot-refs/{YYYY-MM-DD}-{REF_NAME}-compare.md" \
"{비교 분석 프롬프트}" \
"{IMAGE2_PATH}" \
"{IMAGE3_PATH}" # 선택
멀티 이미지: 2-3장을 한 번의 API 호출로 Gemini에 전송하여 직접 비교. 기존 순차 분석 → 텍스트 비교 대비 정확도와 일관성 향상.
모델 선택 (환경변수 GEMINI_MODEL):
# 기본: gemini-3.5-flash (빠르고 저렴)
# 고품질: gemini-2.5-pro (정밀 분해, 복잡한 UI)
GEMINI_MODEL=gemini-2.5-pro bash ~/.claude/scripts/analyze-screenshot.sh ...
Pass 1 분석 완료 후, Pass 2 Verifier와 Extractor를 Agent Teams로 병렬 실행한다.
Pass 2 — Verifier (각 컴포넌트 병렬, gemini-3.1-pro-preview):
각 컴포넌트 bbox로 원본 이미지를 임시 크롭 → Gemini 재전송:
# 임시 크롭 생성
python3 -c "
from PIL import Image
img = Image.open('{IMAGE_PATH}')
w,h = img.size
bbox = {bbox_dict}
left = int(bbox['x']*w); top = int(bbox['y']*h)
right = int((bbox['x']+bbox['w'])*w); bottom = int((bbox['y']+bbox['h'])*h)
img.crop((left,top,right,bottom)).save('/tmp/verify_{comp_id}.png')
"
# Gemini 재확인
GEMINI_MODEL=gemini-3.1-pro-preview bash ~/.claude/scripts/analyze-screenshot.sh \
"/tmp/verify_{comp_id}.png" \
"" \
"이 이미지에서 '{comp_name}'({comp_type}) 컴포넌트가 완전히 포함되어 있는가?
잘린 부분(엣지 클리핑)이 있으면 JSON으로 응답:
{\"clipped\": true, \"expand\": {\"top\": 0, \"bottom\": 0, \"left\": 0, \"right\": 0}}
잘림 없으면: {\"clipped\": false}"
잘림 감지 시 bbox를 expand 값만큼 원본 이미지 기준으로 보정 후 재크롭.
Extractor (Verifier 완료 후 즉시, Sonnet):
GEMINI_MODEL=gemini-3.1-pro-preview \
python3 ~/.claude/scripts/extract-components.py \
--image "{IMAGE_PATH}" \
--analysis "{ANALYSIS_MD_PATH}" \
--output "docs/assets/screenshot-refs/{YYYY-MM-DD}-{REF_NAME}-components"
Kill Conditions:
Canary:
🟢 Green = 루브릭 5항목 PASS (커버리지≥60% / 컴포넌트 2~50 / 크기≥16px / 파일정상 / 중복없음)
🟡 Yellow = 1~2항목 WARN
🔴 Red = bbox JSON 없음 OR 추출 0개
Gemini 응답에서 아래 5개 필수 요소를 검증한다. 하나라도 누락되면 해당 섹션을 AI가 직접 보완한다.
| # | 필수 요소 | 검증 기준 |
|---|---|---|
| 1 | 컴포넌트 분해 테이블 | 마크다운 테이블, 최소 5행 |
| 2 | 컬러 팔레트 | #RRGGBB Hex 최소 3색 |
| 3 | Prefab 계층 트리 | 트리 구조 코드 블록 |
| 4 | 구현 가이드 | Canvas/Anchor 설정 포함 |
| 5 | (추정)/(확정) 태그 | 모든 추정값에 태그 |
--extract 모드 추가 검증 (루브릭 5항목):
| # | 항목 | PASS 기준 | FAIL 시 |
|---|---|---|---|
| 1 | bbox JSON | json {"components":[...]} 블록 존재 | 재프롬프트 1회 → 없으면 폴백 |
| 2 | bbox 커버리지 | 컴포넌트 면적 합계 ≥ 화면 60% | 누락 컴포넌트 경고 |
| 3 | 컴포넌트 수 | 2 ≤ N ≤ 50 | 0~1: 재시도 / 51+: 상위 50개 |
| 4 | 파일 생성 | 추출 PNG 정상 저장 | 실패 목록 출력 |
| 5 | 겹침 상태 | _overlap-report.json GREEN | YELLOW/RED 경고 출력 |
기본 모드: 위 5개 요소를 순서대로 출력
시안 분석 모드 (--mockup): 모든 값을 (확정) 태그로 추출
추가 출력:
| 시안 경로 | 시안 내 요소 | 매핑 대상 섹션 | 매핑 파라미터 | 확정값 |
|---|
| 요소 | 토큰명 | 값 | 출처 |
|---|
토큰명: 프로젝트
style-guide.md기존 토큰 매칭 우선. 없으면--color-{용도}패턴.
트리 구조 + 컴포넌트 테이블 (기본 모드와 동일 형식, 값은 (확정))
Task Doc 모드: Element Task Doc 섹션 형식으로 직접 출력 (경쟁작/참고 자료 — 추정값):
UI 프레임워크: [분석에서 감지된 프레임워크, 예: uGUI / NGUI]
Canvas (Screen Space - Overlay)
├── [관찰된 영역 A] (RectTransform) — [위치 설명]
│ ├── [자식 요소] ([컴포넌트 추정]) — [역할]
│ └── ...
| 오브젝트 | 컴포넌트 (추정) | 역할 | Anchor 추정 | Pivot 추정 | 비고 |
|---|
| 요소 | 토큰명 | 값 | 출처 |
|---|
토큰명:
--color-{용도},--space-{크기},--font-{레벨}패턴.
| 레퍼런스 유형 | 원본 경로 | 참고 구간 | 적용 대상 | 분석 결과 요약 |
|---|
docs/assets/screenshot-refs/에 분석 파일 저장docs/assets/screenshot-refs/{YYYY-MM-DD}-{REF_NAME}-components/
├── _manifest.json ← 컴포넌트 메타데이터 + 픽셀 bbox
├── _overlap-report.json ← IoU 겹침 경고 + 상태(GREEN/YELLOW/RED)
├── backgrounds/ bg_*.png
├── buttons/ btn_*.png
├── icons/ icon_*.png
├── overlays/ overlay_*.png
├── text/ text_*.png
├── images/ img_*.png
├── containers/ container_*.png
└── etc/ 기타
_manifest.json 경로를 game-asset-generate 스킬에 전달 가능
(추출된 컴포넌트를 에셋 생성 레퍼런스로 바로 활용)| Phase | 사용 시점 | 행동 |
|---|---|---|
| S3 (GDD) | 6.3 UI/UX 가이드, 3.3 화면 상세 | 경쟁작 UI 비교 분석 |
| S4 (UI/UX 기획서) | 와이어프레임 + 레퍼런스 | 레퍼런스 분석 → 기획서에 삽입 |
| Trine Phase 2 (Spec) | Section 9.5 UI 상태 | 목업/스크린샷 기반 UI 구조 정의 |
| Phase 2 (Element Task Doc) | Complex UI 요소 상세 명세 시 | 스크린샷 분석 (Task Doc 모드) → Section 7 + 10 + 16 직접 출력 |
| Trine Phase 3 (구현) | 구현 시 레퍼런스 참조 | 분석 파일 재참조 |
| Trine Phase 3 (역비교) | 구현 완료 후 Check 3 PASS 후 | 구현 스크린샷 vs 레퍼런스 비교 (구현 검증 모드) |
/style-train 스킬에서 호출되는 전용 모드. 5-10개 기존 에셋에서 공통 시각 패턴을 추출한다.
분석 항목:
출력: style-guide-template.md 형식에 맞춘 초안
에셋 5개 이상이 생성된 후, 전체를 컴포지트 이미지로 배치하여 "같은 프로젝트의 에셋으로 보이는가?"를 검증한다.
검증 항목:
출력: 일관성 점수 (High/Medium/Low) + 불일치 에셋 목록
에셋 생성 후 4항목 자동 검증:
ai-anti-patterns.md 항목에 해당하지 않는가?GEMINI_API_KEY 환경변수 설정 필수~/.claude/scripts/analyze-screenshot.sh 스크립트 존재이 스킬은 이미지 전체를 base64로 인코딩하여 Google Gemini API로 전송한다. 아래 유형의 이미지는 전송 전 확인이 필요하다:
| 주의 대상 | 이유 | 대안 |
|---|---|---|
| 미공개 게임/앱 기능 스크린샷 | 사전 공개 위험 | 출시 후 또는 공개 베타 버전만 사용 |
| 경쟁사 NDA 적용 베타 화면 | 제3자 정보 무단 전송 | 공식 스토어/사이트 스크린샷만 사용 |
| PII가 포함된 화면 | 개인정보 유출 | 캡처 전 민감 정보 마스킹 처리 |
권장: 경쟁사 분석에는 App Store, Google Play, 공식 웹사이트의 공개 스크린샷만 활용한다.
병렬/다단계 실행 = Workflow 도구로 컨텍스트 격리 + resume 지원. 패턴: Codex Vision→Gemini fallback.
실행: Workflow({ script: Bash("cat ~/.claude/skills/screenshot-analyze/workflow.js"), args: { imagePath, intent, crMode } })
CLAUDE_CODE_DISABLE_WORKFLOWS=1 시 기존 방식 fallback.
--cr 옵션 (crMode)Codex Vision 사용 여부를 제어한다. caller는 ~/forge/shared/scripts/cr-mode.sh 조회 후 args.crMode로 전달한다.
| 값 | 동작 |
|---|---|
on (기본) | Codex Vision primary → Gemini fallback (현재 동작) |
degrade | Codex Vision 스킵 → Gemini Vision 직행 |
off | Codex Vision 스킵 → Gemini Vision 직행 |
로그: [cr] screenshot Codex Vision skipped (crMode=<value>) → Gemini
⚠️ Phase 0 전제: Codex/Gemini Vision용 approve-worker 토큰 외부 선발행 필수 (Workflow는 셸 직접 호출 불가).
Multi-worker 검수 스킬 (Codex + Gemini Double / Opus + Codex + Gemini Triple). 단일 Codex 검수 대비 100% 보완 카테고리 커버. 트리거: /cr-multi, /cr-double, /cr-triple, plan/spec 저장 후 자동(CR_MULTI_AUTO=on), plateau 3회 자동 승격.
Forge 하네스 읽기전용 레거시 감사: 낡은룰/중복/과대 전역컨텍스트/넓은 Skill/불필요 Hook·MCP/제품중복 분류. 트리거: /harness-legacy-scan
YouTube 영상을 트랜스크립트·댓글·설명란까지 수집해 비판적 분석·팩트체크·시스템 개선 제안을 생성한다. 사용자가 YouTube URL을 보내거나 영상 분석을 요청할 때 사용한다.
REST API 엔드포인트 HTTP 레벨 E2E 자동 테스트. Spec 또는 OpenAPI(Swagger) YAML/JSON을 읽어 엔드포인트별 테스트 케이스(happy path/인증 실패/잘못된 입력/경계값)를 자동 생성하고 curl로 실행한다. 응답 스키마를 OpenAPI 스펙과 대조해 드리프트를 감지한다. /qa 스킬이 서버/API 프로젝트 감지 시 자동 트리거. 직접 호출: /api-e2e <spec-path> [--base-url http://localhost:3000]
기획서를 CEO(비즈니스)→Design(UX)→Engineering(기술) 3관점 순차 리뷰 + Synthesizer 종합 + 독립 Evaluator 검증(5-Wave)하는 스킬. Phase 3 에이전트 회의 후 자동 트리거. (적대적 Codex 검수는 cr-triple/codex-review 별도 게이트.)
PR 생성 전 develop 대비 feature 브랜치의 성능을 비교하는 스킬. 번들 크기, 테스트 시간, API 응답 시간을 측정. P7 PR 생성 전 자동 트리거.