Build useful prompts: task, context, examples and boundaries

“Write something professional” leaves many questions unanswered. Who will read it? Which facts are approved? What should happen after reading? Which statement would be wrong? A longer prompt is not automatically better. A precise assignment can nevertheless reduce avoidable misunderstandings.

This guide develops an assignment for a fictional software-maintenance announcement. The example deliberately contains known information and unresolved questions. It demonstrates how to connect purpose, context, examples and boundaries. Provider sources were checked on 9 November 2026. The assignments are original teaching examples rather than documented customer-test results.

1. Start with the intended result

The opening sentence should establish the deliverable. “Create a draft maintenance announcement for existing business customers” is more specific than “Help with marketing.” It identifies the document, its maturity and its recipients.

Add the purpose. Customers should understand which feature is affected and whether they need to do anything beforehand. That purpose guides information selection. A detailed company history probably contributes little to this particular task.

The official OpenAI introduction to prompting recommends describing the outcome and useful context clearly. It does not require a rigid syntax. In practice, include elements that actually influence a decision about the result.

Write a simple acceptance statement. The result might be a reviewable draft preserving known facts and listing missing information separately. That makes later assessment more specific than asking whether the writing sounds impressive.

Specify whether the work should produce advice, a draft or a completed artifact. These deliverables require different actions. A request for a communication plan does not by itself explain whether individual messages should also be written.

2. Describe the audience and use

A text for system administrators can assume different knowledge from a message for staff without technical training. “For everyone” is therefore rarely a useful audience definition. Identify the actual recipients and their situation.

The maintenance announcement may reach managers at small businesses. They do not need an account of internal server architecture. They need the affected feature, timing, practical impact and any required action.

Describe the channel too. A customer-portal message can link to further detail. A standalone email should communicate essential information without requiring additional searching. A short status notice has a different purpose from an extensive help document.

Instead of only requesting a “professional” tone, describe observable properties. The announcement should be factual, understandable and free of unsupported reassurance. Explain technical terms when they are necessary. These requirements are easier to assess than a general quality adjective.

Consider what the reader already knows. Repeating a familiar product introduction may waste space, while assuming knowledge of an internal feature name can conceal the actual impact. The prompt can resolve both problems with a short description of the audience.

3. Select context by relevance

Supply information that could change the result. Here that includes the maintenance window, affected feature, expected impact and contact route. Separate confirmed facts from assumptions and open issues.

An earlier announcement may demonstrate the intended tone. Its dates and promises are not facts about the new event. Identify its function explicitly. Otherwise a useful writing example may carry outdated content into the new draft.

More material is not automatically more useful. A disorganised collection of old minutes and different planning versions can make the task harder. Supply a clearly identified current foundation and explain how supplementary files may be used.

When a necessary source is missing, define appropriate behaviour. An internal draft can list open questions separately. If a missing date determines the whole message, a focused clarification may be needed first.

Give sources understandable names. “Approved maintenance facts, version 2” is more helpful than several attachments called “final”. If the task depends on the latest version, establish which document has that status instead of leaving the model to infer it from filenames.

4. Distinguish facts, assumptions and instructions

This classification is an editorial planning aid rather than a technical access restriction. A heading alone does not make third-party material trustworthy. Securing a connected system remains a separate responsibility.

Read the assignment as someone joining the project for the first time. If the same statement appears as confirmed fact in one place and speculation elsewhere, resolve that contradiction before using the brief.

Also distinguish a quoted instruction inside a source document from your current assignment. A customer email may contain a demand the business has not accepted. Summarising that demand must not silently turn it into an approved company commitment.

5. Express boundaries as concrete decisions

“Make no mistakes” expresses a wish. “Do not promise availability outside the approved maintenance window” describes a specific boundary. The second instruction can be checked against the output.

In this example, an unknown end time must not be invented. Nor should the text guarantee completely interruption-free service. Such boundaries concern substantive meaning and matter more than a preferred greeting.

Tool access introduces another layer. Drafting a message, saving it in a system and sending it to customers are different actions. Describe the authorised scope clearly. Technical permissions must correspond to it.

