Module 3 · Ask clearly
The request checklist: six parts
In short
We check every request to AI against six parts: Goal, Reader, Material, Limits, Shape, Check. The material you paste must represent reality, messy parts included.
After this lesson you can
- Write a request in six parts: Goal, Reader, Material, Limits, Shape, Check
- Choose material and examples that represent the real data
Terms in this lesson
Understand
A new colleague on their first day needs a complete briefing. So that no important part is forgotten, we check every prompt against one checklist. It has six parts: Goal, Reader, Material, Limits, Shape, Check.
Goal: what you want to achieve, and what you will do with the result. "A summary of complaints" is different from "a summary of complaints to decide which fixes to work on next month". The second tells the model what matters and what it can drop.
Reader: who will read the result. The board, a teammate, a customer and a field officer need different words, length and level of detail.
Material: the text, figures or documents to use. Paste the material in, do not just mention it. The model cannot open your filing cabinet, and if the material is missing it fills the gap with guesses.
Limits: what must not be done, how long, and the tone. For example: do not add facts beyond the material, at most 200 words, friendly but not casual.
Shape: the form of a result you can use straight away. A table with given columns, a numbered list, a full email draft with a subject line, or bullet points for a slide.
Check: how you will check the result, and what the model should flag to make checking easy. For example: mark sentences the material does not support, or name the part of the source behind every figure.
The order is up to you, but one habit helps. Write Goal and Reader first. Paste the Material at the bottom under a clear marker, such as the heading "Material:", so the model does not mix the material with your request. If the material is long, repeat your short request once more after it, so the request does not sink under a pile of text.
Not every request needs six long sentences. To rewrite one paragraph, one sentence per part is enough, and some parts can be combined. What matters is that you have thought about all six. The parts most often forgotten are Reader and Check, yet those two decide most whether the result is usable as is. Limits and Shape get their own lesson next.
Of the six parts, Material is the one that most often sends a result off course without you noticing. There are two things to choose on purpose.
First, the material must represent the real situation. If you want AI to help tidy order data, do not paste only five rows that are already neat. Include messy rows too: incomplete addresses, an item name written two ways, dates in different formats. Material that is too clean produces a draft that is clean too, which then fails as soon as it meets messy office data.
Second, examples in a prompt carry a lot of weight. One example of the result you want is often clearer than three paragraphs of explanation, because the model is good at imitating patterns. But for that very reason it can copy your example too closely: its length, its wording, even its mistakes. Give two or three examples that differ from each other, and say which part to imitate (for instance the column layout) and which part not to (for instance the content).
One more thing: do not paste personal or confidential data just because it is "representative". Mask it first. The Protect the data module shows how.
Before
The prompt
Please make a summary of this month's customer complaints.
What came back
Here is a summary of this month's customer complaints: - Many customers complained about long delivery times. - Some customers were disappointed with product quality. - There were complaints about slow customer service responses. Overall, customer satisfaction should be improved by fixing the delivery process and training staff.
After
The prompt
Goal: I need to decide on two fixes to work on next month, based on this month's customer complaints. Reader: the head of customer service, reading between meetings. Material: 42 complaints from the form, pasted below. Some are terse and some mix in a regional language. Limits: use only the complaints below, add no guesses. At most 150 words outside the table. Shape: a table with columns Complaint group, Count, One example quote. Most frequent first. Below it, two proposed fixes, one sentence each. Check: say how many complaints you could not group, and mark groups with fewer than three complaints. [42 complaints pasted here]
What came back
Complaint group | Count | Example quote Parcel arrived after the promised date | 17 | "They said two days, it took six." Tracking number cannot be traced | 11 | "The tracking number is not found on the site." Item does not match the order | 6 | "Ordered large, received medium." Service phone not answered | 5 | "Called three times, nobody picked up." Could not be grouped: 3 complaints. No group has fewer than three complaints. Proposed fixes: 1. Review the delivery promise on the order page, since lateness is the most common complaint. 2. Send the tracking number only after the parcel is handed to the courier, so it can be traced from the start.
What changed
- Without Material, the model invents complaints that sound generic. With material, the content comes from the 42 complaints that came in.
- A clear Goal (choosing two fixes) makes the model rank and propose, not just summarise.
- The Check part makes the model report what it could not group, so you know what to read yourself.
- Saying the material "mixes in a regional language" tells the model the data is messy, as it really is.
Common mistake
- Mistake
- Testing or giving examples with tidy made-up data, while your everyday work data is messy.
- Why it hurts
- The result looks perfect, so you believe the prompt is ready. When it meets messy rows, mixed language or empty fields, the result goes wrong, and usually nobody notices straight away.
- Do this instead
- Take material from real work, mask the personal parts, and deliberately include a few hard or incomplete examples.
Try
For each part of the checklist, first answer the question for one of this week's tasks, then open the card.
What will you do with the result? Which decision does it support?
Who reads it, what do they already know, and how long do they have?
Which text or figures must be used? Have you pasted them, messy examples included?
What is off limits, how long should it be, and what tone?
What form can you use straight away: a table, a list, an email, slide bullets?
How will you check the result, and what should the model flag for you?
You want AI to help draft standard replies to customer questions. Which sample questions should you include?
A request in six parts
Works with any AI assistant.
Your prompt
Goal: I need ‹tujuan›. Reader: ‹pembaca›. Material: pasted below. ‹catatan-bahan› Limits: use only the material below. At most ‹panjang›. Tone: ‹nada›. Shape: ‹bentuk›. Check: mark every sentence the material does not support, and say what the material is missing. [paste material here]
Take home
Before you press send
- Goal: I wrote what I will do with the result.
- Reader: I named who reads it and how much detail they need.
- Material: I pasted material that represents reality, already masked.
- Limits: I wrote what is off limits, the length and the tone.
- Shape: I named a form I can use straight away.
- Check: I know how to check it and asked the model to flag what needs checking.
What went wrong for us
A local env file that changed test results
- Context
- A client's programme app had a local environment file for development.
- What happened
- That file turned on a debug flag that opened all access. The automated tests read it too, so the authorisation tests failed, but only on that machine.
- Impact
- Test results differed between machines, and time went into hunting a bug in code that was actually correct.
- Root cause
- The test framework loaded the local env file automatically, so a developer's settings leaked into the tests.
- What we did
- The debug flag was turned off for tests, and the tests were rerun.
- The guard we keep now
- Tests set the environment values they need themselves, and debug flags may not be on in test mode.
The lessonA good test knows exactly what environment it runs in.
What it means for your workA result that works at your desk may not work elsewhere. When you try or test something, use the same material and conditions as the real work.