Teamlead Coordination

Teamlead Coordination

This skill is the operating model for the Teamlead agent. It tells you how to run a Teamlead-led session the way it is meant to run: backlog-driven, multi-epic, recurring, with explicit verify-triage-fix chains and periodic analysis.

If you are the Orchestrator agent (bounded session, no teammates), load using-my-skills and executing-plans-with-subagents instead. They are orthogonal shapes and should not be mixed.

The user decides at session start whether the session is Teamlead-led or Orchestrator-led. Do not second-guess that choice.

Core Thesis

A Teamlead-led session is a recurring backlog loop, not a linear pipeline. The Teamlead owns the backlog and the high-level alignment across teammates. Teammates own one slice at a time and exit when done.

high-level spec (from user)
        |
        v
backlog teammate          -- research + prototype via own subagents, produce multi-doc backlog
        |
        v
backlog verifier teammate -- second pass on same artifact, improve and challenge
        |
        v
for each epic in backlog, one at a time:
        |
        +-> implementer teammate            -- owns one slice end-to-end (plan via subagent, implement, verify)
        +-> verify-triage-fix teammate      -- independent pass: verify, triage findings, fix
        +-> optional 2nd/3rd verify-triage-fix teammate(s)
        +-> if epic fundamentally broken: reject + spawn fresh implementer with carried knowledge
        |
        v
periodic analysis teammate (between epics) -- docs-vs-reality, manual high-level verification, infra gaps
        |
        v
teamlead updates backlog from analysis findings
        |
        v
next epic

For very big epics, the implementer slot can be multi-attempt + parallel worktrees + comparison + merge before the verify chain starts. This is the only place where Teamlead knowingly dispatches work that is not strictly independent across teammates — isolation is enforced by worktrees.

Teamlead ↔ Teammate ↔ Subagent Boundaries

A Teamlead that starts editing source code in many files is doing the Implementer teammate's job badly. Spawn the teammate instead.

Slice Contract

A slice is a self-contained medium-size delivery handed to one Implementer teammate. It is the unit of work the Teamlead dispatches.

Good slice examples:

• "Create and test a new feature: new page + endpoints + tests"
• "Bootstrap the testing infrastructure for the backend"
• "Refactor the auth module end-to-end and update affected tests"
• "Build the new billing flow with backend, frontend, and integration tests"

Bad slice examples (do not dispatch these):

• "Implement auth" — too broad, no acceptance criteria
• "Fix the failing test in tests/foo.py" — too small, use a subagent
• "Make the app production-ready" — vague, no shape

The Teamlead defines the slice boundary. The Teammate decides how to plan and execute inside the slice. The Teammate may decompose the slice into smaller subagent tasks.

Teammate Lifecycle

Teammates are one-shot by default in most environments. Assume:

• A Teammate starts, completes its assigned work, reports back, and exits.
• The Teamlead cannot ask follow-up questions to the same Teammate.
• A new Teammate cannot see the stopped Teammate's private context.

Therefore, every Teamlead → Teammate prompt must be self-contained for a fresh Teammate, and every Teammate → Teamlead report must be self-contained for the next Teammate the Teamlead spawns.

Spawning a Teammate

Each Teammate prompt should include:

The Teammate decides internal decomposition (subagents, plan, retries) on its own. Do not pre-decompose for it.

Teammate report

The Teamlead must receive enough to continue without re-reading the source. The Teammate decides what to put in based on the real case, but the minimum is:

• What was done — concrete changes, not vague summaries.
• What was verified — commands run, manual checks done, evidence paths.
• Open issues / risks — anything not finished, anything the next Teammate should know, anything the Teamlead should put back into the backlog.
• Recommended next move — which archetype of Teammate to dispatch next, or a recommendation to reject and restart the epic.

Do not lock a long rigid template. The Teammate picks the right level of detail for the case.

Knowledge hand-off

When the Teamlead spawns the next Teammate, it is the Teamlead's job to extract from the previous report the things the next one needs:

• Failed approaches and why they failed.
• Verified working approaches and what evidence backs them.
• Open questions that the next Teammate must resolve.
• Slice contract updates that emerged during the previous Teammate's work.

