Claude Code Prompts: I Shipped a Real Feature and Logged Every One (Including the 3 That Wasted My Afternoon)

Here's the thing those posts get structurally wrong.

They treat the prompt as the input and the code as the output. Prompt in, magic out. So the whole game becomes finding better prompt words.

But that's not how Claude Code actually behaves. The prompt is maybe 20% of the result. The other 80% is context — what the tool already knows about your project before you type anything. Same prompt, two different repos, wildly different output. Anyone who's used it on real work has felt this.

Which means a list of 50 prompts is optimising the smallest variable.

The prompts below are real and you can absolutely steal them. But they only work because of the setup in Stage 1. If you skip that part and just copy the prompts, you'll get the same mediocre results you're getting now, and you'll assume the tool is overhyped.

The job: fix a slow site, without breaking it#

Real context, so you can judge whether this applies to you.

I had a Next.js content site — a few hundred pages, blog articles, a bunch of free developer tools, two languages. Traffic was fine. Speed was not. Mobile PageSpeed was sitting in the 70s and Largest Contentful Paint (LCP) was ugly.

Goal: make it genuinely faster, without breaking a site that people were actively using.

That last clause is the whole difficulty. Making a site fast is easy if you're allowed to break it.

Stage 1: The setup that makes every later prompt better (CLAUDE.md)#

Before I typed a single "fix this" prompt, I did the thing I used to skip.

Claude Code reads a file called CLAUDE.md and loads it into context at the start of every session. Put it at your project root (./CLAUDE.md), or ./.claude/CLAUDE.md if you like things tidy. There's also ~/.claude/CLAUDE.md for personal preferences that follow you across every project.

You don't have to write it from scratch. Run:

        1
        /init
      

It reads your codebase and drafts one for you. Then you edit it, because the draft is generic and your project isn't.

What actually earned its place in mine:

        1
2
3
4
5
6
7
8
9
10
11
12
13
14
        ## Commands
- Build: `npm run build`
- Typecheck: `npm run typecheck`
- Lint: `npm run lint` (must stay at 0 errors)

## Conventions
- Next.js App Router. Server components by default.
- Only add 'use client' when a hook genuinely needs it.
- next-intl for i18n — never hardcode user-facing strings.

## Rules
- Never commit or push unless I explicitly ask.
- Always run typecheck + build before saying something is done.
- If a change touches production behaviour, tell me before doing it.
      

That's it. Short. Boring. It changed more about my results than any clever prompt ever did.

Two things about CLAUDE.md that most posts get wrong#

It is not a system prompt. This one matters. CLAUDE.md gets injected as a regular message — it's strong guidance, not an iron rule. Claude reads it and genuinely tries to follow it, but it's not physically prevented from doing otherwise. So when you write "NEVER DO X" in all caps and it does X anyway, that's not a bug. It's guidance losing to a conflicting instruction later in the conversation.

If you need something to be actually impossible — not just discouraged — that's a job for a PreToolUse hook, which can hard-block a tool call. Different tool, different guarantee.

Shorter is better. Keep it under ~200 lines. This feels backwards — more instructions should mean more control, right? — but a bloated CLAUDE.md burns context on every single request and, counterintuitively, reduces how well the instructions get followed. Mine is about 40 lines and that's deliberate.

If you've got a lot of rules, don't cram them all in. Put path-specific ones in .claude/rules/ with frontmatter so they only load when relevant:

        1
2
3
4
5
6
        ---
paths:
  - "src/api/**/*.ts"
---
# API rules
- Every endpoint validates its input.
      

Now those rules cost you nothing until Claude actually opens an API file.

The honest test for what belongs in CLAUDE.md: did you have to correct the same mistake twice? Then it goes in the file. Everything else is noise.

Stage 2: The highest-leverage "prompt" isn't a prompt#

The single biggest change to my workflow wasn't a prompt at all. It was plan mode.

Hit Shift+Tab to cycle into it, or type /plan. In plan mode, it reads your code, searches around, figures out what's going on — and proposes a plan without touching your source files.

Why this matters so much: the worst outcome with an AI coding tool isn't a bad answer. It's a confident, plausible, 14-file change built on a wrong assumption about your architecture. Plan mode is where you catch the wrong assumption while it's still free to fix.

Here's the actual prompt I used:

        1
2
3
4
5
6
        Audit this Next.js App Router site for Core Web Vitals problems.
Focus on: what the LCP element actually is on the homepage and article
pages, render-blocking resources, and which routes are dynamic that
shouldn't be.

Report findings with file:line references. Don't change anything yet.
      

Note what's in there: a specific scope, a specific output format (file:line), and an explicit "don't change anything." Compare that to "make my site faster," which is what I would have typed six months ago.

It came back with a proper list. One finding I would never have found on my own: my homepage hero image was hidden behind an IntersectionObserver, meaning the LCP image wasn't in the server HTML at all — it couldn't start loading until JavaScript had downloaded and hydrated.

