You will be able to add constraints and format instructions so the output needs little editing before you use it.
Open the context paragraph you wrote in lesson 1.2 and add four instructions to the end of it: length, tone, structure, and what to leave out. Your paragraph already tells the model what situation it's writing for. It doesn't tell the model what the finished draft should look like. Without that, the model makes its own choices, and those choices are the average of everything it has seen.
Priya works in HR and was writing an announcement to drivers about a change to outpatient claims. The change involves an app, and the message has a start date and the HR counter hours. The drivers read it on their phones in a WhatsApp group. They already know what an outpatient claim is, and some may doubt the change.
Her context paragraph from lesson 1.2 worked. The assistant understood who the drivers were and why they might doubt the change. The first draft still ran to 320 words. It opened with "Dear valued colleagues", explained what an outpatient claim is, and ended with "Warm regards, HR Team", even though it was going to a WhatsApp group. Nothing in it was wrong, but she had to cut half before she could send it.
Context tells the model what situation it is writing for. Constraints and format tell it what the finished output should look like. Priya had given the model context but no constraints or format.
"Keep it short" means different things to different people. To a model it might mean 200 words instead of 400. Give a limit the model can actually work to, such as under 150 words, five bullet points, three sentences, one page, or a subject line of no more than eight words.
Models are better at counting items than counting words, so "five bullet points" is usually followed more closely than "120 words". Use an item count where the format allows it. The model can miss a word limit, so check the count if it matters.
Say why the limit is there, because a model that knows the reason makes better choices about what to cut. Priya wrote "under 80 words, because it will be read on a phone", and giving the reason helped.
Adjectives on their own give the model very little. "Professional but friendly" can mean anything from a bank's terms and conditions to a cheerful sales email, and "Write in a friendly tone" is a weak instruction for the same reason.
A reference point works better. It names a specific person writing in a specific situation, which the model has seen many examples of. Priya asked for the message to be written the way a supervisor who knows the drivers by name would post in the group chat. That implies short sentences, no corporate phrases, direct instructions, and warmth without fuss. Other reference points that work include how you'd write to a senior client you've known for years, how a GP explains a result to a worried patient, and how you'd brief your own manager in a corridor.
If you know the shape you need, say so. The more precisely you name it, the less reformatting you do afterwards. You might ask for a table with columns for plan, monthly price, data and contract length, a subject line over three short paragraphs, or numbered steps a new staff member could follow without asking anyone.
Work backwards from where the output is going. Output for a spreadsheet should come as a table. An email draft is easier to paste when the subject line and body come separately. A slide needs a heading with no more than four short points under it. Priya asked for one message she could paste straight into WhatsApp, with the date in the first line and the HR counter hours as the last line. That instruction on its own moved the most important fact to the top.
Models fill gaps by default. If you don't say "no sign-off", one may appear anyway. Without an instruction against guessing, a draft about a price change may invent a percentage. Without an instruction to avoid jargon, a message to drivers may mention a "digital claims workflow". So name what you don't want. These four exclusions are useful in many requests:
Do not guess figures, dates or names that are not in the message. Use a placeholder in square brackets instead. No greeting or sign-off, because the message is going into a group chat. Do not explain what an outpatient claim is, because the readers already know. Avoid jargon and corporate phrases such as "exciting" or "we are pleased to announce".
Add the no-guessing exclusion to anything involving facts. It turns an invented figure you might not notice into a visible blank in square brackets that you fill in yourself.
Priya's full request was her lesson 1.2 context paragraph followed by these instructions: write the announcement; keep it under 80 words because staff read it on their phones; write it the way a supervisor who knows the drivers would post in the group chat; start date in the first line, HR counter hours in the last; no greeting or sign-off; no explanation of what an outpatient claim is; no details she hadn't given, such as how to download the app. The result was 71 words long, opened with the date, and needed one word changed.
Results aren't always that smooth. Models sometimes ignore one instruction in a list, especially when instructions pull in different directions, such as "very short" and "include all the details". When you run your own request, check the result against each instruction, and check the word count if length matters. If an instruction slipped, note which one. It was either unclear or it clashed with another instruction, and both are easy to fix once you know which.
Now test this on your own context paragraph, and keep your expectations realistic. The first run probably won't give you a perfect draft. Use it to see which of your instructions the model treats as firm and which it treats as a suggestion.
Take your context paragraph from lesson 1.2 and add three constraints and one format instruction. Run it, then mark the instruction the output ignored.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).