Paste this before you ask for any code. It stops the model inventing a stack you didn't ask for.
context-primer.txt
You are helping me build: <one sentence, what the thing does>
Stack I am already using: <languages, frameworks, hosting>
Files that already exist: <paste `ls` output or a short list>
What works right now: <the last thing you got working>
What I want next: <one change, not five>
Rules:
- Change the fewest files possible. Show me full file contents for anything you edit.
- Do not add new dependencies unless you say why and I agree first.
- If my request is ambiguous, ask one question before writing code.
- End with the exact command I run to see it working.
Why it works: most bad AI output comes from missing context, not a weak model. Nine lines of setup beats three rounds of "no, not like that".
Stop the model writing 400 lines in the wrong direction.
plan-before-code.txt
Before writing any code, give me a plan for: <the feature>
Format:
1. Files you will create or change, one line each, and why.
2. The order to do them in.
3. Anything you are unsure about — list it as a question for me.
Do not write code yet. I will say "go" when the plan looks right.
Understand the code you just generated, before it becomes a mystery.
explain-it-to-me.txt
Explain this code to me like I can program but have never seen this
library before. Go line by line for anything non-obvious, and at the end
tell me the one thing most likely to confuse me later.
<paste code>
Ten minutes here saves a weekend of building the wrong thing.
spec-from-idea.txt
Here is my idea: <one or two sentences>
Act as a sceptical product engineer. Before any code, write me a short spec:
1. The one job this does. One sentence, no "and".
2. Who uses it and what they have in their hand when they arrive.
3. The screens or steps, in order. Name each one.
4. What it explicitly does NOT do in version one.
5. The three things most likely to make this harder than I think.
Keep it under 400 words. Ask me anything you need before writing it.
The "does NOT do" list is the valuable half. An idea without a scope boundary expands to fill every session you have.
I want to build: <one sentence>
My situation:
- Experience: <none / some HTML / I can read code>
- I want to deploy to: <no idea / a cheap host / my own server>
- Budget: <£0 / a few pounds a month>
Recommend ONE stack. Not a comparison table — one recommendation, and
say why it beats the obvious alternative for someone in my situation.
Bias hard towards fewer moving parts over "modern". Then list every
account I will need to create before I write a line of code.
Ask for one answer. Given a menu, models will hand you five options ranked by popularity, and you will spend the afternoon choosing instead of building.
I have this project and I don't know my way around it: <paste the file
list, then the entry point>
Give me a map, in this order:
1. What happens when a request arrives, step by step, file by file.
2. Where state lives — database, memory, browser, files.
3. The three or four files that matter most, and what each is for.
4. Anything here that looks unfinished, unused, or duplicated.
Plain English. I'll ask about specific files after.
Most vibe-coded projects stall the day the author stops knowing where anything is. Rebuilding the map is a fifteen-minute job you can do any time.
Here's my feature list: <paste>
Rewrite each as a user story: who, what they're trying to do, and why
it matters to them. Then add acceptance criteria — specific,
checkable conditions for "done".
Then the useful part:
- Which of these are actually the same story described twice?
- Which describe a solution rather than a need? Rewrite those as the
underlying need, so the solution stays open.
- Which have no user behind them — features I want because they'd be
satisfying to build?
Be blunt about that last category.
"Features I'd enjoy building" is a real and respectable category. It just shouldn't be disguised as user demand in your planning.
Here's everything I planned to build: <paste the list>
Time available: <honest number>
Cut it to what actually fits. Specifically:
- What's the smallest version that still delivers the core value?
- Which items are I-would-enjoy-building rather than users-need-this?
- Which could be done manually by me, for the first fifty users,
instead of being built?
- What can ship visibly unfinished without embarrassment?
Give me a "version one" list and a "later" list. Be ruthless with
version one — I'd rather argue with you than run out of time.
"Could I do this by hand for the first fifty users?" removes more work than any other question. Most admin features are a spreadsheet until they aren't.
My project: <one sentence about what it does and who it's for>
Give me 15 name options in three groups:
- Descriptive — says what it does.
- Evocative — suggests the feeling or outcome.
- Made-up or compound — short and ownable.
For each: why it works, and one reason it might not.
Constraints: pronounceable out loud, spellable after hearing it once,
under 12 characters if possible, no unusual spellings of common words.
Then tell me which three you'd actually pick and why.
Say your shortlist aloud on an imaginary phone call. Anything you'd have to spell out is a name that will cost you every time you mention it.
Learn from what exists before rebuilding it worse.
competitor-teardown.txt
I'm building <my thing>. An existing tool doing something similar is
<name / description / paste their landing page>.
Analyse it:
- What job is it doing, in their words and in plain words?
- Who is it clearly for, and who is it clearly not for?
- What does their pricing tell me about their customer?
- What's conspicuously missing or obviously bad?
Then honestly: given they exist, why would anyone use mine? If the
answer is weak, say so and suggest where a genuine gap might be —
an audience, a price point, or a simplification.
Ask for the sceptical answer. "There's room for both" is the comfortable response and is often not true; better to find out now.
Explain <concept> to me. I'm building <what> and I've hit it.
In this order:
1. What problem does this exist to solve? What did people do before it?
2. The simplest possible correct explanation. An analogy is fine, but
tell me where the analogy breaks down.
3. A concrete example from my situation, not a generic one.
4. What people get wrong about it, and why.
5. What I can safely ignore for now.
Assume I can read code but don't know the vocabulary. Don't tell me
it's simple.
Point 5 saves the most time. Most concepts have a large surface area and a small part you actually need this week.
I've decided to <the decision> for <the project>.
Write it up as a short record:
- The decision, in one sentence.
- The context: what forced a choice here.
- The alternatives I considered and why each was rejected.
- What this makes easy, and what it makes hard.
- What would make me revisit this.
Keep it under 300 words. It goes in the repo, and the audience is me
in six months having forgotten all of this.
Ask me anything you need before writing it — particularly about the
alternatives, since I probably haven't stated them.
The "what would make me revisit this" line is the one with real value. It turns a decision into something with an expiry condition rather than an assumption you never re-examine.
Your estimate is missing the same things everyone's is.
estimate.txt
I want to build: <describe the feature>
My guess is: <your estimate>
Break it into tasks and estimate each. Then add the things I've almost
certainly forgotten:
- Error states, empty states, loading states.
- Validation, on both sides.
- The mobile layout.
- Testing it myself, properly.
- Deploying it and finding out what differs in production.
Give me a realistic total, and tell me which single task carries the
most uncertainty.
If my guess is badly out, say so and say why.
Estimates are wrong because they price the happy path. The unhappy paths are usually the larger half of the work.
For when you've been going back and forth for an hour.
choose.txt
I'm stuck between two approaches for <the problem>:
A: <describe>
B: <describe>
Don't give me a balanced comparison. Instead:
- What does each one make easy, and what does each make hard later?
- Which is easier to reverse if I'm wrong?
- Which would I regret at 10x my current scale?
- What's the question I should be asking that I'm not?
Then pick one and commit to it. If the honest answer is "it doesn't
matter, pick either and move on", say that — I'd find it useful.
"It doesn't matter" is a real and common answer. An hour spent choosing between two fine options costs more than either choice.
Written down before it does, it's a plan. After, it's an incident.
risk-list.txt
I'm building: <describe the project or feature>
Timeline: <how long>. Constraints: <what's fixed>.
List the risks — things that could stop this working or delay it. For
each:
- How likely, honestly.
- What it costs me if it happens.
- The cheapest thing I could do now to reduce it, or to find out
early.
Include the boring ones: a dependency I've never used, an API whose
limits I haven't read, a step I'm assuming is easy.
Rank by likelihood times cost, and tell me which one to test first.
The risk worth attacking first is rarely the biggest one. It's the one you can cheaply prove or disprove today.
I'm considering using <library> for <purpose>. Stack: <stack>.
Assess it:
- Is it actively maintained? When was the last release, and how
responsive is the issue tracker?
- How big is it, and what does it pull in with it?
- What's the licence, and does it constrain what I can do?
- What's the realistic migration cost if I need to remove it later?
- Is there something in the standard library or the platform that
covers my case?
Then: what would I have to build myself, and how long would that take
including the edge cases?
If you're not confident about the current state of this library, say
so rather than guessing.
Ask what it pulls in. A small library with forty transitive dependencies is not a small library.
For when the list is long and none of it feels urgent.
what-next.txt
Here's everything on my list: <paste>
Where the project is: <live with users / not launched / prototype>
Time I have this week: <hours>
Tell me what to do next and why. Consider:
- What unblocks the most other things?
- What would I learn most from — what reduces uncertainty?
- What's cheap now and expensive later?
- What's on this list because it's enjoyable rather than important?
Pick one thing. Not a prioritised list — one thing to start now.
Ask for one. A ranked list of twelve is a way of not choosing, and you'll re-rank it tomorrow instead of building.
The document that stops scope arriving by accident.
write-spec.txt
Feature: <describe it, however roughly>
Write a short spec:
- The problem, in the user's terms, not mine.
- What "done" looks like — specific, checkable conditions.
- The flow, step by step, including what happens when each step fails.
- Data: what's stored, what's changed, what's sent anywhere.
- Explicitly out of scope, at least five things.
- Open questions you need me to answer.
Under 600 words. Ask me the open questions before writing if any of
them change the shape of the spec.
The out-of-scope list is what the spec is for. Without it, scope arrives one reasonable-sounding addition at a time.
The first build, sized to what you're actually running.
plan-v1.txt
I'm building <one sentence>. Stack: <stack>. It will run on <host>.
Plan the smallest version one:
- The screens or steps, in order, from arriving to the moment it's useful.
- The files I'll create, one line each on what they do.
- Anything this stack or host makes harder than it sounds, and what
you'd do about it.
- What's explicitly left out of version one.
Don't write code yet. Keep it to what one person can finish in a weekend.
Naming the host up front changes the plan. "Store it in a file" and "run a background worker" mean very different things on shared hosting and on a container platform.
A sanity check before the first file, not after the fiftieth.
stack-check.txt
I'm about to build <one sentence> using <stack>, hosted on <host>.
Be honest:
- Is this a good fit, a workable fit, or a mistake?
- Which part of what I'm building will this stack make awkward?
- Is there anything the host can't do that this project will need?
- If you'd change one thing, what and why?
If the answer is "it's fine, stop worrying and build it", say that.
Most stacks are fine for most first projects. The useful answer is the one awkward part, so you can plan round it rather than find it in week three.
Where things go, before the model invents a layout per session.
project-structure.txt
I'm starting <one sentence> with <stack>, deploying to <host>.
Propose a folder and file layout:
- What goes where, with one line on each folder's job.
- Which folder is the web root, and what must never be inside it.
- Where configuration and secrets live.
- Where tests go, if any.
Follow the conventions people expect for this stack rather than
inventing new ones. Keep it as flat as it can be for a project this size.
Save the answer in your project brief. Without an agreed layout, each new chat puts files somewhere slightly different, and after a month nobody knows where anything is.
The monthly bill at ten users, a thousand, and a hundred thousand.
hosting-cost.txt
I'm building <one sentence> with <stack>, hosted on <host>.
Estimate what hosting costs at 10, 1,000 and 100,000 monthly users.
Show your assumptions so I can change them.
- Which of the host's limits do I hit first as usage grows?
- At what point do I need a bigger plan or a different kind of hosting?
- Which extra services will I end up paying for: database, email,
storage, backups?
- What's likely to cost more than I expect?
Give me the number that matters now, and the one I should watch.
For most side projects the honest answer is "the plan you're on, for a long time". It's still worth knowing which limit you'll hit first.
The best database is one your host already runs and backs up.
database-choice.txt
I'm building <one sentence> with <stack> on <host>. It needs to store
<what it stores>.
Recommend one database and defend it:
- Which databases this host provides, and which it backs up.
- Whether SQLite, a single file, is enough for my scale, and when it stops
being enough.
- What my stack talks to most easily.
- How I'd move to something else later if I had to.
Pick one. Don't give me a comparison table.
A database the host already runs and backs up beats a better one you have to run yourself. For a small project, that difference is most of the work.