Claude Code Prompt Generator
Turn a vague idea into a Claude Code prompt that actually ships.
- $29 Free
- 20 sec
- No signup
Describe your goal and your stack
Pick your constraints and tone
Copy the finished prompt straight into the CLI
You get: A structured, paste-ready Claude Code prompt with plan and acceptance criteria.
Your task
Constraints
Acceptance criteria
Out of scope (optional)
Your prompt
# Task: Build a new feature ## What Add a /reports route that lists the user's last 10 generated PDFs with download links. ## Context - **Stack:** TypeScript / Next.js - **Surface area:** PR / change branch PDFs are stored in Supabase Storage under a bucket named `reports`. Auth is already wired via Clerk. The /reports route should be a server component. ## Constraints - Do not introduce new dependencies - Match existing file structure and naming - Add a test that proves the change works - Keep changes under 100 lines of diff ## Plan first, then execute Before writing or editing any code, do the following: 1. Read the relevant files end-to-end. Do not skim. 2. Write a 3-5 step plan in plain English. List the files you will touch and why. 3. Wait for me to confirm the plan, then implement it. ## Acceptance criteria - /reports renders without errors when logged in. - The list is sorted by createdAt descending. - Each row has a working download link. - Lint and typecheck pass. ## Out of scope Pagination beyond 10 items. Bulk download. Email delivery. ## When you are done - Summarize the diff in 3 bullets. - Call out anything you changed that was not in the plan above. - Suggest one follow-up change you noticed but did not make.
Paste into Claude Code as your first message.
Why a structured prompt beats freestyle
Claude Code will happily run on a one-line prompt - 'add a reports page' is a valid input. The output you get back will also be one-line quality: it picks a reasonable interpretation, makes a dozen guesses about your codebase, and ships something that compiles. Sometimes that is what you want. More often you spend the next twenty minutes correcting it. A structured prompt is the cheapest insurance policy in the workflow. You spend ninety seconds writing it and you cut iteration time in half.
The generator above writes prompts in the format that consistently produces the cleanest output: goal, what, context, constraints, plan-then-execute, acceptance, out-of-scope. Each section is doing real work. The 'goal' tag tells the model the shape of the answer. The 'context' section pre-loads the facts the model would otherwise ask for. The 'plan first' instruction kills the most expensive failure mode - the model writing 800 lines in the wrong direction because it never paused to check. The 'acceptance criteria' gives it a self-check before it returns control. None of this is magic, but together it is the difference between a prompt that ships and one that needs three follow-ups.
What goes in each section
- Goal - one of seven categories. Tells the model whether you want a green field build, a surgical fix, or a careful refactor. Each one has a different default risk tolerance.
- What - the concrete change in plain English. Be specific about user-visible behavior, not implementation details.
- Context - the facts the model cannot derive from the code. Where data lives. Which framework. Which library version. Who calls this code.
- Constraints - the rails. 'Do not introduce new dependencies' and 'do not touch unrelated files' are the two most underused constraints in the entire workflow.
- Plan first, then execute - the line that prevents over-eager edits. Forces the model to read the code, write a 3-5 step plan, and pause for confirmation before writing a single line.
- Acceptance criteria - your definition of done. The model will self-check against these before declaring the task complete.
- Out of scope - what you explicitly do NOT want done. Stops feature creep, which is the silent killer of long Claude Code sessions.
Constraints carry more weight than you think
Every constraint you add removes an entire branch of bad output. 'Match existing file structure and naming' alone prevents the model from inventing a new state management library because it thought your old one was 'outdated'. Be generous with constraints.
Plan-first is not optional
The single biggest mental model shift between 'using Claude Code casually' and 'using Claude Code professionally' is the plan-first habit. Casual use: paste prompt, watch it write code, hope for the best. Professional use: paste prompt that ends with 'write a plan first, wait for me to confirm, then implement.' The model writes the plan. You read it. If it is going in the wrong direction, you redirect now - before any code is written and before any context is wasted. If it is going in the right direction, you say 'go' and the implementation lands cleanly.
The math here is simple. A wrong plan caught at the planning stage costs you thirty seconds. A wrong plan caught after implementation costs you the implementation tokens, the diff review time, the rollback, and the re-prompt. Plan-first is a free option on quality, and the generator above bakes it in by default.
When to deviate from the template
The structured format earns its keep on tasks that involve more than one file or more than one concept. For one-line changes - 'rename this function', 'add a console log here' - the overhead of the template is more than the task is worth. Use freestyle for trivia, structured prompts for anything that touches more than one file or that you cannot mentally rehearse start-to-finish in five seconds. The split lands somewhere around eighty percent structured, twenty percent freestyle for most working sessions.
Pair this tool with CLAUDE.md
The prompt template is the per-task layer. CLAUDE.md is the per-project layer. Together they cover the two scopes where Claude Code reads context: 'what does this codebase want' and 'what does this task want'. If you have not written your CLAUDE.md yet, the generator on the previous tool will scaffold one in under a minute. Run both, paste both, and the model has the full picture before it writes its first line.
Frequently asked questions
Why is 'plan first' so important?
It catches direction errors before they cost you implementation tokens. A 30-second plan review beats reviewing 500 lines of misaligned diff every time.
Can I edit the output before pasting it?
Yes - the output is a starting point, not a contract. Treat it like a draft. Cut sections you do not need. Add specifics the form did not ask about.
Does this work for non-code prompts?
The template is tuned for code tasks - build, fix, refactor, test, document, set up, migrate. For non-code prompts (writing copy, summarizing docs), use a simpler 'goal + context + acceptance' shape.
Should every prompt be this structured?
No. Use it for tasks that touch more than one file or more than one concept. For one-line changes, the overhead is more than the task is worth.
What is the difference between this and CLAUDE.md?
CLAUDE.md is loaded automatically every session and describes the project. Prompts are written per task and describe what you want done right now. They stack, they do not compete.
Why are constraints listed separately from acceptance criteria?
Constraints are about the path - 'do not do X on the way'. Acceptance is about the destination - 'this is what done looks like'. The model treats them differently, and so should you.
Liked this tool? The club is the next step.
Join Claude Code Club for $9/month. 400+ lessons, weekly updates, and the workflows behind every tool on this site.
- No experience needed
- Cancel anytime
- Updated weekly