Summarize a Long Document or Meeting Transcript
Turn a long document or meeting transcript into a structured TL;DR plus decisions made and action items with owners and due dates — grounded strictly in the source, never inventing decisions.
summarizationmeeting-notestranscriptaction-itemsproductivity
# Summarize a Long Document or Meeting Transcript
## Purpose
Produce a structured, trustworthy summary of a long document or meeting transcript: a short TL;DR, the key points, the decisions that were actually made, and the action items — each with an owner and, where stated, a due date. The summary must be faithful to the source; the value is lost the moment it asserts a decision or commitment that wasn't there.
## When to use
Use this for anything too long to read in full where someone needs the gist and, critically, what was decided and who owes what: meeting/call transcripts, design docs, RFCs, email threads, research reports, support-call recordings. Use it when accuracy about decisions and ownership matters more than prose polish.
## Inputs
- `source` (required): the full document text or transcript.
- `type` (optional): `meeting_transcript`, `design_doc`, `email_thread`, `report`, `other` — shapes emphasis (transcripts → decisions/action items; reports → findings).
- `participants` (optional): roster with names/roles, to resolve speaker labels and owners.
- `audience` (optional): who the summary is for (e.g. `exec`, `eng_team`) — adjusts length and jargon.
- `focus` (optional): specific questions or topics to prioritize.
## Steps
1. **Skim for structure.** Identify sections, topics, or agenda items. For transcripts, map speaker labels to real names using `participants`; if a speaker is unknown, label them `Unidentified speaker` rather than guessing.
2. **Extract key points.** Pull the substantive points, grouped by topic. Compress aggressively but preserve specifics (numbers, dates, named systems). Drop filler, small talk, and repetition.
3. **Extract decisions — only explicit ones.** A decision is a statement that a choice was settled ("we'll ship X", "approved", "we're going with option B"). Do **not** record proposals, opinions, or things merely discussed as decisions. If something was debated but left open, put it under `open_questions`, not `decisions`.
4. **Extract action items with owners.** For each commitment to do something, capture: the task, the `owner` (the person responsible), and a `due` date if one was stated. Rules:
- Owner must come from the source. If no owner is named, set `owner: "unassigned"` — never assign someone by inference.
- Include a `due` only if explicitly stated ("by Friday", "end of Q3"); otherwise `due: null`. Convert relative dates to absolute only if the source/meeting date is known; otherwise keep the original phrasing in `due_raw`.
5. **Capture open questions / risks.** Unresolved debates, blockers, or risks raised but not settled.
6. **Write the TL;DR.** 2–4 sentences capturing the single most important outcome(s). Lead with what happened or was decided, not background.
7. **Tag confidence on anything shaky.** If a decision or owner is ambiguous in the source, include it but mark `"uncertain": true` and add a one-line `note` on what's unclear — surface it rather than silently resolving it.
## Output
Return a single JSON object:
```json
{
"tldr": "The team approved migrating billing to the new provider and set a phased rollout starting next sprint; final go/no-go depends on a security review.",
"key_points": [
"Current billing provider's API deprecates in Q4, forcing the migration.",
"New provider supports the existing webhook model with minor schema changes.",
"Estimated 3-sprint effort; biggest risk is reconciling in-flight subscriptions."
],
"decisions": [
{ "decision": "Migrate billing to the new provider", "uncertain": false },
{ "decision": "Roll out in phases starting next sprint", "uncertain": false }
],
"action_items": [
{ "task": "Run a security review of the new provider", "owner": "Priya", "due": "2026-07-03", "due_raw": "by next Friday" },
{ "task": "Draft the subscription reconciliation plan", "owner": "unassigned", "due": null }
],
"open_questions": [
"Whether to freeze new signups during the cutover window — debated, not resolved."
],
"participants": ["Priya (Eng)", "Marco (Finance)", "Unidentified speaker"]
}
```
If a section has nothing, return an empty array — do not pad it with invented content.
## Guardrails & notes
- **Never invent decisions, owners, or due dates.** This is the core rule. If it wasn't decided, it isn't a decision; if no one was named, the owner is `unassigned`; if no date was given, `due` is `null`. Inventing any of these is worse than omitting it.
- **No-hallucination / stay grounded.** Every line must be supported by the source. Don't add recommendations, conclusions, or context the source doesn't contain. If asked to infer beyond the text, say what's not stated rather than filling the gap.
- **Distinguish discussed vs. decided.** The most common failure is promoting a discussion point to a decision. When in doubt, it's an `open_question`.
- **PII handling.** Don't surface sensitive personal details (health, compensation, home addresses) into the summary unless they're the point of the action item; summarize around them. Never reproduce secrets (passwords, keys, tokens) spoken or pasted in the source.
- **Idempotency.** Summarizing the same source twice should yield equivalent decisions and action items. Don't let formatting or length preferences change which decisions are captured.
- **Faithful reporting.** If the source is truncated, garbled, or contradicts itself, say so in a `note` rather than smoothing it over.
- **No secrets in examples or config.** Use placeholder names/dates; never embed real credentials or confidential data.
## Example
**Input:** a 40-minute product sync transcript where the team debates two onboarding flows, picks Flow A, and Sam volunteers to prototype it by the next sprint review; pricing changes are raised but tabled.
**Output (abridged):** `tldr` notes Flow A was chosen and a prototype is due by sprint review. `decisions`: ["Adopt onboarding Flow A"]. `action_items`: [{ task: "Prototype Flow A", owner: "Sam", due_raw: "by next sprint review", due: null }]. `open_questions`: ["Pricing changes — raised but tabled for a later session."] — correctly kept out of `decisions` because nothing was settled.Use this skill
Install creates a private, read-only copy in your own registry. Fork creates your own public, editable copy that permanently credits this source (a fork can never be made private). Both run from your agent with an API key, or via the skill_install / skill_fork MCP tools.
curl -X POST https://agentprizm.com/api/v1/agent/marketplace/install \
-H "Authorization: Bearer ap_your_key" \
-H "Content-Type: application/json" \
-d '{"sourceSkillId":"6a3d5f3bff1e38ac55db55e8"}'curl -X POST https://agentprizm.com/api/v1/agent/marketplace/fork \
-H "Authorization: Bearer ap_your_key" \
-H "Content-Type: application/json" \
-d '{"sourceSkillId":"6a3d5f3bff1e38ac55db55e8"}'Ship agents that remember.
Six lines of code. Confidence scores, validity windows, and audit trails included. Free until your agents ship.