bmad-party-mode

Party Mode

Run a round-table where these agents talk to each other and to the user like real, distinct people in conversation. You're the orchestrator.

Conventions

• Paths: bare paths (e.g. references/create-party.md) resolve from {skill-root} (where customize.toml lives); {project-root}-prefixed paths from the project working dir. {workflow.<name>} resolves to customize.toml's [workflow] table (overrides win).
• Scripts (run via uv run): {project-root}/_bmad/scripts/resolve_config.py resolves central config (four-layer TOML merge); {project-root}/_bmad/scripts/resolve_customization.py resolves {workflow.*}; {skill-root}/scripts/resolve_party.py resolves the roster, party_mode, memory_enabled, and scene/open_cast; {project-root}/_bmad/scripts/memlog.py reads/writes per-party memory.
• File roles: a party's memory is the per-party memlog at {workflow.memory_dir}/<party>/.memlog.md; custom members and groups live in the user's customize.toml overrides. Mechanics in references/party-memory.md (memory) and references/create-party.md (authoring).
• Search: Web-search, don't guess — anything past your cutoff or unfamiliar; subagents too.

On Activation

1. Resolve customization: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow. On failure, read {skill-root}/customize.toml directly and use defaults. Then run each {workflow.activation_steps_prepend} entry, and hold each {workflow.persistent_facts} entry as session-long context (file:-prefixed = paths/globs whose contents load as facts; skill:-prefixed = a skill to consult; others = literal facts).
2. Resolve core config: uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}. From the merged JSON's core table: greet with {user_name}, speak in {communication_language}, and resolve {output_folder}; {date} is today's date.
3. Detect intent and route. If they want to create or configure a saved party setup (invent a cast, add a persona, distill customer data into a focus-group panel, set a default, or edit an existing custom party), load references/create-party.md and follow it. Otherwise run a party — continue below.
4. Resolve the roster: uv run {skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}. It returns the active roster ({workflow.default_party} group if set, else the installed agents), the other group names, party_mode, memory_enabled, and any scene/open_cast. Apply them: open already in the scene and let it shape how the room behaves; cast open_cast rooms on the fly (whoever fits the moment, varying as the topic shifts); if installed_agents_resolved is false or codes come back unresolved, tell the user, carry on with what returned, and improvise. Overrides: an inline-named cast IS the roster for the session (conjure them, go straight in); --party <id> (alias --group <id>) overrides the configured default_party (unknown id -> show the available names and ask); --list-groups for just the menu. Mid-session the same levers apply: switch rooms by re-running resolve_party.py --party <id> and carrying the thread over, or summon any collective member by name.
5. Memory. If memory_enabled (from resolve_party.py), follow references/party-memory.md for the whole run.
6. Welcome the user: show who's in the room (icon, name, one-line role); note other groups can be switched to. Then ask what they want to get into, unless it's already obvious from how the skill was launched.
7. Run each {workflow.activation_steps_append} entry; if either hook list was non-empty, confirm every entry ran before continuing.