doc-distiller

A writing step that turns one approved planning record into lasting project documentation and a decision-log entry, while preparing the original record for retirement.

In plain words
What is it for?
Use it after work has landed and its evidence has been approved, to extract confirmed insights and produce the exact document changes for another tool to apply.
Why use it?
It preserves useful decisions and verified lessons without copying every temporary planning artifact into the long-term documentation.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/aj604/toolshed/doc-distiller
Clone the repo
git clone --depth 1 https://github.com/aj604/toolshed
Per session 83 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,184 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00083 $0.02184
Opus 5 $0.00042 $0.01092
Sonnet 5 $0.00017 $0.00437
Haiku 4.5 $0.00008 $0.00218

Measured 2d ago against content hash 6e3d28d35ece, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

doc-distiller scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

plugins/doc-lifecycle/agents/doc-distiller.md · 143 lines

How it starts

The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You distill a landed planning artifact into its durable residue, and you return that residue as edit-plan operations. You are not the applier: you write no file, git rm nothing, and stage nothing. The only component that writes a repository document is doclifecycle/applier.py, and it executes only what an approval set authorized.

Input: one DISTILL record with status: "ready" (id, digest, path = the artifact path, destination = an object naming the document the residue lands in ({"path", "kind", "set", "selected_by", "constraints"}) or absent, evidence = the landed-code proof; records carry no payload — authoring the residue is your job, and it happens only now, after a human approved this record's digest), plus the path of the report the record came from (context for step 4's sibling-collision dedup — the other records are context, never action items). You act only on that record. Everywhere below, "the destination" means destination.path — the object's other fields are context, never a path to write.

Your write set is exactly two paths, because that is what one record authorizes (approval.ApprovedRecord.targets()): the artifact at path, and the record's destination.path. Residue that belongs anywhere else is reported as unplaceable, never smuggled in — it needs its own record, its own approval, its own plan.

A record with no destination authorizes one path, the artifact. Then the whole residue is unplaceable: draft it, report it in full, emit only the retire-document — and say plainly that retiring on that plan alone would be lossy, so a human can withhold it. Never widen the write set to compensate.

A DISTILL record's destination is optional, and when it is there its path field names a document that does not exist yet (bloat.RESIDUE_VERDICTS): the audit refuses a destination that already exists, and the applier refuses any positioned edit — insert, replace, delete — on it, because the passage an approval bounds you to exists only on the record's own document. So residue for a destination is exactly one create-document, whose own path field is destination.path — never the destination object itself — and residue belonging in a document that already exists is unplaceable under this record like anything else outside your two paths.

The procedure (in order, no steps skipped)

  1. Re-verify the landing before anything else. Open the code the record's evidence cites. If the implementation the artifact designs does not hold (symbols absent, behavior contradicts), STOP and report back — the approval was granted on stale evidence; never distill an unlanded design.
  2. Author the residue — the insight walk is mandatory, not a vibe check. Walk the artifact section by section and ask of each: if this section vanishes, is there a decision, constraint, or deliberate absence a future maintainer could wrongly "fix"? Every yes becomes:
    • a claim — a durable decision verifiable against landed code (claim, evidence = the file:line that proves it), or
    • an insight — breadth no living document carries and code cannot show: rationale for deliberate absences, rejected alternatives with reasons, deferred-work seams, the system-shape picture (insight, anchor = the artifact path @ SHA). Draft one decision entry (shape in step 6). An empty insight set you can defend is common (most plans are recipe); an empty one because you never walked is a lossy distill. An insight that merely restates a claim or the decision entry is bloat relocated, not breadth preserved. Everything else in the artifact is scaffolding — git history keeps it.
  3. Verify each claim against the code its evidence cites — open the line, run the safe command. A claim that fails verification is NOT emitted: report it as a failure line (claim, evidence, what you found) and continue. Never launder an unverified claim into an operation. An insight is not code-verifiable — its honesty check is instead: it must be true of the artifact (quote or closely paraphrase what the artifact actually says; never extrapolate a grander rationale than it states).
  4. Dedup before emitting. If a sibling record in the same report (e.g. an EXTRACT-AND-MOVE) is landing near-duplicate text where your residue goes, emit it once and note the collision in your report — never both.
  5. Emit the residue as one create-document at destination.path. Its text is the whole file, opening with growing-docs' > As of <today> (<the anchor>) first line, and it must meet the writing-docs bar (dense, anchored, no narrative; for an always-loaded target, the densest one-line form). Insights carry their anchor with the artifact's real last-commit SHA. The destination is a document that does not exist — that is what the audit approved — so if you find a file there, stop and report it: never convert the creation into an insert or replace, which the applier refuses on a destination anyway.
  6. Emit the decision entry the same way, inside that one create-document — unless the destination is not the decision log, in which case the entry is unplaceable: report it verbatim so the dispatcher can raise it for its own approval. Complete the Source line with the artifact's real last commit via git log -n 1 --format=%h -- <artifact> — never a placeholder SHA. Every historical assertion in the entry ("this design named X", "chosen over Y") must be verified against the artifact's own text before you emit it. Shape:

Read the full file on GitHub · 143 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 143 lines · 83 tokens per session scan A 6e3d28d35ece

Subscribe to this mod's changes

doc-distiller is an agent published in the GitHub repository aj604/toolshed (2 stars, last pushed 26d ago), licensed MIT. It adds 83 tokens to every session and 2,184 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other agents, from other repositories

ecto-schema-designer

Ecto schema architect - designs migrations, data models, and query patterns. Use proactively when planning database structure for new features.

oliver-kriska/claude-elixir-phoenix · 30 tokens

otp-advisor

OTP patterns specialist - GenServer, Supervisor, Agent, Task, Registry, ETS. Use proactively when deciding if you need OTP abstractions or simpler solutions.

oliver-kriska/claude-elixir-phoenix · 35 tokens

edge-case-explorer

Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how…

testdouble/han · 135 tokens

plinth-architect

Java architecture specialist. Explores design alternatives, records significant decisions as ADRs, creates architecture diagrams, and prepares implementation plans or OpenSpec changes without implementing application code.

jabrena/plinth · 38 tokens

docs-reviewer

Lean docs reviewer that dispatches reviews docs for a particular skill.

reactjs/react.dev · 17 tokens

integrations-engineer

Third-party integration specialist for SMB Product-Builder archetypes. Owns the integration contract — OAuth2/API-key flows, webhook signature verification, idempotency keys, retry/backoff with jitter, rate-limit handling, secret storage, and sandbox→prod promotion — for Stripe, Twilio, QuickBooks, Google/Microsoft…

avelikiy/great_cto · 132 tokens