A meta-prompt is a prompt template with blanks. Fill in your specific context and it produces consistent, high-quality output — whether you're scoping a feature, designing an API, writing a technical spec, or hunting for edge cases before they become production bugs. These are the ones we actually use.

01 / Why Templates Beat One-Offs

The problem with prompting from scratch

Most developers prompt like they're having a conversation: they describe what they want, get something back, iterate. That works fine for simple tasks. It breaks down on complex ones — because the quality of the output depends almost entirely on what context you remembered to include, and humans are inconsistent about what they remember to say.

A meta-prompt is a solved version of that problem. Someone — ideally someone who has run the task dozens of times and knows what the model needs — sat down and wrote out every piece of context that produces a good result. Now you fill in the blanks and get that result every time, not just when you remember to say the right things.

The templates below are structured around the tasks that matter most in a real software build. Take them. Adapt them. Run them on your own projects.

"The quality of the output depends on what context you remembered to include."

02 / Scope a Feature

The edge-case hunter

Use this before writing any implementation code. It surfaces the ambiguities and edge cases you'll hit anyway — at day one instead of day twenty.

Template — Feature Scoping
I'm building [FEATURE NAME] for a [TYPE OF APP]. Here is the intended behavior: [2–3 sentences describing the happy path] The data model looks like this: [paste relevant schema or describe the key entities] Your job: 1. List every edge case you can find in this feature, grouped by category (auth, data integrity, concurrency, error states, third-party deps). 2. For each edge case, say whether it needs a product decision, an engineering decision, or is safe to handle with a sensible default. 3. Flag any ambiguities in the spec that will require client input before implementation begins. 4. Suggest the 3 tests that would give the most coverage if we could only write 3.
Best used at project kickoff or when starting a new feature. The output becomes the first item on your scope call agenda.
03 / Design an API

The contract drafter

API contracts written well at the start save weeks of rework. This prompt produces an opinionated first draft you can argue with, which is faster than starting from a blank page.

Template — API Design
I need to design a REST API for [RESOURCE OR FEATURE]. Context: - App type: [web app / mobile app / internal tool] - Auth: [JWT / session / API key / none] - Key consumers: [frontend client / mobile app / third-party webhook] - Scale expectations: [rough MAU or request volume] Business rules: [2–4 rules that constrain the design, e.g. "users can only see their own resources", "soft deletes only", "all writes must be audited"] Design the API: 1. List all endpoints (method + path + one-line description). 2. For the 2 most complex endpoints, show request/response shapes. 3. Flag any design decisions where there are real trade-offs (e.g. pagination strategy, nested vs flat resources). 4. Note anything that will need a migration or be hard to change later.
Run this output past your senior dev before it becomes a contract. The trade-off flags are what they'll care about.
04 / Write a Technical Spec

The spec generator

Technical specs that actually get read are short, structured, and decision-focused. This template produces one — not a document, a tool.

Template — Technical Spec
Write a technical spec for the following feature. Feature: [FEATURE NAME] Product goal: [what problem it solves for the user, one sentence] Acceptance criteria: [list of "done" conditions, ideally testable] Out of scope: [what we are explicitly not building in this version] Dependencies: [other systems, APIs, or features this touches] Format the spec with these sections only: 1. Summary (2 sentences max) 2. Technical approach (how we'll build it, what the key components are) 3. Data changes (schema additions or modifications, if any) 4. Open questions (decisions that need to be made before work starts) 5. Risks (what could go wrong, and what we'll do about it) Keep it under 400 words. If you can't, the feature isn't scoped tightly enough — tell me why.
The last instruction catches scope creep before it starts. If the model can't write it in 400 words, neither can you ship it in 7 days.
05 / Debug a Problem

The structured root cause prompt

Debugging prompts fail when they're just "why is this broken." The model needs the full context of what you expected, what you observed, and what you've already tried.

Template — Root Cause Analysis
I have a bug. Help me find the root cause. What I expected: [describe the intended behavior] What actually happened: [describe the observed behavior, include error messages verbatim] Relevant code: [paste the specific function, route, or component — not the whole file] What I've already tried: [list 2–3 things you ruled out and why] Environment: [language/framework version, local vs staging vs prod, any recent deploys] I want: 1. Your most likely root cause hypothesis. 2. The fastest way to confirm or rule it out. 3. The fix, if the hypothesis is confirmed. 4. Any related issues this fix might surface.
The "what I've already tried" field is the most important. It stops the model from suggesting the thing you just ruled out.
06 / Using These Well

One rule that makes all of them better

Every template above has a gap where you're asked to paste something real — a schema, a code block, an error message. That gap is where most people get lazy and write a vague description instead.

Don't. Paste the actual thing. The difference between "my database has a bookings table with some columns" and pasting the actual schema is the difference between a generic answer and a specific one. Generic answers look useful and aren't. Specific answers are what you can build on.

The other thing worth knowing: these templates are starting points, not final forms. If a section consistently produces bad output for your use case, remove it. If you find yourself always adding the same context, bake it in. The best prompt template for your team is the one your team has adapted for how you actually work.

Quick reference — when to use each

  • Edge-case hunter. Before writing implementation code for any non-trivial feature.
  • Contract drafter. When designing an API that will have more than one consumer.
  • Spec generator. When a feature needs sign-off before development starts.
  • Root cause prompt. When you've been stuck on a bug for more than 20 minutes.