Shape

---
name: shape
description: 제품의 요구·규모·운영 제약을 질문으로 구체화하고 미정인 기술 스택을 공식 자료로 비교해 설계 결정을 정리한다. 가벼운 아이디어 대화는 talk, 결정된 내용의 명세 작성은 spec으로 구분한다.
---

# Shape

먼저 [공통 실행 계약](references/execution-contract.md)을 읽는다. 산출물은 명세가 소비할 결정 기록이다. 명세 작성·tracker 게시·구현은 이 스킬의 자동 후속 작업이 아니다. 사용자가 이미 요청했다면 결정 기록을 해당 후속 작업에 전달한다.

진행 순서는 **현재 근거 → 아래 조건에 맞는 절차 읽기·수행 → 독립 질문 묶음 → 답변 반영 후 조건 재확인 → 결정 전달**이다. 질문을 먼저 끝내고 전문 절차를 나중에 선택하지 않는다.

| 이번에 정할 것 | 결정 전에 읽고 수행 | 다음 단계에 가져올 결과 |
|---|---|---|
| 새 제품의 업무 흐름, 또는 변경되는 용어·규칙·상태·소유권 | [domain](references/workflows/domain.md) | actors·용어·불변식·상태와 아직 답이 필요한 사례 |
| 새 모듈 경계·공통 책임, 또는 기존 구조의 변경 | [architecture](references/workflows/architecture.md) | 기존 재사용·소유 경계·공통/도메인 책임과 선택 근거 |
| 미정 스택, 지원 여부·호환성·운영 제약에 의존하는 선택 | [research](references/workflows/research.md) | 현재 공식 근거·대안·추천·선택을 바꾸는 조건 |
| 새 화면의 시각 방향·구조 재설계 | [디자인 방향](references/workflows/design.md) | 사용자 판단/행동을 표현 선택에 연결한 기준과 미정 |
| 사용자 문구·기존 화면 품질 | [UI·문구 기준](references/workflows/polish/ui-copy.md) | 정보 위계·브랜드/문구 제약 |

이미 정해진 결과가 현재 요구를 설명하면 재사용한다. 선택한 절차에서 제품 질문이 생기면 아래 질문 묶음에 합친다. 기술 사실을 확인할 정보가 아직 부족하면 먼저 필요한 운영 제약을 묻고, 답을 받는 턴에 해당 절차를 수행한다. 모든 행을 순서대로 실행하는 표가 아니다.

## 1. 이미 아는 것부터

입력 대화, 현재 코드·manifest/lockfile, 관련 지침, 용어집·ADR·기존 명세를 확인한다. 확인한 경로/자료와 범위를 남긴다. 사실, 확정 결정, 제안/가정, 미정을 나누고 충돌은 근거와 영향으로 드러낸다. 사용자에게 묻기 전에 환경에서 답을 구할 수 있는 항목을 조사한다. 접근할 수 없는 자료를 읽었다고 쓰지 않는다.

## 2. 질문의 의존성

각 미정 사항이 어떤 결정에 의존하는지 연결한다. 선행 답이 확보된 독립 질문을 주제별로 한 묶음에 담고, 종속 질문은 선행 질문 ID와 함께 뒤로 미룬다. 도구의 질문 수 제한과 사용자의 인지 부담에 맞춰 묶음을 나눈다. 각 중요한 질문에는 추천, 대안, 선택을 바꾸는 조건을 붙인다. 이미 결정된 사항과 되돌릴 수 있는 세부 선택을 반복 승인받지 않는다.

누락 점검 대상은 사용자/권한, 핵심 정상·실패 흐름, 규모·동시성, 데이터량/보존, 응답시간, 운영 비용/담당자, 배포 제약, 보안, 백업·복구다. 관련된 미정만 질문하고 해당하지 않는 영역은 이유를 남긴다. 예를 들어 공개 가입 여부가 미정이면 가입 방식별 보안 선택은 그 답 이후에 다룬다. 무응답은 결정이 아니다. 질문이 필요한 단계에서는 준비된 분석과 질문 묶음을 제공하고 답을 기다린다. 질문 금지 요청이면 중요한 미정과 영향, 조건부 제안을 기록한다.

### 답변 후 계속 진행

답변을 받으면 먼저 각 열린 결정을 아래처럼 갱신한다. 설명이나 역질문은 먼저 답하고 이 흐름으로 돌아온다.

| 답변 상태 | 이번 턴의 처리 |
|---|---|
| 확정 | 출처와 이유를 유지하고 재질문하지 않음 |
| 명시적 보류 — 나중에 결정하자, 지금 묻지 마 | 보류 이유·재개 조건을 남기고 재촉하지 않음 |
| 선택 위임 | 허용된 근거로 선택하고 사용자 확정과 구분 |
| 미응답 — 일부 누락, 아직 답 못함, 잘 모르겠음 | 현재 근거로 추천·대안을 제시하고 기존 미응답 질문부터 다음 묶음에 포함 |

갱신된 답으로 **다음에 결정할 것**을 고른 뒤 위 전문 절차 표를 다시 적용한다. 기술 선택·호환 조건이 새로 생겼거나 기존 근거가 무효화됐다면 다음 제안을 쓰기 전에 [research](references/workflows/research.md)를 읽고 수행한다. 외부 조회 금지는 그 절차의 생략 사유가 아니다. 제공 자료·로컬 원본 등 허용된 근거로 비교하고, 최신성이나 지원 여부를 확인하지 못한 부분은 조건부로 남긴다. 이미 유효한 조사 결과는 재사용한다.

