A recurring review checklist for long sessions

On October 4 I had Claude Code build a small demo for a spoken-English practice app. Once the skeleton was written and committed, it ended its report with:

A lot of files are about to change, per the plan. If you like, start /loop 5m and I'll automatically review new changes every 5 minutes.

My rules file asks for that: during longer coding sessions, suggest a recurring review. I replied: "Go ahead."

Over the next 30 hours the review ran more than 100 rounds. 101 of them came back with the same line:

✅ Recent changes reviewed, no issues found

Exactly one round found anything.

What that round found

That afternoon I gave it what it needed to connect to a third-party chat platform. It wrote the whole integration layer in one go, got 36 tests passing, committed, and pushed. Less than a minute later the next review round started, and its report opened with:

This round reviewed the P1 commit (6177d4a), which hadn't been through this loop yet. Found 2 issues, fixed and pushed (85f9a6c)

The first issue: users' original voice messages stayed in the media directory after being transcribed. They'd pile up, and the app would keep users' voices indefinitely. The fix deletes the original once recognition finishes, and also when transcoding fails.

The second: when the platform's access token expired, several concurrent requests would each fetch a new one, and the token endpoint is rate-limited. The fix makes all requests share the single refresh already in flight.

Both got regression tests, and all 38 tests passed. The report ended with a section I think was the best part:

Two more things I looked at and decided don't need changing

One was that the callback has no replay protection. Its reasoning: a replay would only fetch messages one extra time, and messages are already deduplicated, so nothing gets answered twice. The other was that the cursor still advances when processing a message fails. Its reasoning: a failure gets logged, so it can be traced.

That section told me where it looked and why it let things pass. With a review that only lists problems, you can't tell whether what's not listed is fine or just wasn't looked at.

The rule said git diff; the problem was in a commit

The first step of my rule was "run git diff to see unstaged changes and review each file."

But an agent commits as soon as it finishes. The integration layer was committed and pushed right after it was written, so by the next round git diff was empty. If the review had looked only at unstaged changes, that round would also have said "no issues found."

It went a step further and looked at the commit that hadn't been reviewed yet. The rule didn't ask for that. So the review scope should be "everything since the last reviewed commit," committed or not, not git diff.

Those 101 rounds

In those 101 rounds, most of the time there was simply no new code in the repo. Ten minutes after the loop started, the agent said so itself:

The next step is waiting on you for the model API key... until then there won't be any new code. If you like, I can turn this off for now

I didn't respond, so it kept going. At one point the network dropped and several rounds just reported connection errors. The scheduled task was only deleted the next evening, when I said, "Stop the review loop for now."

Each "no issues found" was short and easy to skim. But every round was a full model call that read the repo and compared commits. With nobody writing code, it was spinning in place.

So I'd add one line to the checklist: after a few rounds with no new changes, remind the user once to turn it off. Whether to turn it off is still the human's call. This time, the one who didn't was me.

What it can and can't catch

One more thing to be clear about: the reviewer and the author were the same agent in the same session. Reviewing your own work means sharing your own blind spots. What you didn't think of while writing, you probably won't think of while checking.

This run had a ready-made example. Before the loop started, the agent had reviewed the skeleton itself and found that temporary wav files from transcription stayed in the media directory, and changed them to be deleted after use. The first issue the loop later found was the same kind of thing, only this time it was the users' original files left behind. Same kind of hole; the first time, only the one in front of it got patched.

Even so, it found two real problems. My take: while writing code, attention is on "make it work"; looking back, the question changes to "can this go wrong?" A different question shows some of what the first one missed.

But it doesn't replace a second pair of eyes. Important changes still deserve a look from an independent reviewer.

A version to copy

Here's the rule from my rules file, revised with the two points above:

## Recurring review
In coding sessions that touch 3+ files or run 15+ minutes, suggest the
user start `/loop 5m`, and check the following each round:
1. Scope: everything since the last reviewed commit, committed or not;
   go file by file
2. Correctness: complete logic, edge cases, matching types
3. Security: injection, XSS, information leaks
4. Performance: unnecessary loops, unclosed resources, N+1 queries
5. Consistency: follows the project's existing patterns, naming, and
   import style
6. Maintainability: duplicated code, needlessly complex logic
7. Report issues as `[file:line] category - problem → suggested fix`;
   list what you looked at but decided not to change, with reasons
8. If nothing's wrong, reply with one line:
   `✅ Recent changes reviewed, no issues found`
9. After 3 rounds with no new changes, remind the user to turn it off

Adapt items 5 and 6 to your project. For that demo, I added absolute imports and validation of data crossing boundaries under consistency, and functions under 50 lines and files under 500 lines under maintainability.

Of those 100-plus rounds, one did real work. Item 9 would have saved most of the 101 idle ones. The one that worked found users' voices piling up on disk.