The Prompting Gap Is the Only Gap Left

There's an uncomfortable pattern I keep seeing.

Two developers, same repo, same version of Claude Code, same task. One of them is done in ten minutes — tests written, PR open, moving on. The other is twenty minutes deep in a back-and-forth, re-explaining context Claude should've already had, watching it guess at requirements nobody stated.

Same tool. Wildly different outcomes.

It's not a skill gap. It's not even an experience gap. It's a vocabulary gap — and it's the last one standing between "I have an AI coding assistant" and "I ship noticeably faster than I did six months ago."

The tool got good before the instructions did

Claude Code can trace a bug from a vague symptom to a root cause. It can read a Terraform plan and tell you what's about to break. It can turn a CSV of ad performance into twenty new headline variations that fit under a character limit. It can do a lot of things most people never ask it to do — because most people never think to ask.

Anthropic has actually published a lot of this — scattered across a Common Workflows guide, a best-practices doc, a "how our own teams use Claude Code" writeup, and a few deep dives into how their legal and security teams use it internally. Genuinely great material. Also, genuinely annoying to piece together from six different pages when you're mid-task and just want to know what to type.

So I pulled all 52 prompts into one place, organized them the way you actually work — not alphabetically, not by topic, but by where you are in the process — and turned it into a field guide.

Six patterns, not fifty-two prompts

Here's the thing nobody tells you about "good" prompts: memorizing someone else's exact wording only gets you so far. What's actually transferable are the patterns underneath them. Learn these six and you can write your own prompt for a problem no cheat sheet ever anticipated.

1. Describe the outcome, not the steps.

Say what you want and let Claude find the files.

add rate limiting to the public API and make sure existing tests still pass

2. Give it a way to check its own work.

Ask for run, test, compare, or verify in the same breath so it iterates instead of stopping after one guess.

write the migration, run it against the dev database, and confirm the schema matches

3. Point at a reference.

Name an existing file or pattern to match. Without one, Claude defaults to generic best practices. With one, it matches your conventions.

add a settings page that follows the same layout as the profile page

4. State the measurable target.

When the goal is performance or coverage, give the number. Ambiguous goals get ambiguous effort.

get the bundle size under 200KB and show me what you removed

5. Give it the artifact.

Paste the error, the log, the screenshot, the plan output. Don't describe the problem — hand over the evidence.

why is the build failing? @build.log

6. Say how you want the answer.

Name the format, the length, the audience.

explain this as a diagram I can show a PM

Once these six patterns click, you stop needing a cheat sheet for everything. You just need one for the stuff you don't do often enough to have memorized — which is exactly what the rest of this is for.

A few, to prove it's not just theory

One from each stage, straight out of the library:

• Getting oriented in a repo you've never seen:

  give me an overview of this codebase: architecture, key directories, and how the pieces connect

• Scoping a change before you promise a timeline:

  which files would I need to touch to add a dark mode toggle to settings?

• Catching a risky change before you commit it:

  review my uncommitted changes and flag anything that looks risky before I commit

• Investigating an incident without five browser tabs open:

  the checkout endpoint started returning 500s an hour ago. check the logs, recent deploys, and config changes, then tell me the most likely cause

• Turning a one-off fix into something your whole team benefits from:

  you keep using default exports when this project uses named exports. add a rule to CLAUDE.md so this stops happening

None of these are clever. That's the point. The unlock isn't cleverness — it's specificity, evidence, and knowing what to ask for at each stage of the work.

What's in the full library

52 prompts across five stages — Discover, Design, Build, Ship, Operate — each with the exact wording, the technique it teaches, role tags for PM/Design/Marketing/Docs/Security/Ops/Data (this isn't just an engineering cheat sheet), and a "try next" tip for turning a good prompt into a standing team habit instead of something you type from memory every time.

23 pages. One download. Every prompt copy-paste ready.