The copy-paste prompt kit

I'm building [what you are building] for [who it is for]. The problem it solves: [the problem it solves].

Write 10 one-sentence descriptions of it, each under 20 words, in this shape: "[Product] helps [who] [do what] without [pain]."
Vary the angle: the result, the time saved, the worry removed, the old way it replaces.

Then pick the 3 strongest and say in one line why each works. Point out any vague word in my own description and what to say instead.
No hype words: no "revolutionary", "seamless", "unlock", "empower".

I want to talk to 5 people from this group: [who it is for], about this problem: [the problem it solves], before I build [what you are building].

1. Write a 4-line message I can send to someone I don't know, asking for 15 minutes. No pitch and no product: make it easy to say yes or no.
2. Write 8 questions about what they actually did the last time they had this problem (what they tried, what it cost them, who else was involved). No questions about my idea, no leading questions.
3. List 5 answers that mean "real problem" and 5 that only mean "polite interest".
4. Give me a short note template to fill in right after each call.

Here is everything I want [what you are building] to do:
[paste your feature list]

Act as a ruthless product lead. The goal: someone from this group, [who it is for], gets the main result once, end to end.
- Keep only what that needs. Call it version 1.
- For every feature you cut: one line on why it can wait, and what would bring it back.
- Estimate version 1 in days for one person, and name the riskiest part to build first.
Answer with a table: Feature | Keep or cut | Why.

Write a CLAUDE.md file (the brief AI coding assistants read first) for my project, [what you are building]. If anything below is missing, ask me up to 5 questions before writing.

Stack: [framework, language, database, hosting]
Commands: [install, dev, test, lint, build]

Sections, in this order, short and specific to this project:
1. What the product does, in 3 lines.
2. The commands, as a list I can copy.
3. Folder map: the 6 to 10 folders that matter, one line each.
4. Rules: code style, naming, and what never to do (commit secrets, edit generated files…).
5. How to check work before saying "done": the exact commands.
6. Gotchas: what surprised me in this codebase.
Under 120 lines. No advice that would fit any project.

Before writing any code, plan this change: [describe the change]

Give me:
1. The files you will touch, and why, one line each.
2. The steps in order, each small enough to check on its own.
3. What could break elsewhere, and how we will know.
4. One question, if anything is unclear.
Then stop and wait for my OK. No code yet.

Something is broken.
Expected: [what should happen]
Actual: [what happens instead]
Error and logs:
[paste the exact error and the lines around it]
What changed recently: [the last change, if you know it]

1. List the 3 most likely causes, ranked, with the evidence for each.
2. For the top one, give me one small experiment that proves or rules it out (a log line, a test, a command), and what each result would mean.
3. Only propose a fix once the cause is confirmed. Keep it minimal and explain why it works.

Review this change as the senior engineer who will have to maintain it. Be direct.
[paste the diff or the files]

Check, in this order:
1. Bugs: wrong logic, unhandled errors, edge cases (empty, huge, duplicate, slow network).
2. Security: user input reaching SQL, HTML, the shell or file paths; secrets; missing permission checks.
3. Data: anything that could lose or corrupt user data, or can't be undone.
4. Readability: names and structure a newcomer would trip on.
For each finding: must fix, should fix or nit; where; why; the fix. If it's fine to ship, say so in one line.

Write tests for this code:
[paste the function or module]
Test runner: [Vitest, Jest, pytest…]

Cover what breaks in real life, not only the happy path: empty and missing input, limits, wrong types, duplicates, dates and time zones, the thing it calls failing.
One test per behaviour, named as a sentence ("rejects an email without a domain").
Mock only the network and the clock.
If a behaviour looks like a bug, list it instead of writing a test that locks it in.

Write the top of the landing page for [what you are building], for [who it is for], whose problem is: [the problem it solves].

Give me 3 versions, each with:
- A headline under 10 words that states the result, not the feature.
- One or two sentences under it: how it works and why it's different.
- A button label of 2 to 4 words that says what happens on click.
- One line of proof I could honestly show (a number, a quote, a guarantee). If I have none yet, tell me what to collect.
Plain words a 12-year-old would understand, no hype. Then tell me which version to test first, and why.

Interview me to write my About page. Ask one question at a time, six in all: what I make, who it's for, why I started, something I believe that others in my field don't, a result I'm proud of, and what people can do next.

When I have answered all six, write the page:
- First person, short paragraphs, under 300 words.
- Open with what I do for the reader, not my life story.
- Keep my own words where they're good.
- End with one clear next step (try [what you are building], join my newsletter, or write to me).
Then give me a one-line bio and a three-line bio for my profiles.

I'm launching [what you are building] for [who it is for] on [date]. It solves this: [the problem it solves].
The offer: [price, launch discount, deadline]

Write:
1. A launch post for [LinkedIn, X or Bluesky]: a first line that stops the scroll (never "I'm excited to announce"), the story in 4 to 6 short lines, one link, and one question that invites replies.
2. The launch email to my list: 3 subject lines under 45 characters, then a body under 150 words (what it is, who it's for, the offer and its deadline, one link).
3. A short reminder email for the last day of the offer.
Write like a person, not a brand.

Help me price [what you are building] for [who it is for].
What it saves them: [time, money, risk]
What they use today, and what it costs: [alternatives and prices]
My costs per customer: [hosting, payment fees, support time]

1. Propose 2 or 3 plans, or just one if that's better (say why). For each: name, price, who it's for in one line, and what's included written as results, not jargon.
2. Tell me which plan most people should pick, and how the page should show it.
3. Write 5 short pricing answers: refunds, cancelling, my data after I leave, changing plans, invoices.
4. Point out anything in my pricing that will bring support emails.

Here is an article I wrote:
[paste the article]

Turn it into 7 posts for [platform], one a day:
- Each stands on its own and makes one point from the article.
- Mix the formats: a story, a list, a mistake I made, a view people will disagree with, a how-to, a quote from the article, a question.
- First line under 12 words, under 120 words each, no hashtags.
- Only 2 of the 7 link to the article.
Keep my voice: my sentence length, my words.

A customer wrote this:
[paste the email]
What happened, and what I can and can't offer: [context]

Write a reply that:
- Opens by naming their problem in their own words.
- Says clearly what I will do and when, or why I can't, without hiding behind a policy.
- Offers one concrete next step.
- Stays under 120 words, warm but not grovelling, never "we apologize for any inconvenience".
Then a second version for if they are right and I messed up, and one line on what to fix so it doesn't happen again.

Run my weekly review for [what you are building]. Ask me these questions one at a time:
1. What did I ship this week?
2. What moved the number that matters most right now ([sign-ups, sales, active users…]), and what didn't?
3. What did users say or do that surprised me?
4. What am I avoiding?
5. What one thing would make next week a success?

Then summarise: 3 wins, 1 lesson, 1 thing to stop, and the 3 tasks for next week ordered by impact. Tell me plainly if the plan is too big for one week.