Why You Should Stop Using Other People’s AI Skill Libraries
There are skill libraries on GitHub right now with 180,000 stars. Hundreds of contributors. Years of community effort baked in. Polished READMEs, structured folders, carefully named markdown files for every occasion.
And if you’ve been working with AI agents for any length of time, you’ve almost certainly cloned one.
Here’s the problem: two weeks later, you’re not shipping faster. You’re maintaining someone else’s system.
This post makes the case for building your own AI agent skill system from scratch — why it matters, how to do it in five steps, and why the developers who take this approach end up with something nobody else has.
What Is an AI Skill System — And Why Does Everyone Have One?
If you’re new to agentic development, a quick primer. A skill is a natural language prompt stored in a special file — usually a skill.md — that gives your AI agent persistent, reusable instructions. Skills sit inside a broader agent harness: the collection of prompts, configurations, scripts, and context files that shape how your agent behaves across a project.
Over the last couple of years, a handful of developers have packaged their skills into shareable libraries and published them publicly. Some of the most well-known include:
- Everything Claude Code by Afen Mustafa — one of the largest, with a heavy focus on memory, security, and sub-agent orchestration
- BMAD Method — enterprise-grade, modelled on a full software development lifecycle with roles like business analyst, product manager, and senior architect
- Superpowers — lighter weight, more accessible, popular with indie developers
- Gary Tan’s stack — highly opinionated, built around Y Combinator-style forcing questions
- Matt Pocock’s library — TypeScript-focused, advocates strongly for domain grounding and test-driven development
- Addy Osmani’s spec-first approach — structured around a spec, plan, build, test, review loop
These are all genuinely impressive pieces of work. The people who built them are experienced engineers who have been refining their approaches for years.
So why shouldn’t you just clone one?
The Cloning Trap
Here’s what actually happens when most developers discover skill libraries.
You find one with a massive star count. The demo looks great. You clone it, drop it into your project, and for about forty-eight hours you feel like you’ve unlocked a superpower.
Then reality sets in.
Half the skills don’t apply to your stack. A quarter of them conflict with how your team actually works. Some of the assumptions baked into the prompts are specific to the original author’s codebase, their preferred architecture, their tooling choices. You start tweaking things. You’re not using the library anymore — you’re maintaining a fork of it.
The deeper issue is this: these libraries were built to solve their problems, not yours. The skills inside them are the residue of someone else’s hard-won experience. When you clone the repo, you get the output without the context that made it valuable.
What a Skill Actually Is
Strip away the tooling, the front matter, the markdown formatting. Strip away the folder structures and the clever naming conventions.
A skill is just a repeatable answer to a recurring problem.
That’s it.
Which means a skill only has real value when you have already encountered the problem it solves. If you haven’t hit that wall yet, the skill isn’t helpful context for the model — it’s noise. It’s documentation for a problem you don’t have, consuming space in a context window that could be used for something that actually matters right now.
The developers behind the popular libraries built their skills after running into the same failures, over and over again, in their specific contexts. The library is the crystallised version of that experience. When you clone it, you skip straight to the crystal and miss everything that made it form.
How to Build Your Own Skill System in 5 Steps
This isn’t a new repository to follow. It’s a way of thinking. Here’s the process.
Step 1: Start With Nothing
Resist the urge to set up a skill system before you’ve started building. Use the native capabilities of your agent tool — ask mode, plan mode, build mode — and just work. The baseline capability of modern agents like Claude Code, Cursor, and Codex is genuinely strong enough to get started without any scaffolding.
Starting with nothing isn’t laziness. It’s data collection.
Step 2: Notice Where It Breaks
Your agent will fail. It always does. The question is how, and whether it fails in the same way more than once.
Maybe it keeps ignoring your project’s file structure conventions. Maybe it over-engineers the database layer every single time. Maybe it writes tests that technically pass but don’t actually test anything meaningful. When a failure repeats — that’s your signal. Write it down.
Step 3: Write the Smallest Possible Fix
Not a comprehensive skill. Not a framework. A short, specific correction aimed at exactly that failure mode.
Two or three paragraphs maximum. Plain language. No fluff.
Something like:
“When writing database queries in this project, always use the existing repository pattern in /src/data. Do not create new abstractions.”
That’s a skill. It’s small, it’s precise, and it was earned through an actual failure. It will do more for your workflow than a 300-line generic skill file copied from someone else’s repo.
Step 4: Watch It in Production
Use the skill across several sessions. Does it actually prevent the problem? Does it solve one thing but create confusion elsewhere? A skill that fixes one failure but bloats the context window and causes the model to misfire on something else isn’t a win — it’s a trade-off you need to see clearly before you commit to it.
Step 5: Prune Ruthlessly
Delete skills that are no longer relevant. Rewrite skills that have grown too long. Your skill system should get leaner over time as your agent improves and as your codebase matures — not heavier.
This is the part most developers skip. They keep adding and never subtract. The result is a context window full of outdated instructions that confuse more than they guide.
The Compounding Effect of a Bespoke Harness
Here’s why this approach matters beyond just individual productivity.
When you build your own skill system, every single skill is a documented lesson from your specific codebase, your specific team, your specific failure patterns. After six months, you have something nobody else in the world has — an agent harness that is precisely tuned to how you build software.
That compounds.
| Clone a Library | Build Your Own |
|---|---|
| Generic coverage | Precisely tuned to your codebase |
| Maintained by others | Owned entirely by you |
| Starts full, stays full | Starts lean, gets leaner |
| Anyone can do it | Takes discipline — and shows |
| Stagnates after the clone | Compounds with every project |
The developer who has spent a year thoughtfully building and refining their own system is not running the same workflow as someone who cloned a popular repo. They are operating at a fundamentally different level of precision. And in a world where everyone has access to the same AI tools, that precision is a genuine professional differentiator.
The Hidden Cost Nobody Talks About
Most of the content around skill libraries treats them as pure upside. More skills, more capability, more productivity.
The reality is more nuanced. Skills are a liability as well as an asset.
They go stale, exactly like documentation. The codebase evolves, the agent tooling improves, the project requirements shift — and suddenly a skill that was helping six months ago is giving the model outdated information it can’t reconcile with what it’s seeing in the files.
They pollute the context window. Every skill you load is competing for space with the actual code, the actual task, and the actual conversation the model needs to reason about right now. Bloated skill systems can actively degrade performance.
And they require ongoing maintenance. Every skill you introduce is a skill you’ll need to revisit, refine, or eventually delete. In traditional software development we talk about technical debt. In agentic development, skill debt is the equivalent — and it’s just as real.
This doesn’t mean don’t use skills. It means be deliberate about which ones you introduce, keep them as small as possible, and review them regularly.
What You Can Still Learn From Popular Libraries
This isn’t an argument to ignore the popular skill systems entirely. There is genuine craft inside all of them, and studying them is worth your time.
Addy Osmani’s spec-first thinking — the idea of working through exactly what you’re building before you start building it — is a sound principle regardless of what tools you’re using. Matt PCO’s emphasis on domain grounding, making sure the agent has a deep understanding of the project’s data model before it writes any code, is something worth internalising. Gary Tan’s forcing questions approach — sitting down and asking hard questions about what you’re building and why before a single line is written — is arguably the most underrated idea in the entire space.
The key is to treat these as inspiration, not installation.
Read through the libraries the way you’d read a senior developer’s blog post. Extract the principle. Then decide whether that principle applies to your situation, and if it does, write your own version of it from scratch, in plain language, specific to your context.
Don’t copy-paste someone else’s thinking into your context window and call it a skill system.
Key Takeaways
- Skills are just repeatable answers to recurring problems — if you haven’t hit the problem yet, the skill is noise
- Cloning a popular skill library gives you residue without experience — the output without the context that made it valuable
- Only write a skill after the agent has already failed you — failure is the signal, the skill is the fix
- Keep every skill as small as possible — two to three paragraphs, plain language, aimed at one specific failure
- Prune regularly — your system should get leaner over time, not heavier
- Skills are a liability as well as an asset — they go stale, pollute context, and require maintenance
- Study popular libraries for principles — extract the idea, write your own version, don’t clone
- A bespoke harness compounds — six months of deliberate skill building creates something nobody else has
Conclusion
The AI tooling space moves fast. New libraries, new frameworks, new repositories with enormous star counts appear every few weeks. It is genuinely difficult to keep up, and the pressure to adopt the latest popular system is real.
But the fundamentals haven’t changed. Build small. Learn from failure. Document what you know. Iterate. These are the same principles that have driven good software development for forty years, and they apply just as cleanly to building an AI agent harness as they do to anything else.
The best skill system you’ll ever use isn’t on GitHub. It’s the one you build yourself, one earned skill at a time.
If there’s one thing worth taking away from all of this, it’s simple: next time your agent fails in a way that frustrates you, don’t open GitHub. Write one sentence describing what went wrong. Write two or three sentences telling the agent what to do differently next time. Save it.
That’s your first skill. That’s where every great system starts.
