agentleFS
matcommatcom/ai-skills/skills/distill/SKILL.md

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

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-mecSkill

    layout

    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-7663Skill

    shape

    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

  • ReScienceLabSkill

    archive

    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

  • klauswgSkill

    ckm: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

  • iovisorSkill

    evolve

    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

  • termdockSkill

    recall

    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

    1. talesofai/cohub★ 585same name
    2. juxt/allium★ 506same name
    3. educlopez/ui-craft★ 441same name
    4. Michaelliv/napkin★ 428same name
    5. nexmoe/DayBee★ 424same name
    6. nexmoe/eve★ 424same name
    7. Southclaws/storyden★ 348same name
    8. 10xChengTu/Mux0★ 337same name
    9. theexperiencecompany/gaia★ 325same name
    10. 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.

  • In this repository5 other files it gives its agents.

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
  1. Very specific:

    Drafts only, never auto-promote: Every distill output lands in ./notes/atomic/.

    line 23
  2. Distinctive:

    Source must be explicit: Before extracting anything, name the source and confirm it.

    line 28
  3. Distinctive:

    Title is a narrative claim: Not a noun phrase ("Maintenance"), but a specific claim ("Operative knowledge must grow sublinearly with work …

    line 33
  4. Very specific:

    Linked: When relevant adjacent notes exist (in ./notes/atomic/ or elsewhere), ## Related includes wikilinks to them.

    line 52
  5. Distinctive:

    If a candidate fails any of these, either reshape it until it passes or abandon it.

    line 56
  6. Very specific:

    Conversation context: If the claim is in the current conversation (just discussed, just transcribed), use that.

    line 78
  7. Distinctive:

    Explicit files: If the user named files ("distill from these three transcriptions"), use exactly those.

    line 83
  8. Distinctive:

    Vague gesture — search: If the user said "I think I've written about this before" or "go find what I've said about X":

    line 87
  9. Very specific:

    Multiple drafts converging: If asked to merge several existing drafts (in ./notes/atomic/ or elsewhere) into a higher-level concept, list …

    line 97
  10. Distinctive:

    Read the source(s) carefully.

    line 104
  11. Distinctive:

    If the source has multiple distinct load-bearing claims, produce multiple Zettels — one per claim.

    line 119
  12. Distinctive:

    Keep paragraphs tight. If you cannot say what the claim is in the first sentence of paragraph 1, the claim is not yet atomic.

    line 166
  13. Very specific:

    If no adjacent notes exist yet, leave the ## Related section empty rather than inventing links.

    line 169
  14. Distinctive:

    After writing, tell the user:

    line 174
  15. Very specific:

    Do not say "promoted to canonical" — you never do that.

    line 181
  16. Very specific:

    ./notes/atomic/: if it exists, or create it under the current working directory.

    line 189

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. 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).
  2. Source must be explicit. Before extracting anything, name the source and confirm it. Distilling from the wrong material wastes the work.
  3. One claim per Zettel. A Zettel-worthy note is atomic. If the body has an "and also", it is two Zettels, not one.
  4. 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), ## Related includes 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:

  1. 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>."
  2. Explicit files. If the user named files ("distill from these three transcriptions"), use exactly those. Confirm by listing them back.
  3. 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?"
  4. 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:

  1. User-specified path in the conversation.
  2. ./notes/atomic/ if it exists, or create it under the current working directory.
  3. ./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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.