That's the kind of thing you get when you make it look before it leaps.

One gotcha worth knowing: plan mode blocks edits to your source, but it still runs read-only commands and searches. It's not a total freeze. That surprised me the first time.

Stage 3: The prompts that did the real work#

Now the actual work. These are copy-pasteable, but notice the shape of them more than the words.

The audit prompt (delegate the reading)#

When a task means reading twenty files, don't do it in your main conversation — it'll eat your context and you'll be compacting in ten minutes. Hand it to a subagent instead:

        1
2
3
        Use a subagent to map every component in src/components that renders
an image. For each: file path, whether it uses next/image, whether it
sets `sizes`, and whether it's above the fold. Return a table only.
      

Subagents run with their own separate context and hand back just the summary. Your main session stays clean. This is genuinely one of the most underrated features in the whole tool and I've never once seen it in a "50 prompts" post.

The narrow-fix prompt#

The mistake I made for months was asking for big changes. "Optimise the images." Now I ask for exactly one thing:

        1
2
3
4
5
6
7
        In src/components/home-page/slider-with-listing.tsx, the first slide's
image is gated behind the IntersectionObserver so it isn't in the SSR
HTML.

Change ONLY the first slide (index 0) to render eagerly so it lands in
the server HTML. Leave slides 1+ lazy. Don't touch anything else in
the file.
      

"Don't touch anything else in the file" earns its keep. Without it you get helpful little drive-by refactors you didn't ask for and now have to review.

The "explain before you change" prompt#

When I don't understand the code yet:

        1
2
        Explain why this component is a client component. What specifically
requires the client runtime? Answer first — don't edit.
      

Half the time the answer reveals the change I wanted is unnecessary. That's a win.

The verification prompt#

        1
2
        Run typecheck, lint, and build. Show me the actual output. If anything
fails, don't fix it yet — just show me.
      

"Show me the actual output" is doing real work in that prompt. Without it you get "All checks pass!" and no way to know if that's true.

Stage 4: The prompt that wasted my afternoon#

Okay. The part I actually want you to read.

Remember the hero image finding — LCP image stuck behind an observer, not in the server HTML? Textbook problem. Textbook fix. I told it to render the first slide eagerly and preload it. Clean change. Build passed. Shipped it.

LCP went from bad to 7.3 seconds. Worse. Measurably, embarrassingly worse.

I stared at that number for a while, because every piece of advice on the internet says "don't lazy-load your LCP image." I'd done the recommended thing and it backfired.

Here's what was actually happening, and it's a genuinely useful lesson:

Before my change, the hero image loaded so late that the browser never counted it as the LCP element at all. LCP was falling back to a text heading that painted almost instantly. The metric looked fine because the slow thing was invisible to it.

My "fix" made the 90KB hero image load properly — which made it the real LCP element. And on throttled mobile, that image was queued behind 146KB of preloaded fonts all fighting for the same tiny pipe. So the honest LCP — the one that was always there, just hidden — finally showed up.

I hadn't broken performance. I'd revealed it. But the number got worse, and the number is what Google ranks.

The real fix wasn't reverting. It was getting the fonts off the critical path so the image could actually download:

        1
2
3
        The LCP image is being preloaded but still paints at 7.3s on Slow 4G.
Check what else is preloaded and competing for bandwidth on the
critical path. Don't change anything — tell me what you find first.
      

Answer: three fonts, 146KB, all preload: true, all jumping the queue ahead of the image. One of them was the code font — used only in code blocks that are nowhere near the top of the homepage.

Turning font preloading off (with display: swap already set, so text still paints instantly in a fallback) freed the pipe.

The three prompts that wasted the afternoon#

Being specific, because this is the useful bit:

1. "Fix the LCP on the homepage." Too vague. It made a reasonable change to a real problem, but nobody had checked which element was even the LCP. Measure first.
2. "Are you sure that's correct?" Useless. It just re-litigates and usually agrees with you. Ask for evidence instead: "Show me the actual preload links in the built HTML." Facts beat vibes.
3. "Just make it faster." This is me being lazy and hoping the tool would do the thinking. It can't read your mind about what "faster" means — FCP? LCP? TBT? They pull in different directions, and optimising one can wreck another. Which is exactly what happened.

The lesson I'd tattoo on my hand: an AI coding tool will confidently do the textbook thing. The textbook thing is right on average and wrong on your specific site more often than you'd like. Measure before, measure after, and be suspicious when a change "obviously" can't hurt.

Stage 5: Verify — the step everyone skips#

Claude Code will tell you a change is done. It's usually right. "Usually" is the problem.

My CLAUDE.md has "always run typecheck + build before saying something is done" for this exact reason, and I still ask for the raw output.

