Prompt library

Every copy-paste prompt from the Handbook, grouped by part. 68 total.

GETTING STARTED

Part 1. Setup

I am installing Claude Code on [Mac / Windows] and got this error:

[paste the entire error]

Explain the fix step by step. I am a beginner and I have never used a
terminal before.

Part 2. The five rules

Commit this with a sensible message.
The app was working thirty minutes ago and now it is broken. Show me the
recent commits and revert to the last working one.
How do I see this in my browser?
Store this in an environment variable, not in the code. Then show me how
to confirm it is not going to end up on GitHub.

Part 3. The core loop

Before writing any code, give me a plan and wait for my approval.
How do I see this in my browser?
I have never built software before. I want a simple one-page web app:
[a tip calculator / my personal homepage / a packing list maker].

Use the simplest possible technology: plain HTML, CSS, and JavaScript in
one folder. No frameworks.

Give me a plan first. After building, tell me exactly how to open it in
my browser.

Part 4. Project memory and the one-page PRD

What does my CLAUDE.md say about how I want changes explained?

Part 5. Save points, GitHub, and working as a team

Commit this with a sensible message.
Push this to GitHub.
Create a GitHub repository for this project and push it. Make the
repository private. Walk me through any login steps.
Show me my recent commits.
The app was working thirty minutes ago and now it is broken. Show me the
recent commits and revert to the last working one.
Deploy this app to Vercel. Walk me through it step by step. I have never
done this before.
Create a private GitHub repository for this project and push it. Then
tell me how to add my teammates so they can push too, and what each of
them should do to get a copy onto their own laptop. Walk us through it.
Pull the latest changes from GitHub before we start.
Create a branch called signup-form and switch to it.
Push this branch and open a pull request. Summarize what changed in
plain English, so a teammate who did not write it can review it.
Show me what this pull request changes and explain it in plain English.
Flag anything that could break the app.
We have a merge conflict. Explain in plain English what two changes are
in conflict and which parts of the app each one affects. Do not pick for
me. I will tell you which one to keep.

FINDING WHAT TO BUILD

Part 7. Research agents

You are a market research analyst. Research this problem space:
[for example, "small landlords managing maintenance requests"].

1. Who has this problem? Estimate how many such people or businesses
   exist in the US. Show your reasoning and your sources.
2. What do they use today? List tools, spreadsheets, and manual
   workarounds.
3. Search Reddit, G2, Capterra, and app store reviews for complaints
   about current solutions. Quote 10 real complaints with links.
4. Why might this be newly solvable with AI in 2026? Be specific about
   which capability changed and when.

Write the findings to research/opportunity-scan.md with a source URL for
every claim. Flag anything you could not verify.
Search for complaints about [category of tool] from the last 18 months.
Look at G2, Capterra, app store reviews, and Reddit.

Group the complaints into themes. For each theme: how often it comes up,
three verbatim quotes with links, and whether it is a product problem or
a pricing problem.

Then search job postings for roles that involve [the task]. What are
companies paying humans to do here, and how much?

