DEV Community: JackTT

BMAD cheat sheet

JackTT — Wed, 11 Mar 2026 09:19:14 +0000

Module 1: BMM (Business Model Management)

The main product development module, designed for end-to-end project delivery following the BMad Method.

Phase 1 — Analysis

Command	Code	What is this	When to use
`/bmad-brainstorming`	BP	Facilitated brainstorming using one or more structured techniques	At the very start, when exploring ideas or when stuck generating them
`/bmad-bmm-market-research`	MR	Competitive landscape, customer needs, and market trends analysis	Before committing to a product direction; validate there's a market
`/bmad-bmm-domain-research`	DR	Deep dive into industry domain, terminology, and subject matter	When entering an unfamiliar domain or needing expert vocabulary
`/bmad-bmm-technical-research`	TR	Technical feasibility study, architecture options, implementation approaches	When tech choices are unclear or high-risk before planning begins
`/bmad-bmm-create-product-brief`	CB	Guided session to crystallize the product idea into a brief	After brainstorming; when you need to lock down "what are we building?"

Phase 2 — Planning

Command	Code	What is this	When to use
`/bmad-bmm-create-prd`	CP	[Required] Expert-facilitated session to produce the Product Requirements Document	After analysis is done; the PRD gates entry into solutioning
`/bmad-bmm-validate-prd`	VP	Checks that the PRD is comprehensive, lean, well-organized, and cohesive	After creating the PRD; run before architecture to catch gaps early
`/bmad-bmm-edit-prd`	EP	Improve and enhance an existing PRD	When the PRD fails validation or stakeholders request changes
`/bmad-bmm-create-ux-design`	CU	Guides the planning of UX patterns and design specifications	Strongly recommended when a UI is a primary part of the product

Phase 3 — Solutioning

Command	Code	What is this	When to use
`/bmad-bmm-create-architecture`	CA	[Required] Guided workflow to document all technical decisions	After PRD is approved; establishes the technical foundation before stories
`/bmad-bmm-create-epics-and-stories`	CE	[Required] Breaks requirements into structured Epics and User Stories	After architecture is set; creates the delivery roadmap
`/bmad-bmm-check-implementation-readiness`	IR	[Required] Validates PRD, UX, Architecture, and Epics/Stories are all aligned	Final gate before implementation; run with a high-quality LLM if available

Phase 4 — Implementation

Command	Code	What is this	When to use
`/bmad-bmm-sprint-planning`	SP	[Required] Generates the sprint plan from epics — the implementation kick-off	Once readiness is confirmed; produces the plan all dev agents will follow
`/bmad-bmm-sprint-status`	SS	Summarizes current sprint status and routes to the next workflow	Anytime during a sprint to check progress
`/bmad-bmm-create-story`	CS	[Required] Prepares the next story in the sprint plan with full context	Start of every story cycle; run before Dev Story
`/bmad-bmm-dev-story`	DS	[Required] Executes story implementation tasks and tests	After story is created and validated; the main coding step
`/bmad-bmm-code-review`	CR	Adversarial code review; routes back to Dev Story if issues found	After Dev Story completes; the final checkpoint before moving to next story
`/bmad-bmm-retrospective`	ER	Post-epic review to extract lessons learned and assess success	Optional; at the end of each epic or when something went significantly wrong

Anytime (BMM)

These BMM commands work at any point in the workflow:

Command	Code	What is this	When to use
`/bmad-bmm-document-project`	DP	Analyzes an existing codebase and produces useful documentation	For brownfield/legacy projects before starting new development
`/bmad-bmm-generate-project-context`	GPC	Scans codebase and generates a lean LLM-optimized `project-context.md`	Essential for brownfield projects; run before any dev agent work
`/bmad-bmm-quick-spec`	QS	Fast one-page tech spec for small changes or features	Quick one-offs, small changes, brownfield additions; not for complex features
`/bmad-bmm-quick-dev`	QD	Implement small tasks without full planning overhead	Single ad-hoc tasks not already in the sprint plan
`/bmad-bmm-correct-course`	CC	Navigates significant mid-sprint changes (may trigger PRD update, architecture redo, etc.)	When a major blocker, pivot, or requirement change disrupts the current plan

Agent-based BMM commands (load agent first, then invoke by code):

Code	Agent	What is this	When to use
WD	📚 Paige (Tech Writer) — `/bmad-bmm-tech-writer`	Write a detailed document following documentation best practices	Producing any formal documentation artifact
US	📚 Paige (Tech Writer)	Update `documentation-standards.md` with project-specific conventions	When you discover missing or incorrect documentation conventions
MG	📚 Paige (Tech Writer)	Generate a Mermaid diagram from a description	Visualizing flows, architecture, or sequences
VD	📚 Paige (Tech Writer)	Review a document against documentation standards	Quality check before publishing or finalizing any document
EC	📚 Paige (Tech Writer)	Create clear technical explanations with examples and diagrams	When a concept needs to be explained to the team or new members

Module 2: CIS (Creative Innovation Suite)

Focused on creative thinking, innovation, and strategic problem solving. All CIS commands work anytime.

Command	Code	What is this	When to use
`/bmad-cis-innovation-strategy`	IS	Identify disruption opportunities and architect business model innovation	When exploring new business models or seeking competitive advantage
`/bmad-cis-problem-solving`	PS	Apply systematic problem-solving methodologies to complex challenges	When stuck on a difficult problem or needing a structured approach
`/bmad-cis-design-thinking`	DT	Guide human-centered design using empathy-driven methodologies	For user-centered design challenges or improving user experience
`/bmad-cis-brainstorming`	BS	Facilitate brainstorming using proven structured techniques	Early in ideation, or whenever idea generation is needed
`/bmad-cis-storytelling`	ST	Craft compelling narratives using proven story frameworks	When preparing persuasive communications, pitches, or story-driven content

Module 3: Core (Universal Tools)

These commands work across all modules and all workflow phases. No module context required.

Command	Code	What is this	When to use
`/bmad-brainstorming`	BSP	Generate diverse ideas through interactive techniques	Any time creative input is needed
`/bmad-party-mode`	PM	Orchestrate a multi-agent discussion with all installed agents	When you want multiple agent perspectives or collaborative agent input
`/bmad-help`	BH	Show the next recommended workflow steps based on context	When you're unsure what to do next
`/bmad-index-docs`	ID	Create a lightweight index of available docs for quick LLM scanning	Before starting work in a docs-heavy folder so agents can navigate quickly
`/bmad-shard-doc`	SD	Split a large document into smaller files organized by section	When a doc exceeds ~500 lines and becomes hard to manage
`/bmad-editorial-review-prose`	EP	Review prose for clarity, tone, and communication issues	After drafting any written content to polish it
`/bmad-editorial-review-structure`	ES	Propose cuts, reorganization, and simplification while preserving comprehension	When a doc was assembled from multiple sub-processes or feels disorganized
`/bmad-review-adversarial-general`	AR	Critically review content to find issues and weaknesses	Quality assurance before finalizing any deliverable or document
`/bmad-review-edge-case-hunter`	ECH	Walk every branch and boundary in code/content, report only unhandled edge cases	Use alongside adversarial review for orthogonal, method-driven coverage

