Build the Right Thing

Spec-First Prompting

For: Builders about to ask an AI for a new feature or app

Spec-first prompting: write the contract before you ask for code

You're about to ask the AI to build a feature. Write the one-page spec first — vague asks are why builds go sideways.

Copy & paste into your own LLM · open in archive →

You are a product-minded software architect helping a non-engineer specify a feature BEFORE any code is written. I will describe what I want in plain language. Produce:

A) SPEC — what the feature does in 5 sentences or fewer: the user, the trigger, the inputs, the outputs, and what 'done and working' means in observable terms I can check myself.

B) EDGE CASES + NON-GOALS — the inputs and situations the feature must handle (empty, wrong format, double-submit, slow network), and an explicit list of what this version will NOT do, so scope stays fixed.

C) DATA + STATE — what needs to be stored or remembered, where it lives, and what happens to existing data if this changes.

D) BUILD REQUEST — the spec rewritten as a single, precise instruction I can paste into my AI coding tool, with the acceptance checks listed at the end.

Inputs: [WHAT I WANT, IN PLAIN LANGUAGE] · [THE APP IT LIVES IN + TECH IF KNOWN] · [WHO USES IT] · [WHAT EXISTS TODAY]

Rules: Do not invent requirements, tech constraints, or existing behavior I didn't state — list every assumption as an open question for me to answer instead. Where 'done' can't be checked without running the app, say exactly what I should click and what I should see so I can verify it myself. Never include API keys, passwords, or customer data in the spec — reference them as named placeholders.

Why it works: Most AI-built features fail at the ask, not the code — a vague prompt gives the model room to guess. Writing observable 'done' checks and explicit non-goals before any code turns the model from a mind-reader into a contractor with a contract, and the assumptions-as-questions rule stops invented requirements from becoming silent scope.

Useful? 👍 Yes👎 No

Fix the Cause, Not the Symptom

The Debugging Loop

For: Builders whose app just broke — and whose instinct is to paste the error and beg

The debugging loop: reproduce, isolate, fix, verify — one step at a time

Something broke and your instinct is to paste the error and accept whatever rewrite comes back. Run the loop instead — one disciplined step at a time.

Copy & paste into your own LLM · open in archive →

You are a patient senior engineer coaching a non-engineer through debugging their AI-built app. We work the loop strictly in order — REPRODUCE → ISOLATE → FIX → VERIFY — one stage per reply, and you do not move on until I confirm the current stage. Produce, starting at stage 1:

A) REPRODUCE — the exact steps, inputs, and starting state that make the bug happen every time. If I can't make it happen on demand, give me up to 3 things to try to pin it down before anything else.

B) ISOLATE — the smallest change that separates working from broken: what to comment out, which single log line to add, or what input to simplify. One experiment per step, with what each result would mean.

C) FIX — the smallest change that addresses the CAUSE we isolated, not the symptom. State in one sentence why this fix matches the evidence.

D) VERIFY — rerun the reproduction from A, plus the 2 nearby behaviors most likely to have broken from the fix.

Inputs: [WHAT I EXPECTED vs WHAT HAPPENED] · [PASTE THE ERROR OR SCREENSHOT TEXT] · [WHAT CHANGED RIGHT BEFORE IT BROKE] · [STACK / TOOL IF KNOWN]

Rules: Do not invent code, settings, or causes you cannot see in what I pasted — when you need something, ask for the specific file or output instead of guessing. No rewrites of whole files while we're isolating; smallest possible steps only. Never ask me to paste API keys, passwords, or customer data — I'll replace secrets with placeholders. The bug isn't fixed until stage D passes and I verify it myself.

Why it works: Non-engineers get stuck in the 'paste error, accept rewrite, new error' spiral because the model jumps to fixes before the cause is isolated. Locking the conversation to one loop stage at a time — and refusing whole-file rewrites during isolation — converts flailing into a binary search, and the verify stage catches the fix that breaks the thing next door.

Useful? 👍 Yes👎 No

Trust, but Verify

Verification & Trust

For: Builders who can't fully read the code they're about to ship

Test before trust: the verification checklist you run before believing 'it works'

The AI says it's done and the happy path worked once. Build the checklist that earns your trust before real users touch it.

Copy & paste into your own LLM · open in archive →

You are a QA engineer writing a hands-on verification checklist for someone who cannot read the code they're about to ship. I will describe the feature and paste what the AI claims it did. Produce:

A) CLAIM LIST — every specific claim in the AI's summary ('saves to the database', 'sends the email', 'handles invalid input'), each restated as a checkable statement.

B) CHECKLIST — for each claim: the exact clicks and inputs to try, what I should SEE if it works, and what failure would look like — covering the happy path, the empty or wrong input, doing it twice fast, and the refresh-the-page case.

C) EVIDENCE CHECK — for claims I can't see in the interface (data saved, email sent, background job ran), the concrete place to look for proof: which screen, dashboard, table, or inbox.

D) VERDICT RULE — the checklist scored: which items are must-pass before anyone else uses this, and which can wait.

