Operating Packs
Operating packs let you activate a named bundle of behavior for one BMO session without rewriting the project config. A pack can bring together skills, hooks, policy rules, choreography, and an optional prompt preamble into a repeatable operating mode.
Use packs when a task has a recognizable posture: review this PR cautiously, run an SRE investigation, apply a team policy bundle, or turn on a workspace-sensing stack for one session.
Maturity: Advanced operator surface. Packs are useful once you have repeatable task postures; they are session overlays, not persistent project configuration.
Do not use it when
Section titled “Do not use it when”- You only need to change a durable project default; edit config instead.
- You need multiple behavior bundles active at once; one pack is active per session.
- You cannot review the pack preview safely before activation.
What changes when a pack is active
Section titled “What changes when a pack is active”An active pack overlays the base configuration for the current session. Clearing the pack restores base behavior.
| Surface | What the pack can affect |
|---|---|
| Skills | Session-active skills by name |
| Hooks | Runloop and lifecycle hooks |
| Rules | Policy, task, and skill rules |
| Choreography | The preset used to shape run behavior |
| Prompt preamble | Optional instructions prepended for that session |
One pack is active at a time. Activating a second pack replaces the first. The active pack reference is persisted with the session so it can be restored after restart when the pack file still resolves.
Enable packs
Section titled “Enable packs”options.operating_packs = truePut pack manifests under packs/ in the working directory. A pack can be a pack.toml inside a subdirectory or another TOML manifest discovered by the pack picker.
Use packs in the TUI
Section titled “Use packs in the TUI”Open /pack or the Commands modal, choose an operating pack, inspect the preview, then confirm activation. The preview is the safety step: it shows the skills, hooks, rules, choreography, and preamble before BMO changes the session overlay.
Use the clear action in the same picker to return to the base config.
For a read-only CLI posture check, run bmo config show-operating-mode. It
shows the effective feature gate, inactive/disabled posture, configured preset
IDs, and local discovery counts without printing hook commands, preamble text,
raw policies, or secrets.
Use packs from tools and automation
Section titled “Use packs from tools and automation”The agent can inspect and mutate the active pack with:
| Tool | Purpose |
|---|---|
get_operating_mode | Read the active operating pack posture snapshot |
session_set_pack | Activate a pack for a session |
session_clear_pack | Clear the active pack |
For one-shot runs, pass --operating-pack <pack> to bmo run or bmo eval run so the session uses the requested pack from creation.
Eval JSON reports include the operating_pack value so A/B runs can be compared
without inferring the posture only from process arguments.
Safety and limits
Section titled “Safety and limits”Packs are session-scoped. They do not edit bmo.toml, and a failed activation leaves the current session state unchanged.
Before activation, BMO validates the pack. Error-level diagnostics block activation. Warnings are shown but do not block.
Related
Section titled “Related”- Operating mode parity documents HTTP and MCP parity for active pack state.
- Agent Skills explains the skill references packs can activate.
- Choreography explains the run-shaping presets packs can apply.
- Configuration documents the canonical config keys.