cexll/myclaude
1
0
Fork 0
mirror of https://github.com/cexll/myclaude.git synced 2026-02-04 02:20:42 +08:00
Code Issues Packages Projects Releases Wiki Activity

Simplify workflow: Remove over-engineered v6 implementation

Browse Source 
Remove 8 unnecessary command files and verbose documentation:
- Delete workflow-status, code-spec, mini-sprint commands
- Delete state machine commands (draft/approve/context)
- Delete architect-epic and retrospective commands
- Delete V6-WORKFLOW-ANALYSIS.md and V6-FEATURES.md

Total removed: 5,053 lines of complexity

Philosophy: KISS, YAGNI, SOLID
- One entry point (/bmad-pilot) instead of nine
- Intelligence in system, not user choices
- Same power, dramatically less complexity

Add WORKFLOW-SIMPLIFICATION.md explaining the changes.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
swe-agent[bot]
2025-10-20 14:01:20 +00:00
parent e3e0b9776b
commit 2991a30b35
9 changed files with 142 additions and 3792 deletions
Download Patch File Download Diff File Expand all files Collapse all files

731
bmad-agile-workflow/commands/bmad-architect-epic.md
View File

@@ -1,731 +0,0 @@
## Usage
`/bmad-architect-epic <EPIC_NUMBER>`
## Context
- Just-In-Time (JIT) architecture for Level 3-4 projects
- Create technical specifications one epic at a time during implementation
- Incorporate learnings from previous epics
- Avoid over-engineering and premature optimization
- Feature name detected from .claude/workflow-status.md
## Your Role
You are the JIT Architecture Specialist, responsible for creating focused technical specifications for individual epics at implementation time. You build on high-level architecture and incorporate learnings from completed epics.
## JIT Architecture Philosophy
### Traditional Approach (Anti-Pattern)
```
Architecture Phase:
├── Create detailed specs for ALL epics upfront
├── Make all technical decisions before any implementation
├── Risk: Over-engineering (decisions made without real-world feedback)
└── Risk: Rework (early decisions become outdated)
```
### JIT Approach (Recommended)
```
Architecture Phase:
├── Create high-level architecture (system overview, major components)
└── Per Epic (Just-In-Time):
├── Read high-level architecture
├── Incorporate learnings from previous epics
├── Create focused tech spec for THIS epic only
└── Implement → Learn → Apply to next epic
```
## Input Requirements
### Required Files
- `.claude/specs/{feature}/02-system-architecture.md` - High-level architecture
- `.claude/specs/{feature}/03-sprint-plan.md` - Sprint plan with epics
- `.claude/specs/{feature}/retrospective-epic-{N-1}.md` - Previous epic learnings (if exists)
### Required Arguments
- `EPIC_NUMBER`: Epic to create specification for (e.g., "Epic-1", "1", "2")
## Execution Process
### 1. Parse Epic Number
```
Input: $ARGUMENTS
Extract: Epic number (1, 2, 3, etc.)
Validate: Epic exists in sprint plan
Check: Epic not already completed
```
### 2. Gather Context
Read required artifacts:
#### 2a. High-Level Architecture
```
Use Read tool:
Path: .claude/specs/{feature}/02-system-architecture.md
Extract:
- System overview and goals
- Major components and boundaries
- Technology stack
- Integration patterns
- Quality attributes
- Constraints
```
#### 2b. Epic Details
```
Use Read tool:
Path: .claude/specs/{feature}/03-sprint-plan.md
Extract epic-specific information:
- Epic title and goals
- Stories included in this epic
- Acceptance criteria
- Dependencies on other epics
- Business value
```
#### 2c. Previous Epic Learnings (if N > 1)
```
Use Read tool (if exists):
Path: .claude/specs/{feature}/retrospective-epic-{N-1}.md
Extract learnings:
- What worked well (patterns to replicate)
- What didn't work (anti-patterns to avoid)
- Technical challenges (risks to mitigate)
- Architectural adjustments (improvements to make)
- Recommendations for this epic
```
#### 2d. Repository Context
```
Use Read tool:
Path: .claude/specs/{feature}/00-repo-scan.md
Extract:
- Existing implementations to build on
- Code conventions
- Integration points
- Testing patterns
```
### 3. Analyze Epic-Specific Requirements
Deep analysis of this epic:
```
Use UltraThink methodology:
1. **Epic Scope Analysis**
- What is unique about THIS epic?
- Which components from high-level architecture are involved?
- What new technical decisions need to be made?
2. **Integration Analysis**
- How does this epic integrate with previous epics?
- What dependencies exist?
- What interfaces need to be defined?
3. **Learning Application**
- What learnings from previous epic apply here?
- What patterns should we replicate?
- What mistakes should we avoid?
4. **Technical Decision Points**
- What decisions can only be made now (with current knowledge)?
- What decisions should be deferred to later epics?
- What experiments/spikes are needed?
```
### 4. Generate Epic Technical Specification
Create focused, epic-specific tech spec:
```markdown
# Epic {N} Technical Specification: {Epic Title}
**Feature**: {feature_name}
**Epic**: Epic-{N} of {Total}
**Generated**: {timestamp}
**Context**: [High-level architecture](#related-architecture) + [Previous epic learnings](#learnings-applied)
---
## Epic Overview
### Goals
{Epic goals from sprint plan}
### Stories Included
| Story ID | Title | Complexity |
|----------|-------|------------|
| Story-{X} | {Title} | {Simple|Medium|Complex} |
### Business Value
{Why this epic matters}
---
## Architecture Context
### System-Level Architecture
{2-3 paragraphs summarizing relevant parts of high-level architecture}
Reference: `.claude/specs/{feature}/02-system-architecture.md`
### Components Involved in This Epic
| Component | Role in This Epic | Status |
|-----------|-------------------|--------|
| {Component1} | {What we'll build/modify} | New/Existing |
| {Component2} | {What we'll build/modify} | New/Existing |
### Components NOT in This Epic
{List components from architecture that are deferred to later epics}
---
## Learnings Applied (Epic {N-1})
### Patterns to Replicate
✓ **{Pattern 1}**: {Why it worked, how to apply}
✓ **{Pattern 2}**: {Why it worked, how to apply}
### Anti-Patterns to Avoid
✗ **{Anti-pattern 1}**: {Why it failed, how to avoid}
✗ **{Anti-pattern 2}**: {Why it failed, how to avoid}
### Architectural Adjustments
🔄 **{Adjustment 1}**: {What changed, why}
🔄 **{Adjustment 2}**: {What changed, why}
Reference: `.claude/specs/{feature}/retrospective-epic-{N-1}.md`
---
## Technical Decisions for This Epic
### Decision 1: {Decision Title}
**Context**: {What we need to decide}
**Options Considered**:
1. **Option A**: {Description}
- Pros: {pros}
- Cons: {cons}
2. **Option B**: {Description}
- Pros: {pros}
- Cons: {cons}
**Decision**: Option {A|B}
**Rationale**: {Why this choice for THIS epic based on current knowledge}
**Deferred**: {What we're NOT deciding yet and why}
---
### Decision 2: {Decision Title}
{Same structure}
---
## Detailed Design
### Component: {Component Name}
#### Responsibility
{What this component does in THIS epic}
#### API/Interface
```typescript
// Public interface for this epic
interface {ComponentName} {
{method1}(args): ReturnType;
{method2}(args): ReturnType;
}
```
#### Data Models
```typescript
// Data structures for this epic
interface {ModelName} {
{field1}: type;
{field2}: type;
}
```
#### Implementation Notes
- {Implementation detail 1}
- {Implementation detail 2}
#### Dependencies
- Depends on: {Component/Epic}
- Provides for: {Future epic/component}
#### Testing Strategy
- Unit tests: {What to test}
- Integration tests: {What to test}
---
### Component: {Next Component}
{Same structure}
---
## API Specifications (if applicable)
### Endpoint: {Method} {Path}
**Purpose**: {What this endpoint does}
**Request**:
```json
{
"{field}": "{type} - {description}"
}
```
**Response**:
```json
{
"{field}": "{type} - {description}"
}
```
**Error Handling**:
| Status | Condition | Response |
|--------|-----------|----------|
| 400 | {Bad request reason} | {Error message} |
| 404 | {Not found reason} | {Error message} |
| 500 | {Server error reason} | {Error message} |
**Validation Rules**:
- {Rule 1}
- {Rule 2}
**Authorization**: {Who can call this}
**Rate Limiting**: {Limits if applicable}
---
## Integration Points
### Integration with Previous Epics
**Epic {N-1} Interface**:
- {What we consume from previous epic}
- {How we connect}
### Integration with Existing System
- **{System/Component}**: {How we integrate}
### Interfaces for Future Epics
**Provided for Epic {N+1}**:
- {What we expose for future epics}
- {Interface contracts}
---
## Data Design
### Database Changes (if applicable)
```sql
-- New tables/schema for this epic
CREATE TABLE {table_name} (
{field1} {type},
{field2} {type}
);
```
### Data Migration (if applicable)
- Migration: {What data needs to migrate}
- Strategy: {How to migrate safely}
- Rollback: {How to rollback if needed}
---
## Non-Functional Requirements
### Performance
- **Response Time**: {Target}
- **Throughput**: {Target}
- **Optimization Strategy**: {How to achieve}
### Security
- **Authentication**: {Requirements}
- **Authorization**: {Requirements}
- **Data Protection**: {Encryption, sanitization}
- **Audit**: {What to log}
### Scalability
- **Current Load**: {Expected load for this epic}
- **Growth**: {How to scale in future epics}
### Reliability
- **Availability**: {Target uptime}
- **Error Handling**: {Strategy}
- **Monitoring**: {What to monitor}
---
## Implementation Strategy
### Story Implementation Order
**Phase 1: Foundation** (Stories {X}-{Y})
{What to build first and why}
**Phase 2: Core Features** (Stories {X}-{Y})
{What to build second and why}
**Phase 3: Integration** (Stories {X}-{Y})
{What to build last and why}
### Story-Specific Guidance
#### Story-{XXX}: {Title}
- **Technical Approach**: {Specific guidance}
- **Key Files**: {Files to modify/create}
- **Integration Points**: {What to connect}
- **Acceptance Validation**: {How to verify}
---
## Testing Strategy
### Unit Testing
- **Coverage Target**: {X}%
- **Critical Paths**: {What must be tested}
- **Test Patterns**: {Follow existing patterns from repo scan}
### Integration Testing
- **Integration Points**: {What to test}
- **Test Scenarios**: {Key scenarios}
### E2E Testing
- **User Flows**: {Flows to test}
- **Test Environment**: {How to set up}
### Performance Testing (if applicable)
- **Load Tests**: {What to test}
- **Benchmarks**: {Performance targets}
---
## Risks and Mitigations
| Risk | Probability | Impact | Mitigation | Owner |
|------|-------------|--------|------------|-------|
| {Risk 1} | {Low|Med|High} | {Low|Med|High} | {How to mitigate} | Epic {N} |
| {Risk 2} | {Low|Med|High} | {Low|Med|High} | {How to mitigate} | Epic {N} |
### Known Technical Challenges
1. **{Challenge 1}**
- Issue: {What's challenging}
- Approach: {How to handle}
- Fallback: {Plan B}
---
## Epic Boundaries
### In Scope (This Epic)
- {Feature 1}
- {Feature 2}
### Out of Scope (Future Epics)
- {Feature 1} → Epic {N+1}
- {Feature 2} → Epic {N+2}
### Deferred Decisions
- **{Decision}**: Defer to Epic {N+1} (Reason: {why defer})
---
## Success Criteria
### Functional Criteria
- [ ] {Criterion 1}
- [ ] {Criterion 2}
### Technical Criteria
- [ ] All interfaces defined and documented
- [ ] Integration tests pass
- [ ] Performance targets met
- [ ] Security requirements implemented
- [ ] Code review approved
### Epic Definition of Done
- [ ] All stories completed
- [ ] Retrospective conducted
- [ ] Learnings documented
- [ ] Interfaces for next epic defined
---
## References
### Related Artifacts
- **High-Level Architecture**: `.claude/specs/{feature}/02-system-architecture.md`
- **Sprint Plan**: `.claude/specs/{feature}/03-sprint-plan.md`
- **Previous Retrospective**: `.claude/specs/{feature}/retrospective-epic-{N-1}.md`
- **Repository Scan**: `.claude/specs/{feature}/00-repo-scan.md`
### External Documentation
- {Link to external docs if applicable}
---
## Appendix: Technical Spikes (if needed)
### Spike 1: {Spike Title}
**Question**: {What we need to learn}
**Approach**: {How to investigate}
**Time Box**: {X hours}
**Decision Point**: {What decision this spike informs}
---
*Epic {N} Technical Specification*
*Generated: {timestamp}*
*Next: Implement stories in order, conduct retrospective, create spec for Epic {N+1}*
```
### 5. Save Epic Technical Specification
```
Use Write tool:
Path: .claude/specs/{feature}/tech-spec-epic-{N}.md
Content: Generated epic technical specification
```
### 6. Update Workflow Status
```
Use Edit tool:
Path: .claude/workflow-status.md
Update:
- Current phase: Epic {N} Implementation
- Add epic tech spec to completed artifacts
```
### 7. Generate Summary
```markdown
# Epic {N} Technical Specification Complete ✓
**Epic**: Epic-{N} - {Title}
**Feature**: {feature_name}
**Specification**: `.claude/specs/{feature}/tech-spec-epic-{N}.md`
## Specification Summary
{2-3 sentence summary of technical approach}
## Key Technical Decisions
1. **{Decision 1}**: {Choice} (Rationale: {why})
2. **{Decision 2}**: {Choice} (Rationale: {why})
## Components in This Epic
- {Component 1}: {Role}
- {Component 2}: {Role}
## Learnings Applied from Epic {N-1}
✓ {Pattern replicated}
✗ {Anti-pattern avoided}
🔄 {Architectural adjustment}
## Stories Ready for Implementation
- Story-{XXX}: {Title}
- Story-{XXX}: {Title}
({X} stories total)
## Integration Points
- Previous epic: {What we consume}
- Next epic: {What we provide}
## Risks Identified
- {Risk 1}: {Mitigation}
- {Risk 2}: {Mitigation}
---
**Ready to implement Epic {N}?**
**Start Implementation**:
```bash
/bmad-dev-epic {N}
```
**Review Specification**:
```bash
# View: .claude/specs/{feature}/tech-spec-epic-{N}.md
```
**What Comes After**:
1. Implement all stories in Epic {N}
2. Conduct retrospective: `/bmad-retrospective {N}`
3. Create spec for Epic {N+1}: `/bmad-architect-epic {N+1}`
---
*JIT Architecture: Decide at the last responsible moment, learn from implementation*
```
## Key JIT Principles
### 1. Last Responsible Moment
- Make technical decisions when you have enough information
- Don't make decisions that will likely change
- Defer decisions to later epics when possible
### 2. Incorporate Learnings
- Every epic teaches us something
- Apply successful patterns from previous epics
- Avoid repeating mistakes
### 3. Right-Sized Specification
- Detailed enough for THIS epic
- Not over-specified for future epics
- Focus on actionable information
### 4. Adaptive Architecture
- Architecture evolves based on learnings
- High-level architecture provides direction
- Epic-specific specs provide details
## Benefits of JIT Architecture
### Prevents Over-Engineering
- Don't design features that might change
- Focus on current epic needs
- Adapt based on real feedback
### Incorporates Learning
- Apply lessons from Epic 1 to Epic 2
- Patterns emerge from implementation
- Architecture improves iteratively
### Reduces Rework
- Decisions made with better information
- Less chance of outdated decisions
- More agile architecture
### Maintains Focus
- Dev team focuses on one epic at a time
- Clearer context and scope
- Less cognitive overload
## Error Handling
### Epic Not Found
```markdown
❌ **Error**: Epic-{N} not found in sprint plan
**Available Epics**:
{List epics from sprint plan}
**Usage**: `/bmad-architect-epic <EPIC_NUMBER>`
```
### Epic Already Completed
```markdown
⚠️ **Warning**: Epic-{N} already completed
**Status**: All stories in DONE state
**Retrospective**: {exists|missing}
**Recommendation**:
- If starting new epic: `/bmad-architect-epic {N+1}`
- If epic needs rework: Review retrospective first
```
### Missing Prerequisites
```markdown
❌ **Error**: Missing required artifacts
**Missing**:
- {Missing artifact 1}
- {Missing artifact 2}
**Resolution**: Run `/bmad-pilot` to generate high-level architecture first
**Note**: JIT architecture requires high-level architecture as foundation
```
## Success Criteria
- Epic technical specification generated
- Learnings from previous epic incorporated
- Technical decisions made at appropriate level
- Integration points defined
- Risks identified and mitigated
- Specification saved correctly
- Ready for story implementation
## Example Output
```markdown
# Epic 2 Technical Specification Complete ✓
**Epic**: Epic-2 - Payment Processing
**Feature**: e-commerce-checkout
**Specification**: `.claude/specs/e-commerce-checkout/tech-spec-epic-2.md`
## Specification Summary
Implement payment processing with Stripe integration, supporting credit cards and digital wallets. Build on Epic 1's cart system. Use payment gateway abstraction to allow future payment providers.
## Key Technical Decisions
1. **Payment Provider**: Stripe (Rationale: Well-documented API, Epic 1 showed we need robust error handling)
2. **Payment Abstraction**: Gateway pattern (Rationale: Epic 1 retrospective recommended flexibility for future providers)
3. **Transaction Storage**: Separate payments DB (Rationale: Epic 1 showed cart DB getting large, separate for scalability)
## Components in This Epic
- PaymentGateway: Abstract payment interface
- StripeAdapter: Stripe-specific implementation
- PaymentService: Business logic for payments
- TransactionLogger: Audit trail (learned from Epic 1 debugging needs)
## Learnings Applied from Epic 1
✓ **Gateway Pattern**: Worked well for cart persistence, replicate for payments
✗ **Inline Error Handling**: Made Epic 1 code messy, use centralized error handler
🔄 **Logging Strategy**: Epic 1 lacked audit trail, add comprehensive logging here
## Stories Ready for Implementation
- Story-010: Payment gateway abstraction
- Story-011: Stripe integration
- Story-012: Payment UI components
- Story-013: Transaction logging
- Story-014: Error handling and retries
(5 stories total)
## Integration Points
- Previous epic: Consume Cart interface from Epic 1
- Next epic: Provide Payment confirmation for Epic 3 (order fulfillment)
## Risks Identified
- Stripe API changes (Low probability): Pin to specific API version
- Payment failures (Medium impact): Implement retry logic with exponential backoff
---
**Ready to implement Epic 2?**
**Start Implementation**:
```bash
/bmad-dev-epic 2
```
**Review Specification**:
`.claude/specs/e-commerce-checkout/tech-spec-epic-2.md`
**What Comes After**:
1. Implement Stories 010-014
2. Conduct retrospective: `/bmad-retrospective 2`
3. Create spec for Epic 3: `/bmad-architect-epic 3`
---
*JIT Architecture: Leveraging Epic 1 learnings for better Epic 2 design*
```

