/cc-designer:decide — 디자인 판단을 물어보지 않고 끝내기

디자인 판단을 되묻지 않고 확정합니다 — 근거 사다리(스펙→시안→코드 선례→디자인 시스템→정량 기준)로 결론을 내고 DDR 기록을 남깁니다.

항목	내용
실행 명령	`/cc-designer:decide`
난이도	●●○ 보통
인자	[질문 — 예: '실패 알림을 토스트로 할까 배너로 할까' 또는 '쿠폰 코드 자릿수 통일 기준']

한마디로#

"이건 디자이너한테 물어봐야 하나?" 싶은 디자인 판단을 던지면, 근거를 순서대로 찾아 결론 하나와 **왜 그렇게 정했는지 5줄 기록(DDR)**을 돌려주는 명령입니다. 되돌리기 어려운 것과 브랜드·법적 사안만 사람에게 올립니다.

누가·언제 쓰나요#

작업 중 디자인 판단에 걸렸지만 기획서·시안에 답이 없을 때
QA에서 "두 화면이 서로 다르게 동작한다"를 발견하고 어느 쪽으로 통일할지 정해야 할 때
자동 파이프라인(/cc-dev:run, /cc-dev:go)이 내부적으로 호출합니다 — 사람이 직접 부르는 것은 단건 확인용입니다

무엇을 해주나요#

질문을 한 문장으로 좁히고, 어떤 종류의 디자인 결정인지 분류합니다.
근거를 위에서부터 찾습니다: 확정 스펙 → 디자인 시안 → 우리 코드가 이미 하고 있는 방식(전수 조사) → 디자인 시스템 지식 → 업계 정량 기준(대비 4.5:1, 44dp, 400ms 등).
결론 하나를 내고, 기각한 대안·되돌리는 방법·확신 정도까지 적은 DDR을 남깁니다.
여러 질문을 한 번에 넘기면 각각 독립 DDR로 처리합니다.
브랜드 정체성·법적 정책·비가역 변경·스펙 충돌 4가지만 권고안과 함께 사람에게 올립니다.

어떻게 쓰나요#

# 단건 — 결정 + DDR 출력 (기본은 기록까지 저장)
/cc-designer:decide "권한 부족으로 생성 실패했을 때 토스트인가 인라인 배너인가"

# 스코프를 지정해 누적 로그 위치를 고정
/cc-designer:decide "쿠폰 코드 자릿수 통일 기준" --scope console-coupon

# 여러 건을 한 번에 (QA 결과 목록 등)
/cc-designer:decide --batch .claude/docs/console-qa/open-questions.md

# 파이프라인 인라인용 — 한 줄 결론만
/cc-designer:decide "빈 목록 문구" --brief

# 기록 없이 판단만 (탐색용)
/cc-designer:decide "다크 모드 카드 elevation" --no-record

옵션	기본값	설명
`--scope <name>`	변경 파일에서 추론	DDR 누적 로그 위치 (`.claude/docs/{scope}/design-decisions.md`)
`--batch <path\|목록>`	off	여러 질문을 각각 독립 DDR로 처리
`--brief`	off	DDR 전문 대신 한 줄 결론(+R번호)만 출력 — 파이프라인 인라인용
`--no-record`	off	파일에 남기지 않고 출력만 (탐색·검토용)
`--record <path>`	위 기본 경로	누적 로그 경로 직접 지정

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Design Principle#

이 커맨드는 design-decision 스킬의 명시 호출 래퍼다. 판정 로직(근거 사다리 R0~R5, 유형 라우팅, 에스컬레이션 4종, DDR 포맷)은 전부 그 스킬이 SoT 이며 여기 복제하지 않는다. 이 커맨드가 추가하는 것은 ① 입력 정규화 ② 배치 처리 ③ 기록 위치 결정 ④ 출력 형식뿐이다.

Steps#

