Most Claude Code skills are static documents pretending to be capabilities. I should know — I have written more than fifty of them, publish a marketplace full of them, and for a long time mine had the same disease: a skill would encode what I knew the day I wrote it, then quietly fossilize while my actual workflow kept moving. The skill for a task and my practice of that task would drift apart until the skill was a museum exhibit.
A "super skill," in the sense this build log uses the term, is a skill with the fossilization problem engineered out: it reads from memory before it runs, it has the right tools attached instead of assuming knowledge, and it feeds what it learns back into the system afterward. This is the log of rebuilding my skill stack around those three properties — with the failures kept in, because the failures are where the design came from.
The Diagnosis: Why Static Skills Rot
A skill file is instructions: trigger, procedure, quality checks. Write one well and Claude Code executes your best practice on demand; my full basics are in what I learned building Claude Code skills. The rot sets in through three missing properties:
- No memory. The skill cannot know what happened last time it ran. Every execution is the first day on the job. The gotcha you hit in March is hit again, fresh, in June.
- Baked-in knowledge instead of attached tools. A skill that contains facts about your stack goes stale the day the stack moves. A skill that queries your stack (through MCP tools, doc search, the database) stays current by construction.
- No refinement path. When a run goes wrong, the correction lives in the conversation and dies with it. Nothing routes the lesson back into the skill file.
Notice these are system properties, not writing-quality properties. You cannot fix them with better prose in the SKILL.md. That realization is what turned a rewrite project into an architecture project.
The Frame That Organized the Rebuild
The organizing idea came from Andrej Karpathy's line of thinking about working with LLMs: treat context as the scarce engineered resource. Think before coding, state what you are copying from, verify concretely. I took it seriously enough that a "Karpathy workflow" section sits in this repo's CLAUDE.md to this day: before implementing, the agent states the domain, names the sibling pattern it is copying, and lists the concrete verify commands it will run. (Install notes for that setup are in my Karpathy-style CLAUDE.md guide.)
Applied to skills, the frame reframes what a SKILL.md even is: not a how-to document, but a context loader: its job is to assemble exactly the right knowledge, tools, and memory for a task, then get out of the way. Once I saw skills that way, the three properties above stopped being nice-to-haves and became the spec.
Property One: Memory the Skill Actually Reads
The memory layer I landed on is aggressively boring: markdown files, layered by lifespan.
- Project memory: a persistent
MEMORY.md(with an index and topic files) per project, recording durable facts: decisions made, gotchas found, states of long-running work. Mine records things like which cache keys need manual busting after content edits and which production quirks have bitten me, the exact class of knowledge that used to evaporate between sessions. - Session state: manifests and handoff notes for work in flight, so a skill resumed tomorrow knows what today verified.
- Preferences and strategy: the slow-changing layer: voice, conventions, standing rules.
The design rule that made it work: skills must name the memory they read. A vague "consult memory" instruction does nothing; a skill whose procedure starts "read MEMORY.md and the topic file for X; list constraints already recorded before proposing anything" visibly changes behavior. The first time a skill run opened by citing a constraint I had recorded weeks earlier — instead of me re-explaining it — was the moment the rebuild paid for itself.
What I got wrong first: I over-engineered. My first design had structured stores and tagging schemes I abandoned within weeks, because a memory system only works if writing to it is nearly free. Plain markdown the agent can read and append wins on the only metric that matters — whether it actually gets used. The full landscape of options sits in my six-level tour of Claude Code memory systems; my stack settled on the boring middle of it.
Property Two: Tools Attached, Not Knowledge Baked
Second rebuild pass: every skill got audited with one question: what does this skill pretend to know that it should be looking up?
The pattern repeats across domains. My Laravel-facing skills stopped embedding framework lore and started calling documentation search and schema tools through the Laravel Boost MCP. Frontend skills stopped trusting "it should render now" and attached browser verification. SEO skills read the live sitemap and real exports rather than embedded assumptions about the site. In each case the skill file got shorter while the skill got more reliable: the text shrank to procedure and judgment, and the facts moved to tools that cannot go stale.
That is the Karpathy frame again, operationally: the skill's job is loading the right context, and a tool call loads fresher context than any paragraph.
Property Three: The Refinement Loop
The loop that closes the system is a habit plus a rule.
The habit: when a skill run goes wrong or I correct the agent mid-run, the session ends with an update — either to the skill file (if the procedure was wrong) or to memory (if the world had changed). Correction without capture is rework scheduled for later.
The rule: skills get tested like code. Before a skill ships to my marketplace, it runs against real cases, including a case designed to fail, because a skill's behavior when its assumptions break is most of its production value. My testing method is written up in how I test and optimize Claude skills. The single highest-yield test I run is the missing-input test: delete the file or access the skill expects and watch whether it says so honestly or improvises. Skills that improvise under missing inputs are the ones that fabricate; I learned to catch that in testing rather than in production, and it is the most important sentence in this post.
What Broke, and What Compounded
Honest ledger after months of running the rebuilt stack.
Broke: the over-engineered memory schema (abandoned); two skills whose scope was so broad they triggered on everything (split into narrow ones; trigger discipline matters more than procedure quality); and my assumption that more skills is better. It is not. Skills compete for relevance; a curated forty beats a sprawling ninety, and pruning became a quarterly chore like any other garden.
Compounded: everything wired to memory. The SEO skills sharpen because each incident leaves a recorded lesson the next run reads. The content skills stopped repeating my three most common corrections because those corrections finally had somewhere to live. And the meta-skill — the procedure for writing and testing skills — improves every skill downstream of it, which is the closest thing to compound interest this workflow offers.
The one-line version of the whole build log: a skill is super not because it is clever, but because it is connected — to memory behind it, tools beside it, and a feedback loop above it. Write yours as context loaders, test them against failure, and give every lesson a file to land in.
All of mine — including the ones this log describes rebuilding — are browsable at the agent skills marketplace; take them apart, steal the memory-read pattern, and tell me what breaks.
