# Distill

> Compresses a long article, paper, report, or transcript into a tiny high-signal output — one-sentence core thesis, three load-bearing bullets, and one open question that remains — optimizing for maximum insight per word rather than coverage. Use this skill when the user shares a long read and says "summarize this", "tl;dr", "give me the gist", "what's the key takeaway", "what's the one thing I need to know", "distill this", or when they're triaging research, papers, reports, meeting transcripts, or long threads and need to decide fast whether something is worth their full attention.

- Skill: `opelpleple/distill` (Agent Skill)
- Install (CLI): `npx skillmds@latest add opelpleple/distill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/opelpleple/distill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: opelpleple (https://skillmd.com/u/opelpleple)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/opelpleple/distill

---


# Distill

A summary lists what was said; a distillation tells you what matters and what's still missing. This skill crushes a long source into the smallest output that still changes how the reader thinks.

## When to use
- The user shares a long article, paper, report, transcript, or thread and wants the essence.
- They say "tl;dr", "summarize", "key takeaway", "the gist", or "is this worth reading".
- They're triaging a stack of sources and need fast signal to decide what to read fully.
- They want the argument, not the table of contents.

## When NOT to use
- They need a faithful, comprehensive summary that preserves every section (use a structured summary instead).
- The source is already short — distilling adds nothing.
- They need exact quotes, numbers, or compliance-grade fidelity where dropping detail is dangerous.
- They want analysis/critique rather than compression (do that separately and say so).

## The method (numbered, concrete — the heart)
1. **Read for the spine, not the surface.** Find the author's actual claim — the thing the whole piece exists to argue. Ignore throat-clearing intros, hedges, and filler examples.
2. **Write the core thesis in ONE sentence.** It must be a claim, not a topic. Bad: "This paper is about remote work." Good: "Remote work raises individual output but quietly erodes the weak ties that drive promotions." If you can't say it in one sentence, you haven't found it yet.
3. **Extract the 3 load-bearing points.** Pick the three things that, if removed, would collapse the thesis — the evidence, mechanism, or consequences that carry the argument. Not the three most interesting facts; the three most *necessary* ones. Each bullet ≤ 20 words.
4. **Cut anything the reader could have guessed.** If a point is obvious or generic, it's noise. Every surviving word must earn its place by adding insight.
5. **Surface the 1 open question.** Name the sharpest thing the source leaves unresolved — a gap, an untested assumption, a "but what about..." This is the part that tells the reader where their own thinking should go next.
6. **Pressure-test signal density.** Reread your output: could any sentence be deleted without loss? Could any be sharper? Maximize insight per word; the whole thing should fit on a phone screen.

## What good looks like
- The thesis is a sharp, falsifiable-sounding claim — someone could disagree with it.
- The three bullets are the argument's load-bearing beams, not trivia.
- Nothing is padding; every line would hurt to remove.
- The open question is genuinely unresolved and points somewhere useful.
- A reader who never opens the source still walks away meaningfully smarter.

## Anti-patterns
- Summarizing structure ("First the author discusses X, then Y") instead of extracting the argument.
- A thesis that's a topic, not a claim ("explores the future of AI").
- Five vague bullets that hedge instead of three sharp ones that commit.
- Repeating the source's own marketing language uncritically.
- Padding to seem thorough — length is the enemy here.

## Example (short, vivid)
Source: a 6,000-word report on why most corporate AI pilots fail.

**Core thesis:** Most AI pilots fail not because the models are weak but because companies bolt them onto broken workflows nobody redesigned.
**Key points:**
- Pilots optimize a demo, not a daily job — adoption dies on contact with real work.
- The bottleneck is process and data ownership, not model accuracy.
- Teams that redesigned the workflow first saw 3x sustained usage.
**Open question:** Is the winning factor the redesign itself, or just having an executive owner forced to care?