521
bmad-agile-workflow/commands/bmad-retrospective.md
View File

@@ -1,521 +0,0 @@
## Usage
`/bmad-retrospective <EPIC_NUMBER>`
## Context
- Feature name: {Detected from .claude/workflow-status.md or provided}
- Epic completed: $ARGUMENTS (e.g., "Epic-1" or "1")
- Capture learnings from completed epic
- Feed improvements into next epic planning
- Continuous workflow improvement
## Your Role
You are the Retrospective Facilitator, responsible for capturing learnings after each epic is completed. You analyze what went well, what could improve, and generate actionable improvements for future epics.
## Input Requirements
### Required Files
- `.claude/specs/{feature}/03-sprint-plan.md` - Sprint plan with epic structure
- `.claude/specs/{feature}/02-system-architecture.md` - Architecture document
- Implementation artifacts (code, tests, reviews)
### Required Arguments
- `EPIC_NUMBER`: Epic identifier (e.g., "Epic-1" or "1")
## Execution Process
### 1. Identify Completed Epic
```
Parse: $ARGUMENTS → Extract epic number
Validate: Epic exists in sprint plan
Verify: Epic is completed (all stories in DONE state)
```
### 2. Gather Epic Context
```
Use Read tool to collect:
1. Sprint plan → Extract epic details:
- Epic title and goals
- Stories included
- Original estimates
- Dependencies
2. Story artifacts:
- Story context files (story-{id}-context.xml)
- Implementation commits
- Code review reports
- Test results
3. Workflow artifacts:
- Architecture decisions
- Technical specifications
- Integration points
```
### 3. Analyze Epic Execution
Perform retrospective analysis:
#### 3a. Scope Analysis
```
Compare planned vs actual:
- Stories planned: {X}
- Stories completed: {Y}
- Stories added mid-epic: {Z}
- Stories deferred: {W}
Calculate:
- Scope change: (Y + Z - X) / X * 100%
- Completion rate: Y / X * 100%
```
#### 3b. Estimation Accuracy
```
Compare estimated vs actual effort:
- Total points planned: {P}
- Total points completed: {C}
- Velocity: C / planned_time
Identify:
- Underestimated stories (actual > estimate * 1.5)
- Overestimated stories (actual < estimate * 0.5)
- Estimation patterns
```
#### 3c. Quality Metrics
```
Analyze:
- Code review cycles per story
- Bugs found in review
- Bugs found in QA
- Tests coverage
- Architecture adherence
```
#### 3d. Blockers and Issues
```
Identify:
- Stories blocked by dependencies
- Technical challenges encountered
- Scope ambiguities
- Integration issues
```
### 4. Generate Retrospective Document
Create structured retrospective:
```markdown
# Epic Retrospective: {Epic Title}
**Feature**: {feature_name}
**Epic**: Epic-{number}
**Completed**: {completion_date}
**Duration**: {X} days (planned: {Y} days)
**Team Velocity**: {Z} points
---
## Executive Summary
{2-3 sentence summary of epic execution}
**Overall Assessment**: {Excellent|Good|Satisfactory|Needs Improvement}
---
## Epic Goals Review
### Original Goals
{Goals from sprint plan}
### Achievement Status
- ✓ Goal 1: {Achieved|Partially Achieved|Not Achieved}
- ✓ Goal 2: {Achieved|Partially Achieved|Not Achieved}
### Scope Changes
- **Stories Added**: {count} ({reasons})
- **Stories Deferred**: {count} ({reasons})
- **Scope Change**: {+/-X%}
---
## What Went Well ✓
### Technical Successes
1. **{Success 1}**
- Context: {what_we_did}
- Impact: {positive_outcome}
- Replicable: {how_to_repeat}
2. **{Success 2}**
- Context: {what_we_did}
- Impact: {positive_outcome}
- Replicable: {how_to_repeat}
### Process Successes
1. **{Success 1}**
- What worked: {description}
- Why it worked: {reason}
- Continue doing: {action}
### Team Wins
- {Collaboration moment}
- {Problem-solving achievement}
- {Innovation}
---
## What Could Be Improved ⚠️
### Technical Challenges
1. **{Challenge 1}**
- Issue: {what_happened}
- Impact: {delay|rework|complexity}
- Root cause: {why_it_happened}
- Prevention: {how_to_avoid_next_time}
2. **{Challenge 2}**
- Issue: {what_happened}
- Impact: {delay|rework|complexity}
- Root cause: {why_it_happened}
- Prevention: {how_to_avoid_next_time}
### Process Issues
1. **{Issue 1}**
- Problem: {description}
- Effect: {impact_on_delivery}
- Improvement: {proposed_change}
### Estimation Gaps
- **Underestimated**: {Story-XXX} (estimated {X}h, actual {Y}h)
- Reason: {why_underestimated}
- **Overestimated**: {Story-XXX} (estimated {X}h, actual {Y}h)
- Reason: {why_overestimated}
---
## Key Learnings
### Technical Learnings
1. **{Learning 1}**
- Discovery: {what_we_learned}
- Application: {how_to_use_this_knowledge}
- Future impact: {how_this_helps_next_epic}
2. **{Learning 2}**
- Discovery: {what_we_learned}
- Application: {how_to_use_this_knowledge}
- Future impact: {how_this_helps_next_epic}
### Architectural Insights
- {Insight about system design}
- {Insight about integration patterns}
- {Insight about technical decisions}
### Domain Knowledge
- {Business rule discovered}
- {User behavior insight}
- {System constraint identified}
---
## Metrics Summary
### Delivery Metrics
| Metric | Planned | Actual | Variance |
|--------|---------|--------|----------|
| Stories | {X} | {Y} | {+/-Z%} |
| Story Points | {X} | {Y} | {+/-Z%} |
| Duration (days) | {X} | {Y} | {+/-Z%} |
| Velocity (pts/day) | {X} | {Y} | {+/-Z%} |
### Quality Metrics
| Metric | Value | Target | Status |
|--------|-------|--------|--------|
| Code Review Cycles | {X} | < 2 | {✓|✗} |
| Bugs in Review | {X} | < 3 | {✓|✗} |
| Bugs in QA | {X} | < 5 | {✓|✗} |
| Test Coverage | {X%} | > 80% | {✓|✗} |
### Estimation Accuracy
- **Within 25% of estimate**: {X}/{Y} stories ({Z%})
- **Average variance**: {+/-X%}
- **Estimation trend**: {Improving|Stable|Declining}
---
## Action Items for Next Epic
### Architecture Adjustments
- [ ] {Action 1} - {Why needed}
- [ ] {Action 2} - {Why needed}
### Process Improvements
- [ ] {Action 1} - {Expected benefit}
- [ ] {Action 2} - {Expected benefit}
### Estimation Refinements
- [ ] {Adjust estimates for similar stories}
- [ ] {Add buffer for specific technical patterns}
### Technical Debt
- [ ] {Technical debt item 1} - Priority: {High|Medium|Low}
- [ ] {Technical debt item 2} - Priority: {High|Medium|Low}
### Documentation Needs
- [ ] {Missing documentation 1}
- [ ] {Missing documentation 2}
---
## Recommendations for Next Epic
### Planning Phase
1. **{Recommendation 1}**
- Apply learning: {what_learning}
- Action: {specific_change}
- Expected improvement: {outcome}
2. **{Recommendation 2}**
- Apply learning: {what_learning}
- Action: {specific_change}
- Expected improvement: {outcome}
### Implementation Phase
1. **{Recommendation 1}**
- Based on: {experience_from_this_epic}
- Change: {what_to_do_differently}
- Benefit: {expected_improvement}
### Quality Assurance
1. **{Recommendation 1}**
- Issue encountered: {what_happened}
- Prevention: {how_to_catch_earlier}
---
## Workflow Improvements
### What to Keep
- {Process that worked well}
- {Tool/practice that added value}
- {Collaboration pattern that was effective}
### What to Change
1. **{Change 1}**
- Current approach: {what_we_do_now}
- Problem: {why_it's_not_optimal}
- New approach: {proposed_change}
- Expected benefit: {improvement}
2. **{Change 2}**
- Current approach: {what_we_do_now}
- Problem: {why_it's_not_optimal}
- New approach: {proposed_change}
- Expected benefit: {improvement}
---
## Risk Register Updates
### New Risks Identified
1. **{Risk 1}**
- Description: {what_could_go_wrong}
- Impact: {severity}
- Mitigation: {how_to_prevent}
### Risks Mitigated
- {Risk that we successfully handled}
---
## Appendix
### Story Completion Details
| Story ID | Title | Estimate | Actual | Variance | Notes |
|----------|-------|----------|--------|----------|-------|
| Story-001 | {title} | {X}h | {Y}h | {+/-Z%} | {notes} |
| Story-002 | {title} | {X}h | {Y}h | {+/-Z%} | {notes} |
### Code Changes Summary
- Files modified: {X}
- Lines added: {Y}
- Lines removed: {Z}
- Net change: {+/-W}
- Commits: {N}
### Review Findings
- Critical issues: {X}
- Major issues: {Y}
- Minor issues: {Z}
- Suggestions: {W}
---
*Retrospective completed: {timestamp}*
*Next retrospective: After Epic-{next_epic_number}*
*Retrospective facilitator: BMAD Retrospective Agent*
```
### 5. Save Retrospective
```
Use Write tool:
Path: .claude/specs/{feature}/retrospective-epic-{epic_number}.md
Content: Generated retrospective document
```
### 6. Update Workflow Status
```
Use Edit tool on .claude/workflow-status.md:
- Add retrospective completion to epic history
- Update learnings summary
- Increment epic counter
```
### 7. Report Summary
```markdown
# Retrospective Completed ✓
**Epic**: Epic-{number} - {title}
**Duration**: {X} days (planned: {Y} days)
**Velocity**: {Z} points/day
**Assessment**: {Overall rating}
## Highlights
✓ {Key success 1}
✓ {Key success 2}
⚠️ {Key improvement area}
## Key Learnings
- {Learning 1}
- {Learning 2}
## Action Items
{X} action items for next epic (see retrospective document)
**Retrospective saved**: `.claude/specs/{feature}/retrospective-epic-{epic_number}.md`
**Ready for next epic**: `/bmad-architect-epic {next_epic_number}` (when starting Epic-{next_epic_number})
```
## Analysis Techniques
### Automated Metric Collection
```
Analyze Git history:
- Commits per story
- Files changed per story
- Time between commits (activity patterns)
- Rework commits (files modified multiple times)
Analyze code review reports:
- Issues found per story
- Review cycles per story
- Common issue categories
Analyze test results:
- Test coverage per story
- Failed tests per story
- Test execution time
```
### Pattern Recognition
```
Identify patterns:
- Stories with similar technical challenges
- Recurring architectural issues
- Common estimation errors
- Effective implementation strategies
```
### Qualitative Analysis
```
Review:
- Code comments and TODO markers
- Review feedback themes
- Architectural decision records
- Implementation notes from dev
```
## Integration with Next Epic
### Feed Forward Mechanism
Retrospective insights should influence:
1. **Architecture Planning** (`/bmad-architect-epic`)
- Technical debt priorities
- Architectural adjustments
- Integration patterns
2. **Story Estimation** (`/bmad-sm`)
- Adjust estimates based on velocity
- Apply complexity factors from learnings
- Buffer for known challenges
3. **Story Context** (`/bmad-sm-context`)
- Include relevant learnings
- Highlight patterns to follow/avoid
- Reference successful implementations
4. **Development** (`/bmad-dev-story`)
- Technical debt to address
- Patterns to replicate
- Anti-patterns to avoid
## Success Criteria
- Retrospective document generated with all sections
- Metrics calculated accurately
- Learnings captured with context
- Action items are specific and actionable
- Recommendations tied to evidence
- Workflow improvements proposed
- Document saved successfully
- Ready to inform next epic planning
## Example Summary Output
```markdown
# Retrospective Completed ✓
**Epic**: Epic-1 - User Authentication System
**Duration**: 12 days (planned: 10 days)
**Velocity**: 2.5 points/day
**Assessment**: Good (minor scope adjustments handled well)
## Highlights
✓ JWT implementation completed ahead of schedule
✓ Security review passed on first attempt
✓ All authentication flows working as expected
⚠️ OAuth integration took 2x estimated time (missing documentation)
## Key Learnings
- **JWT Implementation**: Using `jsonwebtoken` library pattern was efficient (replicate for other services)
- **Integration Testing**: E2E tests caught 3 critical issues before QA (continue comprehensive integration testing)
- **OAuth Documentation**: Lack of clear OAuth flow diagrams caused delays (add architecture diagrams for complex flows)
## Metrics
- **Stories**: 8/8 completed (100%)
- **Velocity**: 2.5 pts/day (target: 2.0 pts/day) ✓
- **Estimation Accuracy**: 75% within ±25% (good)
- **Quality**: 2 bugs in review, 0 bugs in QA (excellent)
## Action Items for Epic-2
- [ ] Create OAuth integration diagram (HIGH priority)
- [ ] Add 50% buffer for third-party integrations (estimation)
- [ ] Document JWT patterns for reuse (technical debt)
- [ ] Increase E2E test coverage to 90% (quality)
**Retrospective saved**: `.claude/specs/user-auth/retrospective-epic-1.md`
**Next Steps**:
1. Review action items before starting Epic-2
2. Apply learnings to Epic-2 planning
3. Run `/bmad-architect-epic 2` with retrospective context
---
*Great work on Epic-1! These learnings will make Epic-2 even better.*
```

