The short version
I built my own set of AI agent skills — xskills, a pipeline of small workflows (x-plan → x-epic → x-decompose → x-implement, plus x-review, x-roast, x-humanize, x-commit) — and I think you should build your own too.
Not because mine is good. Because the argument against it is usually wrong.
The standard objection is “don’t reinvent the wheel” — and it is a good objection when the goal is to ship a product for other people. It is a bad objection when the goal is to learn how the wheel works, to own the wheel, and to have a wheel that fits your car. Everyone who wrote PHP in 2003 built a framework anyway, and everyone who ships games has sat through the buy-versus-build engine argument. Both crowds were told they were wasting their time. Both crowds were partly right, and mostly wrong.
This is the case for building your own, the bill for building your own, and the conditions under which I would tell you not to.
Two rooms full of people who already did this
Every PHP developer built a framework
MIOLO was created in 1999 at UNIVATES, a community university in Lajeado, Brazil, as the foundation of an academic management system. It is described by the people who recovered it as “one of the first PHP frameworks ever built” — before Rails, before Django, before Symfony, before Laravel. Rasmus Lerdorf, who wrote PHP, had worked in Porto Alegre about 120 km away, and in 2001 he spent two weeks in Lajeado helping shape it.
Here is the part worth noticing: MIOLO lived in a Subversion repository for twenty years, accumulated 9,538 revisions and 31 contributors, and was never on GitHub at all. Most of its comments are in Portuguese.
Now multiply that by every university, agency and solo developer of the era. No package manager, no PDO, no Stack Overflow, dial-up connections, deployments by FTP: if you wanted a project skeleton that fit how you worked, you wrote it. A thousand private frameworks existed, and almost none of them survived.
That is the honest shape of the analogy. The 2000s PHP ecosystem was full of reinvention, and it consolidated — Symfony (2005), CakePHP (2005), CodeIgniter (2006), Laravel (2011) — into a handful of shared tools. Consolidation was the right end state. But it arrived years later, built on the experience of everyone who had written their own first.
Every game developer argued about engines
In 2011, Yossarian King — then CTO of Blackbird Interactive, previously 15 years at EA — wrote a piece that has aged extremely well. His team chose to buy. His framing of the trade-off is the cleanest one I have found:
Clearly building your own engine gives you the ultimate in control and customization — just remember that you have to build it before you can extend it. With a third party engine you can jump straight to the extensions.
His article also has a section headed “You May Choose To Build”, and his reasons are not all technical. One of them is simply that it is satisfying and you learn something. That is a legitimate reason. It is just not the reason you tell your investors.
Thirteen years later, at GDC 2024, Jordan Graham — formerly of EA’s Sims team, now running BleachKitty — made the opposite call and defended it:
It is generally cost-effective in the long term because you’re investing in your own company, in your own tech, in your own world. You build the thing that you want and nothing else.
The method matters more than the verdict. Graham is explicit that you should not disappear for two years to build an engine: “you make your game and you extract stuff out as necessary.” Build inside the work, then pull the tool out of it.
The counter-case is real, and it is well argued in Real reasons (not) to build custom game engines. Learning Unity or Unreal is a far smaller investment than writing your own engine from scratch. A stock engine hands you automatic knowledge — institutional solutions to problems other people already paid for — plus shaders, assets and upstream updates you get for free. With a custom engine, the article says flatly, you are constantly reinventing the wheel.
Both things are true at the same time, which is why the useful question is never “build or buy” in the abstract. It is: where is my edge, and how often does this friction repeat? You hire Unreal for rendering. You build the thing nobody else has.
What “build your own” means in 2026
Agent Skills are new enough that most people have not noticed the bar moved.
Anthropic launched Agent Skills on October 16, 2025, and published the format as an open standard on December 18, 2025. The format is almost aggressively simple: a skill is a directory with a SKILL.md file in it.
x-plan/
├── SKILL.md # required: YAML frontmatter + instructions
├── scripts/ # optional: executable helpers
├── references/ # optional: docs the agent reads on demand
└── assets/SKILL.md starts with YAML frontmatter carrying two required fields, name and description, and optional ones like license and compatibility. At startup the agent preloads only every installed skill’s name and description; if a task looks relevant it loads the full SKILL.md, and only if it needs more does it open the files the skill points to. That is the whole trick: progressive disclosure.
There is also already a skill-creator skill that writes the folder and the frontmatter for you — Claude asks about your workflow and generates the scaffolding.
So the cost of entry collapsed, and then the timing got interesting. The standard is roughly nine months old. That means:
- The shared catalogue is thin. Nobody has pre-built the skill library that matches your workflow, because the format barely had time to spread.
- Every skill you write is still a small novelty, not a solved problem.
- The first one is the expensive one. The tenth one is cheap, because you have learned what a good skill looks like for you.
Compare that to the PHP story: in 2003 there was nothing to reuse. In 2011 Laravel existed. In 2026, agent skills are in the 2003 window. That window does not reopen.
What building my own actually bought me
Fit. xskills has 24 skills in it as of September 2026 — 24 directories under skills/ in the repository, which you can count yourself (the published package is already further ahead; see the maintenance note below). Almost none of them are clever. x-commit enforces one-line conventional commits; x-roast reviews a document against a weighted rubric and a number; x-humanize rewrites prose to a B2 reading level and verifies the meaning survived. The pipeline exists because I kept doing those things by hand in a particular order. No general-purpose skill set is going to encode my order.
Ownership. The whole thing is MIT-licensed, dependency-free Node, and sits in one repository — github.com/lleqsnoom/xskills, published as @lleqsnoom/x-skills. If a skill is wrong I fix the file. There is no upstream to wait for, no licence to renew, no roadmap to lobby.
Compounding. Each skill makes the next one cheaper. x-plan produces a spec that x-epic consumes; x-epic produces layers that x-decompose slices into tasks; x-review and x-fix close the loop. I did not design that pipeline up front. I noticed that the third skill I built looked like the first two, and factored it.
Cheapness, now. The old objection to writing your own tooling was that tooling is a cost centre. Roughly: an engineer spends a week building a linter nobody asked for. That week is now measured in hours, because the agent writes and edits most of the code, and the skill itself is a markdown file you can iterate on in one sitting.
A better instinct. The most valuable output is not the skills. It is the reflex: this friction repeated three times, so it is a tool now. I notice the gap before I notice the tool.
What it cost me
This section is the one that usually gets skipped, so here it is in full.
Maintenance is on me, forever. Agent CLIs move fast. When a tool changes how it discovers skills, my skills are the ones that break, and nobody is patching them but me. The skills in agent frameworks get tested against each other; mine get tested against exactly one workflow, mine.
Isolation. There is no community to ask. If x-roast’s rubric weights are wrong, there is no issue tracker full of other people’s opinions — just my own judgement, which is the thing under review. In game-engine terms: I gave up the automatic knowledge.
The relief valve is the standard itself. Because SKILL.md is one format, a skill written for Claude Code runs in any of the clients that share it — the client list is the ecosystem I am missing locally, and publishing a skill is how a private framework gets a second reader. That is the convergence mechanism the PHP story eventually found, arriving on purpose this time.
Opportunity cost. Every hour in the skill repo is an hour not spent on the actual project. x-parallel exists partly as an apology for that, but the trade is real and I would be lying if I said the accounting always comes out positive.
The NIH trap. “Not Invented Here” has a name and a Wikipedia entry for a reason: groups over-value their own code and under-value everyone else’s. The piece calls it “the scourge of the software development culture”, then adds the twist — defenders argue the same tendency catalyses innovation. Both readings are true, and the failure mode is invisible from the inside. I re-solve solved problems more often than I would like to admit.
Quality gap. My skills are prototype-grade. There are no edge cases handled, no documentation, no error recovery. Prototypes only need to kind of work for the person who wrote them. The gap between “works for me today” and “works for a stranger tomorrow” — docs, error handling, an interface someone else can navigate — is what offlinemark calls the song-and-dance difference:
There is a mind-boggling effort difference between making a prototype product that provides value today, and productionizing that product for the mass market.
That is also the liberating part of his argument: the tools on the market are a tiny subset of the tools that could exist. If you only ever use the subset someone finished, you never see the rest.
Fragmentation. This is the PHP lesson. A thousand private frameworks is not a healthy ecosystem; it is a decade of duplicated effort that eventually got consolidated into four projects. Agent Skills are one format, but that does not mean my 24 skills and your 12 skills compose. Some of this work will turn out to have been wasted. Mine included.
And two small, honest examples from my own repository. The README still advertises “14 production-ready skills” while the folder contains 24. And when I checked, my local clone sat at version 4.0.0 while npm’s latest was 5.13.0 — I was about to describe my own tool from a months-old copy. Documentation and checkouts both drift when you are the only maintainer. That is the maintenance tax, in two lines.
How the learning actually happens
The reason to do this is not the artefacts. It is the loop.
You learn by building, not by consuming. You can operate a tool for years and never understand its failure modes, because a good tool hides them from you. The moment you write your own, the hidden decisions become yours: what does “done” mean here, what happens when the input is empty, what do I do when the model ignores the instruction. Those are the questions that teach.
The practice has real stakes. You are not writing a toy project for a tutorial. You are solving friction that you personally have, every week, which means the feedback is immediate and specific. If the skill is bad, you feel it the next time you use it.
The meta-skill outlives the skills. Notice friction → build a solution → critique it → iterate → share. That loop is what transfers. It works on agent skills today and it worked on shell scripts in 2010. Every skill you build makes the next one cheaper, because the pattern-matching gets faster.
Depth where you choose it. Every developer’s knowledge is a mile wide and an inch deep somewhere. Building your own tooling is a way to decide where the inch becomes a mile — and to do it in the layer you actually care about.
So should you build yours?
My honest answer is the same shape as Graham’s engine answer: yes, but not the way you think.
Build where friction repeats and fit matters. Not “I could build a better X.” Rather: “I do this exact thing three times a week, in this exact order, and the general tool fights me.” Repetition plus fit is the signal. Novelty is not.
Use existing tools for the commodity layers. Do not rewrite your linter, your formatter, or your test runner. Use the community’s. Build at your edge — the part of the workflow nobody else can see, because it is made of your habits.
Extract, don’t pre-build. Do not sit down to design a framework. Do the work, feel the friction, write the smallest skill that removes it, then notice the second one looks like the first and factor them. That is how xskills happened: one skill at a time, in the opposite order from a product roadmap. Graham’s engine rule applies to prompts: build the game, not the engine.
Concretely, that is a directory and one file:
my-skill/
└── SKILL.md---
name: my-skill
description: What it does, and when the agent should reach for it.
---
# My skill
1. Do the first thing.
2. Then the second — and stop when <check> passes.The description is the load-bearing field, because it is the only part loaded before the agent decides to open the skill: if it does not name the trigger, the skill never fires. Write it after you have used the skill twice, not before.
Start now, because the window is young. The format is months old, the tooling is nearly free, and the first skill is the expensive one. The longer you wait, the more someone else’s library will fit you, and the less point there is. Right now, nothing fits. That is the opportunity.
And sometimes the answer is no. Stop and use the existing thing when any of these is true:
- You are on a deadline and the existing tool clears the bar.
- The layer is commodity — formatting, linting, test running. There is nothing of yours to express.
- You would be building it to avoid the actual work. That is procrastination with a build log.
- You are doing it because the JSX of someone else’s tool annoys you, not because it fails. Annoyance is not friction.
- Nobody, including you, will maintain it. An abandoned private framework is not a learning artefact; it is the PHP story’s worst ending.
Nobody needs your 2026 framework. They need you to know why you built it.
What I would tell a younger me
The PHP developers who wrote their own frameworks in the early 2000s mostly do not have those frameworks anymore. They have the judgement that writing them produced — the understanding of routing, templating and persistence that later made them good at choosing between Symfony and Laravel instead of just importing one.
xskills is my framework. It might get superseded the way MIOLO’s ideas were superseded. That is fine. The repository is the by-product; the instinct is the asset.
So: pick the thing you do three times a week and hate. Write the smallest skill that fixes it. Then write the second one.
The wheel really does get better when someone reinvents it. You do not see anyone driving on stone tyres.
References
- MIOLO — github.com/wprigollopes/miolo — one of the first PHP frameworks (1999, UNIVATES, Brazil); the source for the recovery story, the 9,538 revisions and the Rasmus Lerdorf connection.
- “Not Invented Here” — qualityandinnovation.com, 2009 — the source for the NIH definition and its defenders.
- Yossarian King, “Why On Earth Would We Write Our Own Game Engine?” — gamedeveloper.com, December 2011 — control vs. time-to-extend.
- Jordan Graham, “A Case for Making Your Own Engine” — GDC 2024 write-up, March 2024, and the session (listed in the GDC Vault as Rez Graham) — ownership, and extract-don’t-pre-build.
- “Real reasons (not) to build custom game engines” — gamedeveloper.com — automatic knowledge, upstream updates, and the Noita counter-example.
- Andrew Schmelyun, “Build your own tools (even if you reinvent the wheel)” — aschmelyun.com, May 2025 — the woodworker’s jig, and the stone-tyres line.
- offlinemark, “Learn to build your own tools” — offlinemark.com — prototype quality is enough, and why the market’s tools are a subset of the possible ones.
- Anthropic, Agent Skills — launch announcement, October 16, 2025, and the engineering deep-dive — the format, progressive disclosure, and
skill-creator. - Agent Skills specification — agentskills.io/specification.md — the directory layout and
SKILL.mdfrontmatter fields. - Anthropic makes Agent Skills an open standard — SiliconANGLE, December 18, 2025 — the date the format went cross-platform.
- xskills — github.com/lleqsnoom/xskills and npm — the skillset this article is about.