🛑 USER INVOCATION REQUIRED: dev-story는 사용자가 에이전트 메뉴 또는 직접 명령으로 명시적으로 호출해야 합니다. create-story, create-epics-and-stories 등 다른 워크플로우에서 자동 체이닝으로 도달한 경우 즉시 중단하고 사용자에게 제어를 반환하세요. The workflow execution engine is governed by: {project-root}/_bmad/core/tasks/workflow.xml You MUST have already loaded and processed: {installed_path}/workflow.yaml Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level} Generate all documents in {document_output_language} Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List, Change Log, and Status Execute ALL steps in exact order; do NOT skip steps Absolutely DO NOT stop because of "milestones", "significant progress", or "session boundaries". Continue in a single execution until the story is COMPLETE (all ACs satisfied and all tasks/subtasks checked) UNLESS a HALT condition is triggered or the USER gives other instruction. Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion. User skill level ({user_skill_level}) affects conversation style ONLY, not code updates. Use {{story_path}} directly Read COMPLETE story file Extract story_key from filename or metadata MUST read COMPLETE sprint-status.yaml file from start to end to preserve order Load the FULL file: {{sprint_status}} Read ALL lines from beginning to end - do not skip any content Parse the development_status section completely to understand story order Find the FIRST story (by reading in order from top to bottom) where: - Key matches pattern: number-number-name (e.g., "1-2-user-auth") - NOT an epic key (epic-X) or retrospective (epic-X-retrospective) - Status value equals "ready-for-dev"

📋 No ready-for-dev stories found in sprint-status.yaml **Current Sprint Status:** {{sprint_status_summary}} **What would you like to do?** 1. Run `create-story` to create next story from epics with comprehensive context 2. Run `*validate-create-story` to improve existing stories before development (recommended quality check) 3. Specify a particular story file to develop (provide full path) 4. Check {{sprint_status}} file to see current sprint status 💡 **Tip:** Stories in `ready-for-dev` may not have been validated. Consider running `validate-create-story` first for a quality check.

Choose option [1], [2], [3], or [4], or specify story file path: HALT - Run create-story to create next story HALT - Run validate-create-story to improve existing stories Provide the story file path to develop: Store user-provided story path as {{story_path}}

Loading {{sprint_status}} for detailed status review...

Display detailed sprint status analysis HALT - User can review sprint status and provide story path Store user-provided story path as {{story_path}} Search {story_dir} for stories directly Find stories with "ready-for-dev" status in files Look for story files matching pattern: *-*-*.md Read each candidate story file to check Status section

📋 No ready-for-dev stories found **Available Options:** 1. Run `create-story` to create next story from epics with comprehensive context 2. Run `*validate-create-story` to improve existing stories 3. Specify which story to develop

What would you like to do? Choose option [1], [2], or [3]: HALT - Run create-story to create next story HALT - Run validate-create-story to improve existing stories It's unclear what story you want developed. Please provide the full path to the story file: Store user-provided story path as {{story_path}} Continue with provided story file Use discovered story file and extract story_key Store the found story_key (e.g., "1-2-user-authentication") for later status updates Find matching story file in {story_dir} using story_key pattern: {{story_key}}.md Read COMPLETE story file from discovered path Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status Load comprehensive context from story file's Dev Notes section Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications Use enhanced story context to inform implementation decisions and approaches Identify first incomplete task (unchecked [ ]) in Tasks/Subtasks Completion sequence HALT: "Cannot develop story without access to story file" ASK user to clarify or HALT Load all available context to inform implementation Load {project_context} for coding standards and project-wide patterns (if exists) Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status Load comprehensive context from story file's Dev Notes section Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications Use enhanced story context to inform implementation decisions and approaches

✅ **Context Loaded** Story and project context available for implementation

Determine if this is a fresh start or continuation after code review Check if "Senior Developer Review (AI)" section exists in the story file Check if "Review Follow-ups (AI)" subsection exists under Tasks/Subtasks Set review_continuation = true Extract from "Senior Developer Review (AI)" section: - Review outcome (Approve/Changes Requested/Blocked) - Review date - Total action items with checkboxes (count checked vs unchecked) - Severity breakdown (High/Med/Low counts) Count unchecked [ ] review follow-up tasks in "Review Follow-ups (AI)" subsection Store list of unchecked review items as {{pending_review_items}}

⏯️ **Resuming Story After Code Review** ({{review_date}}) **Review Outcome:** {{review_outcome}} **Action Items:** {{unchecked_review_count}} remaining to address **Priorities:** {{high_count}} High, {{med_count}} Medium, {{low_count}} Low **Strategy:** Will prioritize review follow-up tasks (marked [AI-Review]) before continuing with regular tasks.