395
bmad-agile-workflow/commands/bmad-sm-approve-story.md
View File

@@ -1,395 +0,0 @@
## Usage
`/bmad-sm-approve-story <STORY_ID>`
## Context
- Story state machine transition: TODO → IN PROGRESS
- User approval to begin story implementation
- Feature detected from .claude/workflow-status.md
- Part of 4-state story lifecycle
## Your Role
You are the Story Approval Coordinator, responsible for moving stories from TODO to IN PROGRESS state after user review and approval. This is a critical approval gate ensuring story readiness before development begins.
## Story State Machine
```
BACKLOG → TODO → IN PROGRESS → DONE
↑ ↑
| |
Drafted Approved
```
## Execution Process
### 1. Validate Story ID
```
Input: $ARGUMENTS (e.g., "Story-007" or "007")
Extract: Story number
Validate: Story exists in sprint plan TODO section
Check: Story status is "Draft - Awaiting Approval"
```
### 2. Verify Dependencies
```
Use Read tool:
Path: .claude/specs/{feature}/03-sprint-plan.md
Check dependencies:
- All dependency stories must be in DONE state
- If dependencies not met, block approval and notify user
```
### 3. Verify Single IN PROGRESS Rule
```
Check sprint plan:
- Count stories currently in IN PROGRESS state
- If count > 0, warn user (recommend completing current story first)
- Allow override with explicit confirmation
```
### 4. Update Sprint Plan State Machine
```
Use Edit tool:
Path: .claude/specs/{feature}/03-sprint-plan.md
Changes:
1. Find story in TODO section
2. Move to IN PROGRESS section
3. Update status: "Status: Ready - Approved for Development"
4. Add approval timestamp
Example:
From:
### TODO
- Story-007: User Avatar Upload (Status: Draft - Awaiting Approval)
To:
### IN PROGRESS
- Story-007: User Avatar Upload (Status: Ready - Approved for Development) [Started: 2025-10-20]
```
### 5. Update Workflow Status
```
Use Edit tool:
Path: .claude/workflow-status.md
Update:
- Move story from TODO to IN PROGRESS
- Set current story to Story-{ID}
- Update last modified timestamp
```
### 6. Trigger Story Context Generation (Optional)
Optionally generate story context XML immediately:
```
Use Task tool with bmad-sm-context:
"Generate story context for Story-{ID}
Feature: {feature_name}
Story: {ID}
This story was just approved and is ready for implementation.
Generate focused technical context XML to guide development."
```
### 7. Present Approval Confirmation
```markdown
# Story Approved ✓
**Story**: Story-{ID} - {Title}
**Epic**: {Epic name}
**State**: IN PROGRESS (Ready for Development)
**Approved**: {timestamp}
## Story Summary
{1-2 sentence summary}
## Next Steps
### Option 1: Generate Story Context (Recommended)
Create focused technical guidance for efficient implementation:
```bash
/bmad-sm-context {ID}
```
Then implement:
```bash
/bmad-dev-story {ID}
```
### Option 2: Direct Implementation
Skip context generation and implement directly:
```bash
/bmad-dev-story {ID}
```
### Option 3: Review Before Implementation
Review story draft one more time:
```bash
# View: .claude/specs/{feature}/story-{ID}-draft.md
```
---
## Story Details
**Estimated Effort**: {X} points ({Y} hours)
**Acceptance Criteria**: {Z} criteria defined
**Dependencies**: {All met ✓}
**Sprint Plan Status**:
- BACKLOG: {X} stories
- TODO: {Y} stories
- IN PROGRESS: 1 story (Story-{ID}) ← Current
- DONE: {Z} stories
---
*Story moved from TODO → IN PROGRESS*
*Ready for development!*
```
## Approval Validations
### Dependency Check
Before approval, verify all dependencies complete:
```markdown
⚠️ **Dependency Check**
Story-{ID} depends on:
- Story-{X}: {Status}
- Story-{Y}: {Status}
**Recommendation**:
{If all DONE: "All dependencies met ✓ - Safe to proceed"}
{If any not DONE: "❌ Blocked - Complete dependencies first"}
```
### Concurrent Work Warning
If another story is IN PROGRESS:
```markdown
⚠️ **Multiple Stories in Progress**
**Currently IN PROGRESS**:
- Story-{X}: {Title} (started {date})
**Recommended Practice**: Complete one story at a time for better focus.
**Options**:
1. **Recommended**: Complete Story-{X} first, then approve Story-{ID}
2. **Override**: Approve Story-{ID} anyway (parallel work)
Reply 'complete-first' or 'approve-anyway'
```
## Approval Gates
### Critical Checks Before Approval
1. **Story Draft Quality**
- [ ] Acceptance criteria defined (3-5 criteria)
- [ ] Technical implementation specified
- [ ] Testing requirements included
- [ ] Dependencies identified
2. **Prerequisites Met**
- [ ] All dependency stories in DONE state
- [ ] Required infrastructure ready
- [ ] No blockers identified
3. **Capacity Check**
- [ ] No other story currently IN PROGRESS (or approved for parallel)
- [ ] Estimated effort reasonable (< 40 hours)
- [ ] Resources available
### Auto-Approval Criteria
Can skip user confirmation if:
- Story is simple (≤ 3 points)
- No dependencies
- No other story IN PROGRESS
- Clear acceptance criteria
Otherwise, require explicit user approval.
## Error Handling
### Story Not in TODO
```markdown
❌ **Error**: Story-{ID} not in TODO state
**Current State**: {BACKLOG|IN PROGRESS|DONE}
**Resolution**:
- BACKLOG: Draft story first with `/bmad-sm-draft-story {ID}`
- IN PROGRESS: Already approved, use `/bmad-dev-story {ID}` to implement
- DONE: Already completed, no action needed
```
### Dependencies Not Met
```markdown
❌ **Approval Blocked**: Dependencies not complete
**Story-{ID} depends on**:
- Story-{X}: {current_state} (Required: DONE)
- Story-{Y}: {current_state} (Required: DONE)
**Resolution**:
1. Complete dependencies first:
- `/bmad-sm-approve-story {X}` (if in TODO)
- `/bmad-dev-story {X}` (if in IN PROGRESS)
2. Then return to approve Story-{ID}
**Alternative**: Remove dependencies if they're not actually required (edit sprint plan)
```
### Story Draft Missing
```markdown
❌ **Error**: Story draft not found
**Expected**: `.claude/specs/{feature}/story-{ID}-draft.md`
**Resolution**:
Re-draft story: `/bmad-sm-draft-story {ID}`
```
## Integration with Development
### Post-Approval Workflow
```
Approval → Story Context → Implementation → Completion
1. /bmad-sm-approve-story {ID}
↓
2. /bmad-sm-context {ID} (optional but recommended)
↓
3. /bmad-dev-story {ID}
↓
4. /bmad-dev-complete-story {ID}
```
### Story Context Generation
After approval, story context XML can be generated:
**Benefits of generating context**:
- 70-80% reduction in context tokens for dev
- Focused implementation guidance
- Consistent patterns across stories
- Better adherence to architecture
**When to skip context**:
- Very simple stories (≤ 2 points)
- Developer very familiar with codebase
- Time-critical implementation
## State Transition Rules
### Valid Transitions
- TODO → IN PROGRESS (this command)
- IN PROGRESS → DONE (via /bmad-dev-complete-story)
- IN PROGRESS → TODO (if story needs rework)
### Invalid Transitions
- BACKLOG → IN PROGRESS (must go through TODO)
- TODO → DONE (must implement first)
- DONE → IN PROGRESS (completed stories don't reopen)
## Success Criteria
- Story dependencies verified and met
- Story moved from TODO to IN PROGRESS in sprint plan
- Workflow status updated
- Approval timestamp recorded
- User provided clear next steps
- Single story in progress (or approval for parallel work)
## Example Output
```markdown
# Story Approved ✓
**Story**: Story-007 - User Avatar Upload
**Epic**: User Profile Management
**State**: IN PROGRESS (Ready for Development)
**Approved**: 2025-10-20 14:30:00
## Story Summary
Enable users to upload and manage profile avatars with automatic image optimization and validation.
## Next Steps
### Option 1: Generate Story Context (Recommended)
Create focused technical guidance for efficient implementation:
```bash
/bmad-sm-context 007
```
Then implement:
```bash
/bmad-dev-story 007
```
### Option 2: Direct Implementation
Skip context generation and implement directly:
```bash
/bmad-dev-story 007
```
---
## Story Details
**Estimated Effort**: 8 points (12 hours)
**Acceptance Criteria**: 5 criteria defined
**Dependencies**: All met ✓
- Story-005 (User Profile API): DONE ✓
- Story-006 (S3 Integration): DONE ✓
**Sprint Plan Status**:
- BACKLOG: 12 stories
- TODO: 3 stories
- IN PROGRESS: 1 story (Story-007) ← Current
- DONE: 5 stories
---
*Story moved from TODO → IN PROGRESS*
*Ready for development! Generate context for best results.*
```
## Approval Undo
### Unapprove Story (Move Back to TODO)
If user wants to unapprove:
```bash
/bmad-sm-unapprove-story {ID}
```
This would move story from IN PROGRESS back to TODO if:
- No implementation has started yet
- Story context not generated yet
- User wants to refine requirements
## Metrics Tracking
Track approval metrics:
- Time from BACKLOG → TODO (drafting time)
- Time from TODO → IN PROGRESS (review time)
- Time from IN PROGRESS → DONE (implementation time)
- Dependency chain length
- Stories blocked by dependencies
This data feeds into sprint retrospectives for process improvement.

381
bmad-agile-workflow/commands/bmad-sm-context.md
View File

@@ -1,381 +0,0 @@
## Usage
`/bmad-sm-context <STORY_ID>`
## Context
- Feature name: {Detected from .claude/workflow-status.md or current working directory}
- Story to analyze: $ARGUMENTS (e.g., "Story-003" or "003")
- Generate focused technical context for story implementation
- Reduce context window usage for dev agent
- Ensure consistent technical patterns
## Your Role
You are the Story Context Generator, responsible for creating targeted technical guidance for individual story implementation. You extract relevant information from PRD, architecture, and repository context to provide focused implementation guidance.
## Input Requirements
### Required Files
- `.claude/specs/{feature}/01-product-requirements.md` - Product requirements
- `.claude/specs/{feature}/02-system-architecture.md` - System architecture
- `.claude/specs/{feature}/03-sprint-plan.md` - Sprint plan with story details
- `.claude/specs/{feature}/00-repo-scan.md` - Repository context (optional)
### Required Arguments
- `STORY_ID`: Story identifier from sprint plan (e.g., "Story-003" or "003")
## Execution Process
### 1. Parse Story ID
```
Input: $ARGUMENTS
Extract: Story number (001, 002, etc.)
Validate: Story exists in sprint plan
```
### 2. Read Source Artifacts
```
Use Read tool to load:
1. Sprint plan → Extract target story details:
- Story title and description
- Acceptance criteria
- Dependencies
- Technical notes
- Estimated complexity
2. Architecture → Extract relevant sections:
- Components involved in this story
- API endpoints affected
- Data models needed
- Integration points
- Security considerations
3. PRD → Extract relevant requirements:
- User needs addressed
- Success metrics
- Business rules
- Constraints
4. Repository scan → Extract patterns:
- Similar existing implementations
- Code conventions to follow
- Libraries/frameworks to use
```
### 3. Generate Story Context XML
Create focused technical context file:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<story-context>
<metadata>
<story-id>{story_id}</story-id>
<story-title>{title}</story-title>
<feature>{feature_name}</feature>
<complexity>{simple|medium|complex}</complexity>
<generated>{timestamp}</generated>
</metadata>
<requirements>
<user-need>
{What user problem this solves}
</user-need>
<acceptance-criteria>
<criterion id="1">{criterion_1}</criterion>
<criterion id="2">{criterion_2}</criterion>
</acceptance-criteria>
<business-rules>
<rule>{rule_1}</rule>
<rule>{rule_2}</rule>
</business-rules>
</requirements>
<technical-guidance>
<components>
<component name="{component_1}">
<location>{file_path}</location>
<responsibility>{what_it_does}</responsibility>
<changes-required>{what_to_modify}</changes-required>
</component>
</components>
<api-endpoints>
<endpoint method="{GET|POST|PUT|DELETE}" path="{/api/path}">
<purpose>{what_it_does}</purpose>
<request-schema>{schema_or_type}</request-schema>
<response-schema>{schema_or_type}</response-schema>
<error-handling>{error_cases}</error-handling>
</endpoint>
</api-endpoints>
<data-models>
<model name="{ModelName}">
<fields>
<field name="{field_name}" type="{type}" required="{true|false}">
{description}
</field>
</fields>
<relationships>
{relationships_to_other_models}
</relationships>
<validation>
{validation_rules}
</validation>
</model>
</data-models>
<integration-points>
<integration type="{database|api|service|library}">
<description>{what_to_integrate}</description>
<existing-pattern>{how_similar_integrations_work}</existing-pattern>
<configuration>{config_needed}</configuration>
</integration>
</integration-points>
<security-considerations>
<authentication>{auth_requirements}</authentication>
<authorization>{permission_requirements}</authorization>
<data-protection>{encryption|sanitization}</data-protection>
<input-validation>{validation_requirements}</input-validation>
</security-considerations>
<performance-requirements>
<response-time>{target_time}</response-time>
<throughput>{requests_per_second}</throughput>
<optimization-hints>
{caching_indexing_strategies}
</optimization-hints>
</performance-requirements>
</technical-guidance>
<implementation-patterns>
<existing-examples>
<example file="{path/to/similar/code.ext}">
<description>{what_this_example_shows}</description>
<key-patterns>{patterns_to_replicate}</key-patterns>
</example>
</existing-examples>
<code-conventions>
<convention category="{naming|structure|style}">
{convention_description}
</convention>
</code-conventions>
<libraries-to-use>
<library name="{library_name}" purpose="{what_for}">
{usage_example}
</library>
</libraries-to-use>
<testing-requirements>
<test-type type="{unit|integration|e2e}">
<coverage>{what_to_test}</coverage>
<framework>{test_framework_to_use}</framework>
<patterns>{existing_test_patterns}</patterns>
</test-type>
</testing-requirements>
</implementation-patterns>
<dependencies>
<story-dependencies>
<depends-on story-id="{Story-XXX}">
{why_this_dependency}
</depends-on>
</story-dependencies>
<external-dependencies>
<dependency type="{api|service|library}">
{what_needs_to_be_ready}
</dependency>
</external-dependencies>
</dependencies>
<quality-checklist>
<checklist-item category="{functionality|security|performance|maintainability}">
{what_to_verify}
</checklist-item>
</quality-checklist>
<related-artifacts>
<artifact type="{prd|architecture|sprint-plan}">
<path>{./.claude/specs/{feature}/...}</path>
<relevant-sections>
{specific_sections_to_reference}
</relevant-sections>
</artifact>
</related-artifacts>
</story-context>
```
### 4. Save Context File
```
Use Write tool:
Path: .claude/specs/{feature}/story-{story_id}-context.xml
Content: Generated XML context
```
### 5. Report Summary
Return concise summary:
```markdown
# Story Context Generated
**Story**: {story_id} - {title}
**Complexity**: {complexity_level}
**Context File**: `.claude/specs/{feature}/story-{story_id}-context.xml`
## Key Implementation Points
- Components: {component_list}
- API Endpoints: {endpoint_count}
- Data Models: {model_count}
- Dependencies: {dependency_count}
## Quick Start for Dev
1. Read context: `.claude/specs/{feature}/story-{story_id}-context.xml`
2. Implement according to technical guidance
3. Follow existing patterns from similar code
4. Validate against acceptance criteria
**Ready for**: `/bmad-dev-story {story_id}`
```
## Context Generation Strategy
### Information Extraction Priorities
**High Priority** (Always include):
- Acceptance criteria (must-implement)
- Components to modify (where to code)
- API contracts (interfaces)
- Security requirements (critical)
- Dependencies (blockers)
**Medium Priority** (Include if available):
- Existing code examples (helpful patterns)
- Performance requirements (optimization targets)
- Integration patterns (how to connect)
- Testing requirements (quality gates)
**Low Priority** (Include if relevant):
- Business context (why we're doing this)
- User journey (contextual understanding)
- Future considerations (extensibility hints)
### Context Optimization
To minimize context window usage:
1. **Extract Only Relevant Sections**
- Don't copy entire PRD → Extract only relevant user stories
- Don't copy entire architecture → Extract only affected components
- Don't copy entire repo scan → Extract only similar implementations
2. **Summarize Background**
- Condense business context into 2-3 sentences
- Reference full docs with section markers
3. **Focus on Actionable Information**
- Prefer "Create POST /api/users endpoint" over "The system needs user management"
- Include specific file paths, function names, patterns
4. **Use Examples Over Descriptions**
- Show code snippets from existing implementations
- Link to similar stories/components
## Error Handling
### Story Not Found
```markdown
❌ **Error**: Story "{story_id}" not found in sprint plan
**Available Stories**:
{List stories from sprint plan}
**Usage**: `/bmad-sm-context <STORY_ID>`
```
### Missing Artifacts
```markdown
❌ **Error**: Required artifacts not found
**Missing Files**:
- {missing_file_1}
- {missing_file_2}
**Resolution**: Run `/bmad-pilot` to generate required artifacts first
```
### Invalid Story State
```markdown
⚠️ **Warning**: Story "{story_id}" is in "{state}" state
**Current State**: {BACKLOG|TODO|IN_PROGRESS|DONE}
**Recommendation**:
- BACKLOG: Move to TODO with `/bmad-sm-draft-story {story_id}` first
- IN_PROGRESS: Context already exists, use existing file
- DONE: Story already completed, context may be outdated
```
## Integration with Dev Workflow
### Usage in bmad-dev-story
The dev agent should:
1. Check for story context file first
2. If exists: Read context XML for focused guidance
3. If not exists: Fall back to reading all artifacts (PRD + Architecture + Sprint Plan)
**Benefits**:
- 70-80% reduction in context tokens
- Faster reasoning (focused information)
- More consistent implementations (guided patterns)
- Better adherence to architecture (explicit integration points)
### Context Refresh
Context should be regenerated if:
- Architecture document updated after context creation
- Dependencies changed (other stories modified interfaces)
- Repository patterns evolved (new conventions adopted)
## Success Criteria
- Story context XML generated successfully
- File saved to correct location
- All acceptance criteria captured
- Technical guidance is actionable (file paths, specific changes)
- Relevant code examples identified
- Security/performance requirements included
- Context is focused (< 5000 tokens typical)
## Example Output
```markdown
# Story Context Generated ✓
**Story**: Story-003 - User Profile Editing
**Complexity**: Medium
**Context File**: `.claude/specs/user-management/story-003-context.xml`
## Key Implementation Points
- Components: UserProfileController, UserService, ProfileValidator
- API Endpoints: 2 (GET /api/users/:id, PUT /api/users/:id)
- Data Models: User (extend with profile_data field)
- Dependencies: Story-001 (User authentication must be complete)
## Technical Highlights
- Follow existing pattern in `src/controllers/authController.js`
- Use `Joi` for validation (see `src/validators/userValidator.js`)
- Implement optimistic locking for concurrent updates
- Add unit tests following `tests/controllers/auth.test.js` pattern
## Security Requirements
- Verify user owns profile before update (authorization)
- Sanitize all input fields (XSS prevention)
- Validate email format and uniqueness
- Rate limit: 10 updates per user per hour
**Ready for**: `/bmad-dev-story Story-003`
---
*Context generated in 2.3s | 3,847 tokens | Valid until architecture update*
```

398
bmad-agile-workflow/commands/bmad-sm-draft-story.md
View File

@@ -1,398 +0,0 @@
## Usage
`/bmad-sm-draft-story <STORY_ID>`
## Context
- Story state machine transition: BACKLOG → TODO
- Generate detailed story draft ready for user approval
- Feature detected from .claude/workflow-status.md
- Part of 4-state story lifecycle
## Your Role
You are the Story Drafter, responsible for moving stories from BACKLOG to TODO state by creating detailed story specifications ready for development approval.
## Story State Machine
```
BACKLOG → TODO → IN PROGRESS → DONE
↑ ↑ ↑ ↑
| | | |
Planned Drafted Approved Completed
```
### State Definitions
**BACKLOG**: Ordered list of stories to be drafted
- Status: Planned but not detailed
- Action needed: Draft story details
**TODO**: Single story ready for drafting (or drafted, awaiting approval)
- Status: Detailed specification created
- Action needed: User review and approval
**IN PROGRESS**: Single story approved for development
- Status: Currently being implemented
- Action needed: Development and testing
**DONE**: Completed stories with dates and points
- Status: Implementation complete, tested, reviewed
- Action needed: None (archived)
## Execution Process
### 1. Validate Story ID
```
Input: $ARGUMENTS (e.g., "Story-003" or "003")
Extract: Story number
Validate: Story exists in sprint plan BACKLOG section
Check: Story not already in TODO, IN PROGRESS, or DONE
```
### 2. Read Sprint Plan
```
Use Read tool:
Path: .claude/specs/{feature}/03-sprint-plan.md
Extract:
- Story title and description from BACKLOG
- Epic association
- Initial estimate
- Dependencies
```
### 3. Read Context Documents
```
Use Read tool:
Paths:
- .claude/specs/{feature}/01-product-requirements.md (user needs)
- .claude/specs/{feature}/02-system-architecture.md (technical context)
- .claude/specs/{feature}/00-repo-scan.md (implementation patterns)
```
### 4. Generate Detailed Story Specification
Create comprehensive story draft:
```markdown
## Story-{ID}: {Title}
**Epic**: {Epic name}
**State**: TODO (Draft - Awaiting Approval)
**Estimated Points**: {X}
**Dependencies**: {Story-XXX, Story-YYY or None}
**Priority**: {High|Medium|Low}
### User Story
As a {user_type}
I want {functionality}
So that {business_value}
### Description
{Detailed description of what needs to be implemented, 2-3 paragraphs}
### Acceptance Criteria
- [ ] {Specific, testable criterion 1}
- [ ] {Specific, testable criterion 2}
- [ ] {Specific, testable criterion 3}
- [ ] {Specific, testable criterion 4}
### Technical Implementation Notes
#### Components to Modify/Create
- **{Component 1}** ({path/to/file}): {What to do}
- **{Component 2}** ({path/to/file}): {What to do}
#### API Changes (if applicable)
- **Endpoint**: {METHOD} {/api/path}
- Request: {schema}
- Response: {schema}
#### Database Changes (if applicable)
- **Table**: {table_name}
- Changes: {what_to_modify}
#### Integration Points
- {Integration 1}: {How to connect}
- {Integration 2}: {How to connect}
### Implementation Steps
1. {Step 1}
2. {Step 2}
3. {Step 3}
### Testing Requirements
#### Unit Tests
- {Test case 1}
- {Test case 2}
#### Integration Tests
- {Test case 1}
#### Manual Testing
- [ ] {Manual test scenario 1}
- [ ] {Manual test scenario 2}
### Edge Cases & Error Handling
- **Edge Case 1**: {Scenario} → {Expected behavior}
- **Error Condition 1**: {Condition} → {Error handling}
### Definition of Done
- [ ] Code implemented following conventions
- [ ] Unit tests written and passing (>80% coverage)
- [ ] Integration tests passing
- [ ] Code reviewed and approved
- [ ] Acceptance criteria validated
- [ ] Documentation updated
- [ ] No new warnings or errors
### Dependencies
**Depends On**:
- {Story-XXX}: {Why this dependency}
**Blocks**:
- {Story-YYY}: {What this story provides}
### Estimated Effort
- **Story Points**: {X}
- **Time Estimate**: {Y hours}
- **Confidence**: {High|Medium|Low}
### Risks
- **{Risk 1}**: {Description} (Mitigation: {strategy})
### References
- PRD Section: {Section reference}
- Architecture Section: {Section reference}
- Similar Implementation: {path/to/example}
---
*Story drafted by bmad-sm-draft-story*
*Ready for user approval to move to IN PROGRESS*
```
### 5. Update Sprint Plan State Machine
```
Use Edit tool:
Path: .claude/specs/{feature}/03-sprint-plan.md
Change:
Find story in BACKLOG section
Move to TODO section with "Status: Draft - Awaiting Approval"
Example:
From:
### BACKLOG
- Story-003: User Profile Edit
To:
### TODO
- Story-003: User Profile Edit (Status: Draft - Awaiting Approval)
Also update the detailed story section in sprint plan with full specification
```
### 6. Save Story Draft
```
Use Write tool:
Path: .claude/specs/{feature}/story-{ID}-draft.md
Content: Detailed story specification
```
### 7. Update Workflow Status
```
Use Edit tool:
Path: .claude/workflow-status.md
Update story state section:
Move story from BACKLOG to TODO
```
### 8. Present Draft to User
```markdown
# Story Draft Complete ✓
**Story**: Story-{ID} - {Title}
**Epic**: {Epic name}
**State**: TODO (Awaiting Approval)
**Estimated Effort**: {X} points ({Y} hours)
## Summary
{1-2 sentence summary of story}
## Acceptance Criteria
- {Criterion 1}
- {Criterion 2}
- {Criterion 3}
## Implementation Approach
{2-3 sentence summary of technical approach}
**Components**: {X} components affected
**API Changes**: {Y} endpoints
**Tests Required**: {Z} test cases
---
**🛑 User Approval Required**
**Review Draft**:
`.claude/specs/{feature}/story-{ID}-draft.md`
**Approve Story**:
```bash
/bmad-sm-approve-story {ID}
```
This will move the story to IN PROGRESS and start implementation.
**Adjust Story**:
Provide feedback for refinement, then re-run `/bmad-sm-draft-story {ID}`
**Dependencies**:
{List dependencies if any - these must be completed first}
---
*Story moved from BACKLOG → TODO*
*Awaiting your approval to begin development*
```
## Story Draft Quality Criteria
### Good Story Draft Checklist
- [ ] Clear user value (As a... I want... So that...)
- [ ] 3-5 specific, testable acceptance criteria
- [ ] Technical implementation is actionable (file paths, specific changes)
- [ ] Edge cases and error handling defined
- [ ] Testing requirements specified
- [ ] Dependencies identified
- [ ] Estimated appropriately (4-40 hours)
- [ ] References to PRD/Architecture included
## Error Handling
### Story Not in BACKLOG
```markdown
❌ **Error**: Story-{ID} not found in BACKLOG
**Current State**: {current_state}
**Resolution**:
- If in TODO: Already drafted, use `/bmad-sm-approve-story {ID}`
- If in IN PROGRESS: Already being developed
- If in DONE: Already completed
- If not exists: Check story ID in sprint plan
```
### Missing Prerequisites
```markdown
❌ **Error**: Cannot draft story - missing dependencies
**Dependency Status**:
- Story-{X}: {BACKLOG|TODO|IN PROGRESS} (must be DONE)
**Recommendation**:
Complete dependency first: `/bmad-sm-draft-story {X}`
Then return to: `/bmad-sm-draft-story {ID}`
```
### Story Already Drafted
```markdown
⚠️ **Warning**: Story-{ID} already in TODO state
**Current Status**: {Status description}
**Options**:
- Approve existing draft: `/bmad-sm-approve-story {ID}`
- Re-draft with updates: Continue with current command
- View draft: `.claude/specs/{feature}/story-{ID}-draft.md`
```
## Integration with Story Context
### Relationship to /bmad-sm-context
**Draft Story** (this command):
- Moves story BACKLOG → TODO
- Creates detailed specification
- Focuses on WHAT to build
**Story Context** (/bmad-sm-context):
- Called after approval (IN PROGRESS state)
- Creates implementation guidance (XML)
- Focuses on HOW to build
**Workflow**:
```
1. /bmad-sm-draft-story {ID} → Creates draft (BACKLOG → TODO)
2. User approves → Story moves to IN PROGRESS
3. /bmad-sm-context {ID} → Creates context XML
4. /bmad-dev-story {ID} → Implements story
```
## Success Criteria
- Story specification created with all required sections
- Story moved from BACKLOG to TODO in sprint plan
- Story draft file saved
- Workflow status updated
- User presented with clear approval options
- Quality criteria met
## Example Output
```markdown
# Story Draft Complete ✓
**Story**: Story-007 - User Avatar Upload
**Epic**: User Profile Management
**State**: TODO (Awaiting Approval)
**Estimated Effort**: 8 points (12 hours)
## Summary
Enable users to upload and manage profile avatars with automatic image optimization and validation.
## Acceptance Criteria
- User can upload image files (JPG, PNG) up to 5MB
- Image automatically resized to 300x300px
- Preview shown before confirmation
- Old avatar deleted when new one uploaded
- Avatar displayed across all user interactions
## Implementation Approach
Create AvatarUpload component using existing ImageUpload pattern from repository. Add POST /api/users/avatar endpoint with multipart form handling. Store avatars in S3 (existing integration). Update User model to include avatar_url field.
**Components**: 3 components (AvatarUpload UI, AvatarController API, AvatarService storage)
**API Changes**: 2 endpoints (POST /api/users/avatar, DELETE /api/users/avatar)
**Tests Required**: 8 test cases (upload validation, resize, delete, error handling)
---
**🛑 User Approval Required**
**Review Draft**:
`.claude/specs/user-profile/story-007-draft.md`
**Approve Story**:
```bash
/bmad-sm-approve-story 007
```
This will move the story to IN PROGRESS and start implementation.
**Dependencies**:
- Story-005 (User Profile API): DONE ✓
- Story-006 (S3 Integration): DONE ✓
---
*Story moved from BACKLOG → TODO*
*Awaiting your approval to begin development*
```

431
bmad-agile-workflow/commands/code-spec.md
View File

@@ -1,431 +0,0 @@
## Usage
`/code-spec <DESCRIPTION>`
## Context
- Scale-adaptive workflow for Level 0-1 projects
- Fast path for simple changes and small features
- Bypasses PRD and full architecture phases
- Direct to technical specification and implementation
## Your Role
You are the Code-Spec Orchestrator for lightweight development. You handle Level 0-1 projects that don't require full BMAD workflow overhead. You create focused technical specifications and coordinate quick implementation.
## Scale Classification
### Level 0: Single Atomic Change
- **Scope**: 1 file, < 50 lines of code
- **Examples**: Bug fix, config update, log statement, version bump
- **Time**: < 1 hour
- **Process**: Tech spec only → Implement
### Level 1: Small Feature
- **Scope**: 1-10 stories, 2-5 files, single epic
- **Examples**: New button, simple form, single endpoint, UI component
- **Time**: 1-2 days
- **Process**: Tech spec → 2-3 stories → Implement
## Workflow Overview
```
1. Classify complexity (Level 0 vs Level 1)
2. Generate technical specification
3. Create minimal story breakdown (Level 1 only)
4. Implement directly
5. Quick review and test
```
## Execution Process
### 1. Complexity Classification
Analyze $ARGUMENTS to determine Level 0 or Level 1:
**Level 0 Indicators**:
- Keywords: "fix", "update", "change", "add log", "bump version"
- Scope: Single responsibility, one component
- Impact: Isolated change, no integration
**Level 1 Indicators**:
- Keywords: "add feature", "new endpoint", "create form", "implement button"
- Scope: Multiple related changes, 2-5 files
- Impact: May require tests, documentation
If complexity exceeds Level 1, recommend full workflow:
```markdown
⚠️ **Project Too Complex for /code-spec**
This appears to be a Level 2+ project requiring:
- Multiple epics or 10+ stories
- Architectural decisions
- Cross-system integration
**Recommended Command**: `/bmad-pilot {description}`
This will provide proper PRD, architecture, and sprint planning.
```
### 2. Generate Technical Specification
Create lightweight tech spec:
```markdown
# Technical Specification: {Feature Name}
**Level**: {0|1}
**Type**: {Bug Fix|Feature|Enhancement|Refactor}
**Estimated Time**: {X hours}
**Generated**: {timestamp}
---
## Objective
{Clear statement of what needs to be done in 1-2 sentences}
---
## Technical Approach
### Changes Required
#### File: {file_path_1}
- **Action**: {Create|Modify|Delete}
- **Changes**:
- {Change 1}
- {Change 2}
#### File: {file_path_2}
- **Action**: {Create|Modify|Delete}
- **Changes**:
- {Change 1}
### Implementation Steps
1. **Step 1**: {Description}
- {Detail}
2. **Step 2**: {Description}
- {Detail}
### Technology Stack
- **Language/Framework**: {detected_from_repo}
- **Libraries**: {required_libraries}
- **Tools**: {build_test_tools}
---
## Acceptance Criteria
- [ ] {Criterion 1}
- [ ] {Criterion 2}
- [ ] {Criterion 3}
---
## Testing Requirements
### Test Cases
1. **{Test scenario 1}**
- Input: {input}
- Expected: {output}
2. **{Test scenario 2}**
- Input: {input}
- Expected: {output}
### Test Execution
- **Unit Tests**: {required|not_required}
- **Integration Tests**: {required|not_required}
- **Manual Testing**: {steps}
---
## Implementation Notes
### Existing Patterns to Follow
- {Pattern or example from codebase}
### Potential Issues
- {Issue 1 and mitigation}
- {Issue 2 and mitigation}
### References
- Related file: {file_path}
- Similar implementation: {example_location}
---
## Story Breakdown (Level 1 Only)
### Story-001: {Story Title}
**Estimated Time**: {X hours}
**Description**: {What to do}
**Acceptance Criteria**:
- [ ] {Criterion 1}
- [ ] {Criterion 2}
### Story-002: {Story Title}
**Estimated Time**: {X hours}
**Description**: {What to do}
**Acceptance Criteria**:
- [ ] {Criterion 1}
---
## Quality Checklist
- [ ] Code follows existing conventions
- [ ] Tests added/updated
- [ ] Documentation updated (if needed)
- [ ] No breaking changes
- [ ] Error handling included
- [ ] Edge cases covered
---
*Specification generated by /code-spec (Level {0|1} workflow)*
```
### 3. Save Technical Specification
```
Use Write tool:
For Level 0-1, use simplified path:
Path: .claude/specs/{feature_name}/tech-spec.md
Content: Generated technical specification
Also create minimal workflow status:
Path: .claude/workflow-status.md
Content:
---
# Workflow Status
**Feature**: {feature_name}
**Level**: {0|1}
**Workflow**: code-spec (lightweight)
**State**: Specification Complete
**Started**: {timestamp}
## Progress
- [x] Technical Specification
- [ ] Implementation
- [ ] Testing
**Next Action**: Implement according to tech-spec.md
---
```
### 4. Present Specification to User
```markdown
# Technical Specification Complete ✓
**Feature**: {feature_name}
**Complexity**: Level {0|1} ({time_estimate})
**Specification**: `.claude/specs/{feature_name}/tech-spec.md`
## Summary
{1-2 sentence summary of approach}
## Changes Required
- {File 1}: {Action}
- {File 2}: {Action}
## Implementation Steps
{X} steps identified (see tech-spec.md for details)
## Acceptance Criteria
{X} criteria defined
---
**Ready to implement?**
**Option 1**: Implement now (recommended)
```bash
/code {feature_name}
```
**Option 2**: Review specification first
```bash
# Review: .claude/specs/{feature_name}/tech-spec.md
# Then: /code {feature_name}
```
**Option 3**: Switch to full workflow (if scope increased)
```bash
/bmad-pilot {description}
```
```
### 5. Auto-Implement (Optional)
If user confirms or no response within context, proceed:
```
Use Task tool with bmad-dev agent:
"Implement according to technical specification.
Feature Name: {feature_name}
Tech Spec Path: .claude/specs/{feature_name}/tech-spec.md
Level: {0|1}
Task: Complete implementation
Instructions:
1. Read technical specification
2. Implement all changes as specified
3. Follow existing code patterns
4. Add tests if required
5. Validate acceptance criteria
6. Report completion
No need for full PRD/Architecture - this is a lightweight workflow."
```
## Repository Scanning
### Minimal Scan for Context
Before generating spec, do quick scan:
```
Use Glob and Read tools:
1. Detect project type:
- package.json → Node.js
- go.mod → Go
- requirements.txt → Python
- Cargo.toml → Rust
2. Find similar implementations:
- Search for related files
- Identify patterns to follow
3. Check conventions:
- Naming patterns
- File structure
- Testing approach
Cache to:
.claude/specs/{feature_name}/repo-context.txt (lightweight, not full scan)
```
## Level 0 vs Level 1 Differences
### Level 0 (Atomic Change)
- **Spec**: 1 page, single file focus
- **Stories**: None (direct implementation)
- **Testing**: Manual verification, maybe 1-2 unit tests
- **Review**: Self-review or skip
- **Time**: 30-60 minutes
### Level 1 (Small Feature)
- **Spec**: 2-3 pages, multi-file focus
- **Stories**: 2-3 stories with clear acceptance criteria
- **Testing**: Unit tests required, integration tests recommended
- **Review**: Quick peer review
- **Time**: 1-2 days
## Error Handling
### Project Too Complex
```markdown
⚠️ **Complexity Exceeds Level 1**
Your project appears to require:
- {Reason 1: e.g., Multiple epics}
- {Reason 2: e.g., Architectural decisions}
- {Reason 3: e.g., Cross-system integration}
**Recommended**: Use `/bmad-pilot` for proper planning
**Estimated Level**: 2-3 (requires PRD + Architecture)
```
### Insufficient Information
```markdown
❌ **Insufficient Information**
To generate a technical specification, I need:
- {Missing information 1}
- {Missing information 2}
**Please provide**:
{Specific questions to clarify scope}
**Example**: `/code-spec Add user login with email and password authentication`
```
## Integration with Full Workflow
### Upgrade Path
If project grows during implementation:
```markdown
🔄 **Project Complexity Increased**
Original: Level {0|1}
Current: Level {2|3}
**Recommendation**: Upgrade to full workflow
**Upgrade Command**:
```bash
/bmad-pilot-upgrade {feature_name}
```
This will:
1. Preserve existing work
2. Generate missing artifacts (PRD, Architecture)
3. Continue with proper planning
```
## Success Criteria
- Correct level classification (0 or 1)
- Technical specification generated
- Clear implementation steps
- Acceptance criteria defined
- Repository context understood
- Appropriate file structure created
- Ready for immediate implementation
## Example Output
```markdown
# Technical Specification Complete ✓
**Feature**: Add Debug Logging
**Complexity**: Level 0 (30 minutes)
**Specification**: `.claude/specs/debug-logging/tech-spec.md`
## Summary
Add debug-level logging to authentication middleware for troubleshooting login issues
## Changes Required
- `src/middleware/auth.js`: Add logger.debug() calls at entry and exit
## Implementation Steps
1. Import logger utility
2. Add debug log at middleware entry (log incoming request)
3. Add debug log at middleware exit (log auth result)
4. Test with DEBUG=* environment variable
## Acceptance Criteria
- [x] Debug logs show authentication flow
- [x] Logs include user ID and timestamp
- [x] Logs only active when DEBUG=* set
- [x] No impact on production performance
---
**Ready to implement?**
```bash
/code debug-logging
```
*Estimated time: 30 minutes | No tests required (logging only) | Self-review sufficient*
```

613
bmad-agile-workflow/commands/mini-sprint.md
View File

@@ -1,613 +0,0 @@
## Usage
`/mini-sprint <DESCRIPTION>`
## Context
- Scale-adaptive workflow for Level 1-2 projects
- Medium-complexity path between /code-spec and /bmad-pilot
- Technical specification + lightweight sprint planning
- Bypasses full PRD and architecture documentation
- Ideal for small-to-medium features
## Your Role
You are the Mini-Sprint Orchestrator for medium-complexity projects. You handle Level 1-2 projects that need more structure than /code-spec but less overhead than full BMAD workflow.
## Scale Classification
### Level 1: Small Feature (Lower Range)
- **Scope**: 1-10 stories, single epic, 2-5 files
- **Examples**: Login form, API endpoint set, UI component with state
- **Time**: 1-2 days
- **Process**: Tech spec → 3-5 stories → Implement
### Level 2: Medium Feature
- **Scope**: 5-15 stories, 1-2 epics, 5-15 files
- **Examples**: User profile system, search functionality, notification system
- **Time**: 1-2 weeks
- **Process**: Tech spec → 5-15 stories → Implement → Review → Test
## Workflow Overview
```
1. Classify complexity (Level 1 or Level 2)
2. Quick repository scan (understand existing patterns)
3. Generate technical specification
4. Create lightweight sprint plan (stories with estimates)
5. User approval gate (review and adjust)
6. Orchestrated implementation (Dev → Review → QA)
```
## Execution Process
### 1. Complexity Classification
Analyze $ARGUMENTS to determine Level 1 or Level 2:
**Level 1 Indicators**:
- Single epic
- 1-10 stories
- Minimal integration
- Well-understood patterns
**Level 2 Indicators**:
- 1-2 epics
- 5-15 stories
- Multiple integrations
- Some architectural decisions
If complexity exceeds Level 2, recommend full workflow:
```markdown
⚠️ **Project Too Complex for /mini-sprint**
This appears to be a Level 3+ project requiring:
- {Reason: Multiple epics, cross-system integration, etc.}
**Recommended Command**: `/bmad-pilot {description}`
This will provide:
- Full PRD with user research
- Complete system architecture
- Comprehensive sprint planning
```
### 2. Quick Repository Scan
Perform lightweight repository analysis:
```
Use Task tool with bmad-orchestrator agent:
"Perform quick repository scan for mini-sprint workflow.
Project Description: {$ARGUMENTS}
Focus on:
1. Project type and tech stack
2. Existing similar implementations (find patterns to follow)
3. Key conventions (naming, structure, testing)
4. Integration points
5. Constraints
Output: Quick context summary (1-2 pages max)
Save to: .claude/specs/{feature_name}/quick-scan.md"
```
### 3. Generate Technical Specification
Create focused tech spec:
```
Use Task tool with bmad-architect agent:
"Create lightweight technical specification for mini-sprint workflow.
Project Description: {$ARGUMENTS}
Repository Context: [Include quick scan results]
Feature Name: {feature_name}
Level: {1|2}
Task: Generate focused technical specification
Instructions:
1. Define technical approach (components, APIs, data models)
2. Identify integration points
3. List technology choices
4. Define acceptance criteria
5. Estimate complexity
6. DO NOT create full architecture document (this is lightweight)
Output: Technical specification document
Save to: .claude/specs/{feature_name}/tech-spec.md"
```
**Tech Spec Structure** (Lightweight):
```markdown
# Technical Specification: {Feature Name}
**Level**: {1|2}
**Estimated Time**: {X days}
**Complexity**: {Simple|Medium}
## Overview
{1-2 paragraphs describing what we're building and why}
## Technical Approach
### Components
| Component | Responsibility | Files |
|-----------|----------------|-------|
| {Component1} | {What it does} | {file_path} |
| {Component2} | {What it does} | {file_path} |
### API Endpoints (if applicable)
| Method | Path | Purpose | Request | Response |
|--------|------|---------|---------|----------|
| POST | /api/users | Create user | UserDTO | User |
| GET | /api/users/:id | Get user | - | User |
### Data Models (if applicable)
```typescript
interface User {
id: string;
email: string;
name: string;
createdAt: Date;
}
```
### Integration Points
- {Integration 1}: {How we connect}
- {Integration 2}: {How we connect}
### Technology Decisions
- **{Decision area}**: {Choice} (Reason: {why})
## Implementation Strategy
### Phase 1: {Phase name}
{What to build first}
### Phase 2: {Phase name}
{What to build second}
## Acceptance Criteria
- [ ] {Criterion 1}
- [ ] {Criterion 2}
## Testing Strategy
- **Unit Tests**: {What to test}
- **Integration Tests**: {What to test}
- **Manual Tests**: {What to verify}
## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| {Risk1} | {High|Medium|Low} | {How to handle} |
## References
- Similar implementation: {path}
- Documentation: {link}
```
### 4. Generate Lightweight Sprint Plan
Create story breakdown:
```
Use Task tool with bmad-sm agent:
"Create lightweight sprint plan for mini-sprint workflow.
Feature Name: {feature_name}
Tech Spec Path: .claude/specs/{feature_name}/tech-spec.md
Repository Context: .claude/specs/{feature_name}/quick-scan.md
Level: {1|2}
Task: Generate focused sprint plan with stories
Instructions:
1. Break down into {3-15} user stories
2. Define acceptance criteria per story
3. Estimate story points/hours
4. Identify dependencies
5. Create implementation order
6. DO NOT create full sprint planning artifacts (this is lightweight)
Output: Lightweight sprint plan
Save to: .claude/specs/{feature_name}/sprint-plan.md"
```
**Sprint Plan Structure** (Lightweight):
```markdown
# Sprint Plan: {Feature Name}
**Level**: {1|2}
**Total Stories**: {X}
**Estimated Time**: {Y days}
**Epic**: {Epic name}
## Story Overview
| ID | Story | Points | Dependencies |
|----|-------|--------|--------------|
| 001 | {Story title} | {X} | - |
| 002 | {Story title} | {X} | Story-001 |
## Story Backlog
### Story-001: {Title}
**Estimate**: {X points / Y hours}
**Description**: {What user can do}
**Acceptance Criteria**:
- [ ] {Criterion 1}
- [ ] {Criterion 2}
**Technical Notes**:
- {Implementation hint}
**Dependencies**: None
---
### Story-002: {Title}
**Estimate**: {X points / Y hours}
**Description**: {What user can do}
**Acceptance Criteria**:
- [ ] {Criterion 1}
**Technical Notes**:
- {Implementation hint}
**Dependencies**: Story-001
---
## Implementation Order
1. Story-001 → Story-002 → Story-003
2. Story-004 → Story-005 (parallel)
3. Story-006 (integration)
## Story State Tracking
### BACKLOG
- Story-001: {Title}
- Story-002: {Title}
- Story-003: {Title}
### TODO
(Empty - will be populated as stories are drafted)
### IN PROGRESS
(Empty - will be populated during implementation)
### DONE
(Empty - will be populated as stories complete)
## Risk Register
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| {Risk} | {Low|Med|High} | {Low|Med|High} | {Strategy} |
## Definition of Done
- [ ] Code implemented and follows conventions
- [ ] Unit tests pass (>80% coverage)
- [ ] Integration tests pass
- [ ] Code review approved
- [ ] QA testing complete
- [ ] Documentation updated
*Sprint plan for mini-sprint workflow (Level {1|2})*
```
### 5. Create Workflow Status
```
Use Write tool:
Path: .claude/workflow-status.md
Content:
---
# Workflow Status
**Feature**: {feature_name}
**Level**: {1|2}
**Workflow**: mini-sprint (medium complexity)
**State**: Planning Complete - Awaiting Approval
**Started**: {timestamp}
## Progress
- [x] Quick Repository Scan
- [x] Technical Specification
- [x] Sprint Planning
- [ ] User Approval
- [ ] Implementation
- [ ] Code Review
- [ ] QA Testing
## Story State
### BACKLOG
{List stories}
### TODO
(Empty)
### IN PROGRESS
(Empty)
### DONE
(Empty)
## Next Action
Review sprint plan and approve to begin implementation
**Approve Command**: Reply 'yes' to begin implementation
**Adjust Command**: Provide feedback for refinement
---
```
### 6. Present Plan to User (Approval Gate)
```markdown
# Mini-Sprint Plan Ready ✓
**Feature**: {feature_name}
**Complexity**: Level {1|2}
**Estimated Time**: {X days}
## Deliverables Created
✓ Quick repository scan: `.claude/specs/{feature_name}/quick-scan.md`
✓ Technical specification: `.claude/specs/{feature_name}/tech-spec.md`
✓ Sprint plan: `.claude/specs/{feature_name}/sprint-plan.md`
## Technical Approach Summary
{2-3 sentence summary of approach}
**Components**: {X}
**API Endpoints**: {Y}
**Stories**: {Z}
## Story Breakdown
| ID | Story | Estimate |
|----|-------|----------|
| 001 | {Title} | {X}h |
| 002 | {Title} | {X}h |
| ... | ... | ... |
**Total Estimate**: {X} hours ({Y} days)
## Implementation Order
1. {Phase 1}: Stories 001-003
2. {Phase 2}: Stories 004-006
3. {Phase 3}: Story 007 (integration)
---
**🛑 Approval Required**
**Ready to start implementation?**
- Reply **'yes'** to begin development
- Reply **'adjust'** to refine the plan
- Reply **'upgrade'** to switch to full /bmad-pilot workflow
**Review Plans**:
- Tech Spec: `.claude/specs/{feature_name}/tech-spec.md`
- Sprint Plan: `.claude/specs/{feature_name}/sprint-plan.md`
```
### 7. Wait for User Approval
**CRITICAL**: Must stop here and wait for user response
Acceptable approval responses:
- "yes", "是", "确认", "继续", "start", "begin", "go"
If approved → Proceed to Phase 8
If adjustment requested → Refine plan with user feedback
If upgrade requested → Transfer to /bmad-pilot
### 8. Orchestrated Implementation (After Approval)
#### 8a. Development Phase
```
Use Task tool with bmad-dev agent:
Feature Name: {feature_name}
Tech Spec Path: .claude/specs/{feature_name}/tech-spec.md
Sprint Plan Path: .claude/specs/{feature_name}/sprint-plan.md
Repository Context: .claude/specs/{feature_name}/quick-scan.md
Task: Implement all stories according to sprint plan
Instructions:
1. Implement stories in order (follow dependencies)
2. Update story state (BACKLOG → TODO → IN PROGRESS → DONE)
3. Create production-ready code with tests
4. Follow existing patterns from repository scan
5. Report completion per story
This is a mini-sprint workflow - focus on implementation efficiency.
```
#### 8b. Code Review Phase
```
Use Task tool with bmad-review agent:
Feature Name: {feature_name}
Review Context: Tech spec + Sprint plan
Task: Conduct code review
Instructions:
1. Review implementation against tech spec
2. Verify acceptance criteria met
3. Check code quality and patterns
4. Generate review report
Save to: .claude/specs/{feature_name}/review-report.md
```
#### 8c. QA Testing Phase (Level 2 only)
```
Use Task tool with bmad-qa agent:
Feature Name: {feature_name}
Test Context: Tech spec + Sprint plan
Task: Execute testing
Instructions:
1. Run all tests (unit, integration)
2. Validate acceptance criteria
3. Perform manual testing if needed
4. Report results
Save to: .claude/specs/{feature_name}/qa-report.md
```
### 9. Completion Report
```markdown
# Mini-Sprint Complete ✓
**Feature**: {feature_name}
**Duration**: {X days} (estimated: {Y days})
**Stories Completed**: {Z}/{Z}
## Deliverables
✓ Technical Specification
✓ Sprint Plan ({X} stories)
✓ Implementation (all stories done)
✓ Code Review (passed)
✓ QA Testing ({pass_rate}%)
## Story Completion
| Story | Status | Time |
|-------|--------|------|
| 001: {Title} | ✓ Done | {X}h |
| 002: {Title} | ✓ Done | {X}h |
## Quality Metrics
- **Code Review**: {pass|pass_with_comments|fail}
- **Test Coverage**: {X}%
- **Bugs Found**: {X}
- **Acceptance Criteria**: {Y}/{Y} met
## Files Changed
{List key files}
## Next Steps
- Merge to main branch
- Deploy to {environment}
- Monitor for {X} days
---
*Mini-sprint completed successfully! Feature ready for deployment.*
```
## Level 1 vs Level 2 Differences
### Level 1 (1-2 days)
- **Scan**: Quick (15 mins)
- **Tech Spec**: 2-3 pages
- **Stories**: 3-5 stories
- **QA**: Optional (unit tests sufficient)
- **Review**: Quick review
### Level 2 (1-2 weeks)
- **Scan**: Thorough (30 mins)
- **Tech Spec**: 3-5 pages
- **Stories**: 5-15 stories
- **QA**: Required (full testing)
- **Review**: Comprehensive review
## Upgrade Path
If project grows during implementation:
```markdown
🔄 **Complexity Increased - Upgrade Recommended**
Original: Level {1|2}
Current: Level {3+}
**Issues**:
- {Issue 1: e.g., Scope expanded to multiple epics}
- {Issue 2: e.g., Architectural decisions needed}
**Recommendation**: Upgrade to /bmad-pilot
**Upgrade Command**:
```bash
/bmad-pilot-upgrade {feature_name}
```
This will:
1. Preserve existing work (tech-spec, sprint-plan)
2. Generate missing artifacts (PRD, full architecture)
3. Continue with proper governance
```
## Success Criteria
- Correct level classification (1 or 2)
- Quick repository scan completed
- Technical specification generated
- Sprint plan with stories created
- User approval received
- Implementation completed
- Code review passed
- Testing completed (Level 2)
- All artifacts saved correctly
## Example Output
```markdown
# Mini-Sprint Plan Ready ✓
**Feature**: User Profile Management
**Complexity**: Level 2 (1-2 weeks)
**Estimated Time**: 8 days
## Deliverables Created
✓ Quick repository scan: `.claude/specs/user-profile/quick-scan.md`
✓ Technical specification: `.claude/specs/user-profile/tech-spec.md`
✓ Sprint plan: `.claude/specs/user-profile/sprint-plan.md`
## Technical Approach Summary
Build user profile system with avatar upload, profile editing, and settings management. Integrate with existing authentication system. Use React for frontend, Express for backend API.
**Components**: 5 (ProfileController, ProfileService, ProfileUI, AvatarUpload, SettingsPanel)
**API Endpoints**: 4 (GET/PUT /api/profile, POST/DELETE /api/avatar)
**Stories**: 8
## Story Breakdown
| ID | Story | Estimate |
|----|-------|----------|
| 001 | View profile page | 4h |
| 002 | Edit profile form | 6h |
| 003 | Avatar upload | 8h |
| 004 | Settings panel | 6h |
| 005 | Profile API endpoints | 8h |
| 006 | Profile validation | 4h |
| 007 | Integration tests | 6h |
| 008 | E2E testing | 4h |
**Total Estimate**: 46 hours (6-7 days with buffer)
## Implementation Order
1. **Backend First**: Stories 005, 006 (API + validation)
2. **Frontend Core**: Stories 001, 002 (view + edit)
3. **Advanced Features**: Stories 003, 004 (avatar + settings)
4. **Testing**: Stories 007, 008
---
**🛑 Approval Required**
**Ready to start implementation?**
- Reply **'yes'** to begin development
- Reply **'adjust'** to refine the plan
**Review Plans**:
- Tech Spec: `.claude/specs/user-profile/tech-spec.md`
- Sprint Plan: `.claude/specs/user-profile/sprint-plan.md`
```

322
bmad-agile-workflow/commands/workflow-status.md
View File

@@ -1,322 +0,0 @@
## Usage
`/workflow-status [OPTIONS]`
### Options
- `--reset`: Clear the workflow status and start fresh
## Context
- Universal entry point for workflow guidance
- Auto-detects project context and current workflow state
- Recommends appropriate workflow based on project complexity
- Tracks progress across all workflow phases
## Your Role
You are the Workflow Status Analyzer, responsible for guiding users to the appropriate workflow based on their project context and current state. You provide clear visibility into workflow progress and recommend next actions.
## Workflow Status Detection
### 1. Check for Existing Status File
Look for `.claude/workflow-status.md` in the repository root:
- If exists: Parse current state and provide progress update
- If not exists: Perform initial project analysis and recommend workflow
### 2. Project Context Analysis
When no status file exists, analyze:
#### 2a. Project Type Detection
- **Greenfield**: No or minimal existing code → Use full BMAD workflow
- **Brownfield**: Existing codebase → Suggest documentation scan first
- **Enhancement**: Has .claude/specs/ directory → Continue existing workflow
#### 2b. Complexity Assessment (Scale-Adaptive Level 0-4)
Determine appropriate workflow level:
**Level 0: Single Atomic Change**
- Indicators: "fix bug", "update config", "add log statement"
- Recommendation: `/code-spec` - Tech spec only, 1 story
- Time estimate: < 1 hour
**Level 1: Small Feature (1-10 stories)**
- Indicators: "add button", "new endpoint", "simple form"
- Recommendation: `/mini-sprint` - Tech spec + 2-3 stories
- Time estimate: 1-2 days
**Level 2: Medium Feature (5-15 stories, 1-2 epics)**
- Indicators: "user authentication", "data export", "notification system"
- Recommendation: `/bmad-pilot` - PRD + tech spec + sprint plan
- Time estimate: 1-2 weeks
**Level 3: Large Feature (12-40 stories, 2-5 epics)**
- Indicators: "payment system", "admin dashboard", "reporting module"
- Recommendation: `/bmad-pilot` - Full workflow with JIT architecture
- Time estimate: 2-4 weeks
**Level 4: Major Project (40+ stories, 5+ epics)**
- Indicators: "complete redesign", "platform migration", "multi-module system"
- Recommendation: `/bmad-pilot` - Full workflow with phased implementation
- Time estimate: 1-3 months
### 3. Status File Structure
When status file exists, parse and display:
```markdown
# Workflow Status
**Feature**: {feature_name}
**Level**: {0-4}
**Workflow**: {workflow_type}
**State**: {current_phase}
**Started**: {timestamp}
**Last Updated**: {timestamp}
## Progress
### Completed Phases
- [x] Phase 0: Repository Scan (2025-10-20)
- [x] Phase 1: Requirements (90/100) (2025-10-20)
### Current Phase
- [~] Phase 2: Architecture (85/100) - In Progress
### Pending Phases
- [ ] Phase 3: Sprint Planning
- [ ] Phase 4: Development
- [ ] Phase 5: Review
- [ ] Phase 6: QA
## Story State (if in implementation)
### BACKLOG
- Story-001: User login
- Story-002: Password reset
### TODO
- Story-003: Profile edit (Status: Draft)
### IN PROGRESS
- Story-004: Dashboard (Status: Ready)
### DONE
- Story-005: Setup (2025-10-15, 3 points)
## Next Action
{recommended_next_command}
## Context
- Feature Path: .claude/specs/{feature_name}/
- Latest Artifact: {latest_file}
```
## Status Detection Logic
### Read Current State
```
1. Check if .claude/workflow-status.md exists
2. If yes:
a. Parse feature name and current phase
b. Check latest artifact timestamp
c. Identify completed vs pending phases
d. Determine next recommended action
3. If no:
a. Scan for .claude/specs/ directories
b. If found: Infer state from existing artifacts
c. If not found: Recommend initial workflow
```
### Infer State from Artifacts
When no status file but artifacts exist:
```
Check for files in .claude/specs/{feature}/:
- 00-repo-scan.md → Phase 0 completed
- 01-product-requirements.md → Phase 1 completed
- 02-system-architecture.md → Phase 2 completed
- 03-sprint-plan.md → Phase 3 completed
- 04-dev-reviewed.md → Phase 4 completed
Current phase = First missing artifact
```
## Response Format
### When Status File Exists
```markdown
# Workflow Status Report
**Feature**: {name}
**Complexity**: Level {0-4} ({description})
**Started**: {date}
**Progress**: {X}/{Y} phases complete
## Current Status
You are currently in **{phase_name}** ({status})
{Phase-specific details}
## Completed Work
✓ {phase_1} - {score}/100 ({date})
✓ {phase_2} - {score}/100 ({date})
## Up Next
→ {next_phase} - {description}
**Recommended Command**: `{command}`
## Quick Actions
- Continue current phase: `{continue_command}`
- View artifacts: `ls .claude/specs/{feature}/`
- Reset workflow: `/workflow-status --reset`
```
### When No Status File (New Project)
```markdown
# Workflow Recommendation
## Project Analysis
I've analyzed your project and detected:
- **Type**: {Greenfield/Brownfield/Enhancement}
- **Complexity**: Level {0-4}
- **Estimated Scope**: {X} stories, {Y} epics
## Recommended Workflow
Based on your project characteristics, I recommend:
**{Workflow Name}** (Level {X})
- Time estimate: {duration}
- Phases: {phase_list}
### Quick Start
```bash
{recommended_command}
```
## Alternative Workflows
**If this is simpler than expected**:
- Level {X-1}: `{alternative_command}`
**If this is more complex**:
- Level {X+1}: `{alternative_command}`
## Need Help?
- Unsure about scope? Run `/bmad-analyze` first
- Just want to code? Use `/code` for quick changes
- Start fresh? Your recommended command is above
```
### When Project Has Issues
```markdown
# Workflow Status - Issues Detected
## Problems Found
⚠️ {issue_1}
⚠️ {issue_2}
## Recommendations
1. {fix_1}
2. {fix_2}
## Recovery Actions
- Reset status: `/workflow-status --reset`
- Clean specs: `rm -rf .claude/specs/{feature}/`
- Start over: `{start_command}`
```
## Status File Management
### Create Status File
When starting a new workflow (called by orchestrator):
```
Use Write tool:
Path: .claude/workflow-status.md
Content: Status structure with:
- Feature name
- Level (0-4)
- Workflow type
- Initial phase
- Timestamps
```
### Update Status File
When phase transitions (called by orchestrator):
```
Use Edit tool:
- Update current phase
- Mark completed phases with checkmarks
- Update timestamps
- Add story state if in implementation
```
## Execution Flow
1. **Check for --reset flag**
- If present: Delete .claude/workflow-status.md and restart analysis
2. **Look for existing status**
- Read .claude/workflow-status.md if exists
3. **If status exists**
- Parse current state
- Check artifact consistency
- Generate progress report
- Recommend next action
4. **If no status**
- Analyze project type (greenfield/brownfield)
- Assess complexity (Level 0-4)
- Recommend appropriate workflow
- Provide quick start command
5. **Present results**
- Clear status summary
- Actionable recommendations
- Quick action buttons
## Integration with Other Commands
### Called by Orchestrator
Orchestrator should call workflow-status to:
- Initialize status file when starting workflow
- Update status when phase completes
- Record quality scores
- Track story state transitions
### Workflow Commands Read Status
Other commands should read status file to:
- Understand current context
- Skip already-completed phases
- Resume from interruption
- Validate prerequisites
## Success Criteria
- User immediately understands current workflow state
- Clear next action provided
- Appropriate workflow recommended for new projects
- Status file maintained consistently across phases
- Recovery guidance when issues detected
## Example Interactions
### Example 1: New Project
```
User: /workflow-status
Agent: [Analyzes project, detects greenfield, Level 2 complexity]
Recommends: /bmad-pilot with PRD + architecture + sprint plan
```
### Example 2: In Progress
```
User: /workflow-status
Agent: [Reads status file]
"You're in Phase 2 (Architecture) - 85/100 quality score
Continue with: /bmad-pilot (will resume from architecture)"
```
### Example 3: Interrupted Workflow
```
User: /workflow-status
Agent: [Finds artifacts but no status file]
"Detected incomplete workflow. Last completed: Phase 1 (PRD)
Resume with: /bmad-pilot (will skip to Phase 2)"
```

142
docs/WORKFLOW-SIMPLIFICATION.md Normal file
View File

@@ -0,0 +1,142 @@
# Workflow Simplification Summary
**Date**: 2025-10-20
**Status**: Simplified v6 implementation
---
## What Changed
### Before (Over-Engineered)
- ❌ 9 commands (workflow-status, code-spec, mini-sprint, architect-epic, sm-draft-story, sm-approve-story, sm-context, retrospective, bmad-pilot)
- ❌ 4,261 lines of command documentation
- ❌ Complex state machine (BACKLOG → TODO → IN PROGRESS → DONE)
- ❌ User has to choose: "Which command should I use?"
- ❌ Ceremony and cognitive overhead
### After (Simplified)
- ✅ 1 primary command: `/bmad-pilot` (intelligent and adaptive)
- ✅ Smart complexity detection built into workflow
- ✅ Automatic phase skipping for simple tasks
- ✅ No state machine ceremony - just get work done
- ✅ Clear: "Just use /bmad-pilot"
---
## Core Philosophy
**KISS (Keep It Simple, Stupid)**
- One entry point, not nine
- Intelligence in system behavior, not user choices
- Less to learn, more to accomplish
**YAGNI (You Aren't Gonna Need It)**
- Removed speculative features (state machine, context injection commands)
- Deleted unused workflow paths (code-spec, mini-sprint)
- Eliminated ceremony (draft-story, approve-story)
**SOLID Principles**
- Single Responsibility: bmad-pilot coordinates entire workflow
- Open/Closed: Can enhance bmad-pilot without changing interface
- Dependency Inversion: Intelligence abstracted from user interaction
---
## What We Kept from v6 Analysis
The v6 BMAD-METHOD had ONE good insight:
**"Adapt workflow to project complexity"**
We implement this by making `/bmad-pilot` intelligent:
- Analyzes task complexity from description
- Skips unnecessary phases automatically
- Uses appropriate documentation depth
- No user decision required
---
## Current Workflow
**Single Command**: `/bmad-pilot "your request"`
**What Happens Internally** (automatic):
1. Scan repository (understand context)
2. Analyze complexity (simple fix vs large feature)
3. Route to appropriate workflow depth:
- **Simple** (< 1 day): Skip PRD, minimal spec, implement
- **Medium** (1-2 weeks): Lightweight PRD, implement
- **Complex** (2+ weeks): Full PRD + Architecture + Sprint Planning
4. Execute with quality gates
5. Deliver working code
**User Experience**:
- Describe what you want
- System figures out how to do it
- Get working code
---
## Deleted Files
**Commands** (8 files, 3,900+ lines):
- workflow-status.md
- code-spec.md
- mini-sprint.md
- bmad-architect-epic.md
- bmad-sm-draft-story.md
- bmad-sm-approve-story.md
- bmad-sm-context.md
- bmad-retrospective.md
**Documentation** (2 files, 1,153 lines):
- V6-WORKFLOW-ANALYSIS.md
- V6-FEATURES.md
**Total Removed**: 5,053 lines of unnecessary complexity
---
## Future Enhancements (If Needed)
Only add complexity if real user pain exists:
1. **If users need status visibility**: Add `/.claude/workflow-status.md` auto-generated file (no new command)
2. **If retrospectives prove valuable**: Auto-generate retrospectives at epic completion (no user command needed)
3. **If context reduction needed**: Generate story-context.xml automatically during dev (no user command needed)
**Key principle**: Features should be automatic/invisible, not additional commands users must learn and invoke.
---
## Lessons Learned
**What Went Wrong**:
- Took v6 analysis and implemented features as NEW commands
- Added complexity instead of simplifying
- Created ceremony and cognitive overhead
- Focused on completeness rather than simplicity
**What We Fixed**:
- Deleted everything that wasn't essential
- Moved intelligence into existing workflow
- Reduced user-facing surface area dramatically
- Focused on "one simple entry point"
---
## Conclusion
**v6 wasn't about adding 9 new commands.**
**v6 was about making workflow SMARTER and SIMPLER.**
We now have that: One command (`/bmad-pilot`) that intelligently adapts to your needs.
**Result**: Same power, dramatically less complexity.
---
**Last Updated**: 2025-10-20