Imported from donchang07/skills (to-prd/SKILL.md). Install upstream with npx skills add donchang07/skills --skill to-prd. Copyright stays with the author.

To PRD — bkit 실행 계약 작성기

이 스킬은 일반적인 제품 기획서를 쓰지 않는다. bkit이 /pdca plan {feature}부터 Design → Do → Check/Act → Report까지 추측 없이 진행하도록 검증 가능한 실행 계약을 만든다.

품질 기준은 하나다.

이 PRD만 받은 bkit이 어떤 사용자를 위해 어떤 화면을 만들고, 화면 안에 무엇을 넣고, 메뉴·권한·로그인을 어떻게 구성하며, 어떤 데이터와 상태를 처리하고, 무엇으로 완료를 판정할지 알 수 있는가.

운영 불변식

1. docs/PRD.md가 유일한 정본이다. feature PRD, 결정 목록, gate 파일은 정본에서 생성하는 파생본이다.
2. feature 파생본을 직접 편집하지 않는다. 기존 파생본에만 있는 사람의 편집은 덮어쓰기 전에 정본으로 옮긴다. 충돌하면 사용자에게 결정받는다.
3. 화면 계약이 FR과 데이터보다 먼저다. 역할 → 화면 인벤토리 → 메뉴·인증 → 화면 요소·행동 → 데이터·FR 순서로 작성하고, 마지막에 양방향 연결을 검증한다.
4. ID를 재사용하거나 재배정하지 않는다. SCR/화면 요소/DATA/FR/SC 삭제는 취소선과 사유로 남기고 새 항목은 다음 번호를 쓴다.
5. Hard Gate가 점수보다 우선한다. Blocker가 하나라도 있으면 최종 파일을 덮어쓰지 않고 정확한 draft 경로에 저장한다.
6. bkit 버전 계약을 본문에 중복하지 않는다. 변동 가능한 경로·명령·기본값은 references/bkit-contract.md에서 확인한다.

단계별 리소스

• Step 0: references/bkit-contract.md — 지원하는 bkit 버전·경로·명령·설정
• Step 4: references/screen-definition-contract.md — 화면·메뉴·권한·로그인·요소·상태의 필수 계약
• Step 5: assets/prd-template.md — 정본과 feature 파생본의 문서 구조
• Step 6: references/gate-checklist.md — Hard Gate, 결함 분류, 채점, 파일명 규칙
• Step 6: scripts/validate_prd.mjs — 제목·ID·placeholder·가정 표를 기계적으로 검사

필요한 단계에서 해당 파일을 읽는다. README는 실행 지침이 아니므로 읽을 필요가 없다.

입력과 산출물

있는 입력을 모두 읽는다. 입력 파일이 없어도 사용자가 제공한 브리프나 현재 대화만으로 시작할 수 있다.

Step 0 — bkit 계약 확인

references/bkit-contract.md를 읽는다.

1. 프로젝트의 bkit.config.json과 설치된 bkit의 로컬 문서·템플릿을 먼저 확인한다.
2. 로컬 계약이 reference와 다르면 로컬 설치본을 우선하고 PRD 메타와 부록 B에 차이를 기록한다.
3. 설치 버전을 확인할 수 없으면 reference의 검증 기준을 사용하되 [검증 기준]으로 표시한다.
4. /pdca pm은 이 스킬이 PM/PRD 역할을 대체할 때만 건너뛴다. 기존 PM 산출물을 병합하는 요청이면 입력으로 읽는다.

Step 1 — 모드와 정본 판단