Quick Cheat Sheet: Where am I? What do I run?

Stage	Must-run commands
Starting a new product	`/bmad-bmm-create-product-brief` → `/bmad-bmm-create-prd`
Planning tech	`/bmad-bmm-create-architecture` → `/bmad-bmm-create-epics-and-stories` → `/bmad-bmm-check-implementation-readiness`
Starting a sprint	`/bmad-bmm-sprint-planning`
Each story cycle	`/bmad-bmm-create-story` → `/bmad-bmm-dev-story` → `/bmad-bmm-code-review`
Brownfield / existing codebase	`/bmad-bmm-generate-project-context` first, then proceed
Quick one-off task	`/bmad-bmm-quick-spec` → `/bmad-bmm-quick-dev`
Something went wrong	`/bmad-bmm-correct-course`
Don't know what's next	`/bmad-help`

This content is summarized by /bmad-help, the agent that helps us with anything about BMAD. You can also ask it for more details about BMAD usage.

BMAD Quick Flow

JackTT — Wed, 11 Mar 2026 06:49:07 +0000

BMAD Quick Flow

Quick Flow is the lean path inside the BMAD Method. It skips the full planning ceremony (PRD → Architecture → Epics → Sprint Planning) and gets you from idea to shipped code in as few steps as possible. Use it for small changes, isolated features, or brownfield additions where the full workflow would be overkill.

The Three Commands

1. `/bmad-agent-bmm-quick-flow-solo-dev` — The Hub Agent

What it is: Loads Barry, an AI persona acting as an Elite Full-Stack Developer and Quick Flow specialist. Barry presents an interactive menu of all Quick Flow operations in one place.

Barry's menu:

Code	Action
`QS`	Quick Spec — create a tech spec
`QD`	Quick Dev — implement a spec
`CR`	Code Review
`PM`	Party Mode (multi-agent discussion)
`DA`	Dismiss Agent

When to use it:

You want a single entry point and prefer to pick your next step interactively
You're new to Quick Flow and want guidance on what to do next

When to skip it:

You already know what you want — call /bmad-bmm-quick-spec or /bmad-bmm-quick-dev directly instead

2. `/bmad-bmm-quick-spec` — Write a Technical Spec

What it is: A conversational workflow that produces an implementation-ready technical specification. It asks you sharp questions about the feature, investigates existing code, and outputs a complete, self-contained spec file.

What "ready for development" means:

Criterion	Requirement
Actionable	Every task has a specific file path and a clear action
Logical	Tasks are ordered by dependency (lowest level first)
Testable	All acceptance criteria follow Given / When / Then
Complete	All investigation results are inlined — no placeholders or TBDs
Self-contained	A fresh agent can implement the feature without reading the conversation history

When to use it:

The change is small to medium in scope and does not need a full PRD
You are adding to a well-established codebase pattern
You want to plan before you code — produce the spec first, implement later
You need a written record of exactly what will be changed and why

When to skip it:

The task is so simple it fits in one sentence — just tell Quick Dev directly
The change is large and complex — use the full BMM workflow instead

3. `/bmad-bmm-quick-dev` — Implement the Spec

What it is: A step-by-step implementation workflow. The AI acts as an autonomous developer: it reads the tech spec (or takes direct instructions), follows existing code patterns, writes the code, and runs tests.

How it works internally:

Mode detection — Did you provide a tech spec file, or are you giving direct instructions?
Code investigation — AI reads relevant files to understand the existing patterns
Implementation — Tasks are executed sequentially, one at a time
Verification — Tests are run and output is confirmed after each change

When to use it:

You have a spec from /bmad-bmm-quick-spec and are ready to implement
The task is small enough to describe directly without a formal spec
You need a one-off change that is not part of the current sprint plan

When to skip it:

The change spans multiple stories or epics — use the full Dev Story workflow (/bmad-bmm-dev-story) instead

Typical Workflows

Spec first, then implement (recommended for anything non-trivial)

/bmad-bmm-quick-spec
  → Discover requirements through conversation
  → AI investigates existing code
  → Outputs a tech-spec file

/bmad-bmm-quick-dev
  → Point it at the spec file
  → AI implements all tasks sequentially
  → Tests run after each change

Direct implementation (for trivial changes)

/bmad-bmm-quick-dev
  → Describe what you want in plain language
  → AI implements immediately

Using the hub agent

/bmad-agent-bmm-quick-flow-solo-dev
  → Barry loads and shows the menu
  → Select QS to create a spec
  → Select QD to implement it

Quick Flow vs. Full BMM Workflow

Situation	Use
New product, complex feature, needs PRD + Architecture	Full BMM flow
Small feature, brownfield addition, well-known pattern	Quick Flow
One-off fix or change during an active sprint	`/bmad-bmm-quick-dev` directly
Unsure what to do next	`/bmad-help` or load Barry via `/bmad-agent-bmm-quick-flow-solo-dev`

Rule of thumb: If you'd feel uncomfortable skipping a PRD and architecture doc, use the full flow. If the change fits on one page of notes, Quick Flow is the right tool.

This content is summarized by /bmad-help, the agent that helps us with anything about BMAD. You can also ask it for more details about BMAD usage.

BMAD Standard Workflow

JackTT — Wed, 11 Mar 2026 06:38:17 +0000

BMAD Standard Workflow Guide

Overview

BMAD (Business Methods and Development) is a structured AI-assisted workflow framework that guides teams from product discovery through implementation. It maps closely to real Scrum ceremonies and artifacts, providing AI agents for each role in the process.

Folder Structure

