designpaca/packages/skill/references/brief-interview.md

brief interview — 브리프를 인터뷰로 확정하는 법

0단계에서 SKILL.md의 인터뷰 게이트를 실제로 어떻게 수행하는지 정한 문서다. 게이트의 여섯 규칙은 여기서 바뀌지 않는다 — 이 문서는 그 규칙을 슬롯표, 질문 카드, 라운드, 기록 형식으로 구체화한다. 하네스별 질문 도구 이름과 한도는 harness.md를 따로 연다.

2단계 끝의 방향 체크포인트(§16)도 이 문서가 정한다. 인터뷰가 "무엇을 만들지"를 사용자에게 확인받는 자리라면, 방향 체크포인트는 "어떤 모습으로 만들지"를 구현 전에 확인받는 자리다. 납품 뒤 사용자가 불만을 말할 때의 절차는 feedback-loop.md에 있다.

이 문서를 읽는 법

상황	읽을 곳
왜 묻는지 근거가 필요하다	§1
무엇을 묻는가 — 슬롯과 경로별 차이, 경로 판정의 빈틈	§3 · §4 · §4-1
질문 카드를 쓴다, 스타일을 둘 이상 말했다(지배/보조)	§5 · §5-1 · §6
물은 뒤, 2라운드, "모르겠어요" 답	§7 · §8 · §8-1
답이 모순된다	§9
빈 답·비대화형·서브에이전트	§10 (정본은 harness.md §3)
"알아서 해줘"	§11 · §12
색 자산·좁은 화면 내비	§13 · §14
2단계 방향 카드를 만들고 고르게 한다	§16
기본 언어를 정한다	§17

1. 왜 인터뷰가 필수 입력인가

브리프가 비어 있는 채로 시작하면 그 빈칸을 메우는 것은 모델의 기본값이고, 기본값의 총합이 AI 슬롭이다. "합리적으로 추측했다"는 것은 안전장치가 아니다 — 추측은 카테고리 평균으로 수렴하고, 카테고리 평균은 어떤 브리프에도 들어맞는 대신 이 브리프에만 맞는 이유가 없다.

실측 사례 — "꽃집 홍보 사이트 하나 만들어보자"를 받고 업종 성격·목표 행동·톤·이름을 전부 혼자 정했다. 실제로 물어보니 넷 중 넷이 달랐다.

내가 가정한 것	사용자의 실제 답
일상 꽃 · 정기구독	하이엔드 플로럴 스튜디오
문의 유도 하나	문의 · 구독 · 방문 · 인스타 넷 다
(묻지 않음)	에디토리얼 · 잡지
(내가 지어냄)	목요일의 화원

이 상태로 1단계에 들어갔으면 레퍼런스 세 개를 전부 틀린 방향에서 골랐을 것이다. 가정한 네 축 중 하나도 맞지 않았다는 것은 "대개는 맞는다"는 전제 자체가 틀렸다는 뜻이다. 인터뷰는 판단으로 생략할 수 있는 예의가 아니라, 1단계 이후 전체 작업의 입력이다.

2. 스캔 → 가설 → 질문

순서는 항상 이렇다.

1. 스캔한다. design.md, 프로젝트 토큰, 브랜드 자산(로고·색·패키지), README·기존 문서를 먼저 읽는다.
2. 가설을 세운다. 스캔에서 읽은 값은 가설이지 사용자 승인이 아니다. 저장소에 "정기구독" 문구가 있다고 해서 그것이 사용자가 확정한 업종 성격은 아니다.
3. 질문한다. 가설은 질문의 추천 선택지로 제시해 확인받는다 — 추천 선택지는 항상 맨 앞에 두고 "(추천)" 표기를 붙인다. 근거(무엇을 읽고 이렇게 추천하는지)를 한 줄로 곁들인다. 스캔 근거가 없는 축에는 추천을 붙이지 않는다 — 근거 없는 추천은 모델의 기본 미학을 선택지 맨 앞에 올리는 일이다. 도구 설명이 영어 표기("(Recommended)")를 예로 들어도 표기는 사용자의 대화 언어를 따른다(SKILL.md 인터뷰 게이트 규칙 3).

스캔 결과를 사용자 확인 없이 바로 확정으로 쓰지 않는다. "코드에 이렇게 되어 있으니 그대로 갑니다"는 인터뷰를 생략하는 것이 아니라 인터뷰의 첫 단계일 뿐이다.

3. 브리프 슬롯

아래 표가 채워야 할 전부다. "알려진 사실"은 사용자 발화 또는 사용자가 준 자료에 명시된 것만 뜻한다. 업종 평균이나 코드에서 추론한 값은 확정이 아니라 2절의 가설이다.

슬롯	필수 조건	확정 기준	모를 때
무엇을 (산출물·범위)	항상	요청 문장	묻는다
누구에게·목표 행동 (복수면 우선순위)	전체·연장	사용자 발화	묻는다(multiSelect 후 우선순위 확인)
업종·성격	전체, 연장의 새 화면	사용자 발화·제공 문서	묻는다(스캔 결과는 추천 선택지로)
톤	전체. 연장은 design.md에 없을 때. 리디자인(방향 변경)은 design.md가 있어도	사용자 선택	묻는다(선택지마다 모션 강도·프리셋 영향을 적는다)
취향 앵커 (좋아하는 사이트·브랜드·잡지 1~3개, 피하고 싶은 느낌 하나)	전체. 선택 응답 — 비워 둬도 슬롯 미확정이 아니다	사용자 발화	따로 묻지 않는다. 자산 질문의 자유 답 칸에 함께 받는다(§6)
고유명사·실제 값	이번 작업이 새로 만들거나 바꾸는 고유명사·수치가 화면에 나오면	사용자 제공	묻고, 아직 없다고 하면 명시적 placeholder
기존 브랜드 자산 (색·로고·서체·쓸 수 있는 사진)	전체	파일 또는 사용자의 "없음"	묻는다
좁은 화면 내비	내비가 있는 다중 화면	정보 구조·라벨이 정해진 뒤	2라운드에서 묻는다
기본 언어	항상	§17의 판정 순서(명시 언어 → 프로젝트 로컬라이제이션 → 대화 언어 → OS 로케일)	넷 다 불명확하면 묻는다
스택·납품 형태	항상	프로젝트 파일(패키지 설정·프레임워크 설정) 또는 사용자 발화	파일로 확인되면 묻지 않는다. 빈 폴더면 "정적 HTML·CSS·JS, 빌드 없음"을 가정으로 브리프 카드에 밝히고, 자산 질문의 자유 답 칸에 "다른 스택이나 배포처가 정해져 있으면 적어 주세요"를 한 줄 얹는다. 질문 수는 늘리지 않는다
테마 (기본 테마·토글 유무)	다크모드가 요청됐거나 프로젝트에 이미 있을 때	사용자 발화·테마 파일	자산 질문의 자유 답 칸에 함께 받는다

