Summarization

Usage

Provide the agent with the text to summarize and optionally specify: the desired length (one-sentence, short, medium, detailed), the strategy (extractive, abstractive, hierarchical), or a specific focus area.

Summarize the following technical RFC into a short paragraph and a detailed
section-by-section breakdown. Focus on the proposed changes and their
backward-compatibility impact.

[paste RFC text here]

Examples

Example 1: Hierarchical Summary of a Technical Document

User Request:

Summarize this document at three levels of detail.

Source Document (excerpt):

The Kubernetes Gateway API is a collection of resources that model service networking in Kubernetes. It is the successor to the Ingress API and provides more expressive, extensible, and role-oriented interfaces. The API introduces three primary resource types: GatewayClass (defines a set of Gateways with common configuration), Gateway (requests a point where traffic can be translated to Services within the cluster), and HTTPRoute (defines HTTP-specific routing rules). Unlike Ingress, the Gateway API supports traffic splitting, header modification, and cross-namespace routing natively. The API reached GA status in v1.0.0, released in October 2023, with implementations available from Istio, Envoy Gateway, Cilium, and Traefik. Migration from Ingress is supported through the ingress2gateway tool, though manual review is recommended for complex configurations. Key limitations include the lack of TCP/UDP routing in the core spec (addressed by TCPRoute and UDPRoute in the experimental channel) and the varying maturity of different implementations.

Output:

TLDR (1 sentence): The Kubernetes Gateway API is the GA successor to Ingress, introducing GatewayClass, Gateway, and HTTPRoute resources for more expressive service networking with native traffic splitting and cross-namespace routing.

Short Summary (1 paragraph): The Kubernetes Gateway API, which reached GA in October 2023, replaces the Ingress API with a more expressive and extensible approach to service networking. It introduces three core resources — GatewayClass, Gateway, and HTTPRoute — that separate concerns by role (infrastructure provider, cluster operator, application developer). The API natively supports traffic splitting, header modification, and cross-namespace routing, features that required annotations or custom resources under Ingress. Implementations are available from Istio, Envoy Gateway, Cilium, and Traefik. Migration from Ingress is possible via the ingress2gateway tool, though TCP/UDP routing remains experimental and implementation maturity varies.

Detailed Breakdown:

• What it is: A collection of Kubernetes-native resources for modeling service networking, designed as the successor to the Ingress API.
• Core resources: GatewayClass (shared gateway configuration), Gateway (traffic entry point), HTTPRoute (HTTP routing rules).
• Key improvements over Ingress: Native traffic splitting, header modification, cross-namespace routing, and role-oriented resource separation — no more vendor-specific annotations.
• Current status: GA since v1.0.0 (October 2023). Supported by Istio, Envoy Gateway, Cilium, and Traefik.
• Migration path: The ingress2gateway tool automates conversion, but complex configurations require manual review.
• Limitations: TCP/UDP routing is still experimental. Implementation maturity varies across providers.

Example 2: Multi-Document Summary of Meeting Notes

User Request:

Synthesize these three meeting note documents into a single weekly digest.

Source Documents:

Monday Standup (Team Alpha):

Discussed the v2.1 release blocker — the payment processing timeout issue. Sarah is investigating the root cause in the Stripe webhook handler. ETA for fix: Wednesday. Jake finished the new onboarding flow UI and it's in code review. Maria flagged that the staging environment SSL cert expires Friday.

Wednesday Sprint Review:

Sarah resolved the payment timeout — root cause was a missing retry configuration in the webhook handler. Fix deployed to staging. QA verified it passes. Jake's onboarding flow PR received feedback on accessibility; he's addressing it. New item: product wants to add a dark mode toggle by v2.2. Estimated at 3 story points.

Friday Retrospective:

Team agreed the week was productive. Payment fix shipped on time. Onboarding flow merged after accessibility fixes. SSL cert renewed by Maria on Thursday. Retro feedback: need better alerting for cert expirations. Action item: Maria to set up automated cert renewal monitoring. Looking ahead: dark mode toggle design starts Monday.

Synthesized Weekly Digest:

Week of Feb 10-14 — Team Alpha Digest

Shipped:

• Payment processing timeout fix — root cause was missing retry config in Stripe webhook handler (Sarah). Deployed to staging Wednesday, QA-verified.
• New onboarding flow UI — completed by Jake, updated after accessibility feedback, merged Friday.
• SSL certificate renewed for staging environment (Maria, Thursday).

In Progress:

• Dark mode toggle added to v2.2 roadmap (3 story points). Design starts next Monday.

Action Items:

• Maria: Set up automated certificate renewal monitoring to prevent future near-misses.

Retro Takeaway: The team identified cert expiration alerting as a process gap and is addressing it proactively.

Best Practices

• Never add information not in the source. Summaries must be faithful to the original. If you are uncertain about a detail, omit it rather than guess.
• Preserve numerical precision. If the source says "37.5% increase," the summary should say "37.5% increase," not "nearly 40% increase."
• Adjust tone to match the source. A summary of a legal contract should be precise and formal. A summary of team chat messages can be concise and informal.
• Front-load the most important information. Readers of summaries often skim. Put the key takeaway in the first sentence, then add supporting detail.
• Use the hierarchical approach for ambiguous length requests. When the user does not specify length, provide a TLDR plus a paragraph-length summary so they can choose their preferred level.
• Handle multi-document synthesis thematically. Don't summarize each document separately and concatenate. Instead, identify themes that cut across documents and organize the synthesis around those themes.

Edge Cases

• Very short source text: If the input is already concise (under 100 words), inform the user that further summarization may lose essential nuance, and offer to highlight the key sentence instead.
• Source text with contradictions: If the document contains internally contradictory statements, flag the contradiction in the summary rather than silently choosing one version.
• Highly technical or jargon-heavy text: If summarizing for a non-specialist audience, define key terms on first use. If summarizing for experts, preserve the technical vocabulary without over-simplifying.
• Incomplete or cut-off documents: If the source text appears truncated (ends mid-sentence, references sections not provided), note this and summarize only the available content, flagging that the summary may be incomplete.
• Multiple documents with overlapping content: In multi-document summarization, deduplicate overlapping information rather than repeating it. Note where sources agree and where they diverge.