Your reviewer remembers. Claude doesn't. A small plugin for the gap.

Claude Code writes code that works. It builds, the tests pass, CI is green. Then a human on the team opens the PR.

• A type that's fine inside the app but can't be sent to another service. It compiles, it gets sent, the other side can't read it. The network doesn't care how elegant your types are.
• A variable called result. In a codebase where even the loop counters have proper names.
• The handler got changed. The validation sitting right next to it didn't. The test still passed because it never looked at the new field.
• The old name, still sitting in a list two folders away from everything Claude touched.

None of that was written down anywhere. All of it was known to every person on the team, including the one who started last week. That's the gap: the stuff people know and never wrote down. The reviewer has it. Claude doesn't. And the only thing moving it across is the reviewer, typing the same comment again, a little shorter each time.

Each comment gets fixed. Next PR, same mistake, different file. Fixing the comment fixes today. Writing down why it happened is the only thing that fixes next week.

What I tried first

A file called lessons.md, pulled into CLAUDE.md. One rule for Claude: when a reviewer catches something, add a line.

Three months later: 99 lines, 312 additions logged, and the top line had been caught by reviewers 19 times. Not 19 reviewers. One mistake, "after a rename, search the whole repo, not just the files you touched", caught 19 times, each with a new twist, by people with steadily less patience. Second place was at 10. Third at 8. The file had quietly turned into a leaderboard.

And Claude had every line of it, in front of it, every single session. Didn't matter. An hour into a change, that line is buried behind three file reads and a test run. The problem was never memory. It was timing. Nobody re-reads the safety card halfway through the flight.

Next attempt: four small shell scripts that Claude Code runs at certain moments, leaning on a tool called jq. Every script started with "if jq isn't installed, quietly exit". On a machine without jq, the whole thing was dead. No error, no message, nothing. I found out weeks later. It had achieved perfect silence, which is the one thing it existed to prevent.

So, tacit

github.com/N1XUS/tacit. A Claude Code plugin. The things it keeps are called papercuts: small, they repeat, they add up. It does three things.

Ask why, not what

When Claude pulls down the review comments on a PR, the plugin steps in and says: fix them, and for each one you fix, answer one question.

Why did I write it that way? What kind of mistake is this?

"I forgot to remove the old name" isn't an answer. "I only looked at the files I was already editing" is. The first one gets you a sticky note. The second one gets you a habit.

Two lists, on purpose

One list for the general rule, one for how it shows up in this particular repo.

I fought this for a while. One file felt cleaner. But "every line must be general" and "after the second time, rewrite it as an exact command" can't both live in one file, because exact commands depend on your stack. Two files. Took me embarrassingly long to accept that.

You can also tie a list to certain files, so your SQL rules only show up when Claude is writing SQL.

Show up at the right moment

This is the part that actually changed things. The list gets put in front of Claude:

• when a session starts, and again after Claude's memory gets squeezed down mid-session,
• on the first file edit, then every 15th,
• right before git push or opening a PR,
• right after it pulls review comments.

Not on every edit. Text that shows up two hundred times a session becomes wallpaper, and Claude learns to skip it about as fast as you learned to skip cookie banners.

Every trigger is something that actually happened: a command ran, a file is about to be written. It never guesses what you meant.

Keeping score, honestly

Every line in the general list ends with a count: how many times a reviewer has caught it. Same mistake again? Bump the count and sharpen the wording. Don't add a near-duplicate. Once a line hits 2, a check fails and tells you: the wording isn't working, turn it into a concrete step.

The catch: Claude reports its own count. Asking a model to tally its own mistakes is asking a cat to log its own vase incidents. The easy way out of "don't duplicate, increment" is to duplicate anyway and report a clean conscience. So every addition also writes one line to a separate log, and tacit audit compares the two. If the log has more entries than the counts add up to, something got added quietly. That's not a feeling, it's a number.

Hard limit: 30 lines per list. Line 31 is where checklists go to become decoration. A list nobody reads is worse than no list, because it looks like you're covered.

Two rules I won't break

1. The plugin never touches permissions. Technically it could approve a git push on your behalf without asking you. Mine never does, and there's a test that makes sure.
2. The plugin never breaks what Claude was doing. If anything goes wrong, it goes quiet. And because "going quiet" is exactly what bit me with the shell scripts, there's a tacit doctor command whose only job is to tell you whether it's actually running.

The part I built and deleted the same day

Catching corrections in chat. "No, we don't do it like that, here's how." There's no fixed shape to that sentence. I tried three ways.

• Pattern matching. Careful, safe, bounded. Only works in English. Fine as a fallback.
• Asking a small model. One cheap call to Haiku per message, four tokens back, yes or no. About a hundredth of a cent. Worked great in tests. Then I asked the obvious question: does it work if you're on a Claude subscription instead of paying per call? No. Subscription sessions don't have an API key lying around for the plugin to use.
• Starting a second Claude in the background. Uses the session's own login, so subscriptions work. Also: almost four seconds to boot, a whole extra session eating into your limits, all to say "yes". Hiring a consultant to nod.

Then the obvious thing. The smartest model in the room is the one already reading the message. So the plugin just drops in one line, on the first message and every tenth after: if the user is asking for a review, fixing PR comments, or telling you something's wrong, here's what to do. Claude decides. Works in any language. Costs about sixty tokens per ten messages. A full day of clever to arrive at the dumb option.

All three of the clever ones are gone from the code. Not behind a setting. Gone. Dead code behind an opt-in is just dead code with a nicer funeral.

Doesn't Claude Code do this already?

I checked, same day, against the current docs. Claude Code now has its own memory, and it does record your corrections. CLAUDE.md survives when the session gets squeezed down, which it didn't used to. Both good.

But nothing built in asks why a review comment happened. Nothing counts how often the same one comes back, or checks that count against reality. Nothing separates "true everywhere" from "true in this repo". And nothing puts a checklist in front of Claude at the moment it's about to write or push. That's the whole reason this exists. The day those ship natively, I delete it, gladly. I have other papercuts.

Try it

claude plugin marketplace add N1XUS/tacit
claude plugin install tacit@tacit

Then fetch the comments on any PR and watch it ask for the why.

Your lists are plain markdown files in your home folder and your repo. Disable the plugin and they're still there. Like real papercuts.