Set review_continuation = false Set {{pending_review_items}} = empty

🚀 **Starting Fresh Implementation** Story: {{story_key}} Story Status: {{current_status}} First incomplete task: {{first_task_description}}

Load the FULL file: {{sprint_status}} Read all development_status entries to find {{story_key}} Get current status value for development_status[{{story_key}}] Update the story in the sprint status report to = "in-progress"

🚀 Starting work on story {{story_key}} Status updated: ready-for-dev → in-progress

⏯️ Resuming work on story {{story_key}} Story is already marked in-progress

⚠️ Unexpected story status: {{current_status}} Expected ready-for-dev or in-progress. Continuing anyway...

Store {{current_sprint_status}} for later use

ℹ️ No sprint status file exists - story progress will be tracked in story file only

Set {{current_sprint_status}} = "no-sprint-tracking" 🌿 GIT BRANCH SETUP - Ensure proper branch for development! 스토리 파일에서 GitHub Tracking 섹션 읽기 {{issue_number}}, {{branch_name}}, Story-Type 필드에서 {{story_type}} 추출

⚠️ 이 스토리에 연결된 GitHub 이슈가 없습니다. **옵션:** 1. SM에게 이슈 생성 요청 (create-story 재실행) 2. SM에게 *link-issue 요청 (기존 이슈 연결) 3. 이슈 없이 수동으로 진행

이슈 없이 진행하시겠습니까? [y/n] HALT - 이슈 연결 후 재시작 필요 {{story_type}} 기본값 설정: "feat" {{branch_name}} 생성: feat/{{story_key}} 현재 브랜치 확인: git branch --show-current 새 브랜치 생성 및 체크아웃: git checkout -b {{branch_name}}

🌿 브랜치 생성됨: {{branch_name}}

기존 브랜치로 체크아웃: git checkout {{branch_name}}

🌿 기존 브랜치로 체크아웃: {{branch_name}} (create-story에서 생성된 브랜치)

✅ 이미 올바른 브랜치에 있음: {{branch_name}} (create-story에서 체크아웃됨)

스토리 파일의 GitHub Tracking > Branch 필드에 실제 브랜치명 기록

ℹ️ Git 저장소가 감지되지 않음 - 브랜치 관리 건너뜀

🔍 VERIFY BEFORE CODING — [unverified] items from create-story MUST be confirmed against reality Scan story Dev Notes for all items tagged [unverified] For EACH [unverified] item: 1. Execute the verification method specified in the story (e.g., run --help, check type definitions, ls/read files) 2. Record verification result in Dev Agent Record: - "✅ Verified: [claim] — confirmed by [method]: [evidence]" - "❌ Verification failed: [claim] — actual: [reality]" 3. If verified: update the story tag from [unverified] to [verified] 4. If verification fails: STOP, correct the story spec to match reality, document the correction in Dev Agent Record, then proceed with corrected spec

🔍 **Technical Verification Results:** - Verified: {{verified_count}} items - Corrected: {{corrected_count}} items (story specs updated)

