1. What are these things?
Method = the main process
It helps you decide what to build, how to build it, and whether the result works. Small changes need a short process. A whole product needs more planning.
Toolbox = extra help
Use it when you need ideas, research, criticism, or more perspectives. For example, research a difficult decision before continuing with the main process.
A skill = an instruction set
A skill tells the AI how to do a particular job. bmad-prd writes requirements. bmad-build turns a request or a small task into checked code.
An activity is the job being done, such as planning or reviewing. An artifact is something left behind, such as a plan, a code change, a test, or a report. Many skills leave files; some mainly produce a conversation.
How do I actually use a skill?
In a chat connected to your software project, name the skill and describe the job: Use bmad-build to add an Export CSV button.
When a planning step is finished, use its result for the next step: Use bmad-build to implement the first story from this SPEC.md. Point the assistant to the relevant files or include the material it needs.
A diagram shows the order of work. It is not a button that automatically runs the whole project. Work through the relevant steps, inspect the results, and continue with the next task.
Translate the jargon into normal words
- Spec / specification
- A short description of what should be built and what counts as success.
- PRD · Product requirements document
- A more detailed description of the users, needs, and required product behavior.
- Product brief
- The product idea, the problem it solves, and who it is for.
- PRFAQ · Press release + frequently asked questions
- Imagine the finished product, write its announcement, and answer hard questions about it. An alternative to a product brief.
- UX / UI
- User experience / user interface: how using the product feels and what the screens look like.
- Architecture
- The technical plan: which parts the software needs and how they work together.
- Epic
- A larger outcome made up of several smaller tasks. Example: “customers can book appointments.”
- Story
- One manageable piece of an epic. Example: “a customer can choose an available time.”
- Sprint status
- A tracking file showing planned work and its current state. It does not prove the code works.
- Review / QA tests
- Review looks for problems. Automated tests run checks on behavior. QA means quality assurance.
- Retrospective
- Look back at a completed epic: did it meet the plan, what did we learn, and what needs action?
- Repository / working tree
- The project folder and its source files. This is where implementation changes happen.
2. Which route should I use?
Choose based on how much work and uncertainty you have. The examples are illustrative.
A small, clear change
“Add a button that exports this table.” The assistant can understand, build, and check it in one coding session.
Choose: one session →A feature with several parts
“Let customers book appointments.” It needs several tasks and several coding sessions.
Choose: one larger feature →A whole product
“Build an appointment-booking product for salons.” It needs product decisions, screens, technical planning, and many features.
Choose: whole product →Not sure? Ask: Use bmad to help me choose a workflow for [describe your goal]. A small change with high risk or unclear requirements may need more planning. An obvious, low-risk edit can be made directly.
3. The full journeys at a glance
Read top to bottom. Each route ends with checked work. The detailed diagrams below explain every handoff.
Small change
- Your request
- Build: clarify → code → check → review
- Any extra checks you choose
- Fix material problems and recheck
- Finished change that meets the request
Larger feature
- Your feature idea
- Spec + ordered small tasks
- Build and check task 1
- Repeat for the remaining tasks
- Retrospective: assess the whole feature
- Feature meets the agreed outcome
Whole product
- Your product idea
- Brief OR PRFAQ
- Requirements → UX if needed → architecture
- Epics + stories → readiness + tracking
- Build and check each story
- Retrospective after each epic
- Repeat until the agreed product scope is complete
4. Follow a route from start to finish
End-to-end flowchart
Follow the arrows. Each activity contains a folded-sheet panel showing its output artifacts. The next activity uses those results. Diamonds ask a question; labeled arrows show the answer. On narrow screens, scroll the diagram sideways.
Step-by-step explanation of the flowchart
Optional quality activities
Build already includes review. Add these when the work benefits from them.
Changes & repository guidance
A significant change can return you to the earliest affected planning activity.
Scope is a signal, not a rule. Risk, uncertainty, architecture, and coordination can justify a larger route. An obvious, low-risk edit can be made directly without a BMAD skill, unless BMAD is explicitly requested.
5. What happens inside “Build”?
This is the same delivery activity used in all three routes. It handles one request or one story at a time.
Does the result meet the task?
No, a material problem remains → fix the code or clarify the task → run the affected checks and review again.
Yes → do any extra checks you chose → finish this task. If the plan has more stories, Build the next story.
This diagram expands the installed guide’s “clarifies → plans as needed → implements → reviews → presents” sequence. It is an explanation of the delivery cycle, not a separate skill to invoke.
6. What if something goes wrong or the goal changes?
A problem in the current change
Review or tests find a defect → fix the affected implementation → check and review again → continue when material findings are resolved.
Result: corrected code and updated check evidence.
A change that affects the plan
New requirement or major finding → bmad-correct-course → impact assessment and change proposal → user approves the proposal → resume the earliest affected activity → continue delivery.
Result: a change proposal; affected plans and code are updated as work resumes.
Example: a broken button is usually an implementation fix. Discovering that the whole product needs a different booking model may affect requirements and architecture. Correct Course helps work out which planning steps need to be revisited.
7. When should I reach for the Toolbox?
Optional conversations with a role
Method personas provide a named perspective. They are not required steps; workflow skills already perform the relevant work.
8. All 29 skills: reference list
9. Where do the files go?
An artifact is a result left behind by an activity. The names in braces below stand for folders selected by the project’s BMAD configuration; they are not literal folder names to create.
{output_folder}/specsDurable specs, supporting files, and ordered story lists. The installed description explicitly names SPEC.md.
{planning_artifacts}Product brief or PRFAQ, PRD, UX and architecture documents, epics and stories, and change proposals. UX explicitly names DESIGN.md and EXPERIENCE.md.
{implementation_artifacts}Build working records, sprint status, reviews, and retrospectives.
{project-root} / working treeImplemented source code and related project changes.
{project-root}/testsGenerated API and end-to-end tests.
{project-root}/AGENTS.mdRepository guidance and recorded pitfalls from project-context work.
Outputs in the catalog describe artifact types, not guaranteed files. Conversation-only support activities may have no saved artifact; optional outputs are labeled. Filenames not specified by the installed guide are intentionally left unspecified.
Completion is about the outcome.
The intent is satisfied, the chosen checks pass, and no chosen review has material unresolved findings. Traversing every skill is not a completion condition. A story marked “done” alone is not proof.
10. Sources and scope
Source, coverage & version
This page describes the 29 host-listed skills installed in BMAD Method and BMAD Toolbox, version 6.13.0-next, inspected on 3 October 2026. Module membership was checked against each skill’s module-manifest.toml. Workflow ordering, alternatives, loops, completion conditions, and storage locations come from the shared installed bmad/references/help.md. Skill descriptions come from the host’s installed skill catalog. Input/output summaries are explanatory paraphrases; they are not exhaustive internal task procedures.
Installed source locations:
Installed plugin: bmad-toolbox/6.13.0-next/skills/bmad/SKILL.mdInstalled plugin: bmad-toolbox/6.13.0-next/skills/bmad/references/help.mdInstalled plugin: bmad-method/6.13.0-next/skills/*/module-manifest.tomlInstalled plugin: bmad-toolbox/6.13.0-next/skills/*/module-manifest.toml
The installed guide points to the remote documentation index, but it returned HTTP 404 during this inspection. This map therefore uses installed-version evidence. It does not claim to document every internal subtask or every BMAD module beyond these two plugins.
How decisions and feedback loops work
- Product brief and PRFAQ are alternatives: choose one, never both.
- UX follows the PRD when the user experience is significant. Architecture precedes epics and stories.
- Epic-sized work can request architecture and/or UX companion files from Spec when needed.
- Use attended Build for risky or foundational stories. An orchestrator can dispatch Build Auto once patterns and decisions are stable; it runs one unit, not an entire autonomous loop by itself.
- Repeat extra code review after material fixes until remaining findings no longer affect acceptance. Repeated minor review cycles are not the goal.
- Finish an epic with a retrospective. A significant planning change goes through Correct Course; after proposal approval, resume at the earliest affected activity without replaying unaffected work.
Navigation, setup & customization
The bmad hub explains the installed skills and recommends a next step based on evidence. Cross-skill routing depends on the hub being installed. Its explicit setup, update, and doctor requests are distinct maintenance flows; this page lists that capability but does not execute it or document its internal steps. Missing project files do not turn a help request into setup.
bmad-customize authors customization overrides for installed skills. It stands outside the delivery routes, like the other Toolbox support activities.