Folder	Purpose
`_bmad/`	Framework core — contains agent definitions, workflow specs, tasks, and configuration. Do not modify manually.
`_bmad/_config/`	BMAD catalog (`bmad-help.csv`) and global settings.
`_bmad/_memory/`	Agent memory files — agents store learned standards and preferences here across sessions.
`_bmad/bmm/`	BMM module — all business/product workflows (PRD, architecture, stories, implementation).
`_bmad/core/`	Core utilities — brainstorming, help, indexing, review, and other cross-cutting tools.
`_bmad-output/planning-artifacts/`	Output: All planning-phase documents (PRD, architecture, epics/stories, UX design, research).
`_bmad-output/implementation-artifacts/`	Output: All implementation-phase artifacts (sprint plan, story files, retrospectives).
`_bmad-output/`	General output folder for miscellaneous outputs (project context, etc.).
`docs/`	Project knowledge base — documentation files that AI agents read for context (architecture references, tech stack, onboarding guides).

BMAD Standard Flow

The full flow consists of four sequential phases. Required steps must be completed before advancing to the next phase.

Phase 1 — Analysis

Scrum Equivalent: Pre-Sprint / Product Discovery

Establish context and understand the problem space before writing any requirements.

Step	Command	Required	Output	Output Folder	Scrum Equivalent
Brainstorm Project	`/bmad-brainstorming`	No	Brainstorming session doc	`_bmad-output/planning-artifacts/`	Pre-sprint ideation / product discovery workshop
Market Research	`/bmad-bmm-market-research`	No	Research documents	`_bmad-output/planning-artifacts/`	Competitor analysis in discovery sprint
Domain Research	`/bmad-bmm-domain-research`	No	Research documents	`_bmad-output/planning-artifacts/`	Domain knowledge deep-dive before backlog refinement
Technical Research	`/bmad-bmm-technical-research`	No	Research documents	`_bmad-output/planning-artifacts/`	Technical spike / feasibility study
Create Product Brief	`/bmad-bmm-create-product-brief`	No	Product brief	`_bmad-output/planning-artifacts/`	Product vision statement / elevator pitch doc

All Phase 1 steps are optional. They feed context into the PRD in Phase 2.

Phase 2 — Planning

Scrum Equivalent: Product Backlog Creation & Refinement

Define what to build. The PRD is the central required artifact.

Step	Command	Required	Output	Output Folder	Scrum Equivalent
Create PRD	`/bmad-bmm-create-prd`	Yes	Product Requirements Document	`_bmad-output/planning-artifacts/`	Product Owner writing the product backlog / vision doc
Validate PRD	`/bmad-bmm-validate-prd`	No	PRD validation report	`_bmad-output/planning-artifacts/`	Peer review / Definition of Ready check on backlog
Edit PRD	`/bmad-bmm-edit-prd`	No	Updated PRD	`_bmad-output/planning-artifacts/`	Backlog refinement session — incorporating stakeholder feedback
Create UX Design	`/bmad-bmm-create-ux-design`	No	UX design specification	`_bmad-output/planning-artifacts/`	UX/UI design sprint or prototype review

Note: Create PRD is the only required step in this phase. Validate and Edit PRD are recommended for quality but not blocking.

Phase 3 — Solutioning

Scrum Equivalent: Sprint 0 / Technical Refinement

Define how to build it. Architecture and story decomposition must be complete before implementation begins.

Step	Command	Required	Output	Output Folder	Scrum Equivalent
Create Architecture	`/bmad-bmm-create-architecture`	Yes	Architecture document	`_bmad-output/planning-artifacts/`	Architecture design review / technical kick-off meeting
Create Epics & Stories	`/bmad-bmm-create-epics-and-stories`	Yes	Epics and stories list	`_bmad-output/planning-artifacts/`	Backlog decomposition — breaking epics into user stories
Check Implementation Readiness	`/bmad-bmm-check-implementation-readiness`	Yes	Readiness report	`_bmad-output/planning-artifacts/`	Definition of Ready check across PRD + UX + Architecture + Stories

All three steps are required. The readiness check validates alignment across all prior artifacts before development starts.

Phase 4 — Implementation

Scrum Equivalent: Sprint Execution

Build and ship. Stories are worked one at a time through a defined cycle.

Step	Command	Required	Output	Output Folder	Scrum Equivalent
Sprint Planning	`/bmad-bmm-sprint-planning`	Yes	Sprint status / plan	`_bmad-output/implementation-artifacts/`	Sprint Planning ceremony — selecting stories and creating the sprint plan
Sprint Status	`/bmad-bmm-sprint-status`	No	Status summary	(inline)	Daily Standup / sprint burndown review
Create Story	`/bmad-bmm-create-story`	Yes	Enriched story file	`_bmad-output/implementation-artifacts/`	Story kick-off — Scrum Master prepares story context for dev
Validate Story	`/bmad-bmm-create-story` (Validate Mode)	No	Story validation report	`_bmad-output/implementation-artifacts/`	Pre-development story review / Three Amigos
Dev Story	`/bmad-bmm-dev-story`	Yes	Implemented code + tests	(codebase)	Sprint execution — developer implements the story
QA Automation Test	`/bmad-bmm-qa-automate`	No	Automated test suite	`_bmad-output/implementation-artifacts/`	QA review / automated test coverage after implementation
Code Review	`/bmad-bmm-code-review`	No	Code review report	(inline)	Pull request code review
Retrospective	`/bmad-bmm-retrospective`	No	Retrospective doc	`_bmad-output/implementation-artifacts/`	Sprint Retrospective at end of epic

Story Cycle (per story):

Create Story → Validate Story → Dev Story → Code Review
     ↑                                           |
     └── (if issues found, back to Dev Story) ───┘
                                                 |
                              (next story) → Create Story
                              (epic done)  → Retrospective

Anytime Tools

These tools can be used at any phase, independent of workflow state.

Tool	Command	Purpose
Quick Spec	`/bmad-bmm-quick-spec`	Lightweight spec for small/simple tasks without full planning
Quick Dev	`/bmad-bmm-quick-dev`	Implement small tasks directly without full process
Correct Course	`/bmad-bmm-correct-course`	Handle significant mid-sprint changes or pivots
Document Project	`/bmad-bmm-document-project`	Generate docs for an existing (brownfield) codebase → `docs/`
Generate Project Context	`/bmad-bmm-generate-project-context`	Produce `project-context.md` for AI agent grounding → `_bmad-output/`
Write Document	Load `/bmad:DITA:agent:tech-writer`, ask "WD"	Write any document following documentation standards → `docs/`
BMAD Help	`/bmad-help`	Get guidance on what to do next at any point
Brainstorming	`/bmad-brainstorming`	Ideation session using creative techniques

Summary: Output Locations

Phase	Outputs Go To
Analysis	`_bmad-output/planning-artifacts/`
Planning	`_bmad-output/planning-artifacts/`
Solutioning	`_bmad-output/planning-artifacts/`
Implementation	`_bmad-output/implementation-artifacts/`
Project Knowledge / Docs	`docs/`
General Output	`_bmad-output/`

