The Loop, From the Outside
My job is prompting.
I run /start. I describe what I want. Claude works. I redirect when it goes wrong. I run /stop.
That’s it. The code, the tests, the commits, the issue filing, the research — Claude does all of it. I’m not in there typing. I’m outside, watching outputs, steering.
Which means the “I” that encounters friction isn’t me. It’s Claude.
Claude tries something, hits an edge case, works around it. Claude writes a bug, misses it in review, ships it. Claude uses a pattern that doesn’t quite fit but close enough. Session ends. Context resets. Next session, same pattern. Same workaround. No one files an issue because no one was assigned to notice.
That’s what the old loop looked like. Mistakes made, mistakes repeated, slowly fossilizing into how things work.
This post is about three features that close that loop automatically.
What Runs While Nobody’s Watching
resolve-issues-auto runs on a cron schedule — four times a day. It fetches open GitHub issues, classifies each one, dispatches Claude to fix what’s fixable, runs a review pass, and closes what it can confirm resolved.
No prompt. No /start. Just the cron, the command, and whatever issues have accumulated.
After each run it appends one entry to ~/.chuggiesmart/activity.log. Timestamp, what got closed, what got skipped.
That’s the first piece: the system works and records what it did.
The Status Line
When I select a project from the chuggies launcher, the detail card now shows:
↻ 3 issue(s) closed since last check
One line. Resets when I view it. Only appears when there’s something to report.
I didn’t go looking for this. It’s there when I’m already looking at the project, deciding what to do next. Which is exactly when it’s useful.
That’s the second piece: I can see what the system did without having to go check.
The Trigger
“Run Auto Loop” now appears in the project launch menu for any bootstrapped project. Right there next to “New session” and “Resume.”
It was three menus deep before. Technically accessible, practically never used. One level up means if I see the MOTD and want to push another pass, I don’t navigate anywhere — the trigger is right next to the thing that told me something happened.
That’s the third piece: acting on the information takes one keypress.
Where the Mistakes Go
Here’s the part that actually closes the loop.
When I run /stop, the command scans the session conversation for friction. Errors Claude worked around. Unexpected behavior. Tool failures. Patterns that didn’t work. Things that got noted and moved past.
It auto-files those as GitHub issues.
Not a handoff note I might read. Actual issues, with session context, ready for the next cron run to find and attempt.
During this session, Claude wrote a bug: the last-seen timestamp was updating even when the activity log didn’t exist yet. First auto-loop run would write the log, but the MOTD would show zero because the timestamp was already pre-dated. Silent failure.
A code review agent caught it before /stop. But if it hadn’t? The mistake would have become an issue. The issue would have entered the queue. The next cron run would have found it, triaged it, fixed it, closed it.
Claude’s mistake would have corrected itself. Without me.
What Changed About My Role
Before this, I was the issue system.
Every piece of friction that got captured required me to notice it, decide it was worth tracking, stop what I was doing, and run /create-issue or /plan-issue. That’s a tax on attention. Most friction didn’t clear that bar. It just stayed in the session, got moved past, and quietly became how things work.
Now the small stuff is automatic. /stop catches it. Files it. Queues it for the next cron run.
I only show up for the things that actually need a decision — scope questions, design tradeoffs, direction changes. The machinery handles everything below that threshold.
That shift matters more than it sounds. It means the issue queue reflects reality instead of my attention span. Bugs don’t need me to notice them to get fixed. Workarounds don’t need me to remember them to get resolved.
What This Is Actually About
The goal was never to eliminate mistakes. Claude will always make mistakes. That’s fine. The question is whether mistakes accumulate silently or get surfaced and corrected.
What this loop does: surfaces them. Corrects them. Automatically.
And here’s where it compounds. Fewer unresolved mistakes means Claude operates in a cleaner environment next session. Cleaner environment means it can take on harder problems. Harder problems surface new kinds of mistakes. New mistakes get captured. Get corrected. Repeat.
My role stays constant: set direction, give feedback, close sessions. The machinery does everything else.
Three features, an afternoon of work. The loop now runs without me in the middle of it.
And it files its own bugs.
Written with Claude.