/tlc-implement

name: tlc-implement
description: 'Implement a work already planned: extracts a checklist, builds it, and proves every check with an independent verifier. Use when the user says "extract a checklist", "build this ticket", "implement this spec", or "tlc-implement". Do NOT use when nobody has decided what to build, or to design the work.'
license: CC-BY-4.0
metadata:
  author: Tech Leads Club - github.com/tech-leads-club
  version: 0.1.0

TLC Implement

Extract the checks. Build. Prove each one, independently.

EXTRACT ─────────→ BUILD ─────────→ VERIFY
(one checklist)    (your call)      (fresh agent)

The thinking already happened somewhere else. Your job is to lose nothing from it, then prove what you built. **How** you build is yours - no phases, no task list, no step-by-step.

Profile

The project chooses how much of this runs, in its `AGENTS.md` or equivalent:

## tlc-implement

profile: standard
handoff: on

`profile` is one of `light`, `standard`, `ui`; `handoff` is `on` or `off`, and absent it is `on`. A batch packs whole slices up to **150k tokens** of estimated reading; a project on a smaller window overrides that with `handoff: on, budget 90k`. Which slices land in which batch is not configured - that is decided per feature, from the slices in front of you, and written down before any code.

| Profile | Adds | Cannot catch | |---|---|---| | `light` (default) | proofs batched at `HEAD`, each named test shown to exist and run, one located assertion per check, level and sampling gaps, `Swept existing` re-read | a set member with no proof; a test that would pass under a wrong implementation | | `standard` | the `Coverage` join, `Test policy` rows with a verdict each, one fault per assertion surface | a check that contradicts the design; a screen nobody built | | `ui` | binding sources opened and compared, per-screen enumeration of copy **and arrangement**, the designed-screens row - [screens.md](references/screens.md) | **only** spacing, colour and type weight, enumerated per screen - never layout, which a selector reaches and which is checked like anything else |

Each step adds a **class of failure detected**, so read the right column before choosing: the cheap profile is not a discount on the same product. Absent a declaration, `light` - a review nobody runs because it outlasts the build protects nothing, so the default is the one that gets run rather than the one that catches most.

Under `standard` or `ui`, read `references/test-policy.md` when writing Coverage and Test policy rows. Under `light` skip that file.

**A step whose input is empty costs a line, not a pass.** The `Coverage` join has nothing to recompute where the checklist declares no set; the `Test policy` verdicts need that section to exist; step 1 needs a source marked binding. Say "no set rows" and move on - working through an empty step is how a small feature ends up paying a large feature's review.

`ui` costs nothing on work with no interface, because every screen step is conditional on a source marked binding; a product repo can set it once and stop thinking about it.

**The profile is a floor and it is not a secret.** The verification report names it, or "no faults injected" reads the same as forgetting. Where the profile looks too thin for the feature in hand, say so in one line and let the user raise it - doing more than the profile in silence costs the predictability that made it worth declaring.

`handoff: on` is the default and governs the build alone: `off` keeps the whole build in one agent, and what that changes is in *When one agent is not enough*. It does not reach the Verifier, which is a separate agent because the author cannot check their own work rather than because the build ran long.

Critical rules

1. Every check names its **proof**: the test or command whose exit code settles it. No proof, no check. 2. Tests assert what the checklist says, never what the code happens to do. Never write a test by reading the implementation. 3. Never weaken an assertion, delete a test, or skip one to make a suite pass. If a test is genuinely wrong, stop and ask. 4. The checks and the test-policy rows do not change while you build: once written they are the bar you build under, not a position to argue against, and lowering either is renegotiation with the user, visible in the diff. `Landing` is the exception, and it is additive - a door you discover while building gets a row, never a deletion. 5. The **Verifier is a fresh sub-agent**, never the author, never optional, never waiting to be asked. It is dispatched by whoever holds the whole feature, after the **last batch** has landed - never by a build agent, and never as a child of one. A build agent never spawns another agent at all. This is what keeps "done" from being a self-report. 6. **Blast radius:** an approved checklist authorises local edits and local commits. `git push`, deploy and production data changes need an explicit go-ahead.

Extract

Read the source completely first - ticket, PRD, RFC, thread. Then walk the codebase around what it touches, so the checks land on real paths and reuse what exists.

**Refuse rather than guess.** Three things must be true before you write the checklist:

• every claim has a **nameable proof** - if you cannot say which test would settle it, it is too vague to write down
• every claim has a **concrete value** - a status code, a field, a bound; never "gracefully", "properly" or "fast"
• the boundary is stated - you can say what is explicitly out

Under `profile: ui` a screen carries a fourth requirement - the design is a **binding** source and its concrete values belong in the checks - and the whole of it lives in [screens.md](references/screens.md). Under `light` or `standard` skip that file entirely.

Missing one is normal and asking is cheap. Proceeding on a guess is not: if it is still unclear after asking, name what is missing and stop there. A vague check becomes a vag