← AI Workflow Guides

Context, Constraints, and Examples

Give the model the right evidence, constraints, approval boundaries, and examples so it stops guessing what matters and starts producing work you can actually use.

Level Beginner
Time 14 minutes
Tools covered: Claude , ChatGPT , Gemini
prompting context constraints examples prompting-playbooks context-packs
Updated April 4, 2026

What This Guide Is For

Once your prompt has a clear goal, the next quality jump usually comes from three things:

  • enough context to understand the situation
  • enough constraints to avoid obvious drift
  • enough examples to show what “good” looks like

In many modern workflows, add a fourth:

  • a clear destination or approval boundary so the model knows whether it is drafting, deciding, or preparing a writeback

Most weak AI output is not caused by the model being lazy or broken. It is caused by the model filling in missing details with generic defaults.

Context: Tell The Model What World It Is In

Context is the material that changes how the task should be interpreted.

Useful context often includes:

  • audience
  • source documents
  • project stage
  • product or domain background
  • known decisions already made
  • what the output will be used for next
  • what system the result should eventually land in

If the task depends on a document, meeting notes, logs, code, or raw research, provide the relevant material or summarize it. Do not assume the model knows your organization, product, or priorities.

For recurring work, think in terms of a context pack instead of a loose prompt.

Constraints: Name The Boundaries Early

Constraints prevent the model from solving a different problem than the one you actually have.

High-value constraints often include:

  • what not to invent
  • allowed length
  • required structure
  • tone or reading level
  • risk boundaries
  • approval boundaries
  • timing or operating limits
  • destination-system rules

Examples:

  • “Do not invent customer quotes.”
  • “Keep the answer under 200 words.”
  • “Preserve existing behavior.”
  • “If information is missing, ask follow-up questions instead of guessing.”

The negative rules are often just as important as the positive ones.

Examples: Show The Pattern You Want

If you can show the model a target pattern, do it.

Examples are especially useful when:

  • output format matters more than creativity
  • tone is hard to describe
  • your team already has a house style
  • you want consistency across repeated runs

An example does not need to be long. One short “bad vs good” pair can be more useful than a paragraph of abstract instruction.

Destination And Approval Matter More Than Most People Think

If the output is supposed to become:

  • a Notion page
  • a Jira ticket
  • a status update
  • a commit plan
  • a customer-facing draft

say so directly. That changes how the model should structure the answer.

If the result is still draft-only, say that too. This is one of the easiest ways to stop a model from sounding more final than the workflow allows.

Non-Goals Prevent Drift

One of the easiest upgrades is to name what the model should not optimize for.

Examples:

  • “Do not make this sound like marketing copy.”
  • “Do not propose implementation yet.”
  • “Do not rewrite the entire architecture.”
  • “Do not remove nuance to make it shorter.”

Non-goals are the easiest way to stop a model from being “helpful” in the wrong direction.

A Practical Context Pack Template

Use this when you need better output without overthinking the prompt.

Task:
- what I need done

Evidence and context:
- what this is
- who it is for
- source material or evidence
- what decisions are already made
- what system or workflow this belongs to

Constraints:
- must do
- must not do
- format or length

Approval boundary:
- what can be drafted now
- what still needs a human decision

Example or reference:
- sample output, style note, or structure to copy

That is enough for many real tasks in business, research, coding, and creative work.

When Examples Beat More Instructions

Prefer examples when:

  • you can show a real pattern quickly
  • you want repeated outputs to feel consistent
  • the team already has a preferred structure

Prefer more instructions when:

  • the task is novel
  • you do not yet know what “good” looks like
  • the output must follow rules more than style

In practice, the strongest prompts often combine both.

A Short Anti-Pattern List

These usually degrade results:

  • giant unstructured context dumps with no clear task
  • constraints hidden at the end
  • asking for five things but only evaluating one
  • vague reference phrases like “make it more professional”
  • assuming the model can infer unstated business logic

Clearer input almost always beats longer input.