There are 60+ built-in commands in Claude Code. /insights is the one that shows you how you work - not just what you built.
There are over 60 built-in commands in Claude Code. Most people use 6 of them regularly, maybe 10 if they're paying close attention. The ones that get used are the visible ones - the commands that directly produce output. Build something, review something, ship something.
The commands that require stepping back from the work itself are the ones that get skipped.
/insights is one of them.
What it actually does
At the end of a work session, /insights generates a structured analysis report across three areas.
Project areas. Which parts of your codebase were touched. Which files changed hands, which systems got attention, which areas were untouched.
Interaction patterns. How you communicated with the model this session. Were your instructions detailed or vague? Did you work linearly or jump between problems? Did you correct the same thing more than once?
Friction points. Where things slowed down. The moments that required rephrasing. The places where multiple rounds were needed. The gaps between what you intended and what the AI understood.
That last section is where the actual value is.
The insight is about you, not the model
When a Claude Code session goes sideways, the instinct is to blame the model. "It kept drifting." "It didn't understand the context." "I had to correct it four times."
Those are symptoms. /insights names the cause.
In most cases, friction traces back to the specification - not the model's capability. A vague instruction produces a vague result. A constraint that was never defined becomes an assumption. Context that was missing gets filled in by the model's best guess.
The hard part is that you can't see this while you're working. You're focused on the problem, not on how you're briefing it. The brief degrades without you noticing, and the session degrades with it.
/insights makes it visible after the fact - in plain language, with specific examples from the session.
How to use it
Run it at the end of any session longer than 30 minutes. Quick tasks don't generate enough signal to make it worth it. But for complex sessions - architectural decisions, multi-file work, anything where you felt friction - run it before you clear the context.
Read the friction points first. Then the interaction patterns.
After a few sessions, patterns emerge. The same type of instruction that always needs a correction round. The same context you always forget to provide upfront. The same categories of work where your spec is consistently weak.
That's not something you fix by learning more about AI tools. That's something you fix by learning more about how you think and communicate before the AI touches anything.
Why nobody runs it
The commands that improve your output directly are obvious - run them, get something. The commands that improve how you work require a different mindset. You have to believe that the process is worth examining, not just the result.
Most people finish a session, close the terminal, and move on. The work either landed or it didn't. What led to it - the quality of the direction, the gaps in the spec, the friction that compounded over two hours - stays invisible.
/insights costs two minutes.
What it produces is a mirror: a specific, session-level picture of how you work with AI and where that working style breaks down.
Builders look at the output. Architects look at both.
Type /insights at the end of your next long session. Read the friction points section. See what you find.