Project Inception

---
name: project-inception
description: Use when kicking off a new project or feature area in an ocul-pm tracked project (.oculpm/ present) — research the stack landscape via web search, then converse with the user (research-backed choices) to settle the optimal spec, and seed a discussion doc, a detailed 3-depth plan (plan_create), EVALS.md done-criteria and starter .claude/rules.
---

# project-inception — 아이디어를 설계 산출물로

새 프로젝트(또는 새 기능 영역)를 시작할 때, 아이디어를 ocul-pm 파일 체계에 **그대로 물리는** 4종 산출물로 바꿉니다. 성공 기준은 문서를 "만드는 것"이 아니라 — **기존 도구가 무수정으로 소비하는 것**입니다 (discussion→플래너 승격, EVALS→회고 추이, rules→에이전트 자동 로드).

## STAGE 0 — 문제 파악 (리서치 방향을 정할 만큼만)

`.oculpm/` 이 없는 새 저장소라면 먼저 사용자에게 **"이 프로젝트를 ocul-pm 으로 추적할까요?"** 를 물어보고, 동의를 받으면 `project_init` 도구(confirm=true)로 초기화합니다 — 동의 없이/선제적으로 호출하지 않습니다. 도구가 없으면 ocul-pm 앱에서 프로젝트 추가를 안내하세요.

**정보가 부족한 채 계획을 지어내지 마세요.** 단, 여기서는 리서치의 방향을 정하는 데 필요한 최소만 묻습니다 — 문제(누구의 어떤 문제), 완성의 정의(첫 데모 한 장면), 비목표, 플랫폼·강한 제약(기한·오프라인·보안). 아이디어에 이미 담긴 것은 다시 묻지 않습니다. 답을 받아 `.oculpm/agents/discussion-spec.md` 규격대로 `.oculpm/discussion/<slug>/discussion.md` 를 만들고 `## 문제 정의` 를 채웁니다.

## STAGE 1 — 환경 탐색 (웹 리서치)

사용자에게 더 묻기 **전에**, 웹 검색(WebSearch/WebFetch)으로 환경을 직접 조사합니다. 문제에 맞는 후보 스택 2~3개에 대해:

- 현재 안정 버전과 권장 조합 (프레임워크 + 빌드 도구 + 테스트 러너)
- 공식 스캐폴드 명령·battle-tested 보일러플레이트
- 해당 도메인의 표준 라이브러리·베스트 프랙티스·흔한 함정
- 필요한 개발 환경 (런타임 버전, 패키지 매니저, 필수 CLI)

조사 결과를 discussion 의 `### 방안 {#opt-id}` 후보안에 **버전·출처와 함께** 기록합니다. 기억 속 버전을 단정하지 말 것 — 검색으로 확인한 것만 적습니다.

## STAGE 2 — 대화로 최적 사양 확정

리서치 근거를 들고 사용자와 대화해 사양을 함께 확정합니다. 질문은 기능
나열이 아니라 **제품 렌즈**로 팝니다 — 누가 쓰는가, 어떤 가치 가설인가, 안
만들면 사용자는 뭘 하는가(비사용 대안), 성공을 무엇으로 알아보는가. 남은 미결(선호 언어·프레임워크, 규모, 비용 허용치, 기존 자산)을 **리서치가 뒷받침하는 객관식**으로 한 번에 묻습니다 — "무엇을 쓸까요?"가 아니라 "A(버전·근거) vs B(버전·근거), 이 상황엔 A 추천"처럼. 모호한 답은 재질문하고, 추측으로 메꾸지 않습니다. 사용자가 방안을 고르면 `## 결론` 을 쓰고 status 를 resolved 로. **증거
게이트**: 결론·계획의 모든 주장에는 근거(조사 출처·사용자 답변·측정)를
병기합니다 — 근거 없는 수식어("빠르고 확장 가능한")는 쓰지 않습니다.

