Ask for what you want

01What this module is about

Your project from Module 1 gives the AI the background. This module is about the request itself: the message you type each time.

Most poor answers come from requests that leave the AI guessing. It doesn't know who the work is for, how long it should be, or what "good" means to you. So it guesses, and it fills the gaps with something safe and bland.

A good request takes a minute longer to write and saves you three rounds of "no, not like that".

By the end of this module you'll have a simple shape for any request, and you'll have used it on your own project.

02The four parts of a good request

Every good request answers four questions. You don't need headings. You just need the answers to be there.

1. What do you want? The thing you want back, in one sentence. "A 300-word newsletter" not "something about the walks".
2. What should it know? Who it's for, why you need it, and anything the AI can't see. Your project files cover the background. Add what's new today.
3. What are the limits? Length, tone, format, and anything it must not do.
4. What does done look like? How you'll judge it. "Three bullet points I can read out at the AGM" tells the AI exactly what to aim for.

03Text to copy

Here is a request for the walking club, without the four parts:

Write something about the walks.

And the same request with them:

Write the walks section of the March newsletter.
It's for members who missed the last meeting, so don't assume they know the routes.
Cover both March walks from the Reference file.
Keep it under 150 words, friendly, with one short paragraph per walk.
Done means: someone could read it and turn up at the right place and time.

Here is the shape to copy for your own requests. Fill in the square brackets.

[What you want, in one sentence.]
It's for [who], because [why].
[Anything it needs to know that isn't in your project files.]
Keep it [length], [tone], in [format].
Don't [anything it must not do].
Done means: [how you'll know it's right].

04Four habits that make the biggest difference

1. Swap vague words for specific ones. "Short" means different things to different people. "Under 150 words" doesn't. The same goes for "simple", "professional" and "better". If you can measure it or point to it, say that instead.

• "Make it shorter" becomes "Cut it to under 100 words."
• "Make it more professional" becomes "Write it as a letter to the council. No jokes."
• "Make it better" becomes "The opening is weak. Start with the date of the AGM."

2. Give a reason for each rule. A rule on its own gets followed. A rule with a reason gets understood, and the AI can apply it to cases you didn't think of.

• "No jargon" works.
• "No jargon, because most members are retired and don't use the internet much" works better. The AI will now avoid things you never listed.

3. Show an example when the format matters. If you want something to look a certain way, paste in an example of it. One good example beats a paragraph of description. Say clearly that it's an example, so the AI copies its style and not its content.

Here's how last month's walk notice looked. Match this style:
[paste last month's notice]

4. Say what to do, not only what not to do. "Don't use bullet points" leaves the AI guessing what you do want. "Write it as two short paragraphs" tells it.

05Things that don't help

• Shouting. Writing rules in capitals, or "CRITICAL" and "you MUST", doesn't make newer AI follow them better. It can make the AI overdo that one rule. Write it calmly, and give the reason.
• Flattery instead of facts. "You are a world-class award-winning writer" is no substitute for the four parts. A plain role can help, like "You help me write the club newsletter". But telling it who the work is for and what good looks like helps far more.
• Asking for everything at once. A newsletter, a poster and an email to the council in one request means three average results. Ask for one thing at a time. You'll do more of this in Module 6.

07Common problems

• The answer is still generic. Something is missing from part 2, what it should know. Ask yourself what you know that the AI doesn't.
• It ignores a rule. The rule may clash with something in your project files, or it may be buried. Put it on its own line, with its reason.
• It's the right content in the wrong shape. Part 3 or 4 is missing. Say the length and format, or paste an example.
• You keep writing the same rule. Move it into your Instructions from Module 1, and paste them into your tool again. Then you never type it again.

08Keeping it current

• When you find yourself typing the same thing twice, move it into your project files. Rules go in Instructions. Facts go in Reference.
• Save the requests that work well. Keep a note of your best ones and reuse them.