Summary / Recap
Purpose
Produce a concise, well-structured summary of a document, conversation, work session, or any body of content. Capture what matters without burying the reader in details.
When to Use
- Summarizing a long document or thread for stakeholders
- Recapping a work session or sprint
- Creating an executive summary from detailed material
- Distilling a conversation into its essential outcomes
Inputs
- Source material: The document, transcript, conversation, or notes to summarize
- Audience: Who will read this summary (e.g., executives, engineers, full team) (optional)
- Focus area: Any specific aspect to emphasize (optional)
- Length preference: Brief (1 paragraph), standard (half page), or detailed (full page) (optional, defaults to standard)
Output Format
Produce a markdown document with the following sections:
1. TL;DR
2-3 sentences capturing the absolute essence. A reader who only reads this should understand the core message.
2. Key Points
Bulleted list of the 3-7 most important facts, findings, or themes. Each point should be one concise sentence. Order by importance, not chronology.
3. Decisions Made
List any decisions that were reached, along with brief rationale. If no decisions were made, note that explicitly. Format:
- Decision: What was decided
- Rationale: Why (one sentence)
4. Action Items
List concrete next steps with owners (if known) and deadlines (if stated):
If no action items exist, state "No action items identified."
5. Open Questions
List unresolved questions or topics that need further discussion. These are loose threads the reader should be aware of.
6. Context and Detail
Optional section for readers who want more depth. Include relevant background, nuances, or supporting details that did not fit in the sections above. Keep this section to 1-3 short paragraphs.
Example
Input: A 45-minute product team meeting transcript discussing the Q2 roadmap.
Output:
- TL;DR: The team aligned on three Q2 priorities (search improvements, onboarding redesign, API v2) and deferred the mobile app to Q3 due to resource constraints.
- Key Points: search is the top revenue driver, onboarding drop-off is at 40%, API v2 has two enterprise customers waiting, mobile deferred but design work can start
- Decisions: Committed to search as the #1 priority; chose incremental API migration over big-bang rewrite
- Action Items: PM to draft search PRD by Friday, engineering lead to scope API v2 migration, design to start mobile exploration
- Open Questions: Hiring timeline for the second frontend engineer, whether to build or buy the search indexing layer
Guidelines
- Lead with the most important information -- do not bury the headline
- Be faithful to the source material; do not add opinions or inferences
- Use the audience context to calibrate the level of technical detail
- Keep bullet points to one sentence each; elaborate only in the Context section
- If the source material is contradictory, note the contradiction rather than resolving it
- Attribute action items to specific people when that information is available
- Distinguish between decisions (settled) and open questions (unsettled)
1---2name: summary3description: Generate a summary or recap of content. Use when the user says /summary, asks to summarize a document, recap a session, create an executive summary, or distill information. Triggers: summary, recap, summarize, executive summary, tldr, distill, key takeaways.4---56# Summary / Recap78## Purpose910Produce a concise, well-structured summary of a document, conversation, work session, or any body of content. Capture what matters without burying the reader in details.1112## When to Use1314- Summarizing a long document or thread for stakeholders15- Recapping a work session or sprint16- Creating an executive summary from detailed material17- Distilling a conversation into its essential outcomes1819## Inputs2021- **Source material**: The document, transcript, conversation, or notes to summarize22- **Audience**: Who will read this summary (e.g., executives, engineers, full team) (optional)23- **Focus area**: Any specific aspect to emphasize (optional)24- **Length preference**: Brief (1 paragraph), standard (half page), or detailed (full page) (optional, defaults to standard)2526## Output Format2728Produce a markdown document with the following sections:2930### 1. TL;DR312-3 sentences capturing the absolute essence. A reader who only reads this should understand the core message.3233### 2. Key Points34Bulleted list of the 3-7 most important facts, findings, or themes. Each point should be one concise sentence. Order by importance, not chronology.3536### 3. Decisions Made37List any decisions that were reached, along with brief rationale. If no decisions were made, note that explicitly. Format:38- **Decision**: What was decided39- **Rationale**: Why (one sentence)4041### 4. Action Items42List concrete next steps with owners (if known) and deadlines (if stated):43- [ ] Action item description -- **Owner** (by Date)4445If no action items exist, state "No action items identified."4647### 5. Open Questions48List unresolved questions or topics that need further discussion. These are loose threads the reader should be aware of.4950### 6. Context and Detail51Optional section for readers who want more depth. Include relevant background, nuances, or supporting details that did not fit in the sections above. Keep this section to 1-3 short paragraphs.5253## Example5455**Input**: A 45-minute product team meeting transcript discussing the Q2 roadmap.5657**Output**:58- TL;DR: The team aligned on three Q2 priorities (search improvements, onboarding redesign, API v2) and deferred the mobile app to Q3 due to resource constraints.59- Key Points: search is the top revenue driver, onboarding drop-off is at 40%, API v2 has two enterprise customers waiting, mobile deferred but design work can start60- Decisions: Committed to search as the #1 priority; chose incremental API migration over big-bang rewrite61- Action Items: PM to draft search PRD by Friday, engineering lead to scope API v2 migration, design to start mobile exploration62- Open Questions: Hiring timeline for the second frontend engineer, whether to build or buy the search indexing layer6364## Guidelines6566- Lead with the most important information -- do not bury the headline67- Be faithful to the source material; do not add opinions or inferences68- Use the audience context to calibrate the level of technical detail69- Keep bullet points to one sentence each; elaborate only in the Context section70- If the source material is contradictory, note the contradiction rather than resolving it71- Attribute action items to specific people when that information is available72- Distinguish between decisions (settled) and open questions (unsettled)
maggit