draft-planlisted

# Draft Plan 스킬 GitHub 이슈 또는 자연어 주제를 기반으로 논의·QA를 진행하며 구현 계획서를 작성하고, `notion-report` 스킬을 통해 Notion Reports DB(`$NOTION_REPORTS_DS_ID`)에 보고서로 저장하는 스킬이다. **핵심 원칙**: - 이 스킬은 **문서 편집 도구**다. 코드를 수정하거나 구현을 시작하지 않는다 (allowed-tools에 Edit/Write가 없는 이유다). - 모든 계획서는 **목표 → 목표 달성 기준 → 구현 성공 기준 → 검증**의 흐름을 갖춘다. 목표 없는 계획, 기준 없는 목표, 검증과 뒤섞인 성공 기준은 만들지 않는다. (이 네 가지의 구분은 Step 3 참고) - 초안이 완성되면 **승인 게이트 없이 즉시** `notion-report`로 Notion에 저장한다. 그 뒤 사용자는 노션에서 읽고 **댓글로 피드백**한다. (`ExitPlanMode` 승인을 저장 트리거로 쓰지 않는다) - 구현은 논의가 끝난 뒤 `/clear`로 컨텍스트를 초기화하고 새 세션에서 시작한다. - 계획이 **실험으로만 판정 가능한 미검증 기술 전제**(외부 SDK·플랫폼·비동기 동작 등) 위에 서 있으면, 본 작업 전에 그 전제를 버리는 최소 코드로 검증하는 **스파이크 게이트(커밋 0)**를 계획에 포함한다. 사용자에게 묻거나 문서로 풀리는 불확실성은 대상이 아니다 — 그건 조사·QA로 푼다. (Step 3의 `## 기술 리스크 / 스파이크` 참고) --- ## 실행 절차 ### Step 1: 입력 파싱 인자 형태에 따라 다르게 처리한다. **이슈 번호** (`#35`, `35`, `gh-35`): ```bash gh issue view <number> --json number,title,body,labels,url ``` 가져온 `number`, `title`, `body`, `labels`, `url` 을 이후 분석 컨텍스트로 보유한다. **GitHub URL** (`https://github.com/.../issues/35`): owner/repo/number를 파싱해 위와 동일하게 `gh issue view` 로 조회한다. **자연어 주제** (예: "로그인 화면 개선"): 그대로 주제 문자열로 사용하고 이슈 메타데이터는 없는 것으로 처리한다. **인자 없음**: 사용자에게 무엇에 대한 계획서인지 묻는다. **기존 계획서 파일 경로** (`@path/to/plan.md` 등 로컬 계획서 .md): 파일을 Read로 읽은 뒤 아래 항목을 점검하고, 누락된 항목을 사용자에게 알린 다음 보강 여부를 확인한다. - YAML 프론트매터 (`created`, `status`) 존재 여부 - Context 섹션에 브랜치명 명시 여부 - `## 목표` / `## 목표 달성 기준` / `## 구현 성공 기준` 세 섹션 존재 여부 - 구현 성공 기준이 각 달성 기준에 매핑되어 있는지, 그리고 **검증과 섞이지 않았는지** (성공 기준=무엇이 참이어야 하나 / 검