Team Build — Parallel Feature Implementation

Spawn an agent team where each teammate implements a different layer or module of a feature in parallel, with clear file ownership to prevent conflicts.

Usage

/team-build [feature description]

How to Execute

Step 1: Analyze the Feature

• Understand what needs to be built from $ARGUMENTS
• Identify the layers/modules involved
• Map out file ownership boundaries (critical — no overlap)
• Identify dependencies between layers
• If unclear, ask the user for clarification

Step 2: Design Task Breakdown

Split work so each teammate owns distinct files. Common patterns:

Cross-Layer Split (most common):

Module Split (for single-layer work):

For the Patina Engine project specifically:

Step 3: Spawn Team with File Boundaries

Critical: ALWAYS specify file ownership to prevent conflicts.

Template for each teammate:

You are the [role] teammate. Your job is to implement [specific piece].

Files you OWN (only you edit these):
- [path/to/dir/]
- [path/to/file]

Files you may READ but NOT edit:
- [shared files like Cargo.toml, package.json]

Dependencies:
- You depend on: [teammate X finishing Y]
- Others depend on you for: [interface Z]

Definition of done:
- [ ] Implementation complete
- [ ] All tests pass (`cargo test` / `pnpm test`)
- [ ] Send summary of changes to lead

Step 4: Task Dependencies

Create tasks with dependencies so blocked work waits automatically:

1. Data model / schema / types (no deps)
2. Core implementation (depends on 1)
3. Integration layer (depends on 2)
4. Tests (depends on 2, 3)
5. Documentation updates (depends on all)

Having 5-6 tasks per teammate keeps everyone productive.

Step 5: Quality Gates

• Require plan approval for architectural teammates
• Let implementation teammates proceed directly
• Lead reviews integration points after teammates finish
• Run full test suite before declaring done
• Shared files (like Cargo.toml, package.json) should only be edited by the lead after teammates finish

Step 6: If Lead Starts Implementing

If you notice the lead doing work instead of coordinating:

Wait for your teammates to complete their tasks before proceeding.

Model Recommendations

• Lead: Opus (architecture decisions, integration review, conflict resolution)
• Implementation teammates: Sonnet (saves tokens for straightforward coding)
• Architecture/design teammate: Opus (if included)

Anti-Patterns to Avoid

1. Two teammates editing the same file — guaranteed conflicts, always assign file ownership
2. Too many small tasks — coordination overhead exceeds benefit
3. Not enough context in spawn prompts — teammates don't inherit history
4. Lead doing implementation instead of coordinating — tell it to wait
5. Running unattended too long — check in, redirect failing approaches
6. Overscaling — 3 focused teammates outperform 5 scattered ones

Example Invocations

/team-build implement the resource UID cache system across engine crates
/team-build add WebSocket support with backend API + frontend client + tests
/team-build refactor physics pipeline into fixed-step lifecycle with tests
/team-build new gdphysics3d crate with rapier integration, scene hooks, and golden tests