Draft Plan 스킬

GitHub 이슈 또는 자연어 주제를 기반으로 논의·QA를 진행하며 구현 계획서를 작성해 프로젝트 private/에 마크다운으로 저장하는 커스텀 플랜 모드 스킬이다.

커스텀 플랜 모드란 — Claude Code 기본 Plan 모드(EnterPlanMode/ExitPlanMode)를 대체한다. 기본 모드가 한 세션 안에서 '계획 → 승인 → 즉시 구현'을 묶는다면, draft-plan은 계획과 구현을 세션 단위로 분리한다. 논의·QA로 계획서를 만들어 private/에 .md로 남기고, 구현은 /clear로 컨텍스트를 비운 뒤 별도 세션에서 그 파일을 읽어 시작한다.

핵심 원칙:

• 이 스킬은 코드를 수정하지 않는다 (allowed-tools에 Edit가 없는 이유다). 계획서 .md 저장을 위해 Write만 허용하며, 계획서 파일 외에는 아무것도 쓰지 않는다.
• 모든 계획서는 목표 → 추적 매트릭스 → 진행 현황 → 변경·결정 로그의 리빙 문서 구조를 갖춘다. 목표·달성기준·성공기준·검증의 네 구분은 유지하되, 달성기준·성공기준·검증은 별도 섹션으로 반복 나열하지 않고 하나의 추적 매트릭스 표의 열로 묶는다 (이 구분과 매트릭스는 Step 3 참고).
• 리빙 문서로 만든다. 계획(목표값)과 진행 현황(실측값)을 갈라, 계획 본문엔 목표값만 두고 변동 값(진행도·개수·버전)은 진행 현황/로그 한 곳에만 둔다(단일 출처). 무엇이 언제 왜 바뀌었는지는 ## 변경·결정 로그에 누적한다 — 진행 상황이 계획 본문에 덧붙어 중구난방이 되는 걸 막는다.
• 초안이 완성되면 승인 게이트 없이 즉시 private/에 .md로 저장한다. 그 뒤 사용자는 파일을 읽고 대화로 피드백한다. (ExitPlanMode 승인을 저장 트리거로 쓰지 않는다)
• 구현은 논의가 끝난 뒤 /clear로 컨텍스트를 초기화하고 새 세션에서 시작한다.
• 계획이 실험으로만 판정 가능한 미검증 기술 전제(외부 SDK·플랫폼·비동기 동작 등) 위에 서 있으면, 본 작업 전에 그 전제를 버리는 최소 코드로 검증하는 스파이크 게이트(커밋 0)를 계획에 포함한다. 사용자에게 묻거나 문서로 풀리는 불확실성은 대상이 아니다 — 그건 조사·QA로 푼다. (Step 3의 ## 기술 리스크 / 스파이크 참고)

실행 절차

Step 1: 입력 파싱

인자 형태에 따라 다르게 처리한다.

이슈 번호 (#35, 35, gh-35):

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 섹션에 브랜치명 명시 여부
• ## 목표 + ## 추적 매트릭스(달성기준·성공기준·검증·현황 열) 존재 여부
• 매트릭스의 각 행이 달성기준↔성공기준↔검증으로 이어지는지(빈 칸=끊긴 고리), 성공 기준 칸과 검증 칸이 섞이지 않았는지 (성공 기준=무엇이 참이어야 하나 / 검증=어떻게 확인하나), 검증 칸에 자동/수동이 구분돼 있는지
• ## 진행 현황 + ## 변경·결정 로그 스캐폴드 존재 여부 (없으면 리빙 문서 구조가 아님)
• ## 커밋 계획 섹션 존재 여부
• ## 코드 리뷰 섹션 존재 여부 (/code-review medium + 위험 지적만 수정 + 커스텀 리뷰 조건부/명시)

보강이 필요하면 Step 2 논의로 진입하고, 이미 완비되어 있으면 그대로 논의를 이어간다.

git 레포가 아닌 디렉터리: 브랜치명 안내를 생략하고 계속 진행한다. 저장은 현재 작업 디렉터리의 private/에 한다 (루트 판별은 pwd로 폴백).

Step 2: 논의 및 조사 (QA)

이 스킬은 논의·QA 중심으로 동작한다. 모든 논의는 일반 대화로 진행한다. 이 스킬은 코드를 수정하지 않으므로(읽기·검색·웹 조사만 함) 별도 Plan Mode 승인 게이트에 의존하지 않는다.

논의 단계 (일반 대화):

• 사용자 질문에 답하고, 방향을 함께 결정한다.
• 코드베이스 파일·심볼·패턴을 Read/grep으로 파악해 근거를 제시한다.
• 이슈 본문에서 언급한 파일·심볼이 실제 코드에 없으면 즉시 피드백한다.
• 외부 근거가 필요하면 웹 검색을 적극 사용한다. 코드베이스·로컬 지식만으로 판단이 서지 않는 경우(라이브러리·프레임워크의 정확한 동작·API 스펙·버전별 변경, 표준/스펙, 에러 메시지의 의미, 베스트 프랙티스 등)에 WebSearch로 찾고 WebFetch로 원문을 확인한다. 단, 출처(URL)를 반드시 남긴다 — 계획서에서 그 근거에 기댄 주장·결정 옆에 인라인으로 출처를 달거나 ## 참고 자료에 모은다. 출처 없는 외부 주장은 계획서에 쓰지 않는다.
• 불명확한 부분은 AskUserQuestion으로 확인한다. 임의 결정하지 않는다.
• 구현 방식에 갈림길이 있으면 한 가지로 단정하지 말고, 선택을 가르는 기준을 세운 뒤 그에 따른 방안을 장단점과 함께 제시해 사용자가 고르게 한다 (추천안을 첫 번째로). 방안 개수는 고정하지 않는다 — 실질적 대안이 없으면 "대안 없음"을 밝힌다.
• 최상위 기술 리스크를 식별한다. 이 계획이 기대는 전제 중 '코드/플랫폼에서 실제로 굴려봐야만 성공·실패를 알 수 있는' 불확실성이 있는지 본다. 있으면 Step 3의 ## 기술 리스크 / 스파이크로 분리하고, 본 작업 앞 커밋 0 게이트로 둔다.

초안 작성·수정:

• 논의가 어느 정도 모이면 곧바로 계획서 초안을 작성한다(Step 3). 초안이 완성되면 승인을 기다리지 않고 Step 5에서 즉시 private/에 저장한다.
• 저장 후 추가 논의·수정이 필요하면 일반 대화로 이어가며, 같은 파일을 덮어쓸지/새 초안으로 다시 저장할지는 사용자 판단에 맡긴다.

외부 블로커로 막히면 부분 저장한다:

• 가장 근본적인 결정 사안이 우리 손 밖의 의존성(백엔드 팀 확인, 외부 응답 대기 등)으로 막혀 논의를 더 진행할 수 없으면, 그때까지 모은 조사·검증 결과(코드 발췌·가정 검증·발견한 사실)를 잃지 말고 계획서 초안(status: 보류)으로 먼저 저장한다.
• 미해결 사안은 ## 결정 사항 / 미해결 질문에 ⬜로, 무엇을 기다리는지는 ## 변경·결정 로그에 '보류'로 남긴다.
• 왜: 근본 사안에서 조기에 이탈하면 그때까지의 양질의 조사가 휘발돼, 다음 세션이 같은 조사를 재실행하게 된다. 부분 저장이 그 재작업을 막는다.

이슈가 있는 경우: 이슈 본문의 "문제 / 작업 범위 / 완료 기준" 섹션을 계획서 골격으로 활용한다. 특히 이슈의 "완료 기준"은 추적 매트릭스 달성 기준 열의 1차 재료로 쓴다.

Step 3: 계획서 본문 작성

계획서 본문을 아래 골격으로 구성한다. 본문은 응답·대화 안에서 작성하고, Step 5에서 그대로 private/에 .md로 저장한다. 골격은 가이드일 뿐이므로 상황에 맞게 섹션을 추가·생략한다. 구조는 계획(목표값) → `---` → 진행 현황·로그(변동값) 두 묶음으로 가른다.

# <한 줄 제목>

> 📌 **요약** — 1~2문장. / **상태** — 계획 수립 (구현 전). / **문서 사용법** — 계획·진행 현황은 항상 최신값만, 결정·변경 이력은 맨 끝 `## 변경·결정 로그`에서 추적.

## 한눈에
- 이 작업이 무엇인지 1~2문장 — 배경지식 없는 독자도 핵심을 잡게

## 배경지식
- 도메인·용어·데이터 흐름을 모르는 사람용으로 풀어서 (용어는 처음 쓸 때 한 줄로 풀이)

## Context
- 이슈: #<n> / <url> (있으면)
- 브랜치: `feat/...`
- 변경의 이유 / 배경

## 목표
- 이 작업이 궁극적으로 달성하려는 것 1~2문장. "왜 하는가"의 종착점. (예: "신규 앱이 Play 스토어 심사를 통과해 배포 가능한 상태가 된다")

## 추적 매트릭스
달성 기준(무엇이 참이어야) ↔ 성공 기준(구현이 무엇을 만족) ↔ 검증(어떻게 확인) ↔ 현황을 **한 행으로** 묶는다. 셋을 따로 나열하지 않고 한 표로 — 같은 항목을 세 번 다시 쓰는 중복이 사라지고, 행 단위로 보면 끊긴 고리(매핑 안 된 성공 기준, 확인 방법 없는 기준)가 즉시 드러난다.

| # | 달성 기준 (무엇이 참이어야) | 성공 기준 (구현이 무엇을 만족) | 검증 (어떻게 확인 · 자동/수동) | 현황 |
|---|---|---|---|---|
| 1 | 구체·측정 가능한 결과 조건 (예: "첫 업로드가 거부 없이 심사 큐에 등록") | 그를 충족할 구현 조건 (예: "업로드 API가 신규 앱 첫 요청에 200 반환") | 자동: 명령/테스트 · 수동: 실기기·눈 (예: "스테이징에 첫 AAB 업로드 후 응답코드 확인") | ⬜ |
| 2 | ... | ... | ... | ⬜ |

> 작성 규칙: 달성 기준은 추상 표현("개선된다", "안정화된다") 금지 — 수치·상태·관찰 가능한 사실로. 성공 기준은 *무엇이 참이어야 하는가*(도달 상태)이고 검증은 *어떻게 확인하는가*(방법)다 — 옆 칸으로 분리돼 섞일 일이 없다. 자동화 가능한 검증은 자동으로 분류, 수동은 실기기·시각 확인이 꼭 필요한 것만.
> 생성 시점엔 **현황 열을 전부 ⬜**로 둔다(구현 전). 구현 세션이 진행하며 ✅/🔶로 갱신한다.

## 현황 분석 (지금 무엇이 문제인가)
- 문제를 **코드 발췌**로 증명한다 — 줄번호(`경로:라인`)만 주지 말고, 관련 코드를 발췌해 코드블록으로 넣고 말로 설명한다. 파일명은 발췌 출처로만 붙인다
- 재사용 후보 (기존 함수·유틸) — 가능하면 핵심 코드를 발췌
- 현재 구조의 문제점

## 결정 사항 / 미해결 질문
- 사용자와 합의된 선택 (✅)
- **대안 비교**: 구현 방식에 갈림길이 있으면 방안을 표(방안 / 장점 / 단점 / 영향)로 비교하고, 선택한 안과 근거를 남긴다
- TBD 항목 (⬜로 명시)
> 여기서 확정된 결정(✅)은 맨 끝 `## 변경·결정 로그`에 한 줄씩 시드한다.

## 기술 리스크 / 스파이크 (해당 시에만)
> 계획이 **실험으로만 판정 가능한 미검증 전제** 위에 설 때만 둔다. 그런 전제가 없으면 이 섹션을 생략한다.
- **검증할 질문**: 가장 불확실한 전제 1~2개 (예: "외부 SDK 콜백이 우리 플러그인→JS까지 실제로 돌아오는가")
- **검증 방법**: 본 구현이 아닌 **버리는 최소 코드**로 그 한 점만 찌른다 — 무엇을 어디까지 만들지 명시
- **통과 기준**: 무엇을 관찰하면 "성립"인가. ⚠️ **통과 신호가 검증 대상 경로를 실제로 거쳤는지**까지 조건에 박는다 — 검증하려던 비동기·앱스위치 경로를 안 타고 즉시 떨어진 신호를 통과로 오판(false positive)하지 않도록
- **실패 시 대안**: 막히면 어느 방안으로 트나
- **타임박스**: 검증에 쓸 상한. 그 안에 통과 신호를 못 보면 실패로 간주한다

## 구현 계획
1. ...
2. ...

## 영향 범위
- 변경 파일 목록
- 잠재 리스크

## 커밋 계획
- 커밋 단위별로 나열 (각 커밋은 컴파일 가능 상태 유지)
- 위 `## 기술 리스크 / 스파이크`가 있으면 그 검증을 **커밋 0(게이트)**로 본 작업 커밋들 앞에 둔다 — 스파이크 통과가 확인돼야 커밋 1~ 본 작업에 진입한다
- 실제 커밋 메시지 작성은 `/syai-commit` 스킬 사용

## 코드 리뷰
구현·검증·커밋을 모두 마친 뒤, 최종 게이트로 코드 품질 정리와 리뷰를 수행한다.
- [ ] `/simplify` 실행 — 변경 코드를 재사용·단순화·효율·altitude 관점에서 정리하고 수정을 적용한다 (품질 전용, 버그는 잡지 않음)
- [ ] `/code-review medium` 실행 — 정확성 버그·보안 등 위험을 검출한다
- [ ] 프로젝트에 커스텀 코드 리뷰 스킬이 있으면 함께 실행 (탐지되면 스킬명 명시)
- [ ] code-review 지적사항 중 **위험한 것만** 수정 — 정확성 버그·보안·데이터 손상·크래시 유발 등. 단순 정리·스타일·효율은 앞서 `/simplify`가 처리했으므로 중복 반영하지 않는다

---

## 진행 현황 (구현 상태 — 생성 시 빈 스캐폴드)
> 구현 시작 전이라 비어 있다. 구현 세션이 이 섹션과 위 추적 매트릭스 '현황' 열을 갱신한다.
> **단일 출처 규칙**: 변동 값(진행도·개수·버전·실측)은 여기와 아래 로그에만 둔다. 위 계획 본문은 *목표값*만 유지한다 — 같은 수치를 두 곳에 적으면 갱신 시 어긋난다.
- **진행 요약**: 구현 전 — 없음
- **빌드 순서 — 계획 대비 실제**: (구현 시작 후 ✅/🔶/⬜로 채움)
- **주요 발견(데이터)**: 없음
- **계획에 없던 추가**: 없음
- **남은 일**: 계획 전체 (아직 미착수)

## 변경·결정 로그 (이력 — 최신 위로, append-only)
계획·현황을 최신값으로 덮어쓸 때, 무엇이 언제 왜 바뀌었는지는 여기에만 쌓는다. 생성 시점 결정들로 시드한다.

| 날짜 | 종류 | 내용 | 영향 |
|---|---|---|---|
| <오늘> | 결정 | (결정 사항에서 시드한 핵심 결정) | <섹션/기준 N> |
| <오늘> | 생성 | 계획 수립 | — |

> 종류 enum: 결정 / 범위조정 / 순서조정 / 보정 / 추가 / 보류 / 생성

계획서 작성 원칙 — 추적 매트릭스 (목표·달성기준·성공기준·검증)

이 네 가지는 서로 다른 질문에 답한다. 한 덩어리로 뭉치면 "무엇을 위해 하는지"도, "됐는지 어떻게 아는지"도 흐려진다. 그래서 구분은 유지하되, 달성기준·성공기준·검증 셋은 별도 섹션으로 반복 나열하지 않고 한 표(추적 매트릭스)의 열로 묶는다. 같은 항목을 세 번 다시 쓰는 중복이 사라지고, 행 단위로 보면 끊긴 고리가 즉시 드러난다. 목표만 1~2문장으로 매트릭스 위에 따로 둔다 — 방향은 표로 적기엔 너무 짧고 추상적이기 때문이다.

핵심 규칙:

1. 목표는 반드시 명시한다. 목표 없는 계획서는 "왜 하는지" 합의 없이 작업만 나열한 것이다. 이슈가 있으면 이슈의 목적을, 없으면 사용자와의 논의에서 목표를 끌어내 한 줄로 박는다.
2. 달성 기준은 구체적이어야 한다. "개선된다"가 아니라 "X가 Y 상태가 된다", "Z 수치가 N 이하가 된다"처럼 관찰·측정 가능해야 한다. 모호하면 충족 여부를 누구도 판정할 수 없다.
3. 성공 기준은 검증이 아니다. 가장 흔한 실수다. 성공 기준은 무엇이 참이어야 하는가(도달 상태)이고, 검증은 그것을 어떻게 확인하는가(방법)다. 매트릭스에서 둘은 옆 칸으로 분리돼 한 칸에 섞일 일이 없다.
4. 한 행이 곧 고리다. 같은 행의 달성 기준 ↔ 성공 기준 ↔ 검증이 이어진다. 빈 칸이 있으면 — 충족할 구현이 없는 달성 기준, 확인 방법 없는 성공 기준 — 그 자리에서 끊긴 고리로 드러난다.

계획서 작성 원칙 — 리빙 문서 (계획 / 진행 현황 / 로그)

계획서는 한 번 쓰고 끝이 아니라 구현이 진행되며 갱신되는 리빙 문서다. 진행 상황이 계획 본문에 덕지덕지 덧붙으면(예: "원랜 N개였는데 지금 M개", 본문과 모순되는 수치) 문서가 중구난방이 된다. 그래서 처음부터 세 묶음으로 가른다:

• 계획(목표·매트릭스·결정·구현계획 등) — 항상 목표값만. 잘 안 바뀐다.
• 진행 현황 — 지금 어디까지 됐나. 실측값만. 구현 세션이 갱신한다.
• 변경·결정 로그 — 무엇이 언제 왜 바뀌었나. append-only, 최신 위로.

생성 시점엔 진행 현황은 빈 스캐폴드(매트릭스 현황 열 전부 ⬜), 로그는 생성 결정으로 시드한다. 변동 값(진행도·개수·버전)은 현황/로그 한 곳에만 둔다(단일 출처) — 계획 본문과 현황에 같은 수치가 따로 적히면 갱신할 때 어긋난다. 이 구조 덕에 나중에 진행 현황이 들어갈 지정된 자리가 있어, 계획에 덧붙어 흐트러지지 않는다.

보고서 작성 원칙 — 코드 발췌·자립 구성

보고서는 코드를 직접 열어보지 않는 독자(본인·리뷰어)도 단독으로 이해할 수 있어야 한다. 사용자는 보고서만 읽고 코드를 열어보지 않는다.

1. 줄번호 대신 코드 발췌 — 경로:라인 줄번호만 주면 독자가 IDE를 켜서 찾아야 해 번거롭다. 현황·문제를 짚을 땐 해당 코드를 발췌해 코드블록으로 넣고 말로 설명한다. 파일명은 발췌가 어디서 왔는지 맥락으로만 붙인다.
2. 자립적 구성 — 보고서만 읽어도 ① 배경지식(도메인·용어·데이터 흐름) ② 문제(지금 코드가 무엇을 어떻게 하고 있어 왜 문제인지, 발췌로 증명) ③ 구현하고자 하는 것(목표·해결 방향)을 파악할 수 있게 한다. 맨 앞 "한눈에 / 배경지식" 섹션에서 용어와 흐름을 먼저 깐다.
3. 재사용할 기존 패턴도 가능하면 핵심 코드를 발췌해 "이미 이런 게 있다"를 눈으로 보이게 한다.

코드 리뷰 섹션 작성 — 커스텀 스킬 탐지 (하이브리드)

## 코드 리뷰는 구현 세션이 모든 작업·커밋을 끝낸 뒤 실행할 마지막 단계다. draft-plan은 리뷰를 직접 실행하지 않고, 아래 항목을 계획서에 적기만 한다.

1. 단순화 먼저 — `/simplify`

   - [ ] `/simplify` 실행 — 변경 코드를 재사용·단순화·효율·altitude 관점에서 정리하고 수정 적용

/simplify 는 버그를 찾지 않고 코드 품질만 다듬는다(재사용·단순화·효율 cleanup을 working tree 에 적용). 버그 검출은 다음 /code-review 가 맡는다. 단순화를 먼저 돌려 군더더기를 걷어낸 뒤 리뷰하면, 리뷰가 본질적 위험에 집중된다.

1. 빌트인 — 항상 `medium` 으로 명시

   - [ ] `/code-review medium` 실행

medium 은 적은 수의 고신뢰 지적만 내므로 노이즈가 적다. 변경 규모가 매우 크면 구현 세션 판단으로 /code-review high 까지 올려도 된다. PR 코멘트가 필요하면 --comment 를 붙인다.

1. 커스텀 — "있다면" 조건부

현재 세션에서 사용 가능한 스킬 목록을 살펴, 빌트인 /code-review 외에 프로젝트·팀 전용 코드 리뷰 스킬(예: review-code)이 있는지 확인한다. 불확실하면 .claude/skills/ 와 설치된 플러그인을 grep으로 추가 확인한다.

• 탐지 성공 → 스킬 이름을 그대로 명시한다.

     - [ ] `/review-code` 실행 후 함께 검토

• 탐지 실패/불확실 → 조건부 문구를 남겨 구현 세션이 판단하게 한다.

     - [ ] 프로젝트에 커스텀 코드 리뷰 스킬이 있으면 함께 실행

1. 수정 범위 — 위험한 지적만

   - [ ] 지적사항 중 위험한 것만 수정 — 정확성 버그·보안·데이터 손상·크래시 유발 등. 단순 정리·스타일·효율 제안은 반영하지 않거나 별도 이슈로 분리한다

--fix 는 모든 지적을 무차별로 working tree 에 적용하므로 쓰지 않는다. 위험한 지적만 골라 손으로 반영해야 의도치 않은 리팩터링 churn 을 막는다.

코드 리뷰는 "모든 작업을 마친 뒤"의 게이트다. 계획서는 실행 지시만 담고, 실제 리뷰·수정은 /clear 이후 구현 세션이 수행한다.

Step 4: 브랜치명 결정

계획서 본문 작성 중 또는 직후, 이 작업을 위한 브랜치명을 결정하여 계획서에 포함한다.

브랜치명 생성 규칙 (git-convention 스킬 컨벤션 준수):

• slug: 영문 소문자 + 하이픈, 40자 이하, 한글은 영문 키워드 추출
• 이슈 레이블에 fix, bug, hotfix 가 있으면 fix/ 접두사 사용
• 프로젝트에 Jira 이슈 키(DEV-123)가 있다면 feat/DEV-123-<slug> 형식 우선

결정된 브랜치명과 커밋 컨벤션을 계획서 Context 섹션에 다음과 같이 명시한다:

## Context
- 이슈: #35 / <url>
- 브랜치: `fix/35-measure-screen-back-press`

git checkout -b fix/35-measure-screen-back-press

- 변경의 이유 / 배경

Step 5: 초안 완성 즉시 private/에 저장

초안(목표·추적 매트릭스·진행 현황·로그를 포함한 본문)이 완성되면 승인을 기다리지 않고 곧바로 프로젝트 private/에 .md로 저장한다. 사용자는 파일을 읽고 대화로 피드백한다 — 그 편이 더 빠르고, 화면 승인 클릭을 없앤다.

저장 전 자체 점검 (저장 직전 한 번 확인):

• ## 목표가 한 줄 이상 박혀 있는가
• ## 추적 매트릭스의 달성 기준이 구체적·측정 가능한가(추상 표현 아님), 각 행이 달성 기준 ↔ 성공 기준 ↔ 검증으로 이어지는가(빈 칸 없음), 성공 기준 칸과 검증 칸이 섞이지 않았는가, 현황 열이 생성 시 전부 ⬜인가
• ## 진행 현황(빈 스캐폴드) + ## 변경·결정 로그(생성 결정 시드)가 들어 있는가
• 웹 검색으로 가져온 외부 주장에 출처(URL)가 달려 있는가

저장 절차:

ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
mkdir -p "$ROOT/private"
DATE="$(date +%Y%m%d)"

• 파일명: private/plan-<slug>-<YYYYMMDD>.md — <slug>는 Step 4 브랜치명 slug 재사용(예: feat/35-ecg-offline-queue → 35-ecg-offline-queue). git 레포가 아니면 주제 slug.
• 본문 맨 위에 YAML 프론트매터를 둔다:

  ---
  type: plan
  title: <계획서 제목>
  project: <프로젝트명>
  created: YYYY-MM-DD
  status: 초안
  ---

• 그 아래에 계획서 전문을 표준 마크다운 그대로 Write한다 — 파이프 표·> 콜아웃을 변환 없이 그대로 둔다.

저장 후 사용자에게 저장된 파일 경로를 알리고 다음과 같이 안내한다: "계획서를 `<경로>`에 저장했습니다. 파일을 열어 검토하고, 수정할 점은 이 대화에서 말씀해 주세요 — 반영해 같은 파일을 갱신합니다. 구현은 `/clear` 후 새 세션에서 이 파일을 읽어 시작하세요." 코드 구현은 시작하지 않는다.

피드백을 반영할 땐 같은 경로로 다시 저장(덮어쓰기)하거나, 리빙 문서 원칙대로 ## 변경·결정 로그에 누적한다.

주의사항

• 구현하지 않는다. 코드 파일을 생성·수정하지 않는다. Write는 오직 private/의 계획서 .md 저장에만 쓴다.
• 목표를 명시한다. 목표·추적 매트릭스(달성기준·성공기준·검증)가 없는 계획서는 저장하지 않는다. 매트릭스에서 성공 기준 열과 검증 열은 별도 칸이다 — 섞지 않는다.
• 리빙 문서 구조를 포함한다. 생성 시 진행 현황은 빈 스캐폴드(매트릭스 현황 열 ⬜), 변경·결정 로그는 생성 시점 결정으로 시드한다. 변동 값은 진행 현황/로그 한 곳에만 둔다(단일 출처).
• 이슈 본문에 모호한 부분이 있으면 임의 결정하지 않고 반드시 사용자에게 확인한다.
• 코드베이스 분석 중 이슈 내용과 괴리(없는 파일·심볼 등)가 발견되면 즉시 피드백한다.
• 외부 근거가 필요하면 WebSearch/WebFetch를 적극 쓰되, 그 근거에 기댄 주장 옆에 출처(URL)를 반드시 남긴다. 출처 없는 외부 주장은 쓰지 않는다.
• 초안이 완성되면 승인 게이트 없이 즉시 private/에 저장한다. 별도 승인 클릭을 받지 않으며, 피드백은 대화로 받는다.
• 브랜치명은 git-convention 스킬 컨벤션을 따른다.
• 커밋 메시지 작성은 syai-commit 스킬이 담당한다. 계획서의 커밋 계획 섹션에는 메시지 형식이 아닌 작업 단위(무엇을 나눌지)만 기술한다.
• 계획서 끝에 ## 코드 리뷰 섹션을 넣어 "모든 작업·커밋 완료 후 /code-review(및 커스텀 리뷰 스킬)를 실행"하도록 지시만 적는다. draft-plan이 직접 코드 리뷰를 실행하지 않는다 — 실행은 구현 세션의 몫이다.
• 계획서는 프로젝트 private/에 로컬 저장한다 — 외부 동기화·노션 없이.