bmad-method 6.10.1-next.9 → 6.11.0

package/src/bmm-skills/3-solutioning/bmad-generate-project-context/steps/step-03-complete.md

@@ -1,284 +0,0 @@
-# Step 3: Context Completion & Finalization
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-- 🛑 NEVER generate content without user input
-- ✅ ALWAYS treat this as collaborative completion between technical peers
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- 💬 FOCUS on finalizing a lean, LLM-optimized project context
-- 🎯 ENSURE all critical rules are captured and actionable
-- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Show your analysis before taking any action
-- 📝 Review and optimize content for LLM context efficiency
-- 📖 Update frontmatter with completion status
-- 🚫 NO MORE STEPS - this is the final step
-
-## CONTEXT BOUNDARIES:
-
-- All rule categories from step-2 are complete
-- Technology stack and versions are documented
-- Focus on final review, optimization, and completion
-- Ensure the context file is ready for AI agent consumption
-
-## YOUR TASK:
-
-Complete the project context file, optimize it for LLM efficiency, and provide guidance for usage and maintenance.
-
-## COMPLETION SEQUENCE:
-
-### 1. Review Complete Context File
-
-Read the entire project context file and analyze:
-
-**Content Analysis:**
-
-- Total length and readability for LLMs
-- Clarity and specificity of rules
-- Coverage of all critical areas
-- Actionability of each rule
-
-**Structure Analysis:**
-
-- Logical organization of sections
-- Consistency of formatting
-- Absence of redundant or obvious information
-- Optimization for quick scanning
-
-### 2. Optimize for LLM Context
-
-Ensure the file is lean and efficient:
-
-**Content Optimization:**
-
-- Remove any redundant rules or obvious information
-- Combine related rules into concise bullet points
-- Use specific, actionable language
-- Ensure each rule provides unique value
-
-**Formatting Optimization:**
-
-- Use consistent markdown formatting
-- Implement clear section hierarchy
-- Ensure scannability with strategic use of bolding
-- Maintain readability while maximizing information density
-
-### 3. Final Content Structure
-
-Ensure the final structure follows this optimized format:
-
-```markdown
-# Project Context for AI Agents
-
-_This file contains critical rules and patterns that AI agents must follow when implementing code in this project. Focus on unobvious details that agents might otherwise miss._
-
----
-
-## Technology Stack & Versions
-
-{{concise_technology_list}}
-
-## Critical Implementation Rules
-
-### Language-Specific Rules
-
-{{specific_language_rules}}
-
-### Framework-Specific Rules
-
-{{framework_patterns}}
-
-### Testing Rules
-
-{{testing_requirements}}
-
-### Code Quality & Style Rules
-
-{{style_and_quality_patterns}}
-
-### Development Workflow Rules
-
-{{workflow_patterns}}
-
-### Critical Don't-Miss Rules
-
-{{anti_patterns_and_edge_cases}}
-
----
-
-## Usage Guidelines
-
-**For AI Agents:**
-
-- Read this file before implementing any code
-- Follow ALL rules exactly as documented
-- When in doubt, prefer the more restrictive option
-- Update this file if new patterns emerge
-
-**For Humans:**
-
-- Keep this file lean and focused on agent needs
-- Update when technology stack changes
-- Review quarterly for outdated rules
-- Remove rules that become obvious over time
-
-Last Updated: {{date}}
-```
-
-### 4. Present Completion Summary
-
-Based on user skill level, present the completion:
-
-**Expert Mode:**
-"Project context complete. Optimized for LLM consumption with {{rule_count}} critical rules across {{section_count}} sections.
-
-File saved to: `{output_folder}/project-context.md`
-
-Ready for AI agent integration."
-
-**Intermediate Mode:**
-"Your project context is complete and optimized for AI agents!
-
-**What we created:**
-
-- {{rule_count}} critical implementation rules
-- Technology stack with exact versions
-- Framework-specific patterns and conventions
-- Testing and quality guidelines
-- Workflow and anti-pattern rules
-
-**Key benefits:**
-
-- AI agents will implement consistently with your standards
-- Reduced context switching and implementation errors
-- Clear guidance for unobvious project requirements
-
-**Next steps:**
-
-- AI agents should read this file before implementing
-- Update as your project evolves
-- Review periodically for optimization"
-
-**Beginner Mode:**
-"Excellent! Your project context guide is ready! 🎉
-
-**What this does:**
-Think of this as a 'rules of the road' guide for AI agents working on your project. It ensures they all follow the same patterns and avoid common mistakes.
-
-**What's included:**
-
-- Exact technology versions to use
-- Critical coding rules they might miss
-- Testing and quality standards
-- Workflow patterns to follow
-
-**How AI agents use it:**
-They read this file before writing any code, ensuring everything they create follows your project's standards perfectly.
-
-Your project context is saved and ready to help agents implement consistently!"
-
-### 5. Final File Updates
-
-Update the project context file with completion information:
-
-**Frontmatter Update:**
-
-```yaml
----
-project_name: '{{project_name}}'
-user_name: '{{user_name}}'
-date: '{{date}}'
-sections_completed:
-  ['technology_stack', 'language_rules', 'framework_rules', 'testing_rules', 'quality_rules', 'workflow_rules', 'anti_patterns']
-status: 'complete'
-rule_count: { { total_rules } }
-optimized_for_llm: true
----
-```
-
-**Add Usage Section:**
-Append the usage guidelines from step 3 to complete the document.
-
-### 6. Completion Validation
-
-Final checks before completion:
-
-**Content Validation:**
-✅ All critical technology versions documented
-✅ Language-specific rules are specific and actionable
-✅ Framework rules cover project conventions
-✅ Testing rules ensure consistency
-✅ Code quality rules maintain standards
-✅ Workflow rules prevent conflicts
-✅ Anti-pattern rules prevent common mistakes
-
-**Format Validation:**
-✅ Content is lean and optimized for LLMs
-✅ Structure is logical and scannable
-✅ No redundant or obvious information
-✅ Consistent formatting throughout
-
-### 7. Completion Message
-
-Present final completion to user:
-
-"✅ **Project Context Generation Complete!**
-
-Your optimized project context file is ready at:
-`{output_folder}/project-context.md`
-
-**📊 Context Summary:**
-
-- {{rule_count}} critical rules for AI agents
-- {{section_count}} comprehensive sections
-- Optimized for LLM context efficiency
-- Ready for immediate agent integration
-
-**🎯 Key Benefits:**
-
-- Consistent implementation across all AI agents
-- Reduced common mistakes and edge cases
-- Clear guidance for project-specific patterns
-- Minimal LLM context usage
-
-**📋 Next Steps:**
-
-1. AI agents will automatically read this file when implementing
-2. Update this file when your technology stack or patterns evolve
-3. Review quarterly to optimize and remove outdated rules
-
-Your project context will help ensure high-quality, consistent implementation across all development work. Great work capturing your project's critical implementation requirements!"
-
-## SUCCESS METRICS:
-
-✅ Complete project context file with all critical rules
-✅ Content optimized for LLM context efficiency
-✅ All technology versions and patterns documented
-✅ File structure is logical and scannable
-✅ Usage guidelines included for agents and humans
-✅ Frontmatter properly updated with completion status
-✅ User provided with clear next steps and benefits
-
-## FAILURE MODES:
-
-❌ Final content is too verbose for LLM consumption
-❌ Missing critical implementation rules or patterns
-❌ Not optimizing content for agent readability
-❌ Not providing clear usage guidelines
-❌ Frontmatter not properly updated
-❌ Not validating file completion before ending
-
-## WORKFLOW COMPLETE:
-
-This is the final step of the Generate Project Context workflow. The user now has a comprehensive, optimized project context file that will ensure consistent, high-quality implementation across all AI agents working on the project.
-
-The project context file serves as the critical "rules of the road" that agents need to implement code consistently with the project's standards and patterns.
-
-## On Complete
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
-
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/bmad-dev-auto/customize.toml

@@ -1,108 +0,0 @@
-# DO NOT EDIT -- overwritten on every update.
-#
-# Default customization values for bmad-dev-auto.
-# Override in _bmad/custom/bmad-dev-auto.toml or
-# _bmad/custom/bmad-dev-auto.user.toml.
-#
-# Merge rules:
-# - Strings replace the default.
-# - Lists append to the default list.
-# - Tables merge key by key.
-# - Arrays of tables merge by `id`: matching `id` replaces, new `id`s append.
-
-[workflow]
-
-# Extra instructions to run before config is loaded.
-
-activation_steps_prepend = []
-
-# Extra instructions to run after config is loaded and before step 01.
-
-activation_steps_append = []
-
-# Facts kept in context for the whole run.
-# Entries are literal text or file references prefixed with "file:".
-# File entries may use globs and are loaded during activation.
-
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
-
-# Instruction run by HALT after writing the terminal result.
-# Empty means no extra terminal behavior.
-
-on_complete = ""
-
-# Handoff for the implementation subagent in step 03. The whole execution
-# recipe — a subagent by default, but an override may run anything (e.g. an
-# external coding tool via bash). {spec_file} is substituted at run time.
-
-implementation_handoff = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Read {spec_file} fully and implement it. The spec is the sole source of truth for this change; its Spec Change Log entries are binding constraints, not history.
->
-> Guardrails:
->
-> - Work in the current project. Before starting, load every file listed in the spec frontmatter `context:`.
-> - Do not edit the spec file itself.
-> - Do not revert or overwrite changes unrelated to this spec.
-> - Run the verification described in the spec, plus focused checks for the code you touched.
->
-> When done, report: files changed with one line each, verification commands run and their outcomes, any files changed beyond the spec's tasks and why each was needed, anything you could not complete and why, and residual risks.
-"""
-
-# Review layers for the review step. `instruction` is the layer's whole
-# execution recipe — subagents by default, but an override may run anything
-# (e.g. an external reviewer via bash). {diff_output} is substituted at run
-# time. `when` (optional) gates a layer; empty `instruction` disables it.
-
-[[workflow.review_layers]]
-id = "blind-hunter"
-name = "Blind Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-adversarial-general` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "edge-case-hunter"
-name = "Edge Case Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "verification-gap"
-name = "Verification Gap Reviewer"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-verification-gap` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "intent-alignment"
-name = "Intent Alignment Auditor"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> You are an intent-alignment auditor. You have no other context about how this change was produced. Here is the verbatim intent this work started from:
->
-> {verbatim_intent}
->
-> Here is the diff:
->
-> {diff_output}
->
-> Your task is strictly descriptive — do not prescribe additional work. Report: (1) the defensible readings of the intent, enumerated; (2) which reading this diff implements; (3) where the readings and the diff diverge — specifically, which surface the intent's expectations live at versus which surface the diff's changes and its tests exercise.
-"""

package/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md

@@ -1,115 +0,0 @@
----
-name: bmad-quick-dev
-description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
----
-
-# Quick Dev New Preview Workflow
-
-**Goal:** Turn user intent into a hardened, reviewable artifact.
-
-**CRITICAL:** If a step says "read fully and follow step-XX", you read and follow step-XX. No exceptions.
-
-Subagents, when the capability is available, are an important part of this workflow. Use them as directed by the workflow steps.
-If you need an explicit user instruction to run them, ask once now for the whole workflow run.
-
-## READY FOR DEVELOPMENT STANDARD
-
-A specification is "Ready for Development" when:
-
-- **Actionable**: Every task has a file path and specific action.
-- **Logical**: Tasks ordered by dependency.
-- **Testable**: All ACs use Given/When/Then.
-- **Complete**: No placeholders or TBDs.
-- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
-- **Coherent**: No unresolved ambiguities or internal contradictions.
-
-## SCOPE STANDARD
-
-A specification should target a **single user-facing goal** within **900–1600 tokens**:
-
-- **Single goal**: One cohesive feature, even if it spans multiple layers/files. Multi-goal means >=2 **top-level independent shippable deliverables** — each could be reviewed, tested, and merged as a separate PR without breaking the others. Never count surface verbs, "and" conjunctions, or noun phrases. Never split cross-layer implementation details inside one user goal.
-  - Split: "add dark mode toggle AND refactor auth to JWT AND build admin dashboard"
-  - Don't split: "add validation and display errors" / "support drag-and-drop AND paste AND retry"
-- **900–1600 tokens**: Optimal range for LLM consumption. Below 900 risks ambiguity; above 1600 risks context-rot in implementation agents.
-- **Neither limit is a gate.** Both are proposals with user override.
-
-## Conventions
-
-- Bare paths (e.g. `step-01-clarify-and-route.md`) resolve from the skill root.
-- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
-- `{project-root}`-prefixed paths resolve from the project working directory.
-- `{skill-name}` resolves to the skill directory's basename.
-
-## On Activation
-
-### Step 1: Resolve the Workflow Block
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow`
-
-**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
-
-1. `{skill-root}/customize.toml` — defaults
-2. `{project-root}/_bmad/custom/{skill-name}.toml` — team overrides
-3. `{project-root}/_bmad/custom/{skill-name}.user.toml` — personal overrides
-
-Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
-
-### Step 2: Execute Prepend Steps
-
-Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
-
-### Step 3: Load Persistent Facts
-
-Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` -- load the referenced contents as facts. All other entries are facts verbatim.
-
-### Step 4: Load Config
-
-Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `project_context` = `**/project-context.md` (load if exists)
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- Language MUST be tailored to `{user_skill_level}`
-- Generate all documents in `{document_output_language}`
-
-### Step 5: Greet the User
-
-Greet `{user_name}`, speaking in `{communication_language}`.
-
-### Step 6: Execute Append Steps
-
-Execute each entry in `{workflow.activation_steps_append}` in order.
-
-Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **Micro-file Design**: Each step is self-contained and followed exactly
-- **Just-In-Time Loading**: Only load the current step file
-- **Sequential Enforcement**: Complete steps in order, no skipping
-- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
-- **Append-Only Building**: Build artifacts incrementally
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Read the entire step file before acting
-2. **FOLLOW SEQUENCE**: Execute sections in order
-3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
-4. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at checkpoints and wait for human input
-
-## FIRST STEP
-
-Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow.

package/src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml

@@ -1,83 +0,0 @@
-# DO NOT EDIT -- overwritten on every update.
-#
-# Default customization values for bmad-quick-dev.
-# Override in _bmad/custom/bmad-quick-dev.toml or
-# _bmad/custom/bmad-quick-dev.user.toml.
-#
-# Merge rules:
-# - Strings replace the default.
-# - Lists append to the default list.
-# - Tables merge key by key.
-# - Arrays of tables merge by `id`: matching `id` replaces, new `id`s append.
-
-[workflow]
-
-# Extra instructions to run before config is loaded and before the user is greeted.
-
-activation_steps_prepend = []
-
-# Extra instructions to run after the greeting and before step 01.
-
-activation_steps_append = []
-
-# Facts kept in context for the whole run.
-# Entries are literal text or file references prefixed with "file:".
-# File entries may use globs and are loaded during activation.
-
-persistent_facts = [
-  "file:{project-root}/**/project-context.md",
-]
-
-# Instruction run after Quick Dev completes.
-# Empty means no extra completion behavior.
-
-on_complete = ""
-
-# Review layers for the review step. `instruction` is the layer's whole
-# execution recipe — subagents by default, but an override may run anything
-# (e.g. an external reviewer via bash). {diff_output} is substituted at run
-# time. `when` (optional) gates a layer; empty `instruction` disables it.
-
-[[workflow.review_layers]]
-id = "blind-hunter"
-name = "Blind Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-adversarial-general` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "edge-case-hunter"
-name = "Edge Case Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
->
-> {diff_output}
-"""
-
-[[workflow.review_layers]]
-id = "verification-gap"
-name = "Verification Gap Reviewer"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-verification-gap` skill on this diff:
->
-> {diff_output}
-"""
-
-# Review layers for the one-shot route.
-
-[[workflow.oneshot_review_layers]]
-id = "blind-hunter"
-name = "Blind Hunter"
-instruction = """
-Launch a subagent with no prior conversation context, with this prompt:
-
-> Invoke the `bmad-review-adversarial-general` skill on the changed files.
-"""

package/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md

@@ -1,82 +0,0 @@
----
-deferred_work_file: '{implementation_artifacts}/deferred-work.md'
----
-
-# Step One-Shot: Implement, Review, Present
-
-## RULES
-
-- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- NEVER auto-push.
-- All review subagents must run at the same model capability as the current session.
-- Run subagents synchronously: launch them together, then wait for all results before continuing.
-
-## INSTRUCTIONS
-
-### Implement
-
-Follow `./sync-sprint-status.md` with `{target_status}` = `in-progress`.
-
-Implement the clarified intent directly.
-
-### Review
-
-The review layers for this route are `{workflow.oneshot_review_layers}`, resolved during activation.
-
-Skip every layer whose `instruction` is empty or missing, and every layer whose `when` condition (if present) does not hold. If no layers remain, HALT with status `blocked` and blocking condition `no active review layers`. Execute all remaining layers in parallel wherever their execution methods allow, following each layer's `instruction` verbatim after substituting any runtime placeholders.
-
-If a layer's instruction requires subagents and none are available, generate one review prompt file per such layer in `{implementation_artifacts}` and HALT. Ask the human to run each in a separate session and paste back the findings.
-
-### Classify
-
-Deduplicate all review findings. Three categories only:
-
-- **patch** — trivially fixable. Auto-fix immediately.
-- **defer** — pre-existing issue not caused by this change. Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
-  ```markdown
-  - source_spec: `{spec_file}`
-    summary: <one sentence>
-    evidence: <why this is real>
-  ```
-- **reject** — noise. Drop silently.
-
-If a finding is caused by this change but too significant for a trivial patch, HALT and present it to the human for decision before proceeding.
-
-### Generate Spec Trace
-
-Set `{title}` = a concise title derived from the clarified intent.
-
-Write `{spec_file}` using `./spec-template.md`. Fill only these sections — delete all others:
-
-1. **Frontmatter** — set `title: '{title}'`, `type`, `created`, `status: 'done'`. Add `route: 'one-shot'`.
-2. **Title and Intent** — `# {title}` heading and `## Intent` with **Problem** and **Approach** lines. Reuse the summary you already generated for the terminal.
-3. **Suggested Review Order** — append after Intent. Build using the same convention as `./step-05-present.md` § "Generate Suggested Review Order" (spec-file-relative links, concern-based ordering, ultra-concise framing).
-
-Follow `./sync-sprint-status.md` with `{target_status}` = `review`.
-
-### Commit
-
-If version control is available and the tree is dirty, create a local commit with a conventional message derived from the intent. If VCS is unavailable, skip.
-
-### Present
-
-1. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
-   - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
-2. Display a summary in conversation output, including:
-   - The commit hash (if one was created).
-   - List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
-   - Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
-   - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
-   - **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
-3. Offer to push and/or create a pull request.
-
-HALT and wait for human input.
-
-Workflow complete.
-
-## On Complete
-
-Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete`
-
-If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmm-skills/4-implementation/bmad-quick-dev/sync-sprint-status.md

@@ -1,19 +0,0 @@
-# Sync Sprint Status
-
-Shared sub-step for updating `sprint-status.yaml` during quick-dev. Called from any route (plan-code-review, one-shot, future routes) with a `{target_status}` parameter.
-
-## Preconditions
-
-Skip this entire file (return to caller) if ANY of:
-- `{story_key}` is unset
-- `{sprint_status}` does not exist on disk
-
-## Instructions
-
-1. Load the FULL `{sprint_status}` file.
-2. Find the `development_status` entry matching `{story_key}`. If not found, warn the user once (`"{story_key} not found in sprint-status; skipping sprint sync"`) and return to caller.
-3. **Idempotency check.** If `development_status[{story_key}]` is already at `{target_status}` or a later state (`review` is later than `in-progress`; `done` is later than both), return to caller — no write needed. Never regress a story's status.
-4. Set `development_status[{story_key}]` to `{target_status}`.
-5. **Epic lift (only when `{target_status}` = `in-progress`).** Derive the parent epic key as `epic-{N}` from the leading numeric segment of `{story_key}` (e.g., `3-2-digest-delivery` → `epic-3`). If that entry exists and is `backlog`, set it to `in-progress`. Leave it alone otherwise. Skip this sub-step entirely when `{target_status}` is not `in-progress`.
-6. Refresh `last_updated` to the current date.
-7. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS and WORKFLOW NOTES.