draft-planlisted

# Draft Plan 스킬 GitHub 이슈 또는 자연어 주제를 기반으로 논의·QA 자료를 준비한 뒤, 현재 하네스의 Plan Mode에서 **PRD 포맷 계획서**를 적용하는 스킬이다. > **Plan Mode 애드온이다 — 대체가 아니다.** 계획 모드 진입·이탈 도구가 제공되면 그 흐름을 > 그대로 쓰고, **최종 계획 작성 단계에서만** 이 스킬의 PRD 템플릿을 적용한다. 도구가 없는 > 하네스에서는 `references/plan-mode-fallback.md`가 승인과 인계를 보완한다. **핵심 원칙**: - 기본은 세션을 분리하지 않는다. 다만 하네스의 계획 승인 자체가 새 컨텍스트로 인계하는 방식이면 그 규칙을 존중하고 완결 계획서 파일을 인계 매체로 쓴다. - 계획 파일은 Plan Mode가 지정한 경로에 먼저 작성한다. **계획서는 구현 세부만이 아니라 논의·판단 근거·결정 컨텍스트를 담으므로, 프로젝트 지침 파일이 명시하는 계획 저장 관례가 있으면 완결된 계획서를 그 위치에도 저장하는 걸 기본으로 한다**(승인 후 또는 보류 시 — Step 2·5 참고). 그런 관례가 없는 프로젝트는 새로 만들지 않고 기존대로 Plan Mode 위치에만 둔다. 하네스가 계획 파일 위치를 주지 않으면 `references/plan-mode-fallback.md`의 저장 사다리를 따른다. - **계획서는 실행자가 아니라 의사결정자가 읽는다.** 사람은 방향성·설계·리뷰 위주로 계획서를 다루고, 실행 세부(어떤 파일을 어떤 순서로 건드릴지 등)는 구현 단계에서 그때그때 정해진다. 그래서 계획서는 문제 배경 → 목표/비목표 → 요구사항 → 트레이드오프 → 성공 지표를 파악해 승인·수정 판단을 내리는 데 필요한 정보만 담고, 실행 순서표·진행 추적 장치는 담지 않는다. (현재 하네스의 상시 로드 지침에 같은 원칙이 있으면 함께 따른다.) - **기본 골격은 5개 절이다** — 배경/문제 정의 / 목표(Goals) / 비목표(Non-Goals) / 요구사항 / 성공 지표·검증 방법 / 리스크·오픈 이슈. 번호를 붙여 읽는 순서와 절 순서를 맞춘다 (Step 3 참고). - **설계 판단은 주제별로 묶어 `결정 | 이유` 표로 낸다.** 나열식 문단으로 이어 쓰면 갈림길이 몇 개인지, 어디까지가 한 판단인지 안 보인다. - **코드 전문·프롬프트 전문·완성된 diff·파일별 작업 순서표는 넣지 않는다.** 그런 디테일은 실행 단계에서 실제로 나오고 PR 리뷰 때 diff로 논의한다. 계획서에 다 담으면 방향이 디테일에 묻힌다. 이 배제 대상은 **완성된 코드 본문·내부 호출 순서·file:line 참조**이지, 공개 인터페이스 자체가 아니다 — 새로 만들거나 바꾸는 **public API(함수/클래스 시그니처, CLI 옵션 등)** 는 그 인터페이스가 왜 필요한지 설명하는 `## 3. 요구사항`의 결정 문장 안에 자연스럽게 녹여 보여준다. 별도 "핵심 인터페이스" 같은 절로 따로