BMad Method

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 1 of 15. Most AI coding assistants fail on day three because they forget why they wrote the code on day one. You end up with a mess of isolated scripts that do not fit together. To solve this, you do not need a better prompt, you need Context Engineering and the four phases. A common mistake is treating the BMad method as a simple code generator. It is not. It is an agile context engineering pipeline. If you just ask an AI agent to build a feature, it guesses the boundaries. BMad prevents this by progressively building and locking in context across four distinct phases. The agent never loses the plot because each phase feeds strict, documented rules to the next. Take the example of building a SaaS application. If you jump straight to code, the AI might choose a database that violates your data residency requirements. Context engineering stops that. The pipeline starts with the Analysis phase. Here, the AI acts as a Business Analyst. It processes your raw ideas and produces a Product Requirements Document. This phase locks down the core constraints. It captures user personas, compliance rules, and main workflows. The resulting document becomes the foundation for everything else. Next is the Planning phase. The agent switches to a Product Owner role. It takes the requirements document and breaks it down into Epics and User Stories. Abstract requirements turn into discrete, actionable items. The context narrows. The AI is no longer thinking about the entire product, just specific deliverable units mapped to a clear timeline. This is where it gets interesting. The third phase is Solutioning. The AI takes on the Architect role. It looks at the User Stories from the Planning phase and the constraints from the Analysis phase to create the technical design. It decides on data models, API endpoints, and folder structures. For your SaaS application, the business constraints defined in phase one tell the Architect in phase three exactly what boundaries exist. This ensures the chosen architecture actually fits the original business rules. Finally, we reach the Implementation phase. Now the AI assumes the Developer role. The Developer agent does not need to guess the architecture or wonder about the business logic. It receives the exact technical blueprint from the Architect. It writes the code to fulfill a specific User Story, following the precise data models and file paths defined in the previous step. This chain of context is the entire point. Information flows downstream through persistent documentation. The output of one phase becomes the strict input boundary for the next. The Developer agent succeeds because the Architect agent paved the road, and the Architect succeeded because the Business Analyst mapped the territory. You are engineering the context at every level so the AI focuses entirely on execution. The defining trait of a resilient AI workflow is not how fast it generates text, but how strictly it enforces boundaries across different stages of thought. If you want to support the show, you can search for DevStoriesEU on Patreon. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 2 of 15. You might think adopting a new AI development framework requires memorizing a massive sequence of specific commands and rigid workflow phases. It does not. You do not need to memorize a single command sequence in this framework, because the system physically inspects your local folder and tells you exactly what to type next. This is the Intelligent Guide and Installation process. Getting started requires just one step. In your terminal, you run the package executor command npx bmad-method install. This command initializes the workspace and structurally prepares your repository. It does this by creating two specific directories in your root folder. The first directory is underscore bmad. This folder is the brain of your local framework. It holds the core skills, prompt definitions, and contextual templates the AI uses to do its work. The second directory is underscore bmad dash output. This serves as the dedicated destination folder. Whenever the framework generates new assets, whether those are product requirement documents, feature specifications, or actual code, they are deposited into this output directory safely isolated from your existing source code. Here is the key insight. Once those folders exist, developers often make a common mistake. They assume they need to pull up the official documentation, study the distinct phases of the framework, and memorize the exact terminal commands required to move from phase to phase. They worry about accidentally skipping a step or running a command out of order. You do not need to do any of this. The framework is self-documenting at runtime thanks to a built-in skill called bmad-help. Bmad-help is an active guide that eliminates the cognitive load of navigating the methodology. It is not a static manual. When you invoke it, the skill actively looks at the current state of your workspace. It checks what is currently inside your folders to determine exactly where you are in the development lifecycle. Consider a concrete scenario. You just finished the installation command. Your workspace is empty except for the new configuration folders. You have an idea for a software product but no idea what command to type next. You simply trigger the CLI and type bmad-help followed by your question in plain English. For example, you type bmad-help I have an idea for a SaaS, where do I start? The skill processes your question, realizes there are no planning documents in your output folder yet, and tells you exactly what to do. It responds with the specific command you need to run to initiate the first phase. It does not give you a generic list of all available commands. It gives you the single precise instruction for your immediate context. As you progress through the methodology, building out documents and code, bmad-help adapts. If you finish generating your architecture and ask what to do next, it sees the architecture files and prescribes the command for the next appropriate phase. The framework physically inspects your progress and dynamically guides your next move. You never have to guess if you are ready to write code or if you need to refine your requirements first, because the local installation constantly reads your environment to keep you on the correct path. I would like to take a moment to thank you for listening, it helps us a lot. Have a great one!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 3 of 15. If you ask a large language model for ten ideas, you usually get ten perfectly averaged, fundamentally boring ideas. The system is designed to predict the most likely next word, which means it gravitates toward the mundane. To get truly innovative results, you need to force the AI to act as a coach that extracts the concepts out of you instead. This is exactly what the Forging Ideas with AI Brainstorming workflow does. Most people equate AI brainstorming with zero-shot prompting. You type a request for ideas into a chat box, and you receive a generic list in return. That approach fails because it treats the AI as an oracle. The brainstorming coach in the BMad Method operates on the opposite principle. It is a guided, multi-turn facilitation framework where the AI does not generate the core ideas at all. Instead, it provides structured cognitive friction to force you to think laterally. The workflow relies heavily on two specific mechanisms, which are anti-bias protocols and domain shifting. When you input an initial thought, the anti-bias protocol prevents the AI from simply agreeing with you. If you suggest a standard solution to a problem, the AI is programmed to challenge it. It might ask what happens if your proposed solution completely fails, or how a competitor might exploit the obvious flaws in your logic. Domain shifting takes this a step further by forcing you to view your problem through the lens of a completely unrelated industry. Consider a concrete scenario where you want to explore ways to improve developer onboarding. A standard AI would give you a list about writing better documentation and assigning mentors. The BMad brainstorming coach, however, might initiate a SCAMPER technique exercise. SCAMPER is a framework that prompts you to Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, or Reverse elements of a process. Here is the key insight. The AI will not run through the entire acronym at once and dump a wall of text on you. It handles the pacing step by step. It asks you how you might eliminate the documentation-reading phase of onboarding entirely. You provide an answer based on your domain expertise. Then, the AI prompts you to combine onboarding with an unrelated engineering task, like live incident response. You answer again. The AI holds the framework steady while you supply the actual insight. You start the workflow by defining your raw problem space. The AI responds with a specific constraint or a targeted question. You reply. The AI processes your answer, applies its anti-bias check, and then pushes back or shifts the domain. This multi-turn loop continues until you have exhausted the obvious answers and start producing genuinely novel concepts. The AI acts as a tireless facilitator that refuses to let you settle for the first thing that comes to mind. The value of an AI in the early stages of product design is not its ability to invent things from scratch, but its endless patience for applying structured cognitive friction to your own expertise. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 4 of 15. Amazon famously writes the press release before building the product. What if an AI relentlessly challenged that press release before letting you touch the codebase? Choosing the right document format early on dictates whether you build a tool people actually need or waste months on something nobody wants. The BMad Method handles this divergence through two distinct analysis phase outputs: The PRFAQ Gauntlet and The Product Brief. Users often struggle with which format to pick. The rule is straightforward. If you already have strong conviction about what you are building and just need team alignment, use the Product Brief. If you need to figure out whether the product even deserves to exist, use the PRFAQ. The Product Brief is a gentle, collaborative discovery process. Think of it as a guided conversation. You and the AI work together to outline the problem space, target users, core features, and success metrics. The AI acts as a supportive co-pilot. It takes your rough concepts, structures them logically, and politely asks questions to fill in missing details. It is the path of least resistance. You use it when the direction is clear and you simply need a professional, organized document to secure approval or move into technical design. The PRFAQ, which stands for Press Release and Frequently Asked Questions, is a completely different mechanism. This is a rigorous, customer-first stress test. It forces you to work backwards from an imagined launch day. You start by writing a concise press release announcing the finished product to your target audience. At this point, the AI drops the helpful co-pilot persona and becomes a skeptical stakeholder. It reads your press release and generates a gauntlet of brutal, probing questions. Consider a scenario where you want to build a new internal deployment tool. You write a press release boasting that deployments will now take one click instead of ten. In a Product Brief, the AI might simply ask you to list the supported platforms. In the PRFAQ gauntlet, the AI will ask how you plan to handle automated rollbacks when that single click deploys a critical bug. It will demand to know why the infrastructure team should adopt this tool over their existing, battle-tested scripts. You must answer these questions satisfactorily. If your answers are vague, the AI pushes back. You are forced to defend the value proposition, usability, and technical feasibility before any real engineering time is spent. Here is the key insight. The Product Brief focuses on what the product is, while the PRFAQ focuses on why the customer should care and whether your execution plan is realistic. The Brief builds consensus. The PRFAQ destroys weak assumptions. You deploy the PRFAQ when an idea is expensive, controversial, or highly ambiguous. Ultimately, surviving the PRFAQ gauntlet proves your concept can withstand real-world scrutiny, acting as an absolute defense against building features nobody actually asked for. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 5 of 15. The fastest way to build the wrong system is to let an AI hallucinate your requirements based on a loose prompt. You need to restrict the AI to exact boundaries before any code gets written. Locking down the PRD is the process that builds those boundaries. People often confuse project planning with technical solutioning. They think planning involves picking a database or mapping out microservices. That is incorrect. Planning is entirely about business logic. It dictates zero technical execution. The planning phase focuses exclusively on the What and the Why. The How belongs to an entirely different phase. In the BMad Method, this happens in Phase Two. The actor responsible is the product manager agent, John. John takes the outputs from phase one, specifically your approved PRFAQ and brainstorming documents, and consumes them. You trigger this process using a command called bmad dash create dash prd. John takes the vision from the PRFAQ and translates it into a rigid text file named PRD dot md. This document serves as the absolute source of truth for the rest of the project. To do this, John breaks the requirements down into two strict categories. These are Functional Requirements, or FRs, and Non-Functional Requirements, or NFRs. Functional Requirements define exactly what the system must do. Non-Functional Requirements define the operational constraints of the system, like performance thresholds, compliance rules, or availability. Consider a concrete scenario. You are building a SaaS billing module. You feed your approved PRFAQ to the PM agent. John outputs Functional Requirements stating that the module must allow users to upgrade their subscription, and it must automatically downgrade users if a payment fails three times. Then, John outputs Non-Functional Requirements stating that all payment status updates must reflect in the user dashboard within two seconds. Here is the key insight. Notice what is missing from those requirements. John does not mention Stripe, he does not mention PostgreSQL, and he does not design an API payload. If your PRD mentions a specific database technology, the process has failed. The PRD only locks down the business expectation. Once the PRD is locked, Phase Two moves into the UX Design workflow. This step takes the raw business logic and maps out the human interaction. If a functional requirement says a user needs to upgrade a subscription, the UX design workflow dictates the exact sequence of screens, buttons, and error messages the user will encounter. Just like the PRD, this UX workflow makes zero frontend framework choices. It does not care if you eventually use React or Vue. It only cares about the step-by-step user journey. By forcing the PM agent to generate a strict, technology-agnostic PRD and UX flow, you create an anchor. Large language models naturally drift over time. Later in the project, your engineering agents will be forced to check their technical solutions against these exact FRs and NFRs. If a feature is not in the PRD, the agents will not build it. The PRD is not a casual suggestion document; it is a rigid boundary for your AI agents that completely isolates your core business needs from the eventual technical implementation. I would like to take a moment to thank you for listening — it helps us a lot. Have a great one!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 6 of 15. If you assign two AI agents to build two different features without a shared architecture document, they will inevitably declare war on each other's code. They will make conflicting technical choices that break your application. The mechanism to stop this is Phase 3 Solutioning, specifically focusing on preventing agent conflicts with architecture. Humans working on a software project talk to each other. They share assumptions over coffee or through chat messages. AI agents operating in parallel do not have a shared consciousness. They operate in completely isolated context windows. Give Agent A the task of implementing a user dashboard, and it might decide a REST API and Redux fit best. Give Agent B the task of building a user settings page, and it might independently decide to spin up GraphQL and Zustand. When those two features try to merge into the main branch, you face a massive integration problem. Both agents did exactly what you asked, but their isolated optimizations created systemic chaos. Developers often want to skip formal architecture documentation because it feels like corporate overhead. If you are hacking together a tiny, isolated script, that is acceptable. The BMad Method includes a Quick Flow specifically for small tasks that deliberately bypasses this phase. But for complex projects, skipping the architecture phase guarantees agent drift. You cannot rely on the default behavior of large language models to accidentally align on the same technical stack across different sessions. To enforce technical alignment, the method uses a specific workflow called bmad create architecture. You execute this workflow before a single line of application code is written. It analyzes your project requirements and generates Architecture Decision Records. Architecture Decision Records are lightweight, structured text files. They capture the definitive technical choices for the project. One record dictates the state management library. Another specifies the exact pattern for data fetching. A third defines the testing framework. They establish the hard, unbending rules of the system. Here is the key insight. In traditional software engineering, an architecture decision record is primarily a historical log to help new human developers understand past choices. In a multi-agent AI system, it is an active control mechanism. Large language models have no memory of what another model decided unless you explicitly feed that information into their prompt context. When you run the architecture workflow, the resulting documents are saved directly into your project repository. Later, when you deploy Agent A to build the dashboard and Agent B to build the settings, the system feeds these exact same decision records to both agents before they start writing code. The architecture files act as the ultimate ground truth. Agent A reads the record dictating Redux and REST, and builds accordingly. Agent B reads the exact same record, and also builds with Redux and REST. The architectural boundaries force independent models to act as a cohesive team. By removing the burden of choice during the feature implementation phase, you drastically reduce hallucinations and prevent conflicting dependencies. Architecture documents in an AI workflow are not just passive notes for humans; they are programmable constraints that force non-deterministic agents to build a deterministic system. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 7 of 15. AI agents default to generic best practices, which means they write code that looks like an average Stack Overflow answer, not your codebase. If you want them to code exactly like your senior engineering team, you have to enforce your own laws. That is what The Project Context Constitution does. At its core, this is a file named project-context.md. You place it at the root of your repository. Think of it as the ultimate governing document for any AI interacting with your project. When an agent reads your repository, it loads this file first to understand the non-negotiable boundaries of your architecture. You can create this file manually, or you can generate a starting point by running the command bmad-generate-project-context in your terminal. Either way, the document must contain two specific sections. These are the Tech Stack, and the Critical Rules. The Tech Stack section is straightforward but requires precision. You do not just list React or Node. You specify the exact versions, the routing paradigm, and the styling libraries. If you are using Next.js with the App Router and Tailwind, state exactly that. The AI uses this to filter its vast training data down to the specific syntax your project requires. Now, the second piece of this is the Critical Rules section. Pay attention to this bit. A very common mistake developers make is filling this section with generic advice like write clean code or use DRY principles. Do not do that. The AI already knows generic clean code. You need to write down the unobvious, project-specific patterns that the agent could never guess on its own. This is where you lay down strict architectural laws. For example, you write a rule that mandates strict mode TypeScript for every new file. You instruct the agent that all integration tests must use Mock Service Worker. Most importantly, you can forbid behaviors. If your project has a custom API client singleton, you explicitly write a rule that says never use native fetch or Axios directly, but always import the custom API client from the network utilities folder. When the AI generates a new feature, it cross-references its output against these rules. Because the project context sits at the top of the prompt hierarchy, these instructions override the baseline tendencies of the AI. If an agent tries to write a direct API fetch, the project context constitution forces it to rewrite that logic using your custom wrapper before it ever outputs the code. The goal of this file is not to teach the AI how to program, but to teach it how to program here, in this specific repository. If you enjoy these episodes and want to support the show, you can search for DevStoriesEU on Patreon. I would like to take a moment to thank you for listening — it helps us a lot. Have a great one!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 8 of 15. Before you let an AI write hundreds of lines of code, there is one critical step you must run to prevent a catastrophic sprint. That step is Breaking Work Down and The Gate Check. At this stage of the workflow, you have a finalized Product Requirements Document and a completed Architecture design. Now you need tickets. This is where the Project Manager agent steps in. Its job is to execute the create epics and stories process. The PM agent reads the requirements document, but it does not operate in a vacuum. It cross-references those business needs with the constraints defined in your Architecture documentation. The PM agent translates high-level features into Epics. Then it slices those Epics into specific, actionable User Stories. It drafts the acceptance criteria and the technical context for each task. By referencing the Architecture documents, the PM ensures that the data models and component interactions required by the story actually exist in the technical plan. This guarantees that every ticket serves a real business requirement while strictly conforming to the boundaries of the system design. The output of this step is a fully populated backlog. Here is the key insight. Once that backlog exists, the temptation is overwhelming to immediately start generating code. People routinely skip the next step out of sheer impatience. They want to see working software, so they push the new tickets straight to development. Do not do this. Skipping the readiness check is how you end up burning expensive API tokens on code that cannot be integrated. This is why the Architect agent steps back in to perform the check implementation readiness phase. This is your ultimate safety net. It operates as a strict gate check before any programming begins. The Architect reads every single Epic and User Story generated by the PM and validates them directly against the Architecture. The Architect is looking for missing technical prerequisites, architectural contradictions, or silent assumptions. It verifies that every data structure mentioned in a story has a corresponding database schema. It checks that the necessary service endpoints are actually defined. Consider a specific scenario. You run the gate check, and the Architect flags an Epic for a new user notification feature. The ticket assumes the use of a specific third-party messaging API. However, the Architect points out that this integration was never discussed or approved in the Architecture Decision Records. The gate check halts the process immediately. You just saved hours of wasted development time trying to build a feature against an unapproved or undocumented dependency. This collaboration between business needs and technical reality is the core of this phase. The PM agent defines the work based on what the user requires. The Architect agent verifies the work based on what the system can actually support. You only move forward when the Architect signs off, proving that the backlog is completely implementable. A perfect product requirement is entirely useless if the underlying system architecture cannot support it, and this gate check is the only objective proof that your tickets are actually ready to build. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 9 of 15. You do not just tell an AI to build an application. If you ask a language model to implement an entire product feature or an Epic at once, you will get half-baked logic, missing files, and a tangled mess of code. To get production-grade output from AI, you have to enforce the exact same discipline you expect from a high-performing human engineering team. Today we look at The Build Cycle and Sprint Tracking, which is the mechanical, disciplined loop of executing phase four implementation. The biggest mistake developers make with AI tools is asking for too much at once. The build cycle relies entirely on strict, one-story-at-a-time execution. You track state, you pick up a single story, you execute it, you validate it, and you update your state. This process requires distinct personas handling specific parts of the pipeline, ensuring no context is lost and no scope is bloated. The cycle begins with sprint planning. You run the bmad sprint planning prompt, which generates a file called sprint status yaml. This file is your absolute source of truth. It explicitly lists every story in your current sprint and marks its status as pending, in progress, or done. This document keeps the AI grounded. It prevents the model from hallucinating progress or forgetting dependencies because the AI must constantly read this file to understand the current state of the project. Once your sprint is planned, you start the execution loop. First, you engage the Scrum Master persona, Bob, using the bmad create story prompt. You instruct Bob to look at the sprint status yaml file and pick up the top pending item. Bob does not write any application code. Instead, he generates a highly focused markdown file dedicated exclusively to that single user story. This document outlines the specific acceptance criteria, technical constraints, and test scenarios required to complete the task. Next, you hand that isolated story file over to the Developer persona, Amelia. You use the bmad dev story prompt to initiate this step. Amelia reads the story file, analyzes the current codebase, and implements the logic. Because her context is artificially narrowed to just Bob's instructions and the relevant application files, she will not accidentally rewrite unrelated modules or drift outside the scope of the immediate task. After Amelia writes the code, the story is not yet done. You invoke the bmad code review prompt. This acts as an automated quality gate. The review process checks Amelia's code against the strict acceptance criteria defined in Bob's story file. It surfaces missing edge cases, logic flaws, or formatting inconsistencies. You fix any issues found during this review. Only when the code passes do you update the sprint status yaml file, manually changing the story from in progress to completed. Then, you loop back to Bob to pull the next pending item. Here is the key insight. The power of this loop is not in the code generation itself, but in the strict separation of concerns that forces the AI to plan, execute, and review as distinct, isolated steps. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 10 of 15. Sometimes the full agile process is overkill for a localized fix. You have a messy Jira bug report, and you just want it fixed and reviewed without manually verifying every step. Here is how to go from that raw ticket to a reviewed pull request in a single, autonomous run using the Quick Dev Track for Zero-Blast Changes. People often view Quick Dev as just a generic code prompt where you throw a ticket at a large language model and hope for the best. It is not. Quick Dev explicitly isolates intent clarification from execution. It gives the system a hard boundary to work against, rather than bleeding the problem definition directly into the code generation step. The standard agile track relies heavily on strict checkpoints. You pause, verify the plan, verify the tests, and verify the implementation. Quick Dev strips those checkpoints away. It trusts the model more and saves your human attention for high-leverage moments. You only use this track for zero-blast-radius changes. Mechanically, this means modifications must be isolated to a single component or function. The change cannot alter public interfaces, modify database schemas, or rewrite shared utility functions used by other domains. If a change touches core state management, it belongs on the standard track. Consider the scenario where you pass a link to a fragmented Jira bug ticket into the bmad-quick-dev tool. The first thing the system executes is intent compression. It reads the scattered comments, the steps to reproduce, and the user complaints. It forces the model to resolve contradictions before touching any code. If the ticket has conflicting instructions, the compression step synthesizes them into a single, definitive goal. This output is plain text, defining exactly what the fix entails and, critically, what the boundaries of the fix are. Here is the key insight. Because the intent is now compressed and isolated, the autonomous execution phase has a strict specification to follow. The system writes the fix, generates or updates the localized tests, and runs a self-review against that initial compressed intent. It loops through these steps continuously. You step away while it works, and you return to a finished pull request. Quick Dev is fast, but when an autonomous run fails, you must diagnose the failure layers accurately. You look at where the process broke. If the final code solves the wrong problem entirely, the failure happened at the intent compression layer. The Jira ticket was likely too ambiguous, causing the model to hallucinate the goal. You fix this by rewriting the initial input. If the intent is correct but the new tests fail or the build breaks, the failure is in the execution layer. You fix execution failures by nudging the model to retry the specific logic block. If the execution layer fails twice in a row, the problem is no longer the prompt. The blast radius of the change was simply larger than you initially thought, and you must drop back to the standard, checkpointed track. Autonomy only works when the boundary of the task is smaller than the context window of the model solving it. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 11 of 15. Most AI coding frameworks assume you are starting from a completely empty directory. They want to generate the scaffolding, dictate the architecture, and own the entire process from day one. But when you drop an AI agent into a massive, five-year-old Rails monolith with undocumented naming conventions, that blank-slate approach breaks everything. Onboarding Established Codebases is how you make BMad work with what you already have. A frequent assumption developers make is that BMad is strictly for greenfield development. That is incorrect. BMad does not force a rewrite or impose an external structure. It is built to adapt, respecting and discovering your existing architecture to integrate cleanly. However, ingesting an established repository requires a specific workflow to prevent the AI from adopting your technical debt. The very first step is cleaning up artifacts. AI models are essentially advanced pattern-matching engines. If you point them at a repository filled with commented-out code blocks, deprecated API calls, and inconsistent file naming, the agent will assume those are the accepted standards. Before introducing the agent, you must remove dead code, enforce your linting rules, and ensure your test suite is actually passing. You are setting the baseline standard. The cleaner the input state, the better the agent will align with your actual intentions. Once the repository is clean, you map it using a command called bmad-generate-project-context. This is where the adaptation happens. Rather than manually typing out pages of documentation about how your application is structured, you run this tool to scan your legacy patterns. Think back to that five-year-old Rails monolith. The context generator reads the file tree, parses the abstractions, and deduces your undocumented rules. It determines whether your team prefers fat models or service objects. It analyzes your testing directory to see how you mock database calls. It takes all these deductions and writes them into a centralized context document. This file becomes the foundational prompt for the AI. When you ask the agent to build a new feature, it reads this context first. It understands the existing architecture and generates code that looks exactly like a senior engineer on your team wrote it. With the context generated, you choose how to apply updates using either Quick Dev or the Full Method. Your choice depends entirely on the complexity of the task. If you are fixing a localized bug or adding a single query parameter to an existing endpoint, use Quick Dev. The agent reads your context file, applies the targeted patch, verifies it against your local tests, and exits. It is a rapid, low-overhead operation. Now, the second piece of this handles complex updates. If you need to build an entirely new billing module into that monolith, you switch to the Full Method. The agent will leverage the context file to write a comprehensive design document first. It outlines how the new module will interact with your existing components. It writes failing tests that match your legacy testing style, implements the business logic, and iterates until the tests pass. The framework scales its rigor based on what the task demands. Here is the key insight. The success of an AI agent in a legacy repository depends entirely on the quality of the patterns it detects, which means a rigorous initial cleanup and an accurate context file are the only things standing between a seamless feature addition and architectural chaos. I would like to take a moment to thank you for listening — it helps us a lot. Have a great one!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 12 of 15. You open your terminal, type a command to format your code, and get a completely generic error. You are trying to use an internal agent command, but the agent is not even running yet. There are two distinct ways to command your AI workforce, and mixing them up is the most common friction point in the system. Today we cover Commanding Agents: Skills versus Triggers. The first category is Skills. Think of Skills as your global entry points. These are what you type into your IDE terminal or command line to launch an action from scratch. When you type bmad-help or trigger a specific agent launch script from your IDE, you are using a Skill. It boots up the environment. It loads the necessary context. It brings the agent online. Skills belong outside the agent conversation. They are the mechanisms that start the engine. This brings us to the common trap. Once the engine is running and you are chatting with an agent, the rules change. You stop using Skills and start using Triggers. A Trigger is a short code typed directly into an active chat session to command an agent that is already listening. If you type an agent menu trigger into your standard terminal, the system has no idea what you mean. If you try to run an IDE Skill from inside an agent chat, it fails. The boundary is absolute. Skills start the session. Triggers control the active session. Once you are inside the chat, Triggers come in two flavors: Workflow Triggers and Conversational Triggers. Workflow Triggers launch rigid, predefined sequences. You type the trigger, the agent executes a specific multi-step process step by step, delivers the output, and the sequence ends. Conversational Triggers are much more fluid. They allow for dynamic task-switching without breaking the agent persona. You stay in the chat, but you pivot the active focus. Consider a concrete scenario. You need new documentation. You start by using an IDE Skill to launch Paige, the Technical Writer agent. The Skill boots Paige up, and she asks what you need. She is now active. Now, instead of writing a massive prompt explaining that you need a specific type of document formatted in a specific way, you simply type the conversational trigger W D to the active chat prompt. This stands for Write Docs. Paige immediately switches into her predefined documentation drafting mode. She asks for your raw notes, processes them, and generates the text. You read the text and realize you need an architecture diagram to accompany it. You do not close the chat. You do not launch a new Skill from the terminal. You just type another conversational trigger, M G, which stands for Mermaid Graph. Paige instantly pivots. She stays in character as your technical writer, keeps the context of the document she just wrote, and generates the Mermaid diagram code to match. You are dynamically routing her capabilities on the fly without ever dropping the context. Here is the key insight. The true power of this dual system is not just having shorter things to type, but maintaining a persistent, intelligent context while instantly switching an agent's internal operating mode. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 13 of 15. Your AI code reviews are probably way too nice. When you simply ask a model to look for bugs, it hands you polite suggestions and generic syntax checks. To find catastrophic flaws, you need specialized, opinionated diagnostic engines. This episode covers exactly that: Adversarial Review and Edge Case Hunting. People often treat AI code review as a single, general-purpose pass. They throw a diff at a model and hope it catches everything. This rarely works well. A generic prompt lacks a specific mental model, leading to shallow feedback. The BMad methodology solves this by using tightly scoped, specialized personas. We are going to look at two distinct review tools that operate with completely different methodologies. First, consider the adversarial reviewer. This tool is attitude-driven and highly skeptical. It does not trust your code, your infrastructure, or your users. It assumes your implementation is fundamentally broken and actively looks for ways it can be exploited. It completely ignores stylistic choices, variable naming, or minor performance optimizations. Instead, it hunts exclusively for business logic gaps, privilege escalations, and broken trust assumptions. The adversarial reviewer looks at your API perimeters and asks how a bad actor could bypass your intended flow. It reads your code with deep cynicism, treating every input as a potential attack vector and every data boundary as a weakness. Next, we have the edge case hunter. This tool operates with the exact opposite personality. It is mathematically cold, devoid of context, and entirely mechanical. It does not care about malicious users or business intent. Instead, it performs strict path-tracing. It builds a mental control flow graph of your code and follows every single branch to its logical conclusion. The edge case hunter focuses purely on state mutations, boundary conditions, and data types. It looks for the obscure execution paths that cause silent failures, memory leaks, or unhandled exceptions. To see the difference, apply both tools to a single piece of code, like a complex authentication diff. You pass this code to the adversarial reviewer first. Because it operates on cynicism, it ignores the mechanical syntax and spots a missing business logic constraint. It notices that while the authentication token is validated properly, the system implicitly trusts the user role embedded inside that token without checking the live database. The adversarial reviewer flags this as a critical trust vulnerability. Now you pass that exact same authentication diff to the edge case hunter. This tool ignores the token trust logic completely. Instead, via mechanical path derivation, it tracks the lifecycle of every variable. It finds a deeply nested validation function that lacks an explicit type check. It points out an unhandled implicit type coercion. If the input payload contains a null object instead of a string at that specific index, the application will throw an unhandled exception and crash. Here is the key insight. You do not use these tools to catch typos. You use them to force two distinct analytical frameworks onto your codebase. One attacks your assumptions about system trust and human behavior. The other attacks your assumptions about execution paths and data states. By separating the cynical attacker from the mechanical path-tracer, you stop relying on generic bug-finding and start exposing deep structural vulnerabilities before they ever reach production. Thanks for tuning in. Until next time!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 14 of 15. If you feed a fifty page document directly into a large language model, it will almost immediately suffer from context blindness. It drops details from the middle of the text, hallucinates facts, and degrades its own reasoning capability. To fix this, you need a lossless compression trick. Today we are covering Managing Context: Distillation and Sharding. Many developers think distillation is just summarization. That is incorrect. Summarization intentionally throws away data to give a human a quick overview. Distillation is a verifiable, lossless compression process. Here is the key insight. The distillator tool takes verbose human prose, strips out the transitions, adjectives, and conversational filler, and converts it into a highly dense bulleted format. This format is built strictly for machine reading. You keep every single fact, but drastically lower the token count. Take that massive fifty page technical whitepaper. If you run it through the distillator tool, you can achieve something like a three point two to one compression ratio. The overall payload size drops by more than two thirds, yet the model retains access to every technical specification and architectural decision. The AI reads the raw data faster and processes the logic more accurately without drowning in human formatted paragraphs. That handles the density of the text, but the overall volume might still be too large to fit cleanly into a single prompt context. This is where the shard document tool comes into play. Sharding mechanically breaks your distilled whitepaper into smaller, standalone text files based on logical boundaries like chapters or distinct sections. You run the shard command, point it at your heavy document, and it outputs a numbered sequence of lightweight files. Instead of forcing the AI to hold the entire whitepaper in working memory, you now have modular pieces. Once you have twenty shard files sitting in a directory, the system needs a way to navigate them. You handle this with the index documents tool. You point the index command at the folder containing your new shards. The tool scans the directory and generates a single master index file. This master file acts as a routing map, listing each shard alongside a brief description of what it contains. In practice, you feed this lightweight index to the language model first. The model reads the map, determines which specific chapter contains the information required to answer a prompt, and then requests only that specific shard. The reasoning stays sharp because the context window remains entirely focused on the relevant data. The single most useful thing to remember here is that a massive context window is not an excuse to dump raw files into a prompt. Structuring your inputs through mechanical distillation and indexed shards forces the model to read systematically instead of scanning blindly. If you find these episodes useful and want to support the show, you can search for DevStoriesEU on Patreon. That is all for this one. Thanks for listening, and keep building!