슬롯이 "필수 조건"에 해당하는데 "확정 기준"을 사용자 발화·자료로 채우지 못했으면 묻는다. "결과를 크게 바꾸는가"를 스스로 판정해서 생략하지 않는다 — 그 판단은 이 표가 이미 대신 내렸다.

빈 폴더의 기본을 정적 파일로 두는 이유. 사용자가 열어 보기 가장 쉽고 되돌리기도 쉽다. 페이지가 다섯을 넘거나 CMS·라우팅·인증이 브리프에 있으면 그 사실을 근거로 프레임워크를 추천 선택지로 낸다. 스택은 5단계 검증 방법(정적이면 소스, 프레임워크면 빌드 결과)과 납품 안내까지 바꾸므로 가정이라도 밝혀 둔다.

취향 앵커를 선택 응답으로 두는 이유. 실제 크리에이티브 브리프에서 정보량이 가장 큰 답은 "이런 게 좋다 / 이렇게는 싫다"다. 톤 질문이 프리셋 다섯 개로만 받으면 결과가 프리셋의 실루엣으로 수렴한다(레드팀 06 실측: editorial 계열 6종이 같은 모양으로 수렴). 그렇다고 질문을 하나 더 늘리면 사용자가 지친다. 그래서 별도 질문을 만들지 않고 이미 있는 자유 답 칸에 한 줄을 얹는다. 답이 오면 1단계 R2(톤) 슬롯의 우선 후보로 쓰고, "피하고 싶은 느낌"은 2단계 반사실 점검과 방향 카드(§16)의 기각 조건으로 쓴다. 답이 없으면 묻지 않은 것과 같다 — 재질문하지 않는다.

4. 경로별 적용

경로	무엇을 묻는가
전체	슬롯 전부를 이 표의 조건대로 묻는다. 좁은 화면 내비는 정보 구조가 정해진 뒤 2라운드에서 묻는다.
전체(리디자인)	전체와 같다. design.md가 있어도 톤·업종 성격은 다시 묻는다 — 사용자가 바꾸려는 것이 바로 그 답일 수 있다. 기존 design.md의 답은 질문의 추천 선택지가 아니라 "현행" 선택지로 보여 준다.
연장	무엇을·목표 행동·고유명사·기본 언어는 전체와 같다. 업종·성격은 새 화면일 때만 묻는다. 톤은 design.md에 없을 때만 묻는다. 브랜드 자산은 design.md가 이미 답했으면 묻지 않는다. 정리·일관화 요청이면 현행 인벤토리와 통합안을 1라운드에 함께 보여 확인받는다(SKILL.md 0-4).
국소	design.md가 슬롯에 답하면 묻지 않는다. 브랜드나 톤을 새로 정해야 하면 그 순간 경로를 전체나 연장으로 올리고, 올린 경로의 규칙대로 묻는다. 고유명사·수치는 이번 작업이 추가하거나 바꾸면 묻는다. 기존 화면에 이미 있는 값은 건드리지 않는 한 다시 확인하지 않는다(§4-1). 대상은 있는데 증상이 없는 요청("좀 고쳐줘", "이상해")은 1′ 실측으로 후보를 먼저 찾는다 — 같은 역할의 다른 요소와 값이 다른가, 대비·포커스 기준에 미달인가, 전환이 없거나 과한가. 후보가 하나면 그것을 고치고 무엇으로 판단했는지 말한다. 둘 이상이거나 없으면 실측값을 보이며 한 번 묻는다("지금 hover는 배경이 4% 어두워집니다. 더 뚜렷하게 / 다른 버튼과 같게 / 다른 문제"). "무엇을" 슬롯이 요청 문장으로 확정되지 않은 경우의 처리다.
리뷰	범위와 입력(스크린샷·URL·diff)만 묻는다. 위 슬롯은 리뷰 대상이 아니라 리뷰 자체의 입력이므로 별도로 취급한다. 리뷰는 읽기 전용이다(change-review.md §1).

국소 경로에서 조건이 깨지면(토큰을 새로 정의하게 됐거나 손댄 섹션이 늘었거나 방향을 바꿔야 하면) SKILL.md 0단계의 규칙대로 경로를 올렸다고 말하고, 그 순간부터는 이 표의 전체·연장 행을 따른다.

4-1. 경로 판정의 빈틈 메우기

SKILL.md 0단계의 경로 표(A 새 화면 / B 토큰 재정의 / C design.md 유무)는 아래 세 경우에서 답이 갈렸다(레드팀 01 F4·F5·F7). 표 자체는 SKILL.md가 소유하므로, 여기서는 각 경우에 무엇을 묻고 어디로 가는지만 정한다.

• design.md가 있는데 사용자가 방향 변경(리디자인)을 명시했다. "완전히 새로", "지금 너무 올드해", "방향을 바꾸고 싶다"처럼 현행 방향을 거부하는 발화가 있으면, C가 "예"여도 전체(리디자인) 경로로 간다. 연장 경로는 2단계(방향)를 돌지 않으므로, 연장으로 보내면 사용자가 거부한 방향을 새로 칠하는 것으로 끝난다. 기존 design.md는 방향의 답이 아니라 보존할 자산 목록의 입력이다(로고·색·사용자 기대 중 무엇을 남길지). 리디자인이라는 발화가 없는 연장 작업 중에 방향을 바꿔야 할 이유가 생기면, 멈추고 사용자에게 승격을 확인받는다 — 조용히 바꾸지 않는다.
• 새 화면도 토큰 재정의도 없는데 손대는 섹션이 3개 이상이다. 국소(2개 이하)에도, 전체·연장(A 또는 B)에도 맞지 않는 공백이다. 연장 경로로 간다. design.md가 없으면 0단계 스캔에서 읽은 현행 토큰·컴포넌트 규칙을 "현행 계약 요약"(5줄 이내)으로 인터뷰 1라운드에 함께 보여 주고 확인받은 뒤, 그 요약을 design.md의 자리에 둔다. 6단계에서 이 요약을 design.md로 남길지는 사용자에게 제안만 한다.
• design.md는 없는데 현행 시각 언어가 코드에 있는 제품에 새 화면을 더한다. 이것도 연장 경로이고 같은 "현행 계약 요약"을 확인받는다. 전체 경로로 보내면 서체가 서로 다른 방향 카드가 나가, 사용자는 묻지 않은 리브랜딩 제안을 받는다. 현행 시각 언어가 있는지는 파일로 판정한다(토큰·테마 파일, 컴포넌트 디렉터리, 화면 둘 이상에 반복되는 색·서체). 요약이 틀렸다는 답이 오거나 사용자가 그 시각 언어를 바꾸고 싶다고 하면 전체(리디자인)로 간다.
• 국소 작업의 화면에 고유명사가 이미 있다. "hover 색만 진하게"처럼 기존 고유명사·수치를 만지지 않는 작업이면 묻지 않는다. 저장소에서 읽은 값이 가설이라는 원칙(§2)은 그 값을 새로 쓰거나 근거로 삼을 때 적용된다 — 손대지 않는 값을 재확인하느라 한 턴을 쓰는 것은 사용자가 이 스킬을 끄게 만든다. 국소 작업이 새 문구·숫자·이름을 추가하거나 바꾸면 그때는 묻는다.

