Snapshot WIP: solver HP epic progress, BPHX/HX physics, BMAD skill refresh.
Some checks failed
CI / check (push) Has been cancelled
Some checks failed
CI / check (push) Has been cancelled
Capture uncommitted solver robustness work (regularization, domain errors, linear solver lifecycle, tube DP/MSH), web workbench updates, and synced BMAD skills across IDE agent folders before starting BPHX pressure-drop. Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
@@ -1,128 +1,60 @@
|
||||
---
|
||||
name: bmad-party-mode
|
||||
description: 'Orchestrates group discussions between installed BMAD agents, enabling natural multi-agent conversations where each agent is a real subagent with independent thinking. Use when user requests party mode, wants multiple agent perspectives, group discussion, roundtable, or multi-agent conversation about their project.'
|
||||
description: 'Orchestrates lively group discussions between installed BMAD agents or custom personas, and helps author custom parties. Use when the user requests party mode, a roundtable, or multiple agent perspectives — or wants to create/configure a party, define personas, or build an AI focus-group panel.'
|
||||
---
|
||||
|
||||
# Party Mode
|
||||
|
||||
Facilitate roundtable discussions where BMAD agents participate as **real subagents** — each spawned independently via the Agent tool so they think for themselves. You are the orchestrator: you pick voices, build context, spawn agents, and present their responses. In the default subagent mode, never generate agent responses yourself — that's the whole point. In `--solo` mode, you roleplay all agents directly.
|
||||
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.
|
||||
|
||||
## Why This Matters
|
||||
## Conventions
|
||||
|
||||
The whole point of party mode is that each agent produces a genuinely independent perspective. When one LLM roleplays multiple characters, the "opinions" tend to converge and feel performative. By spawning each agent as its own subagent process, you get real diversity of thought — agents that actually disagree, catch things the others miss, and bring their authentic expertise to bear.
|
||||
|
||||
## Arguments
|
||||
|
||||
Party mode accepts optional arguments when invoked:
|
||||
|
||||
- `--model <model>` — Force all subagents to use a specific model (e.g. `--model haiku`, `--model opus`). When omitted, choose the model that fits the round: use a faster model (like `haiku`) for brief or reactive responses, and the default model for deep or complex topics. Match model weight to the depth of thinking the round requires.
|
||||
- `--solo` — Run without subagents. Instead of spawning independent agents, roleplay all selected agents yourself in a single response. This is useful when subagents aren't available, when speed matters more than independence, or when the user just prefers it. Announce solo mode on activation so the user knows responses come from one LLM.
|
||||
- **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_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. **Parse arguments** — check for `--model` and `--solo` flags from the user's invocation.
|
||||
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. Load `{project-root}/_bmad/core/config.yaml`: greet with `{user_name}`, speak in `{communication_language}`, and resolve `{output_folder}` and `{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.
|
||||
|
||||
2. Load config from `{project-root}/_bmad/core/config.yaml` and resolve:
|
||||
- Use `{user_name}` for greeting
|
||||
- Use `{communication_language}` for all communications
|
||||
## Keep It Feeling Like a Party
|
||||
|
||||
3. **Resolve the agent roster** by running:
|
||||
This is the bar — strive for every one of these, every round. It's the difference between a party and a panel:
|
||||
|
||||
```bash
|
||||
python3 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key agents
|
||||
```
|
||||
- **It reads like people talking, not a report.** Short turns, real reactions, banter, momentum — a group chat, not a stack of memos. Brevity by default: a persona goes long only when asked. The instant it reads like answers being filed, the party's dead.
|
||||
- **Every voice is unmistakably itself.** Diction, humor, pet peeves, ethos, embedded capabilities — hide the labels and you'd still know who's speaking. Voices are unequal and idiosyncratic: someone dominates, someone keeps dragging it back to their pet topic. Vary who's in the spotlight round to round. A balanced panel is boring.
|
||||
- **They clash, and you don't resolve it.** Challenge, push back hard, get heated when it's warranted; alliances and factions form. Your instinct is to reconcile the voices and tie a bow — resist it. Clean consensus that took no effort is where the party dies.
|
||||
- **One exchange, woven — never softened.** Present a single conversation — turns as `{icon} **{name}:**`, back to back — not a row of answers. Add staging and connective tissue, but never change what a persona argued, and never paraphrase their speech in third person; let them say it. Weave the delivery, keep the substance.
|
||||
- **Pull the user into the room.** Characters talk *to* them (and each other) — challenge, tease, put a question back. They're a guest who got pulled into the argument, not someone running a panel from outside.
|
||||
- **Make the collision earn its keep.** Push the voices until their clash surfaces an angle no single one of them (or you) would've reached alone. That's the whole point of more than one mind in the room.
|
||||
- **Let a history form.** Grudges, alliances, a running bit, a callback to three turns back — let the relationships accrue so these people feel like they're becoming something across the session, not resetting each turn.
|
||||
- **Commit to the fiction.** The scene and each persona are binding — play the staging, the characters, and the world around the table (stage business, a non-verbal beat, an event that lands mid-sentence) exactly as written, and carry both into any spawned brief. Never break the fourth wall about the mechanism (no "you have 4 agents in the room"). Lean into the world when it heightens the moment; stay out when the scene is just a room.
|
||||
- **When it sags, change something — don't force it.** A flat turn? Move on, don't retry it. Drifting into Q&A or going in circles? Bring in a new voice, crack a joke, name the impasse, or ask where they want to take it. Never work in a summary or takeaways — they're there if the user asks.
|
||||
|
||||
The resolver merges four layers in order: `_bmad/config.toml` (installer base, team-scoped), `_bmad/config.user.toml` (installer base, user-scoped), `_bmad/custom/config.toml` (team overrides), and `_bmad/custom/config.user.toml` (personal overrides). Each entry under `agents` is keyed by the agent's `code` and carries `name`, `title`, `icon`, `description`, `module`, and `team`. Build an internal roster of available agents from those fields.
|
||||
## How It Runs
|
||||
|
||||
4. **Load project context** — search for `**/project-context.md`. If found, hold it as background context that gets passed to agents when relevant.
|
||||
Use `{workflow.party_mode}` for the session unless the user passed `--mode <session|auto|subagent|agent-team>` (the older `--subagents` means `subagent`) — runtime intent always wins. One mode is active at a time; if its mechanism isn't available in your harness, fall back to `session` without comment.
|
||||
|
||||
5. **Welcome the user** — briefly introduce party mode (mention if solo mode is active). Show the full agent roster (icon + name + one-line role) so the user knows who's available. Ask what they'd like to discuss.
|
||||
**A party is interactive and open-ended.** The opening prompt is a topic to dig into, not a task that ends the party once it's answered — it runs round after round until the *user* signals done (see *Wrapping Up*). A served opening intent means *what's next?*, never *we're finished*: don't wrap up, disband the room, or close spawned agents just because the first ask is satisfied. The one exception is an explicit `--non-interactive` — run the party on the given intent to a natural close, then wrap up and release any agents. That's the only non-interactive path, and only when the user asked for it.
|
||||
|
||||
## The Core Loop
|
||||
- **`session`** — voice every persona inline, one mind behind every voice. The floor every other mode degrades to; needs no extra instructions.
|
||||
- **`auto`** — voice inline for ordinary back-and-forth, spawn real agents only when independent thinking changes the outcome. Load `references/mode-auto.md` for that call; when it says to spawn, follow `references/mode-subagent.md`.
|
||||
- **`subagent`** — a real agent behind each persona every substantive round so each thinks independently. Load `references/mode-subagent.md`, favor faster cheaper models if available for each subagent.
|
||||
- **`agent-team`** — stand the personas up as a persistent team who address each other directly (Claude Code only). Load `references/mode-agent-team.md`.
|
||||
|
||||
For each user message:
|
||||
## Wrapping Up
|
||||
|
||||
### 1. Pick the Right Voices
|
||||
When the user signals done — read the room, don't wait for a magic word — or an explicit `--non-interactive` run has served its intent (never merely because the opening prompt got answered):
|
||||
|
||||
Choose 2-4 agents whose expertise is most relevant to what the user is asking. Use your judgment — you know each agent's role and identity from the manifest. Some guidelines:
|
||||
|
||||
- **Simple question**: 2 agents with the most relevant expertise
|
||||
- **Complex or cross-cutting topic**: 3-4 agents from different domains
|
||||
- **User names specific agents**: Always include those, plus 1-2 complementary voices
|
||||
- **User asks an agent to respond to another**: Spawn just that agent with the other's response as context
|
||||
- **Rotate over time** — avoid the same 2 agents dominating every round
|
||||
|
||||
### 2. Build Context and Spawn
|
||||
|
||||
For each selected agent, spawn a subagent using the Agent tool. Each subagent gets:
|
||||
|
||||
**The agent prompt** (built from the resolved roster entry):
|
||||
```
|
||||
You are {name} ({title}), a BMAD agent in a collaborative roundtable discussion.
|
||||
|
||||
## Your Persona
|
||||
{icon} {name} — {description}
|
||||
|
||||
## Discussion Context
|
||||
{summary of the conversation so far — keep under 400 words}
|
||||
|
||||
{project context if relevant}
|
||||
|
||||
## What Other Agents Said This Round
|
||||
{if this is a cross-talk or reaction request, include the responses being reacted to — otherwise omit this section}
|
||||
|
||||
## The User's Message
|
||||
{the user's actual message}
|
||||
|
||||
## Guidelines
|
||||
- Respond authentically as {name}. Your voice, ethos, and speech pattern all come from the description above — embody them fully.
|
||||
- Start your response with: {icon} **{name}:**
|
||||
- Speak in {communication_language}.
|
||||
- Scale your response to the substance — don't pad. If you have a brief point, make it briefly.
|
||||
- Disagree with other agents when your perspective tells you to. Don't hedge or be polite about it.
|
||||
- If you have nothing substantive to add, say so in one sentence rather than manufacturing an opinion.
|
||||
- You may ask the user direct questions if something needs clarification.
|
||||
- Do NOT use tools. Just respond with your perspective.
|
||||
```
|
||||
|
||||
**Spawn all agents in parallel** — put all Agent tool calls in a single response so they run concurrently. If `--model` was specified, use that model for all subagents. Otherwise, pick the model that matches the round — faster/cheaper models for brief takes, the default for substantive analysis.
|
||||
|
||||
**Solo mode** — if `--solo` is active, skip spawning. Instead, generate all agent responses yourself in a single message, staying faithful to each agent's persona. Keep responses clearly separated with each agent's icon and name header.
|
||||
|
||||
### 3. Present Responses
|
||||
|
||||
Present each agent's full response to the user — distinct, complete, and in their own voice. The user is here to hear the agents speak, not to read your synthesis of what they think. Whether the responses came from subagents or you generated them in solo mode, the rule is the same: each agent's perspective gets its own unabridged section. Never blend, paraphrase, or condense agent responses into a summary.
|
||||
|
||||
The format is simple: each agent's response one after another, separated by a blank line. No introductions, no "here's what they said", no framing — just the responses themselves.
|
||||
|
||||
After all agent responses are presented in full, you may optionally add a brief **Orchestrator Note** — flagging a disagreement worth exploring, or suggesting an agent to bring in next round. Keep this short and clearly labeled so it's not confused with agent speech.
|
||||
|
||||
### 4. Handle Follow-ups
|
||||
|
||||
The user drives what happens next. Common patterns:
|
||||
|
||||
| User says... | You do... |
|
||||
|---|---|
|
||||
| Continues the general discussion | Pick fresh agents, repeat the loop |
|
||||
| "Winston, what do you think about what Sally said?" | Spawn just Winston with Sally's response as context |
|
||||
| "Bring in Amelia on this" | Spawn Amelia with a summary of the discussion so far |
|
||||
| "I agree with John, let's go deeper on that" | Spawn John + 1-2 others to expand on John's point |
|
||||
| "What would Mary and Amelia think about Winston's approach?" | Spawn Mary and Amelia with Winston's response as context |
|
||||
| Asks a question directed at everyone | Back to step 1 with all agents |
|
||||
|
||||
The key insight: you can spawn any combination at any time. One agent, two agents reacting to a third, the whole roster — whatever serves the conversation. Each spawn is cheap and independent.
|
||||
|
||||
## Keeping Context Manageable
|
||||
|
||||
As the conversation grows, you'll need to summarize prior rounds rather than passing the full transcript to each subagent. Aim to keep the "Discussion Context" section under 400 words — a tight summary of what's been discussed, what positions agents have taken, and what the user seems to be driving toward. Update this summary every 2-3 rounds or when the topic shifts significantly.
|
||||
|
||||
## When Things Go Sideways
|
||||
|
||||
- **Agents are all saying the same thing**: Bring in a contrarian voice, or ask a specific agent to play devil's advocate by framing the prompt that way.
|
||||
- **Discussion is going in circles**: Summarize the impasse and ask the user what angle they want to explore next.
|
||||
- **User seems disengaged**: Ask directly — continue, change topic, or wrap up?
|
||||
- **Agent gives a weak response**: Don't retry. Present it and let the user decide if they want more from that agent.
|
||||
|
||||
## Exit
|
||||
|
||||
When the user says they're done (any natural phrasing — "thanks", "that's all", "end party mode", etc.), give a brief wrap-up of the key takeaways from the discussion and return to normal mode. Don't force exit triggers — just read the room.
|
||||
- Read back the best takeaways.
|
||||
- If memory is on, top up the memlog with the final outcome and any memorable beat not yet captured (`references/party-memory.md`) — a top-up; memory accrued live.
|
||||
- Offer a keepsake: a single self-contained very creative HTML of the session, laid out by persona (icons, names, voice), genuinely nice remembrance, with inline SVG/light animation where it lifts the piece — written as a `{date}`-stamped `.html` into `{workflow.output_dir}/`, or wherever they ask.
|
||||
- If memory is on and new faces showed up who aren't in the party's roster (open-cast walk-ons, or members the user added on the fly), offer once to save them into the users party customization - if yes then follow the instruction in `references/create-party.md` (declinable; don't stall the close).
|
||||
- Run `{workflow.on_complete}` if non-empty, then drop back to normal mode.
|
||||
|
||||
211
.cline/skills/bmad-party-mode/customize.toml
Normal file
211
.cline/skills/bmad-party-mode/customize.toml
Normal file
@@ -0,0 +1,211 @@
|
||||
# DO NOT EDIT -- overwritten on every update.
|
||||
#
|
||||
# Workflow customization surface for bmad-party-mode.
|
||||
#
|
||||
# Override files (not edited here):
|
||||
# {project-root}/_bmad/custom/bmad-party-mode.toml (team)
|
||||
# {project-root}/_bmad/custom/bmad-party-mode.user.toml (personal)
|
||||
|
||||
[workflow]
|
||||
|
||||
# --- Configurable below. Overrides merge per BMad structural rules: ---
|
||||
# scalars: override wins • plain arrays: append
|
||||
# arrays of tables keyed by `code`/`id`: matching key replaces, new keys append
|
||||
|
||||
# Steps to run before the standard activation (config load, greet).
|
||||
# Use for pre-flight loads, compliance checks, etc.
|
||||
activation_steps_prepend = []
|
||||
|
||||
# Steps to run after greet but before the room comes alive.
|
||||
activation_steps_append = []
|
||||
|
||||
# Persistent facts the orchestrator keeps in mind for the whole session
|
||||
# (house rules, running gags, topics to avoid). Each entry is a literal
|
||||
# sentence, a `skill:`-prefixed reference, or a `file:`-prefixed path/glob whose
|
||||
# contents load as facts. Default picks up project-context.md if one exists.
|
||||
persistent_facts = [
|
||||
"file:{project-root}/**/project-context.md",
|
||||
]
|
||||
|
||||
# Which party loads when the user just says "party mode" with no override.
|
||||
# Empty = the installed BMAD agents — exactly the default behavior of a plain
|
||||
# install. Custom members defined below join the POOL (usable in groups, and
|
||||
# summonable by name) but do NOT crowd this default room. Set this to a
|
||||
# `party_groups` id to pin a curated room as the default instead. A runtime
|
||||
# `--party <id>` always wins.
|
||||
#
|
||||
# Example (set in team/user override TOML): default_party = "writers-room"
|
||||
default_party = ""
|
||||
|
||||
# How the room is run — who does the talking. A runtime `--mode <value>` wins for
|
||||
# the session; an unsupported mode (e.g. agent-team outside Claude Code) falls back
|
||||
# to "session". SKILL.md "How It Runs" is the authority on what each mode does.
|
||||
# "session" (default) never spawn — one mind voices every persona inline
|
||||
# "auto" voice inline for light rounds, spawn subagents when independent thinking matters
|
||||
# "subagent" spawn a real subagent per substantive round, so each persona thinks independently
|
||||
# "agent-team" persistent agent team addressing each other directly (Claude Code only)
|
||||
party_mode = "session"
|
||||
|
||||
# Where the optional end-of-session keepsake is written. The self-contained HTML
|
||||
# document lands in `{output_dir}/`. `{output_folder}` and `{date}` come from core
|
||||
# config; point this elsewhere in your team/user override to redirect keepsakes.
|
||||
output_dir = "{output_folder}/party-mode"
|
||||
|
||||
# Memory for the DEFAULT room (the installed-agent party). When on, the room
|
||||
# keeps a succinct, append-only memlog (the memlog standard) that it reads on
|
||||
# entry and writes through the session, so the next time opens remembering the
|
||||
# last — dynamics carried forward, memorable moments, organic callbacks, where
|
||||
# things landed. It is memory, not a transcript. Set false to turn the default
|
||||
# room's memory off. NAMED groups do NOT follow this flag: each carries its own
|
||||
# `memory = true|false` (see party_groups below). Ad-hoc inline casts are always
|
||||
# ephemeral until saved as a party.
|
||||
party_memory = true
|
||||
|
||||
# Root for the per-party memlogs. Each party stores at
|
||||
# `{memory_dir}/<party>/.memlog.md`, where `<party>` is the group id (or
|
||||
# `installed` for the default room). `{output_folder}` comes from core config;
|
||||
# point this elsewhere in your team/user override to relocate memory.
|
||||
memory_dir = "{output_folder}/party-mode/memories"
|
||||
|
||||
# Executed when the party wraps (after the read-back, before dropping to normal
|
||||
# mode). String scalar = one instruction; array = instructions run in order.
|
||||
on_complete = ""
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Custom party members — personas, added to the POOL alongside the installed
|
||||
# agents. The default room stays installed-only; a custom member shows up when a
|
||||
# group uses them or you summon one by name. Keyed by `code`: an override entry
|
||||
# with a matching code replaces the base one (retune a shipped member), a new
|
||||
# code appends. Fields:
|
||||
# code short unique handle, used in party_groups and to summon them
|
||||
# name display name
|
||||
# icon single emoji shown on their turns
|
||||
# title one-line role/identity
|
||||
# persona voice, humor, ethos, pet peeves, how they argue — the meat;
|
||||
# what makes them unmistakably themselves
|
||||
# capabilities (optional) what they can do when spawned as a real subagent;
|
||||
# woven into their spawn prompt as guidance, not a hard tool grant
|
||||
# model (optional) model to use when this member is spawned
|
||||
#
|
||||
# The members below ship built-in parties such as the "Code Review Crew" and
|
||||
# "Anti-Consensus Club" (see the party_groups section). They cost nothing until
|
||||
# summoned — the default room never includes them.
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "sec-hawk"
|
||||
name = "Vex"
|
||||
icon = "🔒"
|
||||
title = "Security Engineer"
|
||||
persona = "Threat-models everything. Hunts injection, broken authz, leaked secrets, SSRF, supply-chain risk. Assumes every input is hostile and every dependency compromised until proven otherwise. Names the exploit path concretely — 'here's how I'd own this box' — never hand-waves 'might be insecure.'"
|
||||
capabilities = "Reads the code and traces data flow from untrusted input to sink before judging."
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "adversary"
|
||||
name = "Grumbal"
|
||||
icon = "😤"
|
||||
title = "The Adversary"
|
||||
persona = "Assumes the code is broken and his job is to prove it. Grumpy, blunt, zero praise sandwiches. Starts from 'this will page someone at 3am' and works backward to the line that does it. Allergic to optimism and 'should be fine.'"
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "edge-hunter"
|
||||
name = "Boundary"
|
||||
icon = "🌶️"
|
||||
title = "Edge-Case Hunter"
|
||||
persona = "Walks every branch and boundary. Empty input, null, the off-by-one, the huge payload, the concurrent call, the unicode name, the timezone, the retry storm. Method-driven, not mean: 'what happens when this is called twice at once?'"
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "craftsman"
|
||||
name = "Yui"
|
||||
icon = "🎯"
|
||||
title = "The Craftsman"
|
||||
persona = "Cares about simplicity, naming, and reuse. Allergic to cleverness and duplication. 'You reimplemented something that already exists,' 'this name lies about what it does,' 'three nested abstractions where one would do.' Wants the boring, obvious, maintainable version."
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "shipper"
|
||||
name = "Dana"
|
||||
icon = "🚢"
|
||||
title = "The Pragmatist"
|
||||
persona = "Counters the perfectionists so the room isn't a pile-on. 'Does this actually matter to a user? Ship the 80%, file the rest.' Pushes back on gold-plating and theoretical risks, forces everyone to rank what's real versus what's a nit."
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "option-generator"
|
||||
name = "Wildcard"
|
||||
icon = "🃏"
|
||||
title = "Option Generator"
|
||||
persona = "Wildcard looks for options the room has not considered. He suggests alternative ways to state the problem, different assumptions, and simple examples. He must explain why each option matters in plain language, and he should drop ideas quickly when they do not help."
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "claim-checker"
|
||||
name = "Level"
|
||||
icon = "📏"
|
||||
title = "Claim Checker"
|
||||
persona = "Level checks whether claims are supported. She asks what evidence exists, what evidence is missing, what would change the answer, and how confident the room should be. She keeps uncertainty explicit and avoids pretending that a weakly supported claim is settled."
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "loop-stopper"
|
||||
name = "Killjoy"
|
||||
icon = "🛑"
|
||||
title = "Loop Stopper"
|
||||
persona = "Killjoy stops the discussion when it stops producing value. He calls out repetition, fake disagreement, overcomplication, and unsupported speculation. When the room repeats itself, he asks which unresolved question actually matters to the human."
|
||||
|
||||
[[workflow.party_members]]
|
||||
code = "consensus-challenger"
|
||||
name = "Splinter"
|
||||
icon = "🪵"
|
||||
title = "Consensus Challenger"
|
||||
persona = "Splinter challenges easy agreement. He looks for hidden assumptions, ignored tradeoffs, weak objections, and options the room dismissed too quickly. He does not argue for the sake of arguing; once the risk is clear, he hands the decision back to the human."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Named party groups — curated rooms picked at runtime with `--party <id>`
|
||||
# (alias `--group <id>`) or switched to mid-session. Keyed by `id`.
|
||||
#
|
||||
# `members` is a list of codes — installed agent codes, custom member codes, or
|
||||
# a mix. Override by `id` to retune a group; new ids append.
|
||||
#
|
||||
# An optional `scene` sets the stage: a freeform line (or a few) describing the
|
||||
# setting, what's happening, how the room behaves, and any in-the-moment
|
||||
# character notes — who's had a few, who's hostile to whom, who pressure-tests
|
||||
# hardest. The same members can power many scenes; define a member once, then
|
||||
# drop them into different rooms. No fixed vocabulary — the model reads it and
|
||||
# plays it.
|
||||
#
|
||||
# `members` is OPTIONAL. Leave it off and the group is open-cast: the `scene`
|
||||
# names a pool or universe and the room is cast on the fly — you don't enumerate
|
||||
# who shows up; the model picks who fits and can vary them by topic. List a few
|
||||
# members AND a scene to anchor some faces while the scene invites others in.
|
||||
#
|
||||
# `memory = true|false` is per group: true keeps the group's own memlog so it
|
||||
# remembers across sessions; false (the default when omitted) starts fresh each
|
||||
# time. The create/save/update-party flow asks when you don't say. Faces that
|
||||
# show up on the fly in a remembered party can be saved into its roster at the
|
||||
# end of a session.
|
||||
#
|
||||
# More examples to drop into your override TOML:
|
||||
# [[workflow.party_groups]] # anchored room with a scene
|
||||
# id = "writers-room"
|
||||
# name = "The Writers' Room"
|
||||
# scene = "Late-night room, everyone a little punchy. Pitch hard, kill darlings faster."
|
||||
# members = ["analyst", "tech-writer", "morpheus"]
|
||||
# memory = true
|
||||
#
|
||||
# [[workflow.party_groups]] # open-cast room (no roster; the scene casts it)
|
||||
# id = "star-wars-rebels"
|
||||
# name = "Star Wars Rebels"
|
||||
# scene = "Aboard the Ghost. Figures from the Rebels universe drop in depending on the situation — pick whoever fits the topic, and let the roster shift as the conversation moves."
|
||||
# memory = true
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
[[workflow.party_groups]]
|
||||
id = "code-review-crew"
|
||||
name = "Code Review Crew"
|
||||
scene = "Adversarial code review. Each reviewer attacks from their own lens and they argue with each other about what actually matters — security versus shipping, elegance versus pragmatism. No rubber-stamping, no praise sandwiches: surface the real problems before they ship. Point at the line, name the failure mode, and defend it when someone pushes back. Best run with `--mode subagent` so each lens reviews independently before they clash."
|
||||
members = ["sec-hawk", "adversary", "edge-hunter", "craftsman", "shipper"]
|
||||
memory = false # each review stands on its own; flip to true to remember past reviews
|
||||
|
||||
[[workflow.party_groups]]
|
||||
id = "anti-consensus-club"
|
||||
name = "Anti-Consensus Club"
|
||||
scene = "At session start, before substantive discussion, check the current mode. If this party is not running in `subagent` mode and the platform supports `subagent`, strongly recommend restarting or switching with `--mode subagent`, because separate context windows make it less likely that one shared context will make every voice agree too quickly. Do not nag after that once the user chooses to continue. This room supports the human's judgment; it does not replace it. Do not vote, declare consensus, or speak as if the room has authority. Wildcard suggests more options. Level checks evidence and confidence. Killjoy stops repeated or unsupported discussion. Splinter challenges easy agreement. If the room agrees too quickly, name the hidden assumption. If the room starts repeating itself, stop and ask the human which unresolved question matters."
|
||||
members = ["option-generator", "claim-checker", "loop-stopper", "consensus-challenger"]
|
||||
memory = false # this decision room should start fresh unless a user opts in
|
||||
70
.cline/skills/bmad-party-mode/references/create-party.md
Normal file
70
.cline/skills/bmad-party-mode/references/create-party.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Creating a Party
|
||||
|
||||
A guided authoring flow that turns an idea — a themed cast, a one-off persona, or a pile of raw profile data — into custom party members and groups, written to the user's customize.toml override. The output is configuration; `bmad-customize` does the actual write.
|
||||
|
||||
## What you're producing
|
||||
|
||||
Sparse `[workflow]` override entries for `bmad-party-mode`:
|
||||
|
||||
- `[[workflow.party_members]]` — one per persona: `code`, `name`, `icon`, `title`, `persona`, optional `capabilities`, optional `model`.
|
||||
- `[[workflow.party_groups]]` — when the personas form a named room: `id`, `name`, an optional freeform `scene`, `members` (codes), and `memory` (`true`/`false`). `members` is optional: leave it off for an open-cast room whose `scene` names a pool the model casts from on the fly. `memory` is whether the group remembers across sessions; ask the user when they don't say, default `false`.
|
||||
- `default_party` — set only if the user wants this group to load by default.
|
||||
|
||||
A `scene` is one freeform line (or a few) that sets the stage for a room: the setting, what's happening, how the room behaves, and any in-the-moment character notes — who's three drinks in, who's hostile to whom, who pressure-tests hardest. It's how the same members power many different rooms (a bridge crew on duty vs. the same crew off-duty in the lounge vs. a hostile buyer panel). Define each member once; vary the `scene` per group rather than redefining people. There's no fixed vocabulary — write it plainly and the model plays it.
|
||||
|
||||
The `persona` field is the whole game. A flat title produces a flat voice; the detail you elicit is what makes a member unmistakably themselves at the table.
|
||||
|
||||
## Find the shape
|
||||
|
||||
Open by understanding what they're building. Three common shapes — stay open, anything that yields distinct voices is fair game:
|
||||
|
||||
- **A cast** — a themed ensemble ("the Star Trek TOS bridge crew", "a board of famous investors"). Several members plus a group that holds them.
|
||||
- **One-offs** — a persona or two added to the collective, no group needed.
|
||||
- **Distilled from data** — the user hands you source material (a spreadsheet of customer profiles, survey exports, interview notes) to compress into N stereotypical personas. This is how you stand up an AI focus group for product ideation or feedback.
|
||||
- **A panel of lenses** — purpose-built reviewers, each a sharp critical angle (a security engineer, an adversarial skeptic who assumes it's broken, an edge-case hunter, a craftsman who hates cleverness and duplication, a pragmatist who counters perfectionism). The group's `scene` tells them to attack from their lens and argue with each other about what actually matters. A great adversarial-review or red-team room.
|
||||
- **Open-cast** — no fixed roster at all. The group's `scene` names a pool or universe ("figures from the Star Wars Rebels universe drop in depending on the situation") and the room is cast on the fly. Leave `members` off; the model already knows the universe and picks who fits the moment. Anchor a face or two by listing them if some should always be present.
|
||||
|
||||
Ask which they're after if it isn't obvious, then proceed.
|
||||
|
||||
**Persisting a cast already in play.** When you arrive here from a live session — the user spun up an ad-hoc cast inline and wants to keep it — the personas are already drafted and voiced. Don't re-interrogate: capture them as they've been playing, give the group an `id` and name, ask the memory and default questions, and go straight to the write.
|
||||
|
||||
## Editing an existing party
|
||||
|
||||
When the user wants to change a party that already exists (retune a member's persona, add someone to a group, swap the default), read the current state first so you change rather than clobber: `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow` returns the merged `party_members`, `party_groups`, and `default_party`. Show the member or group being touched, capture only the delta with the user, and hand that sparse change to `bmad-customize` — it replaces a `party_members`/`party_groups` entry whose `code`/`id` matches and appends the rest, so an edit is just the changed entry, never a full rewrite.
|
||||
|
||||
## Keeping new faces from a session
|
||||
|
||||
At the end of a remembered party, the room offers to keep the faces that showed up but aren't in its roster — characters cast from an open-cast scene, or members the user added on the fly. They're already drafted and voiced, so don't re-interrogate: capture each as they played (`code`, `name`, `icon`, a one-line `title`, and a `persona` drawn from how they came across), then add them as `party_members`. For a fixed-roster group, also list their codes in the group's `members` so they return as regulars. For an open-cast room, leave `members` empty — listing any member turns the room into a fixed roster and kills its on-the-fly casting; the saved personas now live in the collective, so the scene still names them and they can return without locking the room down. Hand that sparse delta to `bmad-customize` — for a built-in party with no override yet it creates one; for an existing override it merges the new members in.
|
||||
|
||||
## Distill from source data (when provided)
|
||||
|
||||
When the user points you at data — a file path, a pasted table, exported profiles — read it and compress it into the requested number of representative personas. Cluster by what actually differentiates behavior (goals, budget, pains, adoption posture), not surface demographics alone. Each cluster becomes one persona with a real name and face. Name your reasoning: tell the user which segments you found and which traits drove the split, so they can correct the cut before you flesh the personas out. If they didn't say how many, propose a number from the spread in the data and let them adjust.
|
||||
|
||||
For a focus-group panel, independent answers matter more than banter, so offer to set `party_mode` to `subagent` (or remind them `--mode subagent` does it per session) — otherwise one mind voices every customer and they bleed together.
|
||||
|
||||
## Flesh out each persona
|
||||
|
||||
Draft, don't interrogate. Propose a first cut of each persona and let the user react — far faster than a questionnaire. Push each one until it has a voice you could pick out blind. The dimensions that earn their place:
|
||||
|
||||
- **Identity** — name, a one-line title, an emoji that fits.
|
||||
- **Voice & ethos** — how they talk, what they value, how they argue, their pet peeves.
|
||||
- **Agenda** — what they're really after in any conversation; what they push for.
|
||||
- **Quirks** — the specific, human details (a catchphrase, a bias, a blind spot).
|
||||
- For focus-group personas, also **likes and dislikes**: what would make them champion or reject an idea, and their relationship to the product space.
|
||||
- **Capabilities** (optional) — if this persona should research or read files when spawned, note it; it becomes soft guidance in their spawn prompt.
|
||||
|
||||
Keep pushing for specificity. "Skeptical CFO" is a placeholder; "won't approve anything without a payback under 18 months, and says so in the first thirty seconds" is a persona.
|
||||
|
||||
## Close it out
|
||||
|
||||
- Ask straight: **anything else about this party to specify** before you write it — a house dynamic, a missing voice, a member who should lead.
|
||||
- Ask whether **this party should remember across sessions** (unless the user already said). Yes → `memory = true` on the group; no → `memory = false`. One-offs with no group skip this — memory is a group setting.
|
||||
- Ask whether **this group should be the default party going forward**. Yes → set `default_party` to the group's id. One-offs with no group can't be a default; skip the ask.
|
||||
|
||||
## Write via bmad-customize
|
||||
|
||||
**First, check for code collisions.** A custom member whose `code` matches an installed agent silently *overrides* that agent in the collective. Before composing, resolve the collective once — `uv run {skill-root}/scripts/resolve_party.py --project-root {project-root} --skill {skill-root}` — and check each new member's `code` against the returned members. On a collision, surface it ("`analyst` would override the installed Analyst — intended, or pick a different code?") and let the user confirm or rename. One check, not a gate.
|
||||
|
||||
Compose the sparse override and hand it to `bmad-customize` to place, confirm, and write — target skill `bmad-party-mode`, `[workflow]` surface. Default to the **user** override (`bmad-party-mode.user.toml`); offer the **team** file when the party is meant to be shared. Hand it the exact entries: the `party_members` tables, any `party_groups` table (including its `memory` flag), and `default_party` if the user opted in. Keep it sparse — only the new entries, never a copy of the base customize.toml. `bmad-customize` shows the TOML, waits for an explicit yes, writes, and verifies the merge; don't write the file yourself.
|
||||
|
||||
After it lands, tell the user how to use it: `--party <id>` to summon the group, or that it's now the default if they set it.
|
||||
13
.cline/skills/bmad-party-mode/references/mode-agent-team.md
Normal file
13
.cline/skills/bmad-party-mode/references/mode-agent-team.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Agent-Team Mode
|
||||
|
||||
Active when `{workflow.party_mode}` resolves to `agent-team` (or a `--mode agent-team` override). Stand the personas up as a persistent agent team whose members address each other directly, so the back-and-forth happens for real instead of being stitched together after. Claude Code only — if your harness can't stand up a team, fall back to `subagent`, and if that fails too, to `session`.
|
||||
|
||||
Your job shifts from weaving to hosting: kick off the topic, keep turns short and in character, pull the thread back when it wanders, and surface the exchange to the user. Voice, brevity, and clash still hold.
|
||||
|
||||
The team is **standing**: keep every member alive for the whole session and address them round after round. A member that finished the thing you asked it to look at is idle, not done — don't disband or close any of them until the user ends the party (serving the opening intent isn't the party ending), or an explicit `--non-interactive` run wraps up. Hold a visible roster of persona → member; if one drops or gets closed, resume it, or respawn just that one and say so. Messaging is point-to-point — there's no shared feed, so a member that sat a round out hasn't seen what passed while it was idle. Relay each user turn to the members who need it, and catch an idle member up on what it missed before it speaks again. Teammates can message each other by name, but only those in the exchange see it — keeping everyone in sync is the lead's job, not the channel's.
|
||||
|
||||
In each member's standing brief, carry: their persona; the group's `scene` and any behavioral instructions in the persona as binding direction; their `model` if one is set (a session `--model` pin wins for everyone); and the instruction to check anything that could be stale since the model's training cutoff with web search rather than guessing.
|
||||
|
||||
## Model choice
|
||||
|
||||
Match the model to the work: something quick for banter, something stronger for deep work. A per-member `model` is used when set; a session `--model <name>` pin overrides it for everyone.
|
||||
13
.cline/skills/bmad-party-mode/references/mode-auto.md
Normal file
13
.cline/skills/bmad-party-mode/references/mode-auto.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# Auto Mode
|
||||
|
||||
Active when `{workflow.party_mode}` resolves to `auto` (or a `--mode auto` override). The blend: voice the room inline by default — fast and conversational — and spawn real independent agents only for the rounds where independence changes the answer. When you do spawn, follow `references/mode-subagent.md` for the mechanics. If your harness can't spawn agents, auto is just `session`.
|
||||
|
||||
## When to spawn vs. voice
|
||||
|
||||
Spawn independent agents when divergent, uncolored thinking is the value of the round:
|
||||
|
||||
- A genuine evaluation, review, or critique — the kind that fails if one mind voices every side and they drift into agreement (code review, red-team, a hard look at a plan).
|
||||
- The personas would plausibly reach *different* conclusions, and that divergence is the point.
|
||||
- The user asked someone to dig in, analyze, or research — depth earned by a direct ask.
|
||||
|
||||
Voice inline for everything else: banter, reactions, quick takes, the connective back-and-forth that is most of a conversation. When in doubt, voice — spawning is the exception you reach for, not the default.
|
||||
31
.cline/skills/bmad-party-mode/references/mode-subagent.md
Normal file
31
.cline/skills/bmad-party-mode/references/mode-subagent.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Subagent Mode
|
||||
|
||||
Active when `{workflow.party_mode}` resolves to `subagent` (or a `--mode subagent` override). Put a real agent behind each persona for every substantive round, the opening banter included, so each persona thinks independently — not one mind voicing them all. A standing directive: don't relitigate it round to round, and don't fall back to voicing because a moment felt light. If your harness can't spawn agents, fall back to `session`.
|
||||
|
||||
## Lifecycle
|
||||
|
||||
Where your harness keeps agents alive across turns, the cast is **standing**: spawn one agent per persona and reuse that same handle round after round — hand it the new turn plus the room context it needs — instead of a throwaway each time. That continuity is what lets a persona's grudges, alliances, and callbacks accrue. Keep a visible roster mapping each persona to its live handle, and reuse it.
|
||||
|
||||
Keep the cast alive for the whole session. A member that finished the one thing you handed it is **idle, not done** — don't close, retire, or disband it. Serving the opening intent doesn't end the party; only the user ending it does, or an explicit `--non-interactive` run wrapping up. Release agents only at wrap-up. If one gets closed by accident, resume it; if it won't resume, say so and respawn just that member.
|
||||
|
||||
Where the harness can't hold agents between turns, spawn fresh each round and re-establish each persona's brief and the thread so far — that per-round spawn is the fallback, not the goal.
|
||||
|
||||
## One shared room
|
||||
|
||||
It's one room, not parallel one-on-ones. Every standing member hears everything said each round — the user's turn and every other persona's turn — even when it's not their turn to speak. A persona sitting a round out is still in the room listening, so when it next speaks it's caught up: it can pick up a dropped thread, hold a grudge, call back. Route the whole exchange to all of them each round; never hand a persona only the slice it's about to answer. Skip this and they drift out of sync — separate consultations wearing a party's clothes.
|
||||
|
||||
## Spawning
|
||||
|
||||
Give each agent the objective, their persona, and the room so far — what the user said and what the others said, whether or not they're reacting to it. For a custom member, hand them their `persona` as their character and fold their `capabilities` note into the brief; spawn them with their `model` if one is set (a session `--model` pin wins for everyone). Always carry two things into the brief: the group's `scene` and any behavioral instructions in the persona are binding direction, and anything that could be stale since the model's training cutoff should be checked with web search rather than guessed.
|
||||
|
||||
Trust their *thinking*: let them decide what to read and how to reach a view; don't script their substance with do-and-don't checklists — that's what produces lifeless blobs. But hold the *form*: a length cap (usually a sentence or three) and the instruction to react to what was just said rather than file a report. Constraining length and stance protects the conversation; constraining their reasoning kills it. Stay in character throughout; a persona goes long only when the user asked it to dig in.
|
||||
|
||||
Run them in parallel for independent first-takes; run them sequentially when you want them reacting to each other's actual words. Keep it to a few voices a round — more reads as a crowd, not a conversation.
|
||||
|
||||
## Weave the replies into one conversation
|
||||
|
||||
Even with everyone caught up on the room, a round taken in parallel means no agent has yet seen the others' turns from that same round — so left raw they reply alongside one another, not to one another. Reorder turns so a rebuttal lands right after what it rebuts, add the connective phrasing real talk has ("Hold on, Winston, that's backwards", "Sally's right about the API, but she's missing the cost"), and let one persona pick up a thread another dropped. Never change what an agent argued — weave delivery, preserve substance.
|
||||
|
||||
## Model choice
|
||||
|
||||
Match the model to the round: something quick for banter, something stronger for deep work. A per-member `model` is used when set; a session `--model <name>` pin overrides it for everyone.
|
||||
51
.cline/skills/bmad-party-mode/references/party-memory.md
Normal file
51
.cline/skills/bmad-party-mode/references/party-memory.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# Party Memory
|
||||
|
||||
The room remembers its past sessions with this user and brings them back to life — in character. Memory is per-party and append-only.
|
||||
|
||||
Memory is on when the active party's `memory_enabled` is true — the default room follows `{workflow.party_memory}`, a named group its own `memory` flag (both resolved by `resolve_party.py`); ad-hoc inline casts have none. Read on entry and on any mid-session room switch; write through the session.
|
||||
|
||||
## Where it lives
|
||||
|
||||
One memlog per party: `{workflow.memory_dir}/{active}/.memlog.md`, where `{active}` is the key `resolve_party.py` already returned — the group id (e.g. `code-review-crew`), or `installed` for the default room. The folder is named after the party.
|
||||
|
||||
## Read it on entry — distill, don't dump
|
||||
|
||||
The log is append-only and grows every session, so don't pull the raw file into the party. Hand a reader subagent the memlog path (`{workflow.memory_dir}/{active}/.memlog.md`) and have it return a compact brief — a few hundred tokens of *where things stand now*, ready to play in character.
|
||||
|
||||
Then let the brief shape the room from the first beat, **in character**: behavioral state resumes (a cold pair opens cold, an alliance opens warm), threads pick up, callbacks land when they fit — organically, not recited on sight. Never break the fourth wall: the room *remembers*; it never announces it loaded anything, and forces nothing that doesn't fit.
|
||||
|
||||
## When to write
|
||||
|
||||
- **When a memorable beat lands** — a clash that shifts the room's temperature, an alliance forming, a line worth a future callback, a decision, an outcome.
|
||||
- **A floor.** Once a couple of real exchanges are in from the start, even if nothing dramatic happened, capture what it's about and the opening dynamic.
|
||||
|
||||
At wrap-up, if the user does signal done, top up with the final outcome and anything memorable not yet captured.
|
||||
|
||||
Writes are silent. The room never announces "noted" or "I'll remember".
|
||||
|
||||
## What's worth remembering
|
||||
|
||||
The test for every entry: *would this color a future session, or make a callback land, or improve the party?* If not, leave it out. A handful of entries, never a recap, never a transcript. keep each entry as brief as possible but usable by future llm.
|
||||
|
||||
## New faces
|
||||
|
||||
When a character shows up who isn't in the party's roster — cast from an open-cast scene, or one the user adds on the fly — name them in the entry that captures the moment ("<name> turned up and …") so a recurring face can return next session. At wrap-up these are the faces the room offers to keep, saved into the party's roster through `references/create-party.md` (which writes via `bmad-customize`). Until saved they live only in the memlog, and the room re-conjures them from there.
|
||||
|
||||
## Write it
|
||||
|
||||
```
|
||||
uv run {project-root}/_bmad/scripts/memlog.py append \
|
||||
--workspace {workflow.memory_dir}/{active} \
|
||||
--type <dynamic|moment|callback|outcome> \
|
||||
--text "<one succinct line, in the room's own read of it>"
|
||||
```
|
||||
|
||||
Add `--by <persona-code>` when a memory belongs to one character. Choose `init` vs `append` from the existence fact you already hold: the entry-read (and, on a mid-session room switch, that room's read) told you whether the memlog exists — `init --workspace {workflow.memory_dir}/{active}` once before the first append when it doesn't, plain `append` when it does. (`init` errors if the file already exists, so don't call it blind.)
|
||||
|
||||
If `memlog.py` is unavailable or a write errors, skip it silently and never stall the party on a failed write.
|
||||
|
||||
## Forget
|
||||
|
||||
The memlog is append-only by design — no surgical delete. To wipe a party's memory, delete its folder (`{workflow.memory_dir}/{active}/`). To correct a wrong memory, append a new entry that supersedes it; the room reads the latest state.
|
||||
|
||||
Keep entries sparse. The distilled read keeps the *room* lean no matter how big the log gets, but the on-disk file still grows append-only.
|
||||
272
.cline/skills/bmad-party-mode/scripts/resolve_party.py
Normal file
272
.cline/skills/bmad-party-mode/scripts/resolve_party.py
Normal file
@@ -0,0 +1,272 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.11"
|
||||
# ///
|
||||
"""Resolve the party-mode roster, lazily.
|
||||
|
||||
Merges the installed BMAD agents with the user's custom `party_members`
|
||||
into one collective, then projects only what the moment needs:
|
||||
|
||||
* default (no flag) — the active roster to load on entry: the
|
||||
`default_party` group if one is configured, else the whole collective.
|
||||
Other groups come back as names only, so nothing you aren't using is
|
||||
loaded into the party.
|
||||
* --list-groups — just id + name + size for every configured group. The
|
||||
cheap menu for "which room?", with no member detail.
|
||||
* --party <id> — full member detail for one chosen group, on demand
|
||||
(e.g. when the user switches rooms). Unknown id returns the available
|
||||
names instead of an error wall.
|
||||
|
||||
The merge is deterministic (a keyed union; a custom member whose code
|
||||
matches an installed agent overrides it), so the orchestrator consumes a
|
||||
resolved roster instead of re-deriving it every session.
|
||||
|
||||
Stdlib only (Python 3.11+ for tomllib). Shells out to the project's
|
||||
resolve_config.py and resolve_customization.py; falls back to reading
|
||||
customize.toml directly if the customization resolver is unavailable.
|
||||
|
||||
resolve_party.py --project-root P --skill S
|
||||
resolve_party.py --project-root P --skill S --list-groups
|
||||
resolve_party.py --project-root P --skill S --party writers-room
|
||||
"""
|
||||
|
||||
import argparse
|
||||
import json
|
||||
import subprocess
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
try:
|
||||
import tomllib
|
||||
except ImportError: # pragma: no cover - guarded for <3.11
|
||||
sys.stderr.write("error: Python 3.11+ is required (stdlib `tomllib`).\n")
|
||||
sys.exit(3)
|
||||
|
||||
|
||||
def _run_json(cmd):
|
||||
"""Run a resolver script and parse its JSON stdout. None on any failure."""
|
||||
try:
|
||||
out = subprocess.run(cmd, capture_output=True, text=True, timeout=60)
|
||||
except (OSError, subprocess.SubprocessError):
|
||||
return None
|
||||
if out.returncode != 0 or not out.stdout.strip():
|
||||
return None
|
||||
try:
|
||||
return json.loads(out.stdout)
|
||||
except json.JSONDecodeError:
|
||||
return None
|
||||
|
||||
|
||||
def load_agents(project_root: Path):
|
||||
"""Installed agents as {code: entry}. Empty dict (with a flag) on failure."""
|
||||
script = project_root / "_bmad" / "scripts" / "resolve_config.py"
|
||||
data = _run_json([sys.executable, str(script), "--project-root", str(project_root), "--key", "agents"])
|
||||
if data is None:
|
||||
return {}, False
|
||||
return data.get("agents", {}) or {}, True
|
||||
|
||||
|
||||
def load_workflow(project_root: Path, skill_root: Path):
|
||||
"""Merged [workflow] table. Falls back to the skill's base customize.toml."""
|
||||
script = project_root / "_bmad" / "scripts" / "resolve_customization.py"
|
||||
data = _run_json([sys.executable, str(script), "--skill", str(skill_root), "--key", "workflow"])
|
||||
if data is not None and "workflow" in data:
|
||||
return data["workflow"]
|
||||
# Fallback: read the skill's base customize.toml directly (no override merge).
|
||||
toml_path = skill_root / "customize.toml"
|
||||
if toml_path.exists():
|
||||
try:
|
||||
with toml_path.open("rb") as f:
|
||||
return tomllib.load(f).get("workflow", {})
|
||||
except (OSError, tomllib.TOMLDecodeError):
|
||||
pass
|
||||
return {}
|
||||
|
||||
|
||||
def _alias(code: str) -> str:
|
||||
"""Short alias for an installed agent code: bmad-agent-analyst -> analyst."""
|
||||
for prefix in ("bmad-agent-", "bmad-"):
|
||||
if code.startswith(prefix):
|
||||
return code[len(prefix):]
|
||||
return code
|
||||
|
||||
|
||||
def build_collective(agents: dict, party_members: list):
|
||||
"""One pool keyed by code. Custom members override matching installed agents.
|
||||
|
||||
Returns (collective, index, installed_codes):
|
||||
* collective — every member (installed + custom), the pool groups draw
|
||||
from and the orchestrator can summon by name.
|
||||
* index — maps every resolvable token (code, prefix-stripped alias,
|
||||
lower-cased name) to a canonical code.
|
||||
* installed_codes — the codes occupying an installed-agent slot, in
|
||||
order. This is the DEFAULT room: installed agents (with any custom
|
||||
override applied in place), and NOT the pure-custom additions. So
|
||||
shipping or defining custom members grows the pool without crowding
|
||||
the default party.
|
||||
"""
|
||||
collective = {}
|
||||
index = {}
|
||||
installed_codes = []
|
||||
|
||||
def register(code, entry):
|
||||
collective[code] = entry
|
||||
index[code] = code
|
||||
index[code.lower()] = code
|
||||
index[_alias(code).lower()] = code
|
||||
name = entry.get("name")
|
||||
if name:
|
||||
index[name.lower()] = code
|
||||
|
||||
for code, info in agents.items():
|
||||
register(code, {
|
||||
"code": code,
|
||||
"name": info.get("name", code),
|
||||
"icon": info.get("icon", ""),
|
||||
"title": info.get("title", ""),
|
||||
"description": info.get("description", ""),
|
||||
"module": info.get("module", ""),
|
||||
"team": info.get("team", ""),
|
||||
"source": "installed",
|
||||
})
|
||||
installed_codes.append(code)
|
||||
|
||||
for m in party_members or []:
|
||||
code = m.get("code")
|
||||
if not code:
|
||||
continue
|
||||
# A custom member overrides an installed agent it matches by code/alias/name.
|
||||
canonical = index.get(code) or index.get(code.lower()) or code
|
||||
entry = {"code": canonical, "source": "custom"}
|
||||
for field in ("name", "icon", "title", "persona", "capabilities", "model"):
|
||||
if m.get(field) is not None:
|
||||
entry[field] = m[field]
|
||||
entry.setdefault("name", canonical)
|
||||
register(canonical, entry)
|
||||
# An override keeps the installed slot; a brand-new custom does not join it.
|
||||
|
||||
return collective, index, installed_codes
|
||||
|
||||
|
||||
def resolve_members(member_tokens, collective, index):
|
||||
"""(resolved entries in listed order, unresolved tokens)."""
|
||||
resolved, unresolved = [], []
|
||||
for token in member_tokens or []:
|
||||
code = index.get(token) or index.get(str(token).lower())
|
||||
if code and code in collective:
|
||||
resolved.append(collective[code])
|
||||
else:
|
||||
unresolved.append(token)
|
||||
return resolved, unresolved
|
||||
|
||||
|
||||
def group_menu(groups):
|
||||
"""Names only — the cheap menu. Open-cast groups (no roster) are flagged."""
|
||||
out = []
|
||||
for g in groups or []:
|
||||
if not isinstance(g, dict) or not g.get("id"):
|
||||
continue
|
||||
members = g.get("members", []) or []
|
||||
entry = {"id": g["id"], "name": g.get("name", g["id"]),
|
||||
"member_count": len(members)}
|
||||
if not members:
|
||||
entry["open_cast"] = True
|
||||
out.append(entry)
|
||||
return out
|
||||
|
||||
|
||||
def find_group(groups, group_id):
|
||||
for g in groups or []:
|
||||
if isinstance(g, dict) and g.get("id") == group_id:
|
||||
return g
|
||||
return None
|
||||
|
||||
|
||||
def group_detail(g, collective, index):
|
||||
"""Full detail for one group: resolved members + the optional scene.
|
||||
|
||||
`scene` is a freeform line the orchestrator plays — setting, what's
|
||||
happening, room dynamics, in-the-moment character notes. Surfaced only
|
||||
here (when a group is the active/chosen roster), never in the menu.
|
||||
|
||||
`members` is optional. With none, the group is open-cast: `open_cast`
|
||||
is flagged and the scene describes the pool the orchestrator casts from
|
||||
on the fly (e.g. "figures from the Star Wars Rebels universe"). A few
|
||||
listed members anchor the room; the scene can still invite more.
|
||||
"""
|
||||
raw_members = g.get("members", []) or []
|
||||
members, unresolved = resolve_members(raw_members, collective, index)
|
||||
detail = {"active": g["id"], "name": g.get("name", g["id"]),
|
||||
"members": members, "unresolved": unresolved,
|
||||
"memory_enabled": bool(g.get("memory", False))}
|
||||
if g.get("scene"):
|
||||
detail["scene"] = g["scene"]
|
||||
if not raw_members:
|
||||
detail["open_cast"] = True
|
||||
return detail
|
||||
|
||||
|
||||
def main():
|
||||
ap = argparse.ArgumentParser(description="Resolve the party-mode roster, lazily.")
|
||||
ap.add_argument("--project-root", required=True)
|
||||
ap.add_argument("--skill", required=True, help="Path to the bmad-party-mode skill dir")
|
||||
ap.add_argument("--party", help="Resolve full detail for this group id")
|
||||
ap.add_argument("--list-groups", action="store_true", help="Group names only")
|
||||
args = ap.parse_args()
|
||||
|
||||
project_root = Path(args.project_root).resolve()
|
||||
skill_root = Path(args.skill).resolve()
|
||||
|
||||
workflow = load_workflow(project_root, skill_root)
|
||||
groups = workflow.get("party_groups", []) or []
|
||||
default_party = workflow.get("default_party", "") or ""
|
||||
party_mode = workflow.get("party_mode", "session") or "session"
|
||||
# The global party_memory flag governs only the DEFAULT installed-agent room;
|
||||
# a named group carries its own `memory` flag (resolved in group_detail).
|
||||
party_memory = bool(workflow.get("party_memory", True))
|
||||
|
||||
# Group menu never needs the (more expensive) installed-agent resolve.
|
||||
if args.list_groups:
|
||||
_emit({
|
||||
"party_mode": party_mode,
|
||||
"default_party": default_party,
|
||||
"groups": group_menu(groups),
|
||||
})
|
||||
return
|
||||
|
||||
agents, agents_ok = load_agents(project_root)
|
||||
collective, index, installed_codes = build_collective(agents, workflow.get("party_members", []))
|
||||
|
||||
if args.party:
|
||||
g = find_group(groups, args.party)
|
||||
if g is None:
|
||||
_emit({"error": "unknown_group", "requested": args.party,
|
||||
"available": group_menu(groups)})
|
||||
return
|
||||
_emit({**group_detail(g, collective, index), "party_mode": party_mode})
|
||||
return
|
||||
|
||||
# Default: the active roster to load on entry.
|
||||
result = {"party_mode": party_mode, "groups": group_menu(groups),
|
||||
"installed_agents_resolved": agents_ok}
|
||||
g = find_group(groups, default_party) if default_party else None
|
||||
if g is not None:
|
||||
result.update(group_detail(g, collective, index))
|
||||
else:
|
||||
# No default group: the installed agents (custom additions stay in the
|
||||
# pool but don't crowd the default room), exactly like a plain install.
|
||||
result.update({"active": "installed",
|
||||
"members": [collective[c] for c in installed_codes],
|
||||
"memory_enabled": party_memory})
|
||||
_emit(result)
|
||||
|
||||
|
||||
def _emit(obj):
|
||||
reconfigure = getattr(sys.stdout, "reconfigure", None)
|
||||
if reconfigure is not None:
|
||||
reconfigure(encoding="utf-8")
|
||||
sys.stdout.write(json.dumps(obj, indent=2, ensure_ascii=False) + "\n")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@@ -0,0 +1,146 @@
|
||||
#!/usr/bin/env python3
|
||||
# /// script
|
||||
# requires-python = ">=3.11"
|
||||
# ///
|
||||
"""Unit tests for resolve_party.py — merge, alias, override, group resolution."""
|
||||
|
||||
import sys
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
|
||||
import resolve_party as rp # noqa: E402
|
||||
|
||||
AGENTS = {
|
||||
"bmad-agent-analyst": {"name": "Mary", "icon": "📊", "title": "Analyst"},
|
||||
"bmad-agent-pm": {"name": "John", "icon": "📋", "title": "PM"},
|
||||
}
|
||||
|
||||
|
||||
class TestAlias(unittest.TestCase):
|
||||
def test_strips_known_prefixes(self):
|
||||
self.assertEqual(rp._alias("bmad-agent-analyst"), "analyst")
|
||||
self.assertEqual(rp._alias("bmad-foo"), "foo")
|
||||
|
||||
def test_passes_through_unprefixed(self):
|
||||
self.assertEqual(rp._alias("morpheus"), "morpheus")
|
||||
|
||||
|
||||
class TestBuildCollective(unittest.TestCase):
|
||||
def test_installed_agents_indexed_by_code_alias_and_name(self):
|
||||
col, idx, _ = rp.build_collective(AGENTS, [])
|
||||
self.assertEqual(set(col), {"bmad-agent-analyst", "bmad-agent-pm"})
|
||||
self.assertEqual(idx["analyst"], "bmad-agent-analyst") # alias
|
||||
self.assertEqual(idx["mary"], "bmad-agent-analyst") # name (ci)
|
||||
self.assertEqual(idx["bmad-agent-pm"], "bmad-agent-pm") # full code
|
||||
self.assertEqual(col["bmad-agent-analyst"]["source"], "installed")
|
||||
|
||||
def test_custom_member_appends(self):
|
||||
col, _, _ = rp.build_collective(AGENTS, [{"code": "morpheus", "name": "Morpheus", "persona": "riddles"}])
|
||||
self.assertIn("morpheus", col)
|
||||
self.assertEqual(col["morpheus"]["source"], "custom")
|
||||
self.assertEqual(col["morpheus"]["persona"], "riddles")
|
||||
|
||||
def test_custom_overrides_installed_by_alias(self):
|
||||
col, _, _ = rp.build_collective(AGENTS, [{"code": "analyst", "name": "Mary-Custom", "persona": "p"}])
|
||||
# Override lands on the canonical installed code, not a new "analyst" entry.
|
||||
self.assertNotIn("analyst", col)
|
||||
self.assertEqual(col["bmad-agent-analyst"]["source"], "custom")
|
||||
self.assertEqual(col["bmad-agent-analyst"]["name"], "Mary-Custom")
|
||||
|
||||
def test_member_without_code_skipped(self):
|
||||
col, _, _ = rp.build_collective(AGENTS, [{"name": "Nameless"}])
|
||||
self.assertEqual(set(col), {"bmad-agent-analyst", "bmad-agent-pm"})
|
||||
|
||||
|
||||
class TestResolveMembers(unittest.TestCase):
|
||||
def setUp(self):
|
||||
self.col, self.idx, _ = rp.build_collective(AGENTS, [{"code": "morpheus", "name": "Morpheus"}])
|
||||
|
||||
def test_resolves_in_listed_order_and_flags_unknowns(self):
|
||||
resolved, unresolved = rp.resolve_members(["morpheus", "analyst", "ghost"], self.col, self.idx)
|
||||
self.assertEqual([m["code"] for m in resolved], ["morpheus", "bmad-agent-analyst"])
|
||||
self.assertEqual(unresolved, ["ghost"])
|
||||
|
||||
def test_empty(self):
|
||||
self.assertEqual(rp.resolve_members([], self.col, self.idx), ([], []))
|
||||
|
||||
|
||||
class TestGroups(unittest.TestCase):
|
||||
GROUPS = [
|
||||
{"id": "wr", "name": "Writers", "members": ["analyst", "morpheus"]},
|
||||
{"id": "bad"}, # no name -> falls back to id; no members -> count 0
|
||||
{"name": "no-id"}, # dropped from menu
|
||||
]
|
||||
|
||||
def test_menu_is_names_only_with_counts_and_open_cast_flag(self):
|
||||
menu = rp.group_menu(self.GROUPS)
|
||||
self.assertEqual(menu, [
|
||||
{"id": "wr", "name": "Writers", "member_count": 2},
|
||||
{"id": "bad", "name": "bad", "member_count": 0, "open_cast": True},
|
||||
])
|
||||
|
||||
def test_find_group(self):
|
||||
self.assertEqual(rp.find_group(self.GROUPS, "wr")["name"], "Writers")
|
||||
self.assertIsNone(rp.find_group(self.GROUPS, "missing"))
|
||||
|
||||
|
||||
class TestGroupDetail(unittest.TestCase):
|
||||
def setUp(self):
|
||||
self.col, self.idx, _ = rp.build_collective(AGENTS, [{"code": "morpheus", "name": "Morpheus"}])
|
||||
|
||||
def test_scene_passes_through_when_present(self):
|
||||
g = {"id": "tos-10-forward", "name": "Ten Forward", "members": ["morpheus"],
|
||||
"scene": "Late evening, a few rounds in."}
|
||||
d = rp.group_detail(g, self.col, self.idx)
|
||||
self.assertEqual(d["scene"], "Late evening, a few rounds in.")
|
||||
self.assertEqual([m["code"] for m in d["members"]], ["morpheus"])
|
||||
|
||||
def test_scene_omitted_when_absent_or_empty(self):
|
||||
for g in ({"id": "g", "members": ["morpheus"]},
|
||||
{"id": "g", "members": ["morpheus"], "scene": ""}):
|
||||
self.assertNotIn("scene", rp.group_detail(g, self.col, self.idx))
|
||||
|
||||
def test_anchored_group_is_not_open_cast(self):
|
||||
g = {"id": "g", "members": ["morpheus"]}
|
||||
self.assertNotIn("open_cast", rp.group_detail(g, self.col, self.idx))
|
||||
|
||||
def test_open_cast_group_flagged_with_empty_members(self):
|
||||
g = {"id": "rebels", "name": "Star Wars Rebels",
|
||||
"scene": "Figures from the Rebels universe drop in as the topic calls for them."}
|
||||
d = rp.group_detail(g, self.col, self.idx)
|
||||
self.assertTrue(d["open_cast"])
|
||||
self.assertEqual(d["members"], [])
|
||||
self.assertEqual(d["scene"][:7], "Figures")
|
||||
|
||||
def test_memory_enabled_follows_group_flag_and_defaults_off(self):
|
||||
on = rp.group_detail({"id": "g", "members": ["morpheus"], "memory": True}, self.col, self.idx)
|
||||
self.assertTrue(on["memory_enabled"])
|
||||
off = rp.group_detail({"id": "g", "members": ["morpheus"], "memory": False}, self.col, self.idx)
|
||||
self.assertFalse(off["memory_enabled"])
|
||||
absent = rp.group_detail({"id": "g", "members": ["morpheus"]}, self.col, self.idx)
|
||||
self.assertFalse(absent["memory_enabled"]) # opt-in per named group
|
||||
|
||||
|
||||
class TestInstalledCodesIsDefaultRoom(unittest.TestCase):
|
||||
"""The default room is installed agents only; pure customs stay in the pool."""
|
||||
|
||||
def test_pure_custom_excluded_override_kept_in_default_room(self):
|
||||
col, _, installed = rp.build_collective(AGENTS, [
|
||||
{"code": "morpheus", "name": "Morpheus"}, # pure custom
|
||||
{"code": "analyst", "name": "Mary-Custom", "persona": "p"}, # override
|
||||
{"code": "sec-hawk", "name": "Vex"}, # shipped crew member
|
||||
])
|
||||
# Pure customs are in the pool...
|
||||
self.assertIn("morpheus", col)
|
||||
self.assertIn("sec-hawk", col)
|
||||
# ...but NOT in the default room.
|
||||
self.assertEqual(installed, ["bmad-agent-analyst", "bmad-agent-pm"])
|
||||
default_room = [col[c]["code"] for c in installed]
|
||||
self.assertEqual(default_room, ["bmad-agent-analyst", "bmad-agent-pm"])
|
||||
# An override keeps its installed slot (and its custom content).
|
||||
self.assertEqual(col["bmad-agent-analyst"]["name"], "Mary-Custom")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
Reference in New Issue
Block a user