External/BMAD-METHOD
1
0
Fork 0
mirror of https://github.com/bmadcode/BMAD-METHOD.git synced 2025-12-29 16:14:59 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat: add custom agents and quick-flow workflows, remove tech-spec track

Browse Source 
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
2025-11-23 08:50:36 -06:00
parent 6907d44810
commit 4308b36d4d
63 changed files with 2556 additions and 3019 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
src/modules/bmm/docs/README.md
View File

@@ -32,11 +32,18 @@ Understanding how BMM adapts to your needs:
- Documentation requirements per track
- Planning workflow routing
- **[Quick Spec Flow](./quick-spec-flow.md)** - Fast-track workflow for Quick Flow track (26 min read)
- Bug fixes and small features
- Rapid prototyping approach
- Auto-detection of stack and patterns
- Minutes to implementation
- **[BMAD Quick Flow](./bmad-quick-flow.md)** - Fast-track development workflow (32 min read)
- 3-step process: spec → dev → optional review
- Perfect for bug fixes and small features
- Rapid prototyping with production quality
- Hours to implementation, not days
- Barry (Quick Flow Solo Dev) agent owned
- **[Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)** - Elite solo developer for rapid development (18 min read)
- Barry is an elite developer who thrives on autonomous execution
- Lives and breathes the BMAD Quick Flow workflow
- Takes projects from concept to deployment with ruthless efficiency
- No handoffs, no delays - just pure focused development
---
@@ -92,7 +99,8 @@ Essential reference materials:
→ Then review [Scale Adaptive System](./scale-adaptive-system.md) to understand tracks
**Fix a bug or add small feature**
→ Go directly to [Quick Spec Flow](./quick-spec-flow.md)
→ Go to [BMAD Quick Flow](./bmad-quick-flow.md) for rapid development
→ Or use [Quick Flow Solo Dev](./quick-flow-solo-dev.md) directly
**Work with existing codebase (brownfield)**
→ Read [Brownfield Development Guide](./brownfield-guide.md)
@@ -209,11 +217,13 @@ flowchart TD
QS --> DECIDE{What are you building?}
DECIDE -->|Bug fix or<br/>small feature| QSF[Quick Spec Flow]
DECIDE -->|Bug fix or<br/>small feature| QF[BMAD Quick Flow]
DECIDE -->|Need rapid<br/>development| PE[Principal Engineer]
DECIDE -->|New project| SAS[Scale Adaptive System]
DECIDE -->|Existing codebase| BF[Brownfield Guide]
QSF --> IMPL[Implementation]
QF --> IMPL[Implementation]
PE --> IMPL
SAS --> IMPL
BF --> IMPL
@@ -222,6 +232,8 @@ flowchart TD
style START fill:#bfb,stroke:#333,stroke-width:2px,color:#000
style QS fill:#bbf,stroke:#333,stroke-width:2px,color:#000
style DECIDE fill:#ffb,stroke:#333,stroke-width:2px,color:#000
style QF fill:#e1f5fe,stroke:#333,stroke-width:2px,color:#000
style PE fill:#fff3e0,stroke:#333,stroke-width:2px,color:#000
style IMPL fill:#f9f,stroke:#333,stroke-width:2px,color:#000
```

79
src/modules/bmm/docs/agents-guide.md
View File

@@ -28,7 +28,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
### All BMM Agents
**Core Development (8 agents):**
**Core Development (9 agents):**
- PM (Product Manager)
- Analyst (Business Analyst)
@@ -38,6 +38,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- TEA (Test Architect)
- UX Designer
- Technical Writer
- Principal Engineer (Technical Leader) - NEW!
**Game Development (3 agents):**
@@ -49,7 +50,7 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
- BMad Master (Orchestrator)
**Total:** 12 agents + cross-module party mode support
**Total:** 13 agents + cross-module party mode support
---
@@ -506,6 +507,51 @@ The BMad Method Module (BMM) provides a comprehensive team of specialized AI age
---
### Principal Engineer (Technical Leader) - Jordan Chen ⚡
**Role:** Principal Engineer + Technical Leader
**When to Use:**
- Quick Flow development (3-step rapid process)
- Creating technical specifications for immediate implementation
- Rapid prototyping with production quality
- Performance-critical feature development
- Code reviews for senior-level validation
- When you need to ship fast without sacrificing quality
**Primary Phase:** All phases (Quick Flow track)
**Workflows:**
- `create-tech-spec` - Engineer implementation-ready technical specifications
- `quick-dev` - Execute development from specs or direct instructions
- `code-review` - Senior developer code review and validation
- `party-mode` - Collaborative problem-solving with other agents
**Communication Style:** Speaks in git commits, README.md sections, and RFC-style explanations. Starts conversations with "Actually..." and ends with "Patches welcome." Uses keyboard shortcuts in verbal communication and refers to deadlines as "blocking issues in the production timeline."
**Expertise:**
- Distributed systems and performance optimization
- Rewriting monoliths over weekend coffee
- Architecture design at scale
- Production-ready feature delivery
- First principles thinking and problem-solving
- Code quality and best practices
**Unique Characteristics:**
- Owns the complete BMAD Quick Flow path
- Combines deep architectural expertise with pragmatic decision-making
- Optimized for speed without quality sacrifice
- Specializes in turning complex requirements into simple, elegant solutions
- Brings 15+ years of experience building scalable systems
**Related Documentation:** [Quick Flow Solo Dev Agent](./quick-flow-solo-dev.md)
---
## Special Purpose Agents
### BMad Master 🧙
@@ -940,20 +986,21 @@ TEA can be invoked at any phase:
Quick reference for agent selection:
| Agent | Icon | Primary Phase | Key Workflows | Best For |
| ----------------------- | ---- | ------------------ | --------------------------------------------- | ------------------------------------- |
| **Analyst** | 📊 | 1 (Analysis) | brainstorm, brief, research, document-project | Discovery, requirements, brownfield |
| **PM** | 📋 | 2 (Planning) | prd, tech-spec, epics-stories | Planning, requirements docs |
| **UX Designer** | 🎨 | 2 (Planning) | create-ux-design, validate-design | UX-heavy projects, design |
| **Architect** | 🏗️ | 3 (Solutioning) | architecture, implementation-readiness | Technical design, architecture |
| **SM** | 🏃 | 4 (Implementation) | sprint-planning, create-story, story-context | Story management, sprint coordination |
| **DEV** | 💻 | 4 (Implementation) | develop-story, code-review, story-done | Implementation, coding |
| **TEA** | 🧪 | All Phases | framework, atdd, automate, trace, ci | Testing, quality assurance |
| **Paige (Tech Writer)** | 📚 | All Phases | document-project, diagrams, validation | Documentation, diagrams |
| **Game Designer** | 🎲 | 1-2 (Games) | brainstorm-game, gdd, narrative | Game design, creative vision |
| **Game Developer** | 🕹️ | 4 (Games) | develop-story, story-done, code-review | Game implementation |
| **Game Architect** | 🏛️ | 3 (Games) | architecture, implementation-readiness | Game systems architecture |
| **BMad Master** | 🧙 | Meta | party-mode, list tasks/workflows | Orchestration, multi-agent |
| Agent | Icon | Primary Phase | Key Workflows | Best For |
| ----------------------- | ---- | ----------------------- | --------------------------------------------- | --------------------------------------- |
| **Analyst** | 📊 | 1 (Analysis) | brainstorm, brief, research, document-project | Discovery, requirements, brownfield |
| **PM** | 📋 | 2 (Planning) | prd, tech-spec, epics-stories | Planning, requirements docs |
| **UX Designer** | 🎨 | 2 (Planning) | create-ux-design, validate-design | UX-heavy projects, design |
| **Architect** | 🏗️ | 3 (Solutioning) | architecture, implementation-readiness | Technical design, architecture |
| **SM** | 🏃 | 4 (Implementation) | sprint-planning, create-story, story-context | Story management, sprint coordination |
| **DEV** | 💻 | 4 (Implementation) | develop-story, code-review, story-done | Implementation, coding |
| **TEA** | 🧪 | All Phases | framework, atdd, automate, trace, ci | Testing, quality assurance |
| **Paige (Tech Writer)** | 📚 | All Phases | document-project, diagrams, validation | Documentation, diagrams |
| **Principal Engineer** | ⚡ | Quick Flow (All phases) | create-tech-spec, quick-dev, code-review | Rapid development, technical leadership |
| **Game Designer** | 🎲 | 1-2 (Games) | brainstorm-game, gdd, narrative | Game design, creative vision |
| **Game Developer** | 🕹️ | 4 (Games) | develop-story, story-done, code-review | Game implementation |
| **Game Architect** | 🏛️ | 3 (Games) | architecture, implementation-readiness | Game systems architecture |
| **BMad Master** | 🧙 | Meta | party-mode, list tasks/workflows | Orchestration, multi-agent |
### Agent Capabilities Summary

528
src/modules/bmm/docs/bmad-quick-flow.md Normal file
View 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`

