plan-format

name	plan-format
description	기획 입력이 기능설계서와 정책서 로컬 초안으로 변환 가능한지 판단해야 할 때 사용한다.
argument-hint	<기획 입력 | 파일 | 디렉터리>

plan-format

기획 입력을 정책서 + 기능설계서 두 로컬 초안으로 변환하는 formatter 스킬이다. config strict-exit, Gate First, dispatch + main 직접 작성·main 검증 후 저장의 3-step 흐름으로 동작한다.

1. .product-team-kit/config.json 존재·유효성 확인 (없으면 종료)
2. 입력 기반 변환 가능 여부 Gate (불가 시 종료)
3. 템플릿 변환·저장 + 부족 항목 화면 출력

산출물은 <outputRoot>/ 아래 로컬 초안이며 공식 팀 문서가 아니다. Product Docs SSOT 충돌과 용어 일관성 검토는 plan-review 책임이다.

진행 표시 원칙

실행 중 사용자에게 보이는 narration은 구조화된 step 헤더 한 줄로만 표시한다. 각 step 진입 시점에 정확히 한 줄을 출력한다. 마지막 step에서 references/output-contract.md 템플릿 1회 출력한다.

형식: Step N: <step 이름> (분기별 총 step 수가 도중 변동되므로 denominator 표기 금지)

분기별 step 시퀀스:

• config 치명: Step 1: 설정 확인 → Step 2: 종료 출력
• gate 보류: Step 1: 설정 확인 → Step 2: gate 판정 → Step 3: 종료 출력
• 검증 실패 보류: Step 1: 설정 확인 → Step 2: gate 판정 → Step 3: dispatch → Step 4: 두 문서 작성·검증 → Step 5: 보류 출력
• 저장 완료/실패: Step 1: 설정 확인 → Step 2: gate 판정 → Step 3: dispatch → Step 4: 두 문서 작성·검증 → Step 5: 저장 절차 → Step 6: 종료 출력

step 헤더 외 금지 항목 (전부 출력 금지):

• file IO 안내: templates read, templates 병렬 read, storage-contract read, output-contract read, timestamp 확인
• dispatch 중간 산출 echo: dispatch 결과: ..., 안전기능명: ..., 라벨 매핑: ..., 용어 사전: ...
• 자체 검증 상세 echo: 빈 골격 검사 통과, 구조 일치 ✓, 중복 없음, cross-bleed 없음
• 저장 sub-action 보고: staging folder 생성, verify OK, rename 완료
• 본문 echo: [기능설계서 초안], [정책서 초안], markdown 섹션, 표, admonition metadata 줄 (Write 툴 호출 결과는 Claude Code UI가 자동 표시 — 별도 echo 금지)
• 추론·계획 narration: 이제 ~ 한다, ~ 직전, ~ 시작, ~ 통과 후 ~ 진행, ~ 완료 (디테일)

Read/Write/Bash 툴 호출은 Claude Code UI가 자동 표시하므로 텍스트 보고 불필요. Tool 호출 사이에 진행 안내 텍스트 삽입 금지.

분기 결정 시점:

• 각 step 진입 시 N=현재 step 번호로 헤더 1회 출력. denominator 없으므로 분기 변경 시 이전 헤더 정정 불필요.
• 분기 단축 시 남은 step은 그대로 생략한다 (예: config 치명 발견 시 Step 2: 종료 출력만 출력하고 Step 3 이후 생략).

사용자가 보는 turn 마지막 결과는 마지막 step 직후 references/output-contract.md 템플릿 1회 출력이다. 분기별 템플릿:

• config 치명 → "설정 없음" 템플릿
• gate 보류 → "저장 보류" 템플릿
• 검증 실패 보류 → "저장 보류" 템플릿
• 저장 완료 → "저장 완료" 템플릿
• 저장 실패 → "저장 실패" 템플릿

