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. More on that below.
First, the part that actually matters more than any single prompt:
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" and "explain
this as a diagram I can show a PM" are two different prompts with two
different amounts of usefulness.
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.
— Omenabyte Intelligence
Top comments (0)