This guide gives you a reusable starting pattern. It is designed to help you see the work more clearly; it is not a substitute for judgment, source checking, or responsibility for the result.
Prepare the inputs before you ask for output.
The model only sees what you give it. Spend a few minutes naming the reader, desired result, and uncertain information. This makes a first draft easier to assess and reduces the need for decorative rewriting later.
Give the task a useful brief.
Turn the notes below into a concise project update for [audience]. Project context: [one sentence] Raw notes: [paste notes] Tone: calm, direct, and specific Use these headings only when needed: Progress, Decision, Risk, Next step. Keep each item concrete. Do not claim work is complete unless the notes say so. End with one clear request, owner, or date if available. Then list information I should confirm before sending.
Replace every bracketed field with your real context. Read the output before reuse.
Four steps that keep the result usable.
- 1
Write one sentence of project context.
- 2
Include decisions and risks, not just completed tasks.
- 3
Specify the audience and tone.
- 4
Check names, dates, commitments, and status words yourself.
Start with the reader’s question
Most readers want to know whether the project is moving, whether anything changed, and whether they need to act. Shape the source notes around those questions before you use a prompt.
Keep status language honest
Words such as “complete”, “on track”, and “blocked” carry meaning. If a note only says a draft exists, the output should not imply final approval. Ask the tool to surface missing information.
One clear ask prevents update fatigue
If a decision is required, name the decision, the owner, and the date. If no action is required, say that instead. This distinction makes routine communication easier to scan and trust.
A worked example: a Friday ops update
For a weekly support update, the raw notes might say “deploy failed, retried, still flaky, customer reports up”. The shaped version should say what changed, what is being monitored, and who owns the follow-up. Writing the reader question first — “is the platform stable this week?” — stops the draft from becoming a list of every ticket touched.
Keep the update inside the record
Updates age quickly. When the draft includes a date, a build number, or a customer name, keep the source note beside it so a reader can check the record instead of trusting memory. If a status word like “almost done” appears, decide whether the notes actually support it or whether it should say “in review”. Precision here is what keeps a project update from becoming a story.
Run a human check.
- Could a busy reader explain the status after one pass?
- Are commitments attributed to a real owner or date?
- Did the draft add certainty the notes did not contain?
- Is there only one primary ask?
AI is strongest here when it makes missing information, structure, and options easier to see. The moment an output becomes a claim, commitment, or decision, bring a person back into the loop.