team-implement

/team-implement

You are orchestrating parallel task implementation using agent teams. Each teammate owns independent tasks and follows strict TDD.

---

Input

You need the task list from /tasks. If it is not in context:

$ARGUMENTS

If $ARGUMENTS is empty and no task list is in context, ask the user to provide the tasks.

---

Step 1 — Analyze task dependencies

Before creating the team, analyze the task list:

1. Identify which tasks are independent (touch different files, no shared state)
2. Identify which tasks have dependencies (must complete before others can start)
3. Group independent tasks into sets that can run in parallel

Critical rule: Two teammates must NEVER edit the same file. If tasks share files, they must be sequential — assign them to the same teammate or set up task dependencies.

---

Step 2 — Determine team size

Based on the analysis:

• N independent task groups → min(N, 5) teammates
• Each teammate should have 3-6 tasks
• If all tasks are sequential, do NOT use a team — use /implement instead

If fewer than 3 tasks can run in parallel, recommend /implement instead and ask the user to confirm.

---

Step 3 — Create the implementation team

Create an agent team with N teammates to implement tasks in parallel.

Each teammate must:
1. Follow strict TDD: Red → Green → Refactor for each behavior
2. Run tests after each cycle
3. Only work on their assigned files — never touch files owned by another teammate
4. Report completion of each task

Spawn prompt for each teammate

Each teammate receives:

• Their assigned tasks (numbers, titles, acceptance criteria)
• The files they own (explicit list — no overlap with other teammates)
• The project's test command and build command
• The TDD rules (non-negotiable):
  1. Never write production code before a failing test
  2. Never move to the next behavior while any test is red
  3. Never skip refactor if cleanup is needed
  4. Never comment out, skip, or empty a test

Set up task dependencies

If task B depends on task A:

• Assign both to the same teammate (preferred), OR
• Set task B to depend on task A in the shared task list — it won't be claimable until A completes

---

Step 4 — Monitor and steer

While teammates work:

1. Watch for task completions in the shared task list
2. If a teammate gets stuck, review their progress and provide guidance
3. If a teammate finishes early, they self-claim the next unassigned task
4. If tests fail across teammates (shared test suite conflict), pause and resolve

Handling conflicts

If two teammates accidentally affect the same test suite:

Pause all teammates. Review the conflict. Reassign tasks to eliminate
the overlap, then resume.

---

Step 5 — Final verification

After all teammates report completion:

1. Run the full test suite from the lead:

# Run the full test suite

2. Run the build:

# Run the build

3. Check for unintended changes:

git diff --stat

Report

Team Implementation Complete
  ✓ Tasks: N/N complete
  ✓ Teammates: N (all shut down)
  ✓ Tests: N passing, 0 failures
  ✓ Build: clean
  ✓ No file conflicts detected

Ready for: /review or /team-review

If any tests fail, diagnose whether it's a merge conflict between teammates' work or a genuine bug. Fix before reporting success.

---

Step 6 — Clean up

Ask all teammates to shut down, then clean up the team.

---

When to use /team-implement vs /implement

Situation	Use
1-2 tasks or highly sequential work	/implement
3+ independent tasks touching different files	/team-implement
Tasks with heavy interdependencies	/implement
Large feature with clear module boundaries	/team-implement
Quick bug fix	/implement
Multi-service or multi-layer changes	/team-implement

---

Gotchas

These are common failure modes during parallel implementation. Watch for them:

• File ownership violations. The most common and most destructive failure. Teammate A adds a helper to utils.ts; Teammate B also adds a helper to utils.ts. Result: merge conflict, wasted work. Audit file assignments before spawning — if two teammates share ANY file, restructure.
• Shared test suite conflicts. Even if teammates own different source files, they may share test infrastructure (fixtures, factories, test helpers). If Teammate A modifies a shared fixture, Teammate B's tests may break. Assign shared infrastructure to one teammate.
• Teammates diverging on conventions. Teammate A names functions handleX, Teammate B names them processX. Without alignment, the codebase becomes inconsistent. Include explicit naming conventions in each teammate's prompt.
• Not running the full suite at the end. Individual teammates test their own code, but integration across teammates' work is only verified by the lead's final test run. Skipping this step means shipping untested interactions.
• Too many teammates. 3 teammates each doing 4 tasks is better than 6 teammates each doing 2 tasks. The coordination overhead of message passing and file ownership tracking scales with team size.

---

Important constraints

• File ownership is sacred. Two teammates must never edit the same file. Violations cause merge conflicts and wasted work.
• TDD is non-negotiable. Every teammate follows Red → Green → Refactor. No exceptions.
• Run the full suite at the end. Individual teammate tests passing does not guarantee integration. The lead must verify.
• Do not ship from this skill. Output is ready for /review or /ship, not a PR.
• Clean up the team when done. Do not leave orphaned teammates.