mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-17 17:55:34 +00:00
fix(bmm): complete cleanup of epic-tech-context workflow removal (#1001)
- Remove references to deprecated epic-tech-context, story-context, validate-epic-tech-context, validate-story-context, and story-done workflows - Simplify epic status: backlog → in-progress → done (was backlog → contexted) - Update create-story to handle legacy 'contexted' status for backward compat - Clean up sprint-planning instructions and status template - Update docs: agents-guide, brownfield-guide, faq, glossary, quick-start 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Brian <bmadcode@gmail.com>
This commit is contained in:
Alex Verkhovsky
GitHub
parent
afd2a163bf
commit
fe0817f590
@ -190,7 +190,7 @@ Workflows load only needed sections:
|
||||
|
||||
- Needs ALL epics to build complete status
|
||||
|
||||
**epic-tech-context, create-story, story-context, code-review** (Selective):
|
||||
**create-story, code-review** (Selective):
|
||||
|
||||
```
|
||||
Working on Epic 3, Story 2:
|
||||
|
||||
@ -182,13 +182,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
|
||||
- `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
|
||||
|
||||
@ -230,7 +225,6 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
|
||||
- Repository docs reference
|
||||
- MCP server best practices
|
||||
- Web search fallback
|
||||
- `story-done` - Mark story complete and advance queue
|
||||
|
||||
**Communication Style:** Succinct and checklist-driven. Cites file paths and acceptance criteria IDs. Only asks questions when inputs are missing.
|
||||
|
||||
@ -458,7 +452,6 @@ 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
|
||||
|
||||
**Communication Style:** Direct and energetic. Execution-focused. Breaks down complex game challenges into actionable steps. Celebrates performance wins.
|
||||
@ -650,14 +643,12 @@ 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 |
|
||||
|
||||
**When to use validation:**
|
||||
|
||||
@ -912,13 +903,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
|
||||
2. DEV: *develop-story
|
||||
3. DEV: *code-review
|
||||
4. Repeat steps 1-3 for next story
|
||||
```
|
||||
|
||||
**Testing Strategy:**
|
||||
@ -992,12 +980,12 @@ Quick reference for agent selection:
|
||||
| **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 |
|
||||
| **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 +1075,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`
|
||||
|
||||
**Testing Strategy:**
|
||||
|
||||
|
||||
@ -320,18 +320,14 @@ 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]
|
||||
DEV[dev-story]
|
||||
REVIEW[code-review]
|
||||
CHECK{More stories?}
|
||||
RETRO[retrospective<br/>Per epic]
|
||||
|
||||
SPRINT --> EPIC
|
||||
EPIC --> CREATE
|
||||
CREATE --> CONTEXT
|
||||
CONTEXT --> DEV
|
||||
SPRINT --> CREATE
|
||||
CREATE --> DEV
|
||||
DEV --> REVIEW
|
||||
REVIEW --> CHECK
|
||||
CHECK -->|Yes| CREATE
|
||||
@ -343,7 +339,7 @@ flowchart TD
|
||||
|
||||
**Status Progression:**
|
||||
|
||||
- Epic: `backlog → contexted`
|
||||
- Epic: `backlog → in-progress → done`
|
||||
- Story: `backlog → drafted → ready-for-dev → in-progress → review → done`
|
||||
|
||||
**Brownfield-Specific Implementation Tips:**
|
||||
@ -351,7 +347,6 @@ flowchart TD
|
||||
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
|
||||
|
||||
---
|
||||
|
||||
@ -405,13 +400,7 @@ Document in tech-spec/architecture:
|
||||
- Context epics before drafting stories
|
||||
- Update `sprint-status.yaml` as work progresses
|
||||
|
||||
### 9. Leverage Context Injection
|
||||
|
||||
- Run `epic-tech-context` before story drafting
|
||||
- Always create `story-context` before implementation
|
||||
- These reference existing patterns for consistency
|
||||
|
||||
### 10. Learn Continuously
|
||||
### 9. Learn Continuously
|
||||
|
||||
- Run `retrospective` after each epic
|
||||
- Incorporate learnings into next stories
|
||||
@ -479,7 +468,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
|
||||
- Load SM → `create-story` per story
|
||||
- Load DEV → `dev-story` per story
|
||||
6. **Review:** Per story completion
|
||||
|
||||
|
||||
@ -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
|
||||
- Code standards applied uniformly
|
||||
- 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 created during planning.
|
||||
|
||||
### Q: What's the difference between Level 1 and Level 2?
|
||||
|
||||
@ -162,15 +162,6 @@ 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?
|
||||
|
||||
**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
|
||||
|
||||
Think of it as: tech-spec is for small projects (replaces PRD and architecture), epic-tech-context is for large projects (supplements PRD).
|
||||
|
||||
### Q: Why no tech-spec at Level 2+?
|
||||
|
||||
**A:** Level 2+ projects need product-level planning (PRD) and system-level design (Architecture), which tech-spec doesn't provide. Tech-spec is too narrow for coordinating multiple features. Instead, Level 2-4 uses:
|
||||
@ -178,13 +169,6 @@ 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)
|
||||
|
||||
### Q: When do I create epic-tech-context?
|
||||
|
||||
**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.
|
||||
|
||||
**Why just-in-time?** You'll learn from earlier epics, and those learnings improve later epic-tech-context.
|
||||
|
||||
### Q: Do I need a PRD for a bug fix?
|
||||
|
||||
@ -219,17 +203,6 @@ PRDs are for Level 2-4 projects with multiple features requiring product-level c
|
||||
|
||||
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.
|
||||
|
||||
### Q: How do I mark a story as done?
|
||||
|
||||
**A:** You have two options:
|
||||
@ -271,7 +244,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
|
||||
- Learnings for future epics
|
||||
|
||||
Don't wait until project end - run after each epic for continuous improvement.
|
||||
|
||||
|
||||
@ -69,12 +69,6 @@ The methodology path (Quick Flow, BMad Method, or Enterprise Method) chosen for
|
||||
|
||||
**Quick Flow track only.** Comprehensive technical plan created upfront that serves as the primary planning document for small changes or features. Contains problem statement, solution approach, file-level changes, stack detection (brownfield), testing strategy, and developer resources.
|
||||
|
||||
### 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.
|
||||
|
||||
**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.
|
||||
|
||||
### PRD (Product Requirements Document)
|
||||
|
||||
**BMad Method/Enterprise tracks.** Product-level planning document containing vision, goals, Functional Requirements (FRs), Non-Functional Requirements (NFRs), success criteria, and UX considerations. Replaces tech-spec for larger projects that need product planning. **V6 Note:** PRD focuses on WHAT to build (requirements). Epic+Stories are created separately AFTER architecture via create-epics-and-stories workflow.
|
||||
@ -125,14 +119,6 @@ Sprint-based development through story-by-story iteration. Uses sprint-planning,
|
||||
|
||||
Fast-track workflow system for Quick Flow track projects that goes straight from idea to tech-spec to implementation, bypassing heavy planning. Designed for bug fixes, small features, and rapid prototyping.
|
||||
|
||||
### 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.
|
||||
|
||||
### 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.
|
||||
|
||||
---
|
||||
|
||||
## Agents and Roles
|
||||
@ -209,11 +195,12 @@ 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 not yet started
|
||||
- **in-progress** - Epic actively being worked on
|
||||
- **done** - All stories in epic completed
|
||||
|
||||
### Retrospective
|
||||
|
||||
@ -253,10 +240,6 @@ Markdown file containing story details: description, acceptance criteria, techni
|
||||
|
||||
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.
|
||||
|
||||
### Epic Context
|
||||
|
||||
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.
|
||||
|
||||
### Sprint Planning
|
||||
|
||||
Workflow that initializes Phase 4 implementation by creating sprint-status.yaml, extracting all epics/stories from planning docs, and setting up tracking infrastructure.
|
||||
|
||||
@ -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 Draft 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
|
||||
|
||||
#### 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 (Optional but 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" (optional but recommended)
|
||||
|
||||
After completing all stories in an epic:
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -95,7 +95,22 @@
|
||||
<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 "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
|
||||
<action>If epic status is "in-progress" → no change needed</action>
|
||||
<check if="epic status is 'done'">
|
||||
<output>🚫 ERROR: Cannot create story in completed epic</output>
|
||||
<output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
|
||||
<output>If you need to add more work, either:</output>
|
||||
<output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
|
||||
<output>2. Create a new epic for additional work</output>
|
||||
<action>HALT - Cannot proceed</action>
|
||||
</check>
|
||||
<check if="epic status is not one of: backlog, contexted, in-progress, done">
|
||||
<output>🚫 ERROR: Invalid epic status '{{epic_status}}'</output>
|
||||
<output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
|
||||
<output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
|
||||
<action>HALT - Cannot proceed</action>
|
||||
</check>
|
||||
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
|
||||
</check>
|
||||
|
||||
@ -137,7 +152,22 @@
|
||||
<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 "contexted" (legacy status) → update to "in-progress" (backward compatibility)</action>
|
||||
<action>If epic status is "in-progress" → no change needed</action>
|
||||
<check if="epic status is 'done'">
|
||||
<output>🚫 ERROR: Cannot create story in completed epic</output>
|
||||
<output>Epic {{epic_num}} is marked as 'done'. All stories are complete.</output>
|
||||
<output>If you need to add more work, either:</output>
|
||||
<output>1. Manually change epic status back to 'in-progress' in sprint-status.yaml</output>
|
||||
<output>2. Create a new epic for additional work</output>
|
||||
<action>HALT - Cannot proceed</action>
|
||||
</check>
|
||||
<check if="epic status is not one of: backlog, contexted, in-progress, done">
|
||||
<output>🚫 ERROR: Invalid epic status '{{epic_status}}'</output>
|
||||
<output>Epic {{epic_num}} has invalid status. Expected: backlog, in-progress, or done</output>
|
||||
<output>Please fix sprint-status.yaml manually or run sprint-planning to regenerate</output>
|
||||
<action>HALT - Cannot proceed</action>
|
||||
</check>
|
||||
<output>📊 Epic {{epic_num}} status updated to in-progress</output>
|
||||
</check>
|
||||
|
||||
|
||||
@ -1395,9 +1395,9 @@ 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}} when ready**
|
||||
- Start drafting stories with SM agent's `create-story`
|
||||
- Epic will be marked as `in-progress` automatically when first story is created
|
||||
- Ensure all critical path items are done first
|
||||
{{/if}}
|
||||
|
||||
|
||||
@ -68,12 +68,6 @@ development_status:
|
||||
</step>
|
||||
|
||||
<step n="3" goal="Apply intelligent status detection">
|
||||
<action>For each epic, check if tech context file exists:</action>
|
||||
|
||||
- Check: `{output_folder}/epic-{num}-context.md`
|
||||
- If exists → set epic status to `contexted`
|
||||
- Else → keep as `backlog`
|
||||
|
||||
<action>For each story, detect current status by checking files:</action>
|
||||
|
||||
**Story file detection:**
|
||||
@ -93,7 +87,7 @@ development_status:
|
||||
|
||||
**Status Flow Reference:**
|
||||
|
||||
- Epic: `backlog` → `contexted`
|
||||
- Epic: `backlog` → `in-progress` → `done`
|
||||
- Story: `backlog` → `drafted` → `ready-for-dev` → `in-progress` → `review` → `done`
|
||||
- Retrospective: `optional` ↔ `completed`
|
||||
</step>
|
||||
@ -113,15 +107,20 @@ 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 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
|
||||
# - 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)
|
||||
# - review: Ready for code review (via Dev's code-review workflow)
|
||||
# - done: Story completed
|
||||
#
|
||||
# Retrospective Status:
|
||||
@ -130,10 +129,10 @@ development_status:
|
||||
#
|
||||
# WORKFLOW NOTES:
|
||||
# ===============
|
||||
# - Epics should be 'contexted' before stories can be 'drafted'
|
||||
# - Epic transitions to 'in-progress' automatically when first story is created
|
||||
# - 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'
|
||||
# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
|
||||
|
||||
generated: { date }
|
||||
project: { project_name }
|
||||
@ -164,8 +163,7 @@ development_status:
|
||||
|
||||
- Total epics: {{epic_count}}
|
||||
- Total stories: {{story_count}}
|
||||
- Epics contexted: {{contexted_count}}
|
||||
- Stories in progress: {{in_progress_count}}
|
||||
- Epics in-progress: {{in_progress_count}}
|
||||
- Stories done: {{done_count}}
|
||||
|
||||
<action>Display completion summary to {user_name} in {communication_language}:</action>
|
||||
@ -175,8 +173,7 @@ development_status:
|
||||
- **File Location:** {status_file}
|
||||
- **Total Epics:** {{epic_count}}
|
||||
- **Total Stories:** {{story_count}}
|
||||
- **Contexted Epics:** {{contexted_count}}
|
||||
- **Stories In Progress:** {{in_progress_count}}
|
||||
- **Epics In Progress:** {{epics_in_progress_count}}
|
||||
- **Stories Completed:** {{done_count}}
|
||||
|
||||
**Next Steps:**
|
||||
@ -197,11 +194,12 @@ 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 not yet started
|
||||
- **in-progress**: Epic actively being worked on (stories being drafted/implemented)
|
||||
- **done**: All stories in epic completed
|
||||
|
||||
**Story Status Flow:**
|
||||
|
||||
@ -213,7 +211,7 @@ backlog → drafted → ready-for-dev → in-progress → review → done
|
||||
- **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)
|
||||
- **review**: Ready for code review (via Dev's code-review workflow)
|
||||
- **done**: Completed
|
||||
|
||||
**Retrospective Status:**
|
||||
@ -227,7 +225,7 @@ optional ↔ completed
|
||||
|
||||
### Guidelines
|
||||
|
||||
1. **Epic Context Recommended**: Epics should be `contexted` before stories can be `drafted`
|
||||
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`
|
||||
|
||||
@ -11,17 +11,17 @@
|
||||
# STATUS DEFINITIONS:
|
||||
# ==================
|
||||
# Epic Status:
|
||||
# - backlog: Epic exists in epic file but not contexted
|
||||
# - contexted or in-progress
|
||||
# - done: Epic completed
|
||||
# - backlog: Epic not yet started
|
||||
# - in-progress: Epic actively being worked on
|
||||
# - done: All stories in epic completed
|
||||
#
|
||||
# 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
|
||||
# - drafted: Story file created in stories folder
|
||||
# - ready-for-dev: Draft approved, ready for development
|
||||
# - in-progress: Developer actively working on implementation
|
||||
# - review: Implementation complete, ready for review
|
||||
# - done: Story completed
|
||||
#
|
||||
# Retrospective Status:
|
||||
# - optional: Can be completed but not required
|
||||
@ -29,9 +29,9 @@
|
||||
#
|
||||
# WORKFLOW NOTES:
|
||||
# ===============
|
||||
# - Epics should be marked `in-progress` before stories can be marked beyond `backlog`
|
||||
# - Mark epic as 'in-progress' when starting work on its first story
|
||||
# - 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'
|
||||
# - Dev moves story to 'review', then Dev runs code-review (fresh context, ideally different LLM)
|
||||
|
||||
# EXAMPLE STRUCTURE (your actual epics/stories will replace these):
|
||||
|
||||
|
||||
@ -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**, manually update story status to 'done' in sprint-status.yaml
|
||||
|
||||
---
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user