Glossary
Every term used in the BMAD+ documentation, in plain words: host, spine, pack, skill, intake, swarm, seed, checkpoint, gate, receipt, recipe and the status words the tools print, grouped by theme.
On this page
- Architecture
- Files and lifecycle
- Intake and swarms
- Orchestration
- Review and acceptance
- Memory and specialist packs
- Status words the tools print
The tables are grouped by theme rather than alphabetically, so that related words sit together. Names of agents, commands, flags, files and status words printed by the tools (such as needs-approval) stay in English in every language, because that is what you will see on screen. The right-hand column points to the page that explains the term in context.
Architecture#
Architecture terms| Term | Meaning | Read more |
|---|
| host | The AI coding tool that reads the instructions and does the work with its own model and permissions: Claude Code, Cursor, Codex CLI and others. | How BMAD+ works |
|---|
| host-managed | The execution contract of BMAD+: the host supplies the model, the permissions and any sub-agents; BMAD+ calls no model and runs nothing in the background. | How BMAD+ works |
|---|
| spine | AGENTS.md, the single generated instruction file that every tool reads: roster, skills, memory rules and registry facts. | How BMAD+ works |
|---|
| adapter | A short generated file in the format one tool expects (CLAUDE.md, GEMINI.md, a Cursor rule, ...) that points to the spine. | Adapters |
|---|
| pack | A group of agents, skills and workflows installed together. There are ten; Core is required. | All the packs |
|---|
| agent | A named persona you address in the chat ("Forge, ..."). 48 across the packs, 15 of them installer entry points. | The agent roster |
|---|
| role | A mode inside an agent, such as Analyst or Product Manager for Atlas. Switching is requested or automatic and is always announced. | How roles activate |
|---|
| persona | The named identity of an agent, with its name, role and description, as declared in the registry. | Registry and skills |
|---|
| skill | A folder with a SKILL.md that the host loads when needed: a procedure such as autopilot, intake or swarm. Every agent is also a skill. | Registry and skills |
|---|
| workflow | A step-by-step Markdown procedure in a pack, executed by your assistant. Dev Studio has 38 and Shield 11. | Dev Studio |
|---|
| registry | registry.yaml, the single source of truth in the source repository from which packs, rosters, counts and adapters are generated. | Registry and skills |
|---|
| CLI | The bmad-plus command-line tool: deterministic bookkeeping on local files. It calls no model and needs Node.js 20 or newer. | Command-line reference |
|---|
| chat instruction | A sentence for your assistant, such as bmad-help, autopilot or parallel. Not a terminal command. | How BMAD+ works |
|---|
Files and lifecycle#
File and lifecycle terms| Term | Meaning | Read more |
|---|
| manifest | _bmad/.bmad-plus-install.json: version, packs, tools and the SHA-256 of every installed file. | Trust and ownership |
|---|
| ownership inventory | The fileInventory of the manifest. A file is BMAD+’s own while it matches its hash; once edited it is yours. Its status is complete, incomplete, legacy or invalid. | Trust and ownership |
|---|
| receipt | The record of an applied update in .bmad/updates/<id>/receipt.json, with backups, used by update --restore. | Install, update, uninstall |
|---|
| update policy | _bmad/update-policy.json: off, notify (default) or auto with an explicit version range, plus channel and prerelease settings. | Using BMAD+ in a team |
|---|
| checkpoint | A stop in an autopilot run, set per stage (discovery, architecture, story, delivery) to require_approval, notify_only or auto. | Nexus |
|---|
| execution mode | manual (you call each agent), autopilot (Nexus manages the pipeline) or hybrid (autopilot with frequent checkpoints). | Reference: config.yaml |
|---|
| deliverable | A file an agent produces, usually under _bmad-output/: a brief, a PRD, an architecture, stories, a review, a report. | Your first hour |
|---|
| prompts-only mode | How the SEO pack works without a usable Python environment: the agent follows its prompts, marks unverified categories and computes no overall score. | The SEO pack |
|---|
Intake and swarms#
Intake and swarm terms| Term | Meaning | Read more |
|---|
| intake | The list of questions a pack needs answered before it acts, defined in an intake.yaml and driven by bmad-plus intake. | Intake |
|---|
| must-have | A question the pack cannot start without: it must be answered or marked unknown with its risk. It can carry no default. | Intake |
|---|
| answered, defaulted, unknown | The three statuses of an intake answer: you said it; you let the proposed default stand; you do not know (the risk is copied). | Intake |
|---|
| brief | Two meanings. An intake brief is the Markdown the CLI renders from the answers, the contract for the pack’s next steps. A swarm brief is the file one sub-agent reads as its whole instruction. | Intake |
|---|
| swarm | Many sub-agents doing the same kind of work once each, driven by bmad-plus swarm: a panel, a jury or a fanout. | Swarms |
|---|
| sub-agent | A worker session launched by the host, one per brief. BMAD+ never starts it; the moderator does, through the host. | Swarms |
|---|
| panel, jury, fanout | The three kinds of swarm: units dealt from a profile; units listed with one lens each; units supplied with disjoint write scopes. | Swarms |
|---|
| unit, card | A unit is one member of a swarm. Its card is its data (segment, age, objection, lens, scope), dealt or listed at init and frozen for the run. | Swarms |
|---|
| profile, definition, template, context | The four inputs of a swarm: the distribution of the panel; the JSON that declares kind, answer form and tally; the brief template; and the text the units read (such as a pitch), included verbatim. | Swarms |
|---|
| seed | A number from 0 to 2147483647 that makes dealing reproducible: same profile, same --n, same seed, same cards. | Swarms |
|---|
| budget, wave | swarm.budget (26) is how many sub-agents a run may use before a human must say yes; swarm.wave (10) is how many launch together. | Swarms |
|---|
| approval | The human yes that allows a run over budget. Recorded as --approved; the assistant must not pass it on its own. | Swarms |
|---|
| disclosure | The sentence that opens every tally, such as "Simulated units are not people". Reported once, before any figure. | Swarms |
|---|
| tally | tally.json and tally.md, computed over valid answers only, with skipped units named and the denominator shown. | Swarms |
|---|
| valid answer | A well-formed answer file: right id, all required fields, no undeclared field, types and bounds respected. Valid means well-formed, not true. | Swarms |
|---|
Orchestration#
Nexus terms| Term | Meaning | Read more |
|---|
| autopilot | The Nexus mode that runs Discovery, Build and Ship with checkpoints. Started by saying autopilot in the chat. | Nexus |
|---|
| Nexus run | A durable task graph and its attempts stored under .bmad-plus/nexus/runs/, created from a plan. | Nexus |
|---|
| plan | The JSON file you write for nexus create: tasks with objective, scope, artifacts, resources, checks and limits. | Nexus |
|---|
| task, attempt | A task is one node of the plan. An attempt is one try at it, bound to an identity (host session or supervised process). | Nexus |
|---|
| write scope | The files or folders a task may write. Scopes are exclusive and disjoint across tasks. | Nexus |
|---|
| resource | A protected input of a task (instructions, a verifier) that Nexus hashes and that must lie outside every write scope. | Nexus |
|---|
| execution, verification, acceptance | The three separate outcomes of a task: someone did the work; independent checks passed; the current workspace was accepted. Each can be pending, passed, failed or ambiguous without implying the next. | Nexus |
|---|
| reconcile | Close an uncertain attempt with an operator observation (owner stopped, retry safe or not). Required before a retry. | Nexus |
|---|
| process backend, supervisor | The optional way to run a task as a local command or a Codex CLI call. The supervisor is the foreground process that launched it and the only one that may signal its child. | Nexus |
|---|
Review and acceptance#
Review and acceptance terms| Term | Meaning | Read more |
|---|
| review scope | The sealed, hashed list of files a review must cover, with a named reason for each file left out. Written by review scope. | Review and acceptance |
|---|
| finding, anchor | A finding is a problem reported with the code it quotes. Anchoring locates that quote in the file (located, ambiguous or unlocated); a line number from a model is never trusted. | Review and acceptance |
|---|
| coverage | coverage.json: for every selected file, completed, failed or waived with a reason. The verdict derives from it. | Review and acceptance |
|---|
| gate | A command whose exit code is a verdict: review gate (0 clean, 1 findings, 2 incomplete), uat gate (0 passed, 1 failed, 2 awaiting, 3 stale), assurance verify. | Review and acceptance |
|---|
| effort | --effort low|medium|high: the number of review passes (1, 2 or 3) and whether each finding is challenged by a refutation step (not at low). Whether the reviewer plans the read first depends on the size of the change, not on the effort. | Review and acceptance |
|---|
| review rule | A Markdown prompt bound to path patterns; eight ship with BMAD+, Shield adds six compliance rules and a project adds its own in _bmad/review-rules.yaml. | Review and acceptance |
|---|
| recipe (recette) | A self-contained page that a person plays step by step to confirm a delivery on screen. The command is bmad-plus uat (alias recette). | Review and acceptance |
|---|
| witness | The thing a recipe relies on (a record, a file, a state), declared with the read-only query that proves its state. | Review and acceptance |
|---|
| run, triage | A run is one tester’s answers as JSON. Triage classifies each failure as product, recipe, data or undecided, with a decision. | Review and acceptance |
|---|
| human-observed | The label on acceptance evidence: a person saw it. The gate establishes that the run is complete, current and triaged, not that the tester looked in the right place. | Review and acceptance |
|---|
Memory and specialist packs#
Memory and pack terms| Term | Meaning | Read more |
|---|
| brain | A folder of shared memory outside one project: the global brain ~/.bmad-plus/brain/, a portfolio _brain/, or Claude’s memory folder. A project links to it; it is never copied. | Memory |
|---|
| handoff | A dated note in .agents/memory/sessions/ summarising what was done, decided and left, so that a cold session can resume. | Memory |
|---|
| guardrails G1 to G4 | Four behavioural rules in every agent’s instructions: think before coding, simplicity first, surgical changes, goal-driven execution. | Memory |
|---|
| Atelier, design read, dials | Atelier is the design agent. The design read is its intake. The dials (variance, motion, density, 1 to 10) tune the design; one left open is inferred from the surface and recorded as inferred. | The Design pack |
|---|
| lawful-basis gate | The OSINT rule that a named-person operation needs a recorded purpose, legal basis, retention and erasure path first. Without them the agent declines. | Trust and ownership |
|---|
| confidence grade | Shadow’s rating of a fact: A three or more sources, B two, C one, D unverified. | The OSINT pack |
|---|
| assurance case, ledger | Shield’s evidence tooling: claims, each backed by a check that ran; a hash-chained ledger runs.jsonl records the runs. A claim is supported or unsupported; passed, failed, stale and missing are the statuses of a check. | The Shield pack |
|---|
| controls | Compliance references written FRAMEWORK:ID, such as ISO27001:A.8.5 or GDPR:Art.32. An unknown or mistyped control is refused. | The Shield pack |
|---|
Status words the tools print#
Status words and their meaning| Word | Printed by | Meaning |
|---|
ready / not ready | intake plan | Every must-have is answered or unknown with its risk / a must-have is still open (exit 2). |
|---|
needs-approval | swarm init | The run is larger than the budget and has not been approved (exit 2); no brief was written. |
|---|
missing / invalid | swarm check | No answer file for a unit / an answer file that fails validation, with the reasons. |
|---|
incomplete / findings / clean | review gate | Evidence missing or review stopped (2) / open findings in a covered scope (1) / none in a covered scope (0). |
|---|
passed / failed / awaiting / stale | uat gate | Finished, current, triaged run (0) / failed (1) / no finished run (2) / the run answered another revision (3). |
|---|
not started / running / completed | nexus summary | The execution state of a task; verification and acceptance are shown separately as pending, passed, failed or accepted. |
|---|
unknown / off / notify / auto | update-check, update-policy | Latest version not established (offline, stale) / lookups stopped / report only / apply within an explicit range. |
|---|
ok / warning / error | doctor | Healthy / a modified or unowned file, reported / a required file missing or unreadable (exit 1). |
|---|