feat: uniform customize.toml support across all BMM workflows (#2308)
* feat: extend customize.toml to all 6 developer-execution workflows (#2303) 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 <action> for XML workflows, ## On Complete section for step-file workflows) - Fix pre-existing step number reference in dev-story (Step 6 → 9) * fix: correct goto step="6" → step="9" in dev-story The XML goto at line 203 still pointed to step 6 ("Author comprehensive tests") instead of step 9 ("Story completion and mark for review"), which is the actual completion gate. This was the same class of pre-existing bug fixed in the text (M-1) but missed in the XML action. --------- Co-authored-by: Brian <bmadcode@gmail.com>
This commit is contained in:
Jérôme Revillard
GitHub
parent
0533976753
commit
e7a213ed07
|
|
@ -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.
|
**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)
|
## 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.
|
- **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}`.
|
- **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
|
## FIRST STEP
|
||||||
|
|
||||||
Read fully and follow `./step-01-orientation.md` to begin.
|
Read fully and follow `./step-01-orientation.md` to begin.
|
||||||
|
|
|
||||||
|
|
@ -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 = ""
|
||||||
|
|
@ -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.
|
- **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.
|
- **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.
|
- **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.
|
||||||
|
|
|
||||||
|
|
@ -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"'
|
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`
|
||||||
|
|
|
||||||
|
|
@ -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 = ""
|
||||||
|
|
@ -124,3 +124,9 @@ Present the user with follow-up options:
|
||||||
> 3. **Done** — end the workflow
|
> 3. **Done** — end the workflow
|
||||||
|
|
||||||
**HALT** — I am waiting for your choice. Do not proceed until the user selects an option.
|
**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.
|
||||||
|
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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"'
|
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
|
||||||
|
|
||||||
|
<workflow>
|
||||||
|
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
||||||
|
<critical>Generate all documents in {document_output_language}</critical>
|
||||||
|
<critical>Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List,
|
||||||
|
Change Log, and Status</critical>
|
||||||
|
<critical>Execute ALL steps in exact order; do NOT skip steps</critical>
|
||||||
|
<critical>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.</critical>
|
||||||
|
<critical>Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 9 decides completion.</critical>
|
||||||
|
<critical>User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.</critical>
|
||||||
|
|
||||||
|
<step n="1" goal="Find next ready story and load it" tag="sprint-status">
|
||||||
|
<check if="{{story_path}} is provided">
|
||||||
|
<action>Use {{story_path}} directly</action>
|
||||||
|
<action>Read COMPLETE story file</action>
|
||||||
|
<action>Extract story_key from filename or metadata</action>
|
||||||
|
<goto anchor="task_check" />
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- Sprint-based story discovery -->
|
||||||
|
<check if="{{sprint_status}} file exists">
|
||||||
|
<critical>MUST read COMPLETE sprint-status.yaml file from start to end to preserve order</critical>
|
||||||
|
<action>Load the FULL file: {{sprint_status}}</action>
|
||||||
|
<action>Read ALL lines from beginning to end - do not skip any content</action>
|
||||||
|
<action>Parse the development_status section completely to understand story order</action>
|
||||||
|
|
||||||
|
<action>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"
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<check if="no ready-for-dev or in-progress story found">
|
||||||
|
<output>📋 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.
|
||||||
|
</output>
|
||||||
|
<ask>Choose option [1], [2], [3], or [4], or specify story file path:</ask>
|
||||||
|
|
||||||
|
<check if="user chooses '1'">
|
||||||
|
<action>HALT - Run create-story to create next story</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="user chooses '2'">
|
||||||
|
<action>HALT - Run validate-create-story to improve existing stories</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="user chooses '3'">
|
||||||
|
<ask>Provide the story file path to develop:</ask>
|
||||||
|
<action>Store user-provided story path as {{story_path}}</action>
|
||||||
|
<goto anchor="task_check" />
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="user chooses '4'">
|
||||||
|
<output>Loading {{sprint_status}} for detailed status review...</output>
|
||||||
|
<action>Display detailed sprint status analysis</action>
|
||||||
|
<action>HALT - User can review sprint status and provide story path</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="user provides story file path">
|
||||||
|
<action>Store user-provided story path as {{story_path}}</action>
|
||||||
|
<goto anchor="task_check" />
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- Non-sprint story discovery -->
|
||||||
|
<check if="{{sprint_status}} file does NOT exist">
|
||||||
|
<action>Search {implementation_artifacts} for stories directly</action>
|
||||||
|
<action>Find stories with "ready-for-dev" status in files</action>
|
||||||
|
<action>Look for story files matching pattern: *-*-*.md</action>
|
||||||
|
<action>Read each candidate story file to check Status section</action>
|
||||||
|
|
||||||
|
<check if="no ready-for-dev stories found in story files">
|
||||||
|
<output>📋 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
|
||||||
|
</output>
|
||||||
|
<ask>What would you like to do? Choose option [1], [2], or [3]:</ask>
|
||||||
|
|
||||||
|
<check if="user chooses '1'">
|
||||||
|
<action>HALT - Run create-story to create next story</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="user chooses '2'">
|
||||||
|
<action>HALT - Run validate-create-story to improve existing stories</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="user chooses '3'">
|
||||||
|
<ask>It's unclear what story you want developed. Please provide the full path to the story file:</ask>
|
||||||
|
<action>Store user-provided story path as {{story_path}}</action>
|
||||||
|
<action>Continue with provided story file</action>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="ready-for-dev story found in files">
|
||||||
|
<action>Use discovered story file and extract story_key</action>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Store the found story_key (e.g., "1-2-user-authentication") for later status updates</action>
|
||||||
|
<action>Find matching story file in {implementation_artifacts} using story_key pattern: {{story_key}}.md</action>
|
||||||
|
<action>Read COMPLETE story file from discovered path</action>
|
||||||
|
|
||||||
|
<anchor id="task_check" />
|
||||||
|
|
||||||
|
<action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status</action>
|
||||||
|
|
||||||
|
<action>Load comprehensive context from story file's Dev Notes section</action>
|
||||||
|
<action>Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications</action>
|
||||||
|
<action>Use enhanced story context to inform implementation decisions and approaches</action>
|
||||||
|
|
||||||
|
<action>Identify first incomplete task (unchecked [ ]) in Tasks/Subtasks</action>
|
||||||
|
|
||||||
|
<action if="no incomplete tasks">
|
||||||
|
<goto step="9">Completion sequence</goto>
|
||||||
|
</action>
|
||||||
|
<action if="story file inaccessible">HALT: "Cannot develop story without access to story file"</action>
|
||||||
|
<action if="incomplete task or subtask requirements ambiguous">ASK user to clarify or HALT</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="2" goal="Load project context and story information">
|
||||||
|
<critical>Load all available context to inform implementation</critical>
|
||||||
|
|
||||||
|
<action>Load {project_context} for coding standards and project-wide patterns (if exists)</action>
|
||||||
|
<action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status</action>
|
||||||
|
<action>Load comprehensive context from story file's Dev Notes section</action>
|
||||||
|
<action>Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications</action>
|
||||||
|
<action>Use enhanced story context to inform implementation decisions and approaches</action>
|
||||||
|
<output>✅ **Context Loaded**
|
||||||
|
Story and project context available for implementation
|
||||||
|
</output>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="3" goal="Detect review continuation and extract review context">
|
||||||
|
<critical>Determine if this is a fresh start or continuation after code review</critical>
|
||||||
|
|
||||||
|
<action>Check if "Senior Developer Review (AI)" section exists in the story file</action>
|
||||||
|
<action>Check if "Review Follow-ups (AI)" subsection exists under Tasks/Subtasks</action>
|
||||||
|
|
||||||
|
<check if="Senior Developer Review section exists">
|
||||||
|
<action>Set review_continuation = true</action>
|
||||||
|
<action>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)
|
||||||
|
</action>
|
||||||
|
<action>Count unchecked [ ] review follow-up tasks in "Review Follow-ups (AI)" subsection</action>
|
||||||
|
<action>Store list of unchecked review items as {{pending_review_items}}</action>
|
||||||
|
|
||||||
|
<output>⏯️ **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.
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="Senior Developer Review section does NOT exist">
|
||||||
|
<action>Set review_continuation = false</action>
|
||||||
|
<action>Set {{pending_review_items}} = empty</action>
|
||||||
|
|
||||||
|
<output>🚀 **Starting Fresh Implementation**
|
||||||
|
|
||||||
|
Story: {{story_key}}
|
||||||
|
Story Status: {{current_status}}
|
||||||
|
First incomplete task: {{first_task_description}}
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="4" goal="Mark story in-progress" tag="sprint-status">
|
||||||
|
<check if="{{sprint_status}} file exists">
|
||||||
|
<action>Load the FULL file: {{sprint_status}}</action>
|
||||||
|
<action>Read all development_status entries to find {{story_key}}</action>
|
||||||
|
<action>Get current status value for development_status[{{story_key}}]</action>
|
||||||
|
|
||||||
|
<check if="current status == 'ready-for-dev' OR review_continuation == true">
|
||||||
|
<action>Update the story in the sprint status report to = "in-progress"</action>
|
||||||
|
<action>Update last_updated field to current date</action>
|
||||||
|
<output>🚀 Starting work on story {{story_key}}
|
||||||
|
Status updated: ready-for-dev → in-progress
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="current status == 'in-progress'">
|
||||||
|
<output>⏯️ Resuming work on story {{story_key}}
|
||||||
|
Story is already marked in-progress
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="current status is neither ready-for-dev nor in-progress">
|
||||||
|
<output>⚠️ Unexpected story status: {{current_status}}
|
||||||
|
Expected ready-for-dev or in-progress. Continuing anyway...
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Store {{current_sprint_status}} for later use</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="{{sprint_status}} file does NOT exist">
|
||||||
|
<output>ℹ️ No sprint status file exists - story progress will be tracked in story file only</output>
|
||||||
|
<action>Set {{current_sprint_status}} = "no-sprint-tracking"</action>
|
||||||
|
</check>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="5" goal="Implement task following red-green-refactor cycle">
|
||||||
|
<critical>FOLLOW THE STORY FILE TASKS/SUBTASKS SEQUENCE EXACTLY AS WRITTEN - NO DEVIATION</critical>
|
||||||
|
|
||||||
|
<action>Review the current task/subtask from the story file - this is your authoritative implementation guide</action>
|
||||||
|
<action>Plan implementation following red-green-refactor cycle</action>
|
||||||
|
|
||||||
|
<!-- RED PHASE -->
|
||||||
|
<action>Write FAILING tests first for the task/subtask functionality</action>
|
||||||
|
<action>Confirm tests fail before implementation - this validates test correctness</action>
|
||||||
|
|
||||||
|
<!-- GREEN PHASE -->
|
||||||
|
<action>Implement MINIMAL code to make tests pass</action>
|
||||||
|
<action>Run tests to confirm they now pass</action>
|
||||||
|
<action>Handle error conditions and edge cases as specified in task/subtask</action>
|
||||||
|
|
||||||
|
<!-- REFACTOR PHASE -->
|
||||||
|
<action>Improve code structure while keeping tests green</action>
|
||||||
|
<action>Ensure code follows architecture patterns and coding standards from Dev Notes</action>
|
||||||
|
|
||||||
|
<action>Document technical approach and decisions in Dev Agent Record → Implementation Plan</action>
|
||||||
|
|
||||||
|
<action if="new dependencies required beyond story specifications">HALT: "Additional dependencies need user approval"</action>
|
||||||
|
<action if="3 consecutive implementation failures occur">HALT and request guidance</action>
|
||||||
|
<action if="required configuration is missing">HALT: "Cannot proceed without necessary configuration files"</action>
|
||||||
|
|
||||||
|
<critical>NEVER implement anything not mapped to a specific task/subtask in the story file</critical>
|
||||||
|
<critical>NEVER proceed to next task until current task/subtask is complete AND tests pass</critical>
|
||||||
|
<critical>Execute continuously without pausing until all tasks/subtasks are complete or explicit HALT condition</critical>
|
||||||
|
<critical>Do NOT propose to pause for review until Step 9 completion gates are satisfied</critical>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="6" goal="Author comprehensive tests">
|
||||||
|
<action>Create unit tests for business logic and core functionality introduced/changed by the task</action>
|
||||||
|
<action>Add integration tests for component interactions specified in story requirements</action>
|
||||||
|
<action>Include end-to-end tests for critical user flows when story requirements demand them</action>
|
||||||
|
<action>Cover edge cases and error handling scenarios identified in story Dev Notes</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="7" goal="Run validations and tests">
|
||||||
|
<action>Determine how to run tests for this repo (infer test framework from project structure)</action>
|
||||||
|
<action>Run all existing tests to ensure no regressions</action>
|
||||||
|
<action>Run the new tests to verify implementation correctness</action>
|
||||||
|
<action>Run linting and code quality checks if configured in project</action>
|
||||||
|
<action>Validate implementation meets ALL story acceptance criteria; enforce quantitative thresholds explicitly</action>
|
||||||
|
<action if="regression tests fail">STOP and fix before continuing - identify breaking changes immediately</action>
|
||||||
|
<action if="new tests fail">STOP and fix before continuing - ensure implementation correctness</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="8" goal="Validate and mark task complete ONLY when fully done">
|
||||||
|
<critical>NEVER mark a task complete unless ALL conditions are met - NO LYING OR CHEATING</critical>
|
||||||
|
|
||||||
|
<!-- VALIDATION GATES -->
|
||||||
|
<action>Verify ALL tests for this task/subtask ACTUALLY EXIST and PASS 100%</action>
|
||||||
|
<action>Confirm implementation matches EXACTLY what the task/subtask specifies - no extra features</action>
|
||||||
|
<action>Validate that ALL acceptance criteria related to this task are satisfied</action>
|
||||||
|
<action>Run full test suite to ensure NO regressions introduced</action>
|
||||||
|
|
||||||
|
<!-- REVIEW FOLLOW-UP HANDLING -->
|
||||||
|
<check if="task is review follow-up (has [AI-Review] prefix)">
|
||||||
|
<action>Extract review item details (severity, description, related AC/file)</action>
|
||||||
|
<action>Add to resolution tracking list: {{resolved_review_items}}</action>
|
||||||
|
|
||||||
|
<!-- Mark task in Review Follow-ups section -->
|
||||||
|
<action>Mark task checkbox [x] in "Tasks/Subtasks → Review Follow-ups (AI)" section</action>
|
||||||
|
|
||||||
|
<!-- CRITICAL: Also mark corresponding action item in review section -->
|
||||||
|
<action>Find matching action item in "Senior Developer Review (AI) → Action Items" section by matching description</action>
|
||||||
|
<action>Mark that action item checkbox [x] as resolved</action>
|
||||||
|
|
||||||
|
<action>Add to Dev Agent Record → Completion Notes: "✅ Resolved review finding [{{severity}}]: {{description}}"</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- ONLY MARK COMPLETE IF ALL VALIDATION PASS -->
|
||||||
|
<check if="ALL validation gates pass AND tests ACTUALLY exist and pass">
|
||||||
|
<action>ONLY THEN mark the task (and subtasks) checkbox with [x]</action>
|
||||||
|
<action>Update File List section with ALL new, modified, or deleted files (paths relative to repo root)</action>
|
||||||
|
<action>Add completion notes to Dev Agent Record summarizing what was ACTUALLY implemented and tested</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="ANY validation fails">
|
||||||
|
<action>DO NOT mark task complete - fix issues first</action>
|
||||||
|
<action>HALT if unable to fix validation failures</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="review_continuation == true and {{resolved_review_items}} is not empty">
|
||||||
|
<action>Count total resolved review items in this session</action>
|
||||||
|
<action>Add Change Log entry: "Addressed code review findings - {{resolved_count}} items resolved (Date: {{date}})"</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Save the story file</action>
|
||||||
|
<action>Determine if more incomplete tasks remain</action>
|
||||||
|
<action if="more tasks remain">
|
||||||
|
<goto step="5">Next task</goto>
|
||||||
|
</action>
|
||||||
|
<action if="no tasks remain">
|
||||||
|
<goto step="9">Completion</goto>
|
||||||
|
</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="9" goal="Story completion and mark for review" tag="sprint-status">
|
||||||
|
<action>Verify ALL tasks and subtasks are marked [x] (re-scan the story document now)</action>
|
||||||
|
<action>Run the full regression suite (do not skip)</action>
|
||||||
|
<action>Confirm File List includes every changed file</action>
|
||||||
|
<action>Execute enhanced definition-of-done validation</action>
|
||||||
|
<action>Update the story Status to: "review"</action>
|
||||||
|
|
||||||
|
<!-- Enhanced Definition of Done Validation -->
|
||||||
|
<action>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
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<!-- Mark story ready for review - sprint status conditional -->
|
||||||
|
<check if="{sprint_status} file exists AND {{current_sprint_status}} != 'no-sprint-tracking'">
|
||||||
|
<action>Load the FULL file: {sprint_status}</action>
|
||||||
|
<action>Find development_status key matching {{story_key}}</action>
|
||||||
|
<action>Verify current status is "in-progress" (expected previous state)</action>
|
||||||
|
<action>Update development_status[{{story_key}}] = "review"</action>
|
||||||
|
<action>Update last_updated field to current date</action>
|
||||||
|
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
||||||
|
<output>✅ Story status updated to "review" in sprint-status.yaml</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="{sprint_status} file does NOT exist OR {{current_sprint_status}} == 'no-sprint-tracking'">
|
||||||
|
<output>ℹ️ Story status updated to "review" in story file (no sprint tracking configured)</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="story key not found in sprint status">
|
||||||
|
<output>⚠️ 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.
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<!-- Final validation gates -->
|
||||||
|
<action if="any task is incomplete">HALT - Complete remaining tasks before marking ready for review</action>
|
||||||
|
<action if="regression failures exist">HALT - Fix regression issues before completing</action>
|
||||||
|
<action if="File List is incomplete">HALT - Update File List with all changed files</action>
|
||||||
|
<action if="definition-of-done validation fails">HALT - Address DoD failures before completing</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="10" goal="Completion communication and user support">
|
||||||
|
<action>Execute the enhanced definition-of-done checklist using the validation framework</action>
|
||||||
|
<action>Prepare a concise summary in Dev Agent Record → Completion Notes</action>
|
||||||
|
|
||||||
|
<action>Communicate to {user_name} that story implementation is complete and ready for review</action>
|
||||||
|
<action>Summarize key accomplishments: story ID, story key, title, key changes made, tests added, files modified</action>
|
||||||
|
<action>Provide the story file path and current status (now "review")</action>
|
||||||
|
|
||||||
|
<action>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
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<check if="user asks for explanations">
|
||||||
|
<action>Provide clear, contextual explanations tailored to {user_skill_level}</action>
|
||||||
|
<action>Use examples and references to specific code when helpful</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Once explanations are complete (or user indicates no questions), suggest logical next steps</action>
|
||||||
|
<action>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
|
||||||
|
</action>
|
||||||
|
|
||||||
|
<output>💡 **Tip:** For best results, run `code-review` using a **different** LLM than the one that implemented this story.</output>
|
||||||
|
<check if="{sprint_status} file exists">
|
||||||
|
<action>Suggest checking {sprint_status} to see project progress</action>
|
||||||
|
</check>
|
||||||
|
<action>Remain flexible - allow user to choose their own path or ask for other assistance</action>
|
||||||
|
<action>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.</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
</workflow>
|
||||||
|
|
|
||||||
|
|
@ -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 = ""
|
||||||
|
|
@ -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
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
<critical>Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}</critical>
|
|
||||||
<critical>Generate all documents in {document_output_language}</critical>
|
|
||||||
<critical>Only modify the story file in these areas: Tasks/Subtasks checkboxes, Dev Agent Record (Debug Log, Completion Notes), File List,
|
|
||||||
Change Log, and Status</critical>
|
|
||||||
<critical>Execute ALL steps in exact order; do NOT skip steps</critical>
|
|
||||||
<critical>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.</critical>
|
|
||||||
<critical>Do NOT schedule a "next session" or request review pauses unless a HALT condition applies. Only Step 6 decides completion.</critical>
|
|
||||||
<critical>User skill level ({user_skill_level}) affects conversation style ONLY, not code updates.</critical>
|
|
||||||
|
|
||||||
<step n="1" goal="Find next ready story and load it" tag="sprint-status">
|
|
||||||
<check if="{{story_path}} is provided">
|
|
||||||
<action>Use {{story_path}} directly</action>
|
|
||||||
<action>Read COMPLETE story file</action>
|
|
||||||
<action>Extract story_key from filename or metadata</action>
|
|
||||||
<goto anchor="task_check" />
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<!-- Sprint-based story discovery -->
|
|
||||||
<check if="{{sprint_status}} file exists">
|
|
||||||
<critical>MUST read COMPLETE sprint-status.yaml file from start to end to preserve order</critical>
|
|
||||||
<action>Load the FULL file: {{sprint_status}}</action>
|
|
||||||
<action>Read ALL lines from beginning to end - do not skip any content</action>
|
|
||||||
<action>Parse the development_status section completely to understand story order</action>
|
|
||||||
|
|
||||||
<action>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"
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<check if="no ready-for-dev or in-progress story found">
|
|
||||||
<output>📋 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.
|
|
||||||
</output>
|
|
||||||
<ask>Choose option [1], [2], [3], or [4], or specify story file path:</ask>
|
|
||||||
|
|
||||||
<check if="user chooses '1'">
|
|
||||||
<action>HALT - Run create-story to create next story</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user chooses '2'">
|
|
||||||
<action>HALT - Run validate-create-story to improve existing stories</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user chooses '3'">
|
|
||||||
<ask>Provide the story file path to develop:</ask>
|
|
||||||
<action>Store user-provided story path as {{story_path}}</action>
|
|
||||||
<goto anchor="task_check" />
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user chooses '4'">
|
|
||||||
<output>Loading {{sprint_status}} for detailed status review...</output>
|
|
||||||
<action>Display detailed sprint status analysis</action>
|
|
||||||
<action>HALT - User can review sprint status and provide story path</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user provides story file path">
|
|
||||||
<action>Store user-provided story path as {{story_path}}</action>
|
|
||||||
<goto anchor="task_check" />
|
|
||||||
</check>
|
|
||||||
</check>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<!-- Non-sprint story discovery -->
|
|
||||||
<check if="{{sprint_status}} file does NOT exist">
|
|
||||||
<action>Search {implementation_artifacts} for stories directly</action>
|
|
||||||
<action>Find stories with "ready-for-dev" status in files</action>
|
|
||||||
<action>Look for story files matching pattern: *-*-*.md</action>
|
|
||||||
<action>Read each candidate story file to check Status section</action>
|
|
||||||
|
|
||||||
<check if="no ready-for-dev stories found in story files">
|
|
||||||
<output>📋 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
|
|
||||||
</output>
|
|
||||||
<ask>What would you like to do? Choose option [1], [2], or [3]:</ask>
|
|
||||||
|
|
||||||
<check if="user chooses '1'">
|
|
||||||
<action>HALT - Run create-story to create next story</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user chooses '2'">
|
|
||||||
<action>HALT - Run validate-create-story to improve existing stories</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="user chooses '3'">
|
|
||||||
<ask>It's unclear what story you want developed. Please provide the full path to the story file:</ask>
|
|
||||||
<action>Store user-provided story path as {{story_path}}</action>
|
|
||||||
<action>Continue with provided story file</action>
|
|
||||||
</check>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="ready-for-dev story found in files">
|
|
||||||
<action>Use discovered story file and extract story_key</action>
|
|
||||||
</check>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Store the found story_key (e.g., "1-2-user-authentication") for later status updates</action>
|
|
||||||
<action>Find matching story file in {implementation_artifacts} using story_key pattern: {{story_key}}.md</action>
|
|
||||||
<action>Read COMPLETE story file from discovered path</action>
|
|
||||||
|
|
||||||
<anchor id="task_check" />
|
|
||||||
|
|
||||||
<action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status</action>
|
|
||||||
|
|
||||||
<action>Load comprehensive context from story file's Dev Notes section</action>
|
|
||||||
<action>Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications</action>
|
|
||||||
<action>Use enhanced story context to inform implementation decisions and approaches</action>
|
|
||||||
|
|
||||||
<action>Identify first incomplete task (unchecked [ ]) in Tasks/Subtasks</action>
|
|
||||||
|
|
||||||
<action if="no incomplete tasks">
|
|
||||||
<goto step="6">Completion sequence</goto>
|
|
||||||
</action>
|
|
||||||
<action if="story file inaccessible">HALT: "Cannot develop story without access to story file"</action>
|
|
||||||
<action if="incomplete task or subtask requirements ambiguous">ASK user to clarify or HALT</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Load project context and story information">
|
|
||||||
<critical>Load all available context to inform implementation</critical>
|
|
||||||
|
|
||||||
<action>Load {project_context} for coding standards and project-wide patterns (if exists)</action>
|
|
||||||
<action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Notes, Dev Agent Record, File List, Change Log, Status</action>
|
|
||||||
<action>Load comprehensive context from story file's Dev Notes section</action>
|
|
||||||
<action>Extract developer guidance from Dev Notes: architecture requirements, previous learnings, technical specifications</action>
|
|
||||||
<action>Use enhanced story context to inform implementation decisions and approaches</action>
|
|
||||||
<output>✅ **Context Loaded**
|
|
||||||
Story and project context available for implementation
|
|
||||||
</output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Detect review continuation and extract review context">
|
|
||||||
<critical>Determine if this is a fresh start or continuation after code review</critical>
|
|
||||||
|
|
||||||
<action>Check if "Senior Developer Review (AI)" section exists in the story file</action>
|
|
||||||
<action>Check if "Review Follow-ups (AI)" subsection exists under Tasks/Subtasks</action>
|
|
||||||
|
|
||||||
<check if="Senior Developer Review section exists">
|
|
||||||
<action>Set review_continuation = true</action>
|
|
||||||
<action>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)
|
|
||||||
</action>
|
|
||||||
<action>Count unchecked [ ] review follow-up tasks in "Review Follow-ups (AI)" subsection</action>
|
|
||||||
<action>Store list of unchecked review items as {{pending_review_items}}</action>
|
|
||||||
|
|
||||||
<output>⏯️ **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.
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="Senior Developer Review section does NOT exist">
|
|
||||||
<action>Set review_continuation = false</action>
|
|
||||||
<action>Set {{pending_review_items}} = empty</action>
|
|
||||||
|
|
||||||
<output>🚀 **Starting Fresh Implementation**
|
|
||||||
|
|
||||||
Story: {{story_key}}
|
|
||||||
Story Status: {{current_status}}
|
|
||||||
First incomplete task: {{first_task_description}}
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Mark story in-progress" tag="sprint-status">
|
|
||||||
<check if="{{sprint_status}} file exists">
|
|
||||||
<action>Load the FULL file: {{sprint_status}}</action>
|
|
||||||
<action>Read all development_status entries to find {{story_key}}</action>
|
|
||||||
<action>Get current status value for development_status[{{story_key}}]</action>
|
|
||||||
|
|
||||||
<check if="current status == 'ready-for-dev' OR review_continuation == true">
|
|
||||||
<action>Update the story in the sprint status report to = "in-progress"</action>
|
|
||||||
<action>Update last_updated field to current date</action>
|
|
||||||
<output>🚀 Starting work on story {{story_key}}
|
|
||||||
Status updated: ready-for-dev → in-progress
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="current status == 'in-progress'">
|
|
||||||
<output>⏯️ Resuming work on story {{story_key}}
|
|
||||||
Story is already marked in-progress
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="current status is neither ready-for-dev nor in-progress">
|
|
||||||
<output>⚠️ Unexpected story status: {{current_status}}
|
|
||||||
Expected ready-for-dev or in-progress. Continuing anyway...
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Store {{current_sprint_status}} for later use</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="{{sprint_status}} file does NOT exist">
|
|
||||||
<output>ℹ️ No sprint status file exists - story progress will be tracked in story file only</output>
|
|
||||||
<action>Set {{current_sprint_status}} = "no-sprint-tracking"</action>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Implement task following red-green-refactor cycle">
|
|
||||||
<critical>FOLLOW THE STORY FILE TASKS/SUBTASKS SEQUENCE EXACTLY AS WRITTEN - NO DEVIATION</critical>
|
|
||||||
|
|
||||||
<action>Review the current task/subtask from the story file - this is your authoritative implementation guide</action>
|
|
||||||
<action>Plan implementation following red-green-refactor cycle</action>
|
|
||||||
|
|
||||||
<!-- RED PHASE -->
|
|
||||||
<action>Write FAILING tests first for the task/subtask functionality</action>
|
|
||||||
<action>Confirm tests fail before implementation - this validates test correctness</action>
|
|
||||||
|
|
||||||
<!-- GREEN PHASE -->
|
|
||||||
<action>Implement MINIMAL code to make tests pass</action>
|
|
||||||
<action>Run tests to confirm they now pass</action>
|
|
||||||
<action>Handle error conditions and edge cases as specified in task/subtask</action>
|
|
||||||
|
|
||||||
<!-- REFACTOR PHASE -->
|
|
||||||
<action>Improve code structure while keeping tests green</action>
|
|
||||||
<action>Ensure code follows architecture patterns and coding standards from Dev Notes</action>
|
|
||||||
|
|
||||||
<action>Document technical approach and decisions in Dev Agent Record → Implementation Plan</action>
|
|
||||||
|
|
||||||
<action if="new dependencies required beyond story specifications">HALT: "Additional dependencies need user approval"</action>
|
|
||||||
<action if="3 consecutive implementation failures occur">HALT and request guidance</action>
|
|
||||||
<action if="required configuration is missing">HALT: "Cannot proceed without necessary configuration files"</action>
|
|
||||||
|
|
||||||
<critical>NEVER implement anything not mapped to a specific task/subtask in the story file</critical>
|
|
||||||
<critical>NEVER proceed to next task until current task/subtask is complete AND tests pass</critical>
|
|
||||||
<critical>Execute continuously without pausing until all tasks/subtasks are complete or explicit HALT condition</critical>
|
|
||||||
<critical>Do NOT propose to pause for review until Step 9 completion gates are satisfied</critical>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="6" goal="Author comprehensive tests">
|
|
||||||
<action>Create unit tests for business logic and core functionality introduced/changed by the task</action>
|
|
||||||
<action>Add integration tests for component interactions specified in story requirements</action>
|
|
||||||
<action>Include end-to-end tests for critical user flows when story requirements demand them</action>
|
|
||||||
<action>Cover edge cases and error handling scenarios identified in story Dev Notes</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="7" goal="Run validations and tests">
|
|
||||||
<action>Determine how to run tests for this repo (infer test framework from project structure)</action>
|
|
||||||
<action>Run all existing tests to ensure no regressions</action>
|
|
||||||
<action>Run the new tests to verify implementation correctness</action>
|
|
||||||
<action>Run linting and code quality checks if configured in project</action>
|
|
||||||
<action>Validate implementation meets ALL story acceptance criteria; enforce quantitative thresholds explicitly</action>
|
|
||||||
<action if="regression tests fail">STOP and fix before continuing - identify breaking changes immediately</action>
|
|
||||||
<action if="new tests fail">STOP and fix before continuing - ensure implementation correctness</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="8" goal="Validate and mark task complete ONLY when fully done">
|
|
||||||
<critical>NEVER mark a task complete unless ALL conditions are met - NO LYING OR CHEATING</critical>
|
|
||||||
|
|
||||||
<!-- VALIDATION GATES -->
|
|
||||||
<action>Verify ALL tests for this task/subtask ACTUALLY EXIST and PASS 100%</action>
|
|
||||||
<action>Confirm implementation matches EXACTLY what the task/subtask specifies - no extra features</action>
|
|
||||||
<action>Validate that ALL acceptance criteria related to this task are satisfied</action>
|
|
||||||
<action>Run full test suite to ensure NO regressions introduced</action>
|
|
||||||
|
|
||||||
<!-- REVIEW FOLLOW-UP HANDLING -->
|
|
||||||
<check if="task is review follow-up (has [AI-Review] prefix)">
|
|
||||||
<action>Extract review item details (severity, description, related AC/file)</action>
|
|
||||||
<action>Add to resolution tracking list: {{resolved_review_items}}</action>
|
|
||||||
|
|
||||||
<!-- Mark task in Review Follow-ups section -->
|
|
||||||
<action>Mark task checkbox [x] in "Tasks/Subtasks → Review Follow-ups (AI)" section</action>
|
|
||||||
|
|
||||||
<!-- CRITICAL: Also mark corresponding action item in review section -->
|
|
||||||
<action>Find matching action item in "Senior Developer Review (AI) → Action Items" section by matching description</action>
|
|
||||||
<action>Mark that action item checkbox [x] as resolved</action>
|
|
||||||
|
|
||||||
<action>Add to Dev Agent Record → Completion Notes: "✅ Resolved review finding [{{severity}}]: {{description}}"</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<!-- ONLY MARK COMPLETE IF ALL VALIDATION PASS -->
|
|
||||||
<check if="ALL validation gates pass AND tests ACTUALLY exist and pass">
|
|
||||||
<action>ONLY THEN mark the task (and subtasks) checkbox with [x]</action>
|
|
||||||
<action>Update File List section with ALL new, modified, or deleted files (paths relative to repo root)</action>
|
|
||||||
<action>Add completion notes to Dev Agent Record summarizing what was ACTUALLY implemented and tested</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="ANY validation fails">
|
|
||||||
<action>DO NOT mark task complete - fix issues first</action>
|
|
||||||
<action>HALT if unable to fix validation failures</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="review_continuation == true and {{resolved_review_items}} is not empty">
|
|
||||||
<action>Count total resolved review items in this session</action>
|
|
||||||
<action>Add Change Log entry: "Addressed code review findings - {{resolved_count}} items resolved (Date: {{date}})"</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Save the story file</action>
|
|
||||||
<action>Determine if more incomplete tasks remain</action>
|
|
||||||
<action if="more tasks remain">
|
|
||||||
<goto step="5">Next task</goto>
|
|
||||||
</action>
|
|
||||||
<action if="no tasks remain">
|
|
||||||
<goto step="9">Completion</goto>
|
|
||||||
</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="9" goal="Story completion and mark for review" tag="sprint-status">
|
|
||||||
<action>Verify ALL tasks and subtasks are marked [x] (re-scan the story document now)</action>
|
|
||||||
<action>Run the full regression suite (do not skip)</action>
|
|
||||||
<action>Confirm File List includes every changed file</action>
|
|
||||||
<action>Execute enhanced definition-of-done validation</action>
|
|
||||||
<action>Update the story Status to: "review"</action>
|
|
||||||
|
|
||||||
<!-- Enhanced Definition of Done Validation -->
|
|
||||||
<action>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
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<!-- Mark story ready for review - sprint status conditional -->
|
|
||||||
<check if="{sprint_status} file exists AND {{current_sprint_status}} != 'no-sprint-tracking'">
|
|
||||||
<action>Load the FULL file: {sprint_status}</action>
|
|
||||||
<action>Find development_status key matching {{story_key}}</action>
|
|
||||||
<action>Verify current status is "in-progress" (expected previous state)</action>
|
|
||||||
<action>Update development_status[{{story_key}}] = "review"</action>
|
|
||||||
<action>Update last_updated field to current date</action>
|
|
||||||
<action>Save file, preserving ALL comments and structure including STATUS DEFINITIONS</action>
|
|
||||||
<output>✅ Story status updated to "review" in sprint-status.yaml</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="{sprint_status} file does NOT exist OR {{current_sprint_status}} == 'no-sprint-tracking'">
|
|
||||||
<output>ℹ️ Story status updated to "review" in story file (no sprint tracking configured)</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="story key not found in sprint status">
|
|
||||||
<output>⚠️ 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.
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<!-- Final validation gates -->
|
|
||||||
<action if="any task is incomplete">HALT - Complete remaining tasks before marking ready for review</action>
|
|
||||||
<action if="regression failures exist">HALT - Fix regression issues before completing</action>
|
|
||||||
<action if="File List is incomplete">HALT - Update File List with all changed files</action>
|
|
||||||
<action if="definition-of-done validation fails">HALT - Address DoD failures before completing</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="10" goal="Completion communication and user support">
|
|
||||||
<action>Execute the enhanced definition-of-done checklist using the validation framework</action>
|
|
||||||
<action>Prepare a concise summary in Dev Agent Record → Completion Notes</action>
|
|
||||||
|
|
||||||
<action>Communicate to {user_name} that story implementation is complete and ready for review</action>
|
|
||||||
<action>Summarize key accomplishments: story ID, story key, title, key changes made, tests added, files modified</action>
|
|
||||||
<action>Provide the story file path and current status (now "review")</action>
|
|
||||||
|
|
||||||
<action>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
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<check if="user asks for explanations">
|
|
||||||
<action>Provide clear, contextual explanations tailored to {user_skill_level}</action>
|
|
||||||
<action>Use examples and references to specific code when helpful</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Once explanations are complete (or user indicates no questions), suggest logical next steps</action>
|
|
||||||
<action>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
|
|
||||||
</action>
|
|
||||||
|
|
||||||
<output>💡 **Tip:** For best results, run `code-review` using a **different** LLM than the one that implemented this story.</output>
|
|
||||||
<check if="{sprint_status} file exists">
|
|
||||||
<action>Suggest checking {sprint_status} to see project progress</action>
|
|
||||||
</check>
|
|
||||||
<action>Remain flexible - allow user to choose their own path or ask for other assistance</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
@ -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.'
|
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.
|
||||||
|
|
|
||||||
|
|
@ -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 = ""
|
||||||
|
|
@ -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.
|
- Offer to push and/or create a pull request.
|
||||||
|
|
||||||
Workflow complete.
|
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.
|
||||||
|
|
|
||||||
|
|
@ -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.
|
HALT and wait for human input.
|
||||||
|
|
||||||
Workflow complete.
|
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.
|
||||||
|
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
@ -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"'
|
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.
|
||||||
|
|
||||||
|
<workflow>
|
||||||
|
|
||||||
|
<step n="1" goal="Parse epic files and extract all work items">
|
||||||
|
<action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
|
||||||
|
<action>Communicate in {communication_language} with {user_name}</action>
|
||||||
|
<action>Look for all files matching `{epics_pattern}` in {epics_location}</action>
|
||||||
|
<action>Could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files</action>
|
||||||
|
|
||||||
|
<action>For each epic file found, extract:</action>
|
||||||
|
|
||||||
|
- 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`
|
||||||
|
|
||||||
|
<action>Build complete inventory of all epics and stories from all epic files</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="2" goal="Build sprint status structure">
|
||||||
|
<action>For each epic found, create entries in this order:</action>
|
||||||
|
|
||||||
|
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
|
||||||
|
```
|
||||||
|
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="3" goal="Apply intelligent status detection">
|
||||||
|
<action>For each story, detect current status by checking files:</action>
|
||||||
|
|
||||||
|
**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`
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="4" goal="Generate sprint status file">
|
||||||
|
<action>Create or update {status_file} with:</action>
|
||||||
|
|
||||||
|
**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
|
||||||
|
```
|
||||||
|
|
||||||
|
<action>Write the complete sprint status YAML to {status_file}</action>
|
||||||
|
<action>CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing</action>
|
||||||
|
<action>Ensure all items are ordered: epic, its stories, its retrospective, next epic...</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="5" goal="Validate and report">
|
||||||
|
<action>Perform validation checks:</action>
|
||||||
|
|
||||||
|
- [ ] 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
|
||||||
|
|
||||||
|
<action>Count totals:</action>
|
||||||
|
|
||||||
|
- Total epics: {{epic_count}}
|
||||||
|
- Total stories: {{story_count}}
|
||||||
|
- Epics in-progress: {{in_progress_count}}
|
||||||
|
- Stories done: {{done_count}}
|
||||||
|
|
||||||
|
<action>Display completion summary to {user_name} in {communication_language}:</action>
|
||||||
|
|
||||||
|
**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
|
||||||
|
|
||||||
|
<action>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.</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
</workflow>
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
|
||||||
|
|
@ -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 = ""
|
||||||
|
|
@ -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.
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="1" goal="Parse epic files and extract all work items">
|
|
||||||
<action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
|
|
||||||
<action>Communicate in {communication_language} with {user_name}</action>
|
|
||||||
<action>Look for all files matching `{epics_pattern}` in {epics_location}</action>
|
|
||||||
<action>Could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files</action>
|
|
||||||
|
|
||||||
<action>For each epic file found, extract:</action>
|
|
||||||
|
|
||||||
- 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`
|
|
||||||
|
|
||||||
<action>Build complete inventory of all epics and stories from all epic files</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Build sprint status structure">
|
|
||||||
<action>For each epic found, create entries in this order:</action>
|
|
||||||
|
|
||||||
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
|
|
||||||
```
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Apply intelligent status detection">
|
|
||||||
<action>For each story, detect current status by checking files:</action>
|
|
||||||
|
|
||||||
**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`
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Generate sprint status file">
|
|
||||||
<action>Create or update {status_file} with:</action>
|
|
||||||
|
|
||||||
**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
|
|
||||||
```
|
|
||||||
|
|
||||||
<action>Write the complete sprint status YAML to {status_file}</action>
|
|
||||||
<action>CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing</action>
|
|
||||||
<action>Ensure all items are ordered: epic, its stories, its retrospective, next epic...</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Validate and report">
|
|
||||||
<action>Perform validation checks:</action>
|
|
||||||
|
|
||||||
- [ ] 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
|
|
||||||
|
|
||||||
<action>Count totals:</action>
|
|
||||||
|
|
||||||
- Total epics: {{epic_count}}
|
|
||||||
- Total stories: {{story_count}}
|
|
||||||
- Epics in-progress: {{in_progress_count}}
|
|
||||||
- Stories done: {{done_count}}
|
|
||||||
|
|
||||||
<action>Display completion summary to {user_name} in {communication_language}:</action>
|
|
||||||
|
|
||||||
**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
|
|
||||||
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
|
|
||||||
## 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
|
|
||||||
|
|
@ -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"'
|
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
|
||||||
|
|
||||||
|
<workflow>
|
||||||
|
|
||||||
|
<step n="0" goal="Determine execution mode">
|
||||||
|
<action>Set mode = {{mode}} if provided by caller; otherwise mode = "interactive"</action>
|
||||||
|
|
||||||
|
<check if="mode == data">
|
||||||
|
<action>Jump to Step 20</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="mode == validate">
|
||||||
|
<action>Jump to Step 30</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="mode == interactive">
|
||||||
|
<action>Continue to Step 1</action>
|
||||||
|
</check>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="1" goal="Locate sprint status file">
|
||||||
|
<action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
|
||||||
|
<action>Try {sprint_status_file}</action>
|
||||||
|
<check if="file not found">
|
||||||
|
<output>sprint-status.yaml not found.
|
||||||
|
Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-status.</output>
|
||||||
|
<action>Exit workflow</action>
|
||||||
|
</check>
|
||||||
|
<action>Continue to Step 2</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="2" goal="Read and parse sprint-status.yaml">
|
||||||
|
<action>Read the FULL file: {sprint_status_file}</action>
|
||||||
|
<action>Parse fields: generated, last_updated, project, project_key, tracking_system, story_location</action>
|
||||||
|
<action>Parse development_status map. Classify keys:</action>
|
||||||
|
- Epics: keys starting with "epic-" (and not ending with "-retrospective")
|
||||||
|
- Retrospectives: keys ending with "-retrospective"
|
||||||
|
- Stories: everything else (e.g., 1-2-login-form)
|
||||||
|
<action>Map legacy story status "drafted" → "ready-for-dev"</action>
|
||||||
|
<action>Count story statuses: backlog, ready-for-dev, in-progress, review, done</action>
|
||||||
|
<action>Map legacy epic status "contexted" → "in-progress"</action>
|
||||||
|
<action>Count epic statuses: backlog, in-progress, done</action>
|
||||||
|
<action>Count retrospective statuses: optional, done</action>
|
||||||
|
|
||||||
|
<action>Validate all statuses against known values:</action>
|
||||||
|
|
||||||
|
- 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
|
||||||
|
|
||||||
|
<check if="any status is unrecognized">
|
||||||
|
<output>
|
||||||
|
**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
|
||||||
|
</output>
|
||||||
|
<ask>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:</ask>
|
||||||
|
<check if="user provided corrections">
|
||||||
|
<action>Update sprint-status.yaml with corrected values</action>
|
||||||
|
<action>Re-parse the file with corrected statuses</action>
|
||||||
|
</check>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Detect risks:</action>
|
||||||
|
|
||||||
|
- 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"
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="3" goal="Select next action recommendation">
|
||||||
|
<action>Pick the next recommended workflow using priority:</action>
|
||||||
|
<note>When selecting "first" story: sort by epic number, then story number (e.g., 1-1 before 1-2 before 2-1)</note>
|
||||||
|
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!
|
||||||
|
<action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV)</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="4" goal="Display summary">
|
||||||
|
<output>
|
||||||
|
## 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}}
|
||||||
|
|
||||||
|
</output>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<step n="5" goal="Offer actions">
|
||||||
|
<ask>Pick an option:
|
||||||
|
1) Run recommended workflow now
|
||||||
|
2) Show all stories grouped by status
|
||||||
|
3) Show raw sprint-status.yaml
|
||||||
|
4) Exit
|
||||||
|
Choice:</ask>
|
||||||
|
|
||||||
|
<check if="choice == 1">
|
||||||
|
<output>Run `/bmad:bmm:workflows:{{next_workflow_id}}`.
|
||||||
|
If the command targets a story, set `story_key={{next_story_id}}` when prompted.</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="choice == 2">
|
||||||
|
<output>
|
||||||
|
### 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}}
|
||||||
|
</output>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="choice == 3">
|
||||||
|
<action>Display the full contents of {sprint_status_file}</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<check if="choice == 4">
|
||||||
|
<action>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.</action>
|
||||||
|
<action>Exit workflow</action>
|
||||||
|
</check>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<!-- ========================= -->
|
||||||
|
<!-- Data mode for other flows -->
|
||||||
|
<!-- ========================= -->
|
||||||
|
|
||||||
|
<step n="20" goal="Data mode output">
|
||||||
|
<action>Load and parse {sprint_status_file} same as Step 2</action>
|
||||||
|
<action>Compute recommendation same as Step 3</action>
|
||||||
|
<template-output>next_workflow_id = {{next_workflow_id}}</template-output>
|
||||||
|
<template-output>next_story_id = {{next_story_id}}</template-output>
|
||||||
|
<template-output>count_backlog = {{count_backlog}}</template-output>
|
||||||
|
<template-output>count_ready = {{count_ready}}</template-output>
|
||||||
|
<template-output>count_in_progress = {{count_in_progress}}</template-output>
|
||||||
|
<template-output>count_review = {{count_review}}</template-output>
|
||||||
|
<template-output>count_done = {{count_done}}</template-output>
|
||||||
|
<template-output>epic_backlog = {{epic_backlog}}</template-output>
|
||||||
|
<template-output>epic_in_progress = {{epic_in_progress}}</template-output>
|
||||||
|
<template-output>epic_done = {{epic_done}}</template-output>
|
||||||
|
<template-output>risks = {{risks}}</template-output>
|
||||||
|
<action>Return to caller</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
<!-- ========================= -->
|
||||||
|
<!-- Validate mode -->
|
||||||
|
<!-- ========================= -->
|
||||||
|
|
||||||
|
<step n="30" goal="Validate sprint-status file">
|
||||||
|
<action>Check that {sprint_status_file} exists</action>
|
||||||
|
<check if="missing">
|
||||||
|
<template-output>is_valid = false</template-output>
|
||||||
|
<template-output>error = "sprint-status.yaml missing"</template-output>
|
||||||
|
<template-output>suggestion = "Run sprint-planning to create it"</template-output>
|
||||||
|
<action>Return</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Read and parse {sprint_status_file}</action>
|
||||||
|
|
||||||
|
<action>Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location (last_updated is optional for backward compatibility)</action>
|
||||||
|
<check if="any required field missing">
|
||||||
|
<template-output>is_valid = false</template-output>
|
||||||
|
<template-output>error = "Missing required field(s): {{missing_fields}}"</template-output>
|
||||||
|
<template-output>suggestion = "Re-run sprint-planning or add missing fields manually"</template-output>
|
||||||
|
<action>Return</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Verify development_status section exists with at least one entry</action>
|
||||||
|
<check if="development_status missing or empty">
|
||||||
|
<template-output>is_valid = false</template-output>
|
||||||
|
<template-output>error = "development_status missing or empty"</template-output>
|
||||||
|
<template-output>suggestion = "Re-run sprint-planning or repair the file manually"</template-output>
|
||||||
|
<action>Return</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<action>Validate all status values against known valid statuses:</action>
|
||||||
|
|
||||||
|
- Stories: backlog, ready-for-dev, in-progress, review, done (legacy: drafted)
|
||||||
|
- Epics: backlog, in-progress, done (legacy: contexted)
|
||||||
|
- Retrospectives: optional, done
|
||||||
|
<check if="any invalid status found">
|
||||||
|
<template-output>is_valid = false</template-output>
|
||||||
|
<template-output>error = "Invalid status values: {{invalid_entries}}"</template-output>
|
||||||
|
<template-output>suggestion = "Fix invalid statuses in sprint-status.yaml"</template-output>
|
||||||
|
<action>Return</action>
|
||||||
|
</check>
|
||||||
|
|
||||||
|
<template-output>is_valid = true</template-output>
|
||||||
|
<template-output>message = "sprint-status.yaml valid: metadata complete, all statuses recognized"</template-output>
|
||||||
|
<action>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.</action>
|
||||||
|
</step>
|
||||||
|
|
||||||
|
</workflow>
|
||||||
|
|
|
||||||
|
|
@ -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 = ""
|
||||||
|
|
@ -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
|
|
||||||
|
|
||||||
<workflow>
|
|
||||||
|
|
||||||
<step n="0" goal="Determine execution mode">
|
|
||||||
<action>Set mode = {{mode}} if provided by caller; otherwise mode = "interactive"</action>
|
|
||||||
|
|
||||||
<check if="mode == data">
|
|
||||||
<action>Jump to Step 20</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="mode == validate">
|
|
||||||
<action>Jump to Step 30</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="mode == interactive">
|
|
||||||
<action>Continue to Step 1</action>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="1" goal="Locate sprint status file">
|
|
||||||
<action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
|
|
||||||
<action>Try {sprint_status_file}</action>
|
|
||||||
<check if="file not found">
|
|
||||||
<output>❌ sprint-status.yaml not found.
|
|
||||||
Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-status.</output>
|
|
||||||
<action>Exit workflow</action>
|
|
||||||
</check>
|
|
||||||
<action>Continue to Step 2</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="2" goal="Read and parse sprint-status.yaml">
|
|
||||||
<action>Read the FULL file: {sprint_status_file}</action>
|
|
||||||
<action>Parse fields: generated, last_updated, project, project_key, tracking_system, story_location</action>
|
|
||||||
<action>Parse development_status map. Classify keys:</action>
|
|
||||||
- Epics: keys starting with "epic-" (and not ending with "-retrospective")
|
|
||||||
- Retrospectives: keys ending with "-retrospective"
|
|
||||||
- Stories: everything else (e.g., 1-2-login-form)
|
|
||||||
<action>Map legacy story status "drafted" → "ready-for-dev"</action>
|
|
||||||
<action>Count story statuses: backlog, ready-for-dev, in-progress, review, done</action>
|
|
||||||
<action>Map legacy epic status "contexted" → "in-progress"</action>
|
|
||||||
<action>Count epic statuses: backlog, in-progress, done</action>
|
|
||||||
<action>Count retrospective statuses: optional, done</action>
|
|
||||||
|
|
||||||
<action>Validate all statuses against known values:</action>
|
|
||||||
|
|
||||||
- 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
|
|
||||||
|
|
||||||
<check if="any status is unrecognized">
|
|
||||||
<output>
|
|
||||||
⚠️ **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
|
|
||||||
</output>
|
|
||||||
<ask>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:</ask>
|
|
||||||
<check if="user provided corrections">
|
|
||||||
<action>Update sprint-status.yaml with corrected values</action>
|
|
||||||
<action>Re-parse the file with corrected statuses</action>
|
|
||||||
</check>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Detect risks:</action>
|
|
||||||
|
|
||||||
- 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"
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="3" goal="Select next action recommendation">
|
|
||||||
<action>Pick the next recommended workflow using priority:</action>
|
|
||||||
<note>When selecting "first" story: sort by epic number, then story number (e.g., 1-1 before 1-2 before 2-1)</note>
|
|
||||||
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!
|
|
||||||
<action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV)</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="4" goal="Display summary">
|
|
||||||
<output>
|
|
||||||
## 📊 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}}
|
|
||||||
|
|
||||||
</output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<step n="5" goal="Offer actions">
|
|
||||||
<ask>Pick an option:
|
|
||||||
1) Run recommended workflow now
|
|
||||||
2) Show all stories grouped by status
|
|
||||||
3) Show raw sprint-status.yaml
|
|
||||||
4) Exit
|
|
||||||
Choice:</ask>
|
|
||||||
|
|
||||||
<check if="choice == 1">
|
|
||||||
<output>Run `/bmad:bmm:workflows:{{next_workflow_id}}`.
|
|
||||||
If the command targets a story, set `story_key={{next_story_id}}` when prompted.</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="choice == 2">
|
|
||||||
<output>
|
|
||||||
### 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}}
|
|
||||||
</output>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="choice == 3">
|
|
||||||
<action>Display the full contents of {sprint_status_file}</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<check if="choice == 4">
|
|
||||||
<action>Exit workflow</action>
|
|
||||||
</check>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<!-- ========================= -->
|
|
||||||
<!-- Data mode for other flows -->
|
|
||||||
<!-- ========================= -->
|
|
||||||
|
|
||||||
<step n="20" goal="Data mode output">
|
|
||||||
<action>Load and parse {sprint_status_file} same as Step 2</action>
|
|
||||||
<action>Compute recommendation same as Step 3</action>
|
|
||||||
<template-output>next_workflow_id = {{next_workflow_id}}</template-output>
|
|
||||||
<template-output>next_story_id = {{next_story_id}}</template-output>
|
|
||||||
<template-output>count_backlog = {{count_backlog}}</template-output>
|
|
||||||
<template-output>count_ready = {{count_ready}}</template-output>
|
|
||||||
<template-output>count_in_progress = {{count_in_progress}}</template-output>
|
|
||||||
<template-output>count_review = {{count_review}}</template-output>
|
|
||||||
<template-output>count_done = {{count_done}}</template-output>
|
|
||||||
<template-output>epic_backlog = {{epic_backlog}}</template-output>
|
|
||||||
<template-output>epic_in_progress = {{epic_in_progress}}</template-output>
|
|
||||||
<template-output>epic_done = {{epic_done}}</template-output>
|
|
||||||
<template-output>risks = {{risks}}</template-output>
|
|
||||||
<action>Return to caller</action>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
<!-- ========================= -->
|
|
||||||
<!-- Validate mode -->
|
|
||||||
<!-- ========================= -->
|
|
||||||
|
|
||||||
<step n="30" goal="Validate sprint-status file">
|
|
||||||
<action>Check that {sprint_status_file} exists</action>
|
|
||||||
<check if="missing">
|
|
||||||
<template-output>is_valid = false</template-output>
|
|
||||||
<template-output>error = "sprint-status.yaml missing"</template-output>
|
|
||||||
<template-output>suggestion = "Run sprint-planning to create it"</template-output>
|
|
||||||
<action>Return</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Read and parse {sprint_status_file}</action>
|
|
||||||
|
|
||||||
<action>Validate required metadata fields exist: generated, project, project_key, tracking_system, story_location (last_updated is optional for backward compatibility)</action>
|
|
||||||
<check if="any required field missing">
|
|
||||||
<template-output>is_valid = false</template-output>
|
|
||||||
<template-output>error = "Missing required field(s): {{missing_fields}}"</template-output>
|
|
||||||
<template-output>suggestion = "Re-run sprint-planning or add missing fields manually"</template-output>
|
|
||||||
<action>Return</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Verify development_status section exists with at least one entry</action>
|
|
||||||
<check if="development_status missing or empty">
|
|
||||||
<template-output>is_valid = false</template-output>
|
|
||||||
<template-output>error = "development_status missing or empty"</template-output>
|
|
||||||
<template-output>suggestion = "Re-run sprint-planning or repair the file manually"</template-output>
|
|
||||||
<action>Return</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<action>Validate all status values against known valid statuses:</action>
|
|
||||||
|
|
||||||
- Stories: backlog, ready-for-dev, in-progress, review, done (legacy: drafted)
|
|
||||||
- Epics: backlog, in-progress, done (legacy: contexted)
|
|
||||||
- Retrospectives: optional, done
|
|
||||||
<check if="any invalid status found">
|
|
||||||
<template-output>is_valid = false</template-output>
|
|
||||||
<template-output>error = "Invalid status values: {{invalid_entries}}"</template-output>
|
|
||||||
<template-output>suggestion = "Fix invalid statuses in sprint-status.yaml"</template-output>
|
|
||||||
<action>Return</action>
|
|
||||||
</check>
|
|
||||||
|
|
||||||
<template-output>is_valid = true</template-output>
|
|
||||||
<template-output>message = "sprint-status.yaml valid: metadata complete, all statuses recognized"</template-output>
|
|
||||||
</step>
|
|
||||||
|
|
||||||
</workflow>
|
|
||||||
Loading…
Reference in New Issue