Write to research/complaints.md.
Research these competitors: [list them, or say "find the top 5 products
that do X"].

For each one: pricing taken from their pricing page with a link, three
core features, target customer, funding if it is public, and the three
most common complaints in their reviews, quoted and linked.

Output a comparison table in research/competitors.md.

Then answer: what does nobody serve well?

Mark any claim you inferred rather than verified with [UNVERIFIED].
Help me size the market bottom up for [product] at [price] per month.

Number of [target customers] in the US, times a plausible adoption
percentage, times price.

Use a real source for the population number. Give a conservative, base,
and optimistic case. State every assumption in a table I can defend to
an investor.

Do not use top-down logic. "One percent of a fifty billion dollar
market" is not a market size.
I claim [product] is newly possible because [specific AI capability].

Find evidence for and against. Look at benchmark results, product
launches, and adoption data from the last 18 months.

Then argue the strongest version of both counterarguments:
1. "This was already possible five years ago."
2. "This still is not possible."

I want to test my claim, not confirm it.

Part 8. Deciding which idea to keep

Keep it short. No introduction and no summary at the end. Do not repeat
my question back to me. Plain English. If you are not sure about
something, say so in one line rather than hedging all the way through.
Read the reports in research/.

I am choosing between these problem areas:
1. [area one]
2. [area two]

Score each from 1 to 5 on four things: how often the problem happens to
them, what it costs them today, whether anyone already pays to solve it,
and whether we have any way to reach these people.

Quote the line of research behind every score. Where the research does
not support a score, write "not established" rather than guessing.

Put it in one table.
We believe [the thing you believe, for example: an independent dog
walker would pay $40 a month for this].

List everything that would have to be true for that to hold, including
things about how these people work that we may not have thought of.

Then sort your list into three groups:
- things our research already established
- things we could find out by talking to five of these people next week
- things we cannot know yet
Based on the research in research/ and the gaps we just found, write
three things we could learn in the next two weeks that would mean we
should stop working on this idea.

Make each one specific enough that we would recognise it if it happened.
"People are not interested" is too vague to be useful.
Argue against this idea. I am not asking for a balanced view.

Give me the four strongest reasons [idea] fails, using only what is in
research/ and not what you assume.

For each reason, tell me what we could see or hear in the next two weeks
that would show it is happening.

Do not offer solutions and do not soften anything.
Use a subagent to review our decision.

Give it the research folder and tell it which problem area we chose. Ask
it one question: would somebody reading only this evidence have chosen
the same one?

Report back what it said, including anything it disagreed with.

Part 9. Talking to real people

Build a one-page landing site for [idea], for [the specific kind of
person it is for].

Include a headline that states the problem, three benefit bullets, and
one placeholder box where a screenshot would go.

Do not add a database, a login, a signup form, or any other features.
This is a page for showing to someone, not a product.

Make it look credible rather than fancy, then show me how to open it on
my own machine.
I am doing customer discovery for [idea], targeting [user].

Draft a 20-minute interview guide following The Mom Test rules:
- Do not pitch my idea
- Ask about their life and their past behavior
- No hypothetical "would you use this" or "would you pay" questions

Cover: their current workflow, the last time the problem happened, what
it cost them, what they have already tried, and what they pay for today.

Then review your own guide and flag every leading question you wrote.
Role-play a [busy restaurant owner in Dallas]. You are skeptical, busy,
and slightly annoyed at being pitched another app. Do not be agreeable.

I will practice my customer interview on you. Stay in character.

Afterwards, break character and grade me. Where did I pitch instead of
listen? Where did I ask leading questions? What did I fail to follow up
on?
Transcribe this recording into interviews/person-N.md. Keep the exact
wording. Do not clean up the grammar or summarize. I need the verbatim
quotes.
Read all files in interviews/.

Extract across ALL interviews:
1. Recurring pains, ranked by how often they came up and how intense
   they were, with verbatim quotes for each
2. Current workarounds people described
3. Any evidence of willingness to pay: money or time already spent
4. Statements that CONTRADICT our idea. Do not soften these. Quote them
   exactly.
5. What we should ask better next time

Write to research/interview-synthesis.md. Tag each finding with which
interviews it came from.
Now argue that our idea is wrong, using only the interview evidence.
Build the strongest case you can that we should not build this.
Draft a 6-question survey testing [specific hypothesis].

Rules: no leading questions, no double-barrelled questions, no questions
about hypothetical future behavior. Ask about what they have actually
done.

Then review your own draft and flag every question that violates those
rules.

BUILDING THE PRODUCT

Part 10. Scoping and the walking skeleton

Read CLAUDE.md and prd.md. We are building the MVP.

Propose the simplest architecture using Next.js, Supabase, and Vercel.

Then build a walking skeleton: the thinnest possible end-to-end version
where a user can [core action]. Ugly is fine. Working is mandatory.

Plan first. Then go one step at a time, and tell me what to test after
each step.

Part 11. Making it a real application

Add sign-in to the app using Supabase Auth. Support email and Google.

Explain in plain English what happens to a password, where the session
is stored, and what a user sees if they are not signed in.
Here is what our app needs to store, in plain English:

[for example: "Users. Each user has projects. Each project has documents
and a status. Each document has an AI-generated summary."]

Design the database tables for this in Supabase. Explain each table and
each relationship in plain English before you build anything.

Then tell me: what happens if a user deletes a project? What happens to
its documents?
I want the app to [AI feature].

Add a call to the Claude API for this. Explain where to get an API key,
how to store it safely as an environment variable, and roughly what each
call costs.

Add a sensible fallback message for when the API fails or is slow.
Read CLAUDE.md and prd.md first.

Add Vercel Web Analytics to this app. I have already clicked Enable on
the Analytics page for this project in the Vercel dashboard.

If this is a Next.js app, install the @vercel/analytics package and add
the Analytics component to the root layout. If it is a plain HTML site
with no package manager, tell me so, and follow the HTML instructions in
Vercel's Web Analytics quickstart instead.

Explain in plain English what you added, which file it is in, and what
it sends to Vercel when somebody opens a page.

Then add Vercel Analytics to the Stack section of CLAUDE.md.
I am about to add a Supabase database. Create a file called .env.local
in this project if it does not exist. Add the names of the two variables
you will need, one for the Supabase project URL and one for the
publishable key, with nothing after the equals signs.

Check that .gitignore lists .env.local. Then tell me the two names.
Read CLAUDE.md and prd.md first.

Add a Supabase database to this project. I have created the Supabase
project and put the project URL and the publishable key in .env.local.
Tell me what you expect those two variables to be named, and stop if
they do not match.

Here is what the app needs to store, in plain English:
[for example: "Notes. Each note has a title, some text, and the date it
was written."]

Explain each table in plain English before you build anything. Give me
any SQL to run as one block I can paste into the Supabase SQL Editor,
and tell me exactly where to paste it.

Turn on row level security for every table, and explain in plain English
who can read and who can change each table.

Then connect the app so that it saves to and reads from the database.

When it works, add Supabase to the Stack section of CLAUDE.md.
Create a file called .env.local in this project if it does not exist.
Add a line that reads GEMINI_API_KEY= with nothing after the equals
sign. Check that .gitignore lists .env.local.
Read CLAUDE.md and prd.md first.

I want the app to [AI feature, for example: "summarize the note the user
just wrote in two sentences"].

Add a call to the Google Gemini API for this. Use the @google/genai
package and the model gemini-3.5-flash. My key is in .env.local as
GEMINI_API_KEY.

The key is secret. Make the call from code that runs on the server, never
from the browser, and explain to me in plain English where that code
lives and why the browser cannot see the key.

Add a sensible fallback message for when the API fails, is slow, or has
hit its free usage limit.

Explain each step as you go.

When it works, add Google Gemini to the Stack section of CLAUDE.md.
I am about to add Stripe Checkout. Create a file called .env.local in
this project if it does not exist. Add the names of the two variables
you will need, one for the Stripe publishable key and one for the Stripe
secret key, with nothing after the equals signs.

Check that .gitignore lists .env.local. Then tell me the two names.
Read CLAUDE.md and prd.md first.

Add a payment step to this app using Stripe Checkout, the page that
Stripe hosts. I have put my Stripe sandbox publishable key and secret
key in .env.local. Tell me what you expect them to be named.

The product is [name] and it costs [price, for example $10, one time].

Use test keys only. Refuse to continue if either key starts with pk_live
or sk_live.

The secret key must only be used by code that runs on the server. Explain
in plain English what happens, step by step, from the moment the user
clicks "pay" to the moment they land back on our site.

Add a simple page for a successful payment and one for a cancelled
payment.

When it works, add Stripe (sandbox only) to the Stack section of
CLAUDE.md.
Read CLAUDE.md and prd.md first.

Add sign-in to the app using Supabase Auth. Email and password only for
now.

Explain in plain English what happens to a password, where the session
is stored, and what a user sees if they are not signed in.

Then update the row level security rules so that each signed-in user can
read and change only their own rows. Give me any SQL as one block for
the Supabase SQL Editor, and explain each rule in plain English.

When it works, add Supabase Auth to the Stack section of CLAUDE.md.
Create a file called .env.local in this project if it does not exist.
Add a line that reads RESEND_API_KEY= with nothing after the equals
sign. Check that .gitignore lists .env.local.
Read CLAUDE.md and prd.md first.

Add an email to this app using Resend. My key is in .env.local as
RESEND_API_KEY.

When [trigger, for example: "somebody submits the signup form"], send
[what, for example: "a short welcome email"].

I have not verified a domain, so send from onboarding@resend.dev and send
only to [the email address I signed up to Resend with]. Explain what
would need to change to email real users later.

The key is secret. Send the email from code that runs on the server, and
explain in plain English where that code lives.

If sending fails, the app should carry on working and should not show
the user an error.

When it works, add Resend to the Stack section of CLAUDE.md.
Read CLAUDE.md and prd.md first.

Add file upload to this app using Supabase Storage. I have created a
private bucket called [bucket name].

Users should be able to upload [what, for example: "one PDF or image"].
Accept only [file types] and refuse anything over [size, for example
5 MB], with a clear message.

Explain in plain English where the file goes, who is allowed to open it,
and what rule enforces that. Give me any SQL as one block for the
Supabase SQL Editor.

Show the user a list of what they have uploaded.

When it works, add Supabase Storage to the Stack section of CLAUDE.md.
Read CLAUDE.md and prd.md first.

Add live weather to this app using the Open-Meteo API, which needs no
API key.

Show [what, for example: "today's temperature and chance of rain"] for
[place], in [where on the page].

Explain in plain English what request the app sends, what comes back,
and how often it asks.

If the request fails or is slow, show a short, friendly message and keep
the rest of the page working.

When it works, add Open-Meteo to the Stack section of CLAUDE.md.
Create a skill called demo-check that runs through these steps: confirm
the app builds, confirm the live URL loads, confirm the signup flow works
end to end, and confirm no error messages appear in the browser console.

Explain what a skill is and where you are putting the file as you go.
Add a hook that blocks any commit containing a file called .env or
.env.local. Explain exactly what it will do, and when it will fire,
before you add it.

Part 12. Design and usability

Rewrite every piece of text in this interface: buttons, error messages,
empty states, form labels, and confirmations.

Make each one clearer and friendlier. Use plain language. Show me
before and after side by side.
Critique these screens against Nielsen's usability heuristics.

For each screen: what is confusing, what is missing (loading states,
empty states, error messages), and what violates visual hierarchy.

Also check accessibility basics: color contrast, font size, and whether
everything can be reached with a keyboard.

Then give me a prioritized top ten fix list, easiest first, phrased so
I can hand each item straight to Claude Code.
Define a small design system for this app: a color palette, a spacing
scale, and three text sizes. Then apply it consistently everywhere.

Part 13. Testing what you built

Act as a hostile QA tester on this app. Systematically try to break it:

- Empty inputs, absurdly long inputs, emoji, negative numbers, and
  SQL-looking strings in every field
- Double-clicking submit buttons
- Using the browser back button in the middle of a flow
- A brand new user with no data. What do the empty screens look like?
- A mobile-width screen
- What happens if the AI or API call fails, or takes 30 seconds?

For each issue: severity (breaks it / embarrasses us / cosmetic), how to
reproduce it, and the fix.

Write to qa-report.md. Then fix all the "breaks it" items one at a time,
re-testing after each fix.
Here are ten real inputs to our [AI feature] and the outputs it produced:

[paste all ten pairs]

For each one, evaluate: is this output actually useful to our user?
Is anything in it factually wrong? Is the tone right?

Then identify patterns in the failures. What kind of input makes this
feature perform badly?

Suggest changes to the prompt we send, and tell me which failures a
prompt change will NOT fix.
I check the same four things by hand every time before we ship. Turn
them into a skill called verify-ship:

[paste your four things, in plain English]

For each one, tell me how you would actually check it, and say so if
there is one you cannot check without me looking.

Then run it on what we just built and report what it finds.

Part 14. Shipping to real users

Review the database security rules for this app. Can any signed-in user
read or modify data belonging to another user? Show me exactly how the
rules prevent that, and test it.
Write a short, plain-language note for our site explaining what data we
collect, where it is stored, that we send [specific input] to an AI
service to provide [feature], and how someone can ask us to delete their
data. Keep it under 150 words and avoid legal jargon.

SHOWING THE WORK

Part 16. The pitch

Here is our pitch narrative: [paste].

Rewrite it in this arc:
1. Name the undeniable change in the world, specific to our market
2. Stakes: who wins and who loses because of it
3. The promised land for our customer
4. Our "magic": what we have that gets them there
5. Proof

Keep OUR evidence and numbers exactly as given. Do not invent or inflate
anything. Ninety seconds spoken, maximum.
You are a skeptical Series A investor who has seen 400 AI pitch decks
this year. Review my deck slide by slide [paste text or screenshots].

For each slide: what claim needs evidence, what a bored partner would
object to, and what to cut.

Be blunt. Then tell me the one slide that loses you, and why.
Generate the 20 hardest questions an investor would ask this venture.
Cover: moat when models improve, why the incumbent doesn't do this,
inference costs and margins, feature versus company, go to market, and
team credibility.

Then interview me. One question at a time. Interrupt vague answers.
Follow up twice before moving on.

Grade each answer from 1 to 5 at the end.