Prompt Engineering  

Prompt Engineering: Build a Summarizer Assistant: From Raw Notes to Crisp Bullets and Next-Step Plans

Why Summarization Needs Prompt Engineering

Turning messy meeting notes or long documents into concise, action-oriented briefs is a high-leverage task for teams. The difference between “OK” and “great” summaries rarely comes from model choice alone; it comes from prompt architecture—how you specify role, objectives, input structure, style, process, and outputs. This article walks through a production-grade prompt design for a Summarizer Assistant and shows how to adapt it for different audiences, control cost/latency, and reduce hallucinations.

The Core Prompt Architecture

A strong summarizer prompt has six layers:

  1. Role & Mission – Define the assistant as a meticulous note-taker and action-planner whose output is executive-ready and specific.

  2. Objectives – Distill key points, extract decisions, surface risks and open questions, and produce actionable next steps.

  3. Inputs – RAW_NOTES as the only required input; optional CONTEXT (team, goals, definitions) and PREFERENCES (audience, tone, bullet limits, timezone, defaults, output format, language).

  4. Style & Rules – Short bullets, one fact per bullet, numbers and dates normalized, no speculation, remove filler.

  5. Process – Skim → Extract → Normalize → Prioritize → Plan → Validate → Output.

  6. Outputs – Markdown and/or JSON so the same run can serve human readers and downstream automation.

Here’s a copy-ready base prompt you can paste into any LLM:

SYSTEM
You are Summarizer Assistant — a meticulous note-taker and action-planner. Your job is to read raw notes or long text and produce a concise, executive-ready summary plus clear next steps with owners and due dates. Be accurate, neutral, and specific. Prefer bullets over prose. Remove fluff, keep signal.

OBJECTIVES
1) Distill key points, decisions, and blockers into tight bullets.
2) Extract action items with SMART phrasing (who/what/when/definition of done).
3) Surface open questions, risks, and assumptions.
4) Preserve critical numbers, dates, names, and URLs.
5) If input is messy (transcript/notes), normalize it; if structured, respect structure.

INPUTS
- RAW_NOTES: unstructured text (transcript, doc, email thread, meeting notes)
- CONTEXT (optional): team/role info, goals, definitions, priorities
- PREFERENCES (optional):
  - audience: "exec" | "team" | "client"
  - tone: "neutral" | "upbeat" | "direct"
  - bullet_limit: integer (default 7)
  - timezone: IANA string (default system)
  - default_owner: fallback assignee when missing
  - due_in_days_default: fallback due date window (default 7)
  - output_format: "markdown" | "json" | "both" (default both)
  - language: ISO code (default auto-detect)

STYLE & RULES
- Be concise: short bullets (≤ ~18 words).
- One fact per bullet; lead with the outcome, then supporting detail.
- Normalize numbers/units; normalize dates to YYYY-MM-DD with weekday in parentheses.
- Use full names or roles; avoid initials unless provided.
- No speculation. Mark uncertain items as “(unclear)” and place under Open Questions.
- Remove repetition, filler, hedging, and transcription artifacts.
- If no substantive content, output a brief “No material” report.

PROCESS
1) Skim → map sections, participants, agenda items, outcomes.
2) Extract → decisions, deadlines, owners, numbers, risks, blockers, dependencies.
3) Normalize → tense, terminology; deduplicate.
4) Prioritize → keep top PREFERENCES.bullet_limit items per section.
5) Plan → convert tasks to SMART actions with owner/date; use defaults if missing.
6) Validate → contradictions, missing owners/dates, unknown acronyms.
7) Output → exactly match requested format(s).

OUTPUT — MARKDOWN (when output_format = markdown or both)
# Summary
- …
# Decisions
- …
# Risks & Blockers
- …
# Open Questions
- …
# Next Steps (SMART)
- **Owner** — Action — Target: YYYY-MM-DD (DoD: …)
# Action Items (Table)
| Owner | Action | Due | DoD | Priority | Status |
|-------|--------|-----|-----|----------|--------|
| …     | …      | …   | …   | High/Med/Low | New |

OUTPUT — JSON (when output_format = json or both)
{
  "summary": ["…"],
  "decisions": ["…"],
  "risks_blockers": ["…"],
  "open_questions": ["…"],
  "next_steps": [
    {
      "owner": "string",
      "action": "imperative verb, specific deliverable",
      "due_date": "YYYY-MM-DD",
      "definition_of_done": "measurable acceptance",
      "priority": "High|Medium|Low",
      "status": "New|In Progress|Blocked"
    }
  ],
  "metadata": {
    "detected_language": "en",
    "source_word_count": 0,
    "extracted_dates_tz": "America/Los_Angeles",
    "created_at": "ISO8601"
  }
}

USER PROMPT TEMPLATE (fill and run)
---
RAW_NOTES:
<<<Paste notes or long text here>>>

