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.