mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-17 17:55:34 +00:00
Merge pull request #1090 from alexeyv/fix/issue-1088-remove-stale-workflow-refs
docs: remove stale references to deleted Phase 4 workflows
This commit is contained in:
Alex Verkhovsky
GitHub
commit
ec90699016
@ -199,24 +199,11 @@ PRDs are for Level 2-4 projects with multiple features requiring product-level c
|
||||
|
||||
### Q: How do I mark a story as done?
|
||||
|
||||
**A:** You have two options:
|
||||
**A:** After dev-story completes and 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. Open `sprint-status.yaml` (created by sprint-planning)
|
||||
2. Change the story status from `review` to `done`
|
||||
3. Save the file
|
||||
|
||||
### Q: Can I work on multiple stories at once?
|
||||
|
||||
|
||||
@ -2934,7 +2934,7 @@
|
||||
"gap": 1
|
||||
},
|
||||
"endBinding": {
|
||||
"elementId": "proc-story-done",
|
||||
"elementId": "proc-code-review",
|
||||
"focus": 0.04241833499478815,
|
||||
"gap": 1.3466869862454587
|
||||
},
|
||||
@ -3189,7 +3189,7 @@
|
||||
"lineHeight": 1.25
|
||||
},
|
||||
{
|
||||
"id": "proc-story-done",
|
||||
"id": "proc-code-review",
|
||||
"type": "rectangle",
|
||||
"x": 1169.3991588878014,
|
||||
"y": 947.2529662369525,
|
||||
@ -3207,12 +3207,12 @@
|
||||
"value": 8
|
||||
},
|
||||
"groupIds": [
|
||||
"proc-story-done-group"
|
||||
"proc-code-review-group"
|
||||
],
|
||||
"boundElements": [
|
||||
{
|
||||
"type": "text",
|
||||
"id": "proc-story-done-text"
|
||||
"id": "proc-code-review-text"
|
||||
},
|
||||
{
|
||||
"type": "arrow",
|
||||
@ -3235,7 +3235,7 @@
|
||||
"link": null
|
||||
},
|
||||
{
|
||||
"id": "proc-story-done-text",
|
||||
"id": "proc-code-review-text",
|
||||
"type": "text",
|
||||
"x": 1187.9272045420983,
|
||||
"y": 972.2529662369525,
|
||||
@ -3249,14 +3249,14 @@
|
||||
"roughness": 0,
|
||||
"opacity": 100,
|
||||
"groupIds": [
|
||||
"proc-story-done-group"
|
||||
"proc-code-review-group"
|
||||
],
|
||||
"fontSize": 16,
|
||||
"fontFamily": 1,
|
||||
"text": "Code Review\n<<use different\nLLM>>",
|
||||
"textAlign": "center",
|
||||
"verticalAlign": "middle",
|
||||
"containerId": "proc-story-done",
|
||||
"containerId": "proc-code-review",
|
||||
"locked": false,
|
||||
"version": 502,
|
||||
"versionNonce": 1242095014,
|
||||
@ -3289,7 +3289,7 @@
|
||||
"opacity": 100,
|
||||
"groupIds": [],
|
||||
"startBinding": {
|
||||
"elementId": "proc-story-done",
|
||||
"elementId": "proc-code-review",
|
||||
"focus": 0.014488632877232727,
|
||||
"gap": 8.284295421831303
|
||||
},
|
||||
|
||||
@ -377,12 +377,6 @@ Checks:
|
||||
|
||||
Quick Spec Flow works seamlessly with all Phase 4 implementation workflows:
|
||||
|
||||
### story-context (SM Agent)
|
||||
|
||||
- ✅ Recognizes tech-spec.md as authoritative source
|
||||
- ✅ Extracts context from tech-spec (replaces PRD)
|
||||
- ✅ Generates XML context for complex scenarios
|
||||
|
||||
### create-story (SM Agent)
|
||||
|
||||
- ✅ Can work with tech-spec.md instead of PRD
|
||||
@ -529,10 +523,6 @@ Quick Spec Flow is **fully standalone**:
|
||||
|
||||
**A:** No problem! You can always transition to BMad Method by running workflow-init and create-prd. Your tech-spec becomes input for the PRD.
|
||||
|
||||
### Q: Do I need story-context for every story?
|
||||
|
||||
**A:** Usually no! Tech-spec is comprehensive enough for most Quick Flow projects. Only use story-context for complex edge cases.
|
||||
|
||||
### Q: Can I skip validation?
|
||||
|
||||
**A:** No, validation always runs automatically. But it's fast and catches issues early!
|
||||
@ -564,15 +554,11 @@ Starter templates save hours of setup time. Let Quick Spec Flow find the best on
|
||||
|
||||
When validation runs, read the scores. They tell you if your spec is production-ready.
|
||||
|
||||
### 5. **Story Context is Optional**
|
||||
|
||||
For single changes, try going directly to dev-story first. Only add story-context if you hit complexity.
|
||||
|
||||
### 6. **Keep Single Changes Truly Atomic**
|
||||
### 5. **Keep Single Changes Truly Atomic**
|
||||
|
||||
If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you.
|
||||
|
||||
### 7. **Validate Story Sequence for Multi-Story Features**
|
||||
### 6. **Validate Story Sequence for Multi-Story Features**
|
||||
|
||||
When you get multiple stories, check the dependency validation output. Proper sequence matters!
|
||||
|
||||
|
||||
@ -196,7 +196,7 @@ workflow-init asks: "Is this work in progress or previous effort?"
|
||||
2. Verify agent has workflow:
|
||||
- PM agent: prd, tech-spec
|
||||
- Architect agent: create-architecture, validate-architecture
|
||||
- SM agent: sprint-planning, create-story, story-context
|
||||
- SM agent: sprint-planning, create-story
|
||||
3. Try menu number instead of name
|
||||
4. Check you're using correct agent for workflow
|
||||
|
||||
@ -219,23 +219,6 @@ workflow-init asks: "Is this work in progress or previous effort?"
|
||||
3. **Run in Phase 4 only** - Ensure Phase 2/3 complete first
|
||||
4. **Check file paths** - Epic files should be in correct output folder
|
||||
|
||||
### Problem: story-context generates empty or wrong context
|
||||
|
||||
**Symptoms:**
|
||||
|
||||
- Context file created but has no useful content
|
||||
- Context doesn't reference existing code
|
||||
- Missing technical guidance
|
||||
|
||||
**Solution:**
|
||||
|
||||
1. **Run epic-tech-context first** - story-context builds on epic context
|
||||
2. **Check story file exists** - Verify story was created by create-story
|
||||
3. **For brownfield**:
|
||||
- Ensure document-project was run
|
||||
- Verify docs/index.md exists with codebase context
|
||||
4. **Try regenerating** - Sometimes needs fresh attempt with more specific story details
|
||||
|
||||
---
|
||||
|
||||
## Context and Documentation Issues
|
||||
@ -362,7 +345,7 @@ For most brownfield projects, **Deep scan is sufficient**.
|
||||
1. **For brownfield**:
|
||||
- Ensure document-project captured existing architecture
|
||||
- Review architecture docs before implementing
|
||||
2. **Check story-context** - Should document integration points
|
||||
2. **Check story file** - Should document integration points
|
||||
3. **In tech-spec/architecture** - Explicitly document:
|
||||
- Which existing modules to modify
|
||||
- What APIs/services to integrate with
|
||||
@ -384,7 +367,7 @@ For most brownfield projects, **Deep scan is sufficient**.
|
||||
- Should detect existing patterns
|
||||
- Asks for confirmation before proceeding
|
||||
2. **Review documentation** - Ensure document-project captured patterns
|
||||
3. **Use story-context** - Injects pattern guidance per story
|
||||
3. **Use comprehensive story files** - Include pattern guidance in story
|
||||
4. **Add to code-review checklist**:
|
||||
- Pattern adherence
|
||||
- Convention consistency
|
||||
@ -459,9 +442,7 @@ To change locations, edit config.yaml then re-run workflows.
|
||||
```
|
||||
2. **Some workflows auto-update**:
|
||||
- sprint-planning creates file
|
||||
- epic-tech-context changes epic to "contexted"
|
||||
- create-story changes story to "drafted"
|
||||
- story-context changes to "ready-for-dev"
|
||||
- create-story changes story to "ready-for-dev"
|
||||
- dev-story may auto-update (check workflow)
|
||||
3. **Re-run sprint-planning** to resync if needed
|
||||
|
||||
@ -657,8 +638,8 @@ If your issue isn't covered here:
|
||||
|
||||
### "Context generation failed"
|
||||
|
||||
**Cause:** Missing prerequisites (epic context, story file, or docs)
|
||||
**Fix:** Verify epic-tech-context run, story file exists, docs present
|
||||
**Cause:** Missing prerequisites (story file or docs)
|
||||
**Fix:** Verify story file exists, docs present
|
||||
|
||||
---
|
||||
|
||||
|
||||
@ -152,10 +152,9 @@ Dependencies: Story 1.2 (DONE) ✅
|
||||
**Recommendation:** Run `create-story` to generate Story 1.3
|
||||
|
||||
After create-story:
|
||||
1. Run story-context
|
||||
2. Run dev-story
|
||||
3. Run code-review
|
||||
4. Run story-done
|
||||
1. Run dev-story
|
||||
2. Run code-review
|
||||
3. Update sprint-status.yaml to mark story done
|
||||
```
|
||||
|
||||
See: [workflow-status instructions](../workflows/workflow-status/instructions.md)
|
||||
|
||||
@ -53,11 +53,9 @@ Run `/bmad:bmm:workflows:sprint-planning` to generate it, then rerun sprint-stat
|
||||
1. If any story status == in-progress → recommend `dev-story` for the first in-progress story
|
||||
2. Else if any story status == review → recommend `code-review` for the first review story
|
||||
3. Else if any story status == ready-for-dev → recommend `dev-story`
|
||||
4. Else if any story status == drafted → recommend `story-ready`
|
||||
5. Else if any story status == backlog → recommend `create-story`
|
||||
6. Else if any epic status == backlog → recommend `epic-tech-context`
|
||||
7. Else if retrospectives are optional → recommend `retrospective`
|
||||
8. Else → All implementation items done; suggest `workflow-status` to plan next phase
|
||||
4. Else if any story status == backlog → recommend `create-story`
|
||||
5. Else if retrospectives are optional → recommend `retrospective`
|
||||
6. Else → All implementation items done; suggest `workflow-status` to plan next phase
|
||||
<action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (SM/DEV as appropriate)</action>
|
||||
</step>
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user