Examples
Learn BMAD through complete, real-world examples. Each example shows the full workflow from start to finish.
Example Projects
| Example | Level | Type | Skills Used |
|---|---|---|---|
| Subagent Execution | N/A | Pattern | Parallel coordination |
| E-commerce API | 2 | API | Full workflow |
| CLI Tool | 1 | Library | Tech spec only |
| Bug Fix | 0 | Atomic | Minimal workflow |
| Mobile App | 3 | Mobile | Full + UX design |
| Feature Research | N/A | Research | Creative Intelligence |
Subagent Execution Example
Understanding how BMAD skills leverage parallel subagents for maximum efficiency.
Core Concept
Each Claude subagent gets its own 200K token context window. BMAD skills decompose complex workflows into independent subtasks that run in parallel, then synthesize results.
Principle: Never do sequentially what can be done in parallel.
Example: Product Manager Creating PRD
When you run /prd, the Product Manager skill doesn’t write the entire document sequentially. Instead, it coordinates parallel subagents.
Step 1: Main Agent Prepares Context
User: /prd
Claude (Product Manager): Creating PRD based on product brief...
Loading: docs/product-brief.md
The main agent writes shared context to a file:
# bmad/context/prd-context.md
Project: E-commerce Product Catalog API
Level: 2
Type: API
## Key Requirements (from product brief)
- Product and category management
- Search with autocomplete
- Real-time inventory
- Multi-warehouse support
- Performance: <100ms P95
- Scale: 1000 RPS
## Target Deliverables
- Functional Requirements section
- Non-Functional Requirements section
- Epics and User Stories
- Dependencies and Constraints
Step 2: Launch Parallel Agents
The main agent launches 4 subagents simultaneously using the Task tool:
# Pseudocode representation
agent1 = Task(
subagent_type="general-purpose",
run_in_background=True,
prompt="""
## Task: Write Functional Requirements section
## Context
Read: bmad/context/prd-context.md
## Objective
Define all functional requirements for the E-commerce API.
Include: Products, Categories, Search, Inventory, Pricing.
Format as FR-001, FR-002, etc. with clear acceptance criteria.
## Output Location
Write results to: bmad/outputs/agent-fr.md
"""
)
agent2 = Task(
subagent_type="general-purpose",
run_in_background=True,
prompt="""
## Task: Write Non-Functional Requirements section
## Context
Read: bmad/context/prd-context.md
## Objective
Define all non-functional requirements.
Include: Performance, Availability, Security, Scalability.
Format as NFR-001, NFR-002, etc. with measurable targets.
## Output Location
Write results to: bmad/outputs/agent-nfr.md
"""
)
agent3 = Task(
subagent_type="general-purpose",
run_in_background=True,
prompt="""
## Task: Write Epics and User Stories section
## Context
Read: bmad/context/prd-context.md
## Objective
Break down requirements into epics and stories.
Include story point estimates.
Format: Epic 1: Product CRUD (21 pts)
- STORY-001: Product model (3)
## Output Location
Write results to: bmad/outputs/agent-epics.md
"""
)
agent4 = Task(
subagent_type="general-purpose",
run_in_background=True,
prompt="""
## Task: Write Dependencies and Constraints section
## Context
Read: bmad/context/prd-context.md
## Objective
Identify technical dependencies, integration points,
timeline constraints, and risk factors.
## Output Location
Write results to: bmad/outputs/agent-dependencies.md
"""
)
Step 3: Parallel Execution
All 4 agents run simultaneously, each in its own 200K token context:
┌─────────────────────┐
│ Main Agent │
│ (Product Manager) │
└──────────┬──────────┘
│ Writes context file
│
┌──────▼──────────────┐
│ bmad/context/ │
│ prd-context.md │
└──────┬──────────────┘
│ Read by all agents
│
┌──────┴──────┬────────────┬────────────┐
▼ ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Agent 1 │ │ Agent 2 │ │ Agent 3 │ │ Agent 4 │
│ FR │ │ NFR │ │ Epics │ │ Deps │
│ 200K ctx │ │ 200K ctx │ │ 200K ctx │ │ 200K ctx │
└────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │ │
▼ ▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│agent-fr │ │agent-nfr │ │agent- │ │agent- │
│.md │ │.md │ │epics.md │ │deps.md │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
Each agent works independently, exploring the codebase, researching best practices, and writing their section.
Step 4: Main Agent Synthesizes Results
Once all agents complete, the main agent reads their outputs:
Claude: Collecting results from parallel agents...
Reading: bmad/outputs/agent-fr.md
Reading: bmad/outputs/agent-nfr.md
Reading: bmad/outputs/agent-epics.md
Reading: bmad/outputs/agent-dependencies.md
Synthesizing into final PRD...
The main agent:
- Reviews all sections for consistency
- Resolves any conflicts (e.g., NFR contradicting FR)
- Ensures story points align with project level
- Formats into final document structure
- Adds executive summary and metadata
Writing final PRD to: docs/prd.md
PRD complete!
- 5 Functional Requirements
- 3 Non-Functional Requirements
- 5 Epics with 23 User Stories
- 73 total story points
Coordination Flow Summary
1. Context → Write shared context to bmad/context/
2. Launch → Start N parallel agents in background
3. Execute → Each agent works in 200K token context
4. Output → Agents write to bmad/outputs/agent-{n}.md
5. Synthesize → Main agent combines results
6. Deliver → Final document written to docs/
Why This Matters
Without subagents (sequential):
- Token budget: 200K for entire PRD
- Time: 15-20 minutes sequential writing
- Depth: Limited by single context
With subagents (parallel):
- Token budget: 200K × 4 = 800K total
- Time: 5-7 minutes (parallel execution)
- Depth: Each section gets full 200K context
Result: 3-4x faster execution with 4x the effective token budget.
Parallel Research Example
The Business Analyst uses the same pattern for comprehensive research:
User: /research
Claude (Business Analyst): What type of research?
> Comprehensive analysis for our API product
Launching 4 parallel research agents...
The main agent coordinates:
Agent 1: Market Research
- Market size and growth trends
- Target customer segments
- Pricing benchmarks
→ Output: bmad/outputs/research-market.md
Agent 2: Competitive Analysis
- Direct competitors (features, pricing)
- Indirect competitors (alternatives)
- Competitive advantages/gaps
→ Output: bmad/outputs/research-competitive.md
Agent 3: Technical Research
- Technology stack options
- Architecture patterns
- Integration requirements
→ Output: bmad/outputs/research-technical.md
Agent 4: User Research
- User personas
- Pain points and needs
- Jobs-to-be-Done analysis
→ Output: bmad/outputs/research-users.md
All 4 agents run in parallel, each conducting deep research in their domain. The main agent then synthesizes findings into docs/research-report.md.
Example 1: E-commerce API (Level 2)
A complete walkthrough building a product catalog API for an e-commerce platform.
Project Setup
User: I want to build a product catalog API for my e-commerce site.
It should handle products, categories, search, and inventory.
Claude: I'll help you build that! Let's start by initializing BMAD.
Step 1: Initialize Project
User: /workflow-init
Claude: Welcome to BMAD! Let's configure your project.
Project name?
> E-commerce Product Catalog API
Project type?
> api
For a catalog API with products, categories, search, and inventory,
I recommend Level 2 (5-15 stories).
Project level?
> 2
Created bmad/config.yaml
Next step: /product-brief
Step 2: Product Brief
User: /product-brief
Claude: I'll create a product brief for the E-commerce Product Catalog API.
## Executive Summary
What problem does this solve?
> Our current product data is spread across multiple systems.
> We need a centralized API that all clients (web, mobile, admin)
> can use to access product information.
## Target Audience
Who uses this API?
> - Frontend web application
> - iOS and Android apps
> - Admin dashboard
> - Third-party integrations
## Problem Statement
1. **Data inconsistency:** Different clients show different product info
2. **Slow queries:** Current DB queries take 2-3 seconds
3. **No search:** Customers can only browse by category
4. **Manual inventory:** Stock updates require database changes
## Success Metrics
> - API response time <100ms
> - Search results in <200ms
> - Zero data inconsistency across clients
> - Real-time inventory updates
## Constraints
> - Must integrate with existing PostgreSQL database
> - Support 1000 requests/second at peak
> - GDPR compliant for EU customers
Saving to: docs/product-brief.md
Step 3: PRD
User: /prd
Claude: Creating PRD based on product brief...
Loading: docs/product-brief.md
## Functional Requirements
### FR-001: Product Management
- Create, read, update, delete products
- Product attributes: name, description, price, images, SKU
- Product variants (size, color)
- Bulk import/export
### FR-002: Category Management
- Hierarchical categories (up to 3 levels)
- Products can belong to multiple categories
- Category images and descriptions
### FR-003: Search
- Full-text search on name and description
- Faceted search (category, price range, attributes)
- Autocomplete suggestions
- Search analytics
### FR-004: Inventory
- Real-time stock levels
- Reserve stock for carts
- Low stock alerts
- Multi-warehouse support
### FR-005: Pricing
- Base price and sale price
- Bulk pricing tiers
- Currency conversion (store in cents)
## Non-Functional Requirements
### NFR-001: Performance
- GET endpoints: <100ms P95
- Search: <200ms P95
- Write endpoints: <300ms P95
- 1000 RPS sustained
### NFR-002: Availability
- 99.9% uptime
- Graceful degradation (serve cached on DB failure)
### NFR-003: Security
- API key authentication
- Rate limiting per client
- Input validation
- SQL injection protection
## Epics and Stories
### Epic 1: Product CRUD (21 pts)
- STORY-001: Product model and migrations (3)
- STORY-002: Create product endpoint (3)
- STORY-003: Read product endpoints (3)
- STORY-004: Update product endpoint (3)
- STORY-005: Delete product (soft) (2)
- STORY-006: Product variants (5)
- STORY-007: Bulk import (2)
### Epic 2: Categories (13 pts)
- STORY-008: Category model with hierarchy (5)
- STORY-009: Category CRUD (3)
- STORY-010: Product-category relationships (3)
- STORY-011: Category tree endpoint (2)
### Epic 3: Search (18 pts)
- STORY-012: Elasticsearch setup (3)
- STORY-013: Product indexing (5)
- STORY-014: Basic search endpoint (3)
- STORY-015: Faceted search (5)
- STORY-016: Autocomplete (2)
### Epic 4: Inventory (13 pts)
- STORY-017: Inventory model (2)
- STORY-018: Stock endpoints (3)
- STORY-019: Stock reservation (5)
- STORY-020: Low stock alerts (3)
### Epic 5: API Infrastructure (8 pts)
- STORY-021: API authentication (3)
- STORY-022: Rate limiting (2)
- STORY-023: Caching layer (3)
## Summary
- Total stories: 23
- Total points: 73
- Estimated sprints: 3
Saving to: docs/prd.md
Step 4: Architecture
User: /architecture
Claude: Designing system architecture...
Loading: docs/prd.md
Using parallel subagents for component design...
- Agent 1: API Gateway and authentication layer
- Agent 2: Product service and business logic
- Agent 3: Data layer (PostgreSQL, schemas)
- Agent 4: Search infrastructure (Elasticsearch)
Synthesizing architecture document...
## System Overview
```
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Clients │────▶│ API GW / │────▶│ Cache │
│ Web/Mobile │ │ Rate Limit │ │ (Redis) │
└─────────────┘ └──────┬──────┘ └──────┬──────┘
│ │
┌──────▼──────┐ │
│ Product │◀───────────┘
│ Service │
└──────┬──────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ PostgreSQL │ │Elasticsearch│ │ Redis │
│ (Primary) │ │ (Search) │ │ (Cache) │
└─────────────┘ └─────────────┘ └─────────────┘
```
## Component Details
### API Gateway
- Kong for routing and rate limiting
- JWT validation
- Request logging
### Product Service
- Node.js + Express
- Handles all business logic
- Connects to all data stores
### PostgreSQL
- Products, categories, inventory tables
- Product variants as JSONB
- Read replicas for scaling
### Elasticsearch
- Product search index
- Autocomplete index
- Updated on product write (async)
### Redis
- Response caching (5 min TTL)
- Session/cart data
- Rate limit counters
## Data Models
### Product Table
```sql
CREATE TABLE products (
id UUID PRIMARY KEY,
sku VARCHAR(100) UNIQUE NOT NULL,
name VARCHAR(255) NOT NULL,
description TEXT,
base_price_cents INTEGER NOT NULL,
sale_price_cents INTEGER,
variants JSONB DEFAULT '[]',
images JSONB DEFAULT '[]',
is_active BOOLEAN DEFAULT true,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
```
### Category Table
```sql
CREATE TABLE categories (
id UUID PRIMARY KEY,
parent_id UUID REFERENCES categories(id),
name VARCHAR(100) NOT NULL,
slug VARCHAR(100) UNIQUE NOT NULL,
description TEXT,
image_url VARCHAR(500),
sort_order INTEGER DEFAULT 0,
is_active BOOLEAN DEFAULT true
);
```
### Inventory Table
```sql
CREATE TABLE inventory (
id UUID PRIMARY KEY,
product_id UUID REFERENCES products(id),
warehouse_id UUID REFERENCES warehouses(id),
quantity INTEGER NOT NULL DEFAULT 0,
reserved INTEGER NOT NULL DEFAULT 0,
low_stock_threshold INTEGER DEFAULT 10,
updated_at TIMESTAMP DEFAULT NOW()
);
```
## API Endpoints
### Products
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /v1/products | List products (paginated) |
| POST | /v1/products | Create product |
| GET | /v1/products/:id | Get product by ID |
| PUT | /v1/products/:id | Update product |
| DELETE | /v1/products/:id | Soft delete product |
| POST | /v1/products/bulk | Bulk import |
### Categories
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /v1/categories | List all categories |
| GET | /v1/categories/tree | Get category hierarchy |
| GET | /v1/categories/:id/products | Products in category |
### Search
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /v1/search | Search products |
| GET | /v1/search/suggest | Autocomplete |
### Inventory
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /v1/inventory/:productId | Get stock levels |
| POST | /v1/inventory/:productId/reserve | Reserve stock |
| POST | /v1/inventory/:productId/release | Release reservation |
## Technology Stack
| Component | Technology | Justification |
|-----------|------------|---------------|
| Runtime | Node.js 20 | Team expertise, async I/O |
| Framework | Express | Simple, flexible |
| Database | PostgreSQL 15 | Existing system, JSONB |
| Search | Elasticsearch 8 | Full-text, facets |
| Cache | Redis 7 | Fast, versatile |
| Gateway | Kong | Open source, plugins |
Saving to: docs/architecture.md
Step 5: Sprint Planning
User: /sprint-planning
Claude: Planning sprints for E-commerce Product Catalog API...
Loading: docs/prd.md, docs/architecture.md
## Sprint Breakdown
### Sprint 1: Foundation (24 pts)
**Goal:** Core product CRUD working
- STORY-001: Product model and migrations (3)
- STORY-002: Create product endpoint (3)
- STORY-003: Read product endpoints (3)
- STORY-004: Update product endpoint (3)
- STORY-005: Delete product (2)
- STORY-008: Category model with hierarchy (5)
- STORY-009: Category CRUD (3)
- STORY-021: API authentication (3)
**Deliverable:** Create and read products and categories
### Sprint 2: Relationships & Search (24 pts)
**Goal:** Full product management with search
- STORY-006: Product variants (5)
- STORY-010: Product-category relationships (3)
- STORY-011: Category tree endpoint (2)
- STORY-012: Elasticsearch setup (3)
- STORY-013: Product indexing (5)
- STORY-014: Basic search endpoint (3)
- STORY-022: Rate limiting (2)
**Deliverable:** Products with variants, categories, and search
### Sprint 3: Inventory & Polish (25 pts)
**Goal:** Complete MVP with inventory
- STORY-015: Faceted search (5)
- STORY-016: Autocomplete (2)
- STORY-017: Inventory model (2)
- STORY-018: Stock endpoints (3)
- STORY-019: Stock reservation (5)
- STORY-020: Low stock alerts (3)
- STORY-007: Bulk import (2)
- STORY-023: Caching layer (3)
**Deliverable:** Full MVP ready for client integration
Saving to: docs/sprint-status.yaml
Creating stories in: docs/stories/
Step 6: Implementation
User: /dev-story STORY-001
Claude: Implementing STORY-001: Product model and migrations
## Acceptance Criteria
- [ ] Product table created with all fields
- [ ] Indexes on SKU and is_active
- [ ] Migration file versioned
- [ ] Sequelize model created
- [ ] Unit tests for model
## Implementation
Creating migration: migrations/001-create-products.js
```javascript
module.exports = {
async up(queryInterface, Sequelize) {
await queryInterface.createTable('products', {
id: {
type: Sequelize.UUID,
defaultValue: Sequelize.UUIDV4,
primaryKey: true
},
sku: {
type: Sequelize.STRING(100),
allowNull: false,
unique: true
},
name: {
type: Sequelize.STRING(255),
allowNull: false
},
description: {
type: Sequelize.TEXT
},
base_price_cents: {
type: Sequelize.INTEGER,
allowNull: false
},
sale_price_cents: {
type: Sequelize.INTEGER
},
variants: {
type: Sequelize.JSONB,
defaultValue: []
},
images: {
type: Sequelize.JSONB,
defaultValue: []
},
is_active: {
type: Sequelize.BOOLEAN,
defaultValue: true
},
created_at: {
type: Sequelize.DATE,
defaultValue: Sequelize.NOW
},
updated_at: {
type: Sequelize.DATE,
defaultValue: Sequelize.NOW
}
});
await queryInterface.addIndex('products', ['sku']);
await queryInterface.addIndex('products', ['is_active']);
},
async down(queryInterface) {
await queryInterface.dropTable('products');
}
};
```
Creating model: src/models/Product.js
[... model code ...]
Creating test: tests/models/Product.test.js
[... test code ...]
## Verification
Running migration: npx sequelize-cli db:migrate
✓ Migration complete
Running tests: npm test -- --grep "Product"
✓ All tests pass
Story complete! Updating docs/stories/STORY-001.md
Final Result
After completing all sprints, you have:
ecommerce-catalog-api/
├── bmad/
│ └── config.yaml
├── docs/
│ ├── product-brief.md
│ ├── prd.md
│ ├── architecture.md
│ ├── sprint-status.yaml
│ └── stories/
│ ├── STORY-001.md through STORY-023.md
├── src/
│ ├── index.js
│ ├── models/
│ ├── routes/
│ ├── services/
│ └── middleware/
├── tests/
├── migrations/
└── package.json
Example 2: CLI Tool (Level 1)
Building a simple command-line tool for converting file formats.
Quick Workflow
For Level 1 projects, skip the product brief and go straight to tech spec:
User: I want to build a CLI tool that converts markdown to HTML.
User: /workflow-init
> Project: md2html CLI
> Type: library
> Level: 1
User: /tech-spec
Claude: Creating tech spec for md2html CLI...
## Overview
A command-line tool to convert Markdown files to HTML.
## Features
- Single file conversion: md2html input.md
- Batch conversion: md2html *.md
- Custom template: md2html -t template.html input.md
- Watch mode: md2html -w input.md
- Output to file: md2html -o output.html input.md
## Technical Implementation
### Dependencies
- commander: CLI argument parsing
- marked: Markdown parsing
- chokidar: File watching
### Files
- bin/md2html.js - CLI entry point
- src/converter.js - Conversion logic
- src/template.js - HTML template handling
- tests/*.test.js - Unit tests
### Usage Examples
```bash
# Basic conversion (outputs to stdout)
md2html README.md
# Save to file
md2html -o docs/readme.html README.md
# Batch convert
md2html -o build/ docs/*.md
# Watch mode
md2html -w -o build/readme.html README.md
```
## Acceptance Criteria
- [ ] Convert single .md file to HTML
- [ ] Support output file option
- [ ] Support batch conversion with glob
- [ ] Support custom HTML template
- [ ] Support watch mode
- [ ] Handle errors gracefully
- [ ] Show help with --help
- [ ] Show version with --version
## Stories (7 points total)
1. **CLI setup with commander** (2 pts)
2. **Basic markdown to HTML conversion** (2 pts)
3. **Output file and batch conversion** (2 pts)
4. **Watch mode** (1 pt)
Saving to: docs/tech-spec.md
User: /sprint-planning
[Single sprint with 4 stories]
User: /dev-story STORY-001
[Implementation]
Example 3: Bug Fix (Level 0)
The minimal BMAD workflow for a single atomic change.
User: There's a bug where user sessions expire after 5 minutes
instead of 1 hour. I need to fix it.
User: /workflow-init
> Project: Fix session timeout bug
> Type: other
> Level: 0
User: /tech-spec
Claude: Creating minimal tech spec for bug fix...
## Issue
User sessions expire after 5 minutes instead of configured 1 hour.
## Root Cause
In config/auth.js, SESSION_TIMEOUT is set to 300000 (5 min)
instead of 3600000 (1 hour).
## Fix
Change line 12 of config/auth.js:
```javascript
// Before
SESSION_TIMEOUT: 300000,
// After
SESSION_TIMEOUT: 3600000,
```
## Testing
1. Log in as test user
2. Wait 10 minutes
3. Verify session still active
4. Wait 65 minutes
5. Verify session expired
## Acceptance Criteria
- [ ] Session lasts 1 hour
- [ ] Existing sessions not affected
- [ ] No breaking changes
Saving to: docs/tech-spec.md
User: /dev-story STORY-001
Claude: Implementing session timeout fix...
[Edits config/auth.js line 12]
[Runs tests]
Bug fix complete!
Example 4: Mobile App (Level 3)
A complex project with UX design included.
Project Scope
Building a fitness tracking app with:
- Workout logging
- Progress tracking
- Social features
- Wearable integration
Workflow with UX Design
User: /workflow-init
> Project: FitTrack Mobile App
> Type: mobile-app
> Level: 3
User: /product-brief
[Comprehensive product brief for fitness app]
User: /prd
[Detailed PRD with 35 stories]
User: /create-ux-design
Claude: Creating UX designs for FitTrack...
Launching parallel UX design agents...
- Agent 1: User personas and research
- Agent 2: Onboarding and authentication flows
- Agent 3: Core workout flows (log, track, complete)
- Agent 4: Social and progress flows
Synthesizing UX design document...
## User Personas
### Primary: Active Alex
- 28, goes to gym 4x/week
- Wants to track progress
- Motivated by data and streaks
### Secondary: Beginner Beth
- 35, starting fitness journey
- Needs guidance and encouragement
- Intimidated by complex apps
## User Flows
### Onboarding Flow
1. Download → 2. Sign up → 3. Set goals → 4. Connect wearable →
5. First workout prompt → 6. Dashboard
### Log Workout Flow
1. Tap + → 2. Select workout type → 3. Start timer →
4. Log exercises → 5. Complete → 6. See summary
### View Progress Flow
1. Tap Progress → 2. Select metric → 3. View chart →
4. Filter date range → 5. Share achievement
## Wireframes
### Dashboard
```
┌─────────────────────────┐
│ FitTrack [🔔] [👤] │
├─────────────────────────┤
│ Good morning, Alex! │
│ │
│ ┌─────────┐ ┌────────┐ │
│ │ 🔥 12 │ │ 💪 4 │ │
│ │ Streak │ │ This │ │
│ │ │ │ Week │ │
│ └─────────┘ └────────┘ │
│ │
│ Today's Goal │
│ [████████░░] 80% │
│ │
│ Quick Start │
│ [Run] [Lift] [Yoga] │
│ │
│ Recent Activity │
│ • Chest Day - 45m │
│ • Morning Run - 5k │
│ │
│ [────] [📊] [+] [🏆] │
└─────────────────────────┘
```
## Design System
### Colors
Primary: #FF6B35 (Orange - energy)
Secondary: #004E89 (Blue - trust)
Success: #2EC4B6 (Teal - achievement)
Background: #F7F7F7
### Typography
- Headings: Montserrat Bold
- Body: Open Sans Regular
- Numbers: Montserrat Bold (for stats)
## Accessibility
- [ ] Large touch targets (48px)
- [ ] High contrast mode
- [ ] VoiceOver/TalkBack labels
- [ ] Reduced motion option
Saving to: docs/ux-design.md
User: /architecture
Claude: Designing mobile app architecture...
## System Overview
### Mobile App (React Native)
- iOS and Android from single codebase
- Offline-first with sync
- Push notifications
### Backend Services
- Auth service (Firebase Auth)
- Workout service (Node.js)
- Social service (Node.js)
- Analytics service (Mixpanel)
### Integrations
- Apple HealthKit
- Google Fit
- Fitbit API
- Strava API
[... complete architecture ...]
User: /sprint-planning
Claude: Planning sprints...
## Sprint Overview
### Sprint 1: Foundation (26 pts)
Auth, onboarding, basic UI
### Sprint 2: Core Workout (28 pts)
Workout logging, timer, exercises
### Sprint 3: Progress (24 pts)
Charts, history, stats
### Sprint 4: Social (25 pts)
Friends, feed, achievements
### Sprint 5: Integrations (22 pts)
HealthKit, wearables, sync
### Sprint 6: Polish (15 pts)
Performance, offline, testing
Total: 140 pts over 6 sprints
Example 5: Feature Research (Creative Intelligence)
Using BMAD for research before committing to a project.
Brainstorming Session
User: We're thinking about adding AI features to our product.
I want to explore possibilities before committing.
User: /brainstorm
Claude: What topic would you like to brainstorm?
> AI-powered features for our project management tool
Which techniques?
> SCAMPER, Six Thinking Hats, SWOT
## SCAMPER Analysis
**Substitute**
- Replace manual task estimation with AI predictions
- Substitute status updates with auto-detection
**Combine**
- Combine chat + task creation (NLP to create tasks from messages)
- Merge reporting + insights (AI-generated reports)
**Adapt**
- Adapt GitHub Copilot's approach for task suggestions
- Adapt Notion's AI summarization for meeting notes
**Modify**
- Smart notifications (AI determines importance)
- Predictive resource allocation
**Put to other uses**
- Use project data to train company-specific models
- Cross-project pattern recognition
**Eliminate**
- Remove manual time tracking (auto-detect from activity)
- Eliminate status meetings (AI-generated summaries)
**Reverse**
- Instead of users finding tasks, tasks find users
- Proactive blocker detection vs. reactive reporting
## Six Thinking Hats
**White Hat (Facts)**
- Competitors: Asana, Monday, ClickUp all adding AI
- 67% of PM tools will have AI by 2025
- User survey: 45% want "smart suggestions"
**Red Hat (Emotions)**
- Excitement about productivity gains
- Fear of AI replacing jobs
- Frustration with "AI-washing" features
**Black Hat (Risks)**
- Privacy concerns with project data
- Inaccurate predictions erode trust
- Expensive API costs
- Vendor lock-in (OpenAI, etc.)
**Yellow Hat (Benefits)**
- Save 5+ hours/week per user
- Better estimations (reduce overruns by 30%)
- Competitive differentiation
**Green Hat (Creativity)**
- "AI Project Manager" assistant persona
- Voice interface for hands-free updates
- Predictive burnout detection
- Auto-generate project retrospectives
**Blue Hat (Process)**
- Start with estimation (highest ROI)
- Beta with 10 power users
- Measure time saved quantitatively
## SWOT Analysis
**Strengths**
- Large dataset of completed projects
- Strong user trust
- Technical team capable
**Weaknesses**
- No ML expertise in-house
- Limited budget for APIs
- Privacy-first brand may conflict
**Opportunities**
- First mover in our niche
- Partner with AI startups
- Premium AI tier
**Threats**
- Big players (Microsoft, Atlassian) have more data
- AI commoditization
- Regulation (EU AI Act)
## Recommendations
### Quick Wins (1-2 months)
1. **Smart task estimation** - Train on historical data
2. **Meeting summary** - Use GPT to summarize notes
### Medium Term (3-6 months)
3. **Predictive blockers** - Flag at-risk tasks
4. **Auto-categorization** - Tag and route tasks
### Long Term (6-12 months)
5. **AI assistant** - Natural language project management
6. **Cross-project insights** - Pattern recognition
Saving to: docs/brainstorm-ai-features.md
User: /research
Claude: What type of research?
> Competitive analysis
Focus?
> AI features in project management tools
## Competitive Analysis: AI in Project Management
### Market Overview
$6.7B market, 13% CAGR, AI adoption accelerating
### Competitor AI Features
#### Asana
- **Smart Fields:** Auto-populate custom fields
- **Workflow recommendations:** Suggest automations
- **Goals AI:** Generate goal suggestions
- Status: Generally available
- Pricing: Included in Business+
#### Monday.com
- **AI Assistant:** Natural language queries
- **Smart suggestions:** Task recommendations
- **Summarization:** Meeting and doc summaries
- Status: Beta
- Pricing: Enterprise only
#### ClickUp
- **ClickUp AI:** Writing assistant, summarization
- **Task creation:** From natural language
- **Brainstorming:** AI-powered ideation
- Status: Add-on ($5/user)
- Pricing: Separate purchase
#### Notion
- **Notion AI:** Writing, summarization, translation
- **Q&A:** Ask questions about workspace
- Status: GA
- Pricing: $8/user add-on
### Feature Comparison
| Feature | Asana | Monday | ClickUp | Notion | Us |
|---------|-------|--------|---------|--------|-----|
| Estimation | - | - | - | - | ★ Opportunity |
| Summarization | - | ✓ | ✓ | ✓ | Plan |
| Writing assist | - | - | ✓ | ✓ | - |
| Smart fields | ✓ | - | - | - | Plan |
| NL queries | - | ✓ | - | ✓ | Long-term |
### Pricing Models
1. **Included in tier:** Asana (high tier lock-in)
2. **Add-on:** ClickUp, Notion ($5-8/user)
3. **Usage-based:** Rare, emerging
### Differentiation Opportunity
Gap: **Predictive project health**
No competitor offers:
- Risk prediction based on patterns
- Resource optimization suggestions
- Burnout early warning
- Delivery date confidence scores
This is data-intensive, requires historical projects,
and aligns with our strength.
### Recommendations
1. **Launch with estimation** - Clear differentiation
2. **Pricing:** Add-on ($3-5/user) - accessible
3. **Privacy-first approach** - Optional, on-premise option
4. **Partner strategy** - Integrate multiple LLM providers
Saving to: docs/research-ai-competition.md
User: Based on this research, I want to build the AI estimation feature.
User: /workflow-init
> Project: AI Task Estimation Feature
> Level: 2
[Continue with regular BMAD workflow]
Common Patterns
Pattern 1: Subagent Coordination
The foundation of BMAD’s efficiency - decompose, parallelize, synthesize:
Step 1: Context Preparation
Main agent writes shared context to bmad/context/
Step 2: Parallel Execution
Launch N independent subagents (each with 200K tokens)
- Task tool with run_in_background: true
- Each agent reads context, executes subtask
- Each agent writes output to bmad/outputs/
Step 3: Synthesis
Main agent collects all outputs
Resolves conflicts, ensures consistency
Writes final deliverable to docs/
Benefits:
- N × 200K effective token budget
- 3-4x faster execution
- Deeper analysis per subtask
Pattern 2: Research → Build
/brainstorm # Explore ideas
/research # Validate market
/workflow-init # Start project
/product-brief # Define scope
...
Pattern 3: Quick Prototype
/workflow-init # Level 1
/tech-spec # Minimal requirements
/dev-story STORY-001
Pattern 4: Enterprise Project
/workflow-init # Level 3-4
/product-brief # Comprehensive
/prd # Detailed requirements
/create-ux-design # Full UX
/architecture # Complete design
/solutioning-gate-check # Validate
/sprint-planning # Multiple sprints
Pattern 5: Custom Workflow
/create-agent # Security Engineer
/create-workflow # /security-audit
[Use new agent in workflow]
Tips for Success
1. Right-Size Your Project
Don’t over-engineer a bug fix with full PRD. Don’t under-plan an enterprise system with just a tech spec.
| If your project… | Use level… |
|---|---|
| Takes <1 day | 0 |
| Takes <1 week | 1 |
| Takes 1-4 weeks | 2 |
| Takes 1-3 months | 3 |
| Takes 3+ months | 4 |
2. Let Phases Build on Each Other
Each phase uses outputs from previous phases. Don’t skip ahead:
- PRD reads product brief
- Architecture reads PRD
- Sprint planning reads both
- Stories read architecture
3. Use /workflow-status Often
When in doubt, check status. BMAD will tell you exactly what to do next.
4. Iterate Within Phases
It’s okay to revise. Run /prd again to update requirements. Run /architecture to refine design.
5. Customize for Your Process
Use /create-agent and /create-workflow to add domain-specific capabilities.
Next Steps
- Review Configuration options
- Check Troubleshooting if you hit issues
- Return to Commands Reference for details