Where are you starting from?

I'm evaluating.

You've heard of LID and you want to know if it's for you. The frame that fits: a structured way to write what your coding agent compiles — your design at a few levels of detail, from broad direction down to the granular claims tests verify. Your time goes into the design docs; the agent writes the specs, tests, and code from those.

The fastest loop: skim the HLD for the framing, skim the README for the mechanics, try the quickstart for the feel. Twenty minutes and you'll know.

The HLD names the problem (agents guessing at what you meant), the reframe (LID as a structure for the English you give your agent), the mechanisms (specs that pin intent down, greppable IDs, tests written before code), and the adoption modes. The examples page links to three projects — one clean and minimal, one complete and clonable, one real and messy. The complete one, portfolio-tracker, is the claims made checkable: clone it and the full arrow — design docs through @spec-cited tests to code — is enforced by a CI gate that fails unless every spec is cited and every citation resolves.

Not sure spec-driven development itself is worth it? Fair question. The anti-patterns page names when LID is the wrong choice, so you can decide before you invest.

LID even ships a coach: /lid-coach reads an already-running LID project and reports back — it edits nothing — where your usage is drifting from the methodology's principles and where there's more value to capture. A good way to learn the discipline by seeing it applied to your own work. See the coach.

Beyond the core, an opt-in lid-experimental plugin bundles skills that work in practice but aren't yet part of the core workflow — currently bidirectional-differential, which checks whether your specs and your code still agree. Worth a look once the basics make sense.

Read the HLD

I'm starting a new project.

Greenfield has nothing to reconcile and nothing to reverse-engineer. Install the plugin, tell the workflow what you want to build, and it only writes code once the design has settled.

/plugin marketplace add jszmajda/lid
/plugin install linked-intent-dev@jszmajda-lid
/linked-intent-dev describe what you want to build

You'll see an HLD first (with architectural alternatives for the big decisions), then LLDs per component, then EARS specs, then tests, then code — every phase stopping for your approval.

Once a few components exist, /lid-coach reviews how well the project is applying LID's principles and points at the highest-value next steps.

Full greenfield walkthrough

I'm adding LID to an existing codebase.

Brownfield is a different shape. You have working code already; what you don't have is an articulated intent behind it. LID's /map-codebase reads every file in scope (deliberately token-intensive — accuracy requires it), proposes multiple ways to slice the system, and works backward from code to LLDs to a synthesized HLD.

/plugin install linked-intent-dev@jszmajda-lid
/plugin install arrow-maintenance@jszmajda-lid
/arrow-maintenance:map-codebase

After mapping you get an arrow — a traceable chain from intent to code — plus an audit overlay that tracks what's implemented, what has drifted, and what still needs design attention. Arrows grow as you work; /arrow-maintenance keeps them honest.

Full brownfield walkthrough

I'm trying LID on one subsystem.

Solo on a team, or piloting LID on one slice of a larger project? Scoped LID is the mode for you. The HLD is still required, but it can mark the rest of the project as "not yet specified" — you own your scope, and the discipline relaxes at the boundary.

Scoped uses the same entry point as Full; the workflow asks which mode you want.

/linked-intent-dev describe your scoped feature
# answer "Scoped" when prompted for mode

Cascade pauses at the edge of your scope, so you don't propagate incoherence into teammates' territory. When the team adopts or your scope grows, /update-lid promotes you to Full.

Read about modes in the HLD