AI Prompt Generator

Most disappointing AI answers are not model failures — they are specification failures. A language model resolves every ambiguity in your request by guessing the statistically average interpretation, and the average interpretation of a vague request is a vague answer. "Write about remote work" has thousands of defensible readings: a blog post, a policy memo, a pros-and-cons list, for executives or new hires, 200 words or 2,000. The model must pick one, and it picks the blandest. The engineering insight is that a prompt is a specification, and it improves the way specifications improve: by pinning down the degrees of freedom that matter. Four pins do most of the work. Task: the verb and deliverable ("write a 600-word onboarding email," not "write about onboarding"). Audience: who reads the output and what they already know. Constraints: length, tone, format, what to exclude. Context: the background facts the model cannot guess — your product, your situation, the previous attempt that failed. There is solid evidence that specificity pays. In practice, adding an explicit audience and length constraint alone visibly changes output quality, because it collapses the space of valid answers. A useful habit: after writing a prompt, ask "could two reasonable people read this and expect different deliverables?" If yes, the model will disappoint one of them — and you do not get to choose which.

Before (vague — average answer guaranteed):
"Write about remote work."

After (specified — 4 pins):
"Write a 600-word article arguing that hybrid schedules
beat fully-remote for junior engineers.
Audience: engineering managers at startups (assume they
already know the standard remote-work pros/cons).
Tone: direct, conversational, no buzzwords.
Structure: hook, 3 arguments each with one concrete
example, one counterargument addressed, action-oriented
close. Do NOT discuss cost savings or real estate."

Prompt engineering accumulated real, tested techniques; it also accumulated folklore. Here is the load-bearing subset. Role assignment ("You are a senior tax accountant reviewing this for errors") works not because the model becomes an accountant but because it shifts the output distribution toward the vocabulary, caution, and structure of that genre. It helps most with tone and depth calibration and least with factual accuracy — a model role-playing a doctor is not more medically accurate, only more clinical-sounding. Use roles to set register; never to manufacture authority. Few-shot examples are the highest-leverage technique for format and style. Two or three input-output pairs beat paragraphs of description, because they specify things you would never think to verbalize — how terse the labels are, how edge cases look, what "good" actually means. Keep examples diverse: models copy the pattern of your examples aggressively, including their biases (if all your examples are positive-sentiment, expect positive-sentiment outputs). Decomposition beats single mega-prompts for anything multi-stage. "Read this contract, find risky clauses, and draft an email about them" mixes three tasks with three different quality criteria; running them as three prompts lets you inspect and correct intermediate output. Similarly, asking the model to plan before writing ("first list the sections, then wait") catches structural problems while they cost one line to fix. Chain-of-thought instructions ("think step by step") help on arithmetic and logic-style problems, but modern reasoning-tuned models often do this internally — the bigger win today is asking the model to verify its answer against your stated constraints before finalizing.

Few-shot format specification (2 examples do the work):

"Classify each support ticket. Respond in exactly this format.

Ticket: 'App crashes when I upload a photo over 10MB'
-> category: bug | severity: high | team: mobile

Ticket: 'Would love a dark mode option'
-> category: feature-request | severity: low | team: design

Ticket: 'I was charged twice this month'
->"

The moment an AI answer feeds into anything downstream — a spreadsheet, a script, another prompt — free-form prose becomes a liability. The fix is to specify an output schema: the exact shape of the response, stated as non-negotiable. Three practices make schemas stick. First, show the schema, do not describe it. "Respond as JSON with keys title, risk_level (one of: low/medium/high), and reasons (array of strings)" is good; pasting a filled-in example of the JSON is better, because an example fixes details a description leaves open (quoting style, casing, whether empty arrays are allowed). Second, close the escape hatches. Models love to wrap JSON in markdown fences, prepend "Here is your JSON:", or add a friendly closing line. Say explicitly: "Output only the JSON object. No code fences, no explanation before or after." Third, design for failure: include a way for the model to say "I could not do this" inside the schema (a status field, a nullable answer) — otherwise it will fill required fields with plausible inventions rather than leave them empty, which is exactly the failure you cannot detect. Schemas also improve non-programmatic work. Asking for "a table with columns X, Y, Z" or "exactly five bullets, each starting with a verb" forces the model to organize its thinking and makes missing pieces visible at a glance. A structured wrong answer is easy to spot; an eloquent wrong answer is not. Even so, validate anything machine-parsed — schema compliance is high with modern models, but it is not guaranteed unless you use an API-level structured output feature.

"Analyze the review below. Output ONLY this JSON —
no code fences, no text before or after:

{
  "sentiment": "positive",
  "confidence": 0.92,
  "topics": ["shipping", "packaging"],
  "actionable_complaint": true,
  "status": "ok"
}

If the text is not a product review, output:
{ "status": "not_a_review" }
and nothing else."

Nobody writes a good prompt on the first try for a task that matters. The people who get consistently strong results are running a loop: draft, test, diagnose, revise — the same loop as debugging. Diagnosis is the skill. When output disappoints, name the failure before touching the prompt. Wrong format? Add a schema or an example. Wrong depth? Your audience line is missing or wrong. Wrong content? You assumed context the model does not have — add the background facts. Ignored an instruction? It may be buried mid-prompt; models weight the beginning and end of a prompt more than the middle, so move critical constraints to the top and restate the single most important one at the end. Confidently wrong facts? No prompt phrasing reliably fixes hallucination — you need to supply source material and instruct the model to answer only from it. Change one thing per iteration. If you rewrite five parts at once and the output improves, you have learned nothing about which part mattered — and prompts, like code, accumulate superstition fast ("we always add this paragraph; nobody remembers why"). Two habits separate casual users from operators. Keep a prompt library: when a prompt works, save it with a note about what it is for and one example of its output; you will reuse it for months. And test on more than one input before trusting a prompt: a prompt tuned on a single example quietly overfits to it, exactly like a model trained on one data point.

A well-built prompt raises the ceiling of what a model produces, but some limits belong to the model, and pretending otherwise wastes hours. No prompt makes a model know things it was not trained on: your yesterday's meeting, a paper published last week, your company's internal pricing. If the answer requires that information, it must be in the prompt — supplied by you or by a retrieval system. Related: prompts do not grant access to real-time data. A model asked for "the current price" will produce a price-shaped number. No prompt eliminates hallucination; grounding merely reduces it. Even with source material provided, models occasionally blend supplied facts with remembered ones. For factual work, the rule stands: the model drafts, you verify. Ask for citations to the supplied text (paragraph numbers work well), spot-check them, and be most suspicious of details that are specific, convenient, and unverifiable. No prompt makes the model a reliable judge of its own output. "Are you sure?" mostly elicits polite self-revision toward whatever you seem to want — models exhibit sycophancy, agreeing with a user's stated position even when it is wrong. Independent checks (a second fresh conversation, a different model, or your own expertise) are worth more than any in-conversation reassurance. Knowing these boundaries is itself a prompting skill: the best practitioners spend their effort where wording helps — specification, examples, schemas, decomposition — and reach for other tools where it cannot.