Hi, this is Alex from DEV STORIES DOT EU. BMad Method, episode 15 of 15. Never ask a language model to just make something better. Vague requests yield lazy, generic revisions. If you want structural improvements, you need to force the model into a rigid reasoning framework, or better yet, spawn three different AI personas and watch them debate the flaws. This is the exact domain of Advanced Elicitation and Party Mode. A common trap when refining outputs, like a newly generated Product Requirements Document, is prompting the model to review and improve its own work. Language models are designed to be helpful and agreeable. When you ask for a general improvement, the model will typically alter a few adjectives, restructure a sentence, and hand it back. It will not rewrite the core logic. Advanced Elicitation solves this by applying formal, recognized mental models to the AI output. You stop asking for general feedback. Instead, you instruct the model to execute a specific cognitive framework. Take the Pre-mortem analysis. You feed your freshly generated requirements document to the model. You instruct it to assume the project has been built, launched, and is an absolute, catastrophic failure. The model must then work backward to diagnose exactly what caused the failure, relying only on the current document. Because you constrained the prompt to a specific failure state, the model bypasses its polite guardrails and aggressively hunts for logic gaps. Another powerful framework is Inversion. Rather than asking how to make a database migration safe, you ask the model to outline the exact steps required to guarantee maximum data loss during the migration. Named reasoning frameworks yield vastly superior results because they force the model out of its default, highly probable text generation paths and into highly specific analytical pathways. Once you identify those guaranteed failures, you have to design the fix. You could ask a single persona to solve the problem, but complex architectural issues require tension. This brings us to Party Mode. The Party Mode tool orchestrates a multi-agent group discussion. You are no longer interacting with a single assistant. You configure a virtual room full of specific, specialized personas, hand them the problem, and step back to let them argue. Here is how the logic flows. You launch the Party Mode tool and define your participants. You might instantiate a Senior Solutions Architect, a paranoid Security Engineer, and a pragmatic Frontend Developer. You pass them the vulnerabilities discovered during your Pre-mortem analysis. The tool then manages the conversation loop autonomously. The Architect proposes a robust, complex fix. The tool passes that output to the Security Engineer, who attacks the proposal for potential exploit vectors. The tool then passes the context to the Developer, who complains about the implementation complexity and suggests a simpler approach. They iterate on these arguments, challenging each other without your intervention, until they either reach a consensus or hit a defined turn limit. You get to observe the debate and extract the finalized, battle-tested solution from the transcript. This approach shifts you from acting as a prompt writer to a director of reasoning engines. You use Advanced Elicitation to systematically break your own ideas, and Party Mode to engineer the rebuild through synthetic friction. The single most valuable shift in working with language models is realizing that engineered disagreement always produces better technical architecture than immediate, polite compliance. As this is the final episode of the series, we highly encourage you to read the official BMad documentation, try orchestrating these debates hands-on, or visit devstories dot eu to suggest topics for our next series. I would like to take a moment to thank you for listening — it helps us a lot. Have a great one!