Choose how much detail the task needs

You do not have to fill out a long template every time. Start with the smallest brief that gives the model enough information to do the job. OpenAI's prompting guidance likewise recommends using only the elements that help with the task.

SituationGive the modelCheck yourself
A low-stakes draft, such as a meeting emailThe recipient, facts to convey, desired action, and a useful length or toneNames, dates, promises, and anything the model added
Analysis of supplied materialThe file or data, the question, definitions, missing-value rules, and desired outputCalculations, omitted rows, and whether explanations are supported
A consequential update or recommendationSource facts, decision status, audience, required sections, and prohibited inferencesEvery material claim against its source, plus any decision the model implies

If the necessary facts are unavailable, ask for questions or a list of unknowns before asking for a finished draft. A more elaborate instruction cannot supply a missing budget, policy, deadline, or approval.

The five parts of a useful prompt

  1. Goal: Name the result, such as an email someone can send or a table a reviewer can inspect.
  2. Context: Say who will use the answer and what situation changes how it should be written.
  3. Inputs: Supply the relevant facts, text, or files. Identify what the model must not guess.
  4. Output: Specify the sections, format, and length only where those choices matter.
  5. Quality check: State the facts and boundaries a reviewer should be able to verify.
Fill-in prompt for a source-dependent task
Goal: [What result do you need?]
Audience and context: [Who will use it, and what do they already know?]
Inputs: [Paste or attach the source material. Name any missing facts.]
Output: [Specify the useful format, length, and required sections.]
Checks: [List the facts to preserve and claims to avoid. Ask for unknowns to be marked.]

For a reusable version with more fields, use the work prompt template. The examples below show when a shorter request is enough and when the checks need to be precise.

Example 1: write a short email without inventing an excuse

Suppose you cannot attend a product review at 11 a.m. on Tuesday. You can join after 2 p.m. on Thursday and want to ask your teammate Mara to move it. You have not supplied a reason for missing Tuesday. The task needs those facts and the desired tone; it does not need five labeled fields.

Short email prompt
Write a friendly email to my teammate Mara asking to move our product review from Tuesday at 11 a.m. to Thursday after 2 p.m. Keep it under 80 words. Do not invent a reason I cannot attend Tuesday. Include a subject line and ask whether the new time works for her.

Before sending, check that the draft says after 2 p.m., keeps the original meeting time accurate, and does not add an excuse or claim that Thursday is already agreed. If Mara needs a calendar invitation, that is a separate action you must take or explicitly ask an approved tool to perform. For a routine email like this, a short factual request may be easier to review than a full template.

An acceptable draft could say: “Could we move Tuesday's 11 a.m. product review to Thursday after 2 p.m.? Please let me know if that works for you.” That is an editorial example, not a claimed model output. If a generated draft says you have a medical appointment or that Mara already accepted, delete those additions. A useful follow-up is: “Remove the reason for rescheduling and leave Thursday as a request. Keep the original meeting time and my availability unchanged.”

Example 2: analyze a small table without filling a gap

Now consider a monthly traffic report. The trial count for March is missing, shown as a dash below. The question is whether visits and trial conversion changed. Here the input, calculation, and missing-value rule matter more than tone.

MonthVisitsTrials
January1,00040
February1,20048
March900Not reported
Data-analysis prompt
Using only the monthly table above, calculate trials divided by visits for every month with both values. Return a table with visits, trials, and conversion rate, followed by two observations and a list of unknowns.

Treat "Not reported" as missing, not zero. Show the arithmetic for each rate. Do not infer why visits changed or claim that conversion improved without supporting data. If a comparison cannot be made, say which value is missing.

A correct check gives January 40 ÷ 1,000 = 4% and February 48 ÷ 1,200 = 4%. Visits rose from January to February and fell in March. March's conversion rate is unknown because its trial count is absent. A response that reports 0% for March, calls the February conversion rate an improvement, or explains the traffic change without another source has failed the brief. Those checks are independent of how polished the prose sounds.

If this were a real spreadsheet, attach or paste the actual rows and define what a visit and a trial mean. For a larger file, ask for the rows used in each calculation so you can spot missing records or a changed denominator. Do not treat a model's self-check as a substitute for recalculating decision-relevant figures.

When the model treats March's blank as zero, correct the input rule first: “March's trial count was not reported. Replace the March rate with ‘unknown,’ remove any comparison that depends on it, and leave January and February unchanged.” If the real report counts visits as sessions but trials as distinct people, ask the data owner whether that ratio is the intended metric before publishing it. A perfectly calculated percentage can still answer the wrong question when the units are unclear.