템플릿을 감싼 ```text ... ``` fence는 docs 가독성용이며 실제 출력에 포함하지 않는다. fence 내부 본문만 raw markdown으로 출력한다 (output-contract.md ## 출력 금지 — fence wrapper). 표 cell 안 |는 backtick·HTML 안에 있어도 \|로 escape한다 (output-contract.md ## 표 cell escape).

예외: 사용자 권한 승인 필요 (Bash, Write 툴 호출 시 Claude Code 권한 prompt)는 자동 표시되며 SKILL이 제어 불가. 모델이 추가 narration 붙이지 않으면 step 헤더 + 권한 prompt만 보인다.

Lazy read 원칙

각 파일은 실제 필요한 step에서만 읽는다. 선행 step에서 미리 묶어 읽지 않는다. 종료 분기에서 안 쓰는 파일을 읽으면 토큰 낭비이며 금지한다.

파일	읽는 시점	용도
<project-root>/.product-team-kit/config.json	step 1 시작	strict-exit 판정
입력 본문 / 파일 / 디렉터리	step 2 시작	gate 판정과 dispatch 입력
templates/기능설계서.md, templates/정책서.md	step 3.2 본문 작성 직전 (병렬 read)	본문 작성 시 섹션·metadata 고정, 표 의미 보존 기준 확인
references/storage-contract.md	step 3.2 main 검증 통과 후 저장 절차 진입 직전	staging→write→verify→rename 절차
references/output-contract.md	종료 출력 직전 (분기 확정 후 1회)	"설정 없음" / "저장 보류" / "저장 완료" 템플릿

분기별 실제 읽기 순서:

• config fail: config.json → output-contract.md → 종료
• gate 보류: config.json → 입력 → output-contract.md → 종료
• 정상 저장: config.json → 입력 → templates/* (병렬) → main 직접 작성·main 검증 → storage-contract.md → 저장 → output-contract.md → 종료

호출

• Claude Code: /product-team-kit:plan-format <기획 입력 또는 파일/디렉터리 경로>
• Codex: $plan-format <기획 입력 또는 파일/디렉터리 경로>

기능명은 별도 인자로 받지 않는다. 입력 본문, 파일명, 디렉터리명에서 추출한다.

1. 설정 확인 (strict-exit)

진행 표시 매핑: Step 1: 설정 확인 헤더 1회 출력 후 진행 (### 진행 표시 원칙).

이 step에서 읽는 파일: <project-root>/.product-team-kit/config.json 하나만. templates·references·입력 파일은 읽지 않는다.

<project-root>/.product-team-kit/config.json을 읽는다. <project-root>는 입력 기준 git root 또는 현재 작업 디렉터리다 (../../references/config-contract.md 동일 규칙).

다음 중 하나라도 해당하면 즉시 종료한다. 파일 생성·gate 진행·이후 step 모두 수행하지 않는다.

• 파일 없음
• JSON 파싱 실패
• version 미일치 또는 누락
• outputRoot 검증 거부 (절대경로, .., 빈 문자열, 경로 구분자 포함, 비문자열)

종료 출력은 references/output-contract.md의 "설정 없음" 템플릿을 사용한다. 이 시점에 output-contract.md를 읽어 템플릿을 적용하고 set-config 안내를 포함한다. 종료 분기가 확정된 뒤에만 읽는다.

비치명 검증 거부 (unknown key, ssot 배열 element 비문자열)는 default fallback + [설정 경고] 블록으로 처리한다. 이 경우는 종료하지 않고 step 2로 진행한다.

2. Gate First 변환 가능 판정

진행 표시 매핑: Step 2: gate 판정 헤더 1회 출력 후 진행. 미통과 시 다음 헤더는 Step 3: 종료 출력로 분기 단축 (### 진행 표시 원칙).

이 step에서 읽는 파일: 입력 (텍스트·파일·디렉터리). templates·references는 아직 읽지 않는다.

입력을 gate용 경량 분류(기능 목적·적용 대상·핵심 행동·판단 기준 식별 수준, ## 입력 처리 참조)만 수행한 뒤 아래 4 조건을 모두 충족하는지 확인한다. 라벨 매핑·용어 사전·안전기능명 등 본격 dispatch는 step 3.1에서 수행한다. 통과 전에는 저장 폴더·임시 파일을 만들지 않는다.

입력 크기·파일 개수 상한 없음은 의도된 계약이다. 디렉터리 입력은 기본 제외 경로와 바이너리·권한 오류·UTF-8 디코딩 실패 파일을 제외한 뒤, 남은 읽을 수 있는 UTF-8 텍스트 파일을 경로명·개수·크기 기준으로 더 줄이지 않고 모두 읽는다. 중간 truncate, 첫 N개 파일만 읽기, 일부 파일 샘플링 금지. 다만 gate 판정은 전체 입력을 직접 문서 본문으로 끌고 오지 않고, 전체 입력을 확인한 뒤 기능 후보·역할·행동·결과·판단 기준만 내부 근거 맵으로 압축해 사용한다. 읽기 대상 텍스트 전체를 확인하지 못한 경우에는 일부 근거만으로 저장하지 말고 저장 보류로 종료한다.

• 기능 목적 또는 기능명: 기능명, 문제, 목적 중 한 문장 요약 가능
• 적용 대상 또는 업무 범위: 사용자, 역할, 조직, 업무 대상, 포함 범위 중 확인 가능
• 핵심 사용자 행동과 기대 결과: 사용자 행동 1개와 사용자에게 보이는 결과 1개 이상
• 주요 조건/정책/제약: 허용/금지/조건/예외/제한/판단 기준 중 업무 판단 기준 1개 이상

추가로 두 문서 최소 내용 검사:

• 기능설계서 최소: 사용자 행동 + 사용자에게 보이는 결과 1개 이상
• 정책서 최소: 업무 판단 기준 1개 이상
• 한쪽이 빈 골격에 가까우면 보류

부서 경계 (제외 대상): 디자인 상세 (컬러·폰트·Figma), 최종 UX copy, QA 케이스, API 명세, DB schema, 운영 런북, 개발 작업 분해. 입력의 주된 내용이 위 디자인·개발·QA·운영 상세이고 제품·업무 판단 정보가 부족하면 보류한다.

조건 미충족 시 references/output-contract.md의 "저장 보류" 템플릿으로 부족 항목만 출력하고 종료한다. 이 시점에 output-contract.md만 읽는다 (templates·storage-contract는 읽지 않는다). 보강용 입력 템플릿·재실행 명령 블록·질문 섹션은 만들지 않는다.

[미정]/[가정]/[확인 필요]/[충돌 후보]/해당 없음은 gate 통과 후 세부 보강·셀 fill용으로만 쓴다. gate 통과 전 부족분을 채우는 용도로 쓰지 않는다.

3. 변환 및 저장

진행 표시 매핑: 3.1 dispatch = Step 3: dispatch. 3.2 본문 작성·검증 = Step 4: 두 문서 작성·검증. 저장 절차 (staging → write → verify → rename) = Step 5: 저장 절차. 종료 출력 = Step 6: 종료 출력. 각 step 진입 시점에 헤더 1회 출력. sub-action narration 금지 (### 진행 표시 원칙).

이 step에서 읽는 파일: step 3.2 본문 작성 직전 templates/*.md 2개 (병렬), main 검증 통과 후 references/storage-contract.md, 종료 출력 직전 references/output-contract.md. step 3 진입 시 한꺼번에 읽지 말고 sub-step별로 lazy read.

dispatch → main 직접 작성 → main 검증 흐름으로 동작한다. 파일 크기와 무관하게 main이 두 문서를 같은 턴에 직접 작성하고 검증한다. 별도 subagent/worker로 기능설계서·정책서 본문을 분리하지 않는다. main이 dispatch, canonical 값, marker 합산, cross-bleed repair, 저장을 모두 소유한다.

step 3.2 본문 작성 직전 templates/기능설계서.md와 templates/정책서.md를 읽는다 (두 파일 병렬). 두 산출물의 섹션 헤더(번호·제목)와 admonition metadata 필드는 템플릿과 1:1로 일치시킨다. 표는 컬럼명·컬럼 순서·컬럼 수를 템플릿과 동일하게 유지하고, 채울 근거가 없는 셀은 marker([미정]/[확인 필요]/해당 없음)로 표기한다. 섹션 추가·삭제·병합·재번역·순서 변경 금지. 본 SKILL.md의 모든 작성 규칙은 템플릿 구조를 깨지 않는 범위에서만 적용된다.

3.1 공통 dispatch

읽는 파일: 없음 (step 2에서 읽은 입력만 사용). templates는 step 3.2 직전에 읽는다.

step 2의 경량 분류를 라벨 매핑·용어 사전·안전기능명까지 확장한다. 분류·고정 항목만 결정하고 본문 작성은 하지 않는다.

• 추출 기능명, 안전기능명
• 도메인, 적용 사용자, 역할명, 용어 사전
• source index: 입력 경로/제목/주요 heading/기능 후보/정책 후보/제외 후보
• gate 근거 맵: 기능 목적, 적용 대상, 핵심 사용자 행동, 기대 결과, 업무 판단 기준이 어느 입력 단편에서 나온 것인지
• 입력 단편별 귀속 라벨: feature, policy, both, excluded
• both 단편의 분리 기준: 기능설계서에는 사용자 결과·가능 행위, 정책서에는 판단 기준
• 본문 제외 항목 후보, 읽기 제외 항목 후보, 원본 문서 피드백 후보, 설정 경고 후보

기능명·역할명·용어 일관성은 이 단계에서만 결정한다. 본문 작성 단계는 dispatch 결과를 그대로 사용하고 재추출하지 않는다.

다기능 입력 처리:

• 서로 독립적인 기능 후보가 여러 개 있으면 사용자의 명시 주제, 파일명, 디렉터리명, 반복 등장 제목 순서로 주 기능 하나를 선택한다.
• 선택되지 않은 기능 후보는 본문에 섞지 않고 [원본 문서 피드백] 또는 저장 완료 출력의 [본문 제외 항목] 성격으로 남긴다.
• 주 기능을 보수적으로 고를 수 없고 각 후보가 서로 다른 목적·대상·정책 기준을 가진다면 저장 보류로 종료한다. 한 번의 plan-format 호출에서 여러 timestamp 폴더를 만들지 않는다.

3.2 두 문서 작성 (main 직접 작성)

읽는 파일: 본문 작성 직전 templates/기능설계서.md, templates/정책서.md 2개를 병렬 read. 두 템플릿 원문을 같은 턴 내에서 참조하며 본문을 채운다.

main이 dispatch 결과를 single source로 사용해 두 문서를 같은 턴에 직접 작성한다. 파일이 크거나 입력 단편이 많아도 기능설계서/정책서 worker로 분리하지 않는다. 큰 입력은 자르지 않고, 전체 입력에서 만든 source index와 gate 근거 맵을 기준으로 본문 반영 범위를 고정한다. 비용은 섹션 6 이상 tail 압축, semantic table validation, 중복/cross-bleed 국소 repair로 제어한다.

본문 echo 금지: 두 문서 본문은 Write 툴 인자로만 전달한다. 응답 텍스트에 markdown 블록, 표 행, 섹션 미리보기, "[기능설계서 초안]" 같은 헤더로 본문을 출력하지 않는다. 작성 진행·자체 검증 결과 echo도 금지한다 (### 진행 표시 원칙의 step 헤더 한 줄 + 종료 출력 "이유" 필드로 대체). 검증 실패 시 분기 단축은 다음 step 헤더 출력으로만 표현한다.

작성 입력:

• dispatch 결과 (안전기능명, 도메인, 적용 사용자, 역할명, 용어 사전, 라벨 매핑, 본문 제외 항목 후보, 읽기 제외 항목 후보, 설정 경고)
• feature + both 라벨 단편 → 기능설계서 (사용자 결과·가능 행위 부분만)
• policy + both 라벨 단편 → 정책서 (판단 기준 부분만 — 허용·금지·조건·예외·제한·승인 기준)
• dispatch 용어 사전 → 정책서 ## 3. 용어 정의 표. 기능설계서엔 별도 용어 섹션 없음.
• templates/기능설계서.md 원문 (섹션 헤더 1~8, admonition metadata, 표 의미) — 기능설계서 골격. 섹션 8은 미결 사항.
• templates/정책서.md 원문 (섹션 헤더 1~10, admonition metadata, 표 의미) — 정책서 골격. 섹션 10은 미결 사항.

작성 규칙:

• 기능설계서(섹션 18, 8=미결 사항), 정책서(섹션 110, 10=미결 사항)의 번호·제목과 admonition metadata 필드는 각각 템플릿과 1:1로 유지한다. 섹션 추가·삭제·병합·재번역·순서 변경 금지.
• 빈 위치 보존 원칙: 입력 근거가 없는 admonition 줄·표 row·표 셀·인라인 항목은 삭제하지 않는다. 빈 셀은 비우지 말고 fill 표기로 채운다. row·컬럼·섹션 헤더·metadata 줄 자체 삭제 금지.
• 셀 fill 표기 규칙:
  • [미정] / [확인 필요] / [가정] / [충돌 후보]: marker 4종. 결정이 쓰이는 위치에 inline (정의는 ### Marker 4종).
  • 해당 없음: marker가 아닌 fill 문구. 입력에 명백히 해당 정보가 없을 때 사용. 분류·합산·미결 사항 색인 대상 아님.
  • 보강 사유가 필요하면 : <짧은 사유> 추가 가능 (예: 해당 없음: 입력 근거 없음, [확인 필요]: 판단 기준 미제공, [미정]: 역할/상태/예외 기준 미정).
• 각 템플릿의 모든 섹션 헤더는 항상 출력한다. 섹션 1~5는 Gate First 통과 후 실질 내용을 포함해야 하며, 헤더 + marker/해당 없음만 남는 수준이면 빈 골격으로 보류한다.
• 섹션 6 이상은 입력 근거가 없으면 표 row 셀을 marker 또는 해당 없음으로 채운다. 표 전체가 근거 전무 시 row 1의 첫 데이터 셀(인덱스 컬럼이 있는 표는 인덱스 다음 셀, 인덱스 컬럼이 없는 표는 첫 셀)에 대표 fill (예: 해당 없음: 입력 근거 없음) 1회, 같은 row의 나머지 데이터 셀도 해당 없음으로 채운다. 인덱스 컬럼이 있는 표(예: 미결 사항 첫 컬럼)는 인덱스 값(1 등)을 템플릿 그대로 유지하고 fill 대상에서 제외한다. row·섹션 헤더 삭제 금지.
• 표는 semantic validation을 적용한다. 템플릿 표가 요구하는 필수 개념(범위, 사용자 흐름, 화면·입력 항목, 기능 동작, 권한·데이터 접근, 예외·메시지, 정책 원칙, 세부 규칙, 상태 처리, 역할·권한, 예외 승인, 외부 연동, 미결 사항 등)을 빠뜨리지 않는다. 컬럼 수·이름·순서는 템플릿과 동일.
• 라벨 cross-bleed 금지: 정책서 본문에 화면 동작·입력 방식·사용자 노출 결과 작성 금지. 기능설계서 본문에 허용/금지/조건/예외 판단 기준 작성 금지. 양쪽에 걸리는 항목은 분류 기준 표에 따라 한쪽에만 남긴다.
• 안전기능명·역할명·용어는 dispatch 결과 그대로 사용. 재추출·재명명 금지.
• marker 4종 ([미정]/[가정]/[확인 필요]/[충돌 후보])은 결정이 쓰이는 본문 문장 또는 표 셀에 inline 표시. 각 문서에 marker가 1건 이상이면 미결 사항 섹션 (기능설계서 ## 8. 미결 사항, 정책서 ## 10. 미결 사항) 표에 항목 색인을 채운다 (인덱스·항목·설명). marker 0건이면 미결 사항 표 row 1 의 항목·설명 셀을 해당 없음으로 채우고 인덱스 컬럼은 1을 유지한다 (row·섹션 삭제 금지). 별도 ## 미확정·가정·확인 필요 섹션은 만들지 않는다.
• 두 문서 marker는 화면 출력의 [미확정·가정 항목] / 확인 필요 질문에 1회만 합산해 반영.
• 원본 문서 피드백, 본문 제외 항목, 읽기 제외 항목, 설정 경고는 본문에 섞지 않고 화면 출력 dispatch 목록을 그대로 사용한다.

작성 후 main 자체 검증:

• 빈 골격 검사: 각 문서 섹션 1~5에 입력 근거 기반의 substance(marker·해당 없음이 아닌 문장 또는 표 셀)가 있는지 확인한다. 헤더 + marker/해당 없음 셀만 남는 빈 골격이면 검증 실패 보류 분기로 전환한다. 저장 절차 (staging folder 생성 포함) 진입 금지. 다음 헤더부터 Step 5: 보류 출력로 전환하고 references/output-contract.md의 "저장 보류" 템플릿으로 출력하되 이유 필드에 검증 실패 발생 step (예: "step 4 검증 실패 — 빈 골격")을 명시하고 부족 항목에 빈 골격 분석 결과 (예: "정책서 본문이 빈 골격 — policy 라벨 단편 부족")를 추가한다.
• 구조 일치 검사: 각 템플릿의 섹션 헤더 (번호·제목)와 admonition metadata 필드가 템플릿과 1:1로 일치하는지 기계적으로 확인한다. 기능설계서는 섹션 18 (8=미결 사항), 정책서는 섹션 110 (10=미결 사항)이 모두 있어야 한다. 표는 컬럼명·컬럼 순서·컬럼 수가 템플릿과 동일해야 하며 row·셀이 비어 있을 경우 marker([미정]/[확인 필요]) 또는 해당 없음으로 채운다 (빈 셀 금지). 섹션·metadata가 어긋나면 1회 국소 수정 retry(어긋난 섹션·metadata·표 컬럼만 수정, 본문 재생성 금지), 2회 어긋나면 검증 실패 보류 fallback. fallback 시 다음 헤더부터 Step 5: 보류 출력로 전환하고 이유 필드에 "step 4 검증 실패 — 구조 불일치"를 명시한다. 표의 의미 보강은 전체 재작성 대신 marker 또는 미결 사항 섹션 (기능설계서 ## 8. 미결 사항, 정책서 ## 10. 미결 사항) 항목으로 남긴다.
• 중복 검사: 같은 항목이 양쪽 문서에 중복 등장하면 전체 문서를 재작성하지 않고 위반 문장·행·셀만 국소 repair한다. 분류 기준 표에 따라 한쪽에만 남기고 다른 쪽 중복 표/행은 삭제하거나 이동한다. 의미 손실 없이 국소 repair가 불가능하면 저장 보류 또는 원본 문서 피드백 후보로 남긴다.
• 라벨 범위 검사: cross-bleed 위반 (정책서에 화면 동작, 기능설계서에 판단 기준)이 발견되면 전체 문서를 재작성하지 않고 위반 문장·행·셀만 분류 기준 표대로 이동·삭제·재서술한다. 의미 손실 없이 국소 repair가 불가능하면 저장 보류 또는 확인 필요 질문으로 남긴다.
• main 검증 통과 후에만 references/storage-contract.md를 읽고 저장 절차 (staging folder → 두 파일 병렬 write → verify → rename → verify)를 진행한다. 두 final 파일 Write 툴 호출은 단일 메시지에 동시(병렬) 발행한다. verify·rename·종료 verify는 순차 유지. 저장은 main이 일괄 처리한다.

분류 기준

섹션 매핑·번호는 templates/*.md 파일 기준이다. 본 표는 입력 항목을 어느 템플릿으로 보낼지 결정하는 용도이며 새 섹션을 만들지 않는다.

입력 성격	귀속 문서
화면, 사용자 흐름, 진입점, 입력 항목, UI, 기능 동작, 사용자에게 보이는 결과, 가능 행위	기능설계서
업무 판단 기준, 규칙, 조건, 제한, 정책, 원칙, 예외 승인 기준, 상태 처리 기준	정책서
상태·권한·예외처럼 양쪽에 걸리는 항목	정책서에 판단 기준, 기능설계서에 사용자 결과·가능 행위. 같은 표를 양쪽에 중복하지 않음
디자인·개발·QA·운영 상세	본문에 두지 않음. 기획 판단에 필요한 최소 맥락 한 줄로 요약 후 저장 완료 출력의 [본문 제외 항목]에 남김

Marker 4종

plan-review/references/review-rules.md의 분류(필수 수정 / 발행 전 확인 / 참고)와 직결된다. 정의·표기·범위 변경 시 cross-skill 검증 필요.

• [미정]: 결정되지 않은 필수 판단. 빈 칸 전부가 아니라 문서 확정에 영향을 주는 결정사항에만 사용.
• [가정]: 입력 근거로 제한적으로 추론한 내용. 확정 사실처럼 쓰지 않음.
• [확인 필요]: 결정자 답변이나 후속 확인이 필요한 항목. 이유, 결정 주체, 후속 확인 방법을 함께 남김.
• [충돌 후보]: 입력 내부에서 서로 맞지 않는 표현, 중복 기준, 상충 조건. 어느 쪽도 확정 불가. 저장 차단 사유 아님.

별도로 해당 없음은 marker 4종이 아닌 셀 fill 문구다. 입력에 명백히 해당 정보가 없을 때 빈 셀 대신 사용한다. 분류·합산·미결 사항 색인 대상이 아니며 plan-review review-rules 분류에도 들어가지 않는다.

[확인 필요] (inline 마커)와 확인 필요 질문 (출력 섹션 헤더)은 다른 표기다.

규칙:

• 사용자가 모르면 [미정]. 공백/무응답/모름/정하지 않음은 [미정].
• [충돌 후보]는 확정 사실로 쓰지 않음. 충돌 항목·상충 표현·후속 확인 방법을 남김.
• plan-format은 Product Docs SSOT 검색·검증 안 함. SSOT 충돌은 plan-review 책임.
• 결정이 쓰이는 본문 문장 또는 표 셀에 marker inline 표시. 최종 문서에서 제거하지 않음.
• 해당 문서에 marker가 1건 이상이면 미결 사항 섹션 (기능설계서 ## 8. 미결 사항, 정책서 ## 10. 미결 사항) 표에 항목 색인을 채운다. marker 0건이면 row 1 의 항목·설명 셀을 해당 없음으로 채우고 인덱스 컬럼은 1을 유지한다 (row·섹션 삭제 금지).
• 두 문서 marker 합산을 화면 출력의 [미확정·가정 항목] 또는 확인 필요 질문 섹션에 반영. 0건이면 화면 출력 섹션 생략 (본문 미결 사항 표는 위 규칙대로 유지).

작성 규칙

• 섹션 헤더(## 1. 개요 등) 자체는 템플릿과 동일하게 유지한다. 임의 삭제·번호 재배열·제목 변형 금지.
• admonition metadata(> [!IMPORTANT] 블록의 - 도메인: 등)는 dispatch 결과로 채운다. 채울 근거 없는 항목은 [미정]/[확인 필요]/해당 없음로 표기하되 줄 자체를 삭제하지 않는다.
• 표 row는 dispatch 결과로 채운다. 채울 근거가 없는 셀은 비우지 않고 marker([미정]/[확인 필요]) 또는 해당 없음을 inline 표기한다. row·컬럼 자체 삭제 금지.
• 짝 문서 경로는 두 템플릿 모두 admonition 관련 문서 항목에 같은 output folder 기준 상대 경로로 추가한다 (한 줄 슬롯, 짝 문서 1건). 짝 문서 외 추가 관련 자료는 admonition에 넣지 않고 [원본 문서 피드백] 화면 출력에 처리한다. 짝 문서 경로가 없으면 해당 없음.
• 정책서 세부 규칙은 허용/금지/조건/예외 판단 기준만. 화면 동작·입력 방식·사용자 노출 결과는 기능설계서.
• 역할명·기능명·범위·용어는 두 문서에 동일하게 쓴다.
• 작성 가이드, HTML 주석, [기능명], [정책명], 생성 과정 설명 (원본, 원문, 입력 반영 요약, 섹션 적용 체크리스트)은 결과물에서 제거.

원본 문서 피드백

원본 정리 중 품질 이슈 (중복 내용, 상충/모순, 용어 불일치, 범위 혼입, 구조 문제, 근거 부족, 표현/품질 문제)는 본문에 섞지 않고 화면 출력에만 요약한다. 문서 확정에 영향 주는 항목은 본문에도 marker로 남긴다.

저장과 출력

저장 위치·안전기능명·collision suffix는 references/storage-contract.md를 따른다. 이 파일은 step 3.2 main 검증 통과 후 저장 절차 직전에만 읽는다.

사용자 출력은 references/output-contract.md의 "저장 완료" / "저장 보류" / "설정 없음" 템플릿을 따른다. 이 파일은 종료 분기가 확정된 직후 1회만 읽는다 (분기마다 동일).

입력 처리

입력 종류	판정	첫 행동	출처 표기
빈 입력 / 최소 입력	입력 없음 또는 기능명/키워드만	정보 부족 보류	사용자 입력
직접 텍스트	경로로 해석 불가	입력 본문 전체 사용	사용자 입력
기존 파일 경로	파일 존재	UTF-8 텍스트 사용	로컬 확인: <파일경로>
기존 디렉터리 경로	디렉터리 존재	기본 제외 경로를 뺀 하위의 모든 읽을 수 있는 UTF-8 텍스트 파일을 상대경로 오름차순으로 통합	로컬 확인: <디렉터리경로> (읽은 텍스트 파일 N개)
없는 path-like	/·확장자·구분자 포함하나 미존재	직접 텍스트로 폴백	사용자 입력
주제 + 경로 혼합	문장 + 기존 경로 포함	사용자 문장 + 로컬 경로 내용 함께 사용	사용자 입력 + 로컬 확인: <경로>

입력 크기와 파일 개수 상한은 두지 않는다. 검증 정확도를 위해 입력이 무거워도 읽기 대상 텍스트 입력은 끝까지 읽는다. 임의 truncate, 첫 N개 파일만 읽기, 일부 파일 샘플링은 금지한다. 호출 환경 한계나 도구 실패로 읽기 대상 텍스트 전체를 확인할 수 없으면 일부 입력만으로 저장하지 않고 저장 보류로 종료한다.

디렉터리 입력:

• 기본 제외 경로: .git, node_modules, dist, build, coverage, .cache, vendor, __pycache__
• 바이너리·권한 오류·UTF-8 디코딩 실패 파일은 실행을 막지 않고 읽기 제외 항목 후보에 경로·이유를 남김. 종료 출력의 실제 블록명은 references/output-contract.md의 분기별 템플릿을 따른다.
• 읽은 텍스트 파일은 상대경로 오름차순으로 통합하되, 먼저 source index를 만든 뒤 기능 후보와 정책 후보를 묶는다. 이 인덱스는 내부 dispatch용이며 사용자 출력에 본문처럼 echo하지 않는다.
• 기존 _기능설계서.md, _정책서.md는 참고 입력일 뿐 보류 사유 아님. 새 산출물은 항상 새 timestamp 폴더에 저장
• <outputRoot> 자체 또는 그 하위 입력도 사용자가 제공한 입력이면 일반 입력처럼 읽되 저장은 storage-contract 규칙에 따름

역할 경계

• plan-format은 사용자가 준 입력·파일·디렉터리만 읽는다.
• Product Docs SSOT 검색·충돌 검증·용어 일관성 판단은 plan-review 책임.
• [충돌 후보]는 입력 내부 모순·중복·상충에만 사용.
• 상위설계서는 지원하지 않음.
• 기존 산출물은 덮어쓰지 않음.
• 로컬 설정은 ../../references/config-contract.md를 따른다.

암묵 호출 라우팅

plan-format 선택:

• 기획 노트·회의록·AI 대화 결과물·초안 스크랩을 기능설계서/정책서로 정리
• 기획자료 디렉터리를 통합해 기능설계서/정책서로 변환
• 저장 보류 후 부족 항목 보강한 입력을 다시 변환

plan-format 비선택:

• 이미 생성된 초안 검토·pass 판단 → plan-review
• 단순 질의응답·아이디어 탐색 → 일반 답변

생성·검토 동시 요청 시 plan-format으로 초안 저장 후 plan-review 안내. 사용자가 명시적으로 바로 검토까지 요청한 경우에만 저장 경로를 대상으로 plan-review 이어 수행.