docs/PRD.md, docs/PRD.draft.md, docs/00-pm/*.prd.md 존재 여부를 확인한다.

• 아무 PRD도 없으면 신규 모드다.
• 사용자가 업데이트·반영·추가를 요청했고 정본이 있으면 확인 질문 없이 업데이트 모드다.
• 기존 문서가 있는데 새로 만들지 업데이트할지 의도가 정말 불명확할 때만 한 번 묻는다.
• 정본 없이 feature PRD만 있으면 내용을 모아 정본을 복구한다. ID와 사람의 편집을 보존하고 출처를 개정 이력에 남긴다.
• 업데이트는 정본을 먼저 수정한 다음 영향받는 모든 파생본을 재생성한다.
• 기존 PRD에 PRD 스키마: screen-first-v1이 없으면 화면 계약 마이그레이션 모드로 처리한다. 기존 FR/SC ID와 내용을 보존하면서 역할·화면·메뉴·인증을 복원하고 SCR/요소/DATA ID를 부여한 뒤 5~8장을 새 구조로 이관한다. 화면 계약과 역연결이 끝나기 전에는 기존 최종본을 덮어쓰지 않는다.

Step 2 — 입력 매핑

파일과 대화를 읽고 다음 표를 작업 메모로 만든다. 머릿속으로만 연결하지 않는다.

1. 사용자 역할 → 접근 권한 → 일반/관리자 차이
2. 시나리오 → 화면 인벤토리 → 메뉴·인증 → 화면 전이
3. 화면 → 영역 → UI 요소 → 표시값·입력·행동·상태
4. UI 요소 → 필요한 데이터 필드 → 읽기·쓰기 위치
5. 화면 행동 → FR → SC → 검증 방법
6. 출처가 있는 결정과 아직 확인되지 않은 가정

입력끼리 충돌하면 최신 사용자 결정, 기존 정본의 명시적 결정, 기획 산출물 순으로 우선한다. 충돌을 조용히 해소하지 말고 개정 이력 또는 13장에 기록한다.

Step 3 — 레벨·스택·시스템 가정

FR을 확정하기 전에 11장을 먼저 채운다.

레벨·스택: Starter(정적), Dynamic(풀스택), Enterprise 중 레벨과 실제 스택을 한 줄로 정한다. 입력에 없으면 프로젝트 코드와 bkit 계약에 맞는 기본값을 제안한다.

시스템 가정 10칸: 모든 행을 두되 다음 상태 중 하나를 사용한다.

• [확정] — 사용자 또는 기존 문서가 결정
• [기본값] — 안전하게 진행 가능한 권장값을 채택
• [해당 없음] — 제품에 적용되지 않으며 이유를 적음
• [결정 필요] — 선택에 따라 범위·아키텍처·비용·보안이 실질적으로 달라짐

빈 칸은 허용하지 않는다. 다만 모든 [결정 필요]가 Blocker는 아니다. 기본값으로 되돌릴 수 없고 P0 설계가 달라지는 결정만 Blocker다. 관련 없는 항목을 억지로 결정하지 말고 [해당 없음] — 이유로 쓴다.

Step 4 — 화면 중심 계약 작성

references/screen-definition-contract.md를 읽고 아래 순서로 작성한다. 화면을 나중에 FR에 끼워 맞추지 않는다.

4.1 User Scenarios와 역할

• 각 시나리오는 사용자 / 상황 / 목표 / 흐름 / 완료 조건을 가진다. 완료 조건은 Given/When/Then으로 판정할 수 있어야 한다.
• 정상 흐름 외에 실패·취소·이탈 시나리오를 최소 하나 포함한다.
• 비로그인 / 일반 사용자 / 관리자의 열람·행동 차이를 먼저 정한다. 없는 역할도 열을 삭제하지 않고 해당 없음 — 이유를 쓴다.

4.2 화면 인벤토리·메뉴·인증

• 화면은 SCR-001부터 안정적인 ID를 부여한다. 기존 문서의 8.1 같은 순서 참조는 업데이트 시 SCR-*로 이관한다.
• 전체 화면 인벤토리, 사이트맵, 진입점과 복귀 경로를 만든다.
• 메뉴는 NAV-* ID, 위치·순서·라벨·노출 역할·대상 화면·데스크톱/모바일 표현·활성 규칙을 정의한다.
• 관리자 기능이나 보호 데이터가 있으면 인증 사용: 예이며 로그인/인증 시작 화면을 독립된 화면 유형: 인증의 SCR-*로 정의한다. 인증 결과·만료·접근 거부·로그아웃·세션 만료도 화면 또는 상태로 정의한다.
• 인증이 없으면 인증 사용: 아니오 — 이유를 쓰고 관리자·보호 기능이 없음을 확인한다.

4.3 화면별 상세 계약

각 SCR-*에 화면 유형, Route, 대상 사용자·권한, 목적, 진입 조건, 종료·전이, 관련 시나리오·FR·SC·데이터를 쓴다.

• 레이아웃은 헤더·메뉴·본문·패널·모달·푸터 등 영역 순서와 일반/관리자 차이, 모바일 재배치를 정의한다.
• 모든 UI 요소는 SCR-001-EL-01 형식의 ID를 갖고 종류, 실제 라벨·표시값, 노출 권한, 조건, 데이터 바인딩, 입력·검증, 행동·결과를 가진다.
• 화면 전이는 트리거, 선행 조건, 처리·데이터 변화, 성공 결과·다음 화면, 실패 결과를 가진다.
• 화면마다 초기 / 로딩 / 빈 / 성공 / 검증 오류 / 시스템 오류 / 권한 없음 / 오프라인을 정의한다. 적용되지 않으면 이유를 쓴다.
• 반응형과 접근성 기준을 화면별로 쓴다.

4.4 데이터 계약 도출

• 동적 표시값과 입력값을 DATA-001 엔티티의 필드로 만들고 UI 요소의 데이터 바인딩과 연결한다.
• 부록 A의 각 필드에 타입, 필수, 기본값, 검증·제약, 읽기 화면·요소, 쓰기 화면·요소, 저장 위치·수명, 출처 라벨을 쓴다.
• 정적 카피는 정적, 데이터가 필요 없는 요소는 해당 없음 — 이유로 표시한다.
• 부록 B에는 가격·일정·법규·API·외부 서비스처럼 바뀔 수 있는 사실을 사실 / 출처 / 기준일 / 재확인 시점으로 정리한다.
• 라벨은 [확정·출처], [조사·기준일], [추정], [가설]만 사용한다. 확정은 출처가 있을 때만 쓴다.

4.5 Functional Requirements와 Success Criteria 도출

• 화면 요소의 표시·입력·행동과 화면 없는 시스템 동작에서 FR-001부터 요구사항을 도출한다.
• 우선순위는 P0 (High), P1 (Medium), P2 (Low)로 bkit 매핑을 병기한다.
• FR 열은 ID / 판정 가능한 요구사항 / 우선순위 / 시나리오 / 화면·요소 / 데이터 / 관련 SC / 검증 방법이다.
• P0 화면 동작 FR에 유효한 SCR-*·요소 ID와 DATA-*가 없으면 Blocker다. 화면 없는 동작은 해당 없음 — 이유를 적는다.
• 성능·보안·접근성·오프라인·용량의 비기능 요구와 측정 방법을 별도 표로 둔다.
• SC는 SC-001부터 유지하고 관련 FR·화면, 측정 방법, 현재 PRD 데이터로 검증 가능한지를 기록한다.
• 외부 성과는 3장 Goals로 옮기고 근거 없는 목표값은 [가설], 출처가 있는 값은 [확정·출처] 또는 [조사·기준일]로 표시한다.
• FR/SC를 부여한 뒤 각 화면의 관련 ID를 다시 채워 양방향 연결을 완성한다.

4.6 오류·경계 처리

상황 / 발생 화면·요소 / 사용자 표시 문구 / 이후 동작 / 데이터·로그 표를 사용한다. 빈 상태, 입력 오류, 중복, 취소·이탈, 권한, 데이터 부족, 외부 서비스 실패, 시간 초과를 적용 가능성에 따라 검토한다.

Step 5 — 정본 구성과 feature 분해

assets/prd-template.md를 읽고 정본을 완성한다.

• 0장: Executive Summary와 Context Anchor의 WHY/WHO/RISK/SUCCESS/SCOPE
• 1~3장: 개요·배경·목표
• 4장: 사용자 시나리오와 역할별 흐름
• 5장: 화면 인벤토리·메뉴·인증·화면별 상세 계약
• 6~8장: 화면에서 도출한 FR·SC·오류 계약
• 9장: 브랜드·디자인. DESIGN.md가 없으면 안전한 기본값 또는 12장 이슈
• 10장: MVP·v1·이후 범위, 비범위, 목표일. 목표일을 알 수 없으면 임의 날짜를 만들지 않는다.
• 11장: Step 3의 레벨·스택·시스템 가정
• 12장: 구현자가 기본값을 선택해도 되는 이슈. [구현자], 기본값, 재확인 시점
• 13장: 작성자만 결정할 수 있는 이슈. 상태, 선택지, 추천값, fallback, 연쇄 영향
• 14장: 영문 kebab-case feature 슬러그, 포함 화면·FR·SC·데이터, 의존 순서, 규모. 한 feature는 한 번의 PDCA로 검증 가능한 크기
• 15장: 확인된 bkit 계약 버전, 설정, 명령 순서, 완료 조건

_decisions.md는 13장의 projection이다. 미결 항목이 없으면 삭제하지 말고 “현재 미결 항목 없음”을 기록한다.

Step 6 — 착수 게이트

references/gate-checklist.md를 읽고 다음 순서로 실행한다.

1. scripts/validate_prd.mjs를 정본과 모든 feature PRD에 실행한다.
2. Hard Gate를 확인한다.
3. 화면·요소·메뉴·권한·인증 완결성, 숫자 재계산, 연결표, 검증 가능성, 시스템 가정, 외부 사실을 검토한다.
4. 결함을 Blocker/Major/Minor로 분류하고 보조 점수를 계산한다.
5. 처음부터 다시 읽어 누락을 추가한다.

판정:

• 착수 가능: Blocker 0, 90점 이상
• 조건부 착수: Blocker 0, 70~89점
• 착수 불가: Blocker 1 이상 또는 70점 미만

점수는 참고값이다. Blocker 0이라는 Hard Gate를 점수로 상쇄할 수 없다.

Step 7 — 저장과 동기화

게이트 통과 또는 조건부 착수

1. docs/PRD.md를 정본으로 저장한다.
2. feature마다 docs/00-pm/{feature}.prd.md를 정본에서 생성한다.
3. docs/00-pm/_product.gate.md와 docs/00-pm/{feature}.gate.md를 저장한다.
4. docs/00-pm/_decisions.md를 정본 13장과 동기화한다.

착수 불가

• 기존 최종 파일을 덮어쓰지 않는다.
• 통합 draft는 docs/PRD.draft.md에 저장한다.
• feature draft는 docs/00-pm/{feature}.prd.draft.md에 저장한다.
• gate는 docs/00-pm/_product.gate.draft.md와 docs/00-pm/{feature}.gate.draft.md에 저장한다.
• 결정이 해소되어 최종본을 만든 뒤에도 기존 draft를 자동 삭제하지 않는다. 첫 줄에 상태: superseded와 대체 파일을 기록한다.

저장은 결과물의 일부다. “파일로 저장할까요?”라고 묻지 않는다.

Step 8 — 보고

다음 순서로 짧게 보고한다.

1. 저장한 정본 또는 draft 경로
2. 게이트 판정과 Blocker/Major/Minor 수
3. 작성자 결정 요청 번호·선택지·추천
4. feature 분해와 첫 실행 명령 /pdca plan {feature}
5. 곧 재확인이 필요한 외부 사실

FR 개수와 P0 개수는 요청이 있을 때만 보고한다.

원칙

• bkit 전용이다. 일반 전략 PRD로 범위를 넓히지 않는다.
• 정본은 하나다. 파생본은 정본에서 재생성한다.
• 추측을 숨기지 않는다. 기본값·추정·가설·출처를 구분한다.
• 미정 표현을 계약 섹션에 남기지 않는다. 결정 또는 fallback을 쓰고, 논점은 12·13장으로 분리한다.
• 화면 계약 없이 FR·데이터를 확정하지 않는다.
• 메뉴·일반/관리자 차이·로그인·화면 요소·행동·데이터·상태 중 하나라도 필요한데 빠진 화면은 완료된 계약이 아니다.
• 유효한 화면·요소·데이터 연결이 없는 P0 UI FR과 측정할 수 없는 SC는 완료된 계약이 아니다.
• Hard Gate가 점수보다 우선한다.
• MVP와 feature를 작게 유지한다.
• ID와 개정 이력을 보존한다.
• 변동 가능한 bkit 사양은 reference에서만 관리한다.