Example 3: keep a decision pending in an executive update

Grow AI Skills tried two versions of an executive project-update request on August 18, 2026. The team first used an anonymous ChatGPT session and then repeated the exercise in a signed-in GPT-5.6 Sol session with Fast reasoning. The screenshots below show the signed-in runs. This is an illustrative comparison, not a reliability estimate.

The short request was: “Write a concise executive project update about the Northstar pilot.” It supplied no dates, results, risks, or rollout decision.

ChatGPT response to a vague project update request adding unsupported statements about progress and rollout
Test 1: the one-line request supplied no project facts, yet the response asserted progress, early signals, active risk owners, and a path toward a broader-rollout recommendation. Credit: Grow AI Skills editorial test capture. Open full-size image.

The response asserted that the pilot was progressing, that early signals were informing refinements, and that owners were tracking mitigations. It also proposed a path toward a broader-rollout recommendation. None of those project claims came from the request. The answer read like a plausible update, which made the unsupported claims easy to miss.

The second request supplied seven synthetic facts, named the audience, required three headings and a 120-word ceiling, and barred two misleading inferences. Here is the complete brief:

Northstar executive-update brief
You are drafting an executive project update.

Context: Northstar is a controlled onboarding pilot. The audience is the operations leadership team. Use only these facts:
- The pilot ran from August 4 to August 15, 2026.
- 18 participants started and 16 completed it.
- Median setup time fell from 42 minutes to 27 minutes.
- Five participants had an SSO connection problem on day one.
- Two participants withdrew because of scheduling conflicts.
- The next controlled test begins September 2, 2026.
- No expansion decision has been made.

Task: Write a concise executive update.

Output format: Use exactly three headings: Status, Evidence, Next decision. Keep the entire response under 120 words.

Quality rules: Preserve every number and date. Do not imply that the pilot caused the setup-time change. Do not imply that expansion is approved. Do not add facts or quotations.
ChatGPT response to a structured five-part prompt using three required headings and preserving supplied facts
Test 2: the structured brief returned the three required sections in 67 words and preserved all seven supplied facts and both decision boundaries. Credit: Grow AI Skills editorial test capture. Open full-size image.

In the signed-in repeat, the answer used the three required headings, stayed under the word limit at 67 words, and preserved the seven supplied facts. It compared the two setup-time values without claiming the pilot caused the change, and it left expansion undecided. We found no added factual claim in that returned update.

The two prompts differed in several ways at once, most importantly in the facts supplied. The example shows what happened when this brief included source facts and decision boundaries; it does not isolate the effect of five-part formatting or show how often another task or model would pass. The useful lesson for a reader is to make consequential facts and unresolved decisions visible before judging the draft.

Check the answer against the brief

A prompt can request a self-check, but the reviewer still needs to inspect the result. For the Northstar update, the acceptance criteria can be written before generating anything:

RequirementVisible passIf it fails
Preserve numbers and datesEach value matches the supplied briefCorrect the affected claim against the source
Keep expansion undecidedNo approval, rollout date, or commitment is impliedReject the unsupported decision language
Avoid a causal claimThe setup-time figures are compared without an invented causeRemove the causal explanation
Meet the requested shapeAll three headings appear once and the answer is under 120 wordsRevise the structure without changing protected facts

For another task, replace these rows with its own failure conditions. An email needs the right recipient and request; a data summary needs valid denominators and visible missing values. “Looks professional” cannot tell you whether either one is correct.

Fix a weak answer without restarting the task

Identify the failure and give the model the information needed to repair it. “Make it better” does not say which claim is wrong or what must stay fixed.

  • A fact is wrong: Point to the affected sentence, provide the source value, and ask for a corrected version that preserves the other checked facts. Recheck the whole draft afterward.
  • A required fact is missing: Supply it if you have it. If you do not, ask the model to mark it unknown or list the question a human must answer.
  • The format is wrong: Request a structure-only revision and explicitly preserve the approved facts, numbers, and citations.
  • The answer copies an example: Label that example as a pattern for structure or voice, then name the details that must not carry into the new output.
  • A claim needs current evidence: Provide a dated source or use a tool that can retrieve one. Open the cited source yourself and check that it supports the claim at the stated scope.

If the model repeatedly changes a protected number or invents a missing decision, stop revising the wording. Return to the source, narrow the task, or have a qualified person handle the consequential part. More prompt detail cannot make an unavailable fact true.

For a repeatable work brief, continue to the reusable template. If the difficult part is verifying claims and citations after the answer arrives, use the fact-checking guide.