Your repo already stands.
Reinforce it.
rungs installs and maintains a repository's agentic development system — backlog, findings, gates, skills — composed from modules extracted from four repos that already paid for the lessons.
Start read-only: npx @rungs/cli doctor. It writes nothing.
Detection runs on repos that never installed rungs. It ends by naming one command — never the maximal one.
npx @rungs/cli check32 pass0 fail0 unimplemented · Phase 6 in progressRead in date order they are one operator learning the same lessons four times. What worked became a module; what hurt became a guardrail. No repo has all four stages — that gap is the product.
tracked is the rung two of the four source repos never reached — and both paid the same price.
The agent entry point, the harness bridge, path-scoped rule sources, and the render pipeline. The one module every repo installs.
Numbered, immutable decision records, with an admission rule that keeps the directory from becoming a second documentation tree.
Work items with stable ids, an eight-status lifecycle, a board, and the three gates that keep the bookkeeping honest.
One workflow that runs the gate registry, a matrix instead of a file per item, and a check that keeps it that way.
A register for what is noticed before it is decided, with a triage path into work items.
The gate runner, the registry every other module registers into, the run ledger, and the generic structural gate set.
A handoff document carrying state between sessions: resume point, active constraints, and a dated archive.
A repeatable assessment whose output is rows in the findings register, never a document per subject.
Skill-authoring discipline and the gates that hold it: spec-pure frontmatter, descriptions that route, neighbours named, and output that lands somewhere.
Behaviour specifications with stable feature and story ids, per-story status, a mandatory scope section, and a gate against overclaiming.
Decision procedures: how to decompose work, whether to reuse or build, and how much planning a piece of work earns.
An external design authority pulled into a local mirror, with every delta routed to a work item, a future item, or an upstream change request — never silent divergence.
Candidate, stable and deploy branch lines; one procedure for cutting a release, hotfixing and rolling back; changelog fragments instead of a shared file.
One owner per topic, declared in a registry and checked — plus a propagation gate for rules that live in more surfaces than their authority.
Many sessions on one integration branch: a verified base to cut from, attributed failures, a land protocol that cannot redden the branch, and merge drivers per conflict class.
audit → findings → backlog (268 unactioned audit reports) ·workflows → skills (an uninvocable 9-step procedure) ·doc-authority → gates (non-negotiables that decayed in place).Selling rung 5 to a rung-1 repo is the most likely way this tool does harm, so the refusal is the default and the override is explicit. Nothing is interactive: rungs runs unattended in the same sessions your agents do.
rungs is not a methodology and not an orchestrator. It does not decide how your agent plans, specifies, or executes — it checks that the repository underneath stays coherent while it does. Whatever writes your code is welcome to keep writing it.
AGENTS.md is embraced rather than competed with. Skills are written to the Agent Skills spec and are portable unchanged; only path-scoped rules are genuinely fragmented across harnesses, so that is the only thing rungs renders per target — and anything a target cannot express is reported in .ai/render-report.md, never silently dropped (ADR-0001).
New here? The nine words this page uses, defined once.