Write down the goal, context, output format, and checking rule. This is an editorial method for defining a request, not a special feature of a particular AI service or a guarantee of a correct answer.
“Summarize this” leaves a lot open. Are you preparing for a meeting, handing work to a colleague, or trying to decide what to do next? The same source material can serve each purpose, but the useful output will look different.
1. Name the job you want to finish
Instead of “make this better,” describe what you need to do with the result. “Identify the decisions I need to make before tomorrow’s meeting” gives you a way to judge whether the answer helped.
For a travel-planning draft, the goal might be to separate reservations you still need to make from ideas you have not chosen. For meeting notes, it might be to distinguish confirmed tasks from suggestions. These are hypothetical examples of a brief, not instructions based on a real itinerary or meeting.
2. Include the conditions that change the answer
State who will read the output, what is already decided, and which constraints are essential. If you are writing to someone who missed the meeting, say so. If the result must fit in a short email, make that part of the request.
Separate requirements from preferences. “Keep every confirmed deadline” is different from “use a friendly tone if possible.” That distinction also helps you review a response that cannot satisfy every preference.
You do not need to include private information merely to make a request detailed. Replace unnecessary names with labels and omit passwords, account numbers, and unrelated personal details. Keep the information the task needs, rather than everything the source happens to contain.
3. Specify the shape you will actually use
If you need a table, name its columns. If you need an email, define its audience and approximate length. Here is a brief for turning meeting notes into a list of follow-ups:
Goal: Help me identify what needs follow-up from these meeting notes. Context: A colleague who missed the meeting will read this. Separate confirmed tasks from suggestions. Output: A table with Item / Status / Owner / Deadline / Question to resolve. Check: Do not invent owners or dates. Write “needs confirmation” when the notes do not specify them. Source notes: [Paste the relevant notes here, with unnecessary personal details removed.]
You can start with an outline or table before asking for a finished document. That gives you a smaller result to check before spending time polishing an answer built around the wrong goal.
A fictional example, from notes to checked rows
Suppose these are the entire source notes: “Morgan agreed to send the draft agenda by Tuesday. We discussed a customer interview; nobody volunteered and no date was chosen.” A table faithful to those notes would look like this:
| Item | Status | Owner | Deadline | Question to resolve |
|---|---|---|---|---|
| Send draft agenda | Confirmed | Morgan | Tuesday | None stated |
| Customer interview | Suggestion | Needs confirmation | Needs confirmation | Will this become an assigned task? |
If a generated version assigns the interview to Morgan for Tuesday, it has carried details from one item into another without support. A precise follow-up would be: “The notes assign only the agenda to Morgan. Keep the interview as a suggestion and mark its owner and deadline as needs confirmation.” Then compare both rows with the notes again. This table is an editorial illustration, not a transcript of an AI test.
4. Say what must not be filled in
A well-formatted answer can still contain unsupported information. Compare names, numbers, dates, quotes, and assignments with the original. If the answer cites a source, open it and check that it supports the claim rather than treating the presence of a link as proof.
Make the next request address one observable problem. The table below shows which part of the brief to repair.
Choose the line that needs a repair
Use this diagnostic when deciding what to change in the brief. These are suggested edits, not promises about a model’s response.
| What went wrong? | Line to revise | A concrete edit |
|---|---|---|
| The answer covers everything except your next decision. | Goal | “List only decisions needed before the planning meeting.” |
| It ignores who will read the result. | Context | “The reader missed the meeting; explain each project label once.” |
| The prose is hard to turn into tasks. | Output | “Use one row per item with the five named columns.” |
| It turns missing details into confident statements. | Check | “Mark unstated owners and dates as needs confirmation.” |
A blank brief to copy
Goal: I want to finish ______ using this result. Context: The reader is ______. The essential conditions are ______. Output: Use ______ format and approximately ______ length. Check: Use the supplied material. Mark missing information as ______.
Before sending or acting on the result, return to those four lines. Does the response do the job, respect the conditions, and preserve the distinction between known and missing information? A useful brief leaves you with a review standard. It does not remove the need to review.