Write a decision-ready [REPORT TYPE] for [AUDIENCE] using only the material in [SOURCE NOTES]. The report covers [REPORTING PERIOD] and must support the following purpose: [DECISION OR ACTION NEEDED]. First, identify the report's central conclusion in one sentence. Then produce a report of 700-1,000 words in this exact structure: 1. Executive summary: 3-5 bullets covering the current state, the most consequential change since the prior period, and the decision or action requested. 2. Progress against plan: a table with workstream, planned outcome, current status (on track, at risk, blocked, or complete), evidence from the notes, and variance from plan. 3. Decisions and dependencies: list each decision needed, its recommended owner, deadline, options if they are present in the notes, and consequence of no decision. Separate external dependencies from internal ones. 4. Action plan: a table with next step, single accountable owner, due date, required input, and success condition. Do not assign a person unless the notes identify that person or role. 5. Risks and issues: for each, state likelihood, impact, early warning sign, mitigation, contingency, and owner when supported. 6. Appendix: short list of source gaps, assumptions, and metrics that need confirmation. Use plain business language. Distinguish completed work, planned work, and recommendations; do not write a recommendation as an accomplished fact. Preserve exact dates, numbers, and names from the notes. If dates conflict, show the conflict rather than resolving it. Before answering, run two checks: flag every claim, owner, date, or metric that is not supported by [SOURCE NOTES]; and confirm every action has one accountable owner, a due date, and a testable success condition. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [REPORT TYPE] | Enter the report format, such as weekly project status report, incident report, or board update. | weekly implementation status report |
| [AUDIENCE] | Enter the people who will read the report and what level of detail they need. | VP of Operations and the launch steering group |
| [SOURCE NOTES] | Paste meeting notes, project updates, metrics, decisions, and other source material. | CRM migration: data mapping is 80% complete; Priya owns field validation by May 16. Vendor test environment was unavailable May 8-10. Sales requested a two-week pilot before cutover. Target cutover remains June 3, but no decision has been made on the pilot. |
| [REPORTING PERIOD] | Enter the dates or milestone period the report covers. | May 6-10 |
| [DECISION OR ACTION NEEDED] | State the decision, approval, or next action you want readers to take. | Approve or decline a two-week sales pilot by May 15 so the June 3 cutover date can be confirmed. |
How to use
- Paste your unedited notes, including contradictions and unfinished items, into [SOURCE NOTES].
- Set the audience and the one decision or action the report must drive.
- Check the action-plan table for missing dates, named owners, and success conditions before sending it.
- Follow up with: “Turn the executive summary into a 150-word email for [AUDIENCE], keeping all dates and decisions unchanged.”
Variations
Board update
Use when leaders need a brief governance-level update.
Create a 400-word [BOARD OR STEERING COMMITTEE] update from [SOURCE NOTES] for [AUDIENCE]. Include: overall status; three material accomplishments or changes; decisions requested with a recommendation and deadline; top three risks with impact and mitigation; and a next-30-days outlook. Use only facts in the notes. Do not include operational detail unless it changes cost, timeline, scope, compliance, or customer impact. Flag unsupported claims and any decision that lacks a named owner or deadline. Ask up to 3 questions only if required inputs are absent.
Incident report
Use after an outage, safety event, or material operational failure.
Draft a blameless [INCIDENT TYPE] report from [TIMELINE AND EVIDENCE] for [AUDIENCE]. Include a factual summary; customer or business impact with duration and scope; time-stamped timeline; contributing conditions versus confirmed root cause; actions taken; corrective and preventive actions with owners and due dates; and open questions. Do not infer root cause or assign fault beyond the evidence. Flag missing timestamps, unsupported causation, and actions without an accountable owner. Ask up to 3 questions only when needed.
Client progress report
Use when a client needs visibility without internal delivery detail.
Write a client-facing [REPORTING PERIOD] progress report for [CLIENT] from [PROJECT NOTES]. Produce 500-700 words with: accomplishments tied to agreed deliverables; current milestone status; decisions or materials needed from the client; next steps with dates; and risks framed with practical mitigation. Keep internal staffing discussions and unconfirmed concerns out unless they affect the client’s scope, cost, or date. Do not promise outcomes not documented in the notes. Check that every requested client action has a clear deadline and consequence.
Tips
- Put raw notes in chronological order when timing matters; this makes missed handoffs and blocked dependencies visible.
- Use one accountable owner per action; contributors can be named separately, but shared ownership often leaves work unclaimed.
- Label a date as a target when it is not committed, and do not turn a discussion point into a decision.
- For recurring reports, keep status definitions fixed so “at risk” means the same thing from one period to the next.
FAQ
Can I use this prompt with incomplete meeting notes?
Yes. It tells the AI to list gaps and unsupported claims instead of filling them in. Add any known dates or owner names before sending the final report.
How long should a project status report be?
Use the length the audience can act on. A leadership update is often 300-600 words plus tables, while a delivery report can need more evidence and detail.
Should risks and issues be separate?
Usually. An issue is already happening; a risk is a future uncertainty. Keeping them separate makes mitigation and escalation clearer.