One thing worth understanding: checkpoints only cover file changes. You can rewind an edit. You cannot rewind a deployed build, a dropped database row, or a pushed commit. That's precisely why "never commit or push unless I explicitly ask" lives in my CLAUDE.md — file mistakes are cheap, remote mistakes are not.

The prompt patterns that actually survived#

If you strip the specifics away, everything that worked follows four patterns. This is the real takeaway — patterns transfer between projects, prompt scripts don't.

Notice what's not in there: no "act as a senior staff engineer," no "take a deep breath," no roleplay. None of it survived real work. What survived is boring: be specific, ask for proof, keep changes small.

Context: the thing that quietly ruins long sessions#

One more thing you'll hit on any real job, and it's not in the listicles.

Long sessions get worse over time. Not your imagination. As context fills, older tool output gets cleared and the conversation gets summarised. Things you said an hour ago get compressed away.

The practical consequences:

• Anything you only said in chat can vanish. If it matters past this hour, it belongs in CLAUDE.md, not a message.
• /compact and /clear are different. /compact summarises and keeps going in the same session. /clear starts fresh. Reach for /clear between unrelated tasks — it's cheaper than dragging irrelevant history around.
• /context shows you what's eating space. Run it when things feel sluggish. It's usually one giant file read you forgot about.
• Use subagents for anything that reads a lot. That's the whole point of them.

The heuristic I use: if a task will read more than ~5 files and I don't need the details afterwards, it goes to a subagent.

What Claude Code is genuinely bad at#

If a post only tells you what a tool is good at, it's marketing. Honestly, after a lot of real hours:

• It doesn't know what you didn't say. It filled a gap with a sensible default and the default was wrong for me. That's the LCP story in one line.
• It's confidently textbook. Best-practice advice, applied without measuring your actual situation. Great baseline, occasionally exactly wrong.
• Long sessions drift. Instructions from an hour ago quietly stop applying after compaction.
• It can't undo the world. Checkpoints cover files. Deploys, DB writes, and pushes are yours to own.
• It'll agree with you. Push back with "are you sure?" and you'll often just get capitulation. Ask for evidence, not reassurance.

None of this makes it not worth it. I got a genuine performance win, a subagent-driven audit that found things I'd have missed, and a whole class of tedious work done fast. But I got there by treating it like a very fast junior who's read every doc and has never seen my codebase — not like an oracle.

FAQ#

Why does Claude Code ignore my instructions?#

Usually one of three things. Your instruction was only in chat and got compacted away — put it in CLAUDE.md instead. Or your CLAUDE.md is so long that adherence dropped (keep it under ~200 lines). Or you're expecting a hard guarantee from what is actually strong guidance — CLAUDE.md is injected as a message, not enforced. For genuinely unbreakable rules, use a PreToolUse hook.

What is CLAUDE.md and do I actually need one?#

It's a markdown file at your project root that gets loaded into context every session — build commands, conventions, and "never do X" rules. And yes. It's the single highest-return thing on this page. Run /init to generate a first draft, then trim it. Without one, every prompt starts from zero.

How do I stop Claude Code from breaking working code?#

Scope your prompts to one file, add "don't change anything else," use plan mode for anything architectural, and put "always run typecheck and build before saying you're done" in your CLAUDE.md. Small reviewable diffs are the entire game.

Do I need to write long, elaborate prompts?#

No. Specific beats long. "In x.tsx, change only the first slide to load eagerly, don't touch anything else" beats three paragraphs of persona roleplay. The persona stuff ("act as a senior engineer") does almost nothing — I've stopped writing it entirely.

Is plan mode actually worth the extra step?#

For anything touching more than one or two files, yes. It's the cheapest place to catch a wrong assumption. Just know it still runs read-only searches and commands — it only blocks edits to your source.

Are those "50 Claude Code prompts" lists useless then?#

Not useless — just aimed at the wrong variable. Skim one for ideas. But a prompt you copy without the context setup behind it will underperform, and then you'll blame the tool. Fix the context first; the prompts get better on their own.

What I'd tell you if we were sitting together#

Delete your prompt collection. Seriously.

Spend that twenty minutes writing a CLAUDE.md instead — commands, conventions, and the two or three rules you're tired of repeating. Then use plan mode before anything non-trivial, keep every change small enough to actually review, and ask for the real output instead of a summary.

That's it. That's the whole thing. It's much less exciting than "50 hacks," which is probably why nobody writes it.

And when a change makes your numbers worse — measure again before you revert. Sometimes you didn't break it. Sometimes you just finally uncovered what was broken the whole time.

Working out which AI coding tool to actually pay for? I've written a full breakdown in Claude Code vs Cursor and a wider comparison in Best AI Coding Agents in 2026 . If you're using both, there's a way to combine them that costs less than you'd think.

More free developer tools and cheat sheets: CodeAiKit Tools · Git Commands Cheat Sheet