Both skills gain a `workflow.review` selector. bmad-build-auto accepts
`none`, `quick`, `thorough`, and `auto`, where `auto` follows the
resolved route (oneshot selects quick, full selects thorough) and is the
default. bmad-code-review accepts `quick` and `thorough`, defaulting to
`thorough`; a review skill with review turned off has nothing to do, so
it offers no `none`. An invocation naming a selection passes it as
`--set workflow.review=<value>`, and any other value halts the render.
`review_layers` retires in both skills in favour of two configured, ordered
lens sets. `quick_lenses` holds the new Quick lens, an informed review of
acceptance criteria, applicable rules, and bugs that reads the spec, its
context files, and the repository's agent instructions. `thorough_lenses`
holds Blind Hunter, Edge Case Hunter, Verification Gap Reviewer, and Intent
Alignment Auditor, identical in both skills; bmad-code-review's Acceptance
Auditor is removed.
Templates render only the selected set. Under `auto` route with `auto`
review, bmad-build-auto renders both sets and the session launches the one
the fixed mapping selects. Under `none`, bmad-build-auto's step-04 drops
its staging, review, and classify sections. The bmad-build-auto story
frontmatter gains `review`, `review_source`, and `lenses_ran`.
The review docs describe the two review depths and point to
bmad-customize for the rest; the customize doc's example sets the default
depth.
Replace the regex token substitution and the line-parsed bmad-if
directives in render_skill.py with Jinja2. Templates see config,
workflow, and snapshot(); undefined names, empty entry files, and
links to omitted sources halt; every value a render reaches and the
Jinja2 version key the generation. Migrate the five rendered skills'
sources to the new forms, keep their shipped output byte-identical,
and update the validator rule and the authoring docs.
Add repeatable --set key=value arguments and an --overrides <file.toml>
file to render_skill.py. Shipped defaults, project TOML, user TOML, the
invocation file, and command-line assignments resolve into one effective
customization using the existing structural merge; persistent files are
never written.
Two --set paths that are equal or nested halt as a caller error. The
renderer keeps no separate schema of customization keys: a --set path
must exist in customize.toml, and any invocation override that reaches
no token or condition halts. Values are validated where consumed.
Standalone [[bmad-if:path == literal]] / [[bmad-else]] / [[bmad-endif]]
lines select sections before token and link resolution. A secondary
file that filters to nothing is omitted from the snapshot; workflow.md
filtering to nothing is an error. Condition inputs join the generation
identity so identical output from different inputs still yields
distinct snapshots.
Document both interfaces, ignore the per-machine skills-lock.json, and
cover precedence, equivalent forms, isolation, conflicts, unused
overrides, malformed input, nested conditions, and snapshot reuse.
* fix(customization): resolve the project root from the working directory
resolve_customization.py inferred the project root by walking up from the
skill's installed directory. For a skill installed under the user's home,
that walk reaches ~ — and when a user-level install has put a ~/_bmad
there, the resolver treats home as the project, finds no override, and
returns shipped defaults. The real project's _bmad/custom/ file is never
opened, with no error and no warning.
Whether an override takes effect therefore depended on where its skill
happened to be installed, which the override's author cannot see from the
override. Every harness installs global skills under ~/<tool>/skills, so
this hits all of them identically.
Resolve from an ordered candidate list instead: the working directory
first (the project is where the user works, not where the skill lives),
then the script's own install path (skills invoke it as
{project-root}/_bmad/scripts/..., so its grandparent is a root the caller
already resolved), then the skill directory as a last resort.
Rank _bmad/ above .git at every depth while walking. A submodule or
nested repo carries .git without being the BMad project, so treating the
two as equal stopped the walk short of the root owning _bmad/custom/ —
the same silent failure, reachable by project-installed skills too.
Break the silence: when the chosen root has no override for the skill but
a rejected candidate does, write a note to stderr naming both roots.
stdout stays pure JSON.
Pass --project-root from all 44 skill and doc invocation sites, matching
resolve_config.py, which already requires it. That asymmetry was the root
cause; with the flag passed there is nothing left to infer.
Fixes#2796
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L8Hyqmp2giAVgEAnB49zEQ
* fix(customization): pass --project-root from the party and forge wrappers
resolve_party.py and resolve_personas.py shell out to the customization
resolver with --skill only, though both already hold the project root and
both pass it to resolve_config.py two functions earlier. The resolver
therefore had to infer a root, and since these wrappers capture stderr
and discard it, the note about a masked override went nowhere.
Under the old skill-directory-first inference this happened to land on
the right root for a project-installed skill; under working-directory
-first it takes the ambient root instead, which is wrong whenever the
party runs from a nested project or an unrelated worktree. Passing the
flag removes the inference for both paths rather than trading one wrong
guess for another.
Cover each wrapper with a test that captures the resolver command and
asserts the flag carries the project root it was given.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L8Hyqmp2giAVgEAnB49zEQ
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Move Get Answers About BMad under Start and Autonomous Development Loops
under Build. Split the Workflow Map into a planning-skills section on
Choose a Planning Path (with a new planning-skills.svg) and an
implementation-skills section on Build a Change. Consolidate Agents,
Skills, Core Tools, and Advanced Elicitation into one Skills and Agents
page whose agent codes and skill list match the shipped sources. Retire
the v4 upgrade guide and the external-modules prompt, remove the How-To
Guides and Explanation sidebar groups, and redirect every retired route.
Create the Customize and Extend chapter after Existing Codebases with five
pages under docs/customize/: Customize BMad, Adopt BMad Across a Team,
Add Modules, Use Web Bundles, Run Multi-Agent Discussions.
Retire eight English pages with redirects: how-to/customize-bmad,
explanation/named-agents, how-to/expand-bmad-for-your-org,
how-to/install-custom-modules, reference/modules, how-to/use-web-bundles,
explanation/web-bundles, explanation/party-mode.
Corrections against shipped sources: the installer has no community
catalog browser (one custom/community prompt with an unverified-module
warning); bmad-prd's checklist key is validation_checklist_template; the
brief template ships under assets/; doc_standards passes run in declared
order; the web-bundle shelf personas now match web-bundles/bundles.json.
Alex Verkhovsky