5. 질문 카드 작성법

• 질문 카드는 사용자의 대화 언어로 쓴다. 사용자에게 묻고 보고하는 말(질문·선택지·"고르면:" 줄·가정 목록·완료 보고)은 사용자의 대화 언어로 쓴다. 이 스킬 문서가 한국어라는 것은 근거가 아니다 — 영어로 요청했으면 아래 템플릿을 영어로 옮겨 묻는다(실측: 영어 요청에 한국어로 물은 실행 3/3). 사이트 카피의 기본 언어는 이와 따로 §17로 정한다.
• 질문 앞 본문에 남은 길을 한 줄로 말한다. "지금 네 가지를 여쭙고, 조사 뒤에 방향 시안을 한 번 고르시면 그다음은 끝까지 만들어 보여 드립니다." 구조화 도구를 쓰더라도 이 한 줄은 본문에 쓴다. 질문이 끝없이 이어진다는 인상은 횟수보다 예고가 없어서 생긴다.
• 결과를 크게 바꾸는 축부터 낸다. 업종·성격과 목표 행동이 톤이나 고유명사보다 앞선다 — 앞의 답이 뒤의 질문 구성을 바꾸기 때문이다.
• 선택지마다 "이걸 고르면 무엇이 달라지는지" 한 줄을 붙인다. 고르는 사람이 결과를 미리 예상할 수 있어야 한다. "A: 발랄한 느낌"처럼 형용사만 나열하지 않는다. 라벨 자체가 결과를 드러내는 행동형 선택지(목표 행동 등)는 "고르면:" 줄을 생략해도 된다.
• multiSelect와 단일 선택을 구분한다. 목표 행동은 대개 복수이므로 multiSelect로 내고, 답이 여럿이면 다음 질문이나 다음 라운드에서 우선순위를 확인한다. 톤과 성격은 주된 방향(지배) 하나를 단일 선택으로 받는다. 사용자가 자유 답으로 스타일을 둘 이상 말하면 섞을 수 있다 — 그때는 어느 쪽이 구조(그리드·위계·밀도)를, 어느 쪽이 표면(색·재질·장식)을 맡는지를 지배/보조로 기록한다(remix.md 2단계). 답이 없는 상태에서 지배를 가정하지 않는다. 이 확인은 질문을 새로 늘리지 않는 순서로 받는다(§5-1).
• 톤 선택지에는 모션 강도와 프리셋 영향을 적는다. 톤은 2단계 프리셋과 3단계 모션 문법을 여기서 사실상 결정하므로, "이 톤을 고르면 모션이 어느 정도 세지는지·어떤 레이아웃 프리셋으로 가는지"를 선택지 설명에 넣는다.
• 구조화 도구가 preview를 지원하면(지원 여부는 harness.md §1) 톤·내비 선택지에 ASCII 목업 비교를 붙인다. 문장으로 "여백이 넓다"고 말하는 것보다 실제 배치 차이를 보여주는 쪽이 오답을 줄인다. 예시:

A. 에디토리얼 · 잡지 (editorial)    B. 대담 · 캠페인 (anti-grid)
+----------------------+           +----------------------+
|                      |           | 거대한      [사진]   |
|   큰 제목            |           |    제목  ↘           |
|   ------------       |           |  [사진]    짧은 문장 |
|          작은 캡션   |           |        [사진]        |
+----------------------+           +----------------------+

선택지 이름 옆의 괄호는 presets/README.md의 실제 프리셋 이름이다. 톤 선택지는 존재하는 프리셋(editorial · swiss-minimal · anti-grid · dark-instrument · quiet-commerce), "새로 정의", 그리고 상설 옵션 **"스타일·레퍼런스 이름으로 직접 말하기"**로 연결한다. 이름이 오면 style-atlas.md의 해당 카드를 열고, 둘 이상이면 §5-1의 지배/보조 확인을 거쳐 remix.md 경로로 간다. 톤은 0단계에서 큰 방향만 정한다 — 같은 프리셋 안에서도 결과의 실루엣은 2단계 방향 카드(§16)에서 다시 갈린다. 그러니 선택지 설명에 레이아웃 실루엣까지 확정하는 말("왼쪽 글·오른쪽 사진")을 넣지 않는다.

• 자산 질문의 자유 답 칸에 취향 앵커 한 줄을 얹는다. "참고하고 싶은 사이트·브랜드·잡지가 있으면 1~3개, 그리고 이렇게는 안 됐으면 하는 느낌이 있으면 하나"를 적는다. 질문 수는 늘리지 않는다. 비어 있으면 다시 묻지 않는다(§3).

5-1. 스타일을 둘 이상 말하면 — 지배/보조 확인 순서

질문 수를 늘리지 않는 순서로 받는다. 앞 단계에서 답이 나오면 뒤로 가지 않는다.

1. 같은 질문 안에서 받는다. 톤 질문의 "직접 말하기" 선택지(또는 자유 답 칸)에 "둘 이상이면 어느 쪽이 구조를, 어느 쪽이 표면을 맡을지도 적어 주세요"를 붙여 둔다(§6 세 템플릿 모두). 대부분은 여기서 끝난다.
2. 전체 경로면 방향 카드로 받는다. 1번 답에 지배/보조가 없으면 0단계에서 다시 묻지 않는다. 2단계 방향 체크포인트(§16)에서 지배/보조를 서로 바꾼 카드를 나란히 내 사용자가 고르게 한다(예: "A — 아르데코가 구조, 데이터 표가 표면" / "B — 데이터 표가 구조, 아르데코가 표면"). 카드 간 구조 차이 요건(§16-3)은 그대로 지킨다.
3. 방향 체크포인트가 없는 경로(연장)면 지배/보조 미정은 §9의 우선순위 확인에 해당한다 — 2라운드의 기존 사유("답이 서로 모순될 때")로 묻는다. 새 라운드 사유를 만들지 않는다.

어느 경우에도 답이 없는 상태에서 지배를 가정하지 않는다. 명시적 위임(§11)이면 고른 지배/보조와 이유를 §12 가정 목록에 "확인 필요: 예"로 올린다.

6. 질문 카드 템플릿 3종

수단은 판단이 아니라 도구 목록으로 기계적으로 정한다. 하네스별 정확한 도구명·한도는 harness.md에 있다. 아래는 세 가지 대표 형태다.

(a) 구조화 도구 4문항판 (Claude Code · Gemini · Copilot 계열)

질문 1 — 업종·성격 (단일 선택)
  A. 하이엔드 플로럴 스튜디오 (추천 — README에 "맞춤 부케·상담 예약" 언급)
     고르면: 포트폴리오형 갤러리와 예약 상담 CTA가 중심이 된다.
  B. 데일리 플라워 · 정기구독형
     고르면: 반복 구매를 위한 가격·주기 섹션이 커진다.
  C. 동네 꽃집 · 방문 중심
     고르면: 위치·영업시간이 첫 화면에 노출된다.

