# 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`