Key Principles

Run each workflow in a fresh context window — do not chain multiple workflows in the same conversation.
Required steps block progress — you cannot skip Create PRD, Create Architecture, Create Epics & Stories, Check Implementation Readiness, Sprint Planning, Create Story, or Dev Story.
Artifacts drive state — BMAD determines workflow state by looking for output files, not by tracking session history.
Use a different LLM for validation steps — Validate PRD, Validate Story, and Check Implementation Readiness benefit from a separate high-quality model to avoid self-confirmation bias.

This content is summarized by /bmad-help, the agent that helps us with anything about BMAD. You can also ask it for more details about BMAD usage.

Understanding the Agents in the BMAD

JackTT — Wed, 11 Mar 2026 06:24:43 +0000

BMAD Agents

BMAD uses a team of specialized agents, each representing a distinct role in the software development lifecycle. Every agent has a unique persona, focused capabilities, and a set of workflows they execute. Load an agent by running its slash command in a fresh context window.

Part 1 — 📊 Mary, Business Analyst

Command: /bmad-agent-bmm-analyst
Code: analyst
Title: Business Analyst

Who She Is

Mary is a strategic business analyst with deep expertise in market research, competitive analysis, and requirements elicitation. She approaches every problem like a treasure hunter — thrilled by clues, energized when patterns emerge. She draws on Porter's Five Forces, SWOT analysis, root cause analysis, and competitive intelligence methodologies.

What She Does

Command	Description
`BP`	Brainstorm Project — Facilitated ideation through structured techniques, produces a final report
`MR`	Market Research — Market analysis, competitive landscape, customer needs and trends
`DR`	Domain Research — Industry deep dive, subject matter expertise and terminology
`TR`	Technical Research — Technical feasibility, architecture options and implementation approaches
`CB`	Create Brief — Guided experience to define your product idea into an executive brief
`DP`	Document Project — Analyze an existing codebase and produce useful docs for humans and LLMs

When to Use Her

Use Mary at the very start of any project, especially when:

You have an idea but haven't validated it yet
You need to understand your market or domain before writing any specs
You want to explore multiple approaches and need structured brainstorming
You're onboarding an AI agent to an existing (brownfield) project

Mary is the entry point into the BMM workflow. Most projects start with her.

Part 2 — 📋 John, Product Manager

Command: /bmad-agent-bmm-pm
Code: pm
Title: Product Manager

Who He Is

John is a veteran product manager with 8+ years launching B2B and consumer products. He asks "WHY?" relentlessly — like a detective cutting through fluff to what actually matters. He uses Jobs-to-be-Done, opportunity scoring, and user-centered design frameworks to discover what users need (not just what they say they want).

What He Does

Command	Description
`CP`	Create PRD — Expert-facilitated Product Requirements Document
`VP`	Validate PRD — Checks the PRD is comprehensive, lean, well-organized, and cohesive
`EP`	Edit PRD — Update or improve an existing PRD
`CE`	Create Epics and Stories — Break down a PRD into epics and user stories
`IR`	Implementation Readiness — Verify PRD, UX, Architecture, and Stories are all aligned
`CC`	Course Correction — Handle major mid-implementation change requests

When to Use Him

Use John in Phase 2 (Planning), after initial research, when:

You need to produce a formal PRD from your idea or brief
You need to break a PRD into development-ready epics and stories
You want to validate that your product requirements are solid before building
You discover a significant change is needed mid-sprint

Creating the PRD (CP) is the only required step before moving to solutioning.

Part 3 — 🎨 Sally, UX Designer

Command: /bmad-agent-bmm-ux-designer
Code: ux-designer
Title: UX Designer

Who She Is

Sally is a senior UX designer with 7+ years creating intuitive experiences across web and mobile. She paints pictures with words, telling user stories that make you feel the problem. She's an empathetic advocate who balances creative storytelling with rigorous attention to edge cases.

What She Does

Command	Description
`CU`	Create UX — Guided workflow to define UX patterns, flows, and specifications

When to Use Her

Use Sally in Phase 2 (Planning) after the PRD is created, when:

Your project has a significant UI component
You need interaction design details that go beyond the PRD
You want to define user flows, screen patterns, and UI specifications before architecture
You want to ensure UX decisions inform the technical architecture

Sally is optional but strongly recommended when a UI is the primary deliverable.

Part 4 — 🏗️ Winston, Architect

Command: /bmad-agent-bmm-architect
Code: architect
Title: System Architect

Who He Is

Winston is a senior architect with expertise in distributed systems, cloud infrastructure, and API design. He speaks in calm, pragmatic tones — balancing "what could be" with "what should be." He embraces boring technology for stability and connects every technical decision to business value.

What He Does

Command	Description
`CA`	Create Architecture — Guided workflow to document all technical decisions
`IR`	Implementation Readiness — Validate PRD, UX, Architecture, and Stories are aligned

When to Use Him

Use Winston in Phase 3 (Solutioning) after the PRD (and optionally UX) is complete, when:

You need to define the technical stack, infrastructure, and API design
You need to document architectural decisions before development begins
You want a readiness gate to verify all planning artifacts are coherent before starting a sprint

Creating architecture (CA) is required before sprint planning can begin.

Part 5 — 🏃 Bob, Scrum Master

Command: /bmad-agent-bmm-sm
Code: sm
Title: Scrum Master

Who He Is

Bob is a certified Scrum Master with a deep technical background. He is crisp, checklist-driven, and has zero tolerance for ambiguity. Every word has a purpose, every requirement must be crystal clear. He loves talking Agile theory and serves as a servant leader to the team.

What He Does

Command	Description
`SP`	Sprint Planning — Generate the sprint plan that sequences all stories for the dev agent
`CS`	Create Story — Prepare a story with all implementation context for the dev agent
`ER`	Epic Retrospective — Party Mode review of all completed work across an epic
`CC`	Course Correction — Navigate significant mid-sprint changes

When to Use Him

Use Bob in Phase 4 (Implementation) to set up and manage development cycles:

At the start of implementation to generate a sprint plan from the epics and stories list
Before each dev cycle to prepare a context-rich story file for Amelia (the dev agent)
After completing an epic, to run a retrospective and extract lessons learned
Whenever unexpected changes require re-planning

Sprint Planning (SP) is the required first step of Phase 4. Story creation (CS) must happen before each Dev Story cycle.

Part 6 — 💻 Amelia, Developer Agent

Command: /bmad-agent-bmm-dev
Code: dev
Title: Developer Agent

Who She Is

