distill

name	distill
description	Conversation mode that makes the LLM speak in distill compressed language for the whole thread.

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:

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:

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

Plan:

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:

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

Review/result:

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:

Dict: B=backend F=frontend C=config

Later additions:

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.

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.