Pick the path that matches where you are.
Each path is a short orientation — a couple of paragraphs and the commands you'd run. Depth is a click away in the README.
I'm evaluating.
You've heard of LID — maybe alongside spec-kit, BMAD, OpenSpec, or another spec-driven-development system — and you want to know if it's for you. LID frames itself a little differently from most of them: not as an "SDD methodology" but as a source language for your coding agent, a dialect of English it can compile faithfully. The others are sibling dialects with different design trade-offs.
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 (intent gaps in agentic coding), the reframe (LID as source language), the mechanisms (narrowing the latent space, linkage, semantic legibility, tests-first), and the adoption modes. The examples page links to two projects — one clean and minimal, one real and messy.
Not sure spec-driven development itself is worth the effort? Fair question. The anti-patterns page names when LID is the wrong choice — honestly, without overselling.
Read the HLDI'm starting a new project.
Greenfield is where LID shines hardest — nothing to reconcile, nothing to reverse-engineer. Install the plugin, run setup, then describe what you want to build. The skill takes you through the four design phases, stopping for your review each time, and only writes code once the design has settled.
/plugin marketplace add jszmajda/lid
/plugin install linked-intent-dev@jszmajda-lid
/linked-intent-dev:lid-setupAfter that, tell Claude what you want to build. You'll see an HLD first (with 2–3 architectural alternatives for big decisions), then LLDs for each component, then EARS specs, then tests-first, then code. Every phase stops for your approval.
Full greenfield walkthroughI'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
/linked-intent-dev:lid-setup
/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.
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 projects use the same setup command as Full LID; the skill asks which mode you want at bootstrap (or you can answer later).
/linked-intent-dev:lid-setup
# answer "Scoped" when prompted for mode
Cascade pauses at the edge of your scope, so you don't accidentally propagate incoherence into teammates' territory. As the team adopts LID or your scope expands, /update-lid supports promoting from Scoped to Full.