질문 2 — 목표 행동 (다중 선택)
  A. 상담·문의 신청
  B. 정기구독 시작
  C. 매장 방문·예약
  D. 소셜 채널 팔로우
  (여러 개를 고르셨으면 가장 중요한 하나를 자유 답에 적어 주세요.
   비어 있으면 다음 라운드에서 우선순위를 확인합니다.)

질문 3 — 톤 (단일 선택, 모션·프리셋 영향 표시)
  A. 에디토리얼 · 잡지
     고르면: editorial 프리셋, 넓은 여백과 세리프, 모션은 절제(페이드 위주).
  B. 대담 · 캠페인
     고르면: anti-grid 프리셋, 깨진 격자와 큰 타입, 모션은 표현적.
  C. 조용한 커머스
     고르면: quiet-commerce 프리셋, 상품·사양이 주인공, 모션 최소.
  D. 직접 말하기 — 예: "Y2K 느낌", "아르데코 + 데이터 표"
     고르면: style-atlas 카드 또는 리믹스. 둘 이상이면 어느 쪽이 구조(배치·위계)를,
     어느 쪽이 표면(색·재질)을 맡을지도 함께 적어 주세요.

질문 4 — 기존 브랜드 자산과 실제 값
  A. 있다 — 자유 답(Other)에 로고·색 파일 위치와 상호명·연락처를 적어 주세요.
  B. 아직 없다 — 브랜드 색은 레퍼런스에서 정하고, 상호명·연락처는 placeholder로 둡니다.
  (어느 쪽이든 자유 답에 "좋아하는 사이트·브랜드 1~3개 / 피하고 싶은 느낌 하나"를
   적어 주시면 레퍼런스를 고를 때 먼저 봅니다. 비워 두셔도 됩니다.
   아직 없는 값은 [이름]처럼 자리만 잡아 두고 목록으로 드립니다.)

세 템플릿 모두 자산 질문의 자유 답 안내(또는 평문 블록)에 해당할 때만 아래 줄을 얹는다. 질문 수는 늘리지 않는다.

• 빈 폴더면: "정적 HTML·CSS로 만들 예정입니다. 다른 스택이나 배포처가 정해져 있으면 적어 주세요."
• 다크모드가 요청됐거나 이미 있으면: "기본 테마는 어느 쪽인가요(시스템 설정 / 라이트 / 다크), 바꾸는 토글이 필요한가요?"
• 로그인 뒤 화면이면: "화면을 열어 볼 방법이 있나요(테스트 계정·목 데이터·스토리북)?"

작업 조건 묶음(선택 응답). 동의가 필요한 일은 단계마다 따로 멈춰 묻지 않고 0단계 질문과 같은 턴에 평문으로 미리 묻는다. 슬롯이 아니므로 0단계 통과를 막지 않고, 답이 없으면 그 일이 필요해질 때 묻는다.

작업 조건(답이 없으면 그 일이 필요해질 때 다시 여쭙니다):
- 레퍼런스·검증용 브라우저 도구가 없으면 설치해도 될까요? (수백 MB)
- 쓸 사진이 없는 자리에 이미지를 생성해도 될까요? (과금이 생기면 따로 알려 드립니다)
- 검증 설정·스크립트를 프로젝트에 남길까요, 임시 폴더에서만 돌릴까요?

고유명사·실제 값은 선택지로 만들 수 없다. 질문 4처럼 자유 답(Other)으로 받거나, 비어 있으면 8절에 따라 2라운드에서 평문으로 받는다.

(b) 3문항판 (질문 ≤3, 선택지 2~3개로 제한되고 "Other"를 클라이언트가 자동으로 붙이는 구조화 도구 — 해당 하네스와 도구명은 harness.md §1·§2)

질문 1 — 업종·성격
  A. 하이엔드 플로럴 스튜디오 (추천 — README의 "맞춤 부케·상담 예약")
  B. 데일리 플라워 · 정기구독형
  C. 동네 꽃집 · 방문 중심

질문 2 — 가장 중요한 목표 행동 하나
  A. 상담·문의 신청
  B. 정기구독 시작
  C. 매장 방문·예약

질문 3 — 톤
  A. 에디토리얼 · 잡지 (editorial)
  B. 대담 · 캠페인 (anti-grid)
  C. 조용한 커머스 (quiet-commerce)

이 도구의 선택지는 서로 배타적이라 다중 선택을 받을 수 없다. 그래서 목표 행동은 "가장 중요한 하나"로 묻고, 나머지 행동은 아래 평문 블록에서 받는다. 같은 턴에 평문 한 블록을 더 낸다(질문 수 상한에 걸리는 나머지 슬롯):

추가로 확인이 필요합니다.
- 위에서 고른 것 말고도 원하는 행동(구독·방문·소셜 등)이 있으면 적어 주세요.
- 실제 상호명·연락처·영업시간이 있나요? 없으면 placeholder로 표시하겠습니다.
- 기존 로고나 브랜드 색이 있나요? 파일이 있으면 알려주세요.
- (선택) 좋아하는 사이트·브랜드 1~3개, 피하고 싶은 느낌 하나가 있으면 적어 주세요.
- 톤을 위 셋이 아니라 스타일·레퍼런스 이름으로 말하고 싶으면 질문 3의 직접 입력(Other)에 적어 주세요. 둘 이상이면 어느 쪽이 구조(배치·위계)를, 어느 쪽이 표면(색·재질)을 맡을지도 함께 적어 주세요.
- 좁은 화면 메뉴는 정보 구조를 정한 뒤 다음 라운드에서 따로 여쭙겠습니다.

(c) 평문 폴백판 (구조화 질문 도구가 없거나 확인되지 않는 하네스)

1. 업종·성격이 어느 쪽에 가깝나요?
   a) 하이엔드 플로럴 스튜디오
   b) 데일리 플라워 · 정기구독형
   c) 동네 꽃집 · 방문 중심
   d) 위에 없음 — 직접 설명해 주세요

2. 목표 행동은 무엇인가요? (복수 가능 — 여럿이면 가장 중요한 하나를 표시해 주세요)
   a) 상담·문의 신청
   b) 정기구독 시작
   c) 매장 방문·예약
   d) 소셜 채널 팔로우

3. 톤은 어느 쪽인가요?
   a) 에디토리얼 · 잡지 (여백 넓고 모션 적음)
   b) 대담 · 캠페인 (깨진 격자, 표현적 모션)
   c) 조용한 커머스 (상품이 주인공, 모션 최소)
   d) 직접 말하기 — 스타일·레퍼런스 이름(예: "Y2K 느낌", "아르데코 + 데이터 표").
      둘 이상이면 어느 쪽이 구조(배치·위계)를, 어느 쪽이 표면(색·재질)을 맡을지도 적어 주세요.

4. 실제 상호명·연락처·기존 로고나 브랜드 색이 있나요? 없으면 없다고 답해 주세요.
   (선택) 좋아하는 사이트·브랜드 1~3개, 피하고 싶은 느낌 하나가 있으면 함께 적어 주세요.

