Summarise a document without distorting it
A summary that separates what the source says from what it implies. Written for Claude, free to copy, with every placeholder explained below.
The prompt
<role>
You are a careful summariser who does not smooth over disagreement.
</role>
<document>
{{document}}
</document>
<task>
Summarise the document above for {{audience}}.
</task>
<constraints>
- Every claim in the summary must be present in the document. Add nothing.
- Where the document is uncertain or hedged, the summary must stay uncertain.
- Where the document contradicts itself, say so rather than picking one side.
- Preserve numbers exactly as written, including their units and any stated ranges.
- {{length}}.
</constraints>
<output_format>
1. A one-paragraph summary a reader could quote.
2. The three most important specifics, as bullets.
3. "Not addressed": anything a reader would expect this document to cover and it does not.
</output_format>
Now summarise the document above.Open this in the prompt builder to adapt it, score it, and re-render it for a different model.
What to replace
| Placeholder | What to put there |
|---|---|
| {{document}} | The source text. |
| {{audience}} | Who the summary is for — changes what counts as important. |
| {{length}} | e.g. "Under 200 words total". |
Why this prompt works
- Hedging must survive
- Summarisation reliably strips uncertainty, turning "may be linked to" into "is linked to". Requiring hedges to survive is the fix.
- Contradictions reported, not resolved
- A summary that silently picks a side is more misleading than one that flags the conflict.
- "Not addressed" section
- Absence is invisible in a summary. Naming what is missing prevents the reader assuming it was covered.
More prompts
- Blog post from an outline — Turn a rough outline into a full draft that keeps your structure and does not pad.
- Rewrite for clarity without changing meaning — Tighten prose while keeping the author's voice and every factual claim intact.
- Code review for correctness only — Findings with a triggering input, ranked by severity — and permission to find nothing.
- Debug from an error and stack trace — Ranked hypotheses with a test for each, instead of one confident guess.
- Unit tests written from the spec — Tests derived from requirements rather than from the implementation, so they can fail.
- Explain unfamiliar code — A walkthrough pitched at your actual level, with the non-obvious decisions called out.
Browse the full prompt library, all writing & content prompts, or read the guides.