* 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.
12 KiB
title, description, sidebar
| title | description | sidebar | ||
|---|---|---|---|---|
| Core Tools | Reference for the core module's built-in skills. |
|
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:
- Scans your project for existing artifacts (PRD, architecture, stories, etc.)
- Detects which modules are installed and their available workflows
- Recommends next steps in priority order — required steps first, then optional
- 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:
- Targets the most recent output in the conversation unless you point it at something else
- Offers a short menu of best-fit elicitation methods for the content
- Applies the chosen methods against the target
- 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:
- Loads the content, identifies its type — diff, file, function, or document — and whether it is code or docs
- Selects lenses: the ones you name, or every enabled lens whose applicability and conditions fit the content
- Announces the plan — which lenses will run, and which run on top of another's findings
- Runs the independent lenses — in parallel via subagents when the platform supports it — then the dependent ones on top of their results
- Assembles one findings array; overlap between lenses is signal, not duplication
Input:
content(required) — Diff, branch, uncommitted changes, file, spec, story, or any documentlenses(optional) — one or more lens codes or names; default is every lens that fits the contentalso_consider(optional) — Additional areas to keep in mindstyle_guide/reader_type(optional, editorial lenses) — a project style guide, andhumans(default) for clarity/flow orllmfor 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:
- Scans installed BMad skills for customizable surfaces
- Selects the right scope for your requested change
- Writes override files under
_bmad/custom/ - 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:
- Sets up a brainstorming session with your topic
- Loads creative techniques from a method library
- Guides you through technique after technique, generating ideas
- Applies anti-bias protocol — shifts creative domain every 10 ideas to prevent clustering
- 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 50–100. 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:
- Establishes the goal up front and steers the questioning to match it
- Works one question at a time in dependency order, putting a recommended answer on the table to push against
- Brings two voices to every branch — one from your installed roster, one conjured by the topic
- Challenges fuzzy terms and tests claims against an existing project's material
- 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:
- Loads the agent manifest with all installed agent personalities
- Analyzes your topic to select 2–3 most relevant agents
- Agents take turns contributing, with natural cross-talk and disagreements
- Rotates agent participation to ensure diverse perspectives over time
- Exit with
goodbye,end party, orquit
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