Most coding-agent guardrails are prose: keep the diff small, prefer the standard library, do not add a dependency casually. Good instructions, but open-loop instructions. Once an agent makes an edit, the session needs a way to surface whether those preferences were crossed.
Ratchet is a small open-source project built around that gap. Its README describes hooks that inspect an agent's edits, measure them, and report findings back into the same session. The project documents four modes—advise, guard, strict, and off—with guard as the default. In its description, strict handling applies only to findings graded certain, and depends on the host honoring the returned decision.
What it tries to make visible
The documented detector set is intentionally practical: new manifest dependencies, duplicate-looking symbols, wrappers that only forward arguments, implementations of things the platform already provides, single-implementation abstractions, and budgets for new files, dependencies, and net added lines.
That is a useful framing for agent-assisted work. The cost is rarely one obviously bad decision. It is the accumulation of small, hard-to-review additions across a long session: another package, another pass-through component, another helper that already exists under a different name.
The public repository separates a guard hook, change-reading code, and detection code under hooks/; its package manifest declares Node.js 20+ and uses node --test. This is a source observation only: I have not installed, configured, or run the project.
The boundary is the important part
Ratchet's README explicitly describes the detectors as regex and git grep, not a type checker. That makes a finding a review prompt, not a correctness verdict. It also means this should not replace tests, security review, or architectural judgement.
The difference from grep, an LSP, or simply reading a diff is not deeper semantic understanding. It is event timing and continuity: checks run after an agent edit, and the project records session-oriented measurements such as a mark and ledger. For a team already using coding agents, that can turn vague preferences into a short discussion while the change is still small.
Who should consider it?
Consider this kind of tool if your team already has an agent workflow and repeatedly sees dependency creep or unnecessary abstraction in agent-produced diffs. Skip it if you need type-level certainty, cannot accept heuristic false positives, or do not want to maintain hook configuration.
I would evaluate it as a pre-review speed bump: start in an advisory mode, inspect whether the findings are useful for your repository, and keep the normal test and review gates intact. Do not treat an alert as proof.
Not tested / not run. This article is based on public documentation and source inspection, with no independent performance, accuracy, or compatibility claims. Further reading: the project's README, detector module, and guard hook.
Top comments (1)
Naming the regex and git-grep boundary up front is the honest part, a finding is a prompt to look rather than a verdict. What I'd want to know before adopting: in guard mode, does the finding text go back into the agent's own context? If it does, you risk the agent optimizing against the check, renaming a wrapper until the duplicate-symbol pattern stops matching, which reads like a fix and isn't. Does the ledger record whether a flagged edit actually got reverted, or only that it fired?