agentleFS
boaz-hwangboaz-hwang/skilloom/skills/distill/SKILL.md

distill

Skill14 starsChanged 36 days agoMITView on GitHub

Turn a completed, user-approved task into a concise reusable skill from the current session. Use when the user asks to distill successful work into a skill, after one pass or several revisions.

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

  • 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

  • bidodevSkill

    devils-advocate

    Challenges decisions, plans, and code by systematically arguing the opposing side. Surfaces risks, pokes holes in assumptions, and stress-tests thinking before committing. Supports intensity levels (gentle, balanced, ruthless, linus) and works with conversation context or a specific file reference. Trigger on requests like "challenge this", "poke holes", "what could go wrong", "play devil's advocate", "linus mode", or "/devils-advocate".

    Also in 3 projects that use this

  • Other versions75 projects use a version of this.

    Word for word · 1

    1. boaz-hwang/distill★ 14100% same

    Edited · 0

    None found.

    Wrote their own version · 74

    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

    64 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 repository3 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 70 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the available session and accepted deliverable.

    line 15
  2. Very specific:

    Create <confirmed-name>/SKILL.md with YAML name and description fields.

    line 46
  3. Distinctive:

    Put evaluation in the generated skill:

    line 64
  4. Distinctive:

    Human: Keep only judgments code cannot establish.

    line 72
  5. Distinctive:

    Check skill metadata and referenced resources.

    line 81
  6. Distinctive:

    After the two confirmations, finish without adding another approval gate.

    line 88

“Common” is measured: kept by at least 6 in 10 of the 70 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

Preserve the minimum needed to reproduce a result the user considers good. Assume a capable agent: specify outcomes, essential constraints, and evidence of quality; leave implementation choices open. Discuss in the user's language.

1. Confirm the destination

Read the available session and accepted deliverable. Infer the quality bar from requests, corrections, and final acceptance. Ask for missing acceptance or essential evidence specifically; do not invent history or search unrelated sessions.

Propose three skill names, recommend the strongest, and describe the intended deliverable in one line. Ask whether the name and outcome match the user's intent; request an explanation if not. Honor a name the user already chose.

Wait for name/outcome confirmation before step 2. Reconfirm corrected proposals.

2. Confirm the shortest sufficient process

Work backward from the accepted result. Propose numbered steps, one line each; merge or remove steps unless a quality requirement would be lost. Omit failed paths and detours, but keep essential constraints learned from corrections.

Separate reusable requirements from incidental tools, filenames, quantities, and style choices. For an uncertainty that would change the result, propose the answer suggested by the session and ask a focused question, not an intake questionnaire.

Show required inputs/templates with the relevant step. Reuse an available template or derive one from the accepted artifact; request it if faithful reconstruction isn't possible. Include evaluation and briefly propose which criteria code checks and which need human judgment, so the user can correct what counts as success.

Wait for process confirmation before writing the skill. Apply requested changes, show the revised steps, and confirm again. Reconfirm a changed name or outcome too. Silence is not approval.

3. Write only what changes the result

Create <confirmed-name>/SKILL.md with YAML name and description fields; describe what it produces and when to use it. For each approved step, state only necessary inputs, decisive constraints, and what completion looks like. The generated skill should ask only for missing inputs that affect its result. Carry over these two confirmation gates only if the target task needs them.

Bundle only needed templates, references, and scripts; link them with relative paths. Choose code languages and tools to fit the task and execution environment. Make session-specific values inputs. Exclude private session content, credentials, and unexplained local dependencies. Past permission for external actions is not blanket permission for future runs.

For each instruction: could removing it cause a capable agent to miss an accepted requirement? If not, delete it. Do not relocate excess into supporting files or add generic advice and speculative rules. Keep detail that quality actually needs.

4. Make quality repeatable

Put evaluation in the generated skill:

  • Code: Automate as many meaningful criteria as the evidence supports. Reuse or write checks in scripts/, documenting dependencies, invocation, and pass/fail output. Check actual artifacts against requirements; counts and formatting cannot substitute for correctness, usefulness, or taste. Test an accepted example and a deliberately defective one, without bundling private examples. If no meaningful check is possible, explain why rather than inventing one.
  • Human: Keep only judgments code cannot establish. Say what to inspect and ask concrete acceptance questions grounded in the feedback. Agent self-assessment is not human approval.

Instruct the generated skill to run its checks before delivery, report failures and untested criteria, and present remaining human review questions. Use subsequent feedback for the smallest justified change to a criterion, template, instruction, or check, preserving scope.

Check skill metadata and referenced resources; use an available format validator when useful. Run generated checks in their required environment, reporting any that cannot be run. When feasible and authorized, try fresh input using only the skill and declared resources. Distinguish format checks, actual execution, and pending human review.

Deliver the location, verification results, and short human review guide. After the two confirmations, finish without adding another approval gate.

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.