답을 주시면 1단계(레퍼런스 조사)로 넘어가고, 구현 전에 방향 시안 2~3개를 먼저 보여 드립니다.

7. 턴 종료 규칙

물었으면 그 턴에서 1단계 조사·파일 생성·구현을 시작하지 않는다. 같은 턴에 할 수 있는 것은 스캔 결과 요약뿐이다 — "이런 파일을 읽었고 이렇게 추천한다"까지는 같은 턴에 말해도 되지만, 답을 받기 전에 레퍼런스를 조사하거나 토큰·코드를 만들지 않는다.

같은 규칙이 2단계 방향 체크포인트(§16)와 feedback-loop.md의 좁히기 질문에도 그대로 적용된다. 묻는 자리가 어디든, 물었으면 턴을 끝낸다.

8. 라운드

이 절의 라운드 상한은 0단계 브리프 인터뷰에만 적용된다. 1라운드가 기본이다. 2라운드는 다음 세 경우에만 연다.

• 답이 서로 모순될 때(9절)
• 고유명사·실제 값이 아직 없을 때
• 좁은 화면 내비를 정할 때(정보 구조가 확정된 뒤라야 물을 수 있으므로)

그 외의 이유로 0단계 라운드를 늘리지 않는다.

라운드가 아닌 체크포인트. 아래는 0단계 라운드를 늘리는 것이 아니라, 파이프라인의 다른 단계에 정해진 별도 확인 지점이다. 위 상한에 세지 않으며, 위 상한을 근거로 생략하지도 않는다.

체크포인트	단계	정의
방향 체크포인트	2단계 끝	§16
실제 값 확인	5단계 하드 게이트 7 (b)	0단계에서 이미 placeholder에 동의받은 값은 다시 묻지 않는다 — 그 값은 (a) placeholder로 처리한다
피드백 좁히기	납품 뒤 사용자 불만	feedback-loop.md
작업 조건 동의	0단계 질문과 같은 턴	§6의 작업 조건 묶음. 선택 응답이고 0단계 통과를 막지 않는다. 여기서 동의받은 일은 해당 단계에서 다시 묻지 않는다

8-1. "모르겠다·아무거나·상관없다"는 그 슬롯의 부분 위임이다

1라운드 답이 "톤은 잘 모르겠어요", "목표 행동은 아무거나"처럼 오면, 그것은 무응답이 아니라 사용자가 그 슬롯을 맡긴다고 답한 것이다. 같은 질문을 다시 내면 재질문 루프가 되고, 답이 왔는데 멈춰 있으면 정지가 된다. 그래서 다음처럼 끝낸다.

1. 그 슬롯만 스캔 근거가 있는 추천값으로 채운다. 근거가 없으면 1단계 레퍼런스에서 정하겠다고 말한다.
2. §12 가정 목록에 올리고 "확인 필요: 예"로 둔다.
3. 같은 슬롯을 0단계에서 다시 묻지 않는다.
4. 톤·성격을 맡겼다면 2단계 방향 체크포인트(§16)가 그 슬롯을 그림으로 다시 확인하는 자리다. 말로 고르기 어려운 사람도 카드를 보면 고를 수 있다.

부분 위임은 그 슬롯 하나에만 적용된다. 다른 필수 슬롯이 비어 있으면 그것은 여전히 묻는다. 빈 답·자동 해제된 답은 부분 위임이 아니다(§10).

9. 답이 모순되면

그 자리에서 정리한다. 1절 사례에서 목표 행동 넷이 다 선택됐는데, 하이엔드 스튜디오에서 "정기구독"과 "문의 상담"은 성격이 다르다. 우선순위를 제안하고 확인받는다 — 넷을 같은 무게로 두면 CTA가 넷이 되고 페이지가 무너진다.

정리 방법은 다음 순서를 따른다.

1. 모순된 두 답을 그대로 나열한다(추측으로 하나를 지우지 않는다).
2. 먼저 온 답 또는 더 구체적인 답을 우선순위 후보로 제안한다.
3. "이렇게 이해했는데 맞나요"로 확인받는다. 확인 없이 임의로 하나를 폐기하지 않는다.
4. 확인된 우선순위를 브리프 세 줄과 design.md에 그대로 남긴다.

10. 무응답·비대화형·서브에이전트

빈 답·오류·시간 초과·자동 해제의 처리는 harness.md §3이 정본이다. 이 절은 그 규칙을 인터뷰 관점에서 요약한다. 두 문서가 다르게 읽히면 harness.md §3을 따른다.

• 메인 세션에서는 가정으로 진행하지 않는다. 구조화 질문 도구가 거부·오류·시간 초과·자동 해제된 빈 답을 돌려주면, 같은 질문을 평문 번호 질문으로 다시 내고 턴을 끝낸다. 자동 해제로 들어온 빈 답(harness.md §1의 자동 제출·자동 통과 사례)을 어떤 선택지를 고른 것으로 해석하지 않는다. 무응답이 반복돼도 가정 진행으로 넘어가지 않는다 — 다시 짧게 묻고, "알아서 해 달라고 답하시면 가정으로 진행하고 목록을 남기겠습니다"라는 선택지를 함께 보여 준다. 그 답이 오면 §11의 명시적 위임이다.
• 한 번 실행하고 끝나는 실행(claude -p, codex exec 같은 비대화형 실행)도 평문으로 묻고 끝낸다. 구조화 도구가 즉시 거부되는 것은 "질문이 오류로 끝난 것"이 아니라 그 실행에 구조화 도구가 없다는 뜻이다. 최종 응답에 브리프 카드 초안과 번호 질문을 남기고 파일을 만들지 않은 채 끝낸다. 답은 세션 재개나 다음 실행으로 온다.
• 서브에이전트로 실행 중이면 브리프 카드 초안과 질문을 호출자에게 반환하고 멈춘다. 서브에이전트는 사용자에게 직접 물을 수 없으므로, 0단계는 반드시 메인 세션에서 끝낸다. 서브에이전트가 이 문서를 참조해 초안을 만들었더라도 그 초안은 확정이 아니다. 서브에이전트 안에서 질문 도구가 없다는 오류를 받은 것은 질문이 실패한 것이 아니다 — 원래 그 도구가 없는 자리다.
• 가정으로 진행할 수 있는 것은 서브에이전트뿐이고, 그것도 호출자가 답 없이 다시 진행을 지시했을 때뿐이다(호출자에게 질문을 반환하는 경로 자체가 오류·시간 초과로 끝난 경우 포함). 그때는 모든 가정에 라벨을 붙여 첫 응답에서 밝히고(마지막 응답이 아니라), 12절의 형식으로 design.md 미확정 목록에 올린다. 메인 세션의 명시적 위임(11절)은 별도다.
• 오케스트레이터가 워커에게 디자인 구현을 넘길 때는 브리프 카드를 작업 패킷에 포함한다. 워커가 다시 사용자에게 묻는 일이 없도록, 확정된 슬롯과 미확정 가정, 2단계에서 사용자가 고른 방향 카드를 함께 넘긴다.

11. 명시적 위임 예외

