Document Summarizer

When to use this skill

Use this skill when you need to:

• Condense lengthy documents while maintaining critical details (dates, numbers, names, decisions)
• Extract key concepts from technical specs, PRDs, reports, research papers
• Create executive summaries of emails, meeting notes, or project documentation
• Prepare briefings that highlight what matters most
• Generate structured overviews for quick understanding and reference

The summarizer works with ANY text type: Product Requirements, Technical Specifications, Articles, Reports, Meeting Notes, Research Papers, Emails, Code Documentation, etc.

How the summarizer works

The summarizer uses a hybrid approach:

1. Identify the document type and intent — What kind of document is this? (PRD, technical spec, article, etc.)
2. Extract critical information — Pull essential facts: dates, decisions, key entities, metrics, specific requirements
3. Distill to key themes — What are the 3-5 essential concepts or sections?
4. Rewrite for clarity — Combine extracts with natural language, keeping it concise and coherent
5. Structure as sections — Organize into logical sections with bullet points for scannability

Output format

ALWAYS use this exact structure for your summary:

# Summary: [Document Title or Topic]

## Overview
[1-2 sentence executive summary capturing the core purpose/essence]

## Key Sections

### [Section Name]
- **Point 1**: High-level extracted insight
- **Point 2**: Essential detail or decision
- **Point 3**: Another critical fact

### [Section Name]
- [bullet points]

## Critical Information
- **Dates/Deadlines**: [if relevant]
- **Key Metrics**: [if relevant]
- **Decision/Outcome**: [core decision or result]
- **Next Steps/Recommendations**: [if applicable]

## Notes
[Any important caveats, assumptions, or context that shouldn't be missed]

Guidelines for sections and bullets

• Section names should reflect the document's natural structure (use its headings if present, invent logical ones if implicit)
• Bullets should be scannable — aim for 3-7 bullets per section, not more
• Preserve specificity — Keep exact names, numbers, dates, quotes where critical
• Combine quotes with paraphrase — Mix direct quotes ("verbatim") with plain English for readability
• Critical Information section is mandatory — Always highlight dates, decisions, and key metrics here if they exist

Compression strategy

The amount of condensing depends on source length and density:

• Short documents (< 500 words): Reduce to 40-50% of original (light summary)
• Medium documents (500–3000 words): Reduce to 20-35% (moderate summary)
• Long documents (> 3000 words): Reduce to 10-25% (aggressive summary)

Exception: If a section is ambiguous or dense, keep slightly MORE detail to preserve clarity.

What NOT to lose

ALWAYS preserve:

• Decisions and conclusions — Never omit what was decided or concluded
• Specific numbers, dates, names — These are anchors for understanding
• Constraints and blockers — If something says "can't do X because of Y", keep it
• Dependencies — Relationships between concepts or tasks
• Assumptions — If there's an explicit "we assume...", include it

What's safe to condense or drop:

• Lengthy explanations or justifications (replace with concise paraphrase)
• Repeated statements (consolidate into one mention)
• Style/formatting commentary (only preserve content)
• Filler or wordy transitions

Examples

Example 1: Technical PRD

Input: 2500-word Product Requirements Document describing a new authentication system with 8 sections

Output:

# Summary: Multi-Factor Authentication System

## Overview
Build a flexible MFA system supporting SMS, TOTP, and hardware keys, launching in Q3 2026 with phased rollout to enterprises first.

## Requirements
- Support SMS (primary), TOTP (Google Authenticator, Authy), hardware keys (FIDO2)
- Integrate with existing IdP (Okta, Entra) via OIDC
- **Backward compatible** — existing users fall back to email verification if needed

## Architecture
- New `/auth/mfa` endpoint for MFA flow
- Redis cache for OTP validation (TTL: 5 mins)
- Audit logging to CloudWatch for compliance (HIPAA, SOC2)

## Rollout
- **Phase 1** (Week 1–4): Enterprise beta, SMS + TOTP
- **Phase 2** (Week 5–8): Hardware key support
- **Phase 3** (Week 9–12): Public GA

## Critical Information
- **Deadline**: Q3 2026 (June 30)
- **Team**: 4 engineers, 1 security reviewer
- **Blockers**: Okta API limits (need escalation)
- **Success metric**: 85% enterprise adoption by end of Phase 2

Example 2: Email thread

Input: 15-message email chain about a product pivot

Output:

# Summary: Product Strategy Pivot Discussion

## Overview
Marketing recommends deprioritizing Feature X in favor of Feature Y based on customer feedback and competitive analysis. Decision pending exec sign-off.

## Why the Pivot
- Customer surveys show 70% prefer Feature Y over Feature X
- Competitor Z just launched similar Feature X; ours no longer differentiated
- Feature Y aligns with Q2 GTM strategy (cost optimization narrative)

## Proposal
- **Delay Feature X** to Q4 2026
- **Accelerate Feature Y** to late Q2
- **Restaff**: 3 engineers from X team → Y team

## Open Questions
- Existing commitments to enterprises expecting Feature X?
- Y's technical feasibility in compressed timeline?

## Decision
Awaiting CTO + CEO sign-off (likely by Friday).

Tips for better summaries

1. Read the whole document first — Scan for structure BEFORE starting the summary. Identify natural sections.
2. Ask yourself: Why would someone need this summary? — That shapes what's critical.
3. Keep signal-to-noise high — Remove nice-to-knows unless they're surprising or urgent.
4. Use section names from the source when possible — This keeps context anchored.
5. If something seems critical but unclear, mention it in Notes — Don't suppress important ambiguity.

---

Common usage patterns

"Summarize this PRD for a quick read" → Follow the output format exactly, aim for 20-30% of original

"Extract just the key decisions from this" → Focus the Critical Information section; minimize everything else

"I'm new to this project, give me a briefing" → Emphasize Overview and Critical Information; make it introduction-friendly

"Condition this for exec presentation" → Lead with a wow statement in Overview; emphasize metrics and decisions