Skip to content
🤖 Consolidated, AI-optimized BMAD docs: llms-full.txt. Fetch this plain text file for complete context.
🚀 Build your own BMad modules and share them with the community! Get started or submit to the marketplace.
BMAD Method

Quick Fixes

Bug fixes, refactorings, and small targeted changes can enter Build directly with little or no upstream planning. This is the same implementation workflow used for fully planned stories.

When to Use This

Section titled “When to Use This”
  • Bug fixes with a clear, known cause
  • Small refactorings (rename, extract, restructure) contained within a few files
  • Minor feature tweaks or configuration changes
  • Dependency updates

Steps

Section titled “Steps”

1. Start a Fresh Chat

Section titled “1. Start a Fresh Chat”

Open a fresh chat session in your AI IDE. Reusing a session from a previous workflow can cause context conflicts.

2. Give It Your Intent

Section titled “2. Give It Your Intent”

Build accepts free-form intent — before, with, or after the invocation. Examples:

run build — Fix the login validation bug that allows empty passwords.
run build — fix https://github.com/org/repo/issues/42
run build — implement the intent in _bmad-output/implementation-artifacts/my-intent.md
I think the problem is in the auth middleware, it's not checking token expiry.
Let me look at it... yeah, src/auth/middleware.ts line 47 skips
the exp check entirely. run build
run build
> What would you like to do?
Refactor UserService to use async/await instead of callbacks.

Plain text, file paths, GitHub issue URLs, bug tracker links — anything the LLM can resolve to a concrete intent.

3. Answer Questions and Approve

Section titled “3. Answer Questions and Approve”

Build may ask clarifying questions or present a short spec for your approval before implementing. Answer its questions and approve when you’re satisfied with the plan.

4. Review and Push

Section titled “4. Review and Push”

Build implements the change, reviews its own work, patches issues, and commits locally. When it’s done, it shows you the review spec.

  • Skim the diff to confirm the change matches your intent
  • If something looks off, tell the agent what to fix — it can iterate in the same session

Once satisfied, push the commit. Build will offer to push and create a PR for you.

What You Get

Section titled “What You Get”
  • Modified source files with the fix or refactoring applied
  • Passing tests (if your project has a test suite)
  • A ready-to-push commit with a conventional commit message

Deferred Work

Section titled “Deferred Work”

Build keeps each run focused on a single goal. If your request contains multiple independent goals, or if the review surfaces pre-existing issues unrelated to your change, Build defers them to a file (deferred-work.md in your implementation artifacts directory) rather than trying to tackle everything at once.

Check this file after a run — it’s your backlog of things to come back to. Each deferred item can be fed into a fresh Build run later.

When to Add Formal Planning

Section titled “When to Add Formal Planning”

Before running the same Build implementation loop, consider adding PRD, UX, architecture, or story planning when:

  • The change affects multiple systems or requires coordinated updates across many files
  • You are unsure about the scope and need requirements discovery first
  • You need documentation or architectural decisions recorded for the team

See Build for how direct intent and planned work converge on the same implementation loop.