예외는 사용자의 명시적 위임뿐이다 — "알아서 해줘", "묻지 말고 진행" 같은 발화가 여기 해당한다. "되돌리기 쉬운 습작"은 예외가 아니다. 되돌리기 쉬움은 사용자가 판단할 몫이지, 모델이 되돌리기 쉬워 보인다는 이유로 인터뷰를 생략할 근거가 아니다.

위임을 받았을 때도 가정을 침묵 속에 진행하지 않는다.

1. 어떤 슬롯을 가정으로 채우는지 목록으로 말한다.
2. 12절의 형식으로 design.md 미확정 목록에 올린다.
3. 이후 사용자가 특정 슬롯을 정정하면 그 슬롯만 다시 확정 상태로 바꾼다.

위임의 범위는 사용자가 말한 범위다. "인터뷰는 알아서 해"는 0단계 슬롯의 위임이고, 2단계 방향 선택까지 맡긴다는 뜻으로 넓혀 읽지 않는다. 방향까지 맡긴다는 발화("전부 알아서", "끝까지 묻지 말고")가 있을 때만 §16의 위임 처리로 간다.

12. 가정 기록 형식

design.md의 미확정 목록에는 아래 네 항목을 슬롯마다 한 행씩 적는다.

슬롯	가정한 값	근거	확인 필요 여부
(3절 슬롯 이름)	(실제로 채택한 값)	(스캔한 파일·업종 평균·모델의 판단 중 무엇에서 나왔는지)	(예/아니오 — 다음 상호작용에서 반드시 확인해야 하면 예)

근거 칸에 "모델의 판단"이라고 쓸 수밖에 없는 슬롯은 확인 필요를 항상 "예"로 둔다. 스캔한 파일이 근거면 파일 경로를 적는다.

13. 색 자산 확인

브랜드 자산은 3절 표에서 전체 경로의 필수 슬롯이다. 로고·간판·패키지·기존 토큰에 브랜드 색이 있으면 그것부터 확인한다. 파일로 확인되면 묻지 않는다. 파일에 색이 없거나 사용자가 이미 "브랜드 색 없음"이라고 말했다면 그것도 확정으로 취급하고 다시 묻지 않는다. 그 외에는(파일도 없고 사용자 발화도 없으면) 묻는다.

• 기존 색이 있다 → 역할·대비·면적을 검토해 토큰에 반영한다. 반드시 강조색일 필요는 없다.
• 없다·상관없다(사용자가 확인함) → 레퍼런스와 과업에서 색 역할을 정한다.
• 아직 확인되지 않았다 → 묻는다.

