A builder's guide to your own Claude Code usage

I ran /insights on a slow Friday, half expecting a token bill and a pie chart. It gave me a short writeup of how I actually work with Claude, and the first line called me a “verification-first skeptic.” I read it twice. It was right, and it landed the way a good code review does: a little uncomfortable, and useful because of it.

That report is now the start of a habit. Once a month I spend half an hour reading how I used AI over the last few weeks, then I change one or two small things so the next month goes better. No dashboards, no telemetry pipeline. One command and a couple of files every Claude Code user already has.

Read the report before you argue with it

/insights reads back your recent sessions and writes up how you work as an HTML report you open in your browser. Mine told me things I half knew but had never said out loud: that I run long, tool-heavy sessions and let Claude do the investigating, that I ask for receipts before I believe a claim, and, the useful part, that the thing most likely to derail me is a quiet screen. When an operation runs silent for a few minutes I read it as a hang and pull the plug, sometimes on work that was doing fine.

I would not have found that by paying closer attention inside a session. You can’t see your own pattern from inside the thing you’re doing. That’s the whole reason a retro exists on a normal team, and it’s the reason to run one on yourself.

You don’t need the full report to start. /context shows what’s loaded into a session and why. /usage shows what it cost. Resuming an old session with /resume and rereading it is free and often enough. Look at the record. Your memory of it is the biased part.

Turn one repeated correction into a rule

Here’s the move that pays off first. Find the thing you tell Claude every single session, and stop telling it. Put it somewhere that gets read on every run.

For me that’s evidence. Before I believe a change works, I want to see the command that proves it. So that expectation lives in CLAUDE.md now, a plain markdown file in the repo that Claude loads at the start of every session:

## How we work here
- Don't tell me it works. Show the command output or the file and line.
- Run the suite with `npm test` before you call a change done.

Two lines. But I stopped re-litigating them, and every session in that repo now starts already knowing them. The report pointed me at a few more of these that are specific to my work, and those are mine to keep. The method is the part worth passing on: a correction you repeat is a missing line of config. Treat it like one.

Turn one repeated workflow into a skill

The next size up is a whole workflow you keep walking Claude through step by step: drafting release notes, running a particular check, setting up a new post. Capture the steps once as a skill, a SKILL.md file under .claude/skills/ that loads only when it’s relevant, so it stays out of the way until you use it.

---
name: release-notes
description: Draft release notes from the PRs merged since the last release.
---

List the PRs merged since the last release tag with
`git log $(git describe --tags --abbrev=0)..HEAD --merges`,
group them by type, and write one plain line for each:
what changed, and why it matters.

Now “do the release notes” runs the same way every time, and I’m not rebuilding the instructions from memory on a Friday afternoon. Skills are where I’ve gotten the most out of this, because the good version of a task you do often is worth writing down once.

Keep it honest, keep it small

Not every annoyance earns a rule. CLAUDE.md is read on every single run, so a bloated one taxes the sessions you were trying to speed up. A one-off you’ll never hit again does not belong there. The trick is telling recurring friction from noise, and that distance is exactly what the monthly read gives you: enough remove to see which problems keep coming back.

None of this is heavy. Run /insights, read it the way you’d read a review of someone else’s work, fix one thing, ship it. Then do it again next month. The changes are small and they stack, because a rule you write once keeps working in every session after it.

Embrace your Claude persona

The instinct when a report hands you a persona is to sand it down. I would push back on that. The skepticism, the demand for receipts, the low tolerance for a silent screen: that is how I get good work out of a model, so the play is to lean in and make the agent match it. Every rule and skill you write is really just your own standard, written down once so Claude has it from the first message. You stop re-drilling it one correction at a time, the model spends fewer turns getting corrected, the output comes back shaped like something you would actually accept, and you trust it enough to build on faster. Speed, quality, and accuracy come from the same move: the agent knowing how you work before it starts.

That does not move you out of the chair. Think of it as an orchestra. The agents can play, and they can play many parts at once, but you hold the baton. You still decide what is worth doing, what is actually true, and what ships, and your persona is how you conduct. The better the agents get, the more that judgment is the scarce part, and the more it has to stay with a person who has it.

That’s the same reason we run tarmac.io out of a git repo and a wall of checks: a habit you encode beats a habit you intend, so we encode it. It’s the same instinct behind the Tarmac 10.