전문 절차에서 얻은 결과를 확정/추천/열린 질문에 합친 뒤 답할 수 있는 독립 질문을 묶는다. 부분 답변에 미정 목록만 반환하지 않는다.

응답은 `이번 답으로 확정된 것 → 필요한 조사 결과 → 기존 미응답과 새로 풀린 질문 묶음` 순서로 구성한다. 미응답에는 선택 이유를 짧게 설명해 답하기 쉽게 만들고, 그 질문을 새로운 질문으로 대체하지 않는다. 질문 도구가 없으면 채팅으로 묻고, 답을 기다리는 턴 종료와 shape 완료를 구분한다. 답을 받기 위해 기다리는 것은 필요하지만 새로 스킬을 호출하라고 요구하지 않는다.

완료를 위해 무관한 질문을 늘리지 않는다. 충분히 결정된 범위는 바로 전달하고, 사용자가 중단·요약·질문 금지·남은 결정 위임을 요청하면 그 범위대로 처리한다. 위임된 선택은 근거 있는 에이전트 선택으로 표시하며 사용자 확정이라고 쓰지 않는다.

## 3. 기술 선택을 닫기

제품 흐름·규모·운영 제약을 알면 구현에 필요한 선택을 식별한다. 언어·프레임워크, 데이터 저장, 배포 플랫폼, 필요한 라이브러리·SDK 중 현재 범위에 영향을 주는 것만 다룬다. 기존 제품은 실제 스택 유지안을 출발점으로 삼고, 충분한 기존 결정까지 다시 비교하지 않는다.

미정인 선택은 공식 자료의 현재 지원 버전·호환 조건·운영 제약을 확인하고, 현실적인 대안과 추천을 비용·복잡도·요구 충족·이행 부담으로 비교한다. 조사 범위는 선택을 바꿀 제약으로 좁히고 그 근거가 확보되면 비교를 반환한다. 부차적 수치의 정밀도를 높이느라 결정을 지연하지 않으며 환산·예상치는 가정과 원 단위를 밝힌다. 최신 버전이라는 이유만으로 선택하지 않는다. 조사 결과로 답할 수 있는 기술 사실을 사용자에게 떠넘기지 말고, 비용·운영 방식 등 사용자의 판단이 필요한 trade-off만 질문에 합친다. 위임받은 선택은 근거와 함께 결정하고 재승인을 요구하지 않는다.

관련 기술 선택마다 기존 결정 유지·사용자 선택·위임받은 선택·명시적 보류를 구분한다. 제품 설계를 바꾸는 스택 미정을 “구현 때 결정”으로 넘기고 shape 완료라고 하지 않는다. 공식 근거에 접근하지 못하면 조사 완료를 주장하지 않고 조건부 제안과 필요한 확인을 남긴다. 제품 요구만 논의하라는 명시적 범위에서는 스택 선정을 강제하지 않는다.

## 4. 재인터뷰 없는 전달

핵심 흐름에는 사용자가 행동할 실제 환경과 결과를 바꾸는 외부 주체·제약을 포함한다. 업무 흐름에서 책임이 넘어가거나 사용자 통제 밖에서 상태가 달라지는 지점을 확인한다. 환경 목록을 전수 질문하지 않으며 상세 전이·검증 시나리오는 후속 spec에서 정의한다.

요청된 위치에 기록하거나 위치가 없으면 답변으로 제공한다. 기존 기록을 갱신할 때 ID와 결정 근거를 보존한다. 크기에 맞게 축약하되 다음 정보를 잃지 않는다.

- 범위·비목표·actors·핵심 흐름과 관련 운영 조건.
- D-ID별 확정 결정, 출처/사용자 답, 이유, 영향을 받는 요구·모듈. 에이전트 추천은 승인된 사실과 분리.
- 용어·불변식·상태 전이·모듈 계약, 공통/도메인 오류 책임 및 대표 실패·복구 검증.
- 기술 후보·기존 유지안·추천·전환 비용과 조사 날짜/버전/공식 출처.
- U-ID별 미정, 영향, 선행 결정, 필요한 답/확인 방법. 근거 없는 수치 목표는 미정으로 남김.
- 후속 spec이 포함해야 할 요구·수용 시나리오 및 공통 기반 의존성. 실제 수행한 확인과 NOTRUN.

사용자가 결정해야 할 중요한 미정이 해소되고 범위·핵심 정상/실패 흐름·도메인 경계·관련 운영 조건과 검증 연결이 설명되면 전달한다. 미정 목록을 작성했다는 사실만으로 이 조건을 충족하지 않는다. 사용자에게 물을 수 있는 제품 결정을 도구 부재나 구현 전이라는 이유로 blocker 처리하지 않는다. 조건·차단 사항을 남긴 중간 전달은 사용자가 중단/요약/질문 금지를 요청했거나, 실제 외부 근거·권한 부재로 진행할 수 없는 부분에 한한다. 남은 답 가능한 독립 질문은 계속한다. 미정이 제품 동작을 바꾸면 전체 설계 확정이라고 보고하지 않는다. 출처와 변경 이유를 점검할 때 [upstream 비교](references/provenance.md)를 읽는다.