Team Work — Fan Out a Session Without Breaking It

Most working sessions end with a pile of loosely-related things the user wants done. Do them serially and you wait. Fan them out naively and you get merge conflicts, wasted opus runs on trivial work, and parallel agents stepping on the same files.

This skill reads the conversation, decomposes it into atomic tasks, assigns each a model tier and the right specialist subagent, and groups them into waves that can actually run in parallel.

When to Use

Use this skill when you have a backlog of loosely-related work from the current session and want to fan it out across agents. Trigger phrases include "team this up", "use a team", "use agent teams", "delegate this", "split this work", "parallelize this", "fan this out", "divide and conquer", or an explicit /team-work. Also useful when a task is big and you want help farming it out.

Why This Exists

Parallel fan-out looks like free speed until the second run writes to the same file as the first, or the architecture task gets a haiku, or four independent workers all decide they need to read CLAUDE.md from scratch. The skill exists to eliminate the three failure modes that happen when an enthusiastic orchestrator spawns agents without thinking:

1. Model mismatch. Opus on a rename is waste; haiku on architecture is theatre.
2. Shared-file collisions. Two agents editing SomeFile.swift in parallel is a merge conflict waiting for you to clean up.
3. Ignored specialists. A generic agent re-deriving domain context another subagent already carries is expensive and worse.

The skill's job is to turn "here's a bunch of stuff" into a small, honest plan — small enough to scan in ten seconds, honest about dependencies, and explicit about which agent handles what.

Workflow

Phase 1: Extract JTBD

Read the conversation. List every concrete deliverable the user has expressed wanting. Be specific — each item names a file, a feature, a deliverable. Not a theme.

Bad: "Improve the dashboard" Good: "Add empty-state card to the Base tab streak section"

If the session is genuinely ambiguous, ask one clarifying question. Never interrogate.

Phase 2: Decompose into atomic tasks

A task is atomic when:

• A single agent can own it start-to-finish
• It has a clear "done" signal — file saved, test passes, answer returned
• It doesn't need coordination with another in-flight task

Split anything bigger. Merge tiny tasks that touch the same area — the overhead of spawning an agent isn't free. The cost of a cold-start matters.

Phase 3: Assign tier and model

Bias cheaper when uncertain — haiku failing fast beats opus doing trivial work. But don't send opus-shaped problems to sonnet. The tiers exist because the work is actually different.

Phase 4: Pick the right subagent

Before defaulting to general-purpose, check the available subagent types. Specialists carry domain context a generic agent would have to re-derive from zero.

1. Scan the Agent tool's subagent_type list.
2. Match on domain — BJJ content to the bjj-* family, iOS/SwiftUI to ios-swift-expert, data pipelines to bjj-data-engineer-*, UI reviews to grapla-ui-reviewer, broad exploration to Explore, planning to Plan.
3. Simple tasks don't need specialists. A haiku-tier lookup runs fine on general-purpose. Specialists earn their seat when domain nuance actually matters.
4. Respect the agent's own pinned model preference unless the task clearly warrants an override.

If nothing fits, use general-purpose with the chosen tier.

Phase 5: Build dependency waves

Group tasks into waves. Inside a wave:

1. No task depends on another in the same wave.
2. No two tasks edit the same file. If they do — even if logically independent — split them across waves. Merge conflicts from parallel agents are painful to unpick.
3. Read-only tasks are always safe to parallelize with each other and with writes, as long as they don't need the writes' output.

A single-task wave is fine when one thing has to land before everything else.

Phase 6: Present the plan

# Team plan: <short title>

## Tasks
- **T1** — <goal>. Tier: S/M/L. Model: haiku/sonnet/opus. Agent: <subagent_type>. Files: <paths/globs>. Deps: none | T?, T?
- **T2** — ...

## Waves
- **Wave 1** (parallel): T1, T3, T5
- **Wave 2** (after W1): T2, T4
- **Wave 3** (after W2): T6

## Notes
<anything the user should flag or override before spawning>

Tight. A briefing, not a dissertation.

Phase 7: Spawn

Three modes based on how confident the plan is:

When in doubt, confirm. The cost of pausing is a sentence. The cost of a bad fan-out is wasted runs and broken state.

When spawning:

• All tasks in a wave in one message, parallel Agent calls.
• Wait for the wave to finish before the next. Foreground is fine for most; background only when tasks are genuinely independent and long.
• Each agent's prompt is self-contained — it won't see the conversation. Include what to do, why it matters, file paths with line numbers, constraints from CLAUDE.md / CODESTYLE.md that apply, expected output shape, and a length cap when useful.
• Don't write "based on your research, implement it." Push concrete instructions, not synthesis onto the agent.

Between waves, report what landed and any surprises before launching the next.

Guardrails

• Never spawn destructive actions in parallel without confirmation. DB migrations, git push, force-pushes, deletions, external API calls with side effects. Those get their own wave and explicit sign-off.
• Respect the project's git flow. Most projects don't allow direct pushes to main. Fan-outs land on feature branches.
• If agents need to write to overlapping areas, serialize them. Parallel edits to the same file end in tears.
• Don't spawn agents for trivial work you can do inline faster. A single-file edit doesn't need a subagent — the cold-start cost outweighs the parallelism.
• Stay inside available agent types. The Agent tool lists them; don't invent names.

Example

A session has discussed three things: adding an empty-state to the Base tab streak card, renaming StreakService to StreakTracker across the iOS code, and writing a validator for a new position data field.

# Team plan: Base tab streak + data validator

## Tasks
- **T1** — Rename StreakService → StreakTracker across grapla/. Tier: S. Model: haiku. Agent: general-purpose. Files: grapla/**/*.swift. Deps: none.
- **T2** — Add EmptyStateCard to Base tab streak section when no sessions logged. Tier: M. Model: sonnet. Agent: bjj-ios-engineer-inherit. Files: grapla/Features/App/Views/BaseTab*.swift. Deps: T1.
- **T3** — Add Zod validator for new `lever_points` field in position schema. Tier: M. Model: sonnet. Agent: bjj-data-engineer-inherit. Files: data/schemas/seed-models/position/enrichment-fields.ts. Deps: none.

## Waves
- **Wave 1** (parallel): T1, T3
- **Wave 2** (after W1): T2

## Notes
T2 waits on T1 because the streak view references the renamed type. T3 is independent of the iOS work.

Wave 1 goes out as two parallel Agent calls in one message. Wave 2 spawns after both come back clean.

Tone

You're the team lead who's been around long enough to know that naive parallelism costs more than it saves. You write plans people can actually read. You push back on sending opus to do haiku work and on sending haiku to do opus work. You'd rather spend thirty seconds writing a dependency note than an hour unpicking a merge conflict from two agents that should never have run in the same wave.

You're biased toward action, but you're honest about the cases where serializing is faster than parallelizing — and when a problem shouldn't be fanned out at all.