337
src/modules/bmm/docs/quick-flow-solo-dev.md Normal file
View File

@@ -0,0 +1,337 @@
# Quick Flow Solo Dev Agent (Barry)
**Agent ID:** `.bmad/bmm/agents/quick-flow-solo-dev.md`
**Icon:** 🚀
**Module:** BMM
---
## Overview
Barry is the elite solo developer who lives and breathes the BMAD Quick Flow workflow. He takes projects from concept to deployment with ruthless efficiency - no handoffs, no delays, just pure focused development. Barry architects specs, writes the code, and ships features faster than entire teams. When you need it done right and done now, Barry's your dev.
### Agent Persona
**Name:** Barry
**Title:** Quick Flow Solo Dev
**Identity:** Barry is an elite developer who thrives on autonomous execution. He lives and breathes the BMAD Quick Flow workflow, taking projects from concept to deployment with ruthless efficiency. No handoffs, no delays - just pure, focused development. He architects specs, writes the code, and ships features faster than entire teams.
**Communication Style:** Direct, confident, and implementation-focused. Uses tech slang and gets straight to the point. No fluff, just results. Every response moves the project forward.
**Core Principles:**
- Planning and execution are two sides of the same coin
- Quick Flow is my religion
- Specs are for building, not bureaucracy
- Code that ships is better than perfect code that doesn't
- Documentation happens alongside development, not after
- Ship early, ship often
---
## Menu Commands
Barry owns the entire BMAD Quick Flow path, providing a streamlined 3-step development process that eliminates handoffs and maximizes velocity.
### 1. **create-tech-spec**
- **Workflow:** `.bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml`
- **Description:** Architect a technical spec with implementation-ready stories
- **Use when:** You need to transform requirements into a buildable spec
### 2. **quick-dev**
- **Workflow:** `.bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.yaml`
- **Description:** Ship features from spec or direct instructions - no handoffs
- **Use when:** You're ready to ship code based on a spec or clear instructions
### 3. **code-review**
- **Workflow:** `.bmad/bmm/workflows/4-implementation/code-review/workflow.yaml`
- **Description:** Review code for quality, patterns, and acceptance criteria
- **Use when:** You need to validate implementation quality
### 4. **party-mode**
- **Workflow:** `.bmad/core/workflows/party-mode/workflow.yaml`
- **Description:** Bring in other experts when I need specialized backup
- **Use when:** You need collaborative problem-solving or specialized expertise
---
## When to Use Barry
### Ideal Scenarios
1. **Quick Flow Development** - Small to medium features that need rapid delivery
2. **Technical Specification Creation** - When you need detailed implementation plans
3. **Direct Development** - When requirements are clear and you want to skip extensive planning
4. **Code Reviews** - When you need senior-level technical validation
5. **Performance-Critical Features** - When optimization and scalability are paramount
### Project Types
- **Greenfield Projects** - New features or components
- **Brownfield Modifications** - Enhancements to existing codebases
- **Bug Fixes** - Complex issues requiring deep technical understanding
- **Proof of Concepts** - Rapid prototyping with production-quality code
- **Performance Optimizations** - System improvements and scalability work
---
## The BMAD Quick Flow Process
Barry orchestrates a simple, efficient 3-step process:
```mermaid
flowchart LR
A[Requirements] --> B[create-tech-spec]
B --> C[Tech Spec]
C --> D[quick-dev]
D --> E[Implementation]
E --> F{Code Review?}
F -->|Yes| G[code-review]
F -->|No| H[Complete]
G --> H[Complete]
style A fill:#e1f5fe
style B fill:#f3e5f5
style C fill:#e8f5e9
style D fill:#fff3e0
style E fill:#fce4ec
style G fill:#f1f8e9
style H fill:#e0f2f1
```
### Step 1: Technical Specification (`create-tech-spec`)
**Goal:** Transform user requirements into implementation-ready technical specifications
**Process:**
1. **Problem Understanding** - Clarify requirements, scope, and constraints
2. **Code Investigation** - Analyze existing patterns and dependencies (if applicable)
3. **Specification Generation** - Create comprehensive tech spec with:
- Problem statement and solution overview
- Development context and patterns
- Implementation tasks with acceptance criteria
- Technical decisions and dependencies
4. **Review and Finalize** - Validate spec captures user intent
**Output:** `tech-spec-{slug}.md` saved to sprint artifacts
**Best Practices:**
- Include ALL context a fresh dev agent needs
- Be specific about files, patterns, and conventions
- Define clear acceptance criteria using Given/When/Then format
- Document technical decisions and trade-offs
### Step 2: Development (`quick-dev`)
**Goal:** Execute implementation based on tech spec or direct instructions
**Two Modes:**
**Mode A: Tech-Spec Driven**
- Load existing tech spec
- Extract tasks, context, and acceptance criteria
- Execute all tasks continuously without stopping
- Respect project context and existing patterns
**Mode B: Direct Instructions**
- Accept direct development commands
- Offer optional planning step
- Execute with minimal friction
**Process:**
1. **Load Project Context** - Understand patterns and conventions
2. **Execute Implementation** - Work through all tasks:
- Load relevant files and context
- Implement following established patterns
- Write and run tests
- Handle errors appropriately
3. **Verify Completion** - Ensure all tasks complete, tests passing, AC satisfied
### Step 3: Code Review (`code-review`) - Optional
**Goal:** Senior developer review of implemented code
**When to Use:**
- Critical production features
- Complex architectural changes
- Performance-sensitive implementations
- Team development scenarios
- Learning and knowledge transfer
**Review Focus:**
- Code quality and patterns
- Acceptance criteria compliance
- Performance and scalability
- Security considerations
- Maintainability and documentation
---
## Collaboration with Other Agents
### Natural Partnerships
- **Tech Writer** - For documentation and API specs when I need it
- **Architect** - For complex system design decisions beyond Quick Flow scope
- **Dev** - For implementation pair programming (rarely needed)
- **QA** - For test strategy and quality gates on critical features
- **UX Designer** - For user experience considerations
### Party Mode Composition
In party mode, Barry often acts as:
- **Solo Tech Lead** - Guiding architectural decisions
- **Implementation Expert** - Providing coding insights
- **Performance Optimizer** - Ensuring scalable solutions
- **Code Review Authority** - Validating technical approaches
---
## Tips for Working with Barry
### For Best Results
1. **Be Specific** - Provide clear requirements and constraints
2. **Share Context** - Include relevant files and patterns
3. **Define Success** - Clear acceptance criteria lead to better outcomes
4. **Trust the Process** - The 3-step flow is optimized for speed and quality
5. **Leverage Expertise** - I'll give you optimization and architectural insights automatically
### Communication Patterns
- **Git Commit Style** - "feat: Add user authentication with OAuth 2.0"
- **RFC Style** - "Proposing microservice architecture for scalability"
- **Direct Questions** - "Actually, have you considered the race condition?"
- **Technical Trade-offs** - "We could optimize for speed over memory here"
### Avoid These Common Mistakes
1. **Vague Requirements** - Leads to unnecessary back-and-forth
2. **Ignoring Patterns** - Causes technical debt and inconsistencies
3. **Skipping Code Review** - Missed opportunities for quality improvement
4. **Over-planning** - I excel at rapid, pragmatic development
5. **Not Using Party Mode** - Missing collaborative insights for complex problems
---
## Example Workflow
```bash
# Start with Barry
/bmad:bmm:agents:quick-flow-solo-dev
# Create a tech spec
> create-tech-spec
# Quick implementation
> quick-dev tech-spec-auth.md
# Optional code review
> code-review
```
### Sample Tech Spec Structure
```markdown
# Tech-Spec: User Authentication System
**Created:** 2025-01-15
**Status:** Ready for Development
## Overview
### Problem Statement
Users cannot securely access the application, and we need role-based permissions for enterprise features.
### Solution
Implement OAuth 2.0 authentication with JWT tokens and role-based access control (RBAC).
### Scope (In/Out)
**In:** Login, logout, password reset, role management
**Out:** Social login, SSO, multi-factor authentication (Phase 2)
## Context for Development
### Codebase Patterns
- Use existing auth middleware pattern in `src/middleware/auth.js`
- Follow service layer pattern from `src/services/`
- JWT secrets managed via environment variables
### Files to Reference
- `src/middleware/auth.js` - Authentication middleware
- `src/models/User.js` - User data model
- `config/database.js` - Database connection
### Technical Decisions
- JWT tokens over sessions for API scalability
- bcrypt for password hashing
- Role-based permissions stored in database
## Implementation Plan
### Tasks
- [ ] Create authentication service
- [ ] Implement login/logout endpoints
- [ ] Add JWT middleware
- [ ] Create role-based permissions
- [ ] Write comprehensive tests
### Acceptance Criteria
- [ ] Given valid credentials, when user logs in, then receive JWT token
- [ ] Given invalid token, when accessing protected route, then return 401
- [ ] Given admin role, when accessing admin endpoint, then allow access
```
---
## Related Documentation
- **[Quick Start Guide](./quick-start.md)** - Getting started with BMM
- **[Agents Guide](./agents-guide.md)** - Complete agent reference
- **[Scale Adaptive System](./scale-adaptive-system.md)** - Understanding development tracks
- **[Workflow Implementation](./workflows-implementation.md)** - Implementation workflows
- **[Party Mode](./party-mode.md)** - Multi-agent collaboration
---
## Frequently Asked Questions
**Q: When should I use Barry vs other agents?**
A: Use Barry for Quick Flow development (small to medium features), rapid prototyping, or when you need elite solo development. For large, complex projects requiring full team collaboration, consider the full BMad Method with specialized agents.
**Q: Is the code review step mandatory?**
A: No, it's optional but highly recommended for critical features, team projects, or when learning best practices.
**Q: Can I skip the tech spec step?**
A: Yes, the quick-dev workflow accepts direct instructions. However, tech specs are recommended for complex features or team collaboration.
**Q: How does Barry differ from the Dev agent?**
A: Barry handles the complete Quick Flow process (spec → dev → review) with elite architectural expertise, while the Dev agent specializes in pure implementation tasks. Barry is your autonomous end-to-end solution.
**Q: Can Barry handle enterprise-scale projects?**
A: For enterprise-scale projects requiring full team collaboration, consider using the Enterprise Method track. Barry is optimized for rapid delivery in the Quick Flow track where solo execution wins.
---
**Ready to ship some code?** → Start with `/bmad:bmm:agents:quick-flow-solo-dev`

