DOCS · REFERENCE · AGENTS · ORCHESTRATION
01 / TL

Tech Lead

Orchestration

Full-stack orchestrator. Breaks tasks down, delegates to specialists, rolls up the result.

Role

Tech Lead sits in the orchestration tier. Coordinates execution across the build phase.

Lifecycle stages

  • Plan
  • Build
  • Ship

Source

The agent's identity — system prompt, model, behavior — is defined in markdown at bluminal/lumenai/blob/main/plugins/synthex/agents/tech-lead.md.

Last modified:

How the Tech Lead actually runs

The Tech Lead is the agent next-priority/synthex:next-priority spawns once per worktree. It is the only agent whose context spans an entire task end-to-end — every other agent that runs during build is delegated to by the Tech Lead and scoped to one slice of the work.

A Tech Lead instance does, in order:

  1. Read the task. Parses the assigned plan task — title, description, dependencies, acceptance criteria with their type tags ([T] / [H] / [O]).
  2. Pre-work search. Greps the codebase for existing implementations relevant to the task so the Tech Lead doesn't reinvent something already in the tree.
  3. Plan the slice. Decides which specialists the task needs. A pure-frontend task pulls in the Lead Frontend Engineer; a security-sensitive change pulls in the Security Reviewer alongside the Code Reviewer; a Terraform change pulls in the Terraform Plan Reviewer.
  4. Implement, then review. The Tech Lead drives implementation, then runs the configured reviewer roster in the reviewer pipeline. Findings at high or critical block merge until addressed.
  5. Write the tests. For every [T] acceptance criterion, the Tech Lead writes (or extends) a test that proves the criterion. The test name and file path are recorded back in the plan alongside the done status.
  6. Surface [H] items. For every [H] criterion, the Tech Lead emits a structured summary for the orchestrating next-priority/synthex:next-priority run to present via AskUserQuestion. The Tech Lead does NOT mark the task done until the user approves.
  7. Hand back. The orchestrator merges fast-forward into main once the gates clear.

What it does not do

  • Cross task boundaries. A Tech Lead instance is scoped to one task in one worktree. It cannot see other in-flight tasks — that's by design (parallel work is isolated; see Parallel execution).
  • Skip pre-commit hooks. If a hook fails, the Tech Lead investigates and fixes the underlying issue rather than bypassing it. --no-verify is forbidden.
  • Mark work done without tests. A [T] criterion without a linked, passing test is sent back, no exceptions.
  • Approve [H] criteria itself. Only the user can.

Common modes

The Tech Lead's behavior shifts based on task complexity:

  • S complexity — typically 1–2 file edits, single specialist (often just the code + security reviewers). The Tech Lead implements and reviews itself.
  • M complexity — multi-file changes, often a frontend + backend pair. The Tech Lead delegates to a domain specialist (Lead Frontend Engineer for UI; the Architect for cross-cutting infrastructure) before running reviewers.
  • L complexity — wide changes that often warrant a sub-plan. The Tech Lead can recommend splitting the task into smaller ones rather than executing as-is — that recommendation comes back as a blocker on the original task.

When you'd use the Tech Lead directly

You normally don't — next-priority/synthex:next-priority wraps it. But the Tech Lead is addressable as a sub-agent if you write your own command that needs orchestrated implementation of a single, scoped task. See authoring commands for the delegation pattern.