If prompting sometimes feels like guessing, it’s usually because you’re making the wrong kind of decision for the problem you actually have: clarity, format, constraints, or evaluation.

Abstract branching signpost showing a highlighted decision path

This guide is a decision tree: pick what’s happening, follow the if/then, and use the matching example.

Step 0: If you can’t tell what’s wrong, classify the failure first

Before you rewrite anything, decide which failure mode you’re seeing. It keeps you from adding random detail that doesn’t help.

  • Off-topic: it answered a different question than you meant.
  • Too shallow: correct but generic, no useful specifics.
  • Wrong format: you needed a checklist/table/JSON, you got paragraphs.
  • Wrong assumptions: it invented details, used the wrong context, or guessed your constraints.
  • Not actionable: no steps, no decision points, no examples.

Now choose the closest match below and follow that branch.

Branch A: If it’s off-topic, then tighten the “task + boundaries”

Off-topic usually means your prompt described a vibe, not a job. Fix it by making the job unskippable and the boundaries explicit.

Target and funnel shapes representing tighter prompt boundaries

  • Then add a one-line task statement: what you want produced.
  • Then add exclusions: what not to include.
  • Then add audience + use case: who it’s for and where it will be used.

Example (vague → bounded)

Instead of: “Help me write about prompting.”

Use: “Write a decision-tree guide for beginners on prompting. Output should be 6 sections with headings and at least one checklist. Exclude tool-specific features and marketing language. Audience: non-technical professionals using AI for writing on the web.”

If it still wanders, add: “If you’re unsure, ask up to 3 clarifying questions before answering.”

Branch B: If it’s too shallow, then force specificity (inputs, constraints, and examples)

Generic answers happen when the model doesn’t have concrete material to work with, or you didn’t require concrete output.

Geometric blocks flowing into a prism for specificity

  • If you have real inputs, then paste them (notes, rough outline, bullet points, messy draft).
  • If you don’t have inputs, then provide constraints (length, tone, required sections, “must include” items).
  • Then require examples: “include 3 examples” is surprisingly effective.

Example (forcing usable detail)

“Draft a short guide on writing better prompts for summarizing meeting notes. Constraints: 500–700 words, calm tone, no hype. Must include: a template prompt, 3 ‘bad vs improved’ examples, and a checklist for what to paste into the prompt. Assume the user is on web (Safari) and wants copy/paste prompts.”

When you need depth, ask for “tradeoffs” and “edge cases,” not “more detail.”

Branch C: If the format is wrong, then specify the container and a strict schema

“Make it structured” is too weak. Choose a container (bullets, steps, table, JSON) and define the fields.

  • If you need scanability, then ask for headings + bullets with max bullet length.
  • If you need copy/paste into a tool, then ask for a schema (keys, allowed values, example object).
  • If you need a decision tree, then require if/then lines and a stop condition.

Example (decision-tree container)

“Create a decision tree for choosing a prompt style. Output format must be: 1) ‘If… then…’ lines only 2) Max 12 lines 3) Each line ends with either ‘ASK’, ‘WRITE’, or ‘DONE’ 4) After the tree, provide 2 worked examples showing which path was taken.”

Small note: when you care about formatting, add “Do not include any other text outside the format.”

Branch D: If it makes wrong assumptions, then pin the context and add a verification step

Hallucinated details and wrong assumptions often come from missing context and no instruction to check.

Shield and checklist shapes representing context and verification

  • Then provide a “context block”: what’s true, what’s unknown, what must not be assumed.
  • Then add a verification instruction: tell it to list assumptions and confirm them.
  • If safety matters, then require uncertainty language and alternatives.

Example (context + assumption check)

“Context: - Product: small ecommerce site - Goal: write support macros - Known: refund window is 30 days - Unknown: shipping carrier details Rules: - Do not invent carrier names or delivery times - If info is missing, ask a question or write a placeholder in [brackets] Task: Write 5 support replies for common refund questions. First, list any assumptions you are about to make and wait for confirmation.”

If you can’t wait for Q&A, swap the last line to: “Proceed using placeholders and label them clearly.”

Branch E: If it’s not actionable, then ask for decisions, steps, and stop rules

“Actionable” usually means: you can do something next without thinking too hard. So require steps and decision points, plus what “done” looks like.

  • Then request a sequence: “Step 1… Step 2…”
  • Then request decision points: “If X, do Y; otherwise do Z.”
  • Then request stop rules: “Stop when you have A and B.”

Example (turning advice into a procedure)

“Give me a 10-minute workflow to refine a prompt. Include: (1) a starting prompt, (2) 3 iteration questions I should ask, (3) if/then rules for when to add constraints vs examples, and (4) a ‘stop when’ checklist.”

Put it together: a compact if/then prompt template you can reuse

This is a fill-in template that matches the decision tree above. Copy it and keep the brackets.

  • Task: [What you want produced in one sentence]
  • Audience/use: [Who it’s for + where it will be used]
  • Inputs: [Paste source material or say “none”]
  • Constraints: [Length, tone, must-include, must-avoid]
  • Format: [Bullets/steps/schema; include field names if needed]
  • Assumptions: [List what must not be assumed; ask questions or use placeholders]
  • Quality bar: [Examples, edge cases, tradeoffs, acceptance criteria]

Mini example (filled)

“Task: Create a decision tree to choose between summarizing vs extracting action items from meeting notes. Audience/use: busy project manager, copy/paste into an internal wiki. Inputs: none. Constraints: 400–600 words, calm tone, include 2 examples. Format: 6 if/then lines + 2 worked examples. Assumptions: do not invent company policies. Quality bar: include stop condition and one edge case (messy notes).”

Takeaway: diagnose first, then make one targeted change

If the output is wrong, don’t “add more detail” as a reflex.

Pick the failure mode (off-topic, shallow, format, assumptions, actionability), apply the matching if/then fix, and iterate one change at a time.