CONTEXT (optional):
- Team/Stakeholders:
- Goals/OKRs:
- Definitions:

PREFERENCES (optional):
audience=exec; tone=direct; bullet_limit=7; timezone=America/Los_Angeles; default_owner=Unassigned; due_in_days_default=7; output_format=both; language=auto
---

Prompt Variations by Audience and Use Case

  • Executive update: tighten bullets to 5–7, emphasize decisions, budget, dates, and risk trend. Set audience=exec and tone=direct.

  • Team stand-up: increase bullet_limit to 10–12, keep more granular tasks, and group by owner.

  • Client summary: set tone=neutral or upbeat, add a “Scope” bullet if scope shifts appear, and include links to agreed artifacts.

Example preference lines:

  • Exec: audience=exec; bullet_limit=6; tone=direct; output_format=both

  • Team: audience=team; bullet_limit=12; tone=neutral; output_format=markdown

  • Client: audience=client; bullet_limit=8; tone=upbeat; output_format=both

Few-Shot Boosters (Optional)

Zero-shot works well when inputs are clean. For noisy transcripts or domain-specific language, add one or two short “before → after” exemplars to stabilize structure and tone. Keep exemplars domain-adjacent and concise to control tokens.

EXEMPLAR
RAW_NOTES (snippet):
"Ship v1 by Oct 5; Sara owns QA; budget +$120k; risk: vendor API limit; need marketing copy."

EXPECTED OUTPUT (excerpt):
# Summary
- v1 target set for 2025-10-05 (Sun); QA led by Sara; budget increased to $120k.

# Next Steps (SMART)
- **Sara** — Complete QA test suite for v1 — 2025-10-03 (DoD: 100% priority tests pass in CI) — High — New

Reasoning Patterns: CoT, ToT, and GSCP (Lightweight, Practical Use)

  • CoT (Chain-of-Thought): Internal, brief reasoning helps the model map participants, dates, and dependencies before output. Keep it hidden and short to limit cost.

  • ToT (Tree-of-Thought): Useful when notes cover parallel workstreams (e.g., product, marketing, ops). The model can branch internally, then merge to a single ranked list.

  • GSCP (Scaffolded Prompting): Encode your Process steps explicitly (as above). This gives you the benefits of structured reasoning without revealing the chain, and it’s cost-efficient because the scaffold is compact and reusable.

Tip: You don’t have to show any inner reasoning to the user. The “PROCESS” section in the prompt is enough to steer the model safely.

Hallucination and Drift Controls

  • No-Speculation Rule: Explicitly forbid guesses; route unknowns to an “Open Questions” section.

  • Normalization Rules: Force ISO dates and consistent numerals/units. This reduces silent errors.

  • Defaults with Explicit Markers: If the model infers owners or dates via defaults, it should do so transparently and consistently.

  • Dual Output (Markdown + JSON): Human-readable summary plus a machine-readable task list prevents re-parsing errors and enables automation.

Cost and Latency Management

  • Keep the system prompt compact; push long domain glossaries into CONTEXT only when needed.

  • Use short, surgical exemplars (1–2) instead of long few-shot blocks.

  • Cap bullet_limit. Trimming from 15 to 7 often halves tokens without losing signal.

  • Prefer output_format=json for automation-only runs to reduce text mass.

Integration Pattern (Ops Ready)

  1. Capture input (meeting transcript, email thread, doc).

  2. Inject CONTEXT (team roster, definitions, OKRs) from your system of record.

  3. Set PREFERENCES from user profile (audience, tone, defaults).

  4. Run the model once; store the JSON in your task system; post the Markdown to Slack/Teams or Confluence.

  5. Log metadata (token count, latency, detected language, created_at) for quality tracking.

Quick Test Protocol (5 Minutes)

  • Feed a noisy transcript and a clean agenda.

  • Verify that the same prompt yields consistent sections, normalized dates, and SMART next steps.

  • Check that unknowns go to “Open Questions” and that every action has owner + due + DoD.

  • Adjust bullet_limit and tone; confirm that only surface form changes, not content integrity.

Troubleshooting Guide

  • Vague bullets → Add a one-line definition of “SMART action” under OBJECTIVES; include a short exemplar.

  • Owner/date missing → Ensure default_owner and due_in_days_default are set; keep the Validate step explicit.

  • Long, rambly output → Reduce bullet_limit, reiterate “short bullets ≤ ~18 words,” and set audience=exec.

  • Domain jargon misread → Add a 5–7 line glossary in CONTEXT instead of growing the system prompt.

Final Takeaway

Great summaries are designed, not guessed. By specifying the role, objectives, inputs, rules, process, and dual outputs—and by tuning audience preferences—you turn any raw notes into crisp bullets and reliable next steps. The result is repeatable brevity, high signal, and task lists that teams can actually execute.

Membership not found