Amelia is a senior software engineer who executes approved stories with strict adherence to story details and team standards. She is ultra-succinct — speaks in file paths and acceptance criteria IDs. No fluff, all precision. She will never lie about tests being written or passing.

What She Does

Command	Description
`DS`	Dev Story — Execute implementation tasks and tests for a prepared story
`CR`	Code Review — Comprehensive code review across multiple quality facets

When to Use Her

Use Amelia in Phase 4 (Implementation) to do the actual coding:

When Bob has prepared a story file with full context
To execute each story's tasks in strict order, writing tests as she goes
After story implementation is complete, to run a code review before marking it done

Dev Story (DS) is a required workflow. It follows every story creation cycle. Tests must pass 100% before a story is marked complete.

Part 7 — 🧪 Quinn, QA Engineer

Command: /bmad-agent-bmm-qa
Code: qa
Title: QA Engineer

Who She Is

Quinn is a pragmatic test automation engineer focused on rapid test coverage. She uses a "ship it and iterate" mentality — coverage first, optimization later. She uses standard test framework APIs (no external utilities) and focuses on realistic user scenarios. She is a simpler, more direct alternative to the advanced Test Architect module.

What She Does

Command	Description
`QA`	Automate — Generate API and E2E tests for existing implemented features

When to Use Her

Use Quinn in Phase 4 (Implementation) after code is written, when:

You want to add automated API or E2E test coverage to implemented features
You need test generation quickly without overthinking
Your project is small-to-medium in scale
You want beginner-friendly test automation using standard framework patterns

Quinn is not for code review or story validation — use Amelia's CR workflow for that. For enterprise-grade test strategy, use the separate Test Architect (TEA) module.

Part 8 — 🚀 Barry, Quick Flow Solo Dev

Command: /bmad-agent-bmm-quick-flow-solo-dev
Code: quick-flow-solo-dev
Title: Quick Flow Solo Dev

Who He Is

Barry handles Quick Flow — from tech spec creation through implementation with minimum ceremony and lean artifacts. He is direct, confident, and implementation-focused. Uses tech slang and gets straight to the point. His philosophy: "Code that ships is better than perfect code that doesn't."

What He Does

