Welcome to The AI Brief.

Every week, you get clear, honest breakdown of what’s really happening in AI. No recycled press releases pretending to be insight. Just the developments that actually matter.

After last week's issue on Claude Code slash commands, several hundred of you replied asking for the PDF. That response told me something more interesting than just demand for a reference guide.

It told me that developers know they are not using their tools well, and what is stopping them is not motivation — it is documentation that was never written clearly in the first place.

AI companies announce capabilities well and explain them poorly. Claude Code's slash commands have existed for months, one forward slash away from any terminal. What never existed was an honest guide to what each command actually does, when to use it, and what breaks when you use it wrong.

That is what we built. Let's get into it.

When you type a prompt, you summarize. When you speak one, you explain. Wispr Flow captures your full reasoning — constraints, edge cases, examples, tone — and turns it into clean, structured text you paste into ChatGPT, Claude, or any AI tool. The difference shows up immediately. More context in, fewer follow-ups out.

89% of messages sent with zero edits. Used by teams at OpenAI, Vercel, and Clay. Try Wispr Flow free — works on Mac, Windows, and iPhone.

Start flowing free

If you want to understand what any AI tool actually does, the worst place to start is the company's own documentation. Not because it is wrong, exactly, but because it is written to impress rather than to inform. Features are presented at their best, with ideal use cases and no acknowledgment of where things go sideways.

This is not unique to AI, but it is particularly costly here because the gap between the advertised experience and the real one is wider than in almost any other software category.

Claude Code's slash commands are a clear example. The commands exist, they are documented, and the documentation is technically accurate.

What it does not tell you is that /batch creates merge conflicts if your task units are not genuinely independent, that /loop will keep billing you if you do not set a ceiling, or that /compact is lossy in ways that can drop important context from early in a long session. Those are the things you learn by using it wrong, and they are not in the official docs.

The reference guide in this issue is built around a different philosophy: tell people what the command does, how to use it well, and specifically what goes wrong when they use it badly. That third part is what most documentation skips, and it is the most useful part.

Fourteen commands are covered in full, organized by what they are actually for — planning and strategy, code review, parallel execution, session management, and automation.

Each entry includes a usage example, the context where it earns its place, and an honest note on cost or risk where one exists.

There is also a section on the /goal and /loop combination specifically, because it is the most capable setup in Claude Code and the most expensive if you are not watching. The developer story from last week — 47 failing tests, a cup of coffee, a three-hour bill — is a real pattern, not an edge case. The guide explains how to use the combo without ending up with a surprise charge.

One broader point worth making: you do not get value from AI tools by reading the feature list first. You get it by understanding the problem the tool was designed to solve, then working backward to the features. The slash commands do not make sense as a list. They make sense as a system for moving Claude Code from conversational to autonomous.

Once you see them that way, knowing which command to reach for becomes much more intuitive.

That reframe is what the guide is built around, and it is why 14 commands covered honestly ends up more useful than 50 commands covered optimistically.

We built a 14-command reference guide so developers can use Claude Code correctly. The irony is that we had to write it ourselves because Anthropic did not. The company that raised billions to build the most capable developer tool on the market apparently has a different budget for explaining how to use it.

Right. Now for the position.

Every feature page shows the happy path. The command works, the output is clean, the workflow is smooth. Nobody publishes a documentation page that says "this works well 70 percent of the time, costs more than you expect 20 percent of the time, and creates a mess the other 10 percent."

But that is what honest documentation looks like, and it is what actually makes tools usable. Developers who understand the failure modes of a tool use it better, not worse. They reach for it when it fits and avoid it when it does not.

That is not a small thing — it is the difference between a tool that sits in your workflow and one that gets cancelled after a frustrating month.

The reference guide for this issue is opinionated in exactly that direction. It is not a celebration of Claude Code. It is a clear account of what each command does in the real world, including what goes sideways and why.

That is what documentation is supposed to be. It is also, apparently, too much to ask for from the companies building these tools.

The PDF is linked in this email. If you did not get it or you are reading this for the first time, reply with one word — "PDF" — and I will send it directly.

If you used a command from last week's issue and something changed about how you work, I genuinely want to hear about it. What worked, what did not, and what I got wrong are all fair replies.