Capture why code exists.
Your code says what it does. It does not say what you were trying to achieve, what you ruled out, or what breaks if someone changes it. Intent gives that a place to live — in the repository, next to the code, in a form both your team and your coding agents can read.
An AI coding agent cannot reconstruct that reasoning. It reads what the code does and builds confidently on assumptions you would have rejected in one sentence, because the sentence was never written down anywhere it could read. Handing an agent more context each session does not fix it: the context has to come from something that cannot silently drift.
Real output, captured whole. The thread is not done because a criterion says so; it is done because a test says so.
Code archaeology is a tax you pay forever
Every codebase accumulates decisions nobody wrote down. Six months later the reasoning is gone and all that is left is the artefact, which cannot be interrogated. New engineers spend weeks reconstructing it. AI agents cannot reconstruct it at all — they read what the code does and build confidently on assumptions you would have rejected in a sentence.
Comments rot because they sit beside the code and nothing checks them. Design docs rot because they sit apart from it and nothing links them. Intent puts the reasoning in the repository as tracked, checkable structure.
A steel thread is one intention, followed end to end
Not a ticket and not a task. A steel thread names something you are trying to achieve, records why it matters, breaks into work packages, and states the acceptance criteria that decide when it is genuinely done.
ok was computed from a test that ran, not ticked by hand.Written for the way you actually work now
Intent generates the context files coding agents read — AGENTS.md for the tool-agnostic contract, CLAUDE.md for Claude Code — from the project's real state rather than from a file someone remembered to update. It ships a rule library agents can be held to, per-language critics that check work against those rules, and commit-time gates that refuse changes contradicting what the project said it was doing.
The point is not that an agent reads your docs. It is that the docs are generated from something that cannot silently drift.
What is in the box
A single CLI, written in Rust, managing a small set of durable objects inside your repository. The first four are the model; the rest is what makes it survive contact with a real project.
| Object | What it is |
|---|---|
| steel thread | One intention followed end to end — what you are trying to achieve, and why it matters. |
| work package | The unit of work a thread breaks into, so a large intention still has something you can finish. |
| acceptance criterion | A condition that decides whether the intention was met. Ratified, not improvised at the end. |
| acceptance test | The small red-to-green test backing a criterion, so satisfaction is computed rather than asserted. |
| the store | The single source of truth for every object. One home, so two copies cannot disagree. |
| generated views | The readable files are rendered from the store, so nothing is hand-maintained twice and a hand edit is reported as skew. |
| agent context files | AGENTS.md for the tool-agnostic contract and CLAUDE.md for Claude Code, generated from the project's real state. |
| rule library | Language rules an agent can be held to, served to the agent rather than remembered by it. |
| critics | Per-language reviewers that check work against those rules and report by severity. |
| commit gates | Checks that refuse a change contradicting what the project said it was doing, at the moment it would land. |
The command reference is generated from the register and names the revision it was made from.
Install
macOS and Linux, via Homebrew. No account, no telemetry, no daemon.
Or read the documentation first.