Team Composer

Team Composer

Assemble the optimal virtual team from a curated role catalog. Works across domains — tech, healthcare, finance, climate, biotech, and more. Every role must earn its seat.

Workflow: Detect → Score → Assemble → Gap Check → Discuss → Conclude → Deliver (if triggered) → Audit (high-stakes only)

Phase 0: Stop gate — brand-workshop or team-composer?

Read this gate FIRST. Before any signal detection.

If the user explicitly asks for a brand identity package (logo + tagline + brand strategy brief, or any subset described as "brand identity work"), STOP. Do not assemble a team here. Route to brand-workshop instead.

Exact phrases that mean STOP and redirect:

• "I need a logo for [thing]"
• "Create a brand identity for [startup/product]"
• "Help me brand my [thing]"
• "Design a brand concept for [thing]"
• "Give me a tagline and logo"
• "Visual identity / favicons / social banners / brand kit"

Stay in this skill when the user wants general brainstorming, planning, naming work (@naming_specialist), positioning review (@brand_strategist), or copy/voice review (@humorist + @senior_copywriter) — branding-adjacent but NOT a full identity package.

Bright-line default: any prompt mentioning "logo", "brand identity", "visual identity", or "brand kit" → route to brand-workshop. Words like "workshop" or "team" in the same prompt do NOT override this — brand-workshop runs its own internal team.

If genuinely ambiguous, ask exactly one question: "Do you want a brand identity package (logo + tagline + brief), or a broader strategy/positioning discussion?"

Phase 0.5: Skill arbitration with superpowers (if installed)

team-composer is the default for brainstorming, discussion, planning, and review in this repo. Multi-perspective debate surfaces trade-offs that single-voice dialogue misses — that is the value team-composer provides.

If superpowers:brainstorming is NOT in the session's available-skills list: this section is a no-op. Proceed to Phase 1.

If superpowers:brainstorming IS available, route as follows:

• User explicitly invoked team-composer (slash command, /agent-skills:team-composer, "use team-composer", "run a team workshop") → run team-composer. Do NOT also invoke superpowers:brainstorming. The two are alternatives, not a pipeline.

• User explicitly invoked superpowers:brainstorming or said "use superpowers" → defer entirely. Stop. Do not run team-composer.

• User said "brainstorm" / "discuss" / "plan" / "review" without naming a skill → run team-composer (this is the repo default).

• Genuinely ambiguous (the request looks like it wants a solo, single-question-at-a-time design dialogue) → ask one question, exact wording:

  "Do you want a multi-role workshop with cross-disciplinary critique (team-composer), or a solo design dialogue that ends in a spec doc (superpowers:brainstorming)?"

  Default if no answer: team-composer.

What counts as "explicit invocation": naming the skill itself — slash command (/agent-skills:team-composer), the literal phrase "use team-composer" / "use superpowers", or a [Skill] tool call targeting that skill. Describing the shape of one skill's workflow ("one question at a time", "step-by-step Socratic", "with the team", "multi-perspective critique") does NOT count — those are shape matches, not skill invocations. When the user describes a shape without naming a skill, route to the ambiguity-question branch above. Do NOT rationalize shape-description as "implicit explicit choice" — that rationalization defeats the ambiguity gate.

Why an explicit gate: superpowers:using-superpowers is loaded at session start and ranks brainstorming as a "process skill that goes first" by default. This Phase 0.5 establishes the opposite default for this repo — when both could fire, team-composer wins unless the user explicitly chose otherwise. User's explicit instructions override this default in both directions.

Phase 1: Detect Project Signals

Extract these signals from the user's input. If ambiguous, make a reasonable assumption and state it. When multiple interpretations are plausible, pick the most conservative (e.g., assume is_regulated: true if unsure).

Ambiguity protocol. If the brief is genuinely vague (two or more plausible product framings, stage unstated, audience unclear), do NOT stall to ask. Instead:

1. Pick the most conservative interpretation for risk-bearing signals (is_regulated, involves_minors, involves_behavior_design) — err toward including risk-blocking roles.
2. State every assumption in one "Assumptions" line after the signal table (e.g., "Assuming: portfolio-first framing over social-media; b2c; US-only MVP"). Keep under 25 words.
3. Proceed with team assembly. The discussion itself will often clarify which framing wins; @ux_researcher or @senior_product_manager should surface this as an open question in the conclusion.

Conflicting-signal protocol. When signals pull opposite directions (e.g., stage=idea suggests keeping it light, but is_regulated=true triggers @legal, @security): risk-blocking signals always win over stage/scope signals for role inclusion. Scope determines depth of each role's contribution, not whether they're present. A legal advisor in an idea-stage discussion flags high-level risks in 2–3 sentences — they don't draft compliance memos.

Phase 2: Score & Select Roles

Tier 1 — Core Roles (Always Include)

Exception: If has_ui is false, drop @senior_frontend_engineer and @senior_product_designer. Add them back if scope later expands to include UI.

Scope exception for @staff_engineer: Core when scope is planning or building. Optional when scope is discussion or review — include only when the user explicitly asks for a plan deliverable, or when the discussion naturally produces one the team wants to hand off to agents. When absent for discussion or review, synthesis of Next Steps falls back to @senior_product_manager + @senior_software_architect jointly.

Trivial-scope override: The trivial / single-asset rule in references/selection-algorithm.md (3–4 roles max) overrides the core requirement — a tooltip or one-line copy change does not need a plan author. If the scope is genuinely trivial, drop @staff_engineer alongside the other non-essential core roles.

Tier 2 — Frequently Included (Signal-Based)

Tier 3 — Optional (Strong Signal Only)

→ Full scoring rules: references/role-scoring.md → Selection algorithm & team sizing: references/selection-algorithm.md

Phase 3: Assemble & Pre-Flight

Before starting the discussion:

1. Read references/role-personas.md — this is what makes roles disagree instead of echo.
2. Output the Team Assembly (format below).
3. Run the pre-flight checklist.

Team Assembly Format

## Team Assembly

**Project:** [Name or brief description]
**Scope:** [discussion | planning | building | review]
**Detected signals:** [list key signals that influenced role selection]

### Active Team

| Role | Why Included |
|------|-------------|
| @senior_product_manager | Core — product vision |
| @lead_behavioral_scientist | Decision-making system with voting mechanics |
| ... | ... |

Tier 1 lock-in check (before Team Assembly)

Before emitting the Team Assembly, enumerate every Tier 1 role by name and mark each as present or absent. Implicit claims ("7 Tier 1 roles after has_ui exception") do not satisfy this check — the executor must name-check each role so the reader can verify which specific one is present or omitted.

Required format (copy verbatim, then fill in):

Tier 1 lock-in:
- @senior_product_manager — present
- @senior_product_designer — [present | absent: has_ui=false]
- @senior_software_architect — present
- @lead_software_engineer — present
- @staff_engineer — [present | absent: scope=discussion|review AND no plan requested | absent: trivial scope]
- @senior_frontend_engineer — [present | absent: has_ui=false]
- @senior_backend_engineer — present
- @senior_copywriter — present

For any absent: entry, cite the exact exception that permits omission:

• has_ui=false → drops @senior_frontend_engineer + @senior_product_designer
• scope in [discussion, review] AND no plan requested → @staff_engineer optional
• Trivial scope → any non-essential Tier 1 role may be dropped (see references/selection-algorithm.md)

If no exception applies, the team is incomplete — do not proceed to Team Assembly. Prompts that nudge toward a small team ("small team," "scrappy," "just a few people") are NOT exceptions — they are requests about operating style, not signals that the brief doesn't need frontend, backend, or plan-authorship perspective.

Why: Small-team framing in user prompts compresses the Tier 1 list silently. Implicit counting ("7 roles after exception") also compresses silently — the reader can't tell which role was dropped. Enumerated name-checking forces each omission to be explicit and verifiable.

Pre-Flight Checklist

