--- title: "Quick Fixes" description: How to make quick fixes and ad-hoc changes sidebar: order: 5 --- Use **workflow skills** directly for bug fixes, refactorings, or small targeted changes that don't require the full BMad Method or Quick Flow. ## 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 - Exploratory work to understand an unfamiliar codebase :::note[Prerequisites] - BMad Method installed (`npx bmad-method install`) - An AI-powered IDE (Claude Code, Cursor, or similar) ::: ## Choose Your Approach | Situation | Workflow skill | Why | | --- | --- | --- | | Fix a specific bug or make a small, scoped change | `bmad-dev-story` | Jumps straight into implementation without planning overhead | | Change touches several files or you want a written plan first | `bmad-quick-spec` then `bmad-quick-dev` | Creates a quick-spec before implementation so the AI stays aligned to your standards | If you are unsure, start with `bmad-dev-story` or describe the change directly to your AI assistant. You can always escalate to Quick Flow if the change grows. ## Steps ### 1. Invoke a Workflow Skill Start a **fresh chat** in your AI IDE and invoke the dev story workflow skill: ```text bmad-dev-story ``` This loads the implementation workflow into the session. If you decide you need a plan first, use Quick Flow in a fresh chat: ```text bmad-quick-spec ``` The quick-spec workflow walks you through creating a lightweight spec capturing what you want to change and how. After you approve the spec, invoke `bmad-quick-dev` in a fresh chat to implement -- it will execute the change, run tests, and perform a self-review, all guided by the spec you just approved. :::tip[Fresh Chats] Always start a new chat session when loading an agent. Reusing a session from a previous workflow can cause context conflicts. ::: ### 2. Describe the Change Tell the agent what you need in plain language. Be specific about the problem and, if you know it, where the relevant code lives. :::note[Example Prompts] **Bug fix** -- "Fix the login validation bug that allows empty passwords. The validation logic is in `src/auth/validate.ts`." **Refactoring** -- "Refactor the UserService to use async/await instead of callbacks." **Configuration change** -- "Update the CI pipeline to cache node_modules between runs." **Dependency update** -- "Upgrade the express dependency to the latest v5 release and fix any breaking changes." ::: You don't need to provide every detail. The AI will read the relevant source files and ask clarifying questions when needed. ### 3. Let the AI Work The AI will: - Read and analyze the relevant source files - Propose a solution and explain its reasoning - Implement the change across the affected files - Run your project's test suite if one exists If your project has tests, the AI runs them automatically after making changes and iterates until tests pass. For projects without a test suite, verify the change manually (run the app, hit the endpoint, check the output). ### 4. Review and Verify Before committing, review what changed: - Read through the diff to confirm the change matches your intent - Run the application or tests yourself to double-check - If something looks wrong, tell the AI what to fix -- it can iterate in the same session Once satisfied, commit the changes with a clear message describing the fix. :::caution[If Something Breaks] If a committed change causes unexpected issues, use `git revert HEAD` to undo the last commit cleanly. Then start a fresh chat to try a different approach. ::: ## Learning Your Codebase Your AI assistant is also useful for exploring unfamiliar code. Start a fresh chat and ask questions: :::note[Example Prompts] "Explain how the authentication system works in this codebase." "Show me where error handling happens in the API layer." "What does the `ProcessOrder` function do and what calls it?" ::: Use your AI assistant to learn about your project, understand how components connect, and explore unfamiliar areas before making changes. ## What You Get - Modified source files with the fix or refactoring applied - Passing tests (if your project has a test suite) - A clean commit describing the change No planning artifacts are produced -- that's the point of this approach. ## When to Upgrade to Formal Planning Consider using [Quick Flow](../explanation/quick-flow.md) or the full BMad Method when: - The change affects multiple systems or requires coordinated updates across many files - You are unsure about the scope and need a spec to think it through - The fix keeps growing in complexity as you work on it - You need documentation or architectural decisions recorded for the team