Party Mode

Run a round-table where these personas 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} (the folder this SKILL.md lives in); {skill-root}/... means the skill folder itself. Any {skill-root} placeholder inside party.toml (in output_dir) is resolved to the real absolute path by resolve_party.py — it returns absolute values.
• Config: the skill's configuration and roster live in party.toml at the skill root. An optional user override at user/party.user.toml merges over it (override wins). Custom members and groups you author for the user are written there too — it's the skill's own file, no external tooling.
• Scripts (run via plain python3, stdlib only): scripts/resolve_party.py resolves the roster, party_mode, memory_enabled, and scene/open_cast. Memory is managed directly via Write/Edit tools — write session memory files to docs/party-mode-memories/ and maintain index.md.
• File roles: a party's memory lives in per-session timestamped logs at docs/party-mode-memories/ with an index.md for quick lookup; custom members and groups live in user/party.user.toml. Mechanics in references/party-memory.md (memory), references/create-party.md (authoring), and references/model-selection.md (model assignment for subagent modes).
• Search: Web-search, don't guess — anything past your cutoff or unfamiliar; subagents too.
• Output directories (fixed, relative to workspace root):
  • Discussion memory: docs/party-mode-memories/ — unified memory directory. Contains index.md (session index) and per-session memory files ({YYYY-MM-DD}-{topic}-memory.md).
  • Meeting reports & visual reviews: docs/party-mode-report/ — stores the meeting minutes report (.md) and the visual discussion review (.html).
  • These directories are not configurable via party.toml; they are always relative to the current workspace root. Create them on first use if they don't exist.

On Activation