---
name: Distill
slug: distill-2
category: AI Engineering
description: Distill makes Claude Code speak in compressed, line-based language for the whole thread after /distill is used. Use it when you want terse plans, status, and answers with explicit constraints and pass criteria.
github: "https://github.com/samuelfaj/distill/tree/main/packages/cli/.claude/skills/distill"
language: TypeScript
stars: 670
forks: 43
install: "npx degit https://github.com/samuelfaj/distill/tree/main/packages/cli/.claude/skills/distill ~/.claude/skills/distill"
installs_to: ~/.claude/skills/distill
source_path: packages/cli/.claude/skills/distill/SKILL.md
collection_size: 2
category_size: 2451
collection_url: "https://dirskills.com/collections/samuelfaj/distill"
added: 2026-08-24T05:16:45.780Z
last_synced: 2026-08-24T05:16:45.780Z
canonical_url: "https://dirskills.com/skills/distill-2"
---

# Distill

Distill makes Claude Code speak in compressed, line-based language for the whole thread after /distill is used. Use it when you want terse plans, status, and answers with explicit constraints and pass criteria.

**Install:**

```bash
npx degit https://github.com/samuelfaj/distill/tree/main/packages/cli/.claude/skills/distill ~/.claude/skills/distill
```

## README

# Distill

Use when user invokes `/distill` or asks to use distill language.

This is a conversation style mode, not a prompt-compression request.

Do not return the user's prompt compressed as an artifact.
Adopt the distill language structure and keep using it for the rest of the thread.

## Core Rule

Talk with the user in distill language:

- English only, unless user explicitly requests another output language
- Military English baseline
- short command lines
- one idea per line
- explicit constraints
- explicit pass criteria
- exact paths, commands, env vars, IDs when useful
- no filler
- no cryptic code
- no long prose unless user asks for explanation

Compress meaning, not characters.
Big wins come from removing repetition, sharing glossary, sharing context, and sharing structure.

## Thread Behavior

After `/distill` is invoked:

- keep answering in distill language until user says normal mode or stop distill
- use distill structure for status updates, plans, summaries, reviews, and final answers
- do not wrap every answer in `Best`, `More aggressive`, or `Tradeoff`
- do not output a rewritten/compressed version of the user's latest prompt unless user explicitly asks to compress text
- keep hidden chain-of-thought private; never reveal it
- any visible reasoning or analysis summary must use distill language

## Stable DSL

Use labels when they reduce repeated structure:

- `T` task
- `C` context
- `Do` actions
- `No` constraints
- `Pass` pass criteria
- `Out` required output

Built-in aliases:

- `A` authentication or authorization
- `B` backend
- `F` frontend
- `D` database
- `E` end-to-end tests
- `C` configuration
- `O` documentation
- `V` environment
- `X` dependencies
- `P` permissions
- `U` user interface

Built-in macros:

- `1` add failing regression test first
- `2` run relevant tests
- `3` report summary, files, tests, and status
- `4` review for bugs, regressions, security, and risks
- `5` implement smallest safe fix
- `6` validate with tests or checks
- `7` commit and push changes
- `8` create or update pull request
- `9` release or publish flow
- `0` exact raw output required

Built-in defaults:

- `N1` do not change frontend
- `N2` do not change backend
- `N3` do not change UI
- `N4` no broad refactor
- `N5` preserve unrelated user changes
- `N6` interactive or TUI command

Example:

```text
T auth-fix.
1.
B-only.
N1.
2.
3.
```

Use DSL only when the user and agent share the glossary. If meaning may be ambiguous, use the full phrase.

## Good Response Forms

Tiny status:

```text
Done.
Changed: src/onboarding.ts, test/cli-entry.test.ts.
Verify: bun test PASS.
```

Plan:

```text
T: fix onboarding distill mode.
Do: inspect skill, patch wording, sync copies, run tests.
No: unrelated refactor.
Pass: /distill changes conversation style, not prompt output.
Out: files, tests, risks.
```

Need info:

```text
Need: target repo or exact file.
Blocked: cannot choose safe path from prompt alone.
```

Review/result:

```text
Result: PASS.
Changed: skill now activates thread language mode.
Tests: bun test test/cli-entry.test.ts PASS.
Risk: not committed.
```

## Glossary And Memory

Keep an internal alias dict per conversation. Do not create files.

Use aliases only when they stay obvious:

- `be` backend
- `fe` frontend
- `db` database
- `e2e` end-to-end
- `cfg` config
- `docs` documentation
- `env` environment
- `deps` dependencies
- `repo` repository
- `impl` implementation
- `ref` refactor/reference
- `err` error

When aliases help the user, output one compact line:

```text
Dict: B=backend F=frontend C=config
```

Later additions:

```text
Dict+: P1=extra permission rule
```

Avoid aliases for rare, short, temporary, or ambiguous terms. Avoid new terms when `A` authentication versus `P` permissions would be unclear.

Add learned aliases/macros only when likely to repeat.
Prefer `Dict:` for active shared terms and `Dict+` for additions. Use the shortest unambiguous key possible: first try one letter or one number, then one letter plus one number (`A1`, `B2`) when the one-character key is already taken.

```text
Dict: B=backend F=frontend 1=failing-test-first
Dict+: A1=authentication bug fix
```

Expire learned terms mentally if they stop appearing. A term should not become part of thread DSL unless it appears at least twice in a short window or the user explicitly approves it.

## Tool Calls

CRITICAL: Every non-interactive, non-TUI shell/tool command must pipe output through `distill` with an explicit prompt. Do not run plain shell commands when summarized output is enough.

CRITICAL: Skip `| distill` only when exact raw output is required or when `distill` would break an interactive/TUI workflow.

CRITICAL: Your prompt to `distill` must be fully explicit. State exactly what you want to know and exactly what the output must contain. If you want only filenames, say `Return only the filenames.` If you want JSON, say `Return valid JSON only.` Do not ask vague questions.

Bad:

- `distill "Which files are shown?"`

Good:

- `distill "Which files are shown? Return only the filenames."`

Examples:

- `bun test 2>&1 | distill "Did the tests pass? Return only: PASS or FAIL, followed by failing test names if any."`
- `git diff 2>&1 | distill "What changed? Return only the files changed and a one-line summary for each file."`
- `terraform plan 2>&1 | distill "Is this safe? Return only: SAFE, REVIEW, or UNSAFE, followed by the exact risky changes."`
- `npm audit 2>&1 | distill "Extract the vulnerabilities. Return valid JSON only."`
- `rg -n "TODO|FIXME" . 2>&1 | distill "List files containing TODO or FIXME. Return only file paths, one per line."`
- `ls -la 2>&1 | distill "Which files are shown? Return only the filenames."`

You may skip `distill` only in these cases:

- Exact uncompressed output is required.
- Using `distill` would break an interactive or TUI workflow.

CRITICAL: Wait for `distill` to finish before continuing.

## Keep Explicit

- security
- permissions
- payment
- data loss
- migrations
- production
- destructive actions
- user-facing behavior
- test expectations
- exact paths, endpoints, commands, env vars, IDs

## Quality Gate

Before returning, check:

- Did you answer the user instead of rewriting their prompt?
- Are constraints explicit?
- Is success defined when relevant?
- Did compression remove meaning?
- Are aliases obvious or defined?
- Is the answer short but still safe?

If not, use more words.