mirror of
https://github.com/bmadcode/BMAD-METHOD.git
synced 2025-12-29 16:14:59 +00:00
feat: add custom agents and quick-flow workflows, remove tech-spec track
Major Changes: - Add sample custom agents demonstrating installable agent system - commit-poet: Generates semantic commit messages (BMAD Method repo sample) - toolsmith: Development tooling expert with knowledge base covering bundlers, deployment, docs, installers, modules, and tests (BMAD Method repo sample) - Both agents demonstrate custom agent architecture and are installable to projects via BMAD installer system - Include comprehensive installation guides and sidecar knowledge bases - Add bmad-quick-flow methodology for rapid development - create-tech-spec: Direct technical specification workflow - quick-dev: Flexible execution workflow supporting both tech-spec-driven and direct instruction development - quick-flow-solo-dev (Barry): 1 man show agent specialized in bmad-quick-flow methodology - Comprehensive documentation for quick-flow approach and solo development - Remove deprecated tech-spec workflow track - Delete entire tech-spec workflow directory and templates - Remove quick-spec-flow.md documentation (replaced by quick-flow docs) - Clean up unused epic and story templates - Fix custom agent installation across IDE installers - Repair antigravity and multiple IDE installers to properly support custom agents - Enable custom agent installation via quick installer, agent installer, regular installer, and special agent installer - All installation methods now accessible via npx with full documentation Infrastructure: - Update BMM module configurations and team setups - Modify workflow status paths to support quick-flow integration - Reorganize documentation with new agent and workflow guides - Add custom/ directory for user customizations - Update platform codes and installer configurations
This commit is contained in:
Brian Madison
528
src/modules/bmm/docs/bmad-quick-flow.md
Normal file
528
src/modules/bmm/docs/bmad-quick-flow.md
Normal file
@@ -0,0 +1,528 @@
|
||||
# BMAD Quick Flow
|
||||
|
||||
**Track:** Quick Flow
|
||||
**Primary Agent:** Quick Flow Solo Dev (Barry)
|
||||
**Ideal For:** Bug fixes, small features, rapid prototyping
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
BMAD Quick Flow is the fastest path from idea to production in the BMAD Method ecosystem. It's a streamlined 3-step process designed for rapid development without sacrificing quality. Perfect for experienced teams who need to move fast or for smaller features that don't require extensive planning.
|
||||
|
||||
### When to Use Quick Flow
|
||||
|
||||
**Perfect For:**
|
||||
|
||||
- Bug fixes and patches
|
||||
- Small feature additions (1-3 days of work)
|
||||
- Proof of concepts and prototypes
|
||||
- Performance optimizations
|
||||
- API endpoint additions
|
||||
- UI component enhancements
|
||||
- Configuration changes
|
||||
- Internal tools
|
||||
|
||||
**Not Recommended For:**
|
||||
|
||||
- Large-scale system redesigns
|
||||
- Complex multi-team projects
|
||||
- New product launches
|
||||
- Projects requiring extensive UX design
|
||||
- Enterprise-wide initiatives
|
||||
- Mission-critical systems with compliance requirements
|
||||
|
||||
---
|
||||
|
||||
## The Quick Flow Process
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
START[Idea/Requirement] --> DECIDE{Planning Needed?}
|
||||
|
||||
DECIDE -->|Yes| CREATE[create-tech-spec]
|
||||
DECIDE -->|No| DIRECT[Direct Development]
|
||||
|
||||
CREATE --> SPEC[Technical Specification]
|
||||
SPEC --> DEV[quick-dev]
|
||||
DIRECT --> DEV
|
||||
|
||||
DEV --> COMPLETE{Implementation Complete}
|
||||
|
||||
COMPLETE -->|Success| REVIEW{Code Review?}
|
||||
COMPLETE -->|Issues| DEBUG[Debug & Fix]
|
||||
DEBUG --> DEV
|
||||
|
||||
REVIEW -->|Yes| CODE_REVIEW[code-review]
|
||||
REVIEW -->|No| DONE[Production Ready]
|
||||
|
||||
CODE_REVIEW --> FIXES{Fixes Needed?}
|
||||
FIXES -->|Yes| DEBUG
|
||||
FIXES -->|No| DONE
|
||||
|
||||
style START fill:#e1f5fe
|
||||
style CREATE fill:#f3e5f5
|
||||
style SPEC fill:#e8f5e9
|
||||
style DEV fill:#fff3e0
|
||||
style CODE_REVIEW fill:#f1f8e9
|
||||
style DONE fill:#e0f2f1
|
||||
```
|
||||
|
||||
### Step 1: Optional Technical Specification
|
||||
|
||||
The `create-tech-spec` workflow transforms requirements into implementation-ready specifications.
|
||||
|
||||
**Key Features:**
|
||||
|
||||
- Conversational spec engineering
|
||||
- Automatic codebase pattern detection
|
||||
- Context gathering from existing code
|
||||
- Implementation-ready task breakdown
|
||||
- Acceptance criteria definition
|
||||
|
||||
**Process Flow:**
|
||||
|
||||
1. **Problem Understanding**
|
||||
- Greet user and gather requirements
|
||||
- Ask clarifying questions about scope and constraints
|
||||
- Check for existing project context
|
||||
|
||||
2. **Code Investigation (Brownfield)**
|
||||
- Analyze existing codebase patterns
|
||||
- Document tech stack and conventions
|
||||
- Identify files to modify and dependencies
|
||||
|
||||
3. **Specification Generation**
|
||||
- Create structured tech specification
|
||||
- Define clear tasks and acceptance criteria
|
||||
- Document technical decisions
|
||||
- Include development context
|
||||
|
||||
4. **Review and Finalize**
|
||||
- Present spec for validation
|
||||
- Make adjustments as needed
|
||||
- Save to sprint artifacts
|
||||
|
||||
**Output:** `{sprint_artifacts}/tech-spec-{slug}.md`
|
||||
|
||||
### Step 2: Development
|
||||
|
||||
The `quick-dev` workflow executes implementation with flexibility and speed.
|
||||
|
||||
**Two Execution Modes:**
|
||||
|
||||
**Mode A: Tech-Spec Driven**
|
||||
|
||||
```bash
|
||||
# Execute from tech spec
|
||||
quick-dev tech-spec-feature-x.md
|
||||
```
|
||||
|
||||
- Loads and parses technical specification
|
||||
- Extracts tasks, context, and acceptance criteria
|
||||
- Executes all tasks in sequence
|
||||
- Updates spec status on completion
|
||||
|
||||
**Mode B: Direct Instructions**
|
||||
|
||||
```bash
|
||||
# Direct development commands
|
||||
quick-dev "Add password reset to auth service"
|
||||
quick-dev "Fix the memory leak in image processing"
|
||||
```
|
||||
|
||||
- Accepts direct development instructions
|
||||
- Offers optional planning step
|
||||
- Executes immediately with minimal friction
|
||||
|
||||
**Development Process:**
|
||||
|
||||
1. **Context Loading**
|
||||
- Load project context if available
|
||||
- Understand patterns and conventions
|
||||
- Identify relevant files and dependencies
|
||||
|
||||
2. **Implementation Loop**
|
||||
For each task:
|
||||
- Load relevant files and context
|
||||
- Implement following established patterns
|
||||
- Write appropriate tests
|
||||
- Run and verify tests pass
|
||||
- Mark task complete and continue
|
||||
|
||||
3. **Continuous Execution**
|
||||
- Works through all tasks without stopping
|
||||
- Handles failures by requesting guidance
|
||||
- Ensures tests pass before continuing
|
||||
|
||||
4. **Verification**
|
||||
- Confirms all tasks complete
|
||||
- Validates acceptance criteria
|
||||
- Updates tech spec status if used
|
||||
|
||||
### Step 3: Optional Code Review
|
||||
|
||||
The `code-review` workflow provides senior developer review of implemented code.
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- Production-critical features
|
||||
- Security-sensitive implementations
|
||||
- Performance optimizations
|
||||
- Team development scenarios
|
||||
- Learning and knowledge transfer
|
||||
|
||||
**Review Process:**
|
||||
|
||||
1. Load story context and acceptance criteria
|
||||
2. Analyze code implementation
|
||||
3. Check against project patterns
|
||||
4. Validate test coverage
|
||||
5. Provide structured review notes
|
||||
6. Suggest improvements if needed
|
||||
|
||||
---
|
||||
|
||||
## Quick Flow vs Other Tracks
|
||||
|
||||
| Aspect | Quick Flow | BMad Method | Enterprise Method |
|
||||
| ----------------- | ---------------- | --------------- | ------------------ |
|
||||
| **Planning** | Minimal/Optional | Structured | Comprehensive |
|
||||
| **Documentation** | Essential only | Moderate | Extensive |
|
||||
| **Team Size** | 1-2 developers | 3-7 specialists | 8+ enterprise team |
|
||||
| **Timeline** | Hours to days | Weeks to months | Months to quarters |
|
||||
| **Ceremony** | Minimal | Balanced | Full governance |
|
||||
| **Flexibility** | High | Moderate | Structured |
|
||||
| **Risk Profile** | Medium | Low | Very Low |
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Before Starting Quick Flow
|
||||
|
||||
1. **Validate Track Selection**
|
||||
- Is the feature small enough?
|
||||
- Do you have clear requirements?
|
||||
- Is the team comfortable with rapid development?
|
||||
|
||||
2. **Prepare Context**
|
||||
- Have project documentation ready
|
||||
- Know your codebase patterns
|
||||
- Identify affected components upfront
|
||||
|
||||
3. **Set Clear Boundaries**
|
||||
- Define in-scope and out-of-scope items
|
||||
- Establish acceptance criteria
|
||||
- Identify dependencies
|
||||
|
||||
### During Development
|
||||
|
||||
1. **Maintain Velocity**
|
||||
- Don't over-engineer solutions
|
||||
- Follow existing patterns
|
||||
- Keep tests proportional to risk
|
||||
|
||||
2. **Stay Focused**
|
||||
- Resist scope creep
|
||||
- Handle edge cases later if possible
|
||||
- Document decisions briefly
|
||||
|
||||
3. **Communicate Progress**
|
||||
- Update task status regularly
|
||||
- Flag blockers immediately
|
||||
- Share learning with team
|
||||
|
||||
### After Completion
|
||||
|
||||
1. **Quality Gates**
|
||||
- Ensure tests pass
|
||||
- Verify acceptance criteria
|
||||
- Consider optional code review
|
||||
|
||||
2. **Knowledge Transfer**
|
||||
- Update relevant documentation
|
||||
- Share key decisions
|
||||
- Note any discovered patterns
|
||||
|
||||
3. **Production Readiness**
|
||||
- Verify deployment requirements
|
||||
- Check monitoring needs
|
||||
- Plan rollback strategy
|
||||
|
||||
---
|
||||
|
||||
## Quick Flow Templates
|
||||
|
||||
### Tech Spec Template
|
||||
|
||||
```markdown
|
||||
# Tech-Spec: {Feature Title}
|
||||
|
||||
**Created:** {date}
|
||||
**Status:** Ready for Development
|
||||
**Estimated Effort:** Small (1-2 days)
|
||||
|
||||
## Overview
|
||||
|
||||
### Problem Statement
|
||||
|
||||
{Clear description of what needs to be solved}
|
||||
|
||||
### Solution
|
||||
|
||||
{High-level approach to solving the problem}
|
||||
|
||||
### Scope (In/Out)
|
||||
|
||||
**In:** {What will be implemented}
|
||||
**Out:** {Explicitly excluded items}
|
||||
|
||||
## Context for Development
|
||||
|
||||
### Codebase Patterns
|
||||
|
||||
{Key patterns to follow, conventions}
|
||||
|
||||
### Files to Reference
|
||||
|
||||
{List of relevant files and their purpose}
|
||||
|
||||
### Technical Decisions
|
||||
|
||||
{Important technical choices and rationale}
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Tasks
|
||||
|
||||
- [ ] Task 1: {Specific implementation task}
|
||||
- [ ] Task 2: {Specific implementation task}
|
||||
- [ ] Task 3: {Testing and validation}
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
- [ ] AC 1: {Given/When/Then format}
|
||||
- [ ] AC 2: {Given/When/Then format}
|
||||
|
||||
## Additional Context
|
||||
|
||||
### Dependencies
|
||||
|
||||
{External dependencies or prerequisites}
|
||||
|
||||
### Testing Strategy
|
||||
|
||||
{How the feature will be tested}
|
||||
|
||||
### Notes
|
||||
|
||||
{Additional considerations}
|
||||
```
|
||||
|
||||
### Quick Dev Commands
|
||||
|
||||
```bash
|
||||
# From tech spec
|
||||
quick-dev sprint-artifacts/tech-spec-user-auth.md
|
||||
|
||||
# Direct development
|
||||
quick-dev "Add CORS middleware to API endpoints"
|
||||
quick-dev "Fix null pointer exception in user service"
|
||||
quick-dev "Optimize database query for user list"
|
||||
|
||||
# With optional planning
|
||||
quick-dev "Implement file upload feature" --plan
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration with Other Workflows
|
||||
|
||||
### Upgrading Tracks
|
||||
|
||||
If a Quick Flow feature grows in complexity:
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
QF[Quick Flow] --> CHECK{Complexity Increases?}
|
||||
CHECK -->|Yes| UPGRADE[Upgrade to BMad Method]
|
||||
CHECK -->|No| CONTINUE[Continue Quick Flow]
|
||||
|
||||
UPGRADE --> PRD[Create PRD]
|
||||
PRD --> ARCH[Architecture Design]
|
||||
ARCH --> STORIES[Create Epics/Stories]
|
||||
STORIES --> SPRINT[Sprint Planning]
|
||||
|
||||
style QF fill:#e1f5fe
|
||||
style UPGRADE fill:#fff3e0
|
||||
style PRD fill:#f3e5f5
|
||||
style ARCH fill:#e8f5e9
|
||||
style STORIES fill:#f1f8e9
|
||||
style SPRINT fill:#e0f2f1
|
||||
```
|
||||
|
||||
### Using Party Mode
|
||||
|
||||
For complex Quick Flow challenges:
|
||||
|
||||
```bash
|
||||
# Start Barry
|
||||
/bmad:bmm:agents:quick-flow-solo-dev
|
||||
|
||||
# Begin party mode for collaborative problem-solving
|
||||
party-mode
|
||||
```
|
||||
|
||||
Party mode brings in relevant experts:
|
||||
|
||||
- **Architect** - For design decisions
|
||||
- **Dev** - For implementation pairing
|
||||
- **QA** - For test strategy
|
||||
- **UX Designer** - For user experience
|
||||
- **Analyst** - For requirements clarity
|
||||
|
||||
### Quality Assurance Integration
|
||||
|
||||
Quick Flow can integrate with TEA agent for automated testing:
|
||||
|
||||
- Test case generation
|
||||
- Automated test execution
|
||||
- Coverage analysis
|
||||
- Test healing
|
||||
|
||||
---
|
||||
|
||||
## Common Quick Flow Scenarios
|
||||
|
||||
### Scenario 1: Bug Fix
|
||||
|
||||
```
|
||||
Requirement: "Users can't reset passwords"
|
||||
Process: Direct development (no spec needed)
|
||||
Steps: Investigate → Fix → Test → Deploy
|
||||
Time: 2-4 hours
|
||||
```
|
||||
|
||||
### Scenario 2: Small Feature
|
||||
|
||||
```
|
||||
Requirement: "Add export to CSV functionality"
|
||||
Process: Tech spec → Development → Code review
|
||||
Steps: Spec → Implement → Test → Review → Deploy
|
||||
Time: 1-2 days
|
||||
```
|
||||
|
||||
### Scenario 3: Performance Fix
|
||||
|
||||
```
|
||||
Requirement: "Optimize slow product search query"
|
||||
Process: Tech spec → Development → Review
|
||||
Steps: Analysis → Optimize → Benchmark → Deploy
|
||||
Time: 1 day
|
||||
```
|
||||
|
||||
### Scenario 4: API Addition
|
||||
|
||||
```
|
||||
Requirement: "Add webhook endpoints for integrations"
|
||||
Process: Tech spec → Development → Review
|
||||
Steps: Design → Implement → Document → Deploy
|
||||
Time: 2-3 days
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Metrics and KPIs
|
||||
|
||||
Track these metrics to ensure Quick Flow effectiveness:
|
||||
|
||||
**Velocity Metrics:**
|
||||
|
||||
- Features completed per week
|
||||
- Average cycle time (hours)
|
||||
- Bug fix resolution time
|
||||
- Code review turnaround
|
||||
|
||||
**Quality Metrics:**
|
||||
|
||||
- Defect escape rate
|
||||
- Test coverage percentage
|
||||
- Production incident rate
|
||||
- Code review findings
|
||||
|
||||
**Team Metrics:**
|
||||
|
||||
- Developer satisfaction
|
||||
- Knowledge sharing frequency
|
||||
- Process adherence
|
||||
- Autonomy index
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting Quick Flow
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Issue: Scope creep during development**
|
||||
**Solution:** Refer back to tech spec, explicitly document new requirements
|
||||
|
||||
**Issue: Unknown patterns or conventions**
|
||||
**Solution:** Use party-mode to bring in architect or senior dev
|
||||
|
||||
**Issue: Testing bottleneck**
|
||||
**Solution:** Leverage TEA agent for automated test generation
|
||||
|
||||
**Issue: Integration conflicts**
|
||||
**Solution:** Document dependencies, coordinate with affected teams
|
||||
|
||||
### Emergency Procedures
|
||||
|
||||
**Production Hotfix:**
|
||||
|
||||
1. Create branch from production
|
||||
2. Quick dev with minimal changes
|
||||
3. Deploy to staging
|
||||
4. Quick regression test
|
||||
5. Deploy to production
|
||||
6. Merge to main
|
||||
|
||||
**Critical Bug:**
|
||||
|
||||
1. Immediate investigation
|
||||
2. Party-mode if unclear
|
||||
3. Quick fix with rollback plan
|
||||
4. Post-mortem documentation
|
||||
|
||||
---
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)** - Primary agent for Quick Flow
|
||||
- **[Agents Guide](./agents-guide.md)** - Complete agent reference
|
||||
- **[Scale Adaptive System](./scale-adaptive-system.md)** - Track selection guidance
|
||||
- **[Party Mode](./party-mode.md)** - Multi-agent collaboration
|
||||
- **[Workflow Implementation](./workflows-implementation.md)** - Implementation details
|
||||
|
||||
---
|
||||
|
||||
## FAQ
|
||||
|
||||
**Q: How do I know if my feature is too big for Quick Flow?**
|
||||
A: If it requires more than 3-5 days of work, affects multiple systems significantly, or needs extensive UX design, consider the BMad Method track.
|
||||
|
||||
**Q: Can I switch from Quick Flow to BMad Method mid-development?**
|
||||
A: Yes, you can upgrade. Create the missing artifacts (PRD, architecture) and transition to sprint-based development.
|
||||
|
||||
**Q: Is Quick Flow suitable for production-critical features?**
|
||||
A: Yes, with code review. Quick Flow doesn't sacrifice quality, just ceremony.
|
||||
|
||||
**Q: How do I handle dependencies between Quick Flow features?**
|
||||
A: Document dependencies clearly, consider batching related features, or upgrade to BMad Method for complex interdependencies.
|
||||
|
||||
**Q: Can junior developers use Quick Flow?**
|
||||
A: Yes, but they may benefit from the structure of BMad Method. Quick Flow assumes familiarity with patterns and autonomy.
|
||||
|
||||
---
|
||||
|
||||
**Ready to ship fast?** → Start with `/bmad:bmm:agents:quick-flow-solo-dev`
|
||||
Reference in New Issue
Block a user