A prompt does not replace access control. A connected process needs suitable permissions and verification of actions actually performed. For a writing-only task, the instruction can simply define the reviewable document to be produced.

Where a boundary is important, make the consequence of missing information explicit. For example, the system can produce a draft with an internal question rather than guess the missing value. A concrete fallback is more useful than an unspecified instruction to be careful.

6. Derive the output format from its next use

Clear prose is often appropriate when a person will read and revise the draft. A downstream program processing fields needs a defined data structure and technical validation.

The maintenance output could contain a subject line, message and open questions. This separation helps prevent an internal clarification item from accidentally appearing as customer information. It also simplifies final review.

An exact word count is useful only when it serves a real need. A sensible range is often enough. Important limitations must not disappear merely to satisfy an arbitrary length.

Request appropriate locations for claims that need evidence. A link alone is insufficient. A reviewer must be able to establish whether the cited source supports that particular statement and matches the relevant version.

Describe how unresolved values should appear in structured output. An empty field, an explicit unknown value and a separate question have different consequences for later processing. The chosen convention should be understood by whoever receives the result.

7. A complete original example

The following assignment is short enough to read as a whole. It requires no particular product interface. Replace the fictional details with approved project information before real use.

Result:
Create a draft maintenance announcement for existing business customers.

Audience:
Managers without specialist technical knowledge.

Confirmed facts:
- The customer portal reporting feature is affected.
- Previously saved reports remain available afterwards.
- The end time has not been approved.

Boundaries:
Do not add an end time, guarantee or another affected feature.
Do not send a message.

Output:
1. Subject
2. Understandable draft message
3. Open questions for internal review

Review:
Check the draft against the confirmed facts.
Identify missing information in the open-questions section.

The assignment does not yet provide a publication-ready maintenance notice. A confirmed time window is missing, for example. Its purpose is a reviewable working draft in which that gap remains visible. The eventual approval process must suit the actual communication.

A suitable output would preserve the known scope without replacing the missing time with a plausible estimate. That expectation can be assessed independently of whether every sentence already matches the final tone.

Before using the template repeatedly, ask the operational owner whether the supplied facts are precise enough. “Remain available afterwards” concerns preservation after maintenance; it should not be read as a promise of access throughout the interruption.

8. Give examples a specific function

An example is worthwhile when a requirement is difficult to explain abstractly. An approved paragraph may demonstrate concise factual writing. State which properties should be followed.

The Anthropic prompting guidance discusses relevant examples and clear separation of instructions, context and examples. For your own brief, ensure that examples do not contradict explicitly stated rules.

Include an exception when appropriate. A sample record with an unknown end time can demonstrate handling missing information. An example containing every field does not explain that situation.

Avoid collecting many almost identical examples. First establish whether one or two carefully chosen examples communicate the expectation adequately. Additional examples should have an identifiable purpose.

Remove incidental details that readers might mistake for mandatory patterns. If a sample happens to describe a Friday, explain whether the day matters. Otherwise a model might copy irrelevant content while correctly reproducing the intended structure.

9. Use headings and data blocks sensibly

Clear headings help people read and maintain the brief. They do not have to be called “Role”, “Context” or “Format”. What matters is that each item communicates its function.

The OpenAI prompt-engineering documentation describes Markdown and XML as ways to identify logical sections. A data block can keep a source and its content together. This does not establish one universally optimal order for every task.

Ordinary paragraphs are often sufficient for a human-maintained assignment. Clearly named fields may help with automated templates. Choose a structure that exposes missing or invalid inputs early.

Distinguish readable organisation from security. Labelling material as source text supports interpretation. It does not guarantee that arbitrary external content cannot influence a connected workflow in an unwanted way.

10. A small tested template component

The JavaScript below constructs a structured brief from two required inputs. It represents the data as JSON. The component makes no model request and grants no permissions. Its checks concern supplied values and the resulting string only.