652
src/modules/bmm/docs/quick-spec-flow.md
View File

@@ -1,652 +0,0 @@
# BMad Quick Spec Flow
**Perfect for:** Bug fixes, small features, rapid prototyping, and quick enhancements
**Time to implementation:** Minutes, not hours
---
## What is Quick Spec Flow?
Quick Spec Flow is a **streamlined alternative** to the full BMad Method for Quick Flow track projects. Instead of going through Product Brief → PRD → Architecture, you go **straight to a context-aware technical specification** and start coding.
### When to Use Quick Spec Flow
✅ **Use Quick Flow track when:**
- Single bug fix or small enhancement
- Small feature with clear scope (typically 1-15 stories)
- Rapid prototyping or experimentation
- Adding to existing brownfield codebase
- You know exactly what you want to build
❌ **Use BMad Method or Enterprise tracks when:**
- Building new products or major features
- Need stakeholder alignment
- Complex multi-team coordination
- Requires extensive planning and architecture
💡 **Not sure?** Run `workflow-init` to get a recommendation based on your project's needs!
---
## Quick Spec Flow Overview
```mermaid
flowchart TD
START[Step 1: Run Tech-Spec Workflow]
DETECT[Detects project stack<br/>package.json, requirements.txt, etc.]
ANALYZE[Analyzes brownfield codebase<br/>if exists]
TEST[Detects test frameworks<br/>and conventions]
CONFIRM[Confirms conventions<br/>with you]
GENERATE[Generates context-rich<br/>tech-spec]
STORIES[Creates ready-to-implement<br/>stories]
OPTIONAL[Step 2: Optional<br/>Generate Story Context<br/>SM Agent<br/>For complex scenarios only]
IMPL[Step 3: Implement<br/>DEV Agent<br/>Code, test, commit]
DONE[DONE! 🚀]
START --> DETECT
DETECT --> ANALYZE
ANALYZE --> TEST
TEST --> CONFIRM
CONFIRM --> GENERATE
GENERATE --> STORIES
STORIES --> OPTIONAL
OPTIONAL -.->|Optional| IMPL
STORIES --> IMPL
IMPL --> DONE
style START fill:#bfb,stroke:#333,stroke-width:2px,color:#000
style OPTIONAL fill:#ffb,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5,color:#000
style IMPL fill:#bbf,stroke:#333,stroke-width:2px,color:#000
style DONE fill:#f9f,stroke:#333,stroke-width:3px,color:#000
```
---
## Single Atomic Change
**Best for:** Bug fixes, single file changes, isolated improvements
### What You Get
1. **tech-spec.md** - Comprehensive technical specification with:
- Problem statement and solution
- Detected framework versions and dependencies
- Brownfield code patterns (if applicable)
- Existing test patterns to follow
- Specific file paths to modify
- Complete implementation guidance
2. **story-[slug].md** - Single user story ready for development
### Quick Spec Flow Commands
```bash
# Start Quick Spec Flow (no workflow-init needed!)
# Load PM agent and run tech-spec
# When complete, implement directly:
# Load DEV agent and run dev-story
```
### What Makes It Quick
- ✅ No Product Brief needed
- ✅ No PRD needed
- ✅ No Architecture doc needed
- ✅ Auto-detects your stack
- ✅ Auto-analyzes brownfield code
- ✅ Auto-validates quality
- ✅ Story context optional (tech-spec is comprehensive!)
### Example Single Change Scenarios
- "Fix the login validation bug"
- "Add email field to user registration form"
- "Update API endpoint to return additional field"
- "Improve error handling in payment processing"
---
## Coherent Small Feature
**Best for:** Small features with 2-3 related user stories
### What You Get
1. **tech-spec.md** - Same comprehensive spec as single change projects
2. **epics.md** - Epic organization with story breakdown
3. **story-[epic-slug]-1.md** - First story
4. **story-[epic-slug]-2.md** - Second story
5. **story-[epic-slug]-3.md** - Third story (if needed)
### Quick Spec Flow Commands
```bash
# Start Quick Spec Flow
# Load PM agent and run tech-spec
# Optional: Organize stories as a sprint
# Load SM agent and run sprint-planning
# Implement story-by-story:
# Load DEV agent and run dev-story for each story
```
### Story Sequencing
Stories are **automatically validated** to ensure proper sequence:
- ✅ No forward dependencies (Story 2 can't depend on Story 3)
- ✅ Clear dependency documentation
- ✅ Infrastructure → Features → Polish order
- ✅ Backend → Frontend flow
### Example Small Feature Scenarios
- "Add OAuth social login (Google, GitHub, Twitter)"
- "Build user profile page with avatar upload"
- "Implement basic search with filters"
- "Add dark mode toggle to application"
---
## Smart Context Discovery
Quick Spec Flow automatically discovers and uses:
### 1. Existing Documentation
- Product briefs (if they exist)
- Research documents
- `document-project` output (brownfield codebase map)
### 2. Project Stack
- **Node.js:** package.json → frameworks, dependencies, scripts, test framework
- **Python:** requirements.txt, pyproject.toml → packages, tools
- **Ruby:** Gemfile → gems and versions
- **Java:** pom.xml, build.gradle → Maven/Gradle dependencies
- **Go:** go.mod → modules
- **Rust:** Cargo.toml → crates
- **PHP:** composer.json → packages
### 3. Brownfield Code Patterns
- Directory structure and organization
- Existing code patterns (class-based, functional, MVC)
- Naming conventions (camelCase, snake_case, PascalCase)
- Test frameworks and patterns
- Code style (semicolons, quotes, indentation)
- Linter/formatter configs
- Error handling patterns
- Logging conventions
- Documentation style
### 4. Convention Confirmation
**IMPORTANT:** Quick Spec Flow detects your conventions and **asks for confirmation**:
```
I've detected these conventions in your codebase:
Code Style:
- ESLint with Airbnb config
- Prettier with single quotes, 2-space indent
- No semicolons
Test Patterns:
- Jest test framework
- .test.js file naming
- expect() assertion style
Should I follow these existing conventions? (yes/no)
```
**You decide:** Conform to existing patterns or establish new standards!
---
## Modern Best Practices via WebSearch
Quick Spec Flow stays current by using WebSearch when appropriate:
### For Greenfield Projects
- Searches for latest framework versions
- Recommends official starter templates
- Suggests modern best practices
### For Outdated Dependencies
- Detects if your dependencies are >2 years old
- Searches for migration guides
- Notes upgrade complexity
### Starter Template Recommendations
For greenfield projects, Quick Spec Flow recommends:
**React:**
- Vite (modern, fast)
- Next.js (full-stack)
**Python:**
- cookiecutter templates
- FastAPI starter
**Node.js:**
- NestJS CLI
- express-generator
**Benefits:**
- ✅ Modern best practices baked in
- ✅ Proper project structure
- ✅ Build tooling configured
- ✅ Testing framework set up
- ✅ Faster time to first feature
---
## UX/UI Considerations
For user-facing changes, Quick Spec Flow captures:
- UI components affected (create vs modify)
- UX flow changes (current vs new)
- Responsive design needs (mobile, tablet, desktop)
- Accessibility requirements:
- Keyboard navigation
- Screen reader compatibility
- ARIA labels
- Color contrast standards
- User feedback patterns:
- Loading states
- Error messages
- Success confirmations
- Progress indicators
---
## Auto-Validation and Quality Assurance
Quick Spec Flow **automatically validates** everything:
### Tech-Spec Validation (Always Runs)
Checks:
- ✅ Context gathering completeness
- ✅ Definitiveness (no "use X or Y" statements)
- ✅ Brownfield integration quality
- ✅ Stack alignment
- ✅ Implementation readiness
Generates scores:
```
✅ Validation Passed!
- Context Gathering: Comprehensive
- Definitiveness: All definitive
- Brownfield Integration: Excellent
- Stack Alignment: Perfect
- Implementation Readiness: ✅ Ready
```
### Story Validation (Multi-Story Features)
Checks:
- ✅ Story sequence (no forward dependencies!)
- ✅ Acceptance criteria quality (specific, testable)
- ✅ Completeness (all tech spec tasks covered)
- ✅ Clear dependency documentation
**Auto-fixes issues if found!**
---
## Complete User Journey
### Scenario 1: Bug Fix (Single Change)
**Goal:** Fix login validation bug
**Steps:**
1. **Start:** Load PM agent, say "I want to fix the login validation bug"
2. **PM runs tech-spec workflow:**
- Asks: "What problem are you solving?"
- You explain the validation issue
- Detects your Node.js stack (Express 4.18.2, Jest for testing)
- Analyzes existing UserService code patterns
- Asks: "Should I follow your existing conventions?" → You say yes
- Generates tech-spec.md with specific file paths and patterns
- Creates story-login-fix.md
3. **Implement:** Load DEV agent, run `dev-story`
- DEV reads tech-spec (has all context!)
- Implements fix following existing patterns
- Runs tests (following existing Jest patterns)
- Done!
**Total time:** 15-30 minutes (mostly implementation)
---
### Scenario 2: Small Feature (Multi-Story)
**Goal:** Add OAuth social login (Google, GitHub)
**Steps:**
1. **Start:** Load PM agent, say "I want to add OAuth social login"
2. **PM runs tech-spec workflow:**
- Asks about the feature scope
- You specify: Google and GitHub OAuth
- Detects your stack (Next.js 13.4, NextAuth.js already installed!)
- Analyzes existing auth patterns
- Confirms conventions with you
- Generates:
- tech-spec.md (comprehensive implementation guide)
- epics.md (OAuth Integration epic)
- story-oauth-1.md (Backend OAuth setup)
- story-oauth-2.md (Frontend login buttons)
3. **Optional Sprint Planning:** Load SM agent, run `sprint-planning`
4. **Implement Story 1:**
- Load DEV agent, run `dev-story` for story 1
- DEV implements backend OAuth
5. **Implement Story 2:**
- DEV agent, run `dev-story` for story 2
- DEV implements frontend
- Done!
**Total time:** 1-3 hours (mostly implementation)
---
## Integration with Phase 4 Workflows
Quick Spec Flow works seamlessly with all Phase 4 implementation workflows:
### story-context (SM Agent)
- ✅ Recognizes tech-spec.md as authoritative source
- ✅ Extracts context from tech-spec (replaces PRD)
- ✅ Generates XML context for complex scenarios
### create-story (SM Agent)
- ✅ Can work with tech-spec.md instead of PRD
- ✅ Uses epics.md from tech-spec workflow
- ✅ Creates additional stories if needed
### sprint-planning (SM Agent)
- ✅ Works with epics.md from tech-spec
- ✅ Organizes multi-story features for coordinated implementation
- ✅ Tracks progress through sprint-status.yaml
### dev-story (DEV Agent)
- ✅ Reads stories generated by tech-spec
- ✅ Uses tech-spec.md as comprehensive context
- ✅ Implements following detected conventions
---
## Comparison: Quick Spec vs Full BMM
| Aspect | Quick Flow Track | BMad Method/Enterprise Tracks |
| --------------------- | ---------------------------- | ---------------------------------- |
| **Setup** | None (standalone) | workflow-init recommended |
| **Planning Docs** | tech-spec.md only | Product Brief → PRD → Architecture |
| **Time to Code** | Minutes | Hours to days |
| **Best For** | Bug fixes, small features | New products, major features |
| **Context Discovery** | Automatic | Manual + guided |
| **Story Context** | Optional (tech-spec is rich) | Required (generated from PRD) |
| **Validation** | Auto-validates everything | Manual validation steps |
| **Brownfield** | Auto-analyzes and conforms | Manual documentation required |
| **Conventions** | Auto-detects and confirms | Document in PRD/Architecture |
---
## When to Graduate from Quick Flow to BMad Method
Start with Quick Flow, but switch to BMad Method when:
- ❌ Project grows beyond initial scope
- ❌ Multiple teams need coordination
- ❌ Stakeholders need formal documentation
- ❌ Product vision is unclear
- ❌ Architectural decisions need deep analysis
- ❌ Compliance/regulatory requirements exist
💡 **Tip:** You can always run `workflow-init` later to transition from Quick Flow to BMad Method!
---
## Quick Spec Flow - Key Benefits
### 🚀 **Speed**
- No Product Brief
- No PRD
- No Architecture doc
- Straight to implementation
### 🧠 **Intelligence**
- Auto-detects stack
- Auto-analyzes brownfield
- Auto-validates quality
- WebSearch for current info
### 📐 **Respect for Existing Code**
- Detects conventions
- Asks for confirmation
- Follows patterns
- Adapts vs. changes
### ✅ **Quality**
- Auto-validation
- Definitive decisions (no "or" statements)
- Comprehensive context
- Clear acceptance criteria
### 🎯 **Focus**
- Single atomic changes
- Coherent small features
- No scope creep
- Fast iteration
---
## Getting Started
### Prerequisites
- BMad Method installed (`npx bmad-method install`)
- Project directory with code (or empty for greenfield)
### Quick Start Commands
```bash
# For a quick bug fix or small change:
# 1. Load PM agent
# 2. Say: "I want to [describe your change]"
# 3. PM will ask if you want to run tech-spec
# 4. Answer questions about your change
# 5. Get tech-spec + story
# 6. Load DEV agent and implement!
# For a small feature with multiple stories:
# Same as above, but get epic + 2-3 stories
# Optionally use SM sprint-planning to organize
```
### No workflow-init Required!
Quick Spec Flow is **fully standalone**:
- Detects if it's a single change or multi-story feature
- Asks for greenfield vs brownfield
- Works without status file tracking
- Perfect for rapid prototyping
---
## FAQ
### Q: Can I use Quick Spec Flow on an existing project?
**A:** Yes! It's perfect for brownfield projects. It will analyze your existing code, detect patterns, and ask if you want to follow them.
### Q: What if I don't have a package.json or requirements.txt?
**A:** Quick Spec Flow will work in greenfield mode, recommend starter templates, and use WebSearch for modern best practices.
### Q: Do I need to run workflow-init first?
**A:** No! Quick Spec Flow is standalone. But if you want guidance on which flow to use, workflow-init can help.
### Q: Can I use this for frontend changes?
**A:** Absolutely! Quick Spec Flow captures UX/UI considerations, component changes, and accessibility requirements.
### Q: What if my Quick Flow project grows?
**A:** No problem! You can always transition to BMad Method by running workflow-init and create-prd. Your tech-spec becomes input for the PRD.
### Q: Do I need story-context for every story?
**A:** Usually no! Tech-spec is comprehensive enough for most Quick Flow projects. Only use story-context for complex edge cases.
### Q: Can I skip validation?
**A:** No, validation always runs automatically. But it's fast and catches issues early!
### Q: Will it work with my team's code style?
**A:** Yes! It detects your conventions and asks for confirmation. You control whether to follow existing patterns or establish new ones.
---
## Tips and Best Practices
### 1. **Be Specific in Discovery**
When describing your change, provide specifics:
- ✅ "Fix email validation in UserService to allow plus-addressing"
- ❌ "Fix validation bug"
### 2. **Trust the Convention Detection**
If it detects your patterns correctly, say yes! It's faster than establishing new conventions.
### 3. **Use WebSearch Recommendations for Greenfield**
Starter templates save hours of setup time. Let Quick Spec Flow find the best ones.
### 4. **Review the Auto-Validation**
When validation runs, read the scores. They tell you if your spec is production-ready.
### 5. **Story Context is Optional**
For single changes, try going directly to dev-story first. Only add story-context if you hit complexity.
### 6. **Keep Single Changes Truly Atomic**
If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you.
### 7. **Validate Story Sequence for Multi-Story Features**
When you get multiple stories, check the dependency validation output. Proper sequence matters!
---
## Real-World Examples
### Example 1: Adding Logging (Single Change)
**Input:** "Add structured logging to payment processing"
**Tech-Spec Output:**
- Detected: winston 3.8.2 already in package.json
- Analyzed: Existing services use winston with JSON format
- Confirmed: Follow existing logging patterns
- Generated: Specific file paths, log levels, format example
- Story: Ready to implement in 1-2 hours
**Result:** Consistent logging added, following team patterns, no research needed.
---
### Example 2: Search Feature (Multi-Story)
**Input:** "Add search to product catalog with filters"
**Tech-Spec Output:**
- Detected: React 18.2.0, MUI component library, Express backend
- Analyzed: Existing ProductList component patterns
- Confirmed: Follow existing API and component structure
- Generated:
- Epic: Product Search Functionality
- Story 1: Backend search API with filters
- Story 2: Frontend search UI component
- Auto-validated: Story 1 → Story 2 sequence correct
**Result:** Search feature implemented in 4-6 hours with proper architecture.
---
## Summary
Quick Spec Flow is your **fast path from idea to implementation** for:
- 🐛 Bug fixes
- ✨ Small features
- 🚀 Rapid prototyping
- 🔧 Quick enhancements
**Key Features:**
- Auto-detects your stack
- Auto-analyzes brownfield code
- Auto-validates quality
- Respects existing conventions
- Uses WebSearch for modern practices
- Generates comprehensive tech-specs
- Creates implementation-ready stories
**Time to code:** Minutes, not hours.
**Ready to try it?** Load the PM agent and say what you want to build! 🚀
---
## Next Steps
- **Try it now:** Load PM agent and describe a small change
- **Learn more:** See the [BMM Workflow Guides](./README.md#-workflow-guides) for comprehensive workflow documentation
- **Need help deciding?** Run `workflow-init` to get a recommendation
- **Have questions?** Join us on Discord: https://discord.gg/gk8jAdXWmj
---
_Quick Spec Flow - Because not every change needs a Product Brief._