Agent Config Adapter

---
name: Team Build
description: Lead breaks a feature into standalone sub-features, plans each, creates worktrees, and spawns teammates that implement and raise PRs independently. Use when user says "team build", "build with team", "implement feature across [surfaces]", "parallel build", or describes a feature needing multiple independent workstreams.
allowed-tools: Bash, Read, Write, Edit, Grep, Glob, Task, WebSearch, WebFetch, Skill, TodoWrite, Bash(gh:*), Bash(git:*)
---

# Team Build — Parallel Feature Development with Agent Teams

Lead decomposes a feature into standalone sub-features, plans each, creates
worktrees, and spawns one teammate per sub-feature. Each teammate implements
autonomously using `/startWork` and `/completeWork`, ending with a PR ready for
review.

## Trigger Phrases

- "Team build [feature]"
- "Build [feature] across [mobile/web/admin/cli]"
- "Implement [feature] with a team"
- "Parallel build: [sub-feature-1], [sub-feature-2], [sub-feature-3]"
- GitHub refs: "#42" with multi-surface or multi-feature scope

---

## LEAD RULES

The lead NEVER implements code. The lead:

1. Decomposes, plans, creates worktrees, spawns teammates
2. Monitors progress via task list
3. Resolves cross-feature issues via messaging
4. Produces final summary with PR links

Use **delegate mode** (Shift+Tab after team creation).

---

## PHASE 0: DECOMPOSITION

### Analyze the Feature

Read the feature description, GitHub issue, or user input. Break it into
**standalone sub-features** that can be built independently with no file overlap.

### Decomposition Patterns

| Feature shape | How to decompose |
|---|---|
| Multi-surface (backend + web + mobile + CLI) | One sub-feature per surface |
| Multi-module (auth + billing + notifications) | One sub-feature per module |
| Large single feature | Split by layer: data model, API, business logic, UI |
| Migration | Split by area: routes, models, tests, config |

### Validate Independence

For each pair of sub-features, check:

- Do they touch the same files? → If yes, merge them or re-split
- Does one depend on another's output? → Mark dependency, order accordingly
- Do they share new types/interfaces? → Extract shared types first (Phase 1.5)

Present decomposition to user:

```
## Feature Decomposition: {feature-name}

| # | Sub-feature | Scope | Dependencies | Estimated files |
|---|---|---|---|---|
| 1 | Backend API | src/api/, src/models/ | None | 5-8 |
| 2 | Web frontend | src/web/ | #1 (needs API contract) | 4-6 |
| 3 | Admin panel | src/admin/ | #1 (needs API contract) | 3-5 |
| 4 | CLI commands | src/cli/ | #1 (needs API contract) | 2-4 |

Shared setup: TypeScript types in src/types/ (done before teammates start)
```

**WAIT for user approval before proceeding.**

---

## PHASE 1: PLANNING

### Run `/codePlanner` for Each Sub-feature

```
/codePlanner {sub-feature-1-description}
/codePlanner {sub-feature-2-description}
/codePlanner {sub-feature-3-description}
```

This creates:

- `taskNotes/{sub-feature-1}/taskFindings.md`
- `taskNotes/{sub-feature-2}/taskFindings.md`
- `taskNotes/{sub-feature-3}/taskFindings.md`

### Optional: Research Teammate per Plan

For complex or unfamiliar sub-features (new library, new API surface, migration),
spawn a research teammate BEFORE planning:

```
Spawn a research teammate: "Investigate the best approach for {sub-feature}.
Check existing patterns in the codebase, relevant library docs, and known
pitfalls. Report findings — do not write any code."
```

Feed research findings into `/codePlanner` for a better plan.

---

## PHASE 1.5: SHARED SETUP (if needed)

If sub-features share types, interfaces, or config:

1. Lead creates these shared files directly (this is the ONE exception to
   "lead never implements")
2. OR spawn a single teammate to create shared foundations first
3. Commit shared setup before spawning parallel teammates

This prevents teammates from creating conflicting type definitions.

---

## PHASE 2: PLAN DIGEST & HUMAN CHECKPOINT

### Present Digests for ALL Sub-features

For each `taskFindings.md`, extract signals in this format:

---
**Plan Digest: {sub-feature-name}**

| Signal | Value |
|--------|-------|
| Complexity | Score and summarized reason |
| Gaps found | {list} OR "None" |
| Edge cases | {list} OR "None" |
| Potential bugs | {list} OR "None" |
| Simplifications possible | {yes/no} + brief explanation |
| External deps added | {list} OR "None" |
| Highest risk | {single riskiest part} |
| Files touched | {count}: {list} |
| New abstractions | {count}: {names} OR "None" |
| Existing code modified | {Yes — what / No — additive only} |

**Rejected alternatives:** {alternatives or "None mentioned"}

**Watch for:** {flags or "Nothing unusual"}

---

### Cross-Plan Validation

After individual digests, check across all plans:

- **File conflicts**: Do any two plans touch the same file? → Flag it
- **Type mismatches**: Do plans assume different shapes for shared data? → Flag it
- **Dependency gaps**: Does plan B assume an API that plan A doesn't define? → Flag it

Present all digests + cross-plan findings together. Then:

```
Ready? [g]o · [t]weak: {feedback} · [r]eject/show full plan
```

**WAIT for user input.**

| Input | Action |
|---|---|
| `g`, `go`, `yes` | Proceed to Phase 3 |
| `t: {feedback}` | Update plans per feedback, re-digest, present again |
| `r`, `reject` | Display full taskFindings.md files, wait |
| `stop`, `cancel` | Abort |

---

## PHASE 3: WORKTREE SETUP

### Create Worktrees

Use the `/tree` command to create isolated worktrees:

```
/tree feat/{sub-feature-1},feat/{sub-feature-2},feat/{sub-feature-3}
```

