I built a new tool. It is a Level 2 project harness installer (blurs into Level 3). The page is at tacoda.dev/keystone. The repo is at github.com/tacoda/keystone.
What it does
keystone init drops a markdown harness into your repo. Five layers: principles, idioms, domain, state, process. Plus an activation file the agent reads first: CLAUDE.md for Claude Code, AGENTS.md for Codex CLI, .cursor/rules/000-harness.mdc for Cursor.
After init the binary is done. The harness is yours. It is plain markdown checked into your repo, edited by you, owned by your team. Keystone is not a runtime dependency: it is a scaffolder that hands you the artifacts and walks away.
Install is one binary. Either:
brew install tacoda/tap/keystone
or the curl bootstrap:
curl -fsSL https://raw.githubusercontent.com/tacoda/keystone/main/install.sh | sh
keystone init runs once per project.
The harness as a corpus, not a config
A config file tells the agent what to do. A corpus tells the agent what kind of code this is. The difference is the difference between a checklist and a vocabulary.
The five layers answer five different questions.
- Principles. What does good engineering look like, regardless of stack?
- Idioms. How does this stack express those principles?
- Domain. What business rules constrain this codebase?
- State. What is true about the codebase right now?
- Process. What happens at each phase of the workflow?
Principles travel between projects. Idioms scope to your stack. Domain and state get written by you and the agent together during a bootstrap pass. Process holds the six phases: spec, planning, implementation, verification, review, release.
The agent reads what is relevant. The harness does not load all at once: process files load when you enter that phase; idiom files load lazily by region. That is the discipline. A monolithic CLAUDE.md paid in tokens every turn is the failure mode this is built to avoid.
Two flywheels keep the harness alive
The harness is not static. It grows.
The Learning flywheel runs after merge. The agent names a pattern from what changed and proposes an addition to learning/. You decide whether to promote it into the corpus.
The Pruning flywheel runs on audit. Rules that no longer apply get archived, with the reasoning preserved. The corpus does not calcify into a list of rules that made sense six months ago and now just get in the way.
These are the moves I have been writing about for months. Keystone is what they look like in practice.
What it does not do
It does not run. There is no daemon, no hook, no background process. The binary scaffolds and exits.
It does not pick your agent for you. Detection reads marker files already in your repo (CLAUDE.md, AGENTS.md, .cursor/, and so on). It can be selected interactively or if you pass --agent. The harness is agent-agnostic; only the activation file and the adapter directory change per agent.
It does not lock you in. The binary is gone after init. The harness is markdown. If keystone disappeared tomorrow your project would not notice.
Where the adapters stand
The Claude Code, Codex CLI, and pi.dev adapters are real. Cursor, Aider, Copilot CLI, Continue, Cline, and Goose ship as stubs: a minimal lifecycle file and a working menu, enough to start. If you write a real adapter for an agent currently listed as a stub, contribute it back. The shape is documented in harness/adapters/README.md: a lifecycle.md, sensors.md, and activation.md per agent, plus a target directory under targets/<agent>/.
The page is at tacoda.dev/keystone. The repo is at github.com/tacoda/keystone.
The thing I keep returning to: the harness is the artifact, not the tool. Keystone is the cheapest way I know to put a good harness in place. After that, the project owns it.
Top comments (1)
Warning: there will likely be some churn with this tool as I learn more. 1.0 will be a solid checkpoint after the idea and design are more robust.