Verified against ChatGPT · 2026-08-12
Write a project status update that surfaces real risk instead of defaulting every line to "on track"
Builds a stakeholder-ready project update from raw notes where status per workstream is graded against actual evidence, not optimistic rounding, and any risk gets a real next step attached.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are writing a project status update for stakeholders from my raw working notes. My past updates have all had the same problem: everything gets rounded up to "on track" because that's the easy, safe-sounding thing to write, and then a real problem surfaces two weeks later that stakeholders had no warning about. RAW PROJECT NOTES Backend team says API integration is 'mostly done, just a few edge cases left'; design is waiting on stakeholder sign-off that's been pending 5 days; QA hasn't started yet. WORKSTREAMS AND THEIR OWNERS Backend integration (owned by Priya), Design sign-off (owned by Marco), QA (owned by Sam). ORIGINAL TIMELINE AND MILESTONES Full launch scheduled for Sept 1; design sign-off was supposed to complete by Aug 5. WHO IS READING THIS UPDATE Non-technical VP who wants plain-language status, not engineering jargon. For each workstream, assign a status of on-track, at-risk, or blocked based strictly on the evidence in my notes, not on how the workstream owner phrased their update to me — if the notes describe a slipped date, an unresolved dependency, or a "we're a bit behind but should catch up," that is at-risk or blocked, not on-track, regardless of how casually it was mentioned. Do not round a genuinely uncertain status up to on-track just because no one has explicitly called it a problem yet. For every at-risk or blocked item, state the specific evidence that earned that status, the concrete next step being taken, and the date by which it needs to resolve before it affects the overall timeline — an at-risk flag without a next step is just an alarm with no plan attached, which is nearly as unhelpful as no flag at all. Compare current progress against the original timeline explicitly and say plainly whether the overall project is still on schedule, not just whether individual workstreams feel fine in isolation — several workstreams can each be individually "mostly fine" while their combined slippage still threatens the milestone. Tailor the level of technical detail to the stated stakeholder audience, but never let that tailoring soften an actual risk into vaguer language. WHAT NOT TO DO Do not use the phrase "on track" for anything with an unresolved open risk attached, even a small one. Do not bury the riskiest workstream at the bottom of the list. OUTPUT FORMAT Overall project status (one line). Then per workstream: status, evidence, next step, resolution date if at-risk/blocked. Order workstreams by risk level, riskiest first.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The reason status updates drift toward uniform "on track" language isn't usually dishonesty — it's that casual, hedged phrasing from a workstream owner ("mostly done, just a few edge cases") gets faithfully summarized by a model into equally casual, reassuring-sounding language, which reads as on-track even when the underlying evidence describes something genuinely uncertain; explicitly instructing the model to grade status against the evidence rather than the tone of the source notes breaks that mirroring effect and forces a harder, more useful judgment call. Requiring a specific next step attached to every at-risk or blocked item targets a common failure in AI-generated status reports: it's easy for a model to correctly identify a risk from the notes but then stop there, producing a flag with no accompanying plan, which functionally tells a stakeholder there's a problem without telling them what's being done about it — arguably worse than no flag, since it invites anxious follow-up questions the update should have already answered. Explicitly requiring an aggregate on-schedule judgment, not just per-workstream status, addresses a structural blind spot: several workstreams individually described as "a little behind but manageable" can combine into a genuine milestone risk that no single workstream status captures on its own, and a model working workstream-by-workstream without an aggregation step will never surface that combined effect unless specifically told to check for it. Ordering by risk level rather than by whatever order the workstreams were listed in matters because burying the riskiest item at the bottom of a list is a subtle way status updates hide problems even when every individual status is technically accurate — a stakeholder skimming from the top should hit the worst news first, not last.
What you get back
Overall: at risk — combined slippage in design sign-off and unstarted QA threatens the Sept 1 launch date.
1. Design sign-off — AT RISK — evidence: stakeholder approval pending 5 days past the Aug 5 target — next step: Marco escalating directly to the approver today — resolution needed by Aug 15. 2. QA — AT RISK — evidence: has not started, was scheduled to begin Aug 10 — next step: Sam starting as soon as backend edge cases close — resolution needed by Aug 18. 3. Backend integration — ON TRACK — edge cases remaining are scoped and estimated at 2 days.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
