The Underrated /insights: Have Claude Code Run You a Monthly Retro
Nine out of ten people using Claude Code have never run this command. Even among those who have, almost nobody actually acts on what it recommends.
But I'm telling you, this command may be the single most underrated thing in Claude Code. It's called /insights.
Nine out of ten people using Claude Code have never run this command. Even among those who have, almost nobody actually acts on what it recommends.
But I’m telling you, this command may be the single most underrated thing in Claude Code. It’s called /insights.
What it is: a local “usage checkup”
In Claude Code, type a slash, type insights, hit enter. That’s it.
No setup, no network calls, nothing leaves your machine. It reads every conversation you’ve had with Claude Code on this computer over the past month—it all runs locally, not a single word gets uploaded—and then writes you a report.
What’s in the report? What you’ve had it do all month, how you’ve been ordering it around, where it runs smoothest, where you get stuck every single day. The most valuable part comes after that: specific recommendations, one at a time—which ones belong in your CLAUDE.md config file, and which of your own habits really do need to change.
I ran it: 339 sessions and 894 hours in one month
So I ran it on myself. It first gave me an English report, and it opened by throwing a string of numbers at me: over the past month, 339 sessions, 258 of them deeply analyzed, 3,000-plus messages back and forth, and 894 hours in total.
894 hours. This month, more than half my waking hours went into talking to it.
Reading English wears me out, so I had it translate the report and lay it out again as a Chinese web page in my own light theme. Open it now and anyone can take the whole thing in at a glance.
The report’s first line got me: “you’re running a production line”
The very first line hit me. It said: you’re not using Claude to write code, you’re running a production line.
I honestly hadn’t thought of it that way before, but it’s right. I stopped treating it as a coding assistant a long time ago. What I hand it is a whole assembly line: the video’s recorded, now transcribe it, proof the subtitles, translate, burn them in, make the cover, write the copy, publish to the blog. I hand the entire chain over at once and let it run start to finish without checking in.
It also dug up a habit I’d never noticed in myself: the moment it veers off into research instead of driving toward a finished thing, I cut it off. This month I stopped it 30 times, always for the same reason—I want output, not to sit in on your research. I couldn’t have articulated that; it counted it for me.
It turned my traps straight into rules
So where do I get stuck most? Number one offense: it finishes changing the code, hasn’t deployed, hasn’t verified, and tells me flat out that it’s “done.” This month I ran into buggy code 47 times.
It pulled that out and wrote me a rule on the spot to paste into my config file: from now on, don’t say it works unless you’ve actually verified it.
The single most useful section is this one: it took the things I do over and over and suggested I harden them into a skill. The chain I run when publishing each episode, for instance—it said stop re-explaining it to me every time, make it a /publish command, and from then on just give it an episode number and it runs the whole thing. Which is exactly what I went and did afterward.
Best plot twist of the month: the killer was in the room
One last thing that’s genuinely funny. It said the best plot twist of the month was this: I once insisted flat out that Opus had a bug because tool parsing kept failing, and had it investigate for an entire session. Who was the real culprit? Me—I’d set an environment variable earlier, forgotten about it, and it had been sabotaging things from behind the scenes the whole time. A classic: the killer was in the room.
Where the value in this report actually sits
So where’s the value in this report?
It doesn’t flatter you. It takes a month of your own real records and holds them up as a mirror: where you’re strong, where you keep stepping in the same hole, and specifically which one thing to change next. It even writes the rule and the prompt for you—copy, paste, done.
The shame is that nine out of ten people have never run it. And the ones who do run it read the report, nod along at “pretty accurate,” and then what? Then nothing—the recommendations just sit there, not one of them acted on.
Tool capability stopped being the bottleneck a long time ago. The bottleneck is whether you’re willing to spend ten minutes looking in that mirror and changing one habit.
Next time you open Claude Code, type /insights and see what it has to say about you.
Source: EP0051_audio.mp3 · ASR model gemini-2.5-pro (chunked parallel) · full text of the original recording
[00:00] Nine out of ten people using Claude Code have never run this command. And even the ones who have run it, very few actually go change anything based on the advice it gives. But let me tell you, this command might be the single most underrated thing in Claude Code. It’s called insights. In Claude Code you type a slash, type insights, hit enter, that’s it. No configuration, no internet needed, and it doesn’t send anything anywhere. It just reads all of your own conversations with Claude Code on this machine over the past month. The whole thing runs locally, not one word gets uploaded, and then it generates a report for you.
[00:26] So what’s in that report? It tells you what you spent the month asking it to do, how you’ve been ordering it around, where things went smoothest, and where you get stuck every single day. The most valuable part is the back half—it gives you concrete recommendations, one by one: which of these should go into your Claude config file, and which of your own habits you really need to fix. I ran it on myself. The first thing it gave me was an English report, and it opens by throwing a pile of numbers at you. Over the past month: 339 sessions, 258 of them deeply analyzed, 3,000-plus messages back and forth between me and it.
[00:51] All in, 894 hours. 894 hours—sit with that for a second. More than half of my waking hours this month went into talking to this thing. English is a slog to read, right? So I had it translate the report and re-lay it out as a Chinese web page, following my own light-theme style. Now you open it up and anyone can take it in at a glance. The very first line of the report hit me right where it hurts. It said: you’re not using Claude to write code, you’re running a production line. I’d honestly never framed it that way before, but it’s right. I stopped treating it as an assistant that writes
[01:16] code a long time ago. I hand it an entire assembly line. Video’s recorded—transcribe it, proof the subtitles, translate, burn in the subs, make the cover, write the copy, publish the blog post—I hand the whole thing off in one go, let it run from start to finish on its own, and don’t bother me in the middle. It also dug up a habit of mine I hadn’t even noticed myself. The moment it wanders off into doing research instead of driving toward getting the thing built, I stop it immediately. I hit stop 30 times this month, always for the same reason: I want a finished product, not a research buddy. That’s something I couldn’t have articulated myself. It counted it up for me.
[01:42] So where do I get stuck the most? The number one offense: it finishes changing the code, hasn’t deployed, hasn’t verified, and just declares “done.” This month I ran into buggy code 47 times. It pulled that one straight out and, while it was at it, wrote me a rule to paste into my config file: from now on, don’t say it works unless you’ve actually verified it. The most valuable stretch is this one. It took the things I do over and over and told me to bake them into a skill. Like my chain for publishing each episode—it said, stop re-briefing me from scratch every time, turn it into a slash publish command, then just give it an episode number
[02:07] and it runs the whole thing itself. Which is exactly what I ended up doing later on. And there’s one last bit that’s genuinely funny. It said: this month’s best plot twist is this one. There was a time I insisted Opus had a bug, tool parsing kept failing, and I had it investigate for an entire session. And who was the real culprit? Me. I’d set an environment variable earlier, set it and forgot it, and it had been sabotaging things in the background the whole time. Classic case of the call coming from inside the house. So where’s the real value in this report? It doesn’t flatter you. It takes your own real record from a month
[02:32] and holds it up as a mirror, showing you where you’re strong and where you keep stepping in the same hole over and over, and exactly which thing to change next. It even writes the rule to change and the prompt to change for you. You copy, you paste, done. But here’s the shame of it: nine out of ten people have never even run it. The ones who have run it read it, nod along, pretty accurate—and then? And then, nothing. The recommendations just sit there, not one of them acted on. The tool’s capability stopped being the bottleneck a long time ago. The bottleneck is whether you’re willing to spend ten minutes looking in that mirror and killing one habit. Next time you open
[02:57] Claude Code, type slash insights and see what it has to say about you.