Anthropic put its best prompts in a library. Here's what I took from it.

Anthropic quietly shipped a page I hadn’t seen before: a prompt library for Claude Code. Not a one-off blog post, but a fixed spot in the docs with copy-paste starting prompts, pulled from the official workflow guides, the best-practices guide, and a piece on how Anthropic’s own teams (engineering, product, design, data, legal) actually use the tool. I’ve used Claude Code daily for months and still found patterns in there I hadn’t noticed myself. That’s exactly why I’m writing this: if it was new to me, odds are it’s new to you too.

Not scripts, patterns

The real value isn’t in the individual examples, it’s in the five patterns underneath them. Under every prompt on the page sits a “Why this works” toggle that exposes the underlying principle, so you can build your own prompts once you recognize the shape. That’s what sets this library apart from a plain list of ready-made lines: it teaches you the form, not just the content.

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

Give it a way to check its own work. Ask for run, test, compare, or confirm in the same prompt, so Claude iterates instead of stopping after one attempt:

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

Point at a reference. Name an existing file or pattern to follow, so new code stays consistent with what’s already there:

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

State a measurable target. For performance or coverage, give the metric and the threshold, so “done” isn’t up for interpretation:

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

Give it the evidence. Paste errors, logs, or screenshots directly into the prompt, or point with @ at a file. Claude then reads the source, not your summary of it:

why is the build failing? @build.log

What I recognized right away

The third pattern, pointing at a reference, is exactly what I do too little of. I often describe in words how something should feel, when I could just point at an existing article or component and say “do it like that.” Since I started doing that, I get fewer first attempts back that still need correcting.

The second pattern, giving it a way to check its own work, connects to something I’ve written before: tell the model less, it often knows a better way. Both come down to the same thing. You decide the goal and how that goal gets verified, and let go of the route there.

One caveat

Honestly, the page itself is an example of something I run into often: many of the individual prompt cards only become visible once you open the page in a browser, not when you fetch it plainly. The five patterns above and the sample prompts were there in the static content, but the full card collection behind them is more interactive than a plain text page. Worth remembering if you ever build documentation for a team yourself: how you display something determines how easy it is to find and reuse.

The page itself also recommends not retyping a prompt that works every time, but saving it as a skill or in your CLAUDE.md, so every new session starts with it already in place. Exactly why I keep tweaking this site’s own instructions file. See the full library yourself at code.claude.com/docs/en/prompt-library, and open the “Why this works” toggle on any prompt that catches your eye. That’s the part where you actually learn something.