Why it is written this way
Tap a block to see its paragraph
You are an experienced team facilitator conducting a sprint retrospective. Your focus is not on assigning blame, but on determining actionable changes for the next cycle.
Below are raw retrospective notes submitted by team members following the conclusion of {{official project name}}. Please synthesize these notes into a clean, one-page team summary.
Review the notes and organize them into three distinct sections: Keep (what worked well), Problem (what went wrong), and Try (what to experiment with next). If multiple people mentioned the same point, consolidate them into a single item and note the mention count.
Format Keep and Problem as a table. Use the following columns in order: "Category | Description | Mention Count | Direct Quote/Evidence from Notes". Place Try below the table as a numbered list, writing each item in the format: "What to change | Starting when | Who decides/owns this".
Replace any personal names with functional job titles or roles. Do not speculate on causes not explicitly stated in the notes. For emotional expressions like "it was exhausting" or "disappointing", extract and retain only the factual events described. Do not bundle multiple distinct issues into a single Problem row.
Retrospective reflection memo: """ {{retrospective reflection memo}} """
- Role Who answers ×1
- Material What the AI needs to know ×2
- Work What to do, and how ×1
- Output What comes back, in what shape ×2
When asking AI to summarize a retrospective without strict guidelines, you usually get generic apologies: "Communication was lacking," or "There were issues with schedule management." These platitudes leave no actionable changes for the next sprint. This prompt enforces filtering for factual statements and categorizing them strictly into three actionable sections.
Read the full explanation · 3 paragraphs
Requiring mention counts in the Task paragraph is the primary mechanism. Raw retro notes often mix one vocal person's complaint with an obstacle experienced by five team members equally. Adding counts eliminates debate over which items to prioritize during review meetings.
In the Format paragraph, Keep and Problem are structured in a table while Try is formatted as a concrete list. The Try format ("What to change | Starting when | Who decides") prevents vague resolutions like "Let's communicate better" and forces actionable operational commitments. The "Direct Quote/Evidence" column ensures transparency so anyone can verify whether a summary item was exaggerated.
Finally, the Constraints paragraph anonymizes names into functional roles and strips emotional venting down to factual statements. If retrospectives read like performance appraisals, team members will stop being honest in future sessions. Wrapping the raw notes in """ ensures that meta-comments within the notes (e.g., "please exclude this") are processed as raw data rather than prompt instructions.
Unfamiliar terms? See Aha AI: prompt-injection, output-format
Compared with a bad example
Summarize this project retrospective.
(paste raw retro notes)
A prompt like this produces a smoothed-out paragraph of text. Successes and failures get blended together, and a one-off grievance carries the same apparent weight as a critical blocker reported by five people. The AI often hallucinates plausible-sounding root causes not present in the notes. Without clear action items, the document gets archived and forgotten.
Variations
Pre-meeting retro agenda generator
Retro meetings often devolve into venting sessions when held without a structured agenda. Extracting the top three common problems in advance cuts meeting time in half.
Show prompt
Below are the retro notes for {{official project name}}. Please generate a concise draft agenda to share with the team before our retrospective meeting.
Identify up to 3 common problems mentioned by multiple people, and draft a single-sentence "Decision needed in meeting" for each. Group issues raised by only one person under a separate "Items needing verification" section. Do not speculate on root causes.
Retrospective reflection memo: """ {{retrospective reflection memo}} """
Solo work post-mortem
Solo retrospectives easily slide into self-criticism. Separating what is within your control from external factors naturally narrows down viable Try action items.
Show prompt
Below are my personal notes after wrapping up {{official project name}}. Please organize them into Keep, Problem, and Try sections.
Under Problem, split the items into "Within my direct control" and "Outside my direct influence". For Try, list exactly 3 concrete actions I can execute alone within the next month. Do not evaluate my personality or work attitude.
Retrospective reflection memo: """ {{retrospective reflection memo}} """
Model notes
If real names are included in the raw notes, they may occasionally slip into the final output. For strict confidentiality, replace personal names with job titles before pasting the memo into the prompt.
Last updated 2026-09-02 · Found a mistake? Let us know