스프린트 계획

계획에서 구현으로 넘어갈 때 bmad-sprint-planning을 실행하세요. 하나의 스킬로 세 가지 질문에 답할 수 있습니다. 계획을 실제로 구현할 수 있는가(준비 상태 게이트), 어떤 작업이 있고 어디까지 진행됐는가(sprint-status.yaml 생성), 지금 상태는 무엇인가(상태 보기)입니다. 추적 파일 자체도 검증하고 복구합니다. “구현 준비 상태를 확인해 줘”, “스프린트 계획을 실행해 줘”, “스프린트 상태를 보여 줘”, “스프린트 상태를 검증해 줘”, “스프린트 상태를 고쳐 줘”라고 말하면 스킬이 원하는 작업을 감지합니다.

하나의 스킬이 담당하는 이유

sprint-status.yaml은 전체 개발 주기가 읽고 쓰는 단일 추적 산출물입니다. Build는 스토리 상태를 이 파일과 동기화합니다. code-review는 스토리를 검토 단계로 옮기고 회고는 실행 항목을 추가합니다. 이제 이 산출물을 만들거나 요약하는 모든 작업은 해당 파일을 담당하는 스킬에 모여 있습니다. 이전에는 게이트, 생성, 조회가 세 스킬(bmad-check-implementation-readiness, bmad-sprint-planning, bmad-sprint-status)에 흩어져 있었습니다. 하나로 통합해 담당자와 상태 용어를 통일했습니다. 게이트의 검사 기준과 추적 파일의 생성 기준도 서로 어긋나지 않습니다.

준비 상태 게이트

추적 파일을 만들기 전에 스킬은 인계 자료를 읽는 회의적인 시니어 개발자처럼 계획을 평가합니다. 프로젝트에 실제로 존재하는 계획 산출물, 즉 개요, PRFAQ, PRD, 사양, UX 산출물, 아키텍처, 에픽을 모두 조사합니다. 파일명 패턴이 아니라 내용을 읽어 문서를 식별합니다. 그런 다음 한 가지를 묻습니다. 개발자가 어디에도 기록되지 않은 결정을 새로 만들어 내지 않고 이 에픽들을 구현할 수 있는가?

판정은 PASS, CONCERNS, FAIL입니다. 우려 사항이 있으면 목록을 보여 주고 계속 진행할지 사용자가 선택합니다. 실패하면 심각도순으로 발견 사항을 제시하고 워크플로를 중단합니다. 각 항목에는 문제를 해결할 스킬을 표시합니다. 문서 유형이 없다는 이유만으로 문제로 보지는 않습니다. UX 산출물이 없더라도 UI 스토리가 없는 프로젝트라면 괜찮습니다.

제품 관리자와 아키텍트 메뉴의 IR 트리거가 이 게이트를 실행합니다.

결정론적으로 처리해야 할 작업

에픽 파일 파싱, 스토리 키 생성, 항목 정렬, 기존 상태 파일과 병합, 상태 개수 계산은 판단이 필요한 작업이 아니므로 추론에 맡기지 않습니다. 스킬 안의 스크립트(sprint_plan.py)가 처리합니다.

