> ## Documentation Index
> Fetch the complete documentation index at: https://specled.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Spec Led Development is no longer maintained. This site remains available as a reference.

> **Maintenance status:** Spec Led Development is no longer maintained. This site remains available as a reference. No new features, bug fixes, or support are planned.

> Spec 1.0: This page reflects the last published portable core release.

Spec Led Development gives a repo a small current-truth layer plus a verification loop.

It keeps intent, code, tests, docs, and review pointed at the same contract.

At the core, the repo keeps authored specs in `.spec/specs/*.spec.md` and derived state in `.spec/state.json`.

If you are new, start with [Why](/why) for the motivation, [Getting Started](/getting-started) for the first pass, and [Tooling](/tooling) for the package repos and commands.

## The problem

Software changes faster than shared understanding.

That gap shows up as drift:

* code that technically passes but misses the point
* tests that only cover part of the behavior
* docs that go stale
* agent output with weak context

## The answer

Spec Led Development keeps four things tied together:

1. intent
2. code
3. tests and docs
4. verification

The spec is not the whole system.
It is the small contract layer that keeps those pieces aligned.

## The loop

1. Write current truth in the repo.
2. Build code, tests, and docs against it.
3. Verify that the effects match the spec.
4. Keep the same check in CI so drift does not stay hidden.

## What stays in the repo

At the core, the repo keeps:

* authored spec files in `.spec/specs/*.spec.md`
* derived verification state in `.spec/state.json`

Some implementations also scaffold local workspace guides and ADRs.
The public model stays intentionally small.

## Who it is for

* teams using AI coding agents
* teams that want clearer engineering back pressure
* projects that need a language-agnostic method
* engineers who want something simple enough to teach and strong enough to verify

## Start Here

<CardGroup cols={2}>
  <Card title="Why" icon="compass" href="/why">
    Read why this exists and the constraints that shaped it.
  </Card>

  <Card title="How It Works" icon="rotate" href="/how-it-works">
    See the loop from current truth to code to verification.
  </Card>

  <Card title="Getting Started" icon="flag" href="/getting-started">
    Take the smallest good first pass into the method.
  </Card>

  <Card title="Core Model" icon="layers" href="/core-model">
    Read the small portable model at the center of the method.
  </Card>
</CardGroup>