Summarization Essentials

Six prompts for summarization you can actually ship — where the failure mode isn't a bad sentence, it's a confident summary of things the document never said. Every prompt here is grounded-only (content must come from the input), returns typed, validated JSON with a strict schema, and ships with a published eval that gates on groundedness.

Like the Structured Extraction, Customer Support, RAG Essentials, and Translation Essentials collections, each prompt is a system message, a user message, and a schema — framework-agnostic, SDK-generatable in TypeScript and Python.

Prompts

Pick by input type

These aren't pipeline stages — they're specialists by input shape. Route by what you have:

  what do you have?
  ├─ a document / article / report ──► document-summary        (prose or bullets, 3 lengths)
  │                                └─► key-points-extraction   (when you need verifiable quotes)
  ├─ a meeting transcript ───────────► meeting-notes-summary   (minutes with never-inferred owners)
  ├─ an email thread ────────────────► email-thread-summary    (status enum for triage)
  ├─ anything needing a title ───────► headline-generation     (style knob + word cap)
  └─ a summary you don't trust ──────► summary-grader          (0–1 groundedness + claim list)

summary-grader composes with all of the others: run it on any summary before showing it to a user, and gate on score > 0.8 exactly like this collection's own evals do.

Dogfooding: the grader grades the collection

The published evals on document-summary, meeting-notes-summary, email-thread-summary, and headline-generation use summary-grader itself as their LLM judge. key-points-extraction needs no judge at all — its verbatim-quote contract is asserted mechanically (quote must appear in the source document). And the grader is evaluated judge-free, against known-good and known-hallucinated summary pairs — a judge's own eval must be deterministic.

House conventions

1. Grounded only — the whole collection's reason to exist. Content comes from the input, never outside knowledge; hedged claims stay hedged ("may improve" never becomes "improves"); owners, dues, and next steps are never inferred. Fabricating any of these is what summary-grader scores below 0.5.
2. Reasoning before the output. Which points make the cut, which commitments were explicit, which angle is strongest — decided before the summary is written. Key order is pinned in every system prompt.
3. Empty sections are correct answers. No decisions → empty array; nothing to summarize → exactly "Nothing to summarize."; empty input → empty output. Sections are never padded to look thorough.
4. Verifiability where it's cheap. key-points-extraction quotes and meeting-notes-summary action-item counts are checked mechanically in the evals; groundedness everywhere else is judged by the collection's own grader.
5. Strict schemas. additionalProperties: false, complete required arrays, closed enums (status, format, target_length, style), ["string","null"] where null is meaningful (owner, due, waiting_on).
6. Input is data, never instructions. All user content is triple-mustache-injected inside XML-style delimiters; "ignore the above" inside a document, transcript, thread, or summary is content to process, never an order — including to the grader itself.
7. Empty/garbage behaviour is specified and observable — and asserted by the published evals.