generate — ## Epic N: / ### Story N.M: Title 헤딩을 kebab-case 키로 파싱합니다. 코드 펜스 안은 무시하고 비라틴 문자 제목은 그대로 유지합니다. 각 에픽 아래에 스토리와 회고 항목을 순서대로 배치하며 기존 파일이 있으면 병합합니다. 더 진행된 상태는 보존하며 절대로 낮추지 않습니다. 이전 v6 값(drafted, contexted)은 초기화하지 않고 현재 의미에 맞게 정규화합니다. 회고의 action_items, 사용자 정의 키, 직접 작성한 주석은 그대로 전달합니다. project_key, tracking_system, story_location도 명시적으로 재정의하지 않는 한 기존 파일에서 유지합니다. 스토리 파일이 디스크에 이미 있으면 상태가 ready-for-dev보다 이전 단계로 낮아지지 않습니다. --dry-run은 파일을 쓰지 않으며 드리프트 보고서 역할도 합니다. in_sync, 새 항목, 기존 상태가 딸린 고립 항목, 잘못된 값을 보고합니다. 파일은 원자적으로 쓰고 결과를 검증합니다. 실패하면 원본을 복원합니다.
status — 상태 개수, 위험 신호(오래된 파일, 고립된 스토리, 진행 중이지만 스토리가 없는 에픽, 검토 대기 중인 스토리, 인식할 수 없는 키), 열려 있는 실행 항목, 다음 권장 작업을 계산합니다. 권장 순서는 진행 중 작업 재개 → 검토 대기 작업 검토 → 다음 준비된 스토리 시작 → backlog 상태인 첫 스토리 시작 → 열려 있는 회고 실행 → 완료입니다.
validate — 파일을 수정하지 않고 구조가 올바른지 검사합니다. 인식 가능한 키, 허용된 상태, 올바른 형식의 실행 항목, 파싱할 수 있는 타임스탬프를 확인합니다.

LLM은 판단이 필요한 부분만 담당합니다. 어떤 파일이 에픽인지 결정하고 준비 상태를 평가합니다. 파싱되지 않은 헤딩을 해석하고, 이름 변경으로 기존 항목이 고립됐다면 보고서에 나온 과거 상태를 --set으로 새 키에 옮깁니다. 직접 편집한 파일 때문에 스크립트가 전혀 작동하지 않으면 스킬이 파일을 직접 읽고 최선의 판단으로 상태를 요약합니다. 결정론적 경로가 실패했다고 알리고 복구 흐름을 제안합니다.

복구

“스프린트 상태를 고쳐 줘”라고 요청하면 깨졌거나 실제 상태와 달라진 추적 파일을 깨끗한 상태로 다시 만듭니다. 순서가 중요합니다. 먼저 추론하고 그다음 확인받은 뒤 마지막에 스크립트를 실행합니다. 하위 에이전트가 증거를 나눠 확인합니다. 에픽 파일에서는 작업 구성을, 스토리 파일과 Git 이력에서는 실제 구현 상태를, 현재 파일에서는 복구할 수 있는 내용을 살핍니다. 이 결과를 제안 상태 표 하나로 종합하며 사용자가 표를 확인하기 전에는 아무것도 쓰지 않습니다. 확인 후 generate --fresh --set key=status ...를 한 번 실행해 표준 형식의 새 파일을 만들고 validate로 검증합니다. 상태를 낮출 수 있는 경로는 의도적으로 --set뿐입니다. 복구에서는 절대로 상태를 낮추지 않는 병합 규칙이 아니라 사용자가 확인한 실제 상태를 반영해야 하기 때문입니다.

상태 보기

“스프린트 상태를 보여 줘”라고 요청하면 게이트를 건너뛰고 스크립트의 요약을 보여줍니다. 상태 개수, 위험 요소, 회고에서 나온 열린 실행 항목, 스토리 키가 포함된 다음 권장 작업 하나를 표시합니다. 예상 시간은 제공하지 않고 상태, 위험 요소, 다음 단계만 보여줍니다. 이전 파일의 레거시 상태 값(drafted, contexted)은 현재 값에 맞게 변환하고 어떻게 처리했는지도 보고합니다.

마이그레이션 참고 사항

bmad-check-implementation-readiness는 삭제됐습니다. 에이전트 메뉴의 IR 트리거는 이제 이 스킬로 연결됩니다.
bmad-sprint-status는 이제 상태 보기 의도로 이 스킬에 연결되는 폐기 예정 호환 스킬입니다. _bmad/custom/bmad-sprint-status.toml의 오버라이드는 _bmad/custom/bmad-sprint-planning.toml로 옮기세요.
sprint-status.yaml의 출력 형식은 바뀌지 않았습니다. Build의 스프린트 동기화와 회고 도구는 이전과 똑같이 이 파일을 읽고 씁니다.