Research, spec-driven development, and where BMAD fits

The book has shipped a recommender, wrapped it in a rubric, and drawn the production blueprint. What it has not answered is the question every shipped system asks within a week: what do we build next? The capstone's own scorecards left a pile of candidates: the diversity FAIL from Chapter 27, the Case D/E gray zone that eats judge budget, an EMA half-life that was chosen by feel, thumbnails whose pixels we hash for dedupe but ignore for ranking. Picking among them by gut is how quarters get wasted.

Picking among them systematically is called research, and this part of the book treats it the way earlier parts treated ranking: as a process with structure, tools, and measurable output. The tool at the center is BMAD, an open-source method for AI-driven development in which research is a first-class phase. The part is built as a ladder:

• This chapter sets the concepts: what research is, spec-driven development, and where BMAD sits in the landscape of tools.
• Chapter 31 is the map: BMAD's modules, its four phases, its six named personas, and the full command surface, organized so you can find any skill and know which persona owns it.
• Chapter 32 opens the research skill itself, bmad-deep-recon, down to its run folder, its ledger, and the Python it runs, with a lab you can execute.
• Chapter 33 runs the whole thing on our feed: one finding riding from a research report all the way down to a story a dev agent implements.
• Chapter 34 opens the machinery underneath (parallel agents, knowledge graphs, and the decision theory of what to investigate next); Chapter 35 compares the hosted research engines and asks what happens to the questions you type; and Chapter 36 leaves the codebase for the research no engineer sees coming.

What research is, and what it is for

Research is the systematic reduction of uncertainty before you commit resources. That definition sounds bloodless, so here is the same idea with money attached: an engineer-quarter costs a company something like $50k to $100k. Committing one to "add image embeddings to the profile" on a hunch is a bet at those stakes. A week of research that moves the bet from "hunch" to "evidence from three sources plus one offline ablation" is the cheapest insurance the team can buy.

For a product team, research comes in a few distinct kinds, and confusing them wastes time because each kind has different sources and a different standard of proof:

The purpose, in all four kinds, is the same three outcomes:

1. Kill bad ideas while they are cheap. An idea killed by a two-day literature check costs two days. The same idea killed by a shipped A/B test costs a quarter plus the user trust it burned.
2. De-risk the expensive commitments. Research does not make the image embedding project safe; it tells you which part is risky (the lift is contested in the literature; the serving cost is not) so the plan attacks the risk first.
3. Borrow instead of reinvent. Pinterest published how they represent users with multiple interest clusters instead of one averaged vector. Reading that paper costs an afternoon; rediscovering its lesson in production costs a bad quarter.

Don't be confused: brainstorming vs. research vs. planning. Brainstorming generates candidate ideas from what is already in the room. Research tests candidates against the world outside the room: literature, competitors, experiments. Planning sequences the survivors into commitments. The failure mode of skipping the middle step has a name in every engineering culture ("we built my best guess"), and AI assistants make it worse, because a model will cheerfully generate a confident plan from an untested guess.

Spec-driven development in one page

Spec-driven development (SDD) inverts the code-first habit: you write down what should exist and why, get that document reviewed, and only then generate the code from it. The idea is older than AI (requirements engineering is a whole discipline), but LLM coding agents revived it, for one blunt reason: an agent amplifies whatever you give it. Give a strong model a vague sentence and it produces confident code for some interpretation of your words, compounding the ambiguity at machine speed. Give it a reviewed spec and the same amplification works in your favor. The spec is context engineering: it is the difference between the agent guessing your constraints and reading them.

A full SDD pipeline is a chain of documents, each consumed by the next stage:

 research      brief         PRD          architecture     stories        code
 report   ->  (what &   ->  (functional -> (how it will  -> (one unit  ->  (agent
 (evidence)    why now)      requirements)  be built)        of work)       implements)

Each arrow is a review point where a human can catch a wrong turn while it is still a paragraph instead of a pull request. And the leftmost box is the one this part of the book is about: research is what makes the PRD's claims true instead of hopeful. A PRD that says "users abandon duplicate-heavy feeds" either cites evidence or launders an assumption, and every downstream document inherits the difference. That chain is not a metaphor in BMAD; Chapter 33 watches an actual finding travel every arrow of it.

BMAD: the method, briefly

BMAD is an open-source framework created by Brian Madison, who goes by "BMad," and first released in 2025. The current documentation expands the name as Build More Architect Dreams; the repository's older tagline, still visible on GitHub, is "Breakthrough Method for Agile AI Driven Development." As of mid-2026 it sits at v6 (out of beta since February 2026, with minor releases landing roughly monthly since), is MIT-licensed, and its repo (bmad-code-org/BMAD-METHOD) carries on the order of 50,000 stars. You install it into a project with one command:

npx bmad-method install --yes --modules bmm --tools claude-code

which writes a _bmad/ directory of configuration plus a set of skills (BMAD v6 adopted the same Agent Skills format Claude Code uses, so bmad-* commands appear in your IDE assistant like any other skill). The full map (modules, phases, personas, and every command) is Chapter 31; the one-paragraph version is: BMAD organizes work into four phases (Analysis, Planning, Solutioning, Implementation), runs each phase through a named persona agent with fixed standards, and passes reviewed documents between phases so a fresh chat never loses the thread.

Why BMAD is a good research tool specifically

Four reasons, in decreasing order of importance:

1. Research is a phase, not a footnote. Most coding-agent frameworks start at "describe the feature." BMAD's Analysis phase exists before that, with its own persona (Mary the Business Analyst) and its own skills: brainstorming, idea pressure-testing, codebase documentation for brownfield projects, and above all bmad-deep-recon, a dedicated research skill with typed research packs (market, domain, technical, competitive, user-voice, academic-lit). You do not bolt research onto the process; the process starts with it.
2. Epistemic discipline is written into the skill. Deep Recon's rules include, verbatim, "Never conclude from training data alone" and a "research firewall": project context shapes what to ask, never what is true, and research subagents receive only their brief, no ambient project files. Every claim needs a publisher and dates. A staleness map records which claims age fastest and when to re-check them. These are exactly the rules a good human researcher follows, made mechanical. Chapter 32 quotes the skill itself.
3. Research has a customer. Deep Recon's output (research.md, with numbered citations resolving to a source appendix) is formatted so the product-brief and PRD skills consume it directly. Research that feeds nothing is entertainment; the pipeline guarantees a reader.
4. It meters honestly. The planning personas also ship as web bundles (Gemini Gems, ChatGPT custom GPTs), so long research conversations can run on a flat-rate chat subscription instead of metered IDE tokens, with the artifacts pasted back into the repo.

The other tools worth considering

BMAD is not alone, and the honest comparison is by where research lives in each tool.

Spec-driven siblings

All five share the SDD spine (reviewable documents before code). BMAD is the only one in the table where "go find out whether this is true in outside sources, cite it, verify it, and track when it goes stale" is a named core step. OpenSpec's Explore is valuable thinking grounded in the repository; that is a different evidence boundary. Spec Kit's workflow engine can be extended to run almost any step, but you must supply the research procedure. If your team already lives in spec-kit, Kiro, or OpenSpec, nothing stops you from running a BMAD-style research phase and feeding the report into /speckit.specify, requirements.md, or /opsx:propose; the documents are portable.

Deep-research engines

These tools execute the search itself: agentic, multi-step, cited web research. They pair with BMAD rather than compete with it (Deep Recon's Draft mode literally writes prompts for them; its Process mode ingests their reports back), and Chapter 35 compares them head to head:

For the academic slice there are also raw graph APIs (Semantic Scholar, OpenAlex), which Chapter 34 uses.

The lightweight path: your coding agent, plain

Claude Code (or any comparable agent) already contains the primitives: plan mode for read-before-write, CLAUDE.md and memory for standing context, skills for repeatable procedures, subagents for parallel sweeps. A disciplined engineer can run the whole research-to-spec loop with those and a folder of markdown. BMAD's value over the DIY path is that the discipline is packaged: the templates, the firewall rules, the citation format, the phase gates, and the personas arrive tested instead of homegrown. Teams with strong existing conventions reasonably choose the DIY path; teams starting from zero rarely regret starting from a method.

When BMAD is the wrong tool

• The prototype is the research. Chapter 27 answered "can a heuristic judge duplicates?" by writing the 30-line heuristic and looking. When an experiment is cheaper than a literature sweep, run the experiment; no document chain needed.
• The change is small. A bugfix or a one-file feature does not need Analysis-to-Implementation ceremony. BMAD itself acknowledges this with a quick-flow track (bmad-quick-dev) that skips the PRD entirely; use it, or skip the method.
• The decision is already made. If leadership has committed to the project regardless of findings, research is theater. Spend the effort on de-risking how instead of relitigating whether (feasibility spikes, not market reports).

Everything else, the genuinely uncertain, genuinely expensive decisions, is what this part walks through. The next chapter lays out the whole board: every module, phase, persona, and command, so that when Chapter 33 runs a real cycle, you already know who each named agent is and which skill it reaches for. 👉