PluginBench
Skill
Pass
Audit score 90

bmad-customize

bmad-code-org/bmad-method

Author and update customization overrides for BMad agent and workflow skills.

What is bmad-customize?

Translates user intent into TOML override files under `_bmad/custom/` to customize installed BMad skills' agent behavior and workflows. Use this when you need to change agent persona, communication style, facts, workflow steps, templates, or other exposed configuration without modifying the skill itself.

  • Discovers customizable BMad skills in your project and lists what can be overridden
  • Reads target skill `customize.toml` to determine available agent and workflow configuration fields
  • Composes sparse TOML overrides that merge correctly with base and team configs using proper semantics (scalars override, arrays append, keyed tables merge by ID)
  • Handles template swaps by copying default templates to custom locations and updating override paths
  • Verifies overrides using the resolver script and shows merged output to confirm changes took effect
  • Distinguishes between team overrides (committed, policy-driven) and user overrides (gitignored, personal)

How to install bmad-customize

npx skills add https://github.com/bmad-code-org/bmad-method --skill bmad-customize
Prerequisites
  • BMad must be set up in your project (`_bmad/` directory present)
  • Target skill must have a `customize.toml` file (not all skills are customizable)
  • Optional: `_bmad/scripts/resolve_customization.py` for verification (falls back to manual merge if missing)
Claude Code
Cursor
Windsurf
Cline

How to use bmad-customize

  1. 1.Invoke the skill with a target skill name and desired change, or leave it open-ended to explore
  2. 2.If exploring, run the discovery script to list customizable skills and their current overrides
  3. 3.Read the target skill's `customize.toml` to see available fields and merge semantics
  4. 4.Compose the override in TOML, translating your intent to the exposed configuration fields
  5. 5.Choose team (committed) or user (gitignored) placement based on whether the change is policy or personal
  6. 6.Review the full TOML diff before confirming
  7. 7.Run the resolver to verify the override merged correctly and show the final resolved config
  8. 8.Commit team overrides to version control; user overrides are automatically gitignored

Use cases

Good for
  • Customize an agent's persona, role, communication style, or persistent facts across all workflows it runs
  • Override a specific workflow's activation steps, output path, or template without touching the skill code
  • Swap a workflow template with a custom version and track it in version control
  • Add org-wide compliance facts or principles to an agent that apply to every workflow it dispatches
  • Review and iterate on existing team or user customizations for a skill
Who it's for
  • BMad method users managing agent and workflow customization
  • Teams establishing org-wide agent policies and conventions
  • Individual contributors personalizing agent behavior without committing changes
  • Developers integrating BMad skills into projects and needing configuration without forking

bmad-customize FAQ

What's the difference between team and user overrides?

Team overrides (`{skill-name}.toml`) are committed to version control and apply to everyone; use them for org policies, compliance, and conventions. User overrides (`{skill-name}.user.toml`) are gitignored and personal; use them for your own tone, private facts, or shortcuts.

Can I override step logic or change the order of workflow steps?

Not directly—`customize.toml` only exposes specific fields. Use `activation_steps_prepend` or `activation_steps_append` to add steps before or after the workflow, or use `bmad-builder` to create a custom skill with different step ordering.

What happens if I override a scalar field like `icon` or `role`?

Scalars override completely: your value replaces the base value. Arrays like `persistent_facts` append instead—your entries are added after the base entries.

How do I swap a workflow template with my own?

The skill will copy the default template to `_bmad/custom/{skill-name}-{purpose}-template.md`, update the override to point to it, and offer to help you edit it. The override then uses your custom template.

What if the resolver script is missing or fails?

The skill falls back to manual merge: it reads the base `customize.toml`, any team override, and any user override, then applies the merge rules (scalars override, arrays append, keyed tables merge by key) and shows you the result.

Full instructions (SKILL.md)

Source of truth, from bmad-code-org/bmad-method.


name: bmad-customize description: Authors and updates customization overrides for installed BMad skills. Use when the user says 'customize bmad', 'override a skill', 'change agent behavior', or 'customize a workflow'

BMad Customize

Translate the user's intent into a correctly-placed TOML override file under {project-root}/_bmad/custom/ for a customizable agent or workflow skill. Discover, route, author, write, verify.

Scope v1: per-skill [agent] overrides (bmad-agent-<role>.toml / .user.toml) and per-skill [workflow] overrides (bmad-<workflow>.toml / .user.toml). Central config ({project-root}/_bmad/custom/config.toml) is out of scope — point users at the How to Customize BMad guide.

When the target's customize.toml doesn't expose what the user wants, say so plainly. Don't invent fields.

Preflight

  • No {project-root}/_bmad/ → BMad is not set up here. Offer to run the bmad skill's setup, installing bmad first if you do not have it (npx skills add bmad-code-org/BMAD-METHOD --skill bmad). Stop if the user declines.
  • {project-root}/_bmad/scripts/resolve_customization.py missing → continue, but Step 6 verify falls back to manual merge.
  • Both present → proceed.

