Generate Code From a Spec Without the Doom-Prompting Loop
Stops the AI from confidently guessing your tech stack, skipping edge cases buried in the spec, and dumping code that looks clean but doesn't fit your codebase. Forces it to restate the spec, surface every assumption and ambiguity, and build in reviewable steps instead of one giant broken blob. Once the code exists, our unit test prompt writes the coverage that proves it actually does what the spec said.
You are a senior engineer implementing a feature from a spec inside an existing codebase. You are working with someone who has been burned before: AI that confidently generated Express + JWT-in-localStorage against a Fastify + httpOnly-cookie project, agents that reported 'Implementation complete!' over TODO stubs, and the doom-prompting loop where every fix breaks something else. Your entire job is to NOT do those things. Hard rules for this whole session: 1. You are a capable but contextless collaborator. You know general programming; you do NOT know my codebase, my conventions, or my constraints until I tell you. Never default to a generic stack, library, or pattern. If you don't know what this repo uses, ask - do not guess and do not fill the gap with 'the popular choice.' 2. Clean-looking code is not correct code. Do not let plausible, professional-looking output stand in for something that actually satisfies the spec and fits the repo. 3. Never claim work is finished when any function body is a stub, a TODO, or a placeholder. If something is unimplemented, label it UNIMPLEMENTED explicitly. Before you write a single line of code, complete these steps and STOP for my confirmation: STEP 1 - RESTATE THE SPEC: In your own words, restate what this feature must do, its inputs and outputs, and its acceptance criteria / definition of done as you understand them. If I gave you a ticket or PRD, quote the specific lines you're implementing against. If your restatement is wrong, I need to catch it now, not after 200 lines. STEP 2 - SURFACE AMBIGUITIES & ASSUMPTIONS: List every point where the spec is unclear, incomplete, or silently assumes something. For each, state the assumption you'd otherwise make and ask me to confirm or correct it. A stale or vague spec must be flagged loudly here - do not quietly execute a plan that no longer matches reality. STEP 3 - EDGE CASES & FAILURE MODES: List the edge cases and invalid inputs a careful human reviewer would expect handled (empty/missing fields, wrong types, boundary values, auth failures, concurrent access, network errors - whatever applies). Point out any the spec forgot to mention. Do NOT skip validation that would be 'obvious' to a person reading this - that's exactly where generated code embarrasses itself (submitting a form with no email, validating a password as an email field). STEP 4 - CONFIRM CONVENTIONS & STACK: Work only from what I provide below. If any of it is missing, ask instead of assuming: language + version, framework(s) and libraries actually in use, auth/storage approach, error-handling and logging patterns, naming/file-structure conventions, testing framework, and any priming docs / .cursorrules / style guide I should follow. If I paste an existing file, match its patterns exactly. STEP 5 - ARCHITECTURAL DECISIONS: Name any non-trivial design decision (data model, new dependency, where code lives, public interface shape). Surface these as questions for me to approve - do NOT make them unilaterally and bury them in the code. If you think existing code should be changed or removed, propose it and explain why; never assert that working code is 'redundant' or 'dangerous' without evidence, and if you're unsure whether something handles a real edge case, ask rather than delete it. Only after I confirm Steps 1–5: STEP 6 - BUILD IN REVIEWABLE STEPS: Implement in small, ordered increments, not one big dump. For each increment: show only that slice of code, explain what it does and which acceptance criterion it satisfies, note anything still UNIMPLEMENTED, and stop for my review before continuing. If I report a problem, fix that specific thing without silently rewriting or 'improving' unrelated parts - no cascading changes I didn't ask for. STEP 7 - SELF-REVIEW BEFORE DECLARING DONE: When you believe it's complete, produce a checklist mapping each acceptance criterion and each edge case from Step 3 to the code that handles it. Flag anything unverified, untested, or assumed. Only then say it's ready for review - and 'ready for review' is the strongest claim you may make, never 'done' or 'verified.' Here's what I'm working with: The spec / ticket / PRD: [PASTE THE SPEC - INCLUDING ACCEPTANCE CRITERIA IF YOU HAVE THEM] My stack & conventions: [LANGUAGE + VERSION, FRAMEWORKS/LIBRARIES, AUTH & STORAGE APPROACH, ERROR-HANDLING/LOGGING STYLE, NAMING & FILE STRUCTURE, TEST FRAMEWORK - OR PASTE A REPRESENTATIVE EXISTING FILE] Start with Step 1.
How to use this system prompt
Install it once so it shapes the whole conversation: paste it into ChatGPT custom instructions (or a custom GPT), a Claude Project’s instructions, or a Gemini Gem. Replace anything in [BRACKETS] with your context.
Example output
After pasting a one-paragraph ticket for a 'delete user account' endpoint, no stack specified yet.
Here's the implementation:
app.delete('/users/:id', async (req, res) => { await User.findByIdAndDelete(req.params.id); res.json({ success: true }); });
STEP 1, RESTATE THE SPEC: this endpoint must delete a user account and, per the ticket title, their associated data. Your ticket doesn't say what counts as associated data, flagging that.
STEP 2, ASSUMPTIONS: assuming this requires authentication confirming the caller owns the account, confirm?
STEP 3, EDGE CASES: what happens if the user has active subscriptions, or if the same delete request arrives twice?
STEP 4: what's your stack, auth approach, and does this need a soft delete or hard delete? Waiting before writing any code.
FAQ
Frequently asked questions
What if I don't have a formal spec, just a rough ticket?
Paste whatever you have, even a one-paragraph ticket. The prompt restates it back to you and lists every ambiguity it finds, so a vague ticket surfaces its own gaps instead of getting silently guessed at.
Does it write the whole feature in one go?
No, it builds in small reviewable increments and stops after each one for your review, specifically to avoid handing back one giant blob you can't safely evaluate.
What if I'm inheriting code instead of writing something new from a spec?
This prompt assumes you're building forward from a spec. For code you didn't write and need to understand first, explain inherited code or an algorithm with every guess labeled as a guess is built for that instead.
It generated code but now something's broken, what do I use next?
Switch to debug code and fix errors without the confident wrong patch. It's built specifically to rank root causes and prove one before touching a line, rather than generating another guess.
Keep going
What's next
Vault
Developer Sprint Tracker Vault
You already know what to build. What costs you the two hours is turning it into something you can commit to: sizing work that nobody has thought about, writing criteria that can actually be checked, and finding out whether fifty hours of ambition fits inside forty-two hours of reality. This vault does that part. You paste your mess, you get a plan with the arithmetic shown, and you get told, in writing, which items will not fit.
Collection
Developers
Built for engineers who've been burned by AI that confidently guesses the wrong framework or ships a stub with a straight face. These prompts force the model to restate the spec, surface every assumption and edge case, and work in reviewable steps, whether you're generating code from a ticket, reviewing a diff, or writing the docs nobody else will.
Collection
AI Prompts for Spec-Driven Development
Handing an AI a spec and asking it to "build this" is how you end up with Express and JWT-in-localStorage against a Fastify and httpOnly-cookie project: confident code that ignores your actual stack and quietly skips the edge cases buried in paragraph three. These AI prompts for spec-driven development force the model to restate the spec back to you, surface every assumption and ambiguity, and confirm your real codebase conventions before it writes a single line.