If you use AI coding tools with any seriousness, you already have a prompt stash. Maybe it’s a Notion page, maybe a scratch file that never closes, maybe — like the setup Nolen Jonker described on XDA — it’s a pile of sticky notes. And maybe, like him, you never questioned it because it worked. The prompts were never the problem. What his write-up accidentally exposes is that a prompt stash is really a routing problem: you’re the router, and you’re bad at it.
The stash works until you count the steps
Run the arithmetic on any one reuse of a saved prompt. Remember you have one that fits. Alt-tab to wherever it lives. Scan your own stack to find the right one. Paste it in. Adjust it to the task at hand. Four manual decisions before the tool does any work — and that’s the good path. The bad paths are worse: you tweaked the prompt in a session last month and the saved version is now stale, so you paste something that no longer matches your workflow. Or you forgot you’d already solved this, and quietly re-solve it from scratch. A stash scales with your attention, and your attention is the one resource that doesn’t scale.
What a skills file actually changes
Claude Code’s skills flip the model. A skill is a folder with a SKILL.md inside — personal ones at ~/.claude/skills/skill-name/, team ones in a project’s .claude/skills/ so they ship with the repo. At startup, Claude loads only each skill’s name and description, roughly 100 tokens apiece. When your message semantically matches a description, the full body gets pulled into context. Heavy material can live in reference files alongside SKILL.md, loaded only when the branch that needs them actually fires.
Three mechanics, and each one kills a specific stash failure:
- Semantic auto-invocation — you describe the task; the tool picks the skill. The alt-tab-and-scan step is gone.
- A ~100-token index — matching runs against tiny descriptions, not full prompt bodies, so a large library doesn’t bloat every session.
- Progressive disclosure — the deep detail loads only when the matching branch fires, so a rich skill costs almost nothing when idle.
There’s also a quieter win: one canonical copy per skill. When the prompt lives in the folder, the version you improved last Tuesday is the version that runs next time. Drift doesn’t die of osmosis — it dies because there’s nothing left to drift apart.
One branching folder, or many thin ones?
This is the design fork everyone hits, and the honest answer is “mostly thin, sometimes fat.” Thin skills — many folders, each doing one job with a tight description — route better, because there’s less overlap for the matcher to weigh. Their failure mode is descriptions that bleed into each other; “production-ready styled components with real content” and “lo-fi wireframes with grayscale rules” sound similar to a matcher and shouldn’t. Large skills — one folder, branches inside — suit tasks that share context, like UI work where wireframing, critique, and prototyping all lean on the same rules. Their failure mode is token bloat: you pay for branches you’re not using, which is exactly what progressive disclosure exists to fix. Move the heavy per-branch detail into a references/ file and point at it.
My default: start thin. Merge skills into one fat folder only when you catch yourself duplicating the same shared rules across three of them.
The description field is the entire router
Here’s the part nobody tells you, and the one edit with the highest return: most people write skill descriptions like documentation. “Generates low-fidelity structural HTML blueprints for interface planning” is technically accurate and routes terribly. The description should read like the sentence you’d actually type. If you’d say “wireframe me a login page,” the word “wireframe” had better be in that description. It’s a matching layer, not a spec — write it the way your fingers write messages at 11pm.
The pattern is bigger than Claude Code
If you run a homelab or IT for a small business, you’ve seen this exact shape before and probably built it badly, like I did. It’s a runbook index. The good version: a thin table of contents that lives wherever decisions happen, with the heavy procedure one hop away, fetched only when that branch fires. The bad version is every wiki page of SOPs nobody opened during the last incident — because during an incident, nobody routes manually either.
Skills files are just the first place the pattern got ergonomic. They live in the repo, so they’re versioned in git, reviewable in PRs, and shareable with a team without pasting prompts into chat. Your on-call colleague gets the same routing you do, for free, on their machine.
Your prompts were probably fine all along. The embarrassing part isn’t what was in the stash — it’s how many hours you spent being its router. Hand that job to the index. Keep your attention for the work.