질문 정규화 — 인자를 결정 질문 한 문장으로 좁힌다. 먼저 design-decision 의 "반사 판정" 표대로 cc-dev:jev-reflex 에 묻는다(질문 문장은 파일로 — --field-file question=…, 세트 ${CLAUDE_PLUGIN_ROOT}/skills/design-decision/jev/design-question.json). 두 결정이 섞여 있으면 분리해 각각 처리하고 (--batch 와 동일 경로) 쪼갠 질문마다 다시 묻는다. 질문이 "이미 정한 디자인을 무엇으로 만들지"(컴포넌트/파라미터 선택)이면 이 커맨드가 아니라 cc-coui(coui-index)로 라우팅하고 그 사실을 알린다 — Jev 의 component_implementation 은 힌트이고 Claude 가 확인한다. 이때도 에스컬레이션 문항이 true 면 4단계를 건너뛰지 않는다.
유형 분류 — design-decision 의 T1~T9 라우팅 표로 1차 스킬을 고른다. 1단계의 반사 판정 question_type 이 reflex 면 그것을 쓰고, 아니면 표로 판단한다.
근거 사다리 실행 — R0→R5. 각 칸의 조사는 실제로 수행한다:
- R0: docs/seed-spec-*.md 중 LOCKED, 이슈 AC
- R1: .claude/docs/{scope}/figma_analysis.md, Figma URL
- R2: 동일 판단 지점 전수 조사 (Grep/Glob), CoUI 기본값, 디자인 토큰, 기존 .claude/docs/*/design-decisions.md 누적 DDR, 용어 사전(용어 질문 — 위치는 ia-controlled-vocabulary 6절), 분류 정의서(구조 질문 — ia-taxonomy 7절)
- R3: 2단계에서 고른 cc-designer 스킬 적용
- R4: 정량 기본값 표
- R5: 가역성 타이브레이크 → 신뢰도: low 최초로 답을 주는 칸에서 멈춘다. R2 를 건너뛴 결정은 무효로 간주하고 재실행한다.
에스컬레이션 판정 — 브랜드 정체성 / 법·정책 / 비가역 / R0 충돌 4종만 AskUserQuestion. 그 외에는 묻지 않는다. 올릴 때도 권고안 1개 + 근거를 먼저 제시한다. 1~3은 1단계 반사 판정의 esc_*, 4는 스펙 요구 한 줄과 시안 설명이 둘 다 있을 때만 jev/spec-design-conflict.json 으로 먼저 묻는다 — 엄격화 전용: true 면 올리고, false 여도 Claude 가 해당한다고 보면 올린다. Jev 만 올린 것은 권고안에 종류·p 를 적는다.
DDR 작성 — 스킬의 DDR 포맷 그대로. 번호는 스코프 누적 로그의 마지막 번호 +1.
기록 — --no-record 가 아니면 누적 로그에 append 하고, T9 용어 결정이면 용어 사전 항목도 추가·갱신한다 (design-decision "기록 위치" 주석). 파이프라인 컨텍스트에서 호출된 경우 호출자가 PR body(prBodyExtras.designDecisions)·이슈 코멘트 반영을 담당한다.

Output#

기본 (단건):

DDR-04 · {결정문 한 줄}
- 질문 / 결정 / 근거(R번호+사실) / 기각한 대안 / 가역성 / 신뢰도
→ 기록: .claude/docs/{scope}/design-decisions.md

--brief:

DDR-04 {결정문} (R2: 선례 5/6)

--batch: 질문별 DDR 목록 + 말미 요약 표 (신뢰도 low 건수, 에스컬레이션 건수).

에스컬레이션 발생 시: 권고안·근거·되돌리기 비용을 먼저 출력한 뒤 확인 질문 1개.

design-decision 스킬 — 판정 로직 SoT (근거 사다리·유형 라우팅·DDR·에스컬레이션)
/cc-designer:critique-screen — 결정 반영 후의 사후 비평 (결정과 검수는 다른 층위)
/cc-dev:run Step 7.1 — 파이프라인 내부 호출 지점
cc-coui(coui-index) — "무엇으로 만들지"(컴포넌트 선택) 판단의 소관