DEV Community

Nova
Nova

Posted on

Prompt Preflight Checklist: 7 Questions Before You Hit Run

#ai #promptengineering #productivity #devtools

If you use AI in your dev workflow, you’ve probably seen this pattern:

  • You write a prompt.
  • It works once.
  • You try it on the “real” input.
  • Suddenly it rambles, misses constraints, or returns something you can’t paste anywhere.

Most of those failures aren’t “model issues”. They’re prompt preflight issues — the same avoidable mistakes you’d catch if you paused for 60 seconds before hitting run.

Here’s the checklist I use. It’s short enough to do every time, and it will save you hours of iterative re-prompting.

The 7-question prompt preflight checklist

1) What is the deliverable?

Don’t describe the task. Name the artifact.

Bad:

Review this code and tell me what you think.

Better:

Produce a GitHub review comment list with (a) severity labels (blocker/major/minor), (b) file+line references, and (c) a short suggested fix for each.

Why this works: the model can “aim” at something concrete. Vague prompts invite vague output.

Preflight test: could a teammate tell whether the output is correct without reading your mind?

2) Who is the audience?

The same content can be correct but unusable if it’s written for the wrong reader.

Example:

Audience: a mid-level backend engineer who knows SQL and Docker but is new to Kubernetes.

If you don’t specify this, the model will pick a random target: too basic, too advanced, or annoyingly verbose.

3) What is in scope vs out of scope?

This is the fastest way to prevent the “helpful but irrelevant” sections.

Example:

In scope: the API design and error handling.
Out of scope: performance tuning, CI/CD, and database indexing.

If you want the model to not talk about something, say so explicitly.

4) What are the hard constraints?

Hard constraints are non-negotiable. Put them in a visible block.

Example constraint block:

Constraints:
- Max 12 bullet points
- No more than 2 paragraphs of explanation
- Use TypeScript
- Output must be valid JSON
- Do not invent endpoints or fields not present in the input
Enter fullscreen mode Exit fullscreen mode

Preflight test: if the model violates one of these, will you throw away the output? If yes, it’s a hard constraint.

5) What context is missing (and how should the model handle it)?

A lot of bad output comes from the model guessing.

Give it a rule for unknowns:

If information is missing:
- Ask up to 3 clarifying questions.
- If still ambiguous, make the smallest reasonable assumption and label it "Assumption:".
Enter fullscreen mode Exit fullscreen mode

This turns “hallucinations” into either questions or clearly-marked assumptions.

6) What should the format look like?

Format is the difference between “nice answer” and “drop-in usable”.

If you want a PR description, say so. If you want a table, say so. If you want a patch, say so.

Example: code review output template

### Summary
- …

### Issues
1) **[blocker]** `src/foo.ts:41` — …
   - Fix: …

### Suggested patch
Enter fullscreen mode Exit fullscreen mode


diff
...

Enter fullscreen mode Exit fullscreen mode

Even better: provide a tiny sample output (one item) so the structure is unambiguous.

7) What is the quality bar?

This is where you encode “what good looks like”.

Instead of:

Make it high quality.

Use:

Quality bar:
- Prefer specific, actionable steps over general advice
- Include edge cases and failure modes
- If you propose a change, include a concrete example (code/config)
- Avoid repetition
Enter fullscreen mode Exit fullscreen mode

This pushes the model toward the kind of output you’d expect from a strong human collaborator.

A practical example: turning a vague prompt into a reusable tool

Let’s say you want a prompt that turns a feature request into implementation tasks.

Version 0 (vague)

Break this feature down into tasks.

Version 1 (preflighted) 

Role: You are a senior engineer writing an implementation plan.

Audience: A small dev team that will execute this next sprint.

Deliverable: A task list suitable for a GitHub issue, with clear acceptance criteria.

In scope: API changes, data model changes, migration notes, and tests.
Out of scope: UI polish, performance optimizations.

Constraints:
- 8–15 tasks total
- Each task includes: title, description, acceptance criteria, estimated complexity (S/M/L)
- If something is ambiguous, ask up to 3 clarifying questions first

Input:
<PASTE FEATURE REQUEST HERE>

Output format (JSON):
{
  "questions": ["..."],
  "tasks": [
    {
      "title": "...",
      "description": "...",
      "acceptance_criteria": ["..."],
      "complexity": "S|M|L"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Notice what happened:

  • The model can’t “wander” into UI polish.
  • You get tasks that are immediately actionable.
  • You can now regression-test the JSON shape.

A tiny trick that makes this even more reliable: add a self-check

After the model produces output, ask it to validate against your own rules.

Append this to many prompts:

Self-check before final answer:
- Confirm you followed every constraint
- Confirm output matches the requested format
- If any constraint is violated, fix it before responding
Enter fullscreen mode Exit fullscreen mode

This doesn’t make the model perfect, but it does reduce the number of “oops, forgot the JSON” moments.

Copy/paste template

Here’s a compact template you can keep in a snippet manager:

Deliverable:
Audience:
In scope:
Out of scope:
Constraints:
Missing-info rule:
Output format:
Quality bar:

Task:
<Input>
Enter fullscreen mode Exit fullscreen mode

Run the checklist once, then reuse the prompt forever.

Closing thought

When prompts fail, it’s tempting to keep tweaking wording (“say it more strongly”). In practice, the biggest improvements come from getting the spec right: deliverable, scope, constraints, format, and quality bar.

Do the preflight. Then hit run.

Top comments (0)