inception

/oculpm:inception

$ARGUMENTS 가 아이디어다 (없으면 한 줄만 묻는다). 산출물은 문서가 아니라 /oculpm:next 가 그대로 도는 플랜 — 완료 조건은 결과, 확인 명령은 지금 빨강.

.oculpm/ 이 없으면 "ocul-pm 으로 추적할까요?" 를 묻고 동의할 때만 project_init(confirm=true).

묻는 법: 한 번에 결정 트리의 프론티어만(답해야 다음이 열리는 것), 질문마다 추천 답과 근거. 코드·검색으로 알 수 있는 것은 묻지 말고 알아낸다.

1. 고도 — 결과

"이게 되면 그다음 무엇이 일어나야 하나?" 를 두 번 묻는다 ("로그인" → "첫날 다시 온다"). 마지막 답이 완료 조건 후보. 사람이 매번 봐 줘야 아는 결과면, 모델이 혼자 피드백을 받을 통로(테스트·크래시 로그·재현 환경·버전→커밋 매핑)를 계획에 넣는다.

2. 깊이 — 네 질문

(a) 최고의 전문가라면 안 시킨 무엇을 하나 (b) 요약 대신 어떤 가장 날것의 재료(로그·실데이터·원문 스펙·경쟁 제품 실측)에서 시작하나 (c) 어떤 방법·도구(프로파일러·DB·통계·하네스)를 쓰나 (d) 나나 모델이 아닌 무엇이 결과가 맞다고 보여 주나. 답한 뒤 목표를 "더 크게가 아니라 더 깊게" 다시 쓴다.

3. 범위 — 동사와 방법

목표를 동사로 ("대시보드" → "바쁜 사람이 3분 안에 다음 결정을 믿게 한다"). 그 동사에 닿는 분야 둘~셋의 방법을 가져온다 (사용성 연구의 5인 과제 관찰, 통계의 검정력 계산). 역할극 금지 — "전문가처럼" 이 아니라 그 전문가가 하는 조사를 한다.

4. 환경 — 기억이 아니라 검색

스택을 골라야 하면 웹 검색으로 후보 2~3개의 현재 안정 버전·공식 스캐폴드·테스트 러너·흔한 함정을 확인해 버전·출처와 추천 하나를 붙여 고르게 한다.

5. 어려운 숫자 목표

측정 가능한 한 줄, 합리적인 것보다 한 단계 어렵게 (5s → 200ms). 그것이 합리적이라고 적는다 — 못 닿아도 된다, 어디까지 갔는지가 남는다.

6. 판정 먼저 → plan_create

• done_when = 1의 결과 + 5의 숫자. check = 통과/실패를 내는 명령.
• 첫 리프 = 그 확인 명령(하네스·벤치·재현 스크립트)을 만들고 지금 실패(빨강)함을 보이기. 빨강을 못 보이면 판정이 아니다.
• 나머지 리프는 반나절 이하의 검증 가능한 동사구("이메일 로그인 happy-path 가 동작한다"), 구현 순서, 리프마다 확인 방법. phase → 항목 → 하위 3단계까지.
• 고른 선택·근거는 description 12문장, 큰 결정은 만든 뒤 플랜의 ## 결정 블록. 이 프로젝트만의 근거 있는 제약(확정 버전·금지 라이브러리)은 .claude/rules/<name>.md 12개(paths 로 범위).

끝

완료 조건·확인 명령·첫 리프를 보여 주고 제안: "/oculpm:next 로 빨간 판정부터 — /oculpm:next until-done 이면 판정이 통과할 때까지 이어 돕니다." 구현은 하지 않는다. 기능 추가는 6부터(낯선 영역이면 1부터).