Why I built Rness: governing AI coding agents across repositories

Description and use

Rness centralises AI agent configuration rules, synchronises them across repositories, and speeds up cross‑repository changes.

Problem

Managing consistent agent configuration across multiple repositories is hard and error‑prone.

Outcome

Rness reduced configuration duplication, enabled single‑source governance, and accelerated cross‑repository changes (e.g., CLI rename and Node version decision) from specification to npm release in under two hours.

Workflow

• 1. Store all standards, ADRs, specs, and plans as Markdown files in .rness. 2. Define rness.json to map rules to repositories. 3. Run rness sync to generate and inject rule blocks into each repository’s AGENTS.md and link CLAUDE.md to it. 4. Use rness sync --check in CI to fail if any repository is out of sync. 5. Create a specification or ADR in .rness; an agent turns it into a plan. 6. Agent commits changes across all affected repositories (CLI, docs, website) within minutes. 7. Run rness:plan check to re‑run proofs before closing a plan. 8. Monitor progress on the GitHub Project board via rness board push.

Evidence

Everything lives in one place. The standards, decisions (ADRs), specifications and plans are Markdown files in one repository, .rness, cloned next to the others, with a rness.json that says which rules apply where.

Source

With Rness the rule is written once, in a standard under .rness/. rness sync rewrites the generated block of every repository from it, and each CLAUDE.md already points to that block.

Source

In under half an hour it committed the new command and its tests in the CLI, then the renamed pages in the documentation. It also updated the website's llms.txt, the file other AI agents read to learn how to use the tool. About two hours after the specification, the new version was on npm.

Source