Friday, 4 pm. The steering committee pack is due Monday and you have a status report to write. Your tracker says 83 percent of tasks are done. You also know the vendor integration slipped twice, the test environment isn't ready, and a key engineer is leaving in three weeks. If the report says "Green, good progress," you're not lying exactly, but you're not telling the truth either.
That gap has a name: watermelon reporting, green on the outside, red inside. Sources on the topic describe the same causes again and again. Fear of delivering bad news, optimism in estimates, vague language such as "good progress," and basing status on task completion rather than measurable indicators. AI can help you write faster, but if you prompt it carelessly it will be the most fluent watermelon you've ever worked with. These prompts are built to push the other way.
These are untested templates. I haven't run them on a live project, and the worked example below is illustrative. This post is deliberately different from prompts for product managers, which is about specs, roadmaps and prioritisation. Here the focus is delivery: status, risk, actions and updates.
How do I write a status report with AI without sugarcoating it?
Make the model work from rules and data, not mood. Define what green, amber and red mean before you start, in numbers where you can.
You are drafting a weekly status report for [PROJECT] for [AUDIENCE: steering
committee / client / team].
RAG DEFINITIONS (apply strictly):
- Green: on track for the baseline date and budget, no open high risks.
- Amber: forecast slip of up to [N] days or [X]% budget overrun, or at least
one high risk with no mitigation in place.
- Red: forecast slip over [N] days, overrun over [X]%, or a blocker needing a
decision from someone outside the team.
DATA (use only this):
- Baseline end date: [DATE]. Current forecast: [DATE].
- Budget: [PLANNED] vs forecast [FORECAST].
- Milestones: [LIST with planned vs forecast dates and status]
- Open risks/issues: [LIST]
- Notes from the team: [PASTE VERBATIM]
Produce:
1. Overall RAG with a one-sentence justification that cites a number or date.
2. RAG per area (schedule, budget, scope, resourcing, quality).
3. What changed since last week.
4. Decisions or help needed, with who must decide and by when.
5. Next period plan: three items maximum.
6. A "contradictions" check: list any green rating that conflicts with the
data or the team notes.
No vague phrases ("good progress", "going well", "on track" without a date).
If data is missing, write [MISSING: ...]. Do not soften bad news.
Item 6 is the point. It forces the model to argue with its own summary. If the contradictions list is empty and you know the project is shaky, your inputs are what's wrong.
A related habit: report the forecast, not the task percentage. "83 percent of tasks complete" says nothing about whether the hard tasks are the ones left. Ask the model to restate progress as "remaining work in days" and "forecast finish," using your estimates.
Escalation without drama
Waiting until you're certain to escalate is a common failure in case studies on this topic. The report that tells the sponsor early is worth more than the perfect one that comes late. Use AI to write the unwelcome message cleanly.
Draft a short message to [SPONSOR] about a problem.
Facts: [WHAT HAPPENED, WHEN IT WAS FOUND, EFFECT ON DATE/COST/SCOPE]
What I know and don't know: [CERTAINTY LEVEL]
Options: [A, B, C with cost and date effect]
My recommendation: [IF ANY]
What I need from them, by when: [DECISION/DATE]
Under 150 words. Lead with the impact, then the ask. No blame, no hedging,
no 'unfortunately'.
Risk registers: use AI to find risks, not to score them
A model is a decent brainstorming partner for risks you haven't thought of, because it has seen many project failure patterns. It's a poor judge of how likely they are on your project.
Project: [DESCRIPTION: goal, scope, team size, duration, key vendors, tech,
regulatory context]
Plan summary: [MILESTONES, DEPENDENCIES]
Known constraints: [BUDGET, DATES, FIXED DEADLINES]
Generate candidate risks, grouped by: schedule, scope, resources, vendors,
technical, stakeholders, compliance, external. For each give:
- Risk statement in the form "If [cause], then [event], resulting in [impact]"
- Early warning sign I could observe
- One mitigation and one contingency
- A question for the team that would help rate its likelihood
Do NOT assign likelihood or impact scores. Mark any risk that depends on an
assumption about my project with [ASSUMPTION: ...]. Give 15 maximum,
prioritising specific over generic.
Then run a short session with the team: strike what doesn't apply, score likelihood and impact together, name an owner for each live risk. The "If, then, resulting in" form matters because it separates cause from event from impact, which makes mitigation clearer.
One more use. Paste your existing register and ask: "Which of these are written as issues, not risks (already happened)? Which have no owner? Which mitigations are just 'monitor'? Which risks conflict with this week's status report?" The last question ties the register to the status. A register that's never reviewed makes a green dashboard look more reliable than it is.
Meeting notes to actions
Turn a transcript or rough notes into decisions and actions, but control the output format so nothing is invented.
Below are notes/transcript from a project meeting. Extract:
DECISIONS: what was decided, by whom (only if stated).
ACTIONS: action, owner, due date. Only include an owner or date if it was
stated explicitly. Otherwise write UNASSIGNED or NO DATE. Do not infer owners
from job titles.
RISKS RAISED: anything mentioned as a concern, even in passing.
OPEN QUESTIONS: things asked but not answered.
DISAGREEMENTS: where people didn't agree and what was left unresolved.
Quote the line each item comes from. If you're unsure whether something was a
decision or a suggestion, put it under OPEN QUESTIONS.
TRANSCRIPT:
[PASTE]
Before you circulate it, read the action list yourself. A meeting where everyone nodded and nobody said "I'll do it" will produce actions with no owner, which is a correct output and an uncomfortable one. Better to see it now.
A note on privacy. Recording and transcribing laws differ by country and sometimes by region, so tell attendees, check your company's policy, and keep sensitive HR or legal discussions out of the tool. Use only tools your IT team has approved.
Stakeholder updates: one fact base, several audiences
The same status has to be told differently to an engineering lead, a sponsor and a client. Don't write three versions by hand. Write one fact base and ask for rewrites.
Fact base (the only source):
[YOUR STATUS FACTS, RAG, DECISIONS NEEDED]
Write the update for [AUDIENCE].
- Sponsor: 120 words, outcome and decisions first, no jargon.
- Technical lead: include dependencies, blockers and specific tickets.
- Client: factual, no internal blame, say what we're doing about delays.
Rules: every version must carry the same RAG and the same dates. If a version
would require leaving out a material problem, keep the problem in and tell me.
The last rule protects against the quiet drift where the client version is greener than the internal one.
A worked example (illustrative)
An invented scenario to show the output shape, not a real run.
Inputs: baseline end date 15 Dec, current forecast 29 Dec. Integration milestone slipped twice. Test environment not ready. Team note: "Priya leaves 31 Oct, no replacement yet." Your RAG rules say amber is up to 10 days slip, red above.
What the report should say (shape):
Overall: RED. Forecast finish is 29 Dec, 14 days after baseline (red threshold
is 10).
Schedule: RED. Integration milestone has slipped twice (now 6 Nov).
Resourcing: AMBER. Key engineer leaves 31 Oct; no replacement approved.
Decision needed: Sponsor to approve backfill or move the end date, by 17 Oct.
Contradictions check: "83% of tasks complete" looks green but the remaining
17% includes integration and testing, the longest-duration items.
An honest red with a decision and a date is better for you than amber that turns red in three weeks. If your culture punishes red, that's the thing to fix, and no prompt will do it for you.
Failure modes to check for
| What goes wrong | Why | What to do |
|---|---|---|
| Everything is green | Model mirrors the optimistic tone of your notes | Strict RAG rules; contradictions check |
| Invented progress | It fills gaps with plausible detail | [MISSING] rule; paste data, not descriptions |
| Wrong owner on an action | It guesses from roles | Owner only if stated; review before sending |
| Generic risks | "Scope creep" and "resource constraints" with no specifics | Give project detail; ask for early warning signs |
| Scores that look precise | 4x3=12 with no basis | Don't ask it to score |
| Different truths for different audiences | Rewrites soften bad news | One fact base; same RAG rule |
What not to automate
- The RAG call itself. The model applies your rules; you own the rating and what it means.
- Risk scoring and ownership. These are conversations between people who will have to act.
- Escalation timing. Deciding when to tell the sponsor is a judgment about trust and context.
- Anything touching people. Performance concerns, conflicts and attrition risks need your words, not a template.
- Circulating notes unread. An AI action list sent without checking creates commitments nobody made.
For turning the output into reusable structure, giving context explains why the inputs matter more than the instruction, and XML tags and delimiters helps when you paste long notes next to rules. For the people side of work, AI prompts for HR covers adjacent territory, and the prompt library has more ready templates.
