*Published July 10, 2026* --- ## TL;DR Work discoveries usually vanish into conversation history or project notes. Pattern capture turns them into permanent, auto-activating expertise through a six-phase workflow: analyze the context, search your existing skills, write the content, integrate it, validate it, refine it. What holds it together is discipline: search before you create so you don't duplicate, extend an existing skill instead of spinning up a new one, and connect each skill to the others so the collection compounds instead of sprawling. The result is a library that surfaces the right guidance on its own, the moment the context calls for it. --- ## The Problem: Ephemeral Insights I typed "help me organize these commits" and my tools handed back a method I'd written months earlier and forgotten I owned. I never went looking for it. That's what capturing patterns as skills buys you that notes never do. It didn't used to work that way. You debug something subtle three hours deep, fix it, ship it, and three months later hit the same pattern in another project, solving it from scratch because the original insight is gone. One case from my own vault: while editing an article I noticed em-dashes were quietly manufacturing run-on sentences, and the fix was to break them into periods or commas depending on the sentence's rhythm. That insight could have stayed buried in a conversation log. Instead I folded it into an existing editing skill, so now it surfaces on its own every time I draft an article. The trap most people fall into is the opposite move: they capture the same insight three times as three narrow skills, an "em-dash-reducer," a "sentence-rhythm-checker," an "editorial-style-guide," each fifteen lines, each overlapping the others. Do that for a year and you have twenty fragments nobody searches, plus the "I know I wrote something about this" feeling that means the knowledge is gone. When capture is ad-hoc, four things are missing: a repeatable process, a way to catch duplicates, cross-references between skills, and the habit of extending what exists before adding something new. --- ## What a Skill Actually Is If you work with an AI coding agent like Claude Code, a skill is just a markdown file with a little frontmatter at the top: a name, a one-line description, and a set of trigger keywords. The agent reads those descriptions, and when your request matches a skill's triggers, it loads that skill's instructions on its own. You don't go find it; the context pulls it in. A minimal one looks like this: ```markdown --- name: atomic-commit description: Organize changes into small, single-purpose git commits triggers: [commit, organize commits, stage changes] --- Group related files. One logical change per commit. Write the "why" in the body. ``` Type "help me organize these commits" and the agent surfaces that guidance without being told where it lives. That auto-loading is the whole payoff, and it's also the catch: it's tool-specific. If you're not using an agent that supports skills, the mechanism won't transfer, but the discipline underneath it will. Capture a pattern once, in a form your tools can retrieve on their own, instead of re-deriving it every few months from memory. --- ## How I Actually Run It The whole thing takes fifteen to twenty minutes, and it's the same six moves every time. I start by pulling three things out of the discovery: the anti-pattern and the fix that actually worked, the phrases that should trigger the skill later (something like "organize commits" pointing at my atomic-commit method), and the context I found it in, the date and situation and original problem. That's about five minutes. Then I search before I create, which is the step that matters most: ```bash grep -ri "keyword1\|keyword2" .claude/skills/*/SKILL.md ``` If I find a match, I extend that skill; if I don't, I start a new one. When I kept getting confused about where things belonged in my PARA setup, I searched my existing skills, found one that already covered the area, and added an anti-pattern section to it instead of writing a new file. Most fragmentation gets prevented right here. Writing the content depends on which way that went. For an update, I add the pattern with its discovery date so the history stays legible: ```markdown ### Common Mistake: Resources vs Areas (January 2026) WRONG - "I'm interested in health, so it goes in Resources/" RIGHT - "Am I responsible for maintaining this? Then it's an Area/" ``` For a new skill, I write the whole thing: the core principles that explain why, the method itself, the patterns to follow and the ones to avoid, real examples instead of hypotheticals, and links to the related skills and documents. That linking is its own move. I connect the skill to the documents, commands, and other skills around it, whether they're prerequisites, alternatives, or extensions. An isolated skill barely gets used; wired into its neighbors, it gets pulled in from several directions at once. Before I call it done, I validate: the frontmatter is valid, the sections are all there, the examples are concrete, the trigger keywords are broad enough to actually fire, and any claim about my own vault carries a citation. Skipping that is how dead skills pile up. Then I refine in the open, showing what the change does and where it connects and what I'm unsure about, and getting feedback before I commit it. --- ## Quality Discipline Over Accumulation The workflow only pays off if two disciplines hold. The first is to enhance before you create. Search first, and when you find an adjacent skill, extend it instead of fragmenting the idea across three mediocre files. One skill with ninety lines of well-organized guidance beats three fifteen-line stubs that each cover a third of the problem and none of it well. The second is to capture patterns, not incidents. A pattern recurs across contexts and earns the fifteen minutes; a one-time fix doesn't. The filter is whether you expect to hit it again. Hold both lines and the collection changes over time. Early on you're creating foundational skills every week. A few months in, you're mostly extending what's there. Eventually you rarely create at all, and most of what you hit is already covered. --- ## Real-World Outcome The point of all this is auto-activation. Because each skill declares its trigger phrases, the right guidance surfaces without my going to find it: "capture this pattern" pulls up the capture workflow, "organize commits" pulls up the git method, and whatever else I hit pulls up whatever matches. I'm not searching a filing cabinet; the cabinet hands me the right drawer. The compounding comes from the connections, not the count. A well-integrated skill might reference a few related skills, a couple of documents, a command, and several trigger scenarios, and every one of those links gets stronger when I improve the skill. Loosely connected skills just pile up in a folder. Densely connected ones get reused, because each is reachable from several others, so expertise carries across projects instead of resetting each time. --- ## Conclusion Pattern capture works because of the discipline around it: search before creating, extend before adding, connect as you go, and validate so each skill earns its keep. Do that and new problems start pulling up the right guidance on their own. That's the point where your expertise stops being something you have to remember and becomes something your tools reach for. The value was never in collecting more patterns. It's in building a system where they hold each other up. If you want to start, run your next worth-keeping discovery through all six moves, and make search-before-create the habit you never skip. The cost is fifteen or twenty minutes a pattern. The payoff is that your best insights stop evaporating.