function buildBrief({ audience, facts }) {
  if (typeof audience !== "string" || !audience.trim()) {
    throw new TypeError("audience required");
  }
  if (!Array.isArray(facts) || facts.length === 0 ||
      facts.some(v => typeof v !== "string" || !v.trim())) {
    throw new TypeError("non-empty facts required");
  }
  const data = { audience: audience.trim(), facts };
  return "Create a reviewable draft. Leave missing facts unresolved.\n" +
    "Source data as JSON:\n" + JSON.stringify(data, null, 2);
}

JSON encoding prevents quotation marks inside a fact from syntactically breaking the data representation. It does not promise protection against prompt injection. A connected workflow requires additional measures appropriate to its actual risks.

A real integration should also validate expected outputs and handle errors understandably. When an essential value is absent, a defined failure is often preferable to silently fabricating a replacement.

The helper deliberately keeps its purpose small. It does not determine whether a supplied fact is true or permitted for use. Those decisions belong to the source preparation and governance around the actual application.

11. Resolve contradictions first

“Very detailed” and “no more than three short sentences” may be incompatible. The same applies to preserving every detail in an extremely short summary. A longer prompt does not resolve that conflict.

Order requirements by significance. Factual fidelity and necessary qualifications may take priority over brevity. If a fixed length is indispensable, reduce the allowed scope accordingly.

Watch for conflicts between examples and instructions. A sample containing promotional exaggeration does not fit a rule against unsupported claims. Remove the conflict instead of expecting the model to infer your intended priority.

Existing project rules also matter. A session may specify a different tone or a fixed format. Identify and reconcile the instructions relevant to the task.

12. Distinguish clarification from routine decisions

Missing information does not always need to stop work immediately. An internal working draft can expose open issues. The same gap may be decisive for a binding commitment.

Describe which choices can be made independently. Selecting an appropriate subheading may be editorial judgement. Inventing unconfirmed availability is not.

A useful rule is to make sensible stylistic choices while leaving missing facts unresolved. When the task cannot meaningfully proceed without a fact, identify the specific gap.

This keeps work moving while preventing important uncertainty from disappearing into smooth prose. For recurring workflows, account for typical gaps explicitly in the template.

13. Improve through focused feedback

After the first output, “make it more professional” usually provides limited guidance. Identify the missed requirement. An unknown end time may be treated too casually, or a technical term may remain unexplained.

Give a specific direction. “Keep open questions separate and simplify the explanation of the reporting feature” changes two observable properties. Afterwards, verify that confirmed facts survived the revision.

Do not replace every instruction in each round. Otherwise it becomes difficult to tell which addition helped. Retain useful components and test new requirements against appropriate examples.

Our overview of the AI tools used in agency work offers broader context. A clearer assignment and an understandable review step often provide the most useful immediate improvement.

14. Maintain recurring prompts as working tools

A successful template needs a defined purpose and an owner. Record the tasks and sources it was designed for. A maintenance-announcement prompt is not a universal communication standard.

Version meaningful changes. Note which failure the revision should address. Check a new formulation against ordinary inputs and relevant exceptions before regular use.

The following table connects typical symptoms with a focused adjustment. It supports diagnosis rather than guaranteeing a model outcome.

15. Checklist before use

• Is the intended result described with its purpose?
• Are audience and actual use clear?
• Is the current factual foundation identified?
• Are assumptions and open questions visibly separate?
• Are substantive boundaries concrete and checkable?
• Does the output structure fit its next use?
• Do examples demonstrate the intended property?
• Are rules and examples consistent?
• Are external actions and permissions appropriately scoped?
• Is there an understandable way to inspect the result?

16. Frequently asked questions

Does every prompt need a role?

No. A role helps when it usefully focuses the task. “You are the best expert” supplies neither facts nor acceptance conditions. Purpose, sources and the intended result are often more informative.

Are longer prompts always better?

No. Repetition and conflicting requirements can make the work harder. Add information when it affects a concrete decision or helps address an observed failure.

Can AI review its own draft?

An explicit self-check can help. It does not replace independent source review or actual functional verification. The word “checked” without an identifiable basis is not dependable evidence.

Can the same template work with ChatGPT and Claude?

A clearly described assignment can often be tested in multiple products. Settings, context and available tools can still differ. Validate the template in the environment actually used.