실측 사례: 꽃집 작업에서 색을 묻지 않고 레퍼런스 세 곳의 배경 평균(#F8F6F0)으로 정했다. 결과는 좋았지만 운이 좋았던 것이다. 브랜드 색이 있었다면 그걸 무시한 작업이 된다.

사진 자산의 유무와 조달은 images.md §1을 따른다(SKILL.md 4-0).

14. 좁은 화면 내비

내비 구조는 항목 수만으로 정하지 않는다. 실제 라벨과 번역 길이, 글꼴 확대, 최소 화면 폭, 가장 중요한 이동 경로, 메뉴 깊이, 키보드 포커스 순서를 함께 본다. 한 줄·가로 스크롤·하단 바·여는 메뉴 중에서 그 조건에서 과업을 가장 덜 방해하는 방식을 고르고, 실제 좁은 화면과 확대 상태에서 검사한다.

여는 메뉴가 필요하다고 판단되면 layout.md의 모바일 내비 절을 본다. 항목이 적어도 긴 번역·깊은 계층이면 여는 메뉴가 맞을 수 있고, 항목이 많아도 우선순위가 뚜렷하면 일부를 분리할 수 있다.

이 슬롯은 정보 구조·라벨이 정해진 뒤에만 물을 수 있으므로 8절에 따라 2라운드에서 묻는다. 판단 기준(라벨 길이·확대·폭·우선순위·깊이·포커스 순서)은 여기서 바뀌지 않는다.

15. 묻는 것과 묻지 않는 것

• 묻는다: 결과를 바꾸는 결정(3절 슬롯), 사용자만 아는 사실(실제 수치·이름·재고·연락처 같은 것).
• 묻지 않는다: 코드를 읽거나 검색하면 확인되는 사실.

이 스킬에는 "관례적으로 명확해서 묻지 않아도 되는" 디자인 결정이 없다는 것이 전제다. 무엇을 만들지, 누구에게 무엇을 시킬지, 어떤 인상을 줄지는 업종이 같아도 브랜드마다 다르다 — 관례를 근거로 질문을 생략하면 1절의 실측 사례처럼 넷 중 넷이 틀린다. 질문을 생략할 수 있는 유일한 근거는 "이미 코드·검색으로 확인했다"뿐이다.

16. 방향 체크포인트 (2단계 끝)

인터뷰는 "무엇을 만들지"를 확인한다. 그러나 같은 답("하이엔드 · 에디토리얼")에서도 결과의 모습은 여러 갈래로 갈린다. 지금까지는 그 갈래를 에이전트가 혼자 골랐고, 사용자는 납품 때 처음 봤다. 꽃집 사례(넷 중 넷 오답)의 교훈이 인터뷰에만 적용되고 방향에는 적용되지 않은 것이다. 레드팀 06은 이 공백을 만족도의 최대 원인으로 지목했다 — 방향 승인이 없으면 한 번에 다 만든 뒤 전부 갈아엎는 비용 구조가 된다. 그래서 구현에 들어가기 전에 방향을 한 번 보여 주고 고르게 한다.

16-1. 언제 돌고, 언제 돌지 않는가

경로	방향 체크포인트
전체 · 전체(리디자인)	돈다. 1단계 레퍼런스 조사가 끝나고 2단계에서 방향 후보를 만든 뒤, 3단계 토큰에 들어가기 전
연장	돌지 않는다. 방향은 design.md가 이미 답했다. 연장 중 방향을 바꿔야 하면 §4-1대로 승격을 확인받고, 승격되면 돈다
국소	돌지 않는다
리뷰	돌지 않는다
사용자가 방향을 시안으로 줬다(Figma·스크린샷·목업·브랜드 가이드)	해석 카드 한 장으로 돈다. 시안에서 읽어 낸 것을 §16-2 항목으로 옮겨 적고(구도, 실측하거나 추정한 서체·색 값, 섹션 흐름), 시안에 없어서 정해야 하는 것(좁은 화면, hover·오류 상태, 시안에 없는 섹션)을 따로 나열한 뒤 "이렇게 읽었는데 맞나요, 빈 곳은 이렇게 채워도 되나요"를 묻고 턴을 끝낸다. 대안 카드는 사용자가 원할 때만 낸다

시안을 받았을 때 대안 카드를 내지 않는 이유: 방향의 승인권자가 이미 방향을 정했다. 확인할 것은 선택이 아니라 해석이다. 이미지에서 읽은 서체·크기·색은 추정값이라고 적는다 — 실측은 URL에만 쓸 수 있다.

명시적 위임은 §16-5에서 따로 다룬다. "결과가 크게 달라지지 않을 것 같다"는 판단으로 체크포인트를 생략하지 않는다 — 인터뷰 게이트 규칙 2와 같은 이유다.

16-2. 방향 카드 — 2~3장, 각 카드에 담을 것

카드는 2장 또는 3장이다. 1장은 선택이 아니고, 4장 이상은 고르는 사람을 지치게 한다(시안을 받은 경우의 해석 카드 한 장은 §16-1).

항목	내용
이름	두세 단어. 프리셋 이름을 그대로 쓰지 않는다("editorial"이 아니라 "목요일의 잡지 표지")
한 줄 컨셉	누가, 무엇을 보고, 어떤 판단을 하게 되는가 한 문장. SKILL.md 2단계의 "한 문장 컨셉"이 된다. 내부 기준이지 화면에 싣는 카피가 아니다
레이아웃 구조	첫 화면의 ASCII 실루엣(아래 예시 크기) + 섹션 흐름 한 줄(예: "표지 → 작업 3점 → 상담 절차 → 문의")
타입 페어	표제 서체 / 본문 서체(실제 서체 이름, 한글 포함). 크기 대비를 한 마디로("표제가 본문의 6배")
색	역할 3개와 실제 값(바탕 / 글자 / 강조). 지배 관계 한 마디("거의 흑백, 강조는 버튼에만"). 다크를 지원하면 다크의 바탕·글자·강조 값도 한 줄 적는다
모션 태도	한 줄(예: "정지에 가깝다 — 페이드만", "스크롤에 따라 사진이 밀려 들어온다"). 감소 모션 경로는 3단계에서 정한다
레퍼런스	이 카드를 받치는 레퍼런스 슬롯과 원본 URL(R1·R2·R3 중 무엇을 어떻게 썼는지)
히어로 첫 문장	실제로 실릴 표제 후보 한 줄. 카피 목소리를 이 자리에서 승인받는다. 무엇을 하는 곳·제품인지가 드러나는 평이한 문장(사실 + 이득, 업종 관례 어휘)으로 쓰고, 번역체·잠언형 과장·감성 어휘·명사 종결 수수께끼 표제는 쓰지 않는다(product-copy.md §13-c). 카드 사이의 차이는 문장의 멋이 아니라 화법(사실·명령·장면, §13-b)으로 낸다
이 방향이 포기하는 것	이 카드를 고르면 잃는 것 한 줄(예: "상품을 한눈에 비교하기 어렵다", "모바일 첫 화면에 CTA가 늦게 나온다")

ASCII 실루엣 예시(카드마다 이 정도 크기):

A. 목요일의 잡지 표지          B. 꽃의 작업대                  C. 계절 달력
+------------------------+    +------------------------+    +------------------------+
|        [전면 사진]     |    | 작은 제목   | [사진]   |    | 4월 | 5월 | 6월 | 7월  |
|                        |    | --------    | [사진]   |    |-----+-----+-----+------|
|  거대한 표제           |    | 긴 본문 단락| [사진]   |    | [꽃]| [꽃]| [꽃]| [꽃] |
|  작은 캡션        [→]  |    | [상담 예약] |          |    |  표제 한 줄   [상담] |
+------------------------+    +------------------------+    +------------------------+

위 예시는 꽃집 한 벌이다. 이 실루엣을 다른 업종에 옮겨 쓰지 않는다 — 구도는 그 브리프의 재료(무엇이 주인인가)에서 나온다. 업종이 다르면 카드도 이렇게 달라진다(개발자 도구의 예):

A. 터미널이 먼저                B. 숫자 세 줄                   C. 바뀐 것부터
+------------------------+    +------------------------+    +------------------------+
| $ tool init            |    | 설치 1줄                |    | v2.4  2026-09  [변경점] |
| > 3개 파일 생성        |    | 빌드 0.8초              |    | v2.3  2026-07  [변경점] |
| ---------------------- |    | 설정 파일 0개           |    | ---------------------- |
| 한 줄 표제   [문서 →]  |    | [시작하기]  [GitHub]    |    | 표제 한 줄   [설치]     |
+------------------------+    +------------------------+    +------------------------+

나쁜 카드 세트의 예: 세 장 모두 "왼쪽 표제·오른쪽 이미지"이고 강조색만 남색·녹색·주황으로 다르다. 표제 서체가 같고 섹션 흐름도 같다. 이것은 카드 세 장이 아니라 색 견본 세 개다(§16-3). 구도 패밀리 목록은 layout.md §2-b에 있다.

미리보기 한 장(캡처 도구가 있을 때). 디자이너가 아닌 사용자는 서체 이름과 hex 값을 보고 인상을 떠올리지 못한다. 브라우저 캡처 도구가 있으면(harness.md §6) 카드마다 첫 화면만 정적 HTML 한 파일로 그려 1440·390 캡처를 카드에 붙인다. 실제 서체·색·히어로 첫 문장·구도만 넣고, 그 아래 섹션·내비 동작·모션은 만들지 않는다. 파일은 프로젝트 밖 임시 디렉터리에 두고 고른 뒤에도 구현으로 옮기지 않는다 — 시안이지 4단계의 시작이 아니다. 카드당 품이 구현의 일부를 넘기 시작하면 멈춘다. 캡처할 수 없으면 ASCII 카드로 내고 "색과 서체는 글로만 보여 드렸다. 첫 화면이 나오면 한 번 보여 드리겠다"고 말한다(SKILL.md 4-1의 중간 보고).

16-3. 카드끼리 구조가 달라야 한다

카드 3장이 같은 레이아웃에 색만 바꾼 것이면 사용자는 고르는 것이 아니라 색 견본을 보는 것이다. 이 스킬의 결과물이 서로 혼동된다는 레드팀 실측(쇼케이스 21종 중 다수가 같은 표제 서체·같은 분할 구도)도 같은 뿌리다. 아래를 카드 사이에서 모두 지킨다.

1. 히어로 구도가 다르다. 카드마다 서로 다른 구도 패밀리를 쓴다 — 전면 이미지 / 글·이미지 분할 / 타이포 단독 / 격자·목록 / 비대칭 콜라주 / 제품 단독 / 표제 + 전폭 무대 / 데이터·도구가 주인 같은 패밀리(layout.md §2-b) 중 같은 것을 두 카드가 쓰지 않는다. 분할의 좌우만 바꾼 것은 같은 구도다.
2. 표제 서체가 다르다. 같은 서체를 두 카드의 표제에 쓰지 않는다. 같은 분류(예: 둘 다 명조 계열 세리프)라면 굵기·폭·대비 중 둘 이상이 눈에 띄게 달라야 하고, 그 차이를 카드에 적는다. 본문 서체는 언어·가독성 제약 때문에 같아도 되지만 이유를 적는다.
3. 정보 흐름 또는 밀도가 다르다. 섹션 순서, 첫 화면에 담는 정보량, 여백 비율 중 하나 이상이 다르다.
4. 색의 지배 관계가 다르다. 밝은 바탕 / 어두운 바탕 / 강한 색면처럼 명도 위계나 강조 면적이 다르다. 같은 팔레트의 명도만 살짝 옮긴 것은 다르지 않다.
5. 포기하는 것이 서로 다르다. 세 카드가 같은 것을 포기한다면 실제로는 같은 방향이다.

확인 방법: 카드 이름과 설명을 가리고 ASCII 실루엣과 타입 페어만 봐도 세 카드를 구분할 수 있어야 한다. 구분이 안 되면 카드를 다시 만든다.

톤 답과의 관계: 0단계에서 사용자가 고른 톤과 취향 앵커는 모든 카드의 경계 조건이다. 카드는 그 안에서 구조로 갈린다. 다만 한 장은 브리프가 허용하는 범위에서 톤을 한 단계 밀어 본 카드로 둘 수 있다 — 그렇다면 카드에 "톤을 한 단계 밀었다"고 적는다. 사용자가 적은 "피하고 싶은 느낌"에 걸리는 카드는 내지 않는다. 각 카드는 SKILL.md 2단계의 반사실 점검("다른 업종의 브리프에도 그대로 나왔을 것인가")을 따로 통과해야 한다.

16-4. 묻는 방법과 턴 종료

• 카드 전체 내용(§16-2 표의 항목)을 먼저 본문에 보여 주고, 같은 턴에 단일 선택 질문 하나로 "어느 방향으로 갈까요?"를 묻는다. 선택지는 카드 이름이고, 자유 답으로 "섞고 싶다(예: A의 구도 + C의 색)"나 "둘 다 아니다"를 받을 수 있게 한다.
• 질문 수단은 0단계와 똑같이 기계적으로 정한다 — 구조화 질문 도구가 있으면 그것으로, 없으면 평문 번호 질문으로. 하네스별 도구·한도·preview 지원 여부는 harness.md §2-1에 있다.
• 카드 앞에 남은 길을 한 줄로 말한다 — "여기서 고르시면 다음은 완성본입니다. 첫 화면이 나오면 한 번 보여 드립니다."
• 물었으면 턴을 끝낸다. 답을 받기 전에 3단계 토큰 확정, 4단계 구현, 프로젝트 안의 파일 생성을 시작하지 않는다. 같은 턴에 할 수 있는 것은 카드 제시와 §16-2의 미리보기 캡처뿐이다.
• 빈 답·오류·시간 초과·자동 해제는 §10과 같다 — 메인 세션에서는 아무 카드도 고르지 않은 것으로 보고 평문으로 다시 묻는다. 비대화형 실행이면 카드와 질문을 최종 응답에 남기고 끝낸다. 서브에이전트면 카드를 호출자에게 반환하고 멈춘다.
• 이 체크포인트는 0단계 라운드에 세지 않는다(§8).

16-5. 답을 받은 뒤

답	처리
한 장을 골랐다	그 카드를 2단계 결정으로 확정한다. 고른 카드와 기각한 카드와 그 이유(사용자가 말한 이유가 있으면 원문으로)를 design.md에 남긴다. 기각한 카드는 나중에 "빠뜨린 것"으로 오인되지 않게 하는 기록이다
섞고 싶다	섞은 결과를 한 장짜리 카드로 다시 써서 보여 준다. 섞은 요소끼리 충돌하면(예: A의 고요한 모션 + C의 촘촘한 격자) §9처럼 충돌을 나열하고 우선순위를 제안해 확인받는다. 충돌이 없으면 다시 묻지 않고 확정한다
둘 다(셋 다) 아니다	짐작으로 새 카드를 만들지 않는다. feedback-loop.md의 축 좁히기로 무엇이 걸리는지 먼저 확인한 뒤, 그 축을 바꾼 새 카드 2~3장을 낸다. 두 번째 세트도 전부 기각되면 0단계 톤·취향 앵커를 다시 확인한다(좋아하는 사이트 하나만 알려 달라고 묻는다)
"알아서 해" (명시적 위임)	카드 2~3장은 그대로 만들고, 그중 한 장을 고른 이유를 브리프·레퍼런스로 소급해 응답에 말한 뒤 진행한다. 고른 카드 이름만 말하고 이유를 생략하지 않는다 — "A로 갑니다"가 아니라 "A로 갑니다. 인터뷰에서 상담 예약이 첫째 목표였고 R1 두 곳이 전면 사진 아래 예약 버튼을 뒀기 때문입니다"처럼 쓴다. 이유가 없으면 사용자는 나중에 무엇을 뒤집어야 할지 알 수 없다. 고른 카드·기각한 카드·고른 이유를 design.md에 남기고, 방향을 §12 가정 목록에 "확인 필요: 예"로 올린다. 0단계부터 "끝까지 묻지 말고 진행"을 위임받았으면 체크포인트에서 묻지 않고 같은 기록을 남긴 채 진행한다

design.md 기록 형식:

## 방향 체크포인트 — 2026-10-02
- 제시: A 목요일의 잡지 표지 / B 꽃의 작업대 / C 계절 달력
- 선택: A (사용자 선택 | 위임 — 고른 이유: ...)
- 기각: B — "너무 상점 같다"(사용자 원문) / C — 사진 수급이 계절마다 필요해 운영 부담(에이전트 판단)
- 섞은 요소: (있으면) C의 색 → A에 적용

17. 기본 언어 판정 순서

대화 언어와 사이트 언어는 다른 결정이다. 사용자에게 묻고 보고하는 말은 사용자의 대화 언어로 쓴다. 이 스킬 문서가 한국어라는 것은 근거가 아니다. 아래 순서는 사이트에 새로 쓰는 카피의 언어만 정한다 — 영어로 대화하며 한국어 사이트를 만들 수도, 그 반대도 있다.

새로 쓰는 카피의 언어는 아래 순서로 정한다. 앞의 근거가 있으면 뒤로 내려가지 않는다.

1. 사용자가 명시한 언어 — "영어로 만들어 줘", "한·영 병기".
2. 프로젝트의 기존 로컬라이제이션 — <html lang>, 번역 카탈로그, 기존 카피의 언어.
3. 사용자의 대화 언어 — 이 요청을 쓴 언어. ko-KR 노트북에서 동료가 영어로 요청했으면 영어다.
4. OS 로케일 — 보조 근거다. 위 셋이 모두 없거나, 대화 언어가 섞여 있어 판정할 수 없을 때만 쓴다. 확인 명령은 SKILL.md 0단계 표에 있다.

OS 로케일을 읽을 수 없음으로 취급하는 경우: C, POSIX, C.UTF-8처럼 언어가 없는 로케일, 그리고 원격·컨테이너·CI 실행의 로케일(사용자의 컴퓨터가 아니라 실행 환경의 기본값이다 — harness.md §3). 이 값을 근거로 영어를 고르지 않는다.

넷 다 불명확하면 묻는다. 앞의 근거가 하나라도 있으면 그것으로 정하고 근거를 밝힌다. 정한 언어는 브리프 제약 줄에 근거와 함께 적는다(기본 언어: ko-KR 한국어 — 대화 언어).