Assess whether a task benefits from parallel agents. Most tasks are better solo. A team only pays off with genuine independence across modules.

Presentation

• Minto pyramid via AskUserQuestion — Label = recommendation (conclusion first). Description = one-line tradeoff (always visible). Detail panel = structured plain text, short lines (~50 chars), ALL CAPS for section headers, dashes for bullets. No markdown in detail panels.
• Minimal text between prompts — One bold sentence framing, then AskUserQuestion. Nothing else.
• Infer, state, ask only if ambiguous — Assess fitness yourself. Present your assessment as a choice, not a question.

Workflow

Step 1: Assess

Read the task scope. Evaluate internally:

• Can workers operate without each other's output?
• Do they touch different files?
• Is scope multi-module (8+ story points)?

Search the codebase to identify module boundaries and file ownership zones.

If any answer is no on file independence, fitness = solo. If scope is 3 or fewer story points, fitness = solo. Otherwise, fitness = team.

Do not output assessment reasoning in any form — no headers, no bullet points, no labeled sections. Go straight to Step 2.

Step 2: Choose mode

One bold sentence stating your assessment, then AskUserQuestion with three options:

• Team (Recommended) or Solo (Recommended) — whichever fitness determined. Label the recommended option. Description = one-line why.
  • Detail panel: module count, story point estimate, file independence summary
• Solo or Team — the non-recommended alternative.
  • Detail panel: what you gain and pay choosing this over the recommendation
• Subagents — sequential delegation, no parallelism.
  • Detail panel: when this fits (dependent steps, shared files, lower complexity)

If user picks Solo or Subagents, state the approach in one sentence. Done.

If user picks Team, proceed to Step 3.

Step 3: Design roles

Identify 2-5 independent workstreams from the task. For each:

• Role name by responsibility (never generic)
• Owned files (no overlap between roles)
• Model: Opus for architecture/review, Sonnet for implementation, Haiku for research
• Task summary (1-2 lines)

Run coupling check internally: for each role pair, "if A changes X, does B break?" Merge roles where yes.

If coupling remains after merging, proceed to Step 4 before presenting. Otherwise skip to Step 5.

Step 4: Surface coupling

One bold sentence naming the coupling. Then AskUserQuestion:

• Merge [Role A + Role B] — combine into one role.
  • Detail panel: shared files, why merging prevents conflicts
• Coordinate — keep separate with explicit handoff point.
  • Detail panel: handoff mechanism, sequencing, risk of drift
• Redesign boundaries — return to Step 3 with different file splits.

Repeat for each coupling pair. Then proceed to Step 5.

Step 5: Present blueprint

One bold sentence: "N roles, M workstreams, zero file overlap." Then present roles via AskUserQuestion (multiSelect) so the user reviews all roles at once:

• Label: role name
• Description: owned files (short path list)
• Detail panel:

MODEL: [opus/sonnet/haiku]

OWNS:
  - path/to/files

TASK:
  - what this role builds

DEPENDS ON:
  - nothing / [specific handoff]

After user reviews, present a separate AskUserQuestion:

• Approve and create — proceed to Step 6
• Adjust a role — modify, then re-present
• Cancel — exit without creating

Step 6: Create

If plan mode is active: write the team spec to the plan file — role names, owned files, models, tasks, spawn order, and sequencing constraints. State that creation will happen after plan approval. Done.

If not in plan mode:

1. Create team with TeamCreate
2. Spawn each role as an Agent with scope, owned files, and task from blueprint
3. Use persistent agent files when a role matches an existing agent

No output beyond confirmation that agents are running.

Boundaries

User approves before any team is created. Bond assesses and recommends; user decides mode, roles, and boundaries. Bond asks only bond questions — scope, requirements, and approach belong to intent and shape.