Command	Description
`QS`	Quick Spec — Create a complete technical spec with implementation-ready stories (no full PRD/Architecture ceremony)
`QD`	Quick Dev — Implement a story/spec end-to-end (the core of Quick Flow)
`CR`	Code Review — Comprehensive code review (same as Amelia's)

When to Use Him

Use Barry when you want to skip the full BMM planning phase, specifically for:

Quick one-off tasks and small bug fixes
Simple features being added to a well-established brownfield codebase
Utilities and scripts without complex architectural concerns
Solo developers who find full BMM planning too heavyweight
Situations where the user explicitly doesn't want extensive planning

Do not use Barry for potentially complex or large features — the full BMM workflow (Mary → John → Winston → Bob → Amelia) exists for a reason. Barry is the escape hatch for simplicity.

Part 9 — 📚 Paige, Technical Writer

Command: /bmad-agent-bmm-tech-writer
Code: tech-writer
Title: Technical Writer

Who She Is

Paige is an experienced technical writer expert in CommonMark, DITA, and OpenAPI. She transforms complex concepts into accessible, structured documentation. She believes a diagram is worth a thousand words and will always use Mermaid diagrams when appropriate. She is a patient educator who explains like teaching a friend.

What She Does

Command	Description
`DP`	Document Project — Generate comprehensive project documentation via brownfield analysis
`WD`	Write Document — Multi-turn conversation to author any document following documentation standards
`US`	Update Standards — Update her memory with your documentation preferences and conventions
`MG`	Mermaid Generate — Create Mermaid-compliant diagrams (sequence, flow, ER, etc.)
`VD`	Validate Document — Review a document against standards and return actionable improvements
`EC`	Explain Concept — Break down a complex technical concept into digestible sections with examples

When to Use Her

Use Paige at any time in the workflow, when:

You need to write or improve any document (README, ADR, API docs, technical specs)
You want to generate a Mermaid diagram from a description
You need to validate whether a document meets quality standards
You want a complex concept explained clearly for a specific audience
You want to establish or update documentation standards for your project

Paige is a universal, anytime agent — she is not tied to any specific phase and can be used throughout the entire lifecycle.

Summary: Agent Selection at a Glance

Phase	Agent	When Required
1 — Analysis	📊 Mary (Analyst)	Optional (recommended)
2 — Planning	📋 John (PM)	Required — Create PRD
2 — Planning	🎨 Sally (UX Designer)	Optional (strongly recommended for UI)
3 — Solutioning	🏗️ Winston (Architect)	Required — Create Architecture
3 — Solutioning	📋 John (PM)	Required — Create Epics & Stories + IR check
4 — Implementation	🏃 Bob (Scrum Master)	Required — Sprint Planning + Create Story
4 — Implementation	💻 Amelia (Dev)	Required — Dev Story each cycle
4 — Implementation	🧪 Quinn (QA)	Optional — Add test coverage
4 — Implementation	🏃 Bob (Scrum Master)	Optional — Retrospective
Any phase	📚 Paige (Tech Writer)	Optional — Docs, diagrams, explanations
Any phase (bypass)	🚀 Barry (Quick Flow)	Optional — Small tasks, skip planning

Run each agent in a fresh context window for best results. For validation workflows, use the highest-quality LLM available.

This content is summarized by /bmad-help, the agent that helps us with anything about BMAD. You can also ask it for more details about BMAD usage.

Cô bé bán diêm phiên bản 2026

JackTT — Wed, 14 Jan 2026 10:08:59 +0000

Đêm đông 2026, văn phòng vắng tanh.
Một cậu dev ngồi OT, tay gõ từng dòng code cho kịp deadline: 5 feature + hơn 80 bug.

Chiều hôm đó công ty thưởng 500k Tết dương lịch.
Bất lực, cậu móc thêm tiền túi, mua Claude $20/tháng, hy vọng AI vớt vát được phần nào.

Lần 1 – Cậu prompt vu vơ 2 dòng
Claude đọc hai ba file mà gen ra một đống code. Code chạy được, test thử đúng logic luôn!
Nhưng nhìn lại thì...không theo chuẩn chung, không đúng convention, code một mình một kiểu.
Kiểu này mà mở PR thì mai các anh reject liền. Cậu yêu cầu nó code lại nhưng chạy được một lúc thì Claude dính rate limit. Phải đợi 1 tiếng.

Cậu xuống đường làm hộp xôi.
Quay lên vẫn còn 40 phút.
Ngồi code chay được vài dòng thì nản quá.
Cậu đi dọc bờ sông Tô Lịch, qua cầu Giấy rồi quay lại, chỉ để đốt thời gian chờ Claude mở rate.

Lần 2 – Yêu cầu Claude đọc hiểu project trước khi code
Lần này Claude đã hiểu context, lên plan, code đúng chuẩn, chạy mượt.
Cậu hưng phấn, xứ lý tiếp các task khác. Nhưng lần này requirement dài gấp 10 lần.

AI giúp nhiều, nhưng cậu vẫn phải động tay kha khá. Với tốc độ này cậu vẫn phải OT thêm vài hôm nữa...

Lần 3 – BMAD
Đêm khuya, cậu nhớ mấy anh từng nhắc tới BMAD như một team software development hoàn chỉnh, có thể tự phân tích requirement, lên kế hoạch, rồi code song song.

Cậu thử install. Và đúng thật:

PM agent chỉ đạo, BA agent đọc requirement, break task rành rọt, trông như một team xịn đang làm việc ngay trước mặt.
Cậu khoái chí, ngồi lướt tóp tóp, đợi team dev $20/tháng mới thuê code hộ.

Sáng hôm sau, mọi người tới văn phòng, thấy cậu dev ngủ gục trên bàn, tay vẫn cầm điện thoại, miệng cười kiểu rất mãn nguyện.

Màn hình máy tính nhấp nháy dòng chữ đỏ:
"You have hit your weekly limit – Your limit will reset 5pm Thursday"

Scaling Read Tracking with Redis Bitmaps

JackTT — Tue, 16 Sep 2025 23:48:26 +0000

A friend recently came to me with a problem. They had designed a feature to track whether each user had read the latest posts in each category (a tab in the app).

The first design looked simple: store a row in MySQL for every (user_id, category_id) pair and update it whenever something changed.

But in production, things broke badly.

The initial design

Their schema looked like this:

category_user_read (
  user_id BIGINT,
  category_id BIGINT,
  read BOOLEAN,
  PRIMARY KEY (user_id, category_id),
  FOREIGN KEY (user_id) REFERENCES users(id)
);

The logic was:

When a user opened a category, update their row with read = true.
When a new post was added, update all rows in that category with read = false.

Simple enough, right?

Where it failed

In practice, this design was a database bottleneck:

Every page view triggered an update.
Every new post triggered a mass update across potentially millions of rows.
InnoDB placed exclusive row locks for each update.
The foreign key to users meant even more locking, since InnoDB had to check referential integrity.

With thousands of concurrent users, the table essentially turned into a global contention point.

Clarified requirements

After digging deeper, I asked the team what the product really needed. It turned out the requirement was much simpler:

Just show a red dot on the tab if the user hasn’t read the category yet.
No need to track the exact “last read post ID”.
The data isn’t critical — it can tolerate some loss.
But it must be fast and able to scale with millions of users.
That clarification changed everything about the design.

The Redis Bitmap approach

I suggested they throw away the heavy MySQL design and move the state into Redis bitmaps:
Think of it as an array of 0 and 1 values, where each position in the array corresponds to a user_id.

One bitmap per category.
We simply use the user_id number as the index in the bit array.
- This makes the implementation extremely simple.
- The trade-off is that if user IDs are sparse (e.g. max ID = 10M but only 1M active users), the bitmap may be larger than necessary.
- But in practice, this overhead is small compared to the simplicity gained.

Example:

SETBIT category:{category_id}:read {user_id} 1
GETBIT category:{category_id}:read {user_id}

When a user opens a category → set their bit to 1.
When a new post is added → Simply delete the bitmap key for that category

  DEL category:{category_id}:read

Result & scalibility

Blazing fast: Bitmap operations are constant time (O(1)), with no locking overhead.
Tiny memory footprint:
- 1 million users → 1 million bits → ~122 KB.
- Even with tens of millions of users, the memory cost stays in MBs.
- Scales naturally: No matter how many users open categories concurrently, Redis handles it without contention.

AWS Lambda with Go - How to Build, Deploy, and Invoke

JackTT — Wed, 20 Aug 2025 00:36:02 +0000

Build, Deploy, and Invoke AWS Lambda Functions in Golang

1. Initialize Lambda main function & handler in Go

Go Lambda starts from the main() function, usually with lambda.Start(handler).
Handler function signatures:

  func ()
  func () error
  func () (TOut, error)
  func (TIn) error
  func (TIn) (TOut, error)
  func (context.Context) error
  func (context.Context) (TOut, error)
  func (context.Context, TIn) error
  func (context.Context, TIn) (TOut, error)

ctx: context for timeout, logs, request ID
TIn and TOut represent types that can be Unmarshal JSON.

Example:

```go
package main

import (
    "context"
    "github.com/aws/aws-lambda-go/lambda"
)

type MyEvent struct {
    Name string `json:"name"`
}

func handler(ctx context.Context, e MyEvent) (string, error) {
    return "Hello " + e.Name, nil
}

func main() {
    lambda.Start(handler)
}
```

2. Deployment methods

(a) Zip deployment

GOOS=linux GOARCH=amd64 go build -o bootstrap main.go
zip function.zip bootstrap

Upload function.zip to Lambda.

(b) Docker container deployment
Dockerfile example:

FROM public.ecr.aws/lambda/go:1
COPY main ${LAMBDA_TASK_ROOT}
CMD ["main"]

Push the image to ECR and deploy.

3. Invocation methods

AWS CLI

aws lambda invoke --function-name MyFunction --payload '{"name":"Jack"}' response.json
cat response.json

Go SDK (aws-sdk-go-v2)

client := lambda.NewFromConfig(cfg)
resp, err := client.Invoke(context.TODO(), &lambda.InvokeInput{
    FunctionName: aws.String("MyFunction"),
    Payload:      []byte(`{"name":"Jack"}`),
})

4. Create & Update Lambda Function via AWS CLI

Create function (ZIP deployment)

aws lambda create-function \
  --function-name MyFunction \
  --runtime go1.x \
  --role arn:aws:iam::<account-id>:role/<lambda-execution-role> \
  --handler bootstrap \
  --zip-file fileb://function.zip

Update function code (ZIP deployment)

aws lambda update-function-code \
  --function-name MyFunction \
  --zip-file fileb://function.zip

References

https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html

Tracing error strack in Golang

JackTT — Fri, 23 May 2025 11:40:00 +0000

Problem: No Stack Trace in Native Errors

Consider this Go snippet:

func function3() error {
    var result1 map[string]int
    input1 := `{"key": "value"}`
    if err := json.Unmarshal([]byte(input1), &result1); err != nil {
        return err
    }

    var result2 map[string]int
    input2 := `{"key": 123}`
    if err := json.Unmarshal([]byte(input2), &result2); err != nil {
        return err
    }

    return nil
}

When an error occurs, you’ll get:

json: cannot unmarshal string into Go value of type int

But which line caused it? The first or second Unmarshal?
Without a stack trace, it’s unclear.

Solution: Attach a Stack Trace

Using github.com/cockroachdb/errors, you can wrap errors with errors.WithStack:

return errors.WithStack(err)

Example output with fmt.Printf("%+v", err):

json: cannot unmarshal string into Go value of type int
(1) attached stack trace
  -- stack trace:
  | main.function3
  |     /golang-test/errror_tracing/main.go:28
  | main.function2
  |     /backend/golang-test/errror_tracing/main.go:19
  | main.function1
  |     /backend/golang-test/errror_tracing/main.go:15
  | main.main
  |     /backend/golang-test/errror_tracing/main.go:10
  | runtime.main
  |     /Users/jack/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.9.darwin-arm64/src/runtime/proc.go:272
  | runtime.goexit
  |     /Users/jack/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.9.darwin-arm64/src/runtime/asm_arm64.s:1223

Now you know exactly where the error occurred.

Under the Hood: How Stack Capture Works

Go’s runtime.Callers() lets you capture the current stack:

func printStack() {
    // Declare an array to hold up to 10 program counters (PCs).
    // PCs represent the addresses of the function calls in the call stack.
    var pcs [10]uintptr

    // Capture the call stack PCs, skipping the first 2 frames:
    // 0 = runtime.Callers, 1 = printStack itself.
    // pcs[:] converts the array to a slice.
    // n is the number of PCs actually captured.
    n := runtime.Callers(2, pcs[:])

    // Create a Frames iterator from the captured PCs slice,
    // which translates PCs into human-readable function/file/line info.
    frames := runtime.CallersFrames(pcs[:n])

    // Loop through the frames iterator until there are no more frames.
    for {
        // Get the next frame and a boolean indicating if more frames remain.
        frame, more := frames.Next()

        // Print the function name, source file, and line number of this frame.
        fmt.Printf("%s\n\t%s:%d\n", frame.Function, frame.File, frame.Line)

        // If there are no more frames, break out of the loop.
        if !more {
            break
        }
    }
}

This function prints the call path to its current point in the code.

Rebuilding errors.WithStack

Here’s a minimal reimplementation of errors.WithStack:

type errWithStack struct {
    err   error
    stack []uintptr
}

func WithStack(err error) error {
    if err == nil {
        return nil
    }
    var pcs [32]uintptr
    n := runtime.Callers(3, pcs[:])
    return &errWithStack{err, pcs[:n]}
}

func (e *errWithStack) Error() string { return e.err.Error() }

// Format implemnets fmt.Formatter
func (e *errWithStack) Format(s fmt.State, verb rune) {
    switch verb {
    case 'v':
        if s.Flag('+') {
            fmt.Fprint(s, e.err)
            frames := runtime.CallersFrames(e.stack)
            for {
                f, more := frames.Next()
                fmt.Fprintf(s, "\n%s\n\t%s:%d", f.Function, f.File, f.Line)
                if !more {
                    break
                }
            }
            return
        }
        fallthrough
    case 's':
        fmt.Fprint(s, e.err)
    }
}

Behavior:

fmt.Println(err) → shows the error message only
fmt.Printf("%+v", err) → includes full stack trace

Summary

Standard errors in Go don’t include stack traces.
Using libraries like cockroachdb/errors gives you precise visibility into where errors happen — critical for debugging complex applications.

A better pkg.go.dev

JackTT — Sun, 16 Feb 2025 12:35:06 +0000

About pkgo.dev

I have never been able to read a package's documentation on pkg.go.dev since all the code there is in black & white...

This is the reason I created this repository to make it possible to read.

Usage

Every time you want to read a package's documentation, you just need to replace pkg.go.dev with pkgo.dev. (remove the .g).

E.g.

How it works

We use Nginx as proxy server.

Every time a request come in, we forward it to the pkg.go.dev server, then append the highlight.js script to the response before sending it back to the client.

Since some README files do not specify the code language, we also update <code> tags to <code class="language-go"> to enable syntax highlighting.

If you don't trust me, no worry, you can deploy it yourself:

Append 127.0.0.1 pkg.go.dev.local to /etc/hosts
Run docker-compose up -d --build
Access http://pkg.go.dev.local

Source code

https://github.com/huantt/better-pkg-go-dev

huantt / better-pkg-go-dev

Make pkg.go.dev more readable

About

I have never been able to read a package's documentation on pkg.go.dev since all the code there is in black & white...

This is the reason I created this repository to make it possible to read.

Usage

Every time you want to read a package's documentation, you just need to replace pkg.go.dev with pkgo.dev. (remove the .g).

How it works

We use Nginx as proxy server.

Every time a request come in, we forward it to the pkg.go.dev server, then append the highlight.js script to the response before sending it back to the client.

Since some README files do not specify the code language, we also update <code> tags to <code class="language-go"> to enable syntax highlighting.

If you don't trust me, no worry, you can deploy it yourself:

Append 127.0.0.1 pkg.go.dev.local to /etc/hosts
Run docker-compose up -d --build
Access http://pkg.go.dev.local

View on GitHub

Pod Topology Spread Constraints

JackTT — Sun, 12 Jan 2025 10:43:49 +0000

Pod Topology Spread Constraints

Pod Topology Spread Constraints - a.k.a topologySpreadConstraints is a field of Pod.spec

It allows you to define how Pods should be spread across different topological domains, such as zones or nodes, to achieve better availability, fault tolerance, and resource utilization.

Main attributes

topologyKey: is a string representing a node label key. Kubernetes uses this key to identify and group nodes into topological domains.
- Common values: kubernetes.io/hostname | topology.kubernetes.io/region
maxSkew: Specifies the maximum difference in the number of Pods across topological domains. A lower skew ensures a more even distribution.
labelSelector: is used to find matching Pods. Pods that match this label selector are counted to determine the number of Pods in their corresponding topology domain.
whenUnsatisfiable: indicates how to deal with a Pod if it doesn't satisfy the spread constraint.
- DoNotSchedule (default) tells the scheduler not to schedule it.
- ScheduleAnyway tells the scheduler to still schedule it while prioritizing nodes that minimize the skew.

Benefits of Using TSC

Improved Fault Tolerance: By spreading Pods across zones or nodes, the impact of a failure in one domain is minimized.
Better Resource Utilization: Ensures even distribution of workloads, preventing overloading specific domains.
Customizable Scheduling: Fine-tune how workloads are distributed based on application requirements.

Example

The following spec prefer spreading pods across nodes based on kubernetes.io/hostname.

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
  labelSelector:
    matchLabels:
      app: hello-world

Reference

https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/

Avoid Misunderstanding ON DELETE NO ACTION

JackTT — Sun, 06 Oct 2024 02:34:34 +0000

Relational databases often provide several options for handling actions when a referenced row in a foreign key relationship is deleted.
Among these options, ON DELETE NO ACTION can be a bit confusing, both in terms of its naming and its behavior.

Let's read my post to ensure that you understand it correctly.

What Are ON DELETE Options?

The ON DELETE clause in SQL allows you to define what should happen to the rows in a child table when the related row in the parent table is deleted. ON DELETE options include:

CASCADE: Automatically deletes child rows when the parent row is deleted.
SET NULL: Sets the foreign key value in child rows to NULL when the parent row is deleted.
RESTRICT: Prevents deletion of the parent row if any child rows exist.
NO ACTION: Similar to RESTRICT; the action is deferred until the end of the transaction.

Comparing ON DELETE NO ACTION and ON DELETE RESTRICT

ON DELETE NO ACTION and ON DELETE RESTRICT seem similar since both options ultimately prevent the deletion of the parent row if it has dependent rows in the child table. However, the difference i in the timing:

ON DELETE NO ACTION: The restriction is enforced at the end of the transaction. If any other statements within the transaction resolve the issue (like deleting the child rows), the delete action can proceed without raising an error.
ON DELETE RESTRICT: The restriction is enforced immediately, preventing the delete action as soon as it’s attempted, without waiting for the end of the transaction.

If you're using Golang, you can reference "ON DELETE NO ACTION" similarly to "defer RESTRICT".

[Golang] Understanding Unbuffered and Buffered Channels

JackTT — Sat, 14 Sep 2024 08:07:26 +0000

Channel capacity
Behavior
Closed channel
Receive-Only & Send-only Channel
References

Channel capacity

Unbuffered channel:
- Has no capacity.
- You can imagine it like a highway that allows one car to run through but does not support any cars to park there.
Buffered channel:
- Has a fixed capacity at declaration time.
- It's like a queue that supports holding up to a fixed number of pending messages before consuming.

Behavior

Unbuffered channel:
- Sender is blocked until a receiver receive the message.
- Receiver is blocked until a sender sends a message.
- The sending and receiving processes are synchronous.
Buffered channel:
- Senders are blocked only when the buffer is full.
- Receivers are blocked when the buffer is empty.
- The sending and receiving processes are asynchronous. Senders are released immediately after the sending action without waiting for the receiver.

Worth noting: An unbuffered channel differs from a buffered channel with a size of 1 according to the behavior described above.

Closed channel

When a channel is closed in Go using the close() function:

Sending to a closed channel causes a panic.
Receiving from a closed channel continues to retrieve values until the buffer is drained (for buffered channels). After the buffer is empty, further receives return the zero value of the channel's type and do not block.

You can check if a channel is closed by receiving a second value from the channel, e.g., v, ok := <-ch. The ok will be false if the channel is closed.

Receive-Only & Send-only Channel

Receive-only channel in Go is a channel that can only be used to receive values.

Declaration: var ch <-chan int defines a channel from which only receiving is allowed.
Behavior:
- Attempting to send to a read-only channel will result in a compilation error.
- Attempting to pass a receive-only channel into a function that requires normal channel also lead to a compilation error.

Send-only channel is similar.

var ch chan<- int

References

https://go.dev/tour/concurrency/2 (By default, sends and receives block until the other side is ready. This allows goroutines to synchronize without explicit locks or condition variables)
https://go.dev/tour/concurrency/3 (Sends to a buffered channel block only when the buffer is full. Receives block when the buffer is empty)
https://golangr.com/channel-directions (Receive-only and Send-only channels)
https://go101.org/article/channel.html

DEV Community: JackTT

BMAD cheat sheet

Module 1: BMM (Business Model Management)

Phase 1 — Analysis

Phase 2 — Planning

Phase 3 — Solutioning

Phase 4 — Implementation

Anytime (BMM)

Module 2: CIS (Creative Innovation Suite)

Module 3: Core (Universal Tools)

Quick Cheat Sheet: Where am I? What do I run?

BMAD Quick Flow

BMAD Quick Flow

The Three Commands

1. /bmad-agent-bmm-quick-flow-solo-dev — The Hub Agent

2. /bmad-bmm-quick-spec — Write a Technical Spec

3. /bmad-bmm-quick-dev — Implement the Spec

Typical Workflows

Spec first, then implement (recommended for anything non-trivial)

Direct implementation (for trivial changes)

Using the hub agent

Quick Flow vs. Full BMM Workflow

BMAD Standard Workflow

BMAD Standard Workflow Guide

Overview

Folder Structure

BMAD Standard Flow

Phase 1 — Analysis

Phase 2 — Planning

Phase 3 — Solutioning

Phase 4 — Implementation

Anytime Tools

Summary: Output Locations

Key Principles

Understanding the Agents in the BMAD

BMAD Agents

Part 1 — 📊 Mary, Business Analyst

Who She Is

What She Does

When to Use Her

Part 2 — 📋 John, Product Manager

Who He Is

What He Does

When to Use Him

Part 3 — 🎨 Sally, UX Designer

Who She Is

What She Does

When to Use Her

Part 4 — 🏗️ Winston, Architect

Who He Is

What He Does

When to Use Him

Part 5 — 🏃 Bob, Scrum Master

Who He Is

What He Does

When to Use Him

Part 6 — 💻 Amelia, Developer Agent

Who She Is

What She Does

When to Use Her

Part 7 — 🧪 Quinn, QA Engineer

Who She Is

What She Does

When to Use Her

Part 8 — 🚀 Barry, Quick Flow Solo Dev

Who He Is

What He Does

When to Use Him

Part 9 — 📚 Paige, Technical Writer

Who She Is

What She Does

When to Use Her

Summary: Agent Selection at a Glance

Cô bé bán diêm phiên bản 2026

Scaling Read Tracking with Redis Bitmaps

The initial design

Where it failed

Clarified requirements

The Redis Bitmap approach

Result & scalibility

1. `/bmad-agent-bmm-quick-flow-solo-dev` — The Hub Agent

2. `/bmad-bmm-quick-spec` — Write a Technical Spec

3. `/bmad-bmm-quick-dev` — Implement the Spec