/tlc-spec-lean

name: tlc-spec-lean
description: 'Spec-driven feature work that freezes obligations instead of the plan: one human-reviewed plan with EARS criteria, path, entities, interface and one-way doors, then proof-backed checks, then build, then an independent Verifier. Use when the user says "tlc-spec-lean", "plan feature", "specify feature", "write the checks", "build this plan", or "verify work". Do NOT use for standalone design documents unattached to a feature, architecture decomposition analysis, or work that already has a task list or checklist to execute.'
license: CC-BY-4.0
metadata:
  author: Tech Leads Club - github.com/tech-leads-club
  version: '1.0.0'

Tech Lead's Club - Spec, Lean

Freeze the obligations. Free the plan. Prove it with someone who did not build it. Derived from tlc-spec-driven 3.3.0 (Felipe Rodrigues), tlc-plan, and tlc-implement.

┌──────┐   ┌────────┐   ┌───────┐   ┌────────┐
│ PLAN │ → │ CHECKS │ → │ BUILD │ → │ VERIFY │
└──────┘   └────────┘   └───────┘   └────────┘
 read it    obligations   yours       always

Four moves, two artifacts before code, one after. A human confirms **what** must be true and **how** it is being built in one document, and only then does any of it become an obligation with a proof attached. There is no task breakdown, and the plan carries no component catalogue: what is hard to reverse gets a one-way door with its literal shape, and everything reversible is decided while building and reviewed in the diff.

Why this shape

The dominant failure of a coding agent is not bad reasoning, it is a requirement that was read and never became an active obligation - and then a completion claim on top of it. The mitigation that measures well is a **small, frozen, external obligation set** plus a **verifier that is not the author**; a self-check reproduces the author's own blind spot. So this skill spends its budget on those two things and refuses to spend it on choreographing how the model works.

Two consequences worth stating up front, because they are what make this different from a conventional spec-driven flow:

• **Granularity is not quality.** Splitting a feature into fifteen one-file tasks buys

ordering, not correctness, and it costs a re-read of the process on every task. Proof coverage buys correctness.

• **A plan the model must obey competes with the obligations for attention.** Fields like

`Where`, `Tools`, `Depends on` are the model's job to decide, so they are not written down.

Critical rules

The pinned set. These hold even if no reference file is read, and they are the only rules that never scale down with the profile.

1. Every check is **one observable claim with a concrete value** plus the **proof** - the test or command whose exit code settles it. No proof, no check. 2. Tests assert what the checks say, 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. A genuinely wrong check is a stop-and-ask, not an edit. 4. Checks and `Test policy` rows are fixed once approved. In the design, `Landing`, `Relations` and `Surface` are additive - a door discovered while building gets a row before the code that closes it, and a row the user approved is never rewritten. `Flow` and `Impact` are neither: they are **kept true**, so a different path changes the hop in that path's commit. 5. The **Verifier is a fresh sub-agent**, dispatched by whoever holds the whole feature, never by a builder, over `<feature base>..HEAD` with **every** check. Never optional, never prompted, never the author. A builder finishes, reports, and stops. 6. **The profile is a floor and it is not a secret.** The verification report names it, or "no faults injected" reads exactly like forgetting to inject them. 7. The completion gate is a script, not a feeling: `validate_verification.py` must exit 0. 8. **Blast radius:** an approved spec authorizes local edits and local commits. `git push`, deploy, and production data changes need an explicit go-ahead for that action.

Profile

The project declares how much runs, in `AGENTS.md` or equivalent. Absent a declaration: `light`. Same three levels as `tlc-implement`, gated the same way, so moving between the two skills needs no second vocabulary.

## tlc-spec-lean

profile: light
budget: 150k

| Profile | Adds | Cannot catch | | --- | --- | --- | | `light` (default) | proofs run at `HEAD` with 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 recomputed, `Test policy` rows with a verdict each, one fault per assertion surface | a check that contradicts a binding source; a screen nobody built | | `ui` | binding sources opened and compared, per-screen enumeration of copy **and** arrangement | only spacing, colour and type weight, enumerated per screen |

Each step adds a **class of failure detected**, so a cheap profile is not a discount on the same product - read the right column before choosing it. Two things about `light` are worth saying out loud, because its own row says them and they are easy to skim past: it will not notice an enumerated set member that nobody proved, and it will not notice a test that passes under a wrong implementation. `standard` exists for exactly those two.

`ui` costs nothing on work with no interface: every screen step is conditional on a screen existing. A step whose input is empty costs a line, not a pass ("no set rows", "no binding source").

The `Coverage` join is **written** into `checks.md` at every profile - the join is what makes an omission structural, and that costs nothing at authoring time. What `standard` buys is the Verifier **recomputing** it from the authority over each set instead of reading the author's table b