Most automation projects build an automation. This one builds a system that discovers which automations to build — by mining your own recent work — and then packages the high-confidence ones into reusable tools. It's a self-improving skill for Claude Code.
The problem: repeated manual work is invisible
You feel it but rarely measure it: the same multi-step sequence done by hand for the third time. A focused bug-fix → branch → conventional commit → PR cycle. A QA-sweep dispatch. A release deploy. Each repetition is a signal that an abstraction is missing — but nobody systematically finds those signals. They're scattered across git history, terminal sessions, and memory.
What distill-workflows does
distill-workflows is a Claude Code skill that turns that scattered signal into reusable tooling, in one pass:
-
Scan three sources of "what was done recently":
- Git commit-shape frequency — normalized subjects, ranked.
-
Session transcripts (
*.jsonl) — repeated bash command patterns and recurring user-request phrasings. What you did and what you were asked. - Repo memory (GPS) — lessons, decisions, and promotion candidates already flagged.
- Cluster the raw signal into named, repeated procedures.
- Reconcile against a persistent cross-session ledger so a pattern seen once per session still accumulates toward the bar over time.
- Score each candidate on frequency × determinism × friction.
- Propose a ranked table and confirm with the human before doing anything irreversible.
- Scaffold the winners from templates into the right artifact — a skill, a subagent, or a workflow — and record the rationale back into memory.
The architecture
The diagram above maps the flow left-to-right: Signal Sources → Scanner (scan.sh) → Distill Engine → Packaging → Outputs, with a Persistent Ledger the engine reads and writes, and a dashed cross-session feedback loop that feeds each run's recorded rationale back into the next run's sources.
A few design choices worth calling out:
- Read-and-propose first, scaffold on confirmation. Nothing lands on disk without a human gate. Automation that edits your repo should ask first.
- Extend before create. If 80% of a candidate already lives in an existing skill, the engine says so instead of producing a near-duplicate.
- The ledger fixes the frequency blind spot. A workflow you do once per session looks rare inside a single run. Accumulating "seen" counts across runs is what lets genuinely recurring work eventually qualify.
It found real work — on itself
Run against its own repo, the scanner surfaced a pattern repeated 50+ times that nobody had abstracted: a single-concern Android/Kotlin fix shipped as a small PR with the same conventions every time (branch naming, conventional commit scope, base branch, size limit, no AI attribution). The engine packaged it into an android-fix-pr skill — exactly the kind of convention layer the generic commit/create-pr tools don't encode.
The higher-frequency QA-sweep pattern was also detected, but the engine correctly declined to package it: it already existed as a parameterized workflow. Knowing when not to build is half the value.
How it's built
- A
SKILL.mdprocedure the agent follows. - A
scan.shsignal miner —jqover transcripts,git logshape analysis,gps recall, artifact inventory — emitting one structured report. - A
watchlist.mdledger for cross-session frequency. - Artifact templates for skill / subagent / workflow.
- GPS repo memory for persisted decisions.
What's next
- Schedule it to run automatically and surface a weekly "candidate digest."
- Rank promotion candidates via the GPS MCP tool.
- Share distilled skills across repos.
Built with Claude Code. The core idea generalizes well beyond one repo: point a discovery loop at your own work history, score what repeats, and let the high-confidence patterns become tools.

Top comments (0)