Inputs: [WHAT THE FEATURE SHOULD DO] · [PASTE THE AI'S 'DONE' SUMMARY] · [WHERE IT RUNS: LOCAL / LIVE URL] · [WHAT REAL USERS WILL DO WITH IT]

Rules: Do not invent behavior, and never assume a claim is true because the AI asserted it — every claim gets a check I can physically perform, and anything unverifiable gets flagged 'needs a way to verify' as its own to-do. Use test data only; never run checks with real customer records, and never paste real customer data into an AI tool.

Why it works: The most dangerous sentence in AI-assisted building is 'Done — everything works.' Converting the model's own claims into physical checks with visible pass/fail evidence closes the gap between asserted and verified, and the must-pass split keeps a non-engineer from either shipping blind or drowning in QA theater.

Useful? 👍 Yes👎 No

Ship Small, Keep It Working

Refactor & Shipping

For: Builders turning a working prototype into something that survives the next change

Make it work, then make it right: the safe refactor pass

The feature finally works but the code is duct tape. Run a behavior-preserving cleanup — without letting the AI 'improve' it into a broken state.

Copy & paste into your own LLM · open in archive →

You are a senior engineer running a strictly behavior-preserving refactor for someone who builds with AI. The feature WORKS; our only goal is to make it safer to change next time. I will paste the working code. Produce:

A) FREEZE LIST — the exact current behaviors we must not change, written as checks I can run before and after (inputs → expected visible results). This is the contract; nothing proceeds until it's written.

B) CLEANUP PLAN — the 3-5 highest-value improvements ONLY (duplicated logic, misleading names, dead code, one giant function split up), each with: what it fixes, why it's safe, and which freeze-list checks cover it. Explicitly list what we are NOT touching this pass.

C) ONE CHANGE AT A TIME — the first cleanup as a single small change, then STOP so I can rerun the freeze checks before you continue to the next.

D) DONE REPORT — after the pass: what changed, what deliberately didn't, and the freeze-list rerun results.

Inputs: [PASTE THE WORKING CODE] · [WHAT IT DOES TODAY] · [WHAT I EXPECT TO CHANGE OR ADD NEXT MONTH] · [ANY KNOWN FRAGILE SPOTS]

Rules: Do not invent tests, behaviors, or requirements beyond the pasted code and my description — the freeze list comes first and everything must trace to it. No new features, no dependency swaps, no 'while we're here' rewrites. If a cleanup can't be verified with the freeze checks, skip it and say so. I verify each step by running the checks myself before you continue. Keep proprietary code out of consumer AI tools beyond what I pasted.

Why it works: 'Make it right' is where working AI-built apps go to die, because cleanup invites the model to rewrite everything at once. Writing the freeze-list contract before touching anything, then moving one verifiable change at a time, gets you the maintainability without gambling the only thing you actually have — software that currently works.

Useful? 👍 Yes👎 No

Manage the Machine

Session & Context Management

For: Builders running long AI coding sessions that drift, loop, or forget

Session context brief: re-onboard your AI at the start of every session

Every new chat starts from amnesia. Build the project brief you paste at the top of each session so the AI stops reinventing your app.

Copy & paste into your own LLM · open in archive →

You are a technical writer building a PROJECT CONTEXT BRIEF — the document I paste at the start of every AI coding session so the model starts oriented instead of guessing. I will paste what I have (notes, file list, previous chat summary). Produce:

A) THE BRIEF (one page max) — sections: what the app is and who uses it (2 sentences); current tech and structure (bullet list of the main files or pieces and what each does); decisions already made and why (so they don't get re-litigated); current state (what works, what's broken, what's half-built); conventions to follow (naming, patterns, style I've committed to).

B) DO-NOT LIST — the things previous sessions got wrong that the next session must not repeat, stated as direct instructions.

C) SESSION HANDOFF TEMPLATE — a 5-line form I fill at the END of each session (what changed, what broke, what's next, what I learned, files touched) that becomes the update to this brief.

D) STALENESS CHECK — the 3 parts of this brief most likely to go out of date, and what to reverify each week.

Inputs: [WHAT THE APP IS] · [PASTE FILE LIST OR STRUCTURE] · [KEY DECISIONS MADE SO FAR] · [WHAT PAST SESSIONS KEPT GETTING WRONG]

Rules: Do not invent project details, decisions, or file purposes I didn't give you — anything you're inferring must be marked 'confirm' so I verify it against the actual project before it enters the brief. The brief describes what IS, not what should be. Never include API keys, passwords, or customer data in the brief — name them as placeholders and note where they live.

Why it works: Context is the currency of AI coding sessions, and most builders spend the first twenty minutes of every chat re-teaching their own app — or worse, letting the model guess. A maintained one-page brief with a do-not list and an end-of-session handoff turns each new chat from a cold start into a shift change.

Useful? 👍 Yes👎 No

Which section is most useful to you this week?

One tap — it shapes which prompt leads next week.

What would you like to see more of?

Prompt of the Week (Pro)

This week's bonus: a pre-launch security sweep prompt that walks a non-engineer through the leaked-key, open-endpoint, and unprotected-page checks an engineer would run before shipping — with a strict verify-each-finding rule so nothing gets 'fixed' on trust.

Your searchable archive

Every prompt we’ve shipped, organized by section and task.