Files
BMAD-METHOD/docs/reference/core-tools.md
T
Brian 8b4da79161 refactor(core): group v6 shims and merge editorial review into bmad-review as lenses (#2608)
* refactor: group v6 deprecation shims into v6-shims folders

Move the nine backward-compatibility forwarders into dedicated v6-shims/
folders so the deprecation set is visible in one place and can later be
made an install-time include/exclude option before removal at the v7 cut.

core-skills/v6-shims/: the five review and editorial husks
bmm-skills/v6-shims/: the four PRD and architecture husks

Grouping only — no content changes. The installer discovers skills by a
recursive walk and installs each under its own name, so installed paths
and skill IDs are unchanged. Verified by diffing a full headless install
against main: identical .claude/skills listing and file content, and an
identical _bmad tree. The only delta is the path column in
skill-manifest.csv, which now records the new source location.

External module repos (gds, loop, tea, bmb, os-utils) and enterprise
users still invoke these IDs, so they continue to ship by default.

* refactor(core): merge editorial review into bmad-review as lenses

All reviews are reviews. bmad-editorial-review's two passes become two
more bmad-review lenses, leaving one lens runtime instead of two skills
with overlapping trigger descriptions — "review this document" matched
both before, so which one ran was close to arbitrary.

Lenses now declare what they apply to. applies_to is "code", "docs", or
"any", and is the first filter on a default review; `when` still refines
it in prose. adversarial stays "any" — it is a stance, not a subject-
matter method, and is the lens a code/doc skill split could not have
placed. edge-case-hunter's `when` was "always", which is why it would
have fired on prose; it now gates on having a behavioral surface.

A lens may also declare `after`, naming a lens it builds on: prose runs
on top of the structure findings, as it always has. The runner announces
the plan, runs the independent lenses (in parallel via subagents when
available), then the dependent ones on their results.

Lens wording is unchanged. The three code lens files are byte-identical;
the editorial passes moved verbatim into references/lens-structure.md,
references/lens-prose.md, and references/editorial-common.md, which
carries what both share — the content-sacrosanct rule, style guide
handling, reader calibration, and the findings table. That material used
to load unconditionally; as lenses it loads just-in-time, so a code
review no longer pays for it.

bmad-editorial-review becomes the sixth v6 shim, forwarding with the
structure and prose lenses named. It keeps its customize.toml so existing
team and user overrides still resolve, and forwards them as pre-resolved
values. The four other husks now name bmad-review and their lens
explicitly. Each still pins its own legacy output contract.

bmm's four document skills point doc_standards at the merged skill with
named lenses. Docs updated across all five locales.

Core is 7 skills. A headless install produces the same 47-skill set as
main, with all six shims resolving.

* fix(core): honor forwarded customization and de-hardcode the lens set

Follow-up to the editorial/review merge, from review of #2608.

Contract fixes:
- bmad-review gains a Forwarded activation clause matching bmad-prd and
  bmad-architecture, so the bmad-editorial-review shim's pre-resolved fields
  are honored instead of being silently overwritten by the skill's own
  customize.toml. Existing bmad-editorial-review overrides resolve again.
- The announce step is skipped when a caller pinned an exact output contract,
  and a forwarder's contract now governs everything emitted rather than the
  findings block alone. The edge-case (raw JSON) and verification-gap (one
  exact line) forwarders no longer get a prose line prepended.

Lens set is no longer hardcoded:
- The description and body intro present the shipped lenses as examples and
  point at whatever {workflow.lenses} resolves to. Docs carry a matching note
  in all five locales.

Also:
- Document the `lenses=` directive form in Inputs and in the four bmm
  doc_standards comments that use it.
- module-help.csv review row rewritten to the house "Use to..." convention,
  naming the reviewable content types and the situations that should trigger
  a suggestion.
- Shim customize.toml trimmed to a lean legacy-key surface with empty
  defaults, so unset keys fall through to bmad-review and project-context.md
  is no longer loaded twice.
- Redundant `when` clauses dropped where applies_to already encodes the rule.
- Core skill count corrected to seven/four and the edge-case applies_to cell
  fixed to match its actual value, across all five locales.
2026-07-19 18:40:47 -05:00

12 KiB
Raw Blame History

title, description, sidebar
title description sidebar
Core Tools Reference for the core module's built-in skills.
order
3

Every BMad installation includes the core module — a small set of skills that work across all projects, all modules, and all phases. This page covers those seven core skills: the four kernel tools plus the three thinking skills (brainstorming, forge idea, party mode).

:::tip[Quick Path] Run any tool by typing its skill name (e.g., bmad-help) in your IDE. No agent session required. :::

Overview

Core module (always installed):

Tool Purpose
bmad-help Get context-aware guidance on what to do next
bmad-advanced-elicitation Push LLM output through iterative refinement methods
bmad-review Multi-lens review — adversarial, edge-case, and verification-gap for code; structure and prose for documents
bmad-customize Create and verify BMad customization overrides

Thinking skills:

Tool Purpose
bmad-brainstorming Facilitate interactive brainstorming sessions
bmad-forge-idea Pressure-test an idea until it hardens, proves out, or dies cheaply
bmad-party-mode Orchestrate multi-agent group discussions

:::note[Moved and removed] bmad-spec now ships with the BMM module as a Phase 2 planning workflow — see the Workflow Map. The bmad-shard-doc and bmad-index-docs utilities have been removed. The former bmad-editorial-review, bmad-editorial-review-prose, bmad-editorial-review-structure, bmad-review-adversarial-general, bmad-review-edge-case-hunter, and bmad-review-verification-gap skills are all merged into bmad-review, whose editorial lenses replace the separate editorial skill; the old IDs still resolve via forwarders for compatibility. :::

bmad-help

Your intelligent guide to what comes next. — Inspects your project state, detects what's been done, and recommends the next required or optional step.

Use it when:

  • You finished a workflow and want to know what's next
  • You're new to BMad and need orientation
  • You're stuck and want context-aware advice
  • You installed new modules and want to see what's available

How it works:

  1. Scans your project for existing artifacts (PRD, architecture, stories, etc.)
  2. Detects which modules are installed and their available workflows
  3. Recommends next steps in priority order — required steps first, then optional
  4. Presents each recommendation with the skill command and a brief description

Input: Optional query in natural language (e.g., bmad-help I have a SaaS idea, where do I start?)

Output: Prioritized list of recommended next steps with skill commands

bmad-advanced-elicitation

Push the LLM to reconsider, refine, and improve its recent output. — BMad's shared refinement checkpoint: other skills invoke it at natural pauses, and you can call it directly on anything recent in the conversation.

Use it when:

  • LLM output feels shallow or generic
  • You want to explore a topic from multiple analytical angles
  • You're refining a critical document and want deeper thinking
  • You want a known method by name — Socratic, first principles, pre-mortem, red team

How it works:

  1. Targets the most recent output in the conversation unless you point it at something else
  2. Offers a short menu of best-fit elicitation methods for the content
  3. Applies the chosen methods against the target
  4. Hands back the improved version so the invoking flow resumes where it paused

Input: The recent output to refine (default), or any content you point it at; optionally a named method

Output: Enhanced version of the content with improvements applied

bmad-review

Multi-lens review over any diff, doc, or artifact. — Runs review lenses — each a distinct method and stance — and reports every finding in one canonical shape. Zero findings is a valid outcome; it never pads to look thorough. Each lens declares what it applies to, so a diff draws the code lenses and a document draws the editorial ones.

The shipped lenses:

Lens Applies to Method
Adversarial Anything Skeptical review that assumes problems exist — hunts what's missing, not just what's wrong
Edge case Anything Walks every branching path and boundary condition in content that defines behavior
Verification gap Code Finds changed behavior that could regress without reliable verification catching it
Structure Documents Proposes cuts, merges, moves, and condensing — does the document's shape serve its purpose?
Prose Documents Copy-edits for communication issues that impede comprehension

The two editorial lenses hold content sacrosanct: they never challenge your ideas, only how they're organized and expressed, and they propose rather than execute. Prose runs on top of the structure findings when both are selected.

The set isn't fixed: a customize.toml override can add lenses or replace shipped ones, and a review runs whatever resolves.

Use it when:

  • You need quality assurance before finalizing a deliverable
  • You want exhaustive edge-case coverage of code or logic
  • You want to know whether a change is adequately verified
  • You've drafted a document and want it tightened and polished
  • You want to reduce length while preserving comprehension

How it works:

  1. Loads the content, identifies its type — diff, file, function, or document — and whether it is code or docs
  2. Selects lenses: the ones you name, or every enabled lens whose applicability and conditions fit the content
  3. Announces the plan — which lenses will run, and which run on top of another's findings
  4. Runs the independent lenses — in parallel via subagents when the platform supports it — then the dependent ones on top of their results
  5. Assembles one findings array; overlap between lenses is signal, not duplication

Input:

  • content (required) — Diff, branch, uncommitted changes, file, spec, story, or any document
  • lenses (optional) — one or more lens codes or names; default is every lens that fits the content
  • also_consider (optional) — Additional areas to keep in mind
  • style_guide / reader_type (optional, editorial lenses) — a project style guide, and humans (default) for clarity/flow or llm for precision/consistency

Output: JSON findings array (each finding carries lens, location, trigger_condition, guard_snippet, potential_consequence) and/or a markdown report grouped by lens. The editorial lenses render a findings table you accept or reject row by row, plus an estimated reduction when structural changes are proposed.

:::note[Used by other workflows] Code Review workflows in other modules run the code lenses automatically, and the document workflows (PRD, UX, architecture, product brief) run the editorial lenses as their finalize step. Custom lenses can be added — and shipped ones tuned or disabled — through the skill's customize.toml. :::

bmad-customize

Create and verify customization overrides. — Helps you change how an installed BMad agent or workflow behaves without hand-authoring TOML.

Use it when:

  • You want to change an agent or workflow behavior
  • You need to add persistent facts, activation hooks, or custom menu items
  • You want the right override scope selected and verified automatically

How it works:

  1. Scans installed BMad skills for customizable surfaces
  2. Selects the right scope for your requested change
  3. Writes override files under _bmad/custom/
  4. Verifies the merged configuration

Input: Natural language description of the customization you want

Output: TOML override files under _bmad/custom/

For a detailed guide on customizing BMad, see How to Customize BMad.

Thinking Skills

The three skills below round out the core module — general-purpose thinking tools that any phase or module can lean on.

bmad-brainstorming

Generate diverse ideas through interactive creative techniques. — A facilitated brainstorming session that loads proven ideation methods from a technique library and guides you toward 100+ ideas before organizing.

Use it when:

  • You're starting a new project and need to explore the problem space
  • You're stuck generating ideas and need structured creativity
  • You want to use proven ideation frameworks (SCAMPER, reverse brainstorming, etc.)

How it works:

  1. Sets up a brainstorming session with your topic
  2. Loads creative techniques from a method library
  3. Guides you through technique after technique, generating ideas
  4. Applies anti-bias protocol — shifts creative domain every 10 ideas to prevent clustering
  5. Produces an append-only session document with all ideas organized by technique

Input: Brainstorming topic or problem statement, optional context file

Output: a self-contained brainstorm.html keepsake of the session, an optional brainstorm-intent.md for downstream skills, and a .memlog.md session record

:::note[Quantity Target] The magic happens in ideas 50100. The workflow encourages generating 100+ ideas before organization. :::

bmad-forge-idea

Pressure-test an idea until it hardens, proves out, or dies cheaply. — An adversarial interrogator drives a half-formed idea one question at a time, bringing two characters to every branch, until what survives is something you can act on with conviction.

Use it when:

  • You hold an idea and want it stress-tested before you invest in it
  • You want an honest read on whether to kill it
  • You need a thinking partner that pushes back instead of agreeing

How it works:

  1. Establishes the goal up front and steers the questioning to match it
  2. Works one question at a time in dependency order, putting a recommended answer on the table to push against
  3. Brings two voices to every branch — one from your installed roster, one conjured by the topic
  4. Challenges fuzzy terms and tests claims against an existing project's material
  5. Lands as Hardened, Killed, or Clearer, with a self-contained report you can keep

Input: The idea, in any domain — a feature, a business model, a research hypothesis, a life decision

Output: A forged-idea.md distillate when an idea hardens (optional), plus a forge-report.html keepsake every run

bmad-party-mode

Orchestrate multi-agent group discussions. — Loads all installed BMad agents and facilitates a natural conversation where each agent contributes from their unique expertise and personality.

Use it when:

  • You need multiple expert perspectives on a decision
  • You want agents to challenge each other's assumptions
  • You're exploring a complex topic that spans multiple domains

How it works:

  1. Loads the agent manifest with all installed agent personalities
  2. Analyzes your topic to select 23 most relevant agents
  3. Agents take turns contributing, with natural cross-talk and disagreements
  4. Rotates agent participation to ensure diverse perspectives over time
  5. Exit with goodbye, end party, or quit

Input: Discussion topic or question, along with specification of personas you would like to participate (optional)

Output: Real-time multi-agent conversation with maintained agent personalities