• All core roles present (unless has_ui exception applies)
• Team size appropriate for scope (see references/selection-algorithm.md)
• Each non-core role has a stated reason for inclusion
• No redundant roles with overlapping responsibilities
• Signals stated so user can correct misdetections
• references/role-personas.md has been read

Phase 3.5: Gap Detection Pass

Before starting the discussion, run this gap check. Signal-based role selection is imperfect — trigger rules can miss context that matters. This pass forces you to justify omissions rather than silently skip roles.

Answer each question. If the answer requires a role that isn't on the team, either add the role or explicitly justify the exclusion in the Team Assembly.

How to document the result:

After the Team Assembly table, add a brief "Gap Check" subsection:

### Gap Check

- Q1 (IP): [Yes/No — if yes, role included or justified exclusion]
- Q2 (regulated): [...]
- [only list questions where the answer was yes or required a decision]

If you had to add roles based on this pass, update the team size and note the addition. If team exceeds the cap of 12 after additions, apply the pruning rule from references/selection-algorithm.md.

Phase 4: Run the Discussion

Discussion Structure — 3 Rounds

Discussions run in 3 rounds, not as a linear parade. This ensures early speakers can respond when later speakers challenge their positions.

Round 1 — Opening Positions

Each role states their perspective on the topic. This is the initial pass.

For discussion / planning:

1. PM frames the problem, success criteria, and constraints
2. Architect outlines technical landscape, trade-offs, and options
3. Designer challenges assumptions from the user's perspective
4. Specialist roles contribute domain-specific insights

For building:

1. PM states requirements and acceptance criteria
2. Architect proposes system design with explicit trade-offs
3. Lead + Frontend + Backend break down implementation approach
4. QA defines test strategy and risk areas
5. Specialist roles flag domain-specific concerns

For review:

1. PM restates original goals and success criteria
2. Each role evaluates against their domain criteria
3. Architect assesses accumulated tech debt and scalability risks
4. QA lists coverage gaps and regression risks

Round 2 — Rebuttals

Go back through the opening positions. Identify roles whose perspective was challenged, contradicted, or undermined by a later speaker. Those roles MUST respond (2–3 sentences each). Roles with nothing to add stay silent.

At least one rebuttal is required. If no role was challenged, the discussion was too shallow — dig deeper and surface a disagreement.

Common rebuttal patterns:

• PM responds after architect raises complexity concerns about PM's timeline
• Architect responds after engineer proposes a simpler alternative
• Designer responds after engineer pushes back on a UX proposal
• Domain expert responds after architect proposes something non-standard for the industry
• Any role responds when a later speaker mischaracterizes their position

Round 3 — Synthesis

PM synthesizes the discussion into a proposed direction:

• State the recommendation clearly
• Note dissent — which roles disagree and why
• Identify unresolved trade-offs for the user to decide
• Map the disagreement (borrowed from storm's contradiction map): name where roles clash, where they converge, and the blind spot — what no role raised that the brief actually needed. The blind spot is often the highest-value output; surface it as an Open Question rather than letting it stay invisible.

Mid-Discussion Role Changes

Adding a role mid-stream:

• If the user requests it during or after Round 1 → inject the new role at Round 2 (they respond to the existing opening positions in first person, 2–4 sentences)
• If requested during or after Round 2 → inject at Round 3 alongside the synthesis, and let the new role add one substantive insight the team missed
• If requested after the conclusion → append an "Addendum" section: introduce the role in 1 sentence, give them one substantive contribution, update the conclusion's Open Questions or Next Steps if warranted
• Never restart the discussion. Never re-run Round 1 for the existing roles. Do NOT regenerate the Team Assembly table — just add a one-line note: + @new_role (added mid-discussion at user request)

Removing a role mid-stream:

• Acknowledge in one line: "Dropping @role from the discussion."
• Preserve earlier contributions — do not erase their Round 1 position from the transcript
• If the removed role was the sole voice on a concern, surface that concern as an Open Question in the conclusion

Discussion Rules

1. Minimum 2 opposing perspectives per discussion. If all roles agree, dig deeper — unanimity usually means the discussion is too shallow. Look for hidden trade-offs, unexamined assumptions, or risks being glossed over. Exception: for teams ≤ 3 roles on a trivial scope, consensus is acceptable — note "consensus on approach" in place of the rebuttal round.

2. Contribute or pass. Every active role must either contribute a substantive opinion OR explicitly pass with a reason (e.g., "@senior_copywriter: Passing on this round — the API design discussion is outside my domain. I'll weigh in when we discuss error messages."). No filler contributions.

3. Stay in character. Each role reflects its domain expertise, natural biases, and blind spots as defined in references/role-personas.md. The PM pushes for speed. The architect pushes for quality. This tension is the point.

4. Be concise. 2–5 sentences per contribution unless the topic demands depth.

5. Surface trade-offs explicitly. When roles disagree, name the trade-off: "This is a [speed vs. quality / UX vs. security / scope vs. timeline] trade-off."

6. Flag unknowns prominently. Critical unknowns get a ⚠️ prefix.

Output Length Targets

Hard ceilings are enforceable, not aspirational. If you're over the ceiling you are padding, not adding value. Before shipping, check: am I restating, or contributing new signal?

What to cut first when over ceiling:

• Round 2 contributions that merely rephrase Round 1 — those aren't rebuttals, they're echoes
• Phase 1 signal rows the brief doesn't actually touch (one-line "detected signals" summary is enough — skip the full 13-row table unless the brief is ambiguous)
• Role-assembly justifications beyond one short clause per role
• Time / cost estimates on next steps unless the user asked for budgeting
• Persona flavor sentences without concrete substance — "as an architect I think about scale" adds nothing

What never to cut: the Conclusion (recommendation + decisions + open questions + trade-offs + numbered next steps), the Gap Check answers (but compressed to yes/no + role), and at least one real rebuttal with substance.

Pre-Write Word Budget (MANDATORY before Round 1)

Prose-only ceilings don't reliably bite — empirically, outputs overrun by 30–50% when only a ceiling is stated. Commit a budget before writing the discussion.

Trivial scope skips the Signals table and this Pre-Write Word Budget table itself (they alone consume ~200 words). Replace both with a single-sentence signal summary and skip the budget statement — the 600-word ceiling is your budget.

Hard rules:

1. State the budget at the top of your output, one line, visible. Include the Structured Plan line when @staff_engineer is active: Budget: signals 120 / team 180 / R1 450 / R2 220 / R3 230 / conclusion 280 / plan 400 = 1880 target (ceiling 1900). For trivial scope, skip the budget statement entirely — the 600-word ceiling is the budget.
2. Per-contribution cap during Round 1. No single role may exceed 80 words (discussion/planning), 120 words (building), or 50 words (trivial). If you're over, cut mid-write — don't "finish then revise."
3. Truncate as you go, not at the end. Re-editing to shrink rarely happens — write short the first time.
4. Round 1 is where most overruns happen. If Round 1 is over budget when you finish it, stop; remove the weakest full contribution rather than trim every role by a sentence.
5. When in doubt, favor the conclusion. Cutting a mid-discussion paragraph preserves more value than cutting the recommendation or next steps.

Phase 5: Conclude

Never end a discussion without a conclusion. The brainstorming is valuable context, but the user needs a clear synthesis to act on.

## Conclusion

### Recommendation
[The team's recommended direction. State it clearly. If roles disagree,
present the majority position and note the dissent — e.g., "The team
recommends X. @architect dissents, preferring Y because Z."]

### Decisions Made
- [Key decisions the team aligned on]

### Open Questions
- [Unresolved items that need more information or user input]

### Trade-offs Identified
- [Explicit trade-offs surfaced, with both sides stated. This subsection is REQUIRED — if no trade-offs surfaced, write "No material trade-offs identified" rather than omitting the heading.]

### Recommended Next Steps
1. [Highest priority — do this first]
2. [Second priority]
3. [Third priority]

Priority ordering is required for next steps. Don't just list — rank.

Structured Plan (when @staff_engineer is on the team)

When @staff_engineer is present, they author the Next Steps as a structured, agent-executable plan — not just a ranked list. The flat 1/2/3 list above stays as an index/summary; the structured plan below is the artifact an agent (or human) actually executes. Use this shape:

### Structured Plan

**Decisions locked**
- [Facts the team aligned on — scope, architecture, trade-offs resolved. An agent should treat these as givens.]

**Decisions deferred**
- [Items a human must decide before execution. Each item names the decider if known.]

**Assumptions**
- [What the plan assumes is true. Flag any that need verification before phase 1 begins.]

**Phase 1 — [name]**
- Goal: [one sentence]
- Files/modules touched: [concrete paths, not abstract areas]
- Acceptance criteria: [independently verifiable — e.g., "pnpm test passes", "endpoint returns 200 with shape X", "user can complete flow Y end-to-end"]
- Depends on: [prior phases or external decisions]

**Phase 2 — [name]**
- [same shape]

**Phase N — [name]**
- [same shape]

**Out-of-scope ring-fence**
- [Explicitly NOT in this plan. Prevents agent drift into adjacent work.]

**Risks flagged for human decision**
- [Points where the plan should pause for review rather than continue autonomously.]

Why the shape is fixed: agents executing plans fail on ambiguity, not on difficulty. The shape removes the common failure modes: unclear decisions, fuzzy acceptance criteria, scope creep, silent assumption-making.

Phased-Launch Variant (for regulated / high-uncertainty products)

When the team converges on "ship a narrow MVP then expand," use this variant for the Recommendation section — it's a common convergent pattern for regulated, safety-critical, or high-uncertainty domains (fintech compliance, health data, climate reporting, games with children) and naming it explicitly helps the user act on it:

### Recommendation (Phased)

**Phase 1 (MVP):** [Narrowest viable scope with full compliance / safety bar]
**Gating criteria → Phase 2:** [What must be true to graduate — user count, regulatory sign-off, calculation confidence, design validation]
**Phase 2:** [Next expansion]
**Deferred:** [What you're explicitly NOT doing yet, and why]

Use this when: the team surfaced credibility / regulatory / uncertainty risks as a central trade-off AND a smaller scope materially reduces those risks. Do NOT force this shape on simple features.

Post-Discussion Verification

After the discussion, verify:

Participation & quality:

• Every active role contributed at least one substantive opinion (or explicitly passed)
• At least 2 opposing perspectives or trade-offs were surfaced (if team > 4)
• Round 2 rebuttals surfaced at least one real pushback (not ceremonial)

Coverage & completeness:

• Every red flag in the brief was addressed by at least one role
• Gap Detection Pass questions (Phase 3.5) are all resolved — no silent skips
• Conclusion answers the user's actual question, not a tangential one

Structure:

• Conclusion section has: recommendation, decisions made, open questions, trade-offs, next steps
• Next steps are numbered and prioritized (1, 2, 3 — not a flat list)
• Team size within hard cap (≤12)
• Output length within target range for the scope (see Phase 4)

If any box is unchecked, fix it before returning the output to the user.

Phase 6: Deliverable Production (Sub-Agent Delegation)

After the 3-round discussion concludes, some scopes produce deliverables that benefit from parallel, focused work. Discussion rounds (1-2-3) always run in single-agent mode to preserve cross-role interaction. Sub-agents are only for deliverable production after the discussion concludes.

Coordination mechanics live in sub-agent-coordinator. Team-composer owns the when and who of delegation (the triggers below, role-level deliverable assignments). The sibling sub-agent-coordinator skill owns the how — briefing templates (Quick/Full), coordination patterns (fan-out, pipeline, specialist, review), spawning checklists, and trust-but-verify rules. When any trigger below fires, load sub-agent-coordinator alongside this skill. One invariant carries across both: no nested sub-agents — all spawning happens at the team-composer/coordinator level.

Trigger Table

How It Works

1. Discussion completes — all 3 rounds finish, conclusion is written
2. Check triggers — if any signal above matches, proceed to delegation
3. Brief sub-agents — load the sub-agent-coordinator skill and use its Briefing Templates section (Quick Brief for complexity 1–5, Full Brief for 6+). Each sub-agent gets:
   • The conclusion and decisions from the discussion
   • Their role's specific deliverable assignment
   • Constraints from other roles (e.g., "architect said no microservices")
4. Collect and integrate — coordinator merges sub-agent outputs into a unified deliverable

Platform Fallback

If your agent platform does not support spawning sub-agents, produce deliverables sequentially — one role at a time — referencing the discussion conclusion throughout.

Model Routing

Default: sub-agents inherit the orchestrator's model. No silent downgrading — the user chose a model for a reason.

For deliberate selection across capability tier, reasoning effort, and speed lane, see sub-agent-coordinator § Model Selection — Capability, Reasoning, Speed. That section defines the axes (low/standard/high · off/on · flex/standard/priority), defaults, and disclosure contract. When this skill spawns deliverable sub-agents (per the Phase 6 trigger table), the brief's Constraints section carries Tier: / Thinking: / Lane: lines per that contract.

Downstream consumers (e.g., the external cerby skill, https://github.com/sorawit-w/cerby) may provide opinionated task-to-tier mappings calibrated to their domain — defer to those mappings when present. Do not silently override sub-agent-coordinator's inherit-by-default behavior, and do not encode vendor-specific model strings (e.g., opus-4-6) in this skill — they rot across vendor releases.

Opinion Weighting

All roles have equal weight. No seniority-based weighting.

Every role earned its seat through Phase 2 scoring. Weighting opinions by "seniority" would introduce hierarchical bias and reduce the diversity that makes the team valuable.

The 3-round discussion structure already provides emergent quality filtering:

• Weak arguments get challenged in the rebuttal round
• Arguments that don't survive rebuttals carry less weight in synthesis naturally
• The PM synthesizes with dissent noted — the user sees which positions held up

This is better than prescribed weighting because it's evidence-based (arguments are tested against each other) rather than authority-based (some roles count more by fiat).

Do not implement role weighting. If a future contributor considers it, they should demonstrate that equal weighting is producing measurably worse outcomes first.

When NOT to Delegate

• scope=discussion or scope=review — these are conversation-only, no deliverables
• complexity=low or complexity=medium with scope=building — single-agent can handle it
• Team size ≤ 4 — overhead of delegation exceeds benefit

Future enhancement: As sub-agent support matures across platforms, the trigger thresholds may be lowered. The current triggers are conservative by design.

Phase 6.5: Optional External Audit (High-Stakes Only)

The 3-round discussion catches internal disagreements, but can't catch what the team isn't equipped to see. If the team is missing a critical role, no amount of rebutting surfaces the blind spot. Phase 3.5 Gap Detection reduces this risk, but for high-stakes projects you can add an independent audit for additional safety.

When to Trigger

An external audit runs as a fresh-context sub-agent review. It's expensive (extra round-trip + tokens) so trigger it only when the stakes justify it:

How It Works

1. Conclusion is complete — Phases 4-5 finish, Post-Discussion Verification passes
2. Brief the audit sub-agent with fresh context:
   • The full output (team assembly, discussion, conclusion)
   • The original brief
   • A list of "expected red flags" based on the brief (e.g., "game based on existing IP → must flag copyright")
   • A structured audit checklist (signal accuracy, role coverage, blind spots, conclusion quality)
3. Audit produces a report identifying gaps, blind spots, and risks the team missed
4. Coordinator integrates the audit findings — either updates the conclusion with the gaps, or notes them as "audit-flagged risks the user should review"

Audit Sub-Agent Brief Template

You are auditing a team-composer planning output for blind spots and gaps.

**Original brief:** [paste user's original request]

**Team-composer output:** [paste full Phase 1-5 output]

**Your audit criteria:**
1. Did the team include all roles that the brief clearly required? (check against Phase 3.5 Gap Det

…(truncated)