This creates:

- `trees/feat/{sub-feature-1}/` → branch `feat/{sub-feature-1}`
- `trees/feat/{sub-feature-2}/` → branch `feat/{sub-feature-2}`
- `trees/feat/{sub-feature-3}/` → branch `feat/{sub-feature-3}`

### Copy Task Notes to Worktrees

Each worktree needs access to its plan:

```bash
# Copy task notes into each worktree
cp -r taskNotes/{sub-feature-1} trees/feat/{sub-feature-1}/taskNotes/{sub-feature-1}
cp -r taskNotes/{sub-feature-2} trees/feat/{sub-feature-2}/taskNotes/{sub-feature-2}
cp -r taskNotes/{sub-feature-3} trees/feat/{sub-feature-3}/taskNotes/{sub-feature-3}
```

---

## PHASE 4: SPAWN TEAMMATES

### Create Agent Team

Create an agent team. One teammate per sub-feature.

### Teammate Spawn Template

For each sub-feature, spawn a teammate with this prompt:

**Teammate: `builder-{sub-feature-name}`**

```
You are implementing the {sub-feature-name} sub-feature for {feature-name}.

Your worktree: trees/feat/{sub-feature-name}/
Your plan: taskNotes/{sub-feature-name}/taskFindings.md

STEPS:
1. cd to your worktree directory
2. Read your plan at taskNotes/{sub-feature-name}/taskFindings.md
3. Run: /startWork {sub-feature-name}, mode: autonomous
   - This handles branching, implementation, and checkpoints
4. When startWork finishes, run: /completeWork {sub-feature-name}, mode: autonomous
   - This validates, tests, and commits
5. Create a PR:
   gh pr create --title "{sub-feature-name}: {short description}" --body "Part of {feature-name}"
6. Report back to lead with the PR URL and a summary of what was built

RULES:
- Stay in your worktree. Do not touch files outside it.
- Follow existing codebase patterns.
- Use /conventional-commit for all commits.
- If you need something from another sub-feature (types, API), message the lead.
- If you are blocked, message the lead immediately — do not guess.
```

### Dependency Ordering

If sub-features have dependencies (e.g., frontend depends on backend):

- Spawn the dependency first (e.g., `builder-backend`)
- Set other teammates' tasks as blocked in the shared task list
- When `builder-backend` completes and reports, unblock the dependent tasks
- Message dependent teammates: "Backend is done. API contract is at {path}. Proceed."

---

## PHASE 5: MONITOR & COORDINATE

### Lead Responsibilities During Build

While teammates work:

1. **Watch the task list** — check for stalled or completed tasks
2. **Handle cross-feature requests** — if a teammate messages asking for a type
   or API detail, relay from the relevant teammate
3. **Resolve conflicts** — if two teammates discover they need the same file,
   intervene and reassign
4. **Nudge stalled teammates** — if a teammate hasn't progressed, message them

### When a Teammate Finishes

1. Teammate reports PR URL + summary
2. Lead records it in the tracking table
3. Lead checks if dependent tasks can now unblock
4. If all teammates done → proceed to Phase 6

### If a Teammate Fails

- If fixable: message the teammate with guidance
- If stuck: shut down the teammate, spawn a replacement in the same worktree
- Accept ~10-20% failure rate as normal (per Boris Cherny)

---

## PHASE 6: SYNTHESIS & SUMMARY

After ALL teammates are done, lead produces:

```
## Team Build Complete: {feature-name}

### PRs Ready for Review

| # | Sub-feature | Branch | PR | Status |
|---|---|---|---|---|
| 1 | Backend API | feat/backend-api | #201 | Ready |
| 2 | Web frontend | feat/web-frontend | #202 | Ready |
| 3 | Admin panel | feat/admin-panel | #203 | Ready |
| 4 | CLI commands | feat/cli-commands | #204 | Ready |

### Cross-feature Notes
- {any coordination issues encountered}
- {shared types/interfaces that were created}
- {dependency ordering for merge: merge #201 first, then others}

### Recommended Merge Order
1. #201 (backend) — no dependencies
2. #202, #203, #204 — depend on #201, can merge in any order after

### Known Issues / Follow-ups
- {anything teammates flagged}
```

---

## PHASE 7: CLEANUP

1. Shut down all teammates
2. Clean up the team
3. Worktrees remain for user to review PRs
4. User merges PRs in recommended order
5. After merge, user runs: `/tree clean feat/{sub-feature-1},feat/{sub-feature-2},...`

---

## SIZE GUARDRAILS

| Feature scope | Team? |
|---|---|
| Single file change | No — use `/sandbox-dev` or `/dev-work` |
| Single module, < 5 files | No — use `/sandbox-dev` |
| 2 independent sub-features | Maybe — 2 teammates if truly independent |
| 3+ independent sub-features | Yes — team build |
| Multi-surface feature | Yes — one teammate per surface |

---

## ANTI-PATTERNS

**DO NOT:**

- Let lead implement code (delegate mode only, except shared setup in Phase 1.5)
- Spawn teammates before worktrees are created
- Skip the cross-plan validation in Phase 2
- Let two teammates work in the same worktree
- Skip copying taskNotes into worktrees
- Forget to set task dependencies for dependent sub-features
- Let teammates push to main — they create PRs to their feature branch

**DO:**

- Validate sub-feature independence before spawning
- Use `/tree` for worktree creation
- Use `/codePlanner` for planning (lead runs this)
- Use `/startWork` + `/completeWork` inside teammates (autonomous mode)
- Copy taskNotes into each worktree
- Handle dependency ordering via task list blocking
- Produce a clear summary with PR links and merge order
- Clean up teammates before cleaning up the team

No companion files

Add companion files to enhance this skill