A project retrospective prompt tackles the hardest part of writing a retrospective: the project is done, the records are scattered across chats, documents and meetings, and when you try to write it up you end up with either a highlight reel or a blame-shifting chronicle. The prompt below hands the AI the goals, the actual results and the process log first, then has it split the write-up into gaps, root causes and fixes, so you can copy it, fill in the variables and get a draft you can take straight into the retrospective meeting.
The hard part is not the summary, it is naming the gap
A retrospective differs from a summary in one way only: a summary says what was done, while a retrospective must state where the result fell short of the goal, why it fell short, and what changes next time. That is why the material you feed the AI needs two anchors, the goal and the actual result. With a process log but no goal, the AI can only reshuffle the log; with results but no process, the root causes become guesswork. If this is just a routine progress report with no need to chase causes or fixes, a weekly-report style write-up is enough and the retrospective structure is unnecessary.
The prompt, ready to copy
You are a facilitator who has run many project retrospectives. Based on the information below, turn this project into a retrospective draft I can take straight into the review meeting.
Project goals and actual results: {{goals and results}}
Process log: {{process log}}
Purpose of the retrospective: {{purpose}}
Number of fixes: {{number of fixes}}
Output rules:
1. Start with a goal-versus-result comparison: for each item, state the original goal, the actual result and the gap. Use numbers for gaps wherever possible, and do not invent figures that are not in the log.
2. Then group the problems by root cause into four categories: planning, collaboration, resourcing and external changes. Each problem must point to the event in the process log it comes from. Do not invent causes that cannot be found in the log; where information is missing, mark it as insufficient information and state exactly what is missing.
3. Give the things that went well their own section: keep only practices that the log supports and that are worth repeating, and for each one state what was done at the time and what result it produced.
4. Finish with a table of fixes with these columns: what will change, which role owns it, when it will be checked, and what standard shows it worked. Use the number of fixes I gave; do not pad the list, and do not write unverifiable filler such as improve communication or pay more attention.
5. Keep the whole draft about the work, not the people: no naming-and-blaming language. Where the log contains conflicting accounts, list both versions and mark them as to be confirmed.
Output the comparison first, then the problem groups, the things that went well and the table of fixes, with no long introduction before it.How to fill the four variables
- {{goals and results}}: write goals and results in pairs. For example: planned launch at the end of September, actually launched on October 12; target conversion rate 3%, actual rate after two weeks 2.1%. If you only write the project finished successfully, the AI has no gap to work with.
- {{process log}}: paste whatever you have in time order: key milestones agreed in chat, the note sent when things slipped, meeting conclusions. A messy log is fine, but do not mix later judgements into the raw record; judgements belong to the retrospective itself.
- {{purpose}}: state who will read the draft and what must be decided with it. For example: for an internal team meeting that must settle three fixes for the next version. For a management version, note in this variable that only gaps and the fix plan are reported, without internal dispute details.
- {{number of fixes}}: give a small number, usually 3 to 5. The most common retrospective failure is not missing problems; it is listing twenty fixes and landing none of them. A tight cap forces priorities.
Once you get the draft, check these three places
First, the numbers: every figure in the comparison must trace back to the process log or the result data. The AI turning an estimate into an exact value, or copying a planned figure into the actual results, are common errors; correct them to what the log says. Second, the depth of the root causes: it slipped and communication was poor are symptoms, not causes. A usable root cause answers why it slipped, for example requirements were frozen two weeks later than planned, or the test environment was only ready three days before launch. Third, whether each fix can be verified: every fix needs a check date and a success standard; if either is missing, send it back and have the AI complete it before you finalize. If the retrospective is held face to face, afterwards you can use the meeting notes prompt to turn the agreed fixes and owners into an action list.
When the draft drifts, pull it back with these follow-ups
- It is all achievements and the problems are glossed over: ask it to keep only achievements supported by the process log, expand the problem section by root cause, and delete unsupported achievements.
- The root causes stay at symptom level: ask it to ask why three times on the first problem, with each level landing on a concrete event or date in the process log, and to mark anything it cannot land as insufficient information.
- The fixes are all slogans: ask it to rewrite each fix as a concrete action with an owning role, a check date and a success standard, and to delete any fix it cannot rewrite instead of padding the count.