Spot-check 2-3 key technical claims in Dev Notes (CLI commands, API signatures, file paths) even if tagged [verified] If any spot-check fails: HALT, correct story, document in Dev Agent Record FOLLOW THE STORY FILE TASKS/SUBTASKS SEQUENCE EXACTLY AS WRITTEN - NO DEVIATION Review the current task/subtask from the story file - this is your authoritative implementation guide Plan implementation following red-green-refactor cycle Write FAILING tests first for the task/subtask functionality Confirm tests fail before implementation - this validates test correctness Implement MINIMAL code to make tests pass Run tests to confirm they now pass Handle error conditions and edge cases as specified in task/subtask Improve code structure while keeping tests green Ensure code follows architecture patterns and coding standards from Dev Notes Document technical approach and decisions in Dev Agent Record → Implementation Plan HALT: "Additional dependencies need user approval" HALT and request guidance HALT: "Cannot proceed without necessary configuration files" NEVER implement anything not mapped to a specific task/subtask in the story file NEVER proceed to next task until current task/subtask is complete AND tests pass Execute the Step 5→6→7→8 loop autonomously for each task without asking for user confirmation — but ALWAYS complete Step 8 (including git commit) before proceeding to the next task Do NOT propose to pause for review until Step 9 completion gates are satisfied Create unit tests for business logic and core functionality introduced/changed by the task Add integration tests for component interactions specified in story requirements Include end-to-end tests for critical user flows when story requirements demand them Cover edge cases and error handling scenarios identified in story Dev Notes Determine how to run tests for this repo (infer test framework from project structure) Run all existing tests to ensure no regressions Run the new tests to verify implementation correctness Run linting and code quality checks if configured in project Validate implementation meets ALL story acceptance criteria; enforce quantitative thresholds explicitly STOP and fix before continuing - identify breaking changes immediately STOP and fix before continuing - ensure implementation correctness NEVER mark a task complete unless ALL conditions are met - NO LYING OR CHEATING 🔴 MANDATORY COMMIT RULE: 각 태스크 완료 후 반드시 개별 커밋 실행 - 건너뛰기 절대 금지 🔴 여러 태스크를 연속 처리하더라도, 각 태스크마다 반드시 개별 커밋 수행 🔴 커밋 없이 다음 태스크로 goto 진행 시 HALT - 커밋 먼저 완료해야 함 Verify ALL tests for this task/subtask ACTUALLY EXIST and PASS 100% Confirm implementation matches EXACTLY what the task/subtask specifies - no extra features Validate that ALL acceptance criteria related to this task are satisfied Run full test suite to ensure NO regressions introduced Extract review item details (severity, description, related AC/file) Add to resolution tracking list: {{resolved_review_items}} Mark task checkbox [x] in "Tasks/Subtasks → Review Follow-ups (AI)" section Find matching action item in "Senior Developer Review (AI) → Action Items" section by matching description Mark that action item checkbox [x] as resolved Add to Dev Agent Record → Completion Notes: "✅ Resolved review finding [{{severity}}]: {{description}}" ONLY THEN mark the task (and subtasks) checkbox with [x] Update File List section with ALL new, modified, or deleted files (paths relative to repo root) Add completion notes to Dev Agent Record summarizing what was ACTUALLY implemented and tested Git commit is NOT a pause — it is a MANDATORY part of each task completion cycle. Do NOT batch commits across multiple tasks. 🔴 [MANDATORY] 변경된 파일 스테이징: git add {{modified_files_for_this_task}} 🔴 [MANDATORY] 태스크 커밋 생성 - 반드시 실행: git commit -m "{{story_type}}(story-{{epic_num}}.{{story_num}}): Task {{task_num}} - {{task_brief_description}} (#{{issue_number}})"

📝 커밋 완료: Task {{task_num}}

커밋 실행 확인 - 커밋 해시가 생성되어야 다음 태스크 진행 가능

ℹ️ Git 저장소 아님 - 커밋 건너뜀

DO NOT mark task complete - fix issues first HALT if unable to fix validation failures Count total resolved review items in this session Add Change Log entry: "Addressed code review findings - {{resolved_count}} items resolved (Date: {{date}})" Save the story file Determine if more incomplete tasks remain Next task Completion Verify ALL tasks and subtasks are marked [x] (re-scan the story document now) Run the full regression suite (do not skip) Confirm File List includes every changed file Execute enhanced definition-of-done validation Update the story Status to: "review" Validate definition-of-done checklist with essential requirements: - All tasks/subtasks marked complete with [x] - Implementation satisfies every Acceptance Criterion - Unit tests for core functionality added/updated - Integration tests for component interactions added when required - End-to-end tests for critical flows added when story demands them - All tests pass (no regressions, new tests successful) - Code quality checks pass (linting, static analysis if configured) - File List includes every new/modified/deleted file (relative paths) - Dev Agent Record contains implementation notes - Change Log includes summary of changes - Only permitted story sections were modified Load the FULL file: {sprint_status} Find development_status key matching {{story_key}} Verify current status is "in-progress" (expected previous state) Update development_status[{{story_key}}] = "review" Save file, preserving ALL comments and structure including STATUS DEFINITIONS

✅ Story status updated to "review" in sprint-status.yaml

ℹ️ Story status updated to "review" in story file (no sprint tracking configured)

⚠️ Story file updated, but sprint-status update failed: {{story_key}} not found Story status is set to "review" in file, but sprint-status.yaml may be out of sync.

HALT - Complete remaining tasks before marking ready for review HALT - Fix regression issues before completing HALT - Update File List with all changed files HALT - Address DoD failures before completing 🔀 CREATE PULL REQUEST - Final step before code review! 최종 커밋 (스토리 완료): git add . git commit -m "docs(story-{{epic_num}}.{{story_num}}): Story ready for review (#{{issue_number}})" 원격 저장소에 푸시: git push -u origin {{branch_name}} PR 생성: gh pr create \ --title "{{story_type}}: Story {{epic_num}}.{{story_num}} - {{story_title}}" \ --body "Closes #{{issue_number}} ## Summary {{story_statement}} ## Changes {{file_list_summary}} ## Acceptance Criteria {{ac_checklist}} ## Story File \`{{story_file_path}}\`" PR 번호와 URL 추출 스토리 파일의 GitHub Tracking 섹션 업데이트: - PR: #{{pr_number}} - PR URL: {{pr_url}}

