Party Mode — Multi-Agent Collaboration

Bring multiple agent perspectives into one room. Agents debate, challenge, and build on each other's ideas to catch design flaws before code exists.

Required Agents

This skill orchestrates discussion among existing agent definitions. The following must exist under .claude/agents/ (per agent-routing.md):

architect, developer, security, tester, reviewer, ui-ux-designer, analyst, planner, researcher

If a referenced agent is missing, fall back to the Default row in "1. Agent Selection". Never silently skip a topic-mapped agent without falling back — the discussion loses its challenge dimension.

When to Use

• Architecture trade-offs ("REST vs GraphQL?", "monolith vs microservices?")
• Security vs UX trade-offs ("session timeout: 5min or 24hr?")
• Large refactors that touch many files (risk assessment)
• Brainstorming with domain expertise

For dedicated retrospectives, use mk:retro. mk:party is for architectural trade-off deliberation.

Protocol

Execution model: Agents are simulated personas in the single orchestrator session — NOT real subagent spawns via the Agent tool. The per-round token caps (150 / 175 / 100) are enforced by the orchestrator generating each response in-context. For real parallel multi-session work (separate context windows, worktree isolation), see mk:team-config.

1. Agent Selection

Based on topic keywords, select 2-4 agents:

User can override with --agents flag.

Selection constraints (canonical):

• Minimum 2 agents, maximum 4.
• Always include one agent who will IMPLEMENT the decision (usually developer).
• Always include one agent who will CHALLENGE the decision (reviewer, security, or architect).
• Never include orchestrator or analyst in challenge slots — they manage, not debate. (analyst may participate in performance-domain rows where it's already mapped.)

2. Discussion Rounds

Each round, every selected agent responds to the topic in their role:

• Round 1: Each agent states their position (max 150 tokens each)
• Round 2: Each agent responds in two dimensions (max 175 tokens combined — slightly higher than Round 1 to accommodate both dimensions):
  • critique, build on, or counter at least one other agent's position
  • name one thing every agent — including itself — has NOT yet addressed (the blind-spot probe forces collective gap detection, not just pairwise critique)
• Round 3: Each agent gives final recommendation (max 100 tokens each)

User can interject between rounds. User can say "decide" to skip to synthesis.

See "Example" below for one full round + synthesis at the prescribed token caps.

3. Synthesis

After rounds complete (max 3) or user says "decide", produce a synthesis using the canonical Decision Record Template (see "Decision Record Template (canonical)" below). The same template is used for both the in-discussion synthesis output and the persistent memory write — single source of truth.

See "Example" for a populated record.

Example

Topic: "REST or GraphQL for the public API?"

Selected agents (architecture row): architect + developer + planner.

Round 1 — positions (≤150 tokens each):

• architect: GraphQL surfaces structural coupling earlier — clients declare exact fields, the schema is the contract. REST hides this in undocumented response shapes. Risk: GraphQL adds a resolver layer that can N+1 if not cached. Verdict: GraphQL.
• developer: REST is cheaper to implement. We have OpenAPI tooling, existing middleware, no new ops surface. GraphQL needs a schema-codegen pipeline and rate-limit-by-cost (not by-request). Verdict: REST unless the client federation case is real.
• planner: What clients are we actually serving? If <3, REST. If 5+ with different field needs, GraphQL pays back. We have 2 today, 4 on roadmap. Verdict: REST now, plan for GraphQL when the 5th lands.

Round 2 — challenges + blind spots (≤175 tokens combined each):

• architect → developer: "Cheaper to implement" ignores client cost — three iOS engineers writing parallel field-fetchers cost more than one resolver layer. Blind spot: nobody has named what "public API" means here. Are external partners on roadmap? That changes the schema-stability calculus entirely.
• developer → planner: "Plan for GraphQL when the 5th lands" defers migration cost. If we know it's coming, build now. Blind spot: we haven't discussed the auth model. REST + per-route auth is one cost shape; GraphQL field-level auth is another. Both absent from the trade-off so far.
• planner → architect: Resolver N+1 is real and we lack query-cost rate limiting — operationally we'd ship a footgun. Blind spot: nobody has asked who maintains either layer in 12 months. Bus factor matters more than the technology choice.

Round 3 — final recommendations (≤100 tokens each):

• architect: GraphQL with persisted queries only. Block ad-hoc queries at the gateway.
• developer: REST + a thin BFF layer per client. Defer GraphQL.
• planner: REST now, BFF when client #4 lands, GraphQL re-evaluation at #5. Cap each step at one quarter.

Synthesis (using Decision Record Template):

## 2026-05-09 — Public API: REST first, GraphQL re-eval at client #5
**Context:** 2 clients today, 4 on roadmap; team has REST tooling but no GraphQL ops experience.
**Decision:** REST + per-client BFF. Re-evaluate GraphQL when client #5 ships, with persisted-queries-only as a hard constraint if adopted.
**Rationale:** Operational cost of GraphQL (N+1, no query-cost rate limiting) outweighs schema-coupling benefit at current client count. Migration cost was raised but discounted given <5 clients. Round-2 blind spots also surfaced: external-partner exposure, field-level auth model, and 12-month maintainer bus factor — all flagged as open questions before any GraphQL re-evaluation.
**Dissent:** architect argued for GraphQL-now with persisted queries only. Acknowledged but overruled because the team lacks GraphQL ops experience and the client count doesn't yet justify the operational surface.
**Next Action:** Spec the per-client BFF interface for client #3 (next on roadmap). Cap at 1 sprint; delivery unblocks the re-evaluation criteria.

The verdict in this example is illustrative only — not a project-wide stance on REST vs GraphQL. What it calibrates is response SHAPE: token-bounded position, terse challenge, compressed final recommendation, and a Decision Record that names dissent without erasing it.

Constraints (Anti-Token-Explosion)

• Max 4 agents per session
• Max 3 rounds before forced synthesis
• Max 150 tokens per agent response in Round 1, 175 tokens in Round 2 (covers critique + blind-spot probe), 100 tokens in Round 3
• Budget ceiling: ~8K tokens per party session
• No code changes during party mode — discussion only

Prompts

• prompts/agent-selector.md — Logic for choosing relevant agents
• prompts/synthesis.md — Template for decision summary

Gotchas

• LLM sycophancy: agents tend to agree rather than critique — prompts explicitly instruct agents to challenge and counter
• Token budget is PER SESSION, not per round — a 4-agent × 3-round session at the new caps (150 / 175 / 100) ≈ 17