## STAGE 3 — 계획 (plan_create, 3-depth 로 매우 자세히)

결론을 **3-depth 계획**으로: `plan_create` MCP 도구로 phases(마일스톤) → items(작업) → children(하위 작업, 1단계)을 만듭니다. 구현이 이 계획을 따라가므로 **자세할수록 좋습니다** — 리프는 반나절 이하 단위의 "검증 가능한 동사구"("로그인"이 아니라 "이메일 로그인 happy-path 가 동작한다"), 구현 순서대로 배열하고, 리프마다 확인 방법을 항목 문구에 담습니다 — 실행할 명령(테스트/빌드) 또는 재현 시나리오가 문구에서 읽혀야 `/oculpm:next` 가 완료 기준으로 씁니다. Phase 1 의 첫 항목은 "리서치에서 확정한 버전으로 환경 구성·스캐폴드". 도구가 없으면 AGENTS.md §4 의 폴백 규격으로 직접 작성.

## STAGE 4 — 완료 정의 (EVALS.md)

프로젝트 루트에 `EVALS.md` 를 만듭니다: 결론의 "완성의 정의"를 **실행/재현 가능한 평가 항목**(체크리스트/시나리오)으로 옮기고, 맨 아래에 기록 표를 둡니다:

| 날짜 | 스위트 | 통과 | 메모 |
|---|---|---|---|

이 표의 형식(날짜 · 스위트 · N/M)은 바꾸지 말 것 — ocul-pm 회고 화면이 그대로 파싱해 추이를 그립니다 (run-evals 스킬이 실행·기록을 담당).

## STAGE 5 — 초기 규칙 (.claude/rules)

리서치·대화에서 확정된 것 중 **근거가 있는 것만** 1~3개를 `.claude/rules/<name>.md` 로 남깁니다 — 예: 확정한 런타임/프레임워크 버전, 도메인 제약, 금지 라이브러리. 조건부 규칙은 frontmatter `paths: ["src/api/**"]` 로 스코프를 좁힙니다 (없으면 상시 로드 — 토큰 비용을 의식할 것). 범용 조언("좋은 코드를 쓰자")은 금지 — 이 프로젝트에서만 참인 제약만.

사양이 확정되면 사용자에게 안내하세요: 확정 스택에 맞는 검증된 스킬(언어 패턴·테스팅·보안)을 **ocul-pm 앱의 스킬 샵(스킬·규칙 → 샵 탭)이 스택 감지로 추천**합니다 — 검색·미리보기 후 원클릭 설치 (설치된 스킬의 설명은 매 세션 컨텍스트에 실리므로 2~3개만).

## 반복 루프 — 기능 추가는 STAGE 3 부터

인셉션은 프로젝트당 한 번이지만, **기능 추가마다 계획→구현 루프는 반복**됩니다: 새 기능 영역이 생기면 STAGE 3 로 바로 가서 기존 플랜에 phase/항목을 더하거나(plan_create/직접 편집) 새 플랜을 만들고 → 리프 단위로 구현(플래너 ▶실행 디스패치 또는 plan_status 로 다음 미완 리프 확인) → 일지 → plan_update. STAGE 0~2 는 그 영역이 낯설 때만(새 도메인·새 스택) 필요한 만큼 재실행합니다.

## 금지

- 리서치 없이 기억으로 버전·도구를 단정하지 말 것 · 대화를 건너뛰고 추측으로 사양을 정하지 말 것.
- discussion 에 진척/실행 로그를 쌓지 말 것 — 그건 플래너·일지의 일.
- 산출물 4종(discussion·plan·EVALS.md·rules) 외의 문서를 남발하지 말 것.
- 평가 기준을 통과 가능하게 미리 약화하지 말 것 — 애매하면 사용자에게 묻는다.
- 이 스킬은 **설계 시드까지만** — 구현은 플래너의 ▶실행(디스패치)으로 항목 단위 진행.