distill
Skill14 starsChanged 5 months agoMITView on GitHub
Use when the user wants to extract a Zettelkasten-style atomic note from a source. Natural triggers: "/distill", "make this a Zettel", "pull the claim out of …", "what's the atomic note here?", "atomic-ize this", "extract a Zettel from this". Source can be: the current conversation, one or more files the user names explicitly, a pulled source, a transcription, or multiple drafts converging on a shared idea. Output: one or more draft Markdown files in `./notes/atomic/`, ready for the user to review and promote into their canonical notes.
75 other projects use a version of this.
Adopted by
Most recently taken up by
- venhdev/skillstheir own version, first seen Nov 8, 2026
- kylehughes/distillation-for-agentstheir own version, first seen Nov 8, 2026
- komluk/scaffoldingtheir own version, first seen Nov 7, 2026
- Integralist/agent-skillstheir own version, first seen Nov 6, 2026
- theexperiencecompany/gaiatheir own version, first seen Nov 3, 2026
- JHostalek/dotclaudetheir own version, first seen Nov 1, 2026
Used with
Projects with it also use layout, shape and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
owshq-mecSkilllayout
Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
Also in 8 projects that use this
HAR5HA-7663Skillshape
Plan the UX and UI for a feature before writing code. Runs a structured discovery interview, then produces a design brief that guides implementation. Use during the planning phase to establish design direction, constraints, and strategy before any code is written.
Also in 11 projects that use this
ReScienceLabSkillarchive
Archive session learnings, debugging solutions, and deployment logs to .archive/yyyy-mm-dd/ as indexed markdown with searchable tags. Use when completing a significant task, resolving a tricky bug, deploying, or when the user says \"archive this\". Maintains .archive/MEMORY.md index for cross-session knowledge reuse.
Also in 3 projects that use this
klauswgSkillckm:design-system
Token architecture, component specifications, and slide generation. Three-layer tokens (primitive→semantic→component), CSS variables, spacing/typography scales, component specs, strategic slide creation. Use for design tokens, systematic design, brand-compliant presentations.
Also in 3 projects that use this
iovisorSkillevolve
Evolve uBPF through a gated spec-first workflow that propagates approved changes through requirements, design, validation, implementation, and RFC alignment artifacts.
Also in 3 projects that use this
termdockSkillrecall
Retrieves cross-session memories about past decisions, lessons, and patterns. Use when user asks about prior work, past decisions, or mentions a feature. Triggers include check memory, what did we decide, how did we solve.
Also in 5 projects that use this
Other versions75 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 75
- talesofai/cohub★ 585same name
- juxt/allium★ 506same name
- educlopez/ui-craft★ 441same name
- Michaelliv/napkin★ 428same name
- nexmoe/DayBee★ 424same name
- nexmoe/eve★ 424same name
- Southclaws/storyden★ 348same name
- 10xChengTu/Mux0★ 337same name
- theexperiencecompany/gaia★ 325same name
- AkaraChen/aghub★ 271same name
65 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 9 are distinctive, and 7 are very specific to this project.
0
Common
Most of the 71 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
Drafts only, never auto-promote: Every distill output lands in ./notes/atomic/.
- Distinctive: line 28
Source must be explicit: Before extracting anything, name the source and confirm it.
- Distinctive: line 33
Title is a narrative claim: Not a noun phrase ("Maintenance"), but a specific claim ("Operative knowledge must grow sublinearly with work …
- Very specific: line 52
Linked: When relevant adjacent notes exist (in ./notes/atomic/ or elsewhere), ## Related includes wikilinks to them.
- Distinctive: line 56
If a candidate fails any of these, either reshape it until it passes or abandon it.
- Very specific: line 78
Conversation context: If the claim is in the current conversation (just discussed, just transcribed), use that.
- Distinctive: line 83
Explicit files: If the user named files ("distill from these three transcriptions"), use exactly those.
- Distinctive: line 87
Vague gesture — search: If the user said "I think I've written about this before" or "go find what I've said about X":
- Very specific: line 97
Multiple drafts converging: If asked to merge several existing drafts (in ./notes/atomic/ or elsewhere) into a higher-level concept, list …
- Distinctive: line 104
Read the source(s) carefully.
- Distinctive: line 119
If the source has multiple distinct load-bearing claims, produce multiple Zettels — one per claim.
- Distinctive: line 166
Keep paragraphs tight. If you cannot say what the claim is in the first sentence of paragraph 1, the claim is not yet atomic.
- Very specific: line 169
If no adjacent notes exist yet, leave the ## Related section empty rather than inventing links.
- Distinctive: line 174
After writing, tell the user:
- Very specific: line 181
Do not say "promoted to canonical" — you never do that.
- Very specific: line 189
./notes/atomic/: if it exists, or create it under the current working directory.
“Common” is measured: kept by at least 6 in 10 of the 71 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
distill
Extract Zettel-worthy atomic notes from any source and deposit them as drafts. Promotion to canonical notes is always manual — the user copy-pastes-and-edits in their own voice.
Operating principles
- Drafts only, never auto-promote. Every distill output lands
in
./notes/atomic/. The user manually promotes to whatever their canonical-notes folder is (./evergreens/,./permanent/, their Obsidian vault, their notes app — the skill does not need to know). - Source must be explicit. Before extracting anything, name the source and confirm it. Distilling from the wrong material wastes the work.
- One claim per Zettel. A Zettel-worthy note is atomic. If the body has an "and also", it is two Zettels, not one.
- Title is a narrative claim. Not a noun phrase ("Maintenance"), but a specific claim ("Operative knowledge must grow sublinearly with work done"). The title is defensible as a standalone assertion.
What is a Zettel-worthy note
A draft Zettel meets ALL of these:
- Standalone. Readable without context. Anyone landing on this note cold should understand the claim and why it matters.
- Self-contained. No "as discussed above" or "see the audio". The claim's substance is in this note.
- Short. 2–4 paragraphs of body. If longer, the claim is probably not yet atomic — split it.
- Memorable. The reader can restate the claim in one sentence after reading.
- Title is a claim. Sentence form, asserts something specific.
- Linked. When relevant adjacent notes exist (in
./notes/atomic/or elsewhere),## Relatedincludes wikilinks to them.
If a candidate fails any of these, either reshape it until it passes or abandon it. A weak Zettel pollutes the candidate pool.
When to use
- The user explicitly invokes distill (see triggers above).
- The user just produced a load-bearing claim in conversation they want captured.
When NOT to use
- Summarisation requests — that's a summary, not a Zettel.
- Briefing generation — different artifact, different home.
- Long-form essays or design docs — distill is for atomic notes, not for prose.
Procedure
1. Identify the source — tiered discovery
In order, until source is determined:
- Conversation context. If the claim is in the current
conversation (just discussed, just transcribed), use that.
State explicitly: "Distilling from this conversation,
specifically
<the relevant message>." - Explicit files. If the user named files ("distill from these three transcriptions"), use exactly those. Confirm by listing them back.
- Vague gesture — search. If the user said "I think I've
written about this before" or "go find what I've said about X":
- Grep across the project for keyword overlap:
grep -rln '<keyword>' --include='*.md' . - List matches as candidates. Confirm BEFORE extracting: "I found these N notes that look relevant: [...]. Distill from these, or refine the search?"
- Grep across the project for keyword overlap:
- Multiple drafts converging. If asked to merge several
existing drafts (in
./notes/atomic/or elsewhere) into a higher-level concept, list the drafts being merged and confirm before extraction.
2. Extract candidate claims
Read the source(s) carefully. Identify the load-bearing claims — the sentences that, if removed, would change the meaning of the surrounding material. Filler, examples, asides, and "thinking out loud" passages are not load-bearing; they are scaffolding that helped the author arrive at the claim.
Common patterns that signal a load-bearing claim:
- An assertion stated multiple times in different words.
- A "the principle is …" / "the key idea is …" / "what matters is …".
- A definition the author coins or reaches for.
- A negation that closes off a wrong path ("the only reason to do this is X, and X is a bad reason").
If the source has multiple distinct load-bearing claims, produce multiple Zettels — one per claim. Don't pack them into one note.
3. Draft each Zettel
File location: ./notes/atomic/<YYYY-MM-DD>-<slug>.md where
<slug> is a hyphenated lowercase short-form of the title (3–6
words).
Frontmatter:
---
date: <YYYY-MM-DD>
type: zettel_candidate
source: "<raw path to source file>"
status: draft — awaiting manual promotion
---The source: field is a raw path string, not a [[wikilink]].
This keeps provenance metadata intact without creating a graph
edge that may not be wanted in the destination notes system.
Body structure:
# <Title — narrative claim, sentence-form>
<Paragraph 1 — state the claim plainly. What is being asserted.>
<Paragraph 2 — why the claim holds. The reasoning, the evidence,
or the mechanism. Should make the claim defensible, not just
stated.>
<Optional paragraph 3 — implications, scope, or boundary
conditions. When does this hold? When does it not? What follows
from it?>
<Optional paragraph 4 — one concrete example or counterexample.>
## Related
- [[<adjacent note slug>]] — one-line description of the link.
- [[<another note>]] — another link.Keep paragraphs tight. If you cannot say what the claim is in the first sentence of paragraph 1, the claim is not yet atomic.
If no adjacent notes exist yet, leave the ## Related section
empty rather than inventing links.
4. Surface the drafts
After writing, tell the user:
- Which source(s) you distilled from.
- How many candidates you produced and their titles.
- Where each landed.
- Any candidates you rejected and why (helps calibrate).
Do not say "promoted to canonical" — you never do that. Say
"drafted in ./notes/atomic/, ready for your review."
Output location
Defaults, in this order:
- User-specified path in the conversation.
./notes/atomic/if it exists, or create it under the current working directory../distilled/or./zettels/if either already exists.
What this skill explicitly does NOT do
- Never auto-promote a draft into the user's canonical-notes folder. Promotion is manual, by the user, in their own voice.
- Never modify the source. Distillation reads; it does not edit the material it draws from.
- Never produce a Zettel without an identified source. "I just thought of this" is not a valid source — that's the user's job, not the skill's.
- Never combine unrelated claims into one note to reduce note count. Atomicity beats tidiness.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

