kunchenguid/no-mistakes

Worth a look if you already lean on coding agents and want their output filtered before a human sees it. It is a fairly invasive workflow change, not a drop-in hook.

The problem

You finish a branch, push it, open a PR, and then discover the missed test, stale doc, or lint error in review — or after CI fails. When a coding agent produced the change, the reviewer ends up doing the agent's cleanup. no-mistakes changes the push step itself: instead of git push origin, you push to a local gate remote, and the branch only reaches the configured push target once review, test, docs and lint steps are green. The result is a PR that arrives with the mechanical issues already handled rather than a first draft for reviewers to triage.

What's different

The mechanism is a local git proxy sitting between you and the real remote. Pushing to it spins up a disposable worktree, so the pipeline runs without disturbing the branch you are working in, then forwards the branch only after every check passes and opens the PR. Findings are split by type: mechanical fixes are applied automatically, while anything touching intent is escalated for you to approve, fix or skip in a TUI.

What makes this more than a pre-commit hook is the interaction model. A commenter asked on the Show HN thread why not use pre-commit hooks, and the author replied that when an agent finds seven problems and you care about four, the back-and-forth is awkward to express in a hook (reply). The pipeline is also agent-agnostic — Claude, Codex, Copilot, Cursor and others with ordered fallbacks — and the same flow is exposed as a /no-mistakes skill so an agent can do a task, gate it, and apply safe fixes headlessly. The trade-off is that you are trusting an AI pass to judge your change, and configuring an agent is mandatory: every gate needs a runnable pipeline agent.

CI failures are where the design gets careful. The pipeline repairs them and republishes through a guarded force-push only when it can prove the repair builds on the commit you already reviewed; otherwise the repair goes back through review, and merge-conflict repairs always do because they rewrite history. You can set ci.revalidate_repairs: true to force review of every CI repair, at the cost of another full pass each time.

Who should try it

It fits developers who routinely ship agent-generated branches and want a gate between the agent and human review — especially those who accept the interactive approve/fix/skip loop and can commit to naming a default agent in config. The fork workflow also has a path: keep origin on the parent and initialize with a fork URL.

It is a poor fit if you only want a lightweight local check before committing, or if you are not prepared to run a coding agent as part of every gate. If your team reviews carefully and rarely produces noisy PRs, the added pass over each change may not pay for itself.

Requirements and limitations

You need one of the supported CLI agents installed and runnable, plus a config naming it and any fallbacks — without that the gate cannot run. Setup also changes your remote topology: you push to the gate and it forwards to the configured target, so existing origin habits and scripts need adjusting.

Ongoing upkeep matters more than install. CI repair can force-push, which is why the proof-of-lineage logic and the revalidation option exist; turning revalidation on means each repair costs another full review pass. Check the configuration reference for what that changes before enabling it. Installation is a one-liner on macOS/Linux, with Windows, Go, Nix and from-source paths in the installation guide; a first run is walked through in the quick start.

HotRepo's take

HotRepo recorded a single daily-board appearance on 2026-10-25, with 8,947 stars and +18 that day; the project was 203 days old at that snapshot. That is one observation, so persistence cannot be judged from it — do not read a trend into it. The decision worth making is whether you are comfortable routing every push through an AI gate and naming a default agent; verify that your agent is supported and decide the CI revalidation setting first.