This is the "knowledge pass" move. It is what makes the verify chain non-redundant.

Default Teammate Archetypes

Use this list as defaults. The Teamlead may invent new archetypes when a task calls for them — these are not the only legitimate Teammate roles.

Common sense archetypes the Teamlead may also dispatch when warranted:

• Environment bootstrap (install browsers, tools, fixtures) — usually a subagent unless the bootstrap is large enough to need its own plan.
• Docs and ADRs update — usually a subagent unless the docs rework is its own epic.
• Release / launch — a Teammate per the existing release and launch skills.

Operating Model In Detail

Phase 1: Backlog creation

user provides high-level spec
   -> Backlog builder Teammate (research, prototype, multi-doc output)
   -> Backlog verifier Teammate (improve and challenge the same artifact)
   -> Teamlead reads both, locks the backlog, decides epic ordering

The output of this phase is a backlog — a project-local artifact the Teamlead owns for the rest of the session. Place it where the project convention suggests (often docs/backlog.md or a docs/backlog/ folder); the Teamlead picks the path and tells the user.

Phase 2: Per-epic loop

For each epic in the backlog, one at a time:

Implementer Teammate (slice owner)
   -> Verifier-triage-fixer Teammate
   -> optional 2nd / 3rd Verifier-triage-fixer Teammate
   -> if epic broken at the root: reject, spawn fresh Implementer with knowledge pass
   -> if epic solid: mark done, advance backlog

The Teamlead decides how many verify passes to run based on:

• Epic size and risk.
• Findings from the prior verify pass.
• Whether the prior Implementer's work touched shared state with other epics.

Two to three verify passes is the normal range for a big epic. One is enough for a small one. Zero is rarely correct.

Phase 3: Periodic analysis

Between epics, the Teamlead dispatches an Analysis Teammate that:

• Compares the current docs and backlog to actual project state.
• Manually verifies the highest-value end-to-end flows.
• Highlights infra and testing gaps that did not catch problems it found.
• Surfaces features the user asked for that have no test or no implementation.

The cadence is the Teamlead's call. A reasonable default: after every two epics, or before any "ship" gate, or whenever the user explicitly asks for drift check.

The Teamlead turns analysis findings into backlog updates and inserts new epics or slices as needed.

Phase 4: Complex-epic comparison flow (exception)

For very big/complex/ambiguous epics where a single Implementer attempt is too risky, the Teamlead may use a multi-attempt pattern:

spawn N Implementer Teammates in parallel worktrees (per git-workflow)
   -> comparison subagent reviews the N attempts
   -> merge Teammate integrates the best parts into the trunk
   -> Verifier-triage-fixer chain as usual

This is the only place where Teamlead knowingly dispatches work that is not strictly independent across teammates. Isolation is enforced by worktrees, not by domain separation. Keep N small (usually 2-3) and be honest about the merge cost.

Hard Rules For Teamlead

• Do not edit source code in many files. Spawn an Implementer Teammate.
• Do not debug problems end-to-end yourself. Spawn a focused Teammate or subagent.
• Do not run a long verification-fix loop yourself. It is the Implementer and Verifier-triage-fixer Teammates' job inside the slice.
• Do not silently replace the user's high-level direction with your own. Surface the conflict, ask or escalate.
• Do not skip the analysis Teammate indefinitely. Without it the backlog drifts away from reality.
• Do not over-decompose. A Teammate owns a slice. A subagent owns a step inside a slice. Do not spawn subagents for tasks that fit a slice.
• Do not let Implementer and Verifier Teammates run in the same worktree without a plan for what happens when both want to commit.
• Do not blindly trust a Teammate's "done" report. Inspect changed files and run integrated verification before advancing the backlog.

Skill Routing

For coding subagents inside a slice, always pass engineering-principles in the prompt.

Handoff At The End Of A Session

When the user closes the session or asks to stop, the Teamlead should leave:

• The backlog at its latest state, with epics marked done / pending / blocked.
• A short summary of where the next session should pick up, written for a fresh Teamlead to read cold.
• Any open Analysis findings not yet turned into backlog items, flagged.

This is what makes the next session low-friction. Without it, the next Teamlead spends the first hour re-deriving context.

Common Mistakes