team-lead

Team Lead — Synthesis Procedure

This is NOT a dispatched agent. These are instructions for the MAIN AGENT acting as Team Lead.

You have received three reports from the Architect, Tech Lead, and QA Engineer agents. You also have the original spec. Your job is to synthesize all of this into a concrete, ordered list of TDD tasks that an implementer can execute without ambiguity.

---

Synthesis Process

Step 1: Identify the Deliverables

From the spec, list every concrete deliverable: each new file, each modified file, each new API endpoint, each new component, each new test file. Cross-reference with:

• The Architect's component list and blast radius
• The Tech Lead's file structure table
• The QA Engineer's test strategy table

If any deliverable appears in the spec but not in the agent reports, investigate. Either the agents missed it or the spec includes something that does not require code changes (documentation, config, etc.).

Build the plan's ## Coverage Matrix before writing tasks:

• Spec-driven mode: one row per spec acceptance item, deliverable, or explicit constraint
• Inline mode: one row per goal, scope boundary, and user-stated constraint
• If an unapproved spec exists in inline mode, treat it as context only. Do not promote its IDs into the matrix as authority items.

Step 2: Determine Task Order

Tasks must be ordered so that:

1. Foundation comes first: types, interfaces, schemas, configuration
2. Core logic comes second: services, handlers, business rules
3. Integration comes third: controllers, routes, UI components that consume the core
4. Wiring comes last: imports, barrel exports, module registration

Within each layer, independent tasks should have no dependencies on each other. Dependent tasks must explicitly list their prerequisites.

Step 3: Size Each Task

Each task should take 2-5 minutes to implement. Use these guidelines:

Size indicator	Action
Task creates 1 file + 1 test file	Good size. Keep as one task.
Task creates 2-3 files + test files	Acceptable if the files are small and tightly coupled.
Task creates 4+ files	Too large. Split by responsibility: one task per logical unit.
Task modifies an existing file with complexity rank in top 10	Mark as complex. The QA Engineer's risk assessment applies.
Task involves only type definitions or interfaces	Mark as standard. These are low-risk.
Task involves cross-cutting concerns (auth, validation, error handling)	Mark as complex. These affect multiple code paths.