I Mined My Own Claude Code Config Files. Here's What I Found.
SubscribeSign in
I Mined My Own Claude Code Config Files. Here's What I Found.<br>After months of AI-assisted development, your config files are hiding a pattern library. Here's how to extract it.
James Cruce<br>Jul 01, 2026
Share
Article voiceover<br>0:00
-11:06
Audio playback is not supported on your browser. Please upgrade.
After months of using Claude Code, I had a confession to make: I had no idea what was in my own config files anymore.<br>A global CLAUDE.md. Ten project memory indices. A hundred individual memory files. Twenty-three project-level CLAUDE.md files. Eleven custom command files. Six rules files scattered across projects. Every one of them contained something I'd had to explain to Claude more than once. A workflow I repeated, a mistake that burned me, or a preference I'd had to correct. But none of it was organized. None of it was searchable. None of it was reusable in any deliberate way.<br>So I ran an experiment. I asked Claude to mine the entire thing.<br>The Setup
The premise was simple: if I've been writing instructions to Claude for months, those instructions should contain patterns. The same workflows keep showing up. The same preferences get stated and restated. The same procedures get encoded in different files for different projects.<br>What if I treated my own config files as a dataset?<br>The goal: find every pattern that appeared in two or more source files, group them by domain, and generate a structured SKILL.md runbook for each one.<br>Source files to read:
The 80+ source files, grouped by type.<br>`~/.claude/CLAUDE.md` (228 lines of global instructions)
All `MEMORY.md` index files across project memory directories
All individual `memory/*.md` files (about 100 of them)
All project `CLAUDE.md` files (23 across active projects)
Custom commands in `.claude/commands/*.md`
Rules files in `.claude/rules/*.md`
That's roughly 80+ files and several thousand lines of accumulated AI instructions.<br>What's Actually Going On
Here's the thing about Claude Code config files that took me a while to internalize: they're not documentation. They're not notes to self. They're a pattern library in disguise.<br>Every `feedback_.md` memory entry represents a correction I had to make more than once. Every `project_.md` entry encodes context that was load-bearing enough to write down. Every custom command I built was a workflow I ran often enough to automate.<br>As The Geek Learns is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Subscribe
The problem is that none of it is explicit. The patterns are implicit in the files. You wrote them under pressure, one at a time, solving immediate problems. You weren't thinking, “This is the third time I've explained the auto-merge workflow." You were just... explaining it again.<br>Skill mining makes the implicit explicit. It takes the accumulated knowledge in your config files and surfaces the signal: here are the things you keep doing, and here they are, written down properly so you can actually use them.<br>The Process
The mining session had four steps.<br>Step 1: File discovery. Find every source file using `find` and `wc -l`. List them. Count the lines. This alone is revealing—seeing 228 lines in your global CLAUDE.md and realizing you've written that many rules for yourself is a moment.<br>Step 2: Read everything in parallel. All MEMORY.md index files first, then the largest individual memory files, then project CLAUDE.md files, then custom commands and rules. Read them all, not to understand each one, but to see what keeps showing up.<br>Step 3: Build the frequency table. For each pattern identified, track what's the pattern, how many files mention it, and which files. The threshold is two occurrences. If a workflow or preference appears in two or more places, it deserves a dedicated runbook.<br>Step 4: Write SKILL.md files. One per pattern, grouped by domain, with a consistent structure: name, description, trigger conditions (when to use it), step-by-step instructions, and notes for edge cases.<br>What We Found
Twenty-two patterns with two or more occurrences across the 80+ files. Here's the frequency table:<br>The top tier (6 occurrences each) had four patterns: the Ironclad Workflow (my 4-phase dev process: Plan-Execute-Verify-Ship), gstack skill routing, the ClaudeClaw agent architecture primitives, and the Cortex memory tagging system. These showed up in six different files each. They're the backbone of how I work.<br>Below that: conventional commits (5 files), the ASTGL publishing pipeline (5 files), auto-merge PRs (4), secrets management via pass-cli and Keychain (4), the Resist and Rise editorial workflow (4 command files defining a complete journalism process), and the ACA Council product pipeline (4).
Behind ASTGL: How I Built an Autonomous AI Product Team That Ships Without Me<br>James Cruce<br>Apr 3
Read full story
Then a cluster of patterns that...