Activation

Greet the user. If the user's invocation already names a target skill AND a specific change, jump to Step 3.

Step 1: Classify intent

  • Directed — specific skill + specific change → Step 3.
  • Exploratory — "what can I customize?" → Step 2.
  • Audit/iterate — wants to review or change something already customized → Step 2, lead with skills that have existing overrides; read the existing override in Step 3 before composing.
  • Cross-cutting — could live on multiple surfaces → Step 3, choose agent vs workflow explicitly with the user.

Step 2: Discovery

uv run {skill-root}/scripts/list_customizable_skills.py --project-root {project-root}

Use --extra-root <path> (repeatable) if the user has skills installed in additional locations.

Group the returned agents and workflows for the user; for each show name, description, whether has_team_override or has_user_override is true. Surface any errors[]. For audit/iterate intents, lead with already-overridden entries.

Empty list: show scanned_roots, ask whether skills live elsewhere (offer --extra-root); otherwise stop.

Step 3: Determine the right surface

Read the target's customize.toml. Top-level [agent] or [workflow] block defines the surface.

If a team or user override already exists, read it first and summarize what's already overridden before composing.

Cross-cutting intent — walk both surfaces with the user:

  • Every workflow a given agent runs → agent surface (e.g. bmad-agent-pm.toml with persistent_facts, principles).
  • One workflow only → workflow surface (e.g. bmad-prd.toml with activation_steps_prepend).
  • Several specific workflows → multiple workflow overrides in sequence, not an agent override.

Single-surface heuristic:

  • Workflow-level: template swap, output path, step-specific behavior, or a named scalar already exposed (*_template, on_complete). Surgical, reliable.
  • Agent-level: persona, communication style, org-wide facts, menu changes, behavior that should apply to every workflow the agent dispatches.

When ambiguous, present both with tradeoff, recommend one, let the user decide.

Intent outside the exposed surface (step logic, ordering, anything not in customize.toml): say so; offer activation_steps_prepend/append or persistent_facts as approximations, or recommend bmad-builder to create a custom skill.

Step 4: Compose the override

Translate plain-English into TOML against the target's customize.toml fields. If an existing override was read, frame the change as additive.

Merge semantics:

  • Scalars (icon, role, *_template, on_complete) — override wins.
  • Append arrays (persistent_facts, activation_steps_prepend/append, principles) — team/user entries append in order.
  • Keyed arrays of tables (menu items with code or id) — matching keys replace, new keys append.

Overrides are sparse: only the fields being changed. Never copy the whole customize.toml.

Template swap (*_template scalar): offer to copy the default template to {project-root}/_bmad/custom/{skill-name}-{purpose}-template.md, point the override at the new path, offer to help edit it.

Step 5: Team or user placement

Under {project-root}/_bmad/custom/:

  • {skill-name}.toml — team, committed. Policies, org conventions, compliance.
  • {skill-name}.user.toml — user, gitignored. Personal tone, private facts, shortcuts.

Default by character (policy → team, personal → user), confirm before writing.

Step 6: Show, confirm, write, verify

  1. Show the full TOML. If the file exists, show a diff. Never silently overwrite.

  2. Wait for explicit yes.

  3. Write. Create {project-root}/_bmad/custom/ if needed.

  4. Verify:

    uv run {project-root}/_bmad/scripts/resolve_customization.py --skill <install-path> --project-root {project-root} --key <agent-or-workflow>
    

    Show the merged output, point out the changed fields.

    Resolver missing or fails: read whichever layers exist — <install-path>/customize.toml (base), {project-root}/_bmad/custom/{skill-name}.toml (team), {project-root}/_bmad/custom/{skill-name}.user.toml (user) — apply base → team → user with the same merge rules (scalars override, tables deep-merge, code/id-keyed arrays merge by key, all other arrays append), describe how the changed fields resolve.

    Verify shows override didn't land (field unchanged, merge conflict, file not picked up): re-enter Step 4 with the verify output as context. Usually wrong field name, wrong merge mode (scalar vs array), or wrong scope.

  5. Summarize what changed, where the file lives, how to iterate. Remind the user to commit team overrides.

Complete when

  • Override file written (or user explicitly aborted).
  • User has seen resolver output (or manual fallback merge summary).
  • User has acknowledged the summary.

Otherwise the skill isn't done — finish or tell the user they're exiting incomplete.

When this skill can't help

  • Central config ({project-root}/_bmad/custom/config.toml) — see the How to Customize BMad guide.
  • Step logic, ordering, behavior not in customize.toml — open a feature request, or use bmad-builder to create a custom skill. Offer to help with either.
  • Skills without a customize.toml — not customizable.