How to Write AI Prompts: A Practical Structure

Writing a useful AI prompt is less about finding a magic phrase and more about making the task observable. A strong prompt states what should be done, supplies the context that changes the answer, identifies who will use the result, and defines how the output can be checked.

Quick answer#

Start with the goal. Add only the context the model needs. Name the audience when it changes vocabulary or depth. Define a usable output format and testable constraints. Add a role, examples, or a quality check only when they solve a real problem.

Prompt anatomy#

This site uses eight transparent structural elements:

1. Goal — the action and intended outcome
2. Context — relevant facts, sources, and boundaries
3. Audience — the person who will read or use the result
4. Role — an optional perspective or review standard
5. Output Format — sections, fields, order, or length
6. Constraints — required items, exclusions, and priorities
7. Examples — optional demonstrations of the desired pattern
8. Quality Check — a request to surface omissions or uncertainty

A prompt does not need every element. Use the smallest set that makes the task clear and reviewable.

Step-by-step method#

1. State the goal#

Use an observable verb such as draft, compare, classify, explain, extract, or revise. Add what the result will be used for.

Compare the three onboarding options and recommend which one to test first.

2. Add relevant context#

Include verified facts, source material, prior decisions, and scope. More context is not automatically better; remove details that would not change the correct output.

3. Name the audience#

Specify who will read the output, what they already know, and what they need to do next. Audience affects terminology, examples, and depth.

4. Choose a role only when useful#

A role can establish a lens such as “review for accessibility” or “edit for a non-technical reader.” It cannot create credentials, current knowledge, or professional authority.

5. Define the output format#

Ask for the structure that fits the next step: email, outline, table, checklist, code patch, or defined fields.

6. Set testable constraints#

Prefer measurable rules such as length, required sections, allowed sources, prohibited claims, or compatibility requirements.

7. Add examples when consistency matters#

Examples can clarify a difficult pattern, but they can also transmit mistakes and bias. Keep them accurate, relevant, and clearly separated from source facts.

8. Request a quality check#

Ask the model to compare the response with the explicit requirements and label missing information. This is not independent fact-checking.

Complete example#

Goal:
Draft a launch email for independent designers who already use our free plan.

Context:
The only approved product benefit is [BENEFIT]. The email announces availability on [DATE].

Audience:
Existing free-plan users who are familiar with the basic product.

Output format:
Return subject line, preview text, email body, and one CTA.

Constraints:
Keep the body between 150 and 190 words. Use a direct and respectful tone. Do not add prices, performance guarantees, testimonials, or unsupported claims.

Quality check:
Finish with a checklist confirming the approved benefit, date, word range, and single CTA are present.

The prompt makes the task, source boundary, audience, format, and review conditions visible. It still does not guarantee factual accuracy or a good business decision; the supplied facts and final output require human review.

Before and after#

Weak prompt

Write something good about our new service.

Improved prompt

Write a 120-word service introduction for first-time small-business buyers. Use only the verified facts below. Explain the main use, one limitation, and the next step. Return one paragraph and three factual bullets. Do not invent prices, customer results, or certifications.

The improvement replaces a vague topic with an action, reader, source boundary, format, and explicit exclusions.

Common mistakes#

• Starting with a topic instead of an action
• Adding a role but no task or context
• Requesting “detailed” output without a useful format
• Adding conflicting limits or too many negative instructions
• Mixing instructions with source material
• Treating a prompt as a substitute for source verification
• Expanding a simple prompt merely to raise a structure score

Reusable checklist#

• Can another person identify the exact task?
• Is the supplied context relevant, verified, and safe to share?
• Is the audience explicit when it affects the result?
• Can the format and constraints be checked?
• Are facts separated from assumptions and examples?
• Does the prompt define what to do when information is missing?
• Is the prompt no longer than the task requires?

Practice with the tools#

Use the Prompt Generator to assemble a first version, then paste it into the Prompt Checker to see which structural elements are detectable. The checker is rule-based: a higher score means more structural cues were found, not that the final response will be true, creative, safe, or useful.

Model and testing notes#

The same prompt can behave differently across models, product settings, dates, and conversation histories. Important prompts need dated tests with realistic and edge-case inputs. Record the model, product, date, prompt version, observed failure, and revision.

FAQ#