🔗 Pull Request 생성됨: #{{pr_number}} URL: {{pr_url}}

⚠️ PR 생성 실패: {{error_message}} 브랜치는 푸시되었습니다. 수동으로 PR을 생성해주세요. 브랜치: {{branch_name}}

⚠️ Git push 실패: {{error_message}} 로컬 변경사항은 저장되었습니다. 네트워크 연결을 확인하고 수동으로 push해주세요.

ℹ️ GitHub 연동 없이 스토리 완료 - PR 생성 건너뜀

Execute the enhanced definition-of-done checklist using the validation framework Prepare a concise summary in Dev Agent Record → Completion Notes Communicate to {user_name} that story implementation is complete and ready for review Summarize key accomplishments: story ID, story key, title, key changes made, tests added, files modified Provide the story file path and current status (now "review") 🎯 수동 테스트 범위 원칙 (반드시 준수): - 수동 테스트는 본 스토리 목표 (AC 직접 매핑 새 기능) 의 검증에만 한정한다 - AC 가 N 개면 보통 N 개 또는 그 이하의 최소 검증 세트를 제시한다 (자산 부담 적은 항목 우선) - 회귀 시나리오 (기존 동작 보존 검증) 는 수동 테스트 목록에 자동 포함하지 않는다 - 스토리 문서에 "회귀 시나리오" 표나 Task 가 명시되어 있어도 동일 — 수동 테스트 안내 시 자동 포함 금지 - 회귀 위험은 "빌드 통과 + 코드 리뷰 + 자동 테스트 / 정적 검사로 커버됨" 을 보고에 명시한다 - 사용자가 명시적으로 회귀 시나리오 검증을 요청한 경우에만 추가한다 - Why: 새 기능 수동 검증과 회귀 보존 검증은 별개 관심사이며, 회귀를 수동 테스트로 떠넘기면 자산 부담이 커지고 본 작업 검증 효율이 떨어진다 스토리의 Acceptance Criteria 를 기준으로 수동 검증 항목 세트를 구성: - 각 AC 마다 사용자가 직접 확인할 수 있는 최소 단위의 검증 절차를 1 개 (또는 그 이하) 작성 - 자산 부담이 적은 (실행 시간 짧고 준비물 적은) 시나리오 우선 - 스토리에 "회귀 시나리오" / "기존 동작 보존 테스트" / "Regression Tests" 류 섹션 / 표 / Task 가 존재하더라도 이 목록에 포함하지 않는다 - 회귀 위험 커버리지는 본 보고서의 별도 문단에 "빌드 통과 + 코드 리뷰 + 자동 테스트 / 정적 검사로 커버됨" 으로 명시 수동 테스트 안내 출력 형식 예시: ## ✅ 사용자 수동 검증 항목 (본 스토리 AC 한정) - [ ] AC1: {{ac1 요약}} — {{검증 절차 한 줄}} - [ ] AC2: {{ac2 요약}} — {{검증 절차 한 줄}} - ... ## 🛡️ 회귀 위험 커버리지 - 회귀 시나리오는 본 수동 테스트 목록에서 제외함 (별개 관심사) - 회귀 위험은 빌드 통과 + 코드 리뷰 + 자동 테스트 / 정적 검사로 커버됨 - 회귀 시나리오 수동 검증이 필요하면 명시적으로 요청해 주세요 Based on {user_skill_level}, ask if user needs any explanations about: - What was implemented and how it works - Why certain technical decisions were made - Any patterns, libraries, or approaches used - Anything else they'd like clarified Provide clear, contextual explanations tailored to {user_skill_level} Use examples and references to specific code when helpful Once explanations are complete (or user indicates no questions), suggest logical next steps Recommended next steps (flexible based on project setup): - Review the implemented story and test the changes - Verify all acceptance criteria are met - Ensure deployment readiness if applicable - Run `code-review` workflow for peer review - Optional: If Test Architect module installed, run `/bmad:tea:automate` to expand guardrail tests

💡 **Tip:** For best results, run `code-review` using a **different** LLM than the one that implemented this story.

Suggest checking {sprint_status} to see project progress Remain flexible - allow user to choose their own path or ask for other assistance