fix: Remove stale references to deprecated Phase 4 context workflows
- Remove all references to epic-tech-context, story-context, story-done, story-ready workflows - Remove contexted and drafted statuses from all files - Update status flow: backlog → ready-for-dev → in-progress → review → done - Update create-story template to output ready-for-dev status directly - Update sprint-planning to use simplified status detection - Update all documentation to reflect 5-workflow Phase 4 structure - Update agent definitions to reference story implementation documents - Fix typo in quick-flow-solo-dev.agent.yaml - Fix incorrect command reference (dev-spec → quick-dev) 23 files changed
This commit is contained in:
lihang
parent
3c81d78991
commit
12f4949313
|
|
@ -93,9 +93,9 @@ BMM automatically adjusts to project complexity (Levels 0-4):
|
|||
|
||||
### Story-Centric Implementation
|
||||
|
||||
Stories move through a defined lifecycle: `backlog → drafted → ready → in-progress → review → done`
|
||||
Stories move through a defined lifecycle: `backlog → ready-for-dev → in-progress → review → done`
|
||||
|
||||
Just-in-time epic context and story context provide exact expertise when needed.
|
||||
The create-story workflow provides comprehensive implementation context just-in-time when needed.
|
||||
|
||||
👉 **[Implementation Workflows](./docs/workflows-implementation.md)** - Complete story lifecycle guide
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ user_skill_level:
|
|||
label: "Expert - Deep technical knowledge, be direct and technical"
|
||||
|
||||
sprint_artifacts:
|
||||
prompt: "Where should Sprint Artifacts be stored (sprint status, stories, story context, temp context, etc...)?"
|
||||
prompt: "Where should Sprint Artifacts be stored (sprint status, story implementation documents, etc...)?"
|
||||
default: "{output_folder}/sprint-artifacts"
|
||||
result: "{project-root}/{value}"
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ agent:
|
|||
|
||||
persona:
|
||||
role: Senior Software Engineer
|
||||
identity: Executes approved stories with strict adherence to acceptance criteria, using Story Context XML and existing code to minimize rework and hallucinations.
|
||||
identity: Executes approved stories with strict adherence to acceptance criteria, using the story implementation document and existing code to minimize rework and hallucinations.
|
||||
communication_style: "Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision."
|
||||
principles: |
|
||||
- The Story File is the single source of truth - tasks/subtasks sequence is authoritative over any model priors
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ agent:
|
|||
- Planning and execution are two sides of the same coin. Quick Flow is my religion.
|
||||
- Specs are for building, not bureaucracy. Code that ships is better than perfect code that doesn't.
|
||||
- Documentation happens alongside development, not after. Ship early, ship often.
|
||||
- Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md ``
|
||||
- Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`
|
||||
|
||||
menu:
|
||||
- trigger: create-tech-spec
|
||||
|
|
|
|||
|
|
@ -30,11 +30,11 @@ agent:
|
|||
|
||||
- trigger: create-story
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/create-story/workflow.yaml"
|
||||
description: Create a Draft Story (Required to prepare stories for development)
|
||||
description: Create story implementation document with comprehensive context (Required before development)
|
||||
|
||||
- trigger: validate-create-story
|
||||
validate-workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/create-story/workflow.yaml"
|
||||
description: Validate Story Draft (Highly Recommended, use fresh context and different LLM for best results)
|
||||
description: Validate story document quality (Highly Recommended, use fresh context and different LLM for best results)
|
||||
|
||||
- trigger: epic-retrospective
|
||||
workflow: "{project-root}/{bmad_folder}/bmm/workflows/4-implementation/retrospective/workflow.yaml"
|
||||
|
|
|
|||
|
|
@ -170,11 +170,9 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
|
|||
**When to Use:**
|
||||
|
||||
- Sprint planning and tracking initialization
|
||||
- Creating user stories
|
||||
- Assembling dynamic story context
|
||||
- Epic-level technical context (optional)
|
||||
- Marking stories ready for development
|
||||
- Creating story implementation documents with comprehensive context
|
||||
- Sprint retrospectives
|
||||
- Course corrections when needed
|
||||
|
||||
**Primary Phase:** Phase 4 (Implementation)
|
||||
|
||||
|
|
@ -182,13 +180,8 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
|
|||
|
||||
- `workflow-status` - Check what to do next
|
||||
- `sprint-planning` - Initialize `sprint-status.yaml` tracking
|
||||
- `epic-tech-context` - Optional epic-specific technical context
|
||||
- `validate-epic-tech-context` - Validate epic technical context
|
||||
- `create-story` - Draft next story from epic
|
||||
- `create-story` - Create story implementation document with comprehensive context
|
||||
- `validate-create-story` - Independent story validation
|
||||
- `story-context` - Assemble dynamic technical context XML
|
||||
- `validate-story-context` - Validate story context
|
||||
- `story-ready-for-dev` - Mark story ready without context generation
|
||||
- `epic-retrospective` - Post-epic review
|
||||
- `correct-course` - Handle changes during implementation
|
||||
|
||||
|
|
@ -225,19 +218,19 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
|
|||
- Multi-run capability (initial + fixes)
|
||||
- Strict file boundary enforcement
|
||||
- `code-review` - Senior developer-level review with:
|
||||
- Story context awareness
|
||||
- Epic-tech-context alignment
|
||||
- Story implementation document awareness
|
||||
- Architecture alignment
|
||||
- Repository docs reference
|
||||
- MCP server best practices
|
||||
- Web search fallback
|
||||
- `story-done` - Mark story complete and advance queue
|
||||
- `code-review` - Review and mark story complete
|
||||
|
||||
**Communication Style:** Succinct and checklist-driven. Cites file paths and acceptance criteria IDs. Only asks questions when inputs are missing.
|
||||
|
||||
**Critical Principles:**
|
||||
|
||||
- Story Context XML is single source of truth
|
||||
- Never start until story Status == Approved
|
||||
- Story implementation document is single source of truth
|
||||
- Never start until story Status == ready-for-dev
|
||||
- All acceptance criteria must be satisfied
|
||||
- Tests must pass 100% before completion
|
||||
- No cheating or lying about test results
|
||||
|
|
@ -458,8 +451,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
|
|||
|
||||
- `workflow-status` - Check what to do next
|
||||
- `develop-story` - Execute Dev Story workflow, implementing tasks and tests
|
||||
- `story-done` - Mark story done after DoD complete
|
||||
- `code-review` - Perform thorough clean context QA code review on a story
|
||||
- `code-review` - Perform thorough clean context QA code review on a story (marks story done)
|
||||
|
||||
**Communication Style:** Direct and energetic. Execution-focused. Breaks down complex game challenges into actionable steps. Celebrates performance wins.
|
||||
|
||||
|
|
@ -649,15 +641,13 @@ Some workflows are available to multiple agents:
|
|||
|
||||
Many workflows have optional validation workflows that perform independent review:
|
||||
|
||||
| Validation | Agent | Validates |
|
||||
| ---------------------------- | ----------- | -------------------------------- |
|
||||
| `validate-prd` | PM | PRD completeness (FRs/NFRs only) |
|
||||
| `validate-tech-spec` | PM | Technical specification quality |
|
||||
| `validate-architecture` | Architect | Architecture document |
|
||||
| `validate-design` | UX Designer | UX specification and artifacts |
|
||||
| `validate-epic-tech-context` | SM | Epic technical context |
|
||||
| `validate-create-story` | SM | Story draft |
|
||||
| `validate-story-context` | SM | Story context XML |
|
||||
| Validation | Agent | Validates |
|
||||
| ----------------------- | ----------- | -------------------------------- |
|
||||
| `validate-prd` | PM | PRD completeness (FRs/NFRs only) |
|
||||
| `validate-tech-spec` | PM | Technical specification quality |
|
||||
| `validate-architecture` | Architect | Architecture document |
|
||||
| `validate-design` | UX Designer | UX specification and artifacts |
|
||||
| `validate-create-story` | SM | Story implementation document |
|
||||
|
||||
**When to use validation:**
|
||||
|
||||
|
|
@ -912,13 +902,10 @@ Load the customized agent and verify the changes are reflected in its behavior a
|
|||
**Story Development Cycle:**
|
||||
|
||||
```
|
||||
1. SM: *epic-tech-context (optional, once per epic)
|
||||
2. SM: *create-story
|
||||
3. SM: *story-context
|
||||
4. DEV: *develop-story
|
||||
5. DEV: *code-review
|
||||
6. DEV: *story-done
|
||||
7. Repeat steps 2-6 for next story
|
||||
1. SM: *create-story (creates detailed implementation document)
|
||||
2. DEV: *develop-story
|
||||
3. DEV: *code-review (marks story done)
|
||||
4. Repeat steps 1-3 for next story
|
||||
```
|
||||
|
||||
**Testing Strategy:**
|
||||
|
|
@ -991,13 +978,13 @@ Quick reference for agent selection:
|
|||
| **PM** | 📋 | 2 (Planning) | prd, tech-spec, epics-stories | Planning, requirements docs |
|
||||
| **UX Designer** | 🎨 | 2 (Planning) | create-ux-design, validate-design | UX-heavy projects, design |
|
||||
| **Architect** | 🏗️ | 3 (Solutioning) | architecture, implementation-readiness | Technical design, architecture |
|
||||
| **SM** | 🏃 | 4 (Implementation) | sprint-planning, create-story, story-context | Story management, sprint coordination |
|
||||
| **DEV** | 💻 | 4 (Implementation) | develop-story, code-review, story-done | Implementation, coding |
|
||||
| **SM** | 🏃 | 4 (Implementation) | sprint-planning, create-story | Story management, sprint coordination |
|
||||
| **DEV** | 💻 | 4 (Implementation) | develop-story, code-review | Implementation, coding |
|
||||
| **TEA** | 🧪 | All Phases | framework, atdd, automate, trace, ci | Testing, quality assurance |
|
||||
| **Paige (Tech Writer)** | 📚 | All Phases | document-project, diagrams, validation | Documentation, diagrams |
|
||||
| **Principal Engineer** | ⚡ | Quick Flow (All phases) | create-tech-spec, quick-dev, code-review | Rapid development, technical leadership |
|
||||
| **Game Designer** | 🎲 | 1-2 (Games) | brainstorm-game, gdd, narrative | Game design, creative vision |
|
||||
| **Game Developer** | 🕹️ | 4 (Games) | develop-story, story-done, code-review | Game implementation |
|
||||
| **Game Developer** | 🕹️ | 4 (Games) | develop-story, code-review | Game implementation |
|
||||
| **Game Architect** | 🏛️ | 3 (Games) | architecture, implementation-readiness | Game systems architecture |
|
||||
| **BMad Master** | 🧙 | Meta | party-mode, list tasks/workflows | Orchestration, multi-agent |
|
||||
|
||||
|
|
@ -1087,10 +1074,8 @@ Quick reference for agent selection:
|
|||
|
||||
- [ ] SM: `*sprint-planning` (once)
|
||||
- [ ] SM: `*create-story`
|
||||
- [ ] SM: `*story-context`
|
||||
- [ ] DEV: `*develop-story`
|
||||
- [ ] DEV: `*code-review`
|
||||
- [ ] DEV: `*story-done`
|
||||
- [ ] DEV: `*code-review` (marks story done)
|
||||
|
||||
**Testing Strategy:**
|
||||
|
||||
|
|
|
|||
|
|
@ -251,7 +251,7 @@ Without AI-optimized documentation, workflows fail:
|
|||
- **tech-spec** (Quick Flow) can't auto-detect stack/patterns → Makes wrong assumptions
|
||||
- **PRD** (BMad Method) can't reference existing code → Designs incompatible features
|
||||
- **architecture** can't build on existing structure → Suggests conflicting patterns
|
||||
- **story-context** can't inject existing patterns → Dev agent rewrites working code
|
||||
- **create-story** can't reference existing patterns → Dev agent rewrites working code
|
||||
- **dev-story** invents implementations → Breaks existing integrations
|
||||
|
||||
### Key Principle
|
||||
|
|
@ -320,9 +320,7 @@ See the [Workflows section in BMM README](../README.md) for details.
|
|||
```mermaid
|
||||
flowchart TD
|
||||
SPRINT[sprint-planning<br/>Initialize tracking]
|
||||
EPIC[epic-tech-context<br/>Per epic]
|
||||
CREATE[create-story]
|
||||
CONTEXT[story-context]
|
||||
CREATE[create-story<br/>Per story]
|
||||
DEV[dev-story]
|
||||
REVIEW[code-review]
|
||||
CHECK{More stories?}
|
||||
|
|
@ -343,15 +341,15 @@ flowchart TD
|
|||
|
||||
**Status Progression:**
|
||||
|
||||
- Epic: `backlog → contexted`
|
||||
- Story: `backlog → drafted → ready-for-dev → in-progress → review → done`
|
||||
- Epic: `backlog → in-progress → done`
|
||||
- Story: `backlog → ready-for-dev → in-progress → review → done`
|
||||
|
||||
**Brownfield-Specific Implementation Tips:**
|
||||
|
||||
1. **Respect existing patterns** - Follow established conventions
|
||||
2. **Test integration thoroughly** - Validate interactions with existing code
|
||||
3. **Use feature flags** - Enable gradual rollout
|
||||
4. **Context injection matters** - epic-tech-context and story-context reference existing patterns
|
||||
4. **Context injection matters** - create-story references existing patterns from documentation
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -375,7 +373,7 @@ When workflow-init asks about your work:
|
|||
|
||||
### 4. Respect Existing Patterns
|
||||
|
||||
Tech-spec and story-context will detect conventions. Follow them unless explicitly modernizing.
|
||||
Tech-spec and create-story will reference detected conventions. Follow them unless explicitly modernizing.
|
||||
|
||||
### 5. Plan Integration Points Explicitly
|
||||
|
||||
|
|
@ -407,9 +405,8 @@ Document in tech-spec/architecture:
|
|||
|
||||
### 9. Leverage Context Injection
|
||||
|
||||
- Run `epic-tech-context` before story drafting
|
||||
- Always create `story-context` before implementation
|
||||
- These reference existing patterns for consistency
|
||||
- Run `create-story` before implementation
|
||||
- The workflow references existing patterns from documentation for consistency
|
||||
|
||||
### 10. Learn Continuously
|
||||
|
||||
|
|
@ -457,7 +454,7 @@ Document in tech-spec/architecture:
|
|||
- Analyzes existing auth patterns
|
||||
- Confirms conventions
|
||||
- Creates tech-spec.md + epic + 3-5 stories
|
||||
3. **Implement:** Load SM → `sprint-planning` → `create-story` → `story-context`
|
||||
3. **Implement:** Load SM → `sprint-planning` → `create-story`
|
||||
Load DEV → `dev-story` for each story
|
||||
4. **Review:** Load DEV → `code-review`
|
||||
|
||||
|
|
@ -479,7 +476,7 @@ Document in tech-spec/architecture:
|
|||
4. **Solution:** Load Architect → `create-architecture` → `create-epics-and-stories` → `implementation-readiness`
|
||||
5. **Implement:** Sprint-based (10-15 stories)
|
||||
- Load SM → `sprint-planning`
|
||||
- Per epic: `epic-tech-context` → stories
|
||||
- Per story: `create-story` → `dev-story`
|
||||
- Load DEV → `dev-story` per story
|
||||
6. **Review:** Per story completion
|
||||
|
||||
|
|
@ -575,7 +572,7 @@ Document in tech-spec/architecture:
|
|||
**Solution:**
|
||||
|
||||
1. Ensure `document-project` captured existing architecture
|
||||
2. Check `story-context` - should document integration points
|
||||
2. Check story files - should document integration points
|
||||
3. In tech-spec/architecture - explicitly document:
|
||||
- Which existing modules to modify
|
||||
- What APIs/services to integrate with
|
||||
|
|
@ -608,7 +605,7 @@ Document in tech-spec/architecture:
|
|||
|
||||
1. Check convention detection (Quick Spec Flow should detect patterns)
|
||||
2. Review documentation - ensure `document-project` captured patterns
|
||||
3. Use `story-context` - injects pattern guidance
|
||||
3. Use `create-story` - injects pattern guidance
|
||||
4. Add to code-review checklist: pattern adherence, convention consistency
|
||||
5. Run retrospective to identify deviations early
|
||||
|
||||
|
|
@ -644,7 +641,7 @@ implementation-readiness # Final validation
|
|||
# Phase 4: Implementation (All Tracks)
|
||||
# SM agent:
|
||||
sprint-planning # Initialize tracking
|
||||
create-story # Create story
|
||||
create-story # Create story implementation document with comprehensive context
|
||||
|
||||
# DEV agent:
|
||||
dev-story # Implement
|
||||
|
|
@ -685,9 +682,7 @@ correct-course # If issues
|
|||
**Phase 4 Implementation:**
|
||||
|
||||
- `docs/sprint-status.yaml` - **Single source of truth**
|
||||
- `docs/epic-{n}-context.md`
|
||||
- `docs/stories/{epic}-{story}-{title}.md`
|
||||
- `docs/stories/{epic}-{story}-{title}-context.md`
|
||||
- `docs/stories/{epic}-{story}-{title}.md` - Story implementation documents
|
||||
|
||||
### Decision Flowchart
|
||||
|
||||
|
|
|
|||
|
|
@ -288,8 +288,8 @@ bmad ux *create-ux-design
|
|||
|
||||
**BMad ensures:**
|
||||
|
||||
- AI agents follow architectural patterns consistently (via story-context)
|
||||
- Code standards applied uniformly (via epic-tech-context)
|
||||
- AI agents follow architectural patterns consistently (via create-story)
|
||||
- Code standards applied uniformly (via comprehensive story documents)
|
||||
- PRD traceability throughout implementation (via acceptance criteria)
|
||||
- No "telephone game" between PM, design, and dev
|
||||
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ When in doubt, start smaller. You can always run create-prd later if needed.
|
|||
|
||||
### Q: Do I always need architecture for Level 2?
|
||||
|
||||
**A:** No, architecture is **optional** for Level 2. Only create architecture if you need system-level design. Many Level 2 projects work fine with just PRD + epic-tech-context created during implementation.
|
||||
**A:** No, architecture is **optional** for Level 2. Only create architecture if you need system-level design. Many Level 2 projects work fine with just PRD + epics.md created during planning.
|
||||
|
||||
### Q: What's the difference between Level 1 and Level 2?
|
||||
|
||||
|
|
@ -162,14 +162,14 @@ If status file exists, use workflow-status. If not, use workflow-init.
|
|||
|
||||
## Planning Documents
|
||||
|
||||
### Q: What's the difference between tech-spec and epic-tech-context?
|
||||
### Q: What's the difference between tech-spec and create-story?
|
||||
|
||||
**A:**
|
||||
|
||||
- **Tech-spec (Level 0-1):** Created upfront in Planning Phase, serves as primary/only planning document, a combination of enough technical and planning information to drive a single or multiple files
|
||||
- **Epic-tech-context (Level 2-4):** Created during Implementation Phase per epic, supplements PRD + Architecture
|
||||
- **Story implementation documents (Level 2-4):** Created during Implementation Phase via `create-story`, synthesizes PRD + Architecture + epics.md into comprehensive developer context
|
||||
|
||||
Think of it as: tech-spec is for small projects (replaces PRD and architecture), epic-tech-context is for large projects (supplements PRD).
|
||||
Think of it as: tech-spec is for small projects (replaces PRD and architecture), create-story is for large projects (creates detailed implementation documents from PRD + Architecture + epics.md).
|
||||
|
||||
### Q: Why no tech-spec at Level 2+?
|
||||
|
||||
|
|
@ -178,13 +178,13 @@ Think of it as: tech-spec is for small projects (replaces PRD and architecture),
|
|||
- PRD (product vision, functional requirements, non-functional requirements)
|
||||
- Architecture (system design)
|
||||
- Epics+Stories (created AFTER architecture is complete)
|
||||
- Epic-tech-context (detailed implementation per epic, created just-in-time)
|
||||
- Story implementation documents (detailed implementation per story, created just-in-time via create-story)
|
||||
|
||||
### Q: When do I create epic-tech-context?
|
||||
### Q: When do I create story implementation documents?
|
||||
|
||||
**A:** In Phase 4, right before implementing each epic. Don't create all epic-tech-context upfront - that's over-planning. Create them just-in-time using the epic-tech-context workflow as you're about to start working on that epic.
|
||||
**A:** In Phase 4, right before implementing each story. Don't create all story documents upfront - that's over-planning. Create them just-in-time using the create-story workflow as you're about to start working on that story.
|
||||
|
||||
**Why just-in-time?** You'll learn from earlier epics, and those learnings improve later epic-tech-context.
|
||||
**Why just-in-time?** You'll learn from earlier stories, and those learnings improve later story documents.
|
||||
|
||||
### Q: Do I need a PRD for a bug fix?
|
||||
|
||||
|
|
@ -209,47 +209,30 @@ PRDs are for Level 2-4 projects with multiple features requiring product-level c
|
|||
|
||||
## Implementation
|
||||
|
||||
### Q: Do I need story-context for every story?
|
||||
### Q: Does create-story include all context I need?
|
||||
|
||||
**A:** Technically no, but it's recommended. story-context provides implementation-specific guidance, references existing patterns, and injects expertise. Skip it only if:
|
||||
**A:** Yes! The create-story workflow generates comprehensive implementation documents that include:
|
||||
|
||||
- Very simple story (self-explanatory)
|
||||
- You're already expert in the area
|
||||
- Time is extremely limited
|
||||
- Story requirements from epics.md
|
||||
- Technical implementation guidance from Architecture
|
||||
- UX patterns from UX Design (if available)
|
||||
- Previous story learnings
|
||||
- Git intelligence for code patterns
|
||||
- Latest technical specifics
|
||||
|
||||
For Level 0-1 using tech-spec, story-context is less critical because tech-spec is already comprehensive.
|
||||
|
||||
### Q: What if I don't create epic-tech-context before drafting stories?
|
||||
|
||||
**A:** You can proceed without it, but you'll miss:
|
||||
|
||||
- Epic-level technical direction
|
||||
- Architecture guidance for this epic
|
||||
- Integration strategy with other epics
|
||||
- Common patterns to follow across stories
|
||||
|
||||
epic-tech-context helps ensure stories within an epic are cohesive.
|
||||
**Note:** Level 0-1 (Quick Flow) uses `tech-spec` + `quick-dev` workflow instead of create-story. The tech-spec serves as the primary context document for quick-dev.
|
||||
|
||||
### Q: How do I mark a story as done?
|
||||
|
||||
**A:** You have two options:
|
||||
**A:** Run the `code-review` workflow! When code review passes:
|
||||
|
||||
**Option 1: Use story-done workflow (Recommended)**
|
||||
|
||||
1. Load SM agent
|
||||
2. Run `story-done` workflow
|
||||
3. Workflow automatically updates `sprint-status.yaml` (created by sprint-planning at Phase 4 start)
|
||||
4. Moves story from current status → `DONE`
|
||||
5. Advances the story queue
|
||||
|
||||
**Option 2: Manual update**
|
||||
|
||||
1. After dev-story completes and code-review passes
|
||||
2. Open `sprint-status.yaml` (created by sprint-planning)
|
||||
3. Change the story status from `review` to `done`
|
||||
4. Save the file
|
||||
|
||||
The story-done workflow is faster and ensures proper status file updates.
|
||||
1. Load DEV agent
|
||||
2. Run `code-review` workflow
|
||||
3. Review implementation thoroughly
|
||||
4. If review passes, the workflow automatically:
|
||||
- Updates `sprint-status.yaml` to mark story as `done`
|
||||
- Advances the story queue
|
||||
5. If review fails, DEV fixes issues and runs code-review again
|
||||
|
||||
### Q: Can I work on multiple stories at once?
|
||||
|
||||
|
|
@ -271,7 +254,7 @@ The story-done workflow is faster and ensures proper status file updates.
|
|||
- What went well
|
||||
- What could improve
|
||||
- Technical insights
|
||||
- Input for next epic-tech-context
|
||||
- Input for next story implementation
|
||||
|
||||
Don't wait until project end - run after each epic for continuous improvement.
|
||||
|
||||
|
|
|
|||
|
|
@ -71,9 +71,9 @@ The methodology path (Quick Flow, BMad Method, or Enterprise Method) chosen for
|
|||
|
||||
### Epic-Tech-Context (Epic Technical Context)
|
||||
|
||||
**BMad Method/Enterprise tracks only.** Detailed technical planning document created during implementation (just-in-time) for each epic. Supplements PRD + Architecture with epic-specific implementation details, code-level design decisions, and integration points.
|
||||
**BMad Method/Enterprise tracks only.** Detailed technical planning document created during implementation (just-in-time) for each story via `create-story` workflow. Synthesizes PRD + Architecture + epics.md with story-specific implementation details, code-level design decisions, and integration points.
|
||||
|
||||
**Key Difference:** Tech-spec (Quick Flow) is created upfront and is the only planning doc. Epic-tech-context (BMad Method/Enterprise) is created per epic during implementation and supplements PRD + Architecture.
|
||||
**Key Difference:** Tech-spec (Quick Flow) is created upfront and is the only planning doc. Story implementation documents (BMad Method/Enterprise) are created per story during implementation via `create-story` and synthesize all project artifacts into comprehensive developer context.
|
||||
|
||||
### PRD (Product Requirements Document)
|
||||
|
||||
|
|
@ -127,11 +127,11 @@ Fast-track workflow system for Quick Flow track projects that goes straight from
|
|||
|
||||
### Just-In-Time Design
|
||||
|
||||
Pattern where epic-tech-context is created during implementation (Phase 4) right before working on each epic, rather than all upfront. Enables learning and adaptation.
|
||||
Pattern where detailed story context is created during implementation (Phase 4) right before working on each story, rather than all upfront. Enables learning and adaptation.
|
||||
|
||||
### Context Injection
|
||||
|
||||
Dynamic technical guidance generated for each story via epic-tech-context and story-context workflows, providing exact expertise when needed without upfront over-planning.
|
||||
Dynamic technical guidance generated for each story via the create-story workflow, providing exact expertise when needed without upfront over-planning.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ Agent that designs system architecture, creates architecture documents, performs
|
|||
|
||||
### SM (Scrum Master)
|
||||
|
||||
Agent that manages sprints, creates stories, generates contexts, and coordinates implementation. Primary orchestrator for Phase 4 implementation.
|
||||
Agent that manages sprints, creates story implementation documents with comprehensive context, and coordinates implementation. Primary orchestrator for Phase 4 implementation.
|
||||
|
||||
### DEV (Developer)
|
||||
|
||||
|
|
@ -196,12 +196,11 @@ Multi-agent collaboration feature where all installed agents (19+ from BMM, CIS,
|
|||
### Story Status Progression
|
||||
|
||||
```
|
||||
backlog → drafted → ready-for-dev → in-progress → review → done
|
||||
backlog → ready-for-dev → in-progress → review → done
|
||||
```
|
||||
|
||||
- **backlog** - Story exists in epic but not yet drafted
|
||||
- **drafted** - Story file created by SM via create-story
|
||||
- **ready-for-dev** - Story has context, ready for DEV via story-context
|
||||
- **backlog** - Story exists in epic but not yet started
|
||||
- **ready-for-dev** - Story file created by SM via create-story with comprehensive context
|
||||
- **in-progress** - DEV is implementing via dev-story
|
||||
- **review** - Implementation complete, awaiting code-review
|
||||
- **done** - Completed with DoD met
|
||||
|
|
@ -209,11 +208,11 @@ backlog → drafted → ready-for-dev → in-progress → review → done
|
|||
### Epic Status Progression
|
||||
|
||||
```
|
||||
backlog → contexted
|
||||
backlog → in-progress → done
|
||||
```
|
||||
|
||||
- **backlog** - Epic exists in planning docs but no context yet
|
||||
- **contexted** - Epic has technical context via epic-tech-context
|
||||
- **backlog** - Epic exists in planning docs but not started
|
||||
- **in-progress** - Epic has at least one story in progress
|
||||
|
||||
### Retrospective
|
||||
|
||||
|
|
@ -251,11 +250,11 @@ Markdown file containing story details: description, acceptance criteria, techni
|
|||
|
||||
### Story Context
|
||||
|
||||
Technical guidance document created via story-context workflow that provides implementation-specific context, references existing patterns, suggests approaches, and injects expertise for the specific story.
|
||||
Technical guidance is now integrated directly into the story implementation document created via create-story workflow. This provides implementation-specific context, references existing patterns, suggests approaches, and injects expertise for the specific story.
|
||||
|
||||
### Epic Context
|
||||
### Story Implementation Document
|
||||
|
||||
Technical planning document created via epic-tech-context workflow before drafting stories within an epic. Provides epic-level technical direction, architecture notes, and implementation strategy.
|
||||
Comprehensive implementation guide created via the create-story workflow for each story. Contains story requirements, technical implementation guidance, architecture compliance notes, and developer context.
|
||||
|
||||
### Sprint Planning
|
||||
|
||||
|
|
|
|||
|
|
@ -200,35 +200,21 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
|
|||
3. Tell the agent: "Run sprint-planning"
|
||||
4. This creates your `sprint-status.yaml` file that tracks all epics and stories
|
||||
|
||||
#### 3.2 Create Epic Context (Optional but Recommended)
|
||||
|
||||
1. **Start a new chat** with the **SM agent**
|
||||
2. Wait for the menu
|
||||
3. Tell the agent: "Run epic-tech-context"
|
||||
4. This creates technical context for the current epic before drafting stories
|
||||
|
||||
#### 3.3 Draft Your First Story
|
||||
#### 3.2 Create Your First Story
|
||||
|
||||
1. **Start a new chat** with the **SM agent**
|
||||
2. Wait for the menu
|
||||
3. Tell the agent: "Run create-story"
|
||||
4. This drafts the story file from the epic
|
||||
4. This creates the story implementation document with comprehensive context from the epic
|
||||
|
||||
#### 3.4 Add Story Context (Optional but Recommended)
|
||||
|
||||
1. **Start a new chat** with the **SM agent**
|
||||
2. Wait for the menu
|
||||
3. Tell the agent: "Run story-context"
|
||||
4. This creates implementation-specific technical context for the story
|
||||
|
||||
#### 3.5 Implement the Story
|
||||
#### 3.3 Implement the Story
|
||||
|
||||
1. **Start a new chat** with the **DEV agent**
|
||||
2. Wait for the menu
|
||||
3. Tell the agent: "Run dev-story"
|
||||
4. The DEV agent will implement the story and update the sprint status
|
||||
|
||||
#### 3.6 Review the Code (Optional but Recommended)
|
||||
#### 3.4 Review the Code (Recommended)
|
||||
|
||||
1. **Start a new chat** with the **DEV agent**
|
||||
2. Wait for the menu
|
||||
|
|
@ -240,9 +226,8 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
|
|||
For each subsequent story, repeat the cycle using **fresh chats** for each workflow:
|
||||
|
||||
1. **New chat** → SM agent → "Run create-story"
|
||||
2. **New chat** → SM agent → "Run story-context"
|
||||
3. **New chat** → DEV agent → "Run dev-story"
|
||||
4. **New chat** → DEV agent → "Run code-review" (optional but recommended)
|
||||
2. **New chat** → DEV agent → "Run dev-story"
|
||||
3. **New chat** → DEV agent → "Run code-review" (marks story done)
|
||||
|
||||
After completing all stories in an epic:
|
||||
|
||||
|
|
@ -326,13 +311,12 @@ flowchart LR
|
|||
|
||||
subgraph P4["Phase 4 (Required)<br/>Implementation"]
|
||||
direction TB
|
||||
D1[Per Epic:<br/>epic context]
|
||||
D1[sprint-planning]
|
||||
D2[Per Story:<br/>create-story]
|
||||
D3[story-context]
|
||||
D4[dev-story]
|
||||
D5[code-review]
|
||||
D6[SM, DEV]
|
||||
D1 ~~~ D2 ~~~ D3 ~~~ D4 ~~~ D5 ~~~ D6
|
||||
D3[dev-story]
|
||||
D4[code-review]
|
||||
D5[SM, DEV]
|
||||
D1 ~~~ D2 ~~~ D3 ~~~ D4 ~~~ D5
|
||||
end
|
||||
|
||||
P1 --> P2
|
||||
|
|
|
|||
|
|
@ -27,14 +27,16 @@ For a visual representation of the complete workflow, see: [workflow-method-gree
|
|||
|
||||
## Quick Reference
|
||||
|
||||
| Workflow | Agent | When | Purpose |
|
||||
| ------------------- | ----- | --------------------- | ------------------------------------- |
|
||||
| **sprint-planning** | SM | Once at Phase 4 start | Initialize sprint tracking file |
|
||||
| **create-story** | SM | Per story | Create next story from epic backlog |
|
||||
| **dev-story** | DEV | Per story | Implement story with tests |
|
||||
| **code-review** | DEV | Per story | Senior dev quality review |
|
||||
| **retrospective** | SM | After epic complete | Review lessons and extract insights |
|
||||
| **correct-course** | SM | When issues arise | Handle significant mid-sprint changes |
|
||||
| Workflow | Agent | When | Purpose |
|
||||
| ------------------------- | ----- | --------------------------- | --------------------------------------------------------------- |
|
||||
| **sprint-planning** | SM | Once at Phase 4 start | Initialize sprint tracking file |
|
||||
| **create-story** | SM | Per story | Create story implementation document with comprehensive context |
|
||||
| **validate-create-story** | SM | Optional after create-story | Validate story document quality |
|
||||
| **develop-story** | DEV | Per story | Implement story with tests |
|
||||
| **code-review** | DEV | Per story | Senior dev quality review and mark done |
|
||||
| **epic-retrospective** | SM | After epic complete | Review lessons and extract insights |
|
||||
| **correct-course** | SM | When issues arise | Handle significant mid-sprint changes |
|
||||
| **workflow-status** | Any | Anytime | Check "what should I do now?" |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -42,24 +44,25 @@ For a visual representation of the complete workflow, see: [workflow-method-gree
|
|||
|
||||
### SM (Scrum Master) - Primary Implementation Orchestrator
|
||||
|
||||
**Workflows:** sprint-planning, create-story, retrospective, correct-course
|
||||
**Workflows:** sprint-planning, create-story, validate-create-story, epic-retrospective, correct-course
|
||||
|
||||
**Responsibilities:**
|
||||
|
||||
- Initialize and maintain sprint tracking
|
||||
- Create stories from epic backlog
|
||||
- Handle course corrections when issues arise
|
||||
- Facilitate retrospectives after epic completion
|
||||
- Orchestrate overall implementation flow
|
||||
- Create story implementation documents with comprehensive context
|
||||
- Orchestrate story lifecycle with optional validations
|
||||
- Handle course corrections
|
||||
- Facilitate retrospectives
|
||||
|
||||
### DEV (Developer) - Implementation and Quality
|
||||
|
||||
**Workflows:** dev-story, code-review
|
||||
**Workflows:** develop-story, code-review
|
||||
|
||||
**Responsibilities:**
|
||||
|
||||
- Implement stories with tests
|
||||
- Perform senior developer code reviews
|
||||
- Mark stories complete and advance queue when review passes
|
||||
- Ensure quality and adherence to standards
|
||||
- Complete story implementation lifecycle
|
||||
|
||||
|
|
@ -69,10 +72,11 @@ For a visual representation of the complete workflow, see: [workflow-method-gree
|
|||
|
||||
Stories move through these states in the sprint status file:
|
||||
|
||||
1. **TODO** - Story identified but not started
|
||||
2. **IN PROGRESS** - Story being implemented (create-story → story-context → dev-story)
|
||||
3. **READY FOR REVIEW** - Implementation complete, awaiting code review
|
||||
4. **DONE** - Accepted and complete
|
||||
1. **backlog** - Story exists in epics.md but not yet started
|
||||
2. **ready-for-dev** - Story file created by create-story with comprehensive context
|
||||
3. **in-progress** - Developer actively working on implementation
|
||||
4. **review** - Implementation complete, awaiting code review
|
||||
5. **done** - Story completed and reviewed
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -90,21 +94,19 @@ Stories move through these states in the sprint status file:
|
|||
|
||||
1. SM runs `sprint-planning` (once)
|
||||
|
||||
**Per Epic:**
|
||||
|
||||
- Epic context and stories are already prepared from Phase 3
|
||||
|
||||
**Per Story (repeat until epic complete):**
|
||||
|
||||
1. SM runs `create-story`
|
||||
2. DEV runs `dev-story`
|
||||
3. DEV runs `code-review`
|
||||
4. If code review fails: DEV fixes issues in `dev-story`, then re-runs `code-review`
|
||||
1. SM runs `create-story` (creates comprehensive story implementation document)
|
||||
2. SM optionally runs `validate-create-story`
|
||||
3. DEV runs `develop-story`
|
||||
4. DEV runs `code-review`
|
||||
5. If code review passes: Story automatically marked as `done` in sprint status
|
||||
6. If code review finds issues: DEV fixes in `develop-story`, then back to code-review
|
||||
|
||||
**After Epic Complete:**
|
||||
|
||||
- SM runs `retrospective`
|
||||
- Move to next epic
|
||||
- SM runs `epic-retrospective`
|
||||
- Move to next epic (start with `create-story` for first story)
|
||||
|
||||
**As Needed:**
|
||||
|
||||
|
|
@ -119,6 +121,19 @@ Stories move through these states in the sprint status file:
|
|||
|
||||
Complete each story's full lifecycle before starting the next. This prevents context switching and ensures quality.
|
||||
|
||||
### Comprehensive Story Context
|
||||
|
||||
The `create-story` workflow generates comprehensive story implementation documents that include all necessary context:
|
||||
|
||||
- Story requirements from epics.md
|
||||
- Technical implementation guidance from Architecture
|
||||
- UX patterns from UX Design (if available)
|
||||
- Previous story learnings
|
||||
- Git intelligence for code patterns
|
||||
- Latest technical specifics
|
||||
|
||||
This provides just-in-time comprehensive context without upfront over-planning.
|
||||
|
||||
### Quality Gates
|
||||
|
||||
Every story goes through `code-review` before being marked done. No exceptions.
|
||||
|
|
@ -136,9 +151,10 @@ PRD (PM) → Architecture (Architect)
|
|||
→ create-epics-and-stories (PM) ← V6: After architecture!
|
||||
→ implementation-readiness (Architect)
|
||||
→ sprint-planning (SM, once)
|
||||
→ [Per Epic]:
|
||||
→ story loop (SM/DEV)
|
||||
→ retrospective (SM)
|
||||
→ [Per Story]:
|
||||
create-story (SM) → develop-story (DEV) → code-review (DEV)
|
||||
→ [After Epic Complete]:
|
||||
epic-retrospective (SM)
|
||||
→ [Next Epic]
|
||||
```
|
||||
|
||||
|
|
@ -164,7 +180,10 @@ A: Run `correct-course` to analyze impact and route appropriately.
|
|||
A: Not recommended. Complete one story's full lifecycle before starting the next. Prevents context switching and ensures quality.
|
||||
|
||||
**Q: What if code review finds issues?**
|
||||
A: DEV runs `dev-story` to make fixes, re-runs tests, then runs `code-review` again until it passes.
|
||||
A: DEV runs `develop-story` to make fixes, re-runs tests, then runs `code-review` again until it passes.
|
||||
|
||||
**Q: When do I run validations?**
|
||||
A: Validations are optional quality gates. Use `validate-create-story` when you want independent review of story implementation documents before proceeding with development.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -424,13 +424,13 @@ Architecture documents are living. Update them as you learn during implementatio
|
|||
|
||||
- **Planning:** prd (PM) - creates FRs/NFRs only, NOT epics
|
||||
- **Solutioning:** Optional UX → architecture (Architect) → create-epics-and-stories (PM) → implementation-readiness (Architect)
|
||||
- **Implementation:** sprint-planning → epic-tech-context → dev-story
|
||||
- **Implementation:** sprint-planning → create-story → dev-story
|
||||
|
||||
### Enterprise
|
||||
|
||||
- **Planning:** prd (PM) - creates FRs/NFRs only (same as BMad Method)
|
||||
- **Solutioning:** Optional UX → architecture (Architect) → Optional extended workflows (security-architecture, devops-strategy) → create-epics-and-stories (PM) → implementation-readiness (Architect)
|
||||
- **Implementation:** sprint-planning → epic-tech-context → dev-story
|
||||
- **Implementation:** sprint-planning → create-story → dev-story
|
||||
|
||||
**Key Difference:** Enterprise adds optional extended workflows AFTER architecture but BEFORE create-epics-and-stories. Everything else is identical to BMad Method.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
name,displayName,title,icon,role,identity,communicationStyle,principles,module,path
|
||||
"analyst","Mary","Business Analyst","📊","Strategic Business Analyst + Requirements Expert","Senior analyst with deep expertise in market research, competitive analysis, and requirements elicitation. Specializes in translating vague needs into actionable specs.","Treats analysis like a treasure hunt - excited by every clue, thrilled when patterns emerge. Asks questions that spark 'aha!' moments while structuring insights with precision.","Every business challenge has root causes waiting to be discovered. Ground findings in verifiable evidence. Articulate requirements with absolute precision.","bmm","bmad/bmm/agents/analyst.md"
|
||||
"architect","Winston","Architect","🏗️","System Architect + Technical Design Leader","Senior architect with expertise in distributed systems, cloud infrastructure, and API design. Specializes in scalable patterns and technology selection.","Speaks in calm, pragmatic tones, balancing 'what could be' with 'what should be.' Champions boring technology that actually works.","User journeys drive technical decisions. Embrace boring technology for stability. Design simple solutions that scale when needed. Developer productivity is architecture.","bmm","bmad/bmm/agents/architect.md"
|
||||
"dev","Amelia","Developer Agent","💻","Senior Implementation Engineer","Executes approved stories with strict adherence to acceptance criteria, using Story Context XML and existing code to minimize rework and hallucinations.","Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision.","Story Context XML is the single source of truth. Reuse existing interfaces over rebuilding. Every change maps to specific AC. Tests pass 100% or story isn't done.","bmm","bmad/bmm/agents/dev.md"
|
||||
"dev","Amelia","Developer Agent","💻","Senior Implementation Engineer","Executes approved stories with strict adherence to acceptance criteria, using the story implementation document and existing code to minimize rework and hallucinations.","Ultra-succinct. Speaks in file paths and AC IDs - every statement citable. No fluff, all precision.","Story implementation document is the single source of truth. Reuse existing interfaces over rebuilding. Every change maps to specific AC. Tests pass 100% or story isn't done.","bmm","bmad/bmm/agents/dev.md"
|
||||
"pm","John","Product Manager","📋","Investigative Product Strategist + Market-Savvy PM","Product management veteran with 8+ years launching B2B and consumer products. Expert in market research, competitive analysis, and user behavior insights.","Asks 'WHY?' relentlessly like a detective on a case. Direct and data-sharp, cuts through fluff to what actually matters.","Uncover the deeper WHY behind every requirement. Ruthless prioritization to achieve MVP goals. Proactively identify risks. Align efforts with measurable business impact.","bmm","bmad/bmm/agents/pm.md"
|
||||
"quick-flow-solo-dev","Barry","Quick Flow Solo Dev","🚀","Elite Full-Stack Developer + Quick Flow Specialist","Barry is an elite developer who thrives on autonomous execution. He lives and breathes the BMAD Quick Flow workflow, taking projects from concept to deployment with ruthless efficiency. No handoffs, no delays - just pure, focused development. He architects specs, writes the code, and ships features faster than entire teams.","Direct, confident, and implementation-focused. Uses tech slang and gets straight to the point. No fluff, just results. Every response moves the project forward.","Planning and execution are two sides of the same coin. Quick Flow is my religion. Specs are for building, not bureaucracy. Code that ships is better than perfect code that doesn't. Documentation happens alongside development, not after. Ship early, ship often.","bmm","bmad/bmm/agents/quick-flow-solo-dev.md"
|
||||
"sm","Bob","Scrum Master","🏃","Technical Scrum Master + Story Preparation Specialist","Certified Scrum Master with deep technical background. Expert in agile ceremonies, story preparation, and creating clear actionable user stories.","Crisp and checklist-driven. Every word has a purpose, every requirement crystal clear. Zero tolerance for ambiguity.","Strict boundaries between story prep and implementation. Stories are single source of truth. Perfect alignment between PRD and dev execution. Enable efficient sprints.","bmm","bmad/bmm/agents/sm.md"
|
||||
|
|
|
|||
|
|
|
@ -72,7 +72,7 @@
|
|||
<check if="no backlog story found">
|
||||
<output>📋 No backlog stories found in sprint-status.yaml
|
||||
|
||||
All stories are either already drafted, in progress, or done.
|
||||
All stories are either already ready-for-dev, in progress, or done.
|
||||
|
||||
**Options:**
|
||||
1. Run sprint-planning to refresh story tracking
|
||||
|
|
@ -95,7 +95,7 @@
|
|||
<check if="this is first story in epic {{epic_num}}">
|
||||
<action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
|
||||
<action>If epic status is "backlog" → update to "in-progress"</action>
|
||||
<action>If epic status is "contexted" → this means same as "in-progress", no change needed</action>
|
||||
<action>If epic status is already "in-progress" → no change needed</action>
|
||||
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
|
||||
</check>
|
||||
|
||||
|
|
@ -114,7 +114,7 @@
|
|||
<check if="no backlog story found">
|
||||
<output>📋 No backlog stories found in sprint-status.yaml
|
||||
|
||||
All stories are either already drafted, in progress, or done.
|
||||
All stories are either already ready-for-dev, in progress, or done.
|
||||
|
||||
**Options:**
|
||||
1. Run sprint-planning to refresh story tracking
|
||||
|
|
@ -137,7 +137,7 @@
|
|||
<check if="this is first story in epic {{epic_num}}">
|
||||
<action>Load {{sprint_status}} and check epic-{{epic_num}} status</action>
|
||||
<action>If epic status is "backlog" → update to "in-progress"</action>
|
||||
<action>If epic status is "contexted" → this means same as "in-progress", no change needed</action>
|
||||
<action>If epic status is already "in-progress" → no change needed</action>
|
||||
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
|
||||
</check>
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Story {{epic_num}}.{{story_num}}: {{story_title}}
|
||||
|
||||
Status: drafted
|
||||
Status: ready-for-dev
|
||||
|
||||
## Story
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ so that {{benefit}}.
|
|||
|
||||
### Context Reference
|
||||
|
||||
<!-- Path(s) to story context XML will be added here by context workflow -->
|
||||
<!-- All context is now integrated directly in Dev Notes section above -->
|
||||
|
||||
### Agent Model Used
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@
|
|||
|
||||
**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 drafted stories before development
|
||||
2. Run `*validate-create-story` to improve existing ready-for-dev stories before development
|
||||
3. Specify a particular story file to develop (provide full path)
|
||||
4. Check {{sprint_status}} file to see current sprint status
|
||||
</output>
|
||||
|
|
@ -85,7 +85,7 @@
|
|||
|
||||
**Available Options:**
|
||||
1. Run `create-story` to create next story from epics with comprehensive context
|
||||
2. Run `*validate-create-story` to improve existing drafted stories
|
||||
2. Run `*validate-create-story` to improve existing ready-for-dev stories
|
||||
3. Specify which story to develop
|
||||
</output>
|
||||
<ask>What would you like to do? Choose option [1], [2], or [3]:</ask>
|
||||
|
|
|
|||
|
|
@ -1395,10 +1395,10 @@ Retrospective document was saved successfully, but {sprint_status_file} may need
|
|||
- Do NOT start Epic {{next_epic_num}} until review is complete
|
||||
{{else}}
|
||||
|
||||
4. **Begin Epic {{next_epic_num}} planning when preparation complete**
|
||||
- Load PM agent and run `epic-tech-context` for Epic {{next_epic_num}}
|
||||
- Or continue with existing contexted epics
|
||||
4. **Begin Epic {{next_epic_num}} implementation when preparation complete**
|
||||
- Run `create-story` to create the first story for Epic {{next_epic_num}}
|
||||
- Ensure all critical path items are done first
|
||||
- Review epics.md for Epic {{next_epic_num}} requirements before starting
|
||||
{{/if}}
|
||||
|
||||
**Team Performance:**
|
||||
|
|
|
|||
|
|
@ -22,12 +22,17 @@
|
|||
|
||||
<workflow>
|
||||
|
||||
<step n="1" goal="Parse epic files and extract all work items">
|
||||
<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>
|
||||
<step n="0.5" goal="Discover and load project documents">
|
||||
<action>Communicate in {communication_language} with {user_name}</action>
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {epics_content} (all epics loaded - uses FULL_LOAD strategy)</note>
|
||||
</step>
|
||||
|
||||
<action>For each epic file found, extract:</action>
|
||||
<step n="1" goal="Parse epic files and extract all work items">
|
||||
<action>Parse {epics_content} to extract all epics and stories</action>
|
||||
<action>Epic files could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files</action>
|
||||
|
||||
<action>For each epic found in {epics_content}, extract:</action>
|
||||
|
||||
- Epic numbers from headers like `## Epic 1:` or `## Epic 2:`
|
||||
- Story IDs and titles from patterns like `### Story 1.1: User Authentication`
|
||||
|
|
@ -40,14 +45,9 @@
|
|||
- 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>
|
||||
<action>Build complete inventory of all epics and stories from {epics_content}</action>
|
||||
</step>
|
||||
|
||||
<step n="0.5" goal="Discover and load project documents">
|
||||
<invoke-protocol name="discover_inputs" />
|
||||
<note>After discovery, these content variables are available: {epics_content} (all epics loaded - uses FULL_LOAD strategy)</note>
|
||||
</step>
|
||||
|
||||
<step n="2" goal="Build sprint status structure">
|
||||
<action>For each epic found, create entries in this order:</action>
|
||||
|
||||
|
|
@ -68,33 +68,35 @@ development_status:
|
|||
</step>
|
||||
|
||||
<step n="3" goal="Apply intelligent status detection">
|
||||
<action>For each epic, check if tech context file exists:</action>
|
||||
<action>For each epic, check current status:</action>
|
||||
|
||||
- Check: `{output_folder}/epic-{num}-context.md`
|
||||
- If exists → set epic status to `contexted`
|
||||
- Else → keep as `backlog`
|
||||
- If existing `{status_file}` exists and epic has status → preserve existing status
|
||||
- Else → set epic status to `backlog` (default)
|
||||
|
||||
<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 `drafted`
|
||||
|
||||
**Story context detection:**
|
||||
|
||||
- Check: `{story_location_absolute}/{story-key}-context.md` (e.g., `stories/1-1-user-authentication-context.md`)
|
||||
- If exists → upgrade status to at least `ready-for-dev`
|
||||
- If file exists:
|
||||
- Read story file to check Status field
|
||||
- Map Status field to sprint status:
|
||||
- "ready-for-dev" → `ready-for-dev`
|
||||
- "in-progress" → `in-progress`
|
||||
- "review" → `review`
|
||||
- "done" → `done`
|
||||
- Any other value → `ready-for-dev` (default for existing files)
|
||||
- If file doesn't exist → keep as `backlog`
|
||||
|
||||
**Preservation rule:**
|
||||
|
||||
- If existing `{status_file}` exists and has more advanced status, preserve it
|
||||
- Never downgrade status (e.g., don't change `done` to `drafted`)
|
||||
- Never downgrade status (e.g., don't change `done` to `ready-for-dev`)
|
||||
|
||||
**Status Flow Reference:**
|
||||
|
||||
- Epic: `backlog` → `contexted`
|
||||
- Story: `backlog` → `drafted` → `ready-for-dev` → `in-progress` → `review` → `done`
|
||||
- Epic: `backlog` → `in-progress` → `done`
|
||||
- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done`
|
||||
- Retrospective: `optional` ↔ `completed`
|
||||
</step>
|
||||
|
||||
|
|
@ -113,27 +115,27 @@ development_status:
|
|||
# STATUS DEFINITIONS:
|
||||
# ==================
|
||||
# Epic Status:
|
||||
# - backlog: Epic exists in epic file but not contexted
|
||||
# - contexted: Epic tech context created (required before drafting stories)
|
||||
# - backlog: Epic exists in epic file but not started
|
||||
# - in-progress: Epic has at least one story in progress
|
||||
# - done: All stories in epic are completed
|
||||
#
|
||||
# Story Status:
|
||||
# - backlog: Story only exists in epic file
|
||||
# - drafted: Story file created in stories folder
|
||||
# - ready-for-dev: Draft approved and story context created
|
||||
# - in-progress: Developer actively working on implementation
|
||||
# - review: Under SM review (via code-review workflow)
|
||||
# - done: Story completed
|
||||
# - ready-for-dev: Story file created by create-story workflow with comprehensive context (Status: ready-for-dev)
|
||||
# - in-progress: Developer actively working on implementation (dev-story workflow)
|
||||
# - review: Implementation complete, ready for review (code-review workflow)
|
||||
# - done: Story completed and reviewed
|
||||
#
|
||||
# Retrospective Status:
|
||||
# - optional: Can be completed but not required
|
||||
# - completed: Retrospective has been done
|
||||
# - completed: Retrospective has been done (retrospective workflow)
|
||||
#
|
||||
# WORKFLOW NOTES:
|
||||
# ===============
|
||||
# - Epics should be 'contexted' before stories can be 'drafted'
|
||||
# - Run create-story to create detailed story implementation documents
|
||||
# - Stories can be worked in parallel if team capacity allows
|
||||
# - SM typically drafts next story after previous one is 'done' to incorporate learnings
|
||||
# - Dev moves story to 'review', SM reviews, then Dev moves to 'done'
|
||||
# - Create next story after previous one is 'done' to incorporate learnings
|
||||
# - Dev moves story to 'review' when complete, code-review marks as 'done'
|
||||
|
||||
generated: { date }
|
||||
project: { project_name }
|
||||
|
|
@ -164,7 +166,7 @@ development_status:
|
|||
|
||||
- Total epics: {{epic_count}}
|
||||
- Total stories: {{story_count}}
|
||||
- Epics contexted: {{contexted_count}}
|
||||
- Epics in progress: {{in_progress_epic_count}}
|
||||
- Stories in progress: {{in_progress_count}}
|
||||
- Stories done: {{done_count}}
|
||||
|
||||
|
|
@ -175,16 +177,37 @@ development_status:
|
|||
- **File Location:** {status_file}
|
||||
- **Total Epics:** {{epic_count}}
|
||||
- **Total Stories:** {{story_count}}
|
||||
- **Contexted Epics:** {{contexted_count}}
|
||||
- **Epics In Progress:** {{in_progress_epic_count}}
|
||||
- **Stories 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
|
||||
1. **Review the generated {status_file}** - Verify all epics and stories are correctly listed
|
||||
|
||||
2. **Create your first story** (if not already created):
|
||||
|
||||
```
|
||||
workflow create-story
|
||||
```
|
||||
|
||||
This will automatically select the next backlog story and create a detailed implementation document
|
||||
|
||||
3. **Begin development**:
|
||||
|
||||
```
|
||||
workflow dev-story
|
||||
```
|
||||
|
||||
Use the dev agent to implement the story following the detailed plan
|
||||
|
||||
4. **Workflow sequence for each story:**
|
||||
- `create-story` → creates detailed story document
|
||||
- `dev-story` → implements the story
|
||||
- `code-review` → reviews and marks as done
|
||||
- (repeat for next story)
|
||||
|
||||
**Note:** Re-run `sprint-planning` anytime to refresh auto-detected statuses from existing story files
|
||||
|
||||
</step>
|
||||
|
||||
|
|
@ -197,24 +220,24 @@ development_status:
|
|||
**Epic Status Flow:**
|
||||
|
||||
```
|
||||
backlog → contexted
|
||||
backlog → in-progress → done
|
||||
```
|
||||
|
||||
- **backlog**: Epic exists in epic file but tech context not created
|
||||
- **contexted**: Epic tech context has been generated (prerequisite for story drafting)
|
||||
- **backlog**: Epic exists in epic file but not started
|
||||
- **in-progress**: Epic has at least one story in progress
|
||||
- **done**: All stories in epic are completed
|
||||
|
||||
**Story Status Flow:**
|
||||
|
||||
```
|
||||
backlog → drafted → ready-for-dev → in-progress → review → done
|
||||
backlog → ready-for-dev → in-progress → review → done
|
||||
```
|
||||
|
||||
- **backlog**: Story only exists in epic file
|
||||
- **drafted**: Story file created (e.g., `stories/1-3-plant-naming.md`)
|
||||
- **ready-for-dev**: Draft approved + story context created
|
||||
- **in-progress**: Developer actively working
|
||||
- **review**: Under SM review (via code-review workflow)
|
||||
- **done**: Completed
|
||||
- **ready-for-dev**: Story file created by create-story workflow with comprehensive context (Status: ready-for-dev)
|
||||
- **in-progress**: Developer actively working (dev-story workflow)
|
||||
- **review**: Implementation complete, ready for review (code-review workflow)
|
||||
- **done**: Story completed and reviewed
|
||||
|
||||
**Retrospective Status:**
|
||||
|
||||
|
|
@ -227,8 +250,8 @@ optional ↔ completed
|
|||
|
||||
### Guidelines
|
||||
|
||||
1. **Epic Context Recommended**: Epics should be `contexted` before stories can be `drafted`
|
||||
1. **Story Creation**: Run `create-story` workflow to create detailed implementation documents for backlog stories
|
||||
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**: SM typically drafts next story after previous one is `done` to incorporate learnings
|
||||
4. **Review Before Done**: Stories should pass through `review` (code-review) before `done`
|
||||
5. **Learning Transfer**: Create next story after previous one is `done` to incorporate learnings
|
||||
|
|
|
|||
|
|
@ -11,27 +11,27 @@
|
|||
# STATUS DEFINITIONS:
|
||||
# ==================
|
||||
# Epic Status:
|
||||
# - backlog: Epic exists in epic file but not contexted
|
||||
# - contexted or in-progress
|
||||
# - done: Epic completed
|
||||
# - backlog: Epic exists in epic file but not started
|
||||
# - in-progress: Epic has at least one story in progress
|
||||
# - done: Epic completed (all stories done)
|
||||
#
|
||||
# Story Status:
|
||||
# - backlog: Story only exists in epic file
|
||||
# - drafted: Story file created in stories folder by *create-story
|
||||
# - ready-for-dev: Draft approved and story context created by *story-ready
|
||||
# - in-progress: Developer actively working on implementation by *dev-story
|
||||
# - review: Implementation complete, ready for review by *code-review
|
||||
# - done: Story completed by *story-done
|
||||
# - ready-for-dev: Story file created by create-story workflow with comprehensive context (Status: ready-for-dev)
|
||||
# - in-progress: Developer actively working on implementation (dev-story workflow)
|
||||
# - review: Implementation complete, ready for review (code-review workflow)
|
||||
# - done: Story completed and reviewed
|
||||
#
|
||||
# Retrospective Status:
|
||||
# - optional: Can be completed but not required
|
||||
# - completed: Retrospective has been done by *retrospective
|
||||
# - completed: Retrospective has been done (retrospective workflow)
|
||||
#
|
||||
# WORKFLOW NOTES:
|
||||
# ===============
|
||||
# - Epics should be marked `in-progress` before stories can be marked beyond `backlog`
|
||||
# - SM typically drafts next story ONLY after previous one is 'done' to incorporate learnings
|
||||
# - Dev moves story to 'review', dev reviews, then Dev moves to 'done'
|
||||
# - Run create-story to create detailed story implementation documents
|
||||
# - Stories can be worked in parallel if team capacity allows
|
||||
# - Create next story after previous one is 'done' to incorporate learnings
|
||||
# - Dev moves story to 'review' when complete, code-review marks as 'done'
|
||||
|
||||
# EXAMPLE STRUCTURE (your actual epics/stories will replace these):
|
||||
|
||||
|
|
@ -42,9 +42,9 @@ tracking_system: file-system
|
|||
story_location: "{story_location}"
|
||||
|
||||
development_status:
|
||||
epic-1: backlog
|
||||
epic-1: in-progress
|
||||
1-1-user-authentication: done
|
||||
1-2-account-management: drafted
|
||||
1-2-account-management: ready-for-dev
|
||||
1-3-plant-data-model: backlog
|
||||
1-4-add-plant-manual: backlog
|
||||
epic-1-retrospective: optional
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ Saved to: {sprint_artifacts}/tech-spec-{slug}.md
|
|||
[d] Done - exit
|
||||
[p] Party Mode - get feedback
|
||||
|
||||
**Recommended:** Run `dev-spec {sprint_artifacts}/tech-spec-{slug}.md` in fresh context.
|
||||
**Recommended:** Run `quick-dev {sprint_artifacts}/tech-spec-{slug}.md` in fresh context.
|
||||
</output>
|
||||
|
||||
<ask>Choice (a/b/d/p):</ask>
|
||||
|
|
|
|||
|
|
@ -296,7 +296,7 @@ test('should do something', async ({ {fixtureName} }) => {
|
|||
4. **Work one test at a time** (red → green for each)
|
||||
5. **Share progress** in daily standup
|
||||
6. **When all tests pass**, refactor code for quality
|
||||
7. **When refactoring complete**, run `bmad sm story-done` to move story to DONE
|
||||
7. **When refactoring complete**, run `code-review` to validate and move story to DONE
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue