From 6df553f1b14eb450c7b7a19e372e9314d1763fb2 Mon Sep 17 00:00:00 2001 From: Jerome Revillard Date: Fri, 24 Apr 2026 17:21:47 +0200 Subject: [PATCH] feat: extend customize.toml to all 6 developer-execution workflows (#2303) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add uniform customization support to dev-story, code-review, sprint-planning, sprint-status, quick-dev, and checkpoint-preview, matching the same 4 extension points (activation_steps_prepend, activation_steps_append, persistent_facts, on_complete) already available on 17 BMM workflows from PR #2287. - Create customize.toml for each workflow - Add 6-step activation block to SKILL.md (merge workflow.md content in, delete workflow.md per PR #2287 pattern) - Wire on_complete at terminal steps (inline for XML workflows, ## On Complete section for step-file workflows) - Fix pre-existing step number reference in dev-story (Step 6 → 9) --- .../bmad-checkpoint-preview/SKILL.md | 59 ++- .../bmad-checkpoint-preview/customize.toml | 41 ++ .../bmad-checkpoint-preview/step-05-wrapup.md | 6 + .../bmad-code-review/SKILL.md | 86 +++- .../bmad-code-review/customize.toml | 41 ++ .../bmad-code-review/steps/step-04-present.md | 6 + .../bmad-code-review/workflow.md | 55 -- .../4-implementation/bmad-dev-story/SKILL.md | 481 +++++++++++++++++- .../bmad-dev-story/customize.toml | 41 ++ .../bmad-dev-story/workflow.md | 450 ---------------- .../4-implementation/bmad-quick-dev/SKILL.md | 107 +++- .../bmad-quick-dev/customize.toml | 41 ++ .../bmad-quick-dev/step-05-present.md | 6 + .../bmad-quick-dev/step-oneshot.md | 6 + .../bmad-quick-dev/workflow.md | 76 --- .../bmad-sprint-planning/SKILL.md | 295 ++++++++++- .../bmad-sprint-planning/customize.toml | 41 ++ .../bmad-sprint-planning/workflow.md | 263 ---------- .../bmad-sprint-status/SKILL.md | 293 ++++++++++- .../bmad-sprint-status/customize.toml | 41 ++ .../bmad-sprint-status/workflow.md | 261 ---------- 21 files changed, 1576 insertions(+), 1120 deletions(-) create mode 100644 src/bmm-skills/4-implementation/bmad-checkpoint-preview/customize.toml create mode 100644 src/bmm-skills/4-implementation/bmad-code-review/customize.toml delete mode 100644 src/bmm-skills/4-implementation/bmad-code-review/workflow.md create mode 100644 src/bmm-skills/4-implementation/bmad-dev-story/customize.toml delete mode 100644 src/bmm-skills/4-implementation/bmad-dev-story/workflow.md create mode 100644 src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml delete mode 100644 src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md create mode 100644 src/bmm-skills/4-implementation/bmad-sprint-planning/customize.toml delete mode 100644 src/bmm-skills/4-implementation/bmad-sprint-planning/workflow.md create mode 100644 src/bmm-skills/4-implementation/bmad-sprint-status/customize.toml delete mode 100644 src/bmm-skills/4-implementation/bmad-sprint-status/workflow.md diff --git a/src/bmm-skills/4-implementation/bmad-checkpoint-preview/SKILL.md b/src/bmm-skills/4-implementation/bmad-checkpoint-preview/SKILL.md index 2cfd04420..101dcf2bc 100644 --- a/src/bmm-skills/4-implementation/bmad-checkpoint-preview/SKILL.md +++ b/src/bmm-skills/4-implementation/bmad-checkpoint-preview/SKILL.md @@ -7,7 +7,55 @@ description: 'LLM-assisted human-in-the-loop review. Make sense of a change, foc **Goal:** Guide a human through reviewing a change — from purpose and context into details. -You are assisting the user in reviewing a change. +**Your Role:** You are assisting the user in reviewing a change. + +## Conventions + +- Bare paths (e.g. `step-01-orientation.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: + +- `implementation_artifacts` +- `planning_artifacts` +- `communication_language` +- `document_output_language` + +### Step 5: Greet the User + +Greet the user, speaking in `{communication_language}`. + +### Step 6: Execute Append Steps + +Execute each entry in `{workflow.activation_steps_append}` in order. + +Activation is complete. Begin the workflow below. ## Global Step Rules (apply to every step) @@ -15,15 +63,6 @@ You are assisting the user in reviewing a change. - **Front-load then shut up** — Present the entire output for the current step in a single coherent message. Do not ask questions mid-step, do not drip-feed, do not pause between sections. - **Language** — Speak in `{communication_language}`. Write any file output in `{document_output_language}`. -## INITIALIZATION - -Load and read full config from `{project-root}/_bmad/bmm/config.yaml` and resolve: - -- `implementation_artifacts` -- `planning_artifacts` -- `communication_language` -- `document_output_language` - ## FIRST STEP Read fully and follow `./step-01-orientation.md` to begin. diff --git a/src/bmm-skills/4-implementation/bmad-checkpoint-preview/customize.toml b/src/bmm-skills/4-implementation/bmad-checkpoint-preview/customize.toml new file mode 100644 index 000000000..2f9b034ac --- /dev/null +++ b/src/bmm-skills/4-implementation/bmad-checkpoint-preview/customize.toml @@ -0,0 +1,41 @@ +# DO NOT EDIT -- overwritten on every update. +# +# Workflow customization surface for bmad-checkpoint-preview. Mirrors the +# agent customization shape under the [workflow] namespace. + +[workflow] + +# --- Configurable below. Overrides merge per BMad structural rules: --- +# scalars: override wins • arrays (persistent_facts, activation_steps_*): append +# arrays-of-tables with `code`/`id`: replace matching items, append new ones. + +# Steps to run before the standard activation (config load, greet). +# Overrides append. Use for pre-flight loads, compliance checks, etc. + +activation_steps_prepend = [] + +# Steps to run after greet but before the workflow begins. +# Overrides append. Use for context-heavy setup that should happen +# once the user has been acknowledged. + +activation_steps_append = [] + +# Persistent facts the workflow keeps in mind for the whole run +# (standards, compliance constraints, stylistic guardrails). +# Distinct from the runtime memory sidecar — these are static context +# loaded on activation. Overrides append. +# +# Each entry is either: +# - a literal sentence, e.g. "All stories must include testable acceptance criteria." +# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md" +# (glob patterns are supported; the file's contents are loaded and treated as facts). + +persistent_facts = [ + "file:{project-root}/**/project-context.md", +] + +# Scalar: executed when the workflow reaches its final step, +# after the review decision (approve/rework/discuss) is made. Override wins. +# Leave empty for no custom post-completion behavior. + +on_complete = "" diff --git a/src/bmm-skills/4-implementation/bmad-checkpoint-preview/step-05-wrapup.md b/src/bmm-skills/4-implementation/bmad-checkpoint-preview/step-05-wrapup.md index 5f293d56c..346a1c535 100644 --- a/src/bmm-skills/4-implementation/bmad-checkpoint-preview/step-05-wrapup.md +++ b/src/bmm-skills/4-implementation/bmad-checkpoint-preview/step-05-wrapup.md @@ -22,3 +22,9 @@ HALT — do not proceed until the user makes their choice. - **Approve**: Acknowledge briefly. If the human wants to patch something before shipping, help apply the fix interactively. If reviewing a PR, offer to approve via `gh pr review --approve` — but confirm with the human before executing, since this is a visible action on a shared resource. - **Rework**: Ask what went wrong — was it the approach, the spec, or the implementation? Help the human decide on next steps (revert commit, open an issue, revise the spec, etc.). Help draft specific, actionable feedback tied to `path:line` locations if the change is a PR from someone else. - **Discuss**: Open conversation — answer questions, explore concerns, dig into any aspect. After discussion, return to the decision prompt above. + +## 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. diff --git a/src/bmm-skills/4-implementation/bmad-code-review/SKILL.md b/src/bmm-skills/4-implementation/bmad-code-review/SKILL.md index 32f020af7..44223f11a 100644 --- a/src/bmm-skills/4-implementation/bmad-code-review/SKILL.md +++ b/src/bmm-skills/4-implementation/bmad-code-review/SKILL.md @@ -3,4 +3,88 @@ name: bmad-code-review description: 'Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"' --- -Follow the instructions in ./workflow.md. +# Code Review Workflow + +**Goal:** Review code changes adversarially using parallel review layers and structured triage. + +**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler. + +## Conventions + +- Bare paths (e.g. `checklist.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) +- CLAUDE.md / memory files (load if exist) +- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_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. Begin the workflow below. + +## 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 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: `./steps/step-01-gather-context.md` diff --git a/src/bmm-skills/4-implementation/bmad-code-review/customize.toml b/src/bmm-skills/4-implementation/bmad-code-review/customize.toml new file mode 100644 index 000000000..26ba792f9 --- /dev/null +++ b/src/bmm-skills/4-implementation/bmad-code-review/customize.toml @@ -0,0 +1,41 @@ +# DO NOT EDIT -- overwritten on every update. +# +# Workflow customization surface for bmad-code-review. Mirrors the +# agent customization shape under the [workflow] namespace. + +[workflow] + +# --- Configurable below. Overrides merge per BMad structural rules: --- +# scalars: override wins • arrays (persistent_facts, activation_steps_*): append +# arrays-of-tables with `code`/`id`: replace matching items, append new ones. + +# Steps to run before the standard activation (config load, greet). +# Overrides append. Use for pre-flight loads, compliance checks, etc. + +activation_steps_prepend = [] + +# Steps to run after greet but before the workflow begins. +# Overrides append. Use for context-heavy setup that should happen +# once the user has been acknowledged. + +activation_steps_append = [] + +# Persistent facts the workflow keeps in mind for the whole run +# (standards, compliance constraints, stylistic guardrails). +# Distinct from the runtime memory sidecar — these are static context +# loaded on activation. Overrides append. +# +# Each entry is either: +# - a literal sentence, e.g. "All stories must include testable acceptance criteria." +# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md" +# (glob patterns are supported; the file's contents are loaded and treated as facts). + +persistent_facts = [ + "file:{project-root}/**/project-context.md", +] + +# Scalar: executed when the workflow reaches its final step, +# after review findings are presented and sprint status is synced. Override wins. +# Leave empty for no custom post-completion behavior. + +on_complete = "" diff --git a/src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md b/src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md index 2a6a70e44..1697c769c 100644 --- a/src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md +++ b/src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md @@ -124,3 +124,9 @@ Present the user with follow-up options: > 3. **Done** — end the workflow **HALT** — I am waiting for your choice. Do not proceed until the user selects an option. + +## 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. diff --git a/src/bmm-skills/4-implementation/bmad-code-review/workflow.md b/src/bmm-skills/4-implementation/bmad-code-review/workflow.md deleted file mode 100644 index 2cad2d870..000000000 --- a/src/bmm-skills/4-implementation/bmad-code-review/workflow.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -main_config: '{project-root}/_bmad/bmm/config.yaml' ---- - -# Code Review Workflow - -**Goal:** Review code changes adversarially using parallel review layers and structured triage. - -**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler. - - -## 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 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 - - -## INITIALIZATION SEQUENCE - -### 1. Configuration Loading - -Load and read full config from `{main_config}` 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) -- CLAUDE.md / memory files (load if exist) - -YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`. - -### 2. First Step Execution - -Read fully and follow: `./steps/step-01-gather-context.md` to begin the workflow. diff --git a/src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md b/src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md index 0eb505cc7..94dda993a 100644 --- a/src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md +++ b/src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md @@ -3,4 +3,483 @@ name: bmad-dev-story description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"' --- -Follow the instructions in ./workflow.md. +# Dev Story Workflow + +**Goal:** Execute story implementation following a context filled story spec file. + +**Your Role:** Developer implementing the story. +- 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 9 decides completion. +- User skill level ({user_skill_level}) affects conversation style ONLY, not code updates. + +## Conventions + +- Bare paths (e.g. `steps/step-01-init.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`, `user_name` +- `communication_language`, `document_output_language` +- `user_skill_level` +- `implementation_artifacts` +- `date` as system-generated current datetime + +### 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. Begin the workflow below. + +## Paths + +- `story_file` = `` (explicit story path; auto-discovered if empty) +- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml` + +## Execution + + + 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 9 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 {implementation_artifacts} 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 {implementation_artifacts} 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" + Update last_updated field to current date + 🚀 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" + + + + + 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 continuously without pausing until all tasks/subtasks are complete or explicit HALT condition + 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 + + + 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 + + + + 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" + Update last_updated field to current date + 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 + + + + 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") + + 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 + - How to test or verify the changes + - 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 + Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting. + + + diff --git a/src/bmm-skills/4-implementation/bmad-dev-story/customize.toml b/src/bmm-skills/4-implementation/bmad-dev-story/customize.toml new file mode 100644 index 000000000..84f5dcbe4 --- /dev/null +++ b/src/bmm-skills/4-implementation/bmad-dev-story/customize.toml @@ -0,0 +1,41 @@ +# DO NOT EDIT -- overwritten on every update. +# +# Workflow customization surface for bmad-dev-story. Mirrors the +# agent customization shape under the [workflow] namespace. + +[workflow] + +# --- Configurable below. Overrides merge per BMad structural rules: --- +# scalars: override wins • arrays (persistent_facts, activation_steps_*): append +# arrays-of-tables with `code`/`id`: replace matching items, append new ones. + +# Steps to run before the standard activation (config load, greet). +# Overrides append. Use for pre-flight loads, compliance checks, etc. + +activation_steps_prepend = [] + +# Steps to run after greet but before the workflow begins. +# Overrides append. Use for context-heavy setup that should happen +# once the user has been acknowledged. + +activation_steps_append = [] + +# Persistent facts the workflow keeps in mind for the whole run +# (standards, compliance constraints, stylistic guardrails). +# Distinct from the runtime memory sidecar — these are static context +# loaded on activation. Overrides append. +# +# Each entry is either: +# - a literal sentence, e.g. "All stories must include testable acceptance criteria." +# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md" +# (glob patterns are supported; the file's contents are loaded and treated as facts). + +persistent_facts = [ + "file:{project-root}/**/project-context.md", +] + +# Scalar: executed when the workflow reaches its final step, +# after the story implementation is complete and status is updated. Override wins. +# Leave empty for no custom post-completion behavior. + +on_complete = "" diff --git a/src/bmm-skills/4-implementation/bmad-dev-story/workflow.md b/src/bmm-skills/4-implementation/bmad-dev-story/workflow.md deleted file mode 100644 index 4164479c3..000000000 --- a/src/bmm-skills/4-implementation/bmad-dev-story/workflow.md +++ /dev/null @@ -1,450 +0,0 @@ -# Dev Story Workflow - -**Goal:** Execute story implementation following a context filled story spec file. - -**Your Role:** Developer implementing the story. -- 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. - ---- - -## INITIALIZATION - -### Configuration Loading - -Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve: - -- `project_name`, `user_name` -- `communication_language`, `document_output_language` -- `user_skill_level` -- `implementation_artifacts` -- `date` as system-generated current datetime - -### Paths - -- `story_file` = `` (explicit story path; auto-discovered if empty) -- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml` - -### Context - -- `project_context` = `**/project-context.md` (load if exists) - ---- - -## EXECUTION - - - 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 {implementation_artifacts} 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 {implementation_artifacts} 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" - Update last_updated field to current date - 🚀 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" - - - - - 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 continuously without pausing until all tasks/subtasks are complete or explicit HALT condition - 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 - - - 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 - - - - 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" - Update last_updated field to current date - 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 - - - - 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") - - 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 - - How to test or verify the changes - - 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 - - - diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md b/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md index b2f0df476..f5326fc3f 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md @@ -3,4 +3,109 @@ 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.' --- -Follow the instructions in ./workflow.md. +# 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. + +## 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. + +## 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) +- CLAUDE.md / memory files (load if exist) +- 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. Begin the workflow below. + +## 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. diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml b/src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml new file mode 100644 index 000000000..351465443 --- /dev/null +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml @@ -0,0 +1,41 @@ +# DO NOT EDIT -- overwritten on every update. +# +# Workflow customization surface for bmad-quick-dev. Mirrors the +# agent customization shape under the [workflow] namespace. + +[workflow] + +# --- Configurable below. Overrides merge per BMad structural rules: --- +# scalars: override wins • arrays (persistent_facts, activation_steps_*): append +# arrays-of-tables with `code`/`id`: replace matching items, append new ones. + +# Steps to run before the standard activation (config load, greet). +# Overrides append. Use for pre-flight loads, compliance checks, etc. + +activation_steps_prepend = [] + +# Steps to run after greet but before the workflow begins. +# Overrides append. Use for context-heavy setup that should happen +# once the user has been acknowledged. + +activation_steps_append = [] + +# Persistent facts the workflow keeps in mind for the whole run +# (standards, compliance constraints, stylistic guardrails). +# Distinct from the runtime memory sidecar — these are static context +# loaded on activation. Overrides append. +# +# Each entry is either: +# - a literal sentence, e.g. "All stories must include testable acceptance criteria." +# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md" +# (glob patterns are supported; the file's contents are loaded and treated as facts). + +persistent_facts = [ + "file:{project-root}/**/project-context.md", +] + +# Scalar: executed when the workflow reaches its final step, +# after implementation is complete and explanations are provided. Override wins. +# Leave empty for no custom post-completion behavior. + +on_complete = "" diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md b/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md index 6b1a1501b..5efe96164 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md @@ -70,3 +70,9 @@ Display summary of your work to the user, including the commit hash if one was c - Offer to push and/or create a pull request. 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. diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md b/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md index 62192c74a..72078b34d 100644 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md +++ b/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md @@ -63,3 +63,9 @@ If version control is available and the tree is dirty, create a local commit wit 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. diff --git a/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md b/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md deleted file mode 100644 index 8e13989fb..000000000 --- a/src/bmm-skills/4-implementation/bmad-quick-dev/workflow.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -main_config: '{project-root}/_bmad/bmm/config.yaml' ---- - -# 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. - - -## 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. - - -## 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. - - -## 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 - - -## INITIALIZATION SEQUENCE - -### 1. Configuration Loading - -Load and read full config from `{main_config}` 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) -- CLAUDE.md / memory files (load if exist) - -YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`. - -### 2. First Step Execution - -Read fully and follow: `./step-01-clarify-and-route.md` to begin the workflow. diff --git a/src/bmm-skills/4-implementation/bmad-sprint-planning/SKILL.md b/src/bmm-skills/4-implementation/bmad-sprint-planning/SKILL.md index 85783cf00..25266d716 100644 --- a/src/bmm-skills/4-implementation/bmad-sprint-planning/SKILL.md +++ b/src/bmm-skills/4-implementation/bmad-sprint-planning/SKILL.md @@ -3,4 +3,297 @@ name: bmad-sprint-planning description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"' --- -Follow the instructions in ./workflow.md. +# Sprint Planning Workflow + +**Goal:** Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file. + +**Your Role:** You are a Developer generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml. + +## Conventions + +- Bare paths (e.g. `checklist.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`, `user_name` +- `communication_language`, `document_output_language` +- `implementation_artifacts` +- `planning_artifacts` +- `date` as system-generated current datetime +- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}` +- 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. Begin the workflow below. + +## Paths + +- `tracking_system` = `file-system` +- `project_key` = `NOKEY` +- `story_location` = `{implementation_artifacts}` +- `story_location_absolute` = `{implementation_artifacts}` +- `epics_location` = `{planning_artifacts}` +- `epics_pattern` = `*epic*.md` +- `status_file` = `{implementation_artifacts}/sprint-status.yaml` + +## Input Files + +| Input | Path | Load Strategy | +|-------|------|---------------| +| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD | + +## Execution + +### Document Discovery - Full Epic Loading + +**Strategy**: Sprint planning needs ALL epics and stories to build complete status tracking. + +**Epic Discovery Process:** + +1. **Search for whole document first** - Look for `epics.md`, `bmm-epics.md`, or any `*epic*.md` file +2. **Check for sharded version** - If whole document not found, look for `epics/index.md` +3. **If sharded version found**: + - Read `index.md` to understand the document structure + - Read ALL epic section files listed in the index (e.g., `epic-1.md`, `epic-2.md`, etc.) + - Process all epics and their stories from the combined content + - This ensures complete sprint status coverage +4. **Priority**: If both whole and sharded versions exist, use the whole document + +**Fuzzy matching**: Be flexible with document names - users may use variations like `epics.md`, `bmm-epics.md`, `user-stories.md`, etc. + + + + +Load {project_context} for project-wide patterns and conventions (if exists) +Communicate in {communication_language} with {user_name} +Look for all files matching `{epics_pattern}` in {epics_location} +Could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files + +For each epic file found, extract: + +- Epic numbers from headers like `## Epic 1:` or `## Epic 2:` +- Story IDs and titles from patterns like `### Story 1.1: User Authentication` +- Convert story format from `Epic.Story: Title` to kebab-case key: `epic-story-title` + +**Story ID Conversion Rules:** + +- Original: `### Story 1.1: User Authentication` +- Replace period with dash: `1-1` +- Convert title to kebab-case: `user-authentication` +- Final key: `1-1-user-authentication` + +Build complete inventory of all epics and stories from all epic files + + + +For each epic found, create entries in this order: + +1. **Epic entry** - Key: `epic-{num}`, Default status: `backlog` +2. **Story entries** - Key: `{epic}-{story}-{title}`, Default status: `backlog` +3. **Retrospective entry** - Key: `epic-{num}-retrospective`, Default status: `optional` + +**Example structure:** + +```yaml +development_status: + epic-1: backlog + 1-1-user-authentication: backlog + 1-2-account-management: backlog + epic-1-retrospective: optional +``` + + + + +For each story, detect current status by checking files: + +**Story file detection:** + +- Check: `{story_location_absolute}/{story-key}.md` (e.g., `stories/1-1-user-authentication.md`) +- If exists → upgrade status to at least `ready-for-dev` + +**Preservation rule:** + +- If existing `{status_file}` exists and has more advanced status, preserve it +- Never downgrade status (e.g., don't change `done` to `ready-for-dev`) + +**Status Flow Reference:** + +- Epic: `backlog` → `in-progress` → `done` +- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done` +- Retrospective: `optional` ↔ `done` + + + +Create or update {status_file} with: + +**File Structure:** + +```yaml +# generated: {date} +# last_updated: {date} +# project: {project_name} +# project_key: {project_key} +# tracking_system: {tracking_system} +# story_location: {story_location} + +# STATUS DEFINITIONS: +# ================== +# Epic Status: +# - backlog: Epic not yet started +# - in-progress: Epic actively being worked on +# - done: All stories in epic completed +# +# Epic Status Transitions: +# - backlog → in-progress: Automatically when first story is created (via create-story) +# - in-progress → done: Manually when all stories reach 'done' status +# +# Story Status: +# - backlog: Story only exists in epic file +# - ready-for-dev: Story file created in stories folder +# - in-progress: Developer actively working on implementation +# - review: Ready for code review (via Dev's code-review workflow) +# - done: Story completed +# +# Retrospective Status: +# - optional: Can be completed but not required +# - done: Retrospective has been completed +# +# WORKFLOW NOTES: +# =============== +# - Epic transitions to 'in-progress' automatically when first story is created +# - Stories can be worked in parallel if team capacity allows +# - Developer typically creates next story after previous one is 'done' to incorporate learnings +# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended) + +generated: { date } +last_updated: { date } +project: { project_name } +project_key: { project_key } +tracking_system: { tracking_system } +story_location: { story_location } + +development_status: + # All epics, stories, and retrospectives in order +``` + +Write the complete sprint status YAML to {status_file} +CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing +Ensure all items are ordered: epic, its stories, its retrospective, next epic... + + + +Perform validation checks: + +- [ ] Every epic in epic files appears in {status_file} +- [ ] Every story in epic files appears in {status_file} +- [ ] Every epic has a corresponding retrospective entry +- [ ] No items in {status_file} that don't exist in epic files +- [ ] All status values are legal (match state machine definitions) +- [ ] File is valid YAML syntax + +Count totals: + +- Total epics: {{epic_count}} +- Total stories: {{story_count}} +- Epics in-progress: {{in_progress_count}} +- Stories done: {{done_count}} + +Display completion summary to {user_name} in {communication_language}: + +**Sprint Status Generated Successfully** + +- **File Location:** {status_file} +- **Total Epics:** {{epic_count}} +- **Total Stories:** {{story_count}} +- **Epics In Progress:** {{in_progress_count}} +- **Stories Completed:** {{done_count}} + +**Next Steps:** + +1. Review the generated {status_file} +2. Use this file to track development progress +3. Agents will update statuses as they work +4. Re-run this workflow to refresh auto-detected statuses + +Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting. + + + + +## Additional Documentation + +### Status State Machine + +**Epic Status Flow:** + +``` +backlog → in-progress → done +``` + +- **backlog**: Epic not yet started +- **in-progress**: Epic actively being worked on (stories being created/implemented) +- **done**: All stories in epic completed + +**Story Status Flow:** + +``` +backlog → ready-for-dev → in-progress → review → done +``` + +- **backlog**: Story only exists in epic file +- **ready-for-dev**: Story file created (e.g., `stories/1-3-plant-naming.md`) +- **in-progress**: Developer actively working +- **review**: Ready for code review (via Dev's code-review workflow) +- **done**: Completed + +**Retrospective Status:** + +``` +optional ↔ done +``` + +- **optional**: Ready to be conducted but not required +- **done**: Finished + +### Guidelines + +1. **Epic Activation**: Mark epic as `in-progress` when starting work on its first story +2. **Sequential Default**: Stories are typically worked in order, but parallel work is supported +3. **Parallel Work Supported**: Multiple stories can be `in-progress` if team capacity allows +4. **Review Before Done**: Stories should pass through `review` before `done` +5. **Learning Transfer**: Developer typically creates next story after previous one is `done` to incorporate learnings diff --git a/src/bmm-skills/4-implementation/bmad-sprint-planning/customize.toml b/src/bmm-skills/4-implementation/bmad-sprint-planning/customize.toml new file mode 100644 index 000000000..bc89e8230 --- /dev/null +++ b/src/bmm-skills/4-implementation/bmad-sprint-planning/customize.toml @@ -0,0 +1,41 @@ +# DO NOT EDIT -- overwritten on every update. +# +# Workflow customization surface for bmad-sprint-planning. Mirrors the +# agent customization shape under the [workflow] namespace. + +[workflow] + +# --- Configurable below. Overrides merge per BMad structural rules: --- +# scalars: override wins • arrays (persistent_facts, activation_steps_*): append +# arrays-of-tables with `code`/`id`: replace matching items, append new ones. + +# Steps to run before the standard activation (config load, greet). +# Overrides append. Use for pre-flight loads, compliance checks, etc. + +activation_steps_prepend = [] + +# Steps to run after greet but before the workflow begins. +# Overrides append. Use for context-heavy setup that should happen +# once the user has been acknowledged. + +activation_steps_append = [] + +# Persistent facts the workflow keeps in mind for the whole run +# (standards, compliance constraints, stylistic guardrails). +# Distinct from the runtime memory sidecar — these are static context +# loaded on activation. Overrides append. +# +# Each entry is either: +# - a literal sentence, e.g. "All stories must include testable acceptance criteria." +# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md" +# (glob patterns are supported; the file's contents are loaded and treated as facts). + +persistent_facts = [ + "file:{project-root}/**/project-context.md", +] + +# Scalar: executed when the workflow reaches its final step, +# after sprint-status.yaml is generated and validated. Override wins. +# Leave empty for no custom post-completion behavior. + +on_complete = "" diff --git a/src/bmm-skills/4-implementation/bmad-sprint-planning/workflow.md b/src/bmm-skills/4-implementation/bmad-sprint-planning/workflow.md deleted file mode 100644 index 99a2e2528..000000000 --- a/src/bmm-skills/4-implementation/bmad-sprint-planning/workflow.md +++ /dev/null @@ -1,263 +0,0 @@ -# Sprint Planning Workflow - -**Goal:** Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file. - -**Your Role:** You are a Developer generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml. - ---- - -## INITIALIZATION - -### Configuration Loading - -Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve: - -- `project_name`, `user_name` -- `communication_language`, `document_output_language` -- `implementation_artifacts` -- `planning_artifacts` -- `date` as system-generated current datetime -- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}` - -### Paths - -- `tracking_system` = `file-system` -- `project_key` = `NOKEY` -- `story_location` = `{implementation_artifacts}` -- `story_location_absolute` = `{implementation_artifacts}` -- `epics_location` = `{planning_artifacts}` -- `epics_pattern` = `*epic*.md` -- `status_file` = `{implementation_artifacts}/sprint-status.yaml` - -### Input Files - -| Input | Path | Load Strategy | -|-------|------|---------------| -| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD | - -### Context - -- `project_context` = `**/project-context.md` (load if exists) - ---- - -## EXECUTION - -### Document Discovery - Full Epic Loading - -**Strategy**: Sprint planning needs ALL epics and stories to build complete status tracking. - -**Epic Discovery Process:** - -1. **Search for whole document first** - Look for `epics.md`, `bmm-epics.md`, or any `*epic*.md` file -2. **Check for sharded version** - If whole document not found, look for `epics/index.md` -3. **If sharded version found**: - - Read `index.md` to understand the document structure - - Read ALL epic section files listed in the index (e.g., `epic-1.md`, `epic-2.md`, etc.) - - Process all epics and their stories from the combined content - - This ensures complete sprint status coverage -4. **Priority**: If both whole and sharded versions exist, use the whole document - -**Fuzzy matching**: Be flexible with document names - users may use variations like `epics.md`, `bmm-epics.md`, `user-stories.md`, etc. - - - - -Load {project_context} for project-wide patterns and conventions (if exists) -Communicate in {communication_language} with {user_name} -Look for all files matching `{epics_pattern}` in {epics_location} -Could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files - -For each epic file found, extract: - -- Epic numbers from headers like `## Epic 1:` or `## Epic 2:` -- Story IDs and titles from patterns like `### Story 1.1: User Authentication` -- Convert story format from `Epic.Story: Title` to kebab-case key: `epic-story-title` - -**Story ID Conversion Rules:** - -- Original: `### Story 1.1: User Authentication` -- Replace period with dash: `1-1` -- Convert title to kebab-case: `user-authentication` -- Final key: `1-1-user-authentication` - -Build complete inventory of all epics and stories from all epic files - - - -For each epic found, create entries in this order: - -1. **Epic entry** - Key: `epic-{num}`, Default status: `backlog` -2. **Story entries** - Key: `{epic}-{story}-{title}`, Default status: `backlog` -3. **Retrospective entry** - Key: `epic-{num}-retrospective`, Default status: `optional` - -**Example structure:** - -```yaml -development_status: - epic-1: backlog - 1-1-user-authentication: backlog - 1-2-account-management: backlog - epic-1-retrospective: optional -``` - - - - -For each story, detect current status by checking files: - -**Story file detection:** - -- Check: `{story_location_absolute}/{story-key}.md` (e.g., `stories/1-1-user-authentication.md`) -- If exists → upgrade status to at least `ready-for-dev` - -**Preservation rule:** - -- If existing `{status_file}` exists and has more advanced status, preserve it -- Never downgrade status (e.g., don't change `done` to `ready-for-dev`) - -**Status Flow Reference:** - -- Epic: `backlog` → `in-progress` → `done` -- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done` -- Retrospective: `optional` ↔ `done` - - - -Create or update {status_file} with: - -**File Structure:** - -```yaml -# generated: {date} -# last_updated: {date} -# project: {project_name} -# project_key: {project_key} -# tracking_system: {tracking_system} -# story_location: {story_location} - -# STATUS DEFINITIONS: -# ================== -# Epic Status: -# - backlog: Epic not yet started -# - in-progress: Epic actively being worked on -# - done: All stories in epic completed -# -# Epic Status Transitions: -# - backlog → in-progress: Automatically when first story is created (via create-story) -# - in-progress → done: Manually when all stories reach 'done' status -# -# Story Status: -# - backlog: Story only exists in epic file -# - ready-for-dev: Story file created in stories folder -# - in-progress: Developer actively working on implementation -# - review: Ready for code review (via Dev's code-review workflow) -# - done: Story completed -# -# Retrospective Status: -# - optional: Can be completed but not required -# - done: Retrospective has been completed -# -# WORKFLOW NOTES: -# =============== -# - Epic transitions to 'in-progress' automatically when first story is created -# - Stories can be worked in parallel if team capacity allows -# - Developer typically creates next story after previous one is 'done' to incorporate learnings -# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended) - -generated: { date } -last_updated: { date } -project: { project_name } -project_key: { project_key } -tracking_system: { tracking_system } -story_location: { story_location } - -development_status: - # All epics, stories, and retrospectives in order -``` - -Write the complete sprint status YAML to {status_file} -CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing -Ensure all items are ordered: epic, its stories, its retrospective, next epic... - - - -Perform validation checks: - -- [ ] Every epic in epic files appears in {status_file} -- [ ] Every story in epic files appears in {status_file} -- [ ] Every epic has a corresponding retrospective entry -- [ ] No items in {status_file} that don't exist in epic files -- [ ] All status values are legal (match state machine definitions) -- [ ] File is valid YAML syntax - -Count totals: - -- Total epics: {{epic_count}} -- Total stories: {{story_count}} -- Epics in-progress: {{in_progress_count}} -- Stories done: {{done_count}} - -Display completion summary to {user_name} in {communication_language}: - -**Sprint Status Generated Successfully** - -- **File Location:** {status_file} -- **Total Epics:** {{epic_count}} -- **Total Stories:** {{story_count}} -- **Epics In Progress:** {{in_progress_count}} -- **Stories Completed:** {{done_count}} - -**Next Steps:** - -1. Review the generated {status_file} -2. Use this file to track development progress -3. Agents will update statuses as they work -4. Re-run this workflow to refresh auto-detected statuses - - - - - -## Additional Documentation - -### Status State Machine - -**Epic Status Flow:** - -``` -backlog → in-progress → done -``` - -- **backlog**: Epic not yet started -- **in-progress**: Epic actively being worked on (stories being created/implemented) -- **done**: All stories in epic completed - -**Story Status Flow:** - -``` -backlog → ready-for-dev → in-progress → review → done -``` - -- **backlog**: Story only exists in epic file -- **ready-for-dev**: Story file created (e.g., `stories/1-3-plant-naming.md`) -- **in-progress**: Developer actively working -- **review**: Ready for code review (via Dev's code-review workflow) -- **done**: Completed - -**Retrospective Status:** - -``` -optional ↔ done -``` - -- **optional**: Ready to be conducted but not required -- **done**: Finished - -### Guidelines - -1. **Epic Activation**: Mark epic as `in-progress` when starting work on its first story -2. **Sequential Default**: Stories are typically worked in order, but parallel work is supported -3. **Parallel Work Supported**: Multiple stories can be `in-progress` if team capacity allows -4. **Review Before Done**: Stories should pass through `review` before `done` -5. **Learning Transfer**: Developer typically creates next story after previous one is `done` to incorporate learnings diff --git a/src/bmm-skills/4-implementation/bmad-sprint-status/SKILL.md b/src/bmm-skills/4-implementation/bmad-sprint-status/SKILL.md index 3a15968e8..c52a84947 100644 --- a/src/bmm-skills/4-implementation/bmad-sprint-status/SKILL.md +++ b/src/bmm-skills/4-implementation/bmad-sprint-status/SKILL.md @@ -3,4 +3,295 @@ name: bmad-sprint-status description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"' --- -Follow the instructions in ./workflow.md. +# Sprint Status Workflow + +**Goal:** Summarize sprint status, surface risks, and recommend the next workflow action. + +**Your Role:** You are a Developer providing clear, actionable sprint visibility. No time estimates — focus on status, risks, and next steps. + +## Conventions + +- Bare paths (e.g. `checklist.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`, `user_name` +- `communication_language`, `document_output_language` +- `implementation_artifacts` +- `date` as system-generated current datetime +- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_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. Begin the workflow below. + +## Paths + +- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml` + +## Input Files + +| Input | Path | Load Strategy | +|-------|------|---------------| +| Sprint status | `{sprint_status_file}` | FULL_LOAD | + +## Execution + + + + + Set mode = {{mode}} if provided by caller; otherwise mode = "interactive" + + + Jump to Step 20 + + + + Jump to Step 30 + + + + Continue to Step 1 + + + + + Load {project_context} for project-wide patterns and conventions (if exists) + Try {sprint_status_file} + + sprint-status.yaml not found. +Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-status. + Exit workflow + + Continue to Step 2 + + + + Read the FULL file: {sprint_status_file} + Parse fields: generated, last_updated, project, project_key, tracking_system, story_location + Parse development_status map. Classify keys: +- Epics: keys starting with "epic-" (and not ending with "-retrospective") +- Retrospectives: keys ending with "-retrospective" +- Stories: everything else (e.g., 1-2-login-form) + Map legacy story status "drafted" → "ready-for-dev" + Count story statuses: backlog, ready-for-dev, in-progress, review, done + Map legacy epic status "contexted" → "in-progress" + Count epic statuses: backlog, in-progress, done + Count retrospective statuses: optional, done + +Validate all statuses against known values: + +- Valid story statuses: backlog, ready-for-dev, in-progress, review, done, drafted (legacy) +- Valid epic statuses: backlog, in-progress, done, contexted (legacy) +- Valid retrospective statuses: optional, done + + + +**Unknown status detected:** +{{#each invalid_entries}} + +- `{{key}}`: "{{status}}" (not recognized) + {{/each}} + +**Valid statuses:** + +- Stories: backlog, ready-for-dev, in-progress, review, done +- Epics: backlog, in-progress, done +- Retrospectives: optional, done + + How should these be corrected? + {{#each invalid_entries}} + {{@index}}. {{key}}: "{{status}}" → [select valid status] + {{/each}} + +Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue without fixing: + +Update sprint-status.yaml with corrected values +Re-parse the file with corrected statuses + + + +Detect risks: + +- IF any story has status "review": suggest `/bmad:bmm:workflows:code-review` +- IF any story has status "in-progress" AND no stories have status "ready-for-dev": recommend staying focused on active story +- IF all epics have status "backlog" AND no stories have status "ready-for-dev": prompt `/bmad:bmm:workflows:create-story` +- IF `last_updated` timestamp is more than 7 days old (or `last_updated` is missing, fall back to `generated`): warn "sprint-status.yaml may be stale" +- IF any story key doesn't match an epic pattern (e.g., story "5-1-..." but no "epic-5"): warn "orphaned story detected" +- IF any epic has status in-progress but has no associated stories: warn "in-progress epic has no stories" + + + + Pick the next recommended workflow using priority: + When selecting "first" story: sort by epic number, then story number (e.g., 1-1 before 1-2 before 2-1) + 1. If any story status == in-progress → recommend `dev-story` for the first in-progress story + 2. Else if any story status == review → recommend `code-review` for the first review story + 3. Else if any story status == ready-for-dev → recommend `dev-story` + 4. Else if any story status == backlog → recommend `create-story` + 5. Else if any retrospective status == optional → recommend `retrospective` + 6. Else → All implementation items done; congratulate the user - you both did amazing work together! + Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV) + + + + +## Sprint Status + +- Project: {{project}} ({{project_key}}) +- Tracking: {{tracking_system}} +- Status file: {sprint_status_file} + +**Stories:** backlog {{count_backlog}}, ready-for-dev {{count_ready}}, in-progress {{count_in_progress}}, review {{count_review}}, done {{count_done}} + +**Epics:** backlog {{epic_backlog}}, in-progress {{epic_in_progress}}, done {{epic_done}} + +**Next Recommendation:** /bmad:bmm:workflows:{{next_workflow_id}} ({{next_story_id}}) + +{{#if risks}} +**Risks:** +{{#each risks}} + +- {{this}} + {{/each}} + {{/if}} + + + + + + Pick an option: +1) Run recommended workflow now +2) Show all stories grouped by status +3) Show raw sprint-status.yaml +4) Exit +Choice: + + + Run `/bmad:bmm:workflows:{{next_workflow_id}}`. +If the command targets a story, set `story_key={{next_story_id}}` when prompted. + + + + +### Stories by Status +- In Progress: {{stories_in_progress}} +- Review: {{stories_in_review}} +- Ready for Dev: {{stories_ready_for_dev}} +- Backlog: {{stories_backlog}} +- Done: {{stories_done}} + + + + + Display the full contents of {sprint_status_file} + + + + Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting. + Exit workflow + + + + + + + + + Load and parse {sprint_status_file} same as Step 2 + Compute recommendation same as Step 3 + next_workflow_id = {{next_workflow_id}} + next_story_id = {{next_story_id}} + count_backlog = {{count_backlog}} + count_ready = {{count_ready}} + count_in_progress = {{count_in_progress}} + count_review = {{count_review}} + count_done = {{count_done}} + epic_backlog = {{epic_backlog}} + epic_in_progress = {{epic_in_progress}} + epic_done = {{epic_done}} + risks = {{risks}} + Return to caller + + + + + + + + Check that {sprint_status_file} exists + + is_valid = false + error = "sprint-status.yaml missing" + suggestion = "Run sprint-planning to create it" + Return + + +Read and parse {sprint_status_file} + +Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location (last_updated is optional for backward compatibility) + +is_valid = false +error = "Missing required field(s): {{missing_fields}}" +suggestion = "Re-run sprint-planning or add missing fields manually" +Return + + +Verify development_status section exists with at least one entry + +is_valid = false +error = "development_status missing or empty" +suggestion = "Re-run sprint-planning or repair the file manually" +Return + + +Validate all status values against known valid statuses: + +- Stories: backlog, ready-for-dev, in-progress, review, done (legacy: drafted) +- Epics: backlog, in-progress, done (legacy: contexted) +- Retrospectives: optional, done + + is_valid = false + error = "Invalid status values: {{invalid_entries}}" + suggestion = "Fix invalid statuses in sprint-status.yaml" + Return + + +is_valid = true +message = "sprint-status.yaml valid: metadata complete, all statuses recognized" +Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting. + + + diff --git a/src/bmm-skills/4-implementation/bmad-sprint-status/customize.toml b/src/bmm-skills/4-implementation/bmad-sprint-status/customize.toml new file mode 100644 index 000000000..c3c5600c4 --- /dev/null +++ b/src/bmm-skills/4-implementation/bmad-sprint-status/customize.toml @@ -0,0 +1,41 @@ +# DO NOT EDIT -- overwritten on every update. +# +# Workflow customization surface for bmad-sprint-status. Mirrors the +# agent customization shape under the [workflow] namespace. + +[workflow] + +# --- Configurable below. Overrides merge per BMad structural rules: --- +# scalars: override wins • arrays (persistent_facts, activation_steps_*): append +# arrays-of-tables with `code`/`id`: replace matching items, append new ones. + +# Steps to run before the standard activation (config load, greet). +# Overrides append. Use for pre-flight loads, compliance checks, etc. + +activation_steps_prepend = [] + +# Steps to run after greet but before the workflow begins. +# Overrides append. Use for context-heavy setup that should happen +# once the user has been acknowledged. + +activation_steps_append = [] + +# Persistent facts the workflow keeps in mind for the whole run +# (standards, compliance constraints, stylistic guardrails). +# Distinct from the runtime memory sidecar — these are static context +# loaded on activation. Overrides append. +# +# Each entry is either: +# - a literal sentence, e.g. "All stories must include testable acceptance criteria." +# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md" +# (glob patterns are supported; the file's contents are loaded and treated as facts). + +persistent_facts = [ + "file:{project-root}/**/project-context.md", +] + +# Scalar: executed when the workflow reaches its final step, +# after sprint status is summarized and risks are surfaced. Override wins. +# Leave empty for no custom post-completion behavior. + +on_complete = "" diff --git a/src/bmm-skills/4-implementation/bmad-sprint-status/workflow.md b/src/bmm-skills/4-implementation/bmad-sprint-status/workflow.md deleted file mode 100644 index 7b72c717c..000000000 --- a/src/bmm-skills/4-implementation/bmad-sprint-status/workflow.md +++ /dev/null @@ -1,261 +0,0 @@ -# Sprint Status Workflow - -**Goal:** Summarize sprint status, surface risks, and recommend the next workflow action. - -**Your Role:** You are a Developer providing clear, actionable sprint visibility. No time estimates — focus on status, risks, and next steps. - ---- - -## INITIALIZATION - -### Configuration Loading - -Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve: - -- `project_name`, `user_name` -- `communication_language`, `document_output_language` -- `implementation_artifacts` -- `date` as system-generated current datetime -- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}` - -### Paths - -- `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml` - -### Input Files - -| Input | Path | Load Strategy | -|-------|------|---------------| -| Sprint status | `{sprint_status_file}` | FULL_LOAD | - -### Context - -- `project_context` = `**/project-context.md` (load if exists) - ---- - -## EXECUTION - - - - - Set mode = {{mode}} if provided by caller; otherwise mode = "interactive" - - - Jump to Step 20 - - - - Jump to Step 30 - - - - Continue to Step 1 - - - - - Load {project_context} for project-wide patterns and conventions (if exists) - Try {sprint_status_file} - - ❌ sprint-status.yaml not found. -Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-status. - Exit workflow - - Continue to Step 2 - - - - Read the FULL file: {sprint_status_file} - Parse fields: generated, last_updated, project, project_key, tracking_system, story_location - Parse development_status map. Classify keys: - - Epics: keys starting with "epic-" (and not ending with "-retrospective") - - Retrospectives: keys ending with "-retrospective" - - Stories: everything else (e.g., 1-2-login-form) - Map legacy story status "drafted" → "ready-for-dev" - Count story statuses: backlog, ready-for-dev, in-progress, review, done - Map legacy epic status "contexted" → "in-progress" - Count epic statuses: backlog, in-progress, done - Count retrospective statuses: optional, done - -Validate all statuses against known values: - -- Valid story statuses: backlog, ready-for-dev, in-progress, review, done, drafted (legacy) -- Valid epic statuses: backlog, in-progress, done, contexted (legacy) -- Valid retrospective statuses: optional, done - - - -⚠️ **Unknown status detected:** -{{#each invalid_entries}} - -- `{{key}}`: "{{status}}" (not recognized) - {{/each}} - -**Valid statuses:** - -- Stories: backlog, ready-for-dev, in-progress, review, done -- Epics: backlog, in-progress, done -- Retrospectives: optional, done - - How should these be corrected? - {{#each invalid_entries}} - {{@index}}. {{key}}: "{{status}}" → [select valid status] - {{/each}} - -Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue without fixing: - -Update sprint-status.yaml with corrected values -Re-parse the file with corrected statuses - - - -Detect risks: - -- IF any story has status "review": suggest `/bmad:bmm:workflows:code-review` -- IF any story has status "in-progress" AND no stories have status "ready-for-dev": recommend staying focused on active story -- IF all epics have status "backlog" AND no stories have status "ready-for-dev": prompt `/bmad:bmm:workflows:create-story` -- IF `last_updated` timestamp is more than 7 days old (or `last_updated` is missing, fall back to `generated`): warn "sprint-status.yaml may be stale" -- IF any story key doesn't match an epic pattern (e.g., story "5-1-..." but no "epic-5"): warn "orphaned story detected" -- IF any epic has status in-progress but has no associated stories: warn "in-progress epic has no stories" - - - - Pick the next recommended workflow using priority: - When selecting "first" story: sort by epic number, then story number (e.g., 1-1 before 1-2 before 2-1) - 1. If any story status == in-progress → recommend `dev-story` for the first in-progress story - 2. Else if any story status == review → recommend `code-review` for the first review story - 3. Else if any story status == ready-for-dev → recommend `dev-story` - 4. Else if any story status == backlog → recommend `create-story` - 5. Else if any retrospective status == optional → recommend `retrospective` - 6. Else → All implementation items done; congratulate the user - you both did amazing work together! - Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV) - - - - -## 📊 Sprint Status - -- Project: {{project}} ({{project_key}}) -- Tracking: {{tracking_system}} -- Status file: {sprint_status_file} - -**Stories:** backlog {{count_backlog}}, ready-for-dev {{count_ready}}, in-progress {{count_in_progress}}, review {{count_review}}, done {{count_done}} - -**Epics:** backlog {{epic_backlog}}, in-progress {{epic_in_progress}}, done {{epic_done}} - -**Next Recommendation:** /bmad:bmm:workflows:{{next_workflow_id}} ({{next_story_id}}) - -{{#if risks}} -**Risks:** -{{#each risks}} - -- {{this}} - {{/each}} - {{/if}} - - - - - - Pick an option: -1) Run recommended workflow now -2) Show all stories grouped by status -3) Show raw sprint-status.yaml -4) Exit -Choice: - - - Run `/bmad:bmm:workflows:{{next_workflow_id}}`. -If the command targets a story, set `story_key={{next_story_id}}` when prompted. - - - - -### Stories by Status -- In Progress: {{stories_in_progress}} -- Review: {{stories_in_review}} -- Ready for Dev: {{stories_ready_for_dev}} -- Backlog: {{stories_backlog}} -- Done: {{stories_done}} - - - - - Display the full contents of {sprint_status_file} - - - - Exit workflow - - - - - - - - - Load and parse {sprint_status_file} same as Step 2 - Compute recommendation same as Step 3 - next_workflow_id = {{next_workflow_id}} - next_story_id = {{next_story_id}} - count_backlog = {{count_backlog}} - count_ready = {{count_ready}} - count_in_progress = {{count_in_progress}} - count_review = {{count_review}} - count_done = {{count_done}} - epic_backlog = {{epic_backlog}} - epic_in_progress = {{epic_in_progress}} - epic_done = {{epic_done}} - risks = {{risks}} - Return to caller - - - - - - - - Check that {sprint_status_file} exists - - is_valid = false - error = "sprint-status.yaml missing" - suggestion = "Run sprint-planning to create it" - Return - - -Read and parse {sprint_status_file} - -Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location (last_updated is optional for backward compatibility) - -is_valid = false -error = "Missing required field(s): {{missing_fields}}" -suggestion = "Re-run sprint-planning or add missing fields manually" -Return - - -Verify development_status section exists with at least one entry - -is_valid = false -error = "development_status missing or empty" -suggestion = "Re-run sprint-planning or repair the file manually" -Return - - -Validate all status values against known valid statuses: - -- Stories: backlog, ready-for-dev, in-progress, review, done (legacy: drafted) -- Epics: backlog, in-progress, done (legacy: contexted) -- Retrospectives: optional, done - - is_valid = false - error = "Invalid status values: {{invalid_entries}}" - suggestion = "Fix invalid statuses in sprint-status.yaml" - Return - - -is_valid = true -message = "sprint-status.yaml valid: metadata complete, all statuses recognized" - - -