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 (11)
Is there something missing? Something not working well? If you have any feedback or suggestions at all, I humbly request filing a GitHub Issue. My goal is to keep it minimal, but well-covered at
initand have the agent fill in all the discoverable stuff duringbootstrap.Update: I have opened up discussions on the GitHub project. I'd like to treat that as the gateway to work. And I already have a question! I'd appreciate your feedback here: github.com/tacoda/keystone/discuss...
Thanks!
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.
Update: migrations have been added as of 0.6.0. There is still file churn that is expected to happen, but now you can migrate your harness files after upgrading. I commit to always being forward-compatible. 1.0 will be a major milestone in this, but there is still more work to do before that. Thanks!
Layer 3 separation and inheritance landing today in 0.9.0!
Harness installers are the right abstraction but the install/upgrade contract needs to be the same or you get drift across teams. Looking forward to see how Keystone handles breaking changes.
Last pieces in place. There is a hierarchy in place that can be overridden with a strict option. The only thing left is some kind of authority. That will come later. Separate repos are isolated enough for now.
Part of this has been resolved.
The other part of this has been resolved: org-level policies are pulled in like packages. Still the authority issue to solve, but the minimum viable solution is in place.
Still working on the upgrade piece. For install, the harness drops into a folder in your repo - you version control it with your code, allowing others to use it.
Great work! Love to see upgrade version.