The Extraction Process
I have a repo with 13 reusable skills. None of them were designed. Every single one was extracted from a real session where I was solving a real problem and noticed — after the fact — that the solution was bigger than the problem.
This is the opposite of how most tools get built. The standard approach: identify a need, design a solution, build it, ship it. Top-down. Intentional. Clean.
The extraction approach: solve a problem, finish the work, look at what you built, and ask — does this apply beyond the context that created it? If yes, pull it out, clean it up, and make it standalone.
It's less elegant. It produces better tools.
Why Extraction Beats Invention
When you design a tool from scratch, you're guessing. You imagine use cases. You anticipate needs. You build abstractions for scenarios that may never happen. This is how you end up with configuration options nobody uses and flexibility nobody asked for.
When you extract a tool from real work, every line of code has already proven its value. The edge cases are real edge cases you actually hit. The defaults are the values that actually worked. There's no speculation — only experience compressed into a reusable form.
The distillation analogy is exact: you start with a large, messy volume of raw material (the session), apply heat (analysis), and collect only what evaporates and recondenses (the essential pattern). Everything that doesn't survive the process was context-specific noise.
The Three Artifacts
Not every extraction produces the same thing. I've found three natural categories, roughly sorted by complexity:
Commands — The Simple Extract
A command is a single operation. It takes input, does a thing, produces output. No branching logic, no multi-step orchestration.
Example: I was committing code and kept writing the same style of commit message manually. The pattern was obvious — summarize changes, categorize (feat/fix/refactor), keep it under 72 characters. That became a commit-smart command. It reads the diff, generates the message, and commits. One operation. No decisions.
The test: if a flowchart of the tool has no diamonds (decision points), it's a command.
Skills — The Structured Workflow
A skill is a multi-step process with decisions. It has a defined procedure, conditional branches, and produces different outputs depending on context.
Example: I was building an Android APK without Android Studio — raw SDK, command line, manual signing. By the third APK, I had a mental checklist: scaffold the project structure, write the manifest, set up the build script, generate keystores, handle the specific gotchas (HTTP cleartext permissions, intent filters for share targets). That checklist became the android-apk skill. It's not one command — it's an entire build methodology with decision points at each step.
The test: if someone could follow it as a written procedure and produce the same output, it's a skill.
Agents — The Autonomous System
An agent is a persistent entity with its own context, memory, and decision-making loop. It doesn't execute a procedure — it evaluates a situation and decides what to do.
Example: my operations manager started as a morning briefing script. Check system health, read the calendar, summarize overnight messages. But it kept growing — handle message delivery failures, retry on specific error codes, update relationship tracking when contacts are detected, run semantic searches to cross-reference topics. At some point it stopped being a script and became an agent: something that observes, decides, and acts on its own schedule.
The test: if it needs to make judgment calls without human input, it's an agent.
How to Recognize an Extraction Opportunity
Most sessions produce solutions. Few produce extractable solutions. The difference:
You catch yourself explaining the approach, not just the result. When the interesting part is how you solved it rather than that you solved it, there's a pattern worth capturing.
You've done the same shape of work before. Not the same problem — the same shape. Different inputs, same structure. The third time you notice this, extract it.
The solution works without knowing the original context. If you have to explain the specific project, the specific bug, the specific client requirement for the solution to make sense — it's not extractable yet. If the solution makes sense described generically — "handles the case where a catch-all route intercepts specific endpoints" — it's ready.
Someone else could use it. Not a hypothetical someone. A specific person you can picture running this tool on their own work. If you can't picture that person, the solution is still too context-bound.
The Extraction Procedure
When I spot something worth extracting, the process is consistent:
1. Isolate the core. Strip everything project-specific. Variable names, file paths, API keys, domain logic — all replaced with parameters or sensible defaults. What's left is the structural skeleton.
2. Name the pattern. Not the implementation — the pattern. "Voice-to-structured-data pipeline" not "Whisper transcription with Haiku cleanup." The name should describe what it does at a level that survives the next technology cycle.
3. Document the procedure. Write it as instructions a skilled person could follow cold. Not code comments — a procedure. What comes first, what decisions get made, what the output looks like. This is the skill definition.
4. Test it on a second problem. The extraction isn't valid until it works somewhere other than where it was born. Take the generalized version and apply it to a different project, a different context. The parts that break reveal where you under-generalized.
5. Ship it. Put it in a repo. Make it findable. A tool that only exists in your notes isn't a tool — it's a memory.
What Gets Lost in Extraction
Not everything should survive the process.
Configuration for one. If a setting only made sense for the original use case, don't carry it forward as an option. Default it or remove it. Every configuration option is a decision someone has to make later.
Defensive code for impossible scenarios. In the original session, you hit a weird edge case with malformed Unicode in emoji. In the extracted tool, that's a sanitization utility — not an integral part of the workflow. Factor it out or document it as a known environment issue.
Sequential coupling. In the session, step 3 depended on step 2 because of how the specific project was structured. In the extracted tool, if the dependency isn't inherent to the pattern, make the steps independent. Let people reorder or skip.
The goal is the minimum viable pattern. Three similar lines of code are better than a premature abstraction. One clear procedure with no options is better than a flexible framework with twelve switches.
The Compound Effect
The first few extractions feel like overhead. You solved the problem — why spend more time packaging the solution?
The compound effect kicks in around extraction 8 or 9. By then you have a library of patterns that cover common scenarios. New problems start mapping to existing tools. A task that would have taken an hour takes ten minutes because you've already extracted the hard part from a previous session.
More importantly: your thinking changes. You start recognizing extractable patterns during the work, not after. You structure solutions with cleaner boundaries because you know you might pull them apart later. The extraction habit improves the work itself, not just the artifacts it produces.
This is the real payoff. Not the repo with 13 skills. The fact that skill 14 will be easier to build because the first 13 trained you to see patterns differently.
The Repo
All 13 extracted skills are open source: claude-code-skills
They range from simple (generate a commit message) to complex (build a native Android APK from the command line, multi-step security audit, open-source intelligence research). Each one started as a session. Each one outgrew it.
The discipline isn't invention. It's recognition. The tools are already there, embedded in the work you've already done. The extraction process is just learning to see them.
