A stale skill is worse than no skill

An Nguyễn Hoàng — Thu, 04 Jun 2026 07:26:21 +0000

While building a skill index I almost recommended a repo with sixteen thousand stars. Looked great. Then I checked when it was last touched: January 2023. Three years dead. If an agent had loaded its instructions it would have followed them confidently, and they're wrong now. That's the whole problem nobody talks about with these skill libraries.

If you've used Claude Code or any agent setup recently, you've seen the pattern. There's a folder of SKILL.md files, or an MCP registry, or some awesome-agent-skills repo, and the agent reaches into it when it needs to do a thing. Everyone is building the library. The library is easy. It's a folder of markdown.

The part nobody builds is the part that actually matters: how does the agent know which skill in the pile won't lie to it?

A skill is instructions an AI follows. Confidently. That's different from code. When code is wrong it crashes, loud, you notice. When a skill is wrong the agent just does the wrong thing and tells you it went great. So a stale or subtly-broken skill isn't neutral. It's negative. It produces a confident wrong answer instead of making the agent stop and think. No skill at all would have been safer.

I went looking for the existing solution and what I found was a hundred link lists. They tell you a skill exists. They do not tell you the one thing you need before you load it: can I trust this, and is it still true.

So I built the missing layer. It's called Skill Atlas. It's a public index of skills, but organized by job (the thing you're about to do, like "work on Upwork" or "build an MCP server" or "write Go" or "set up CI"), and every single entry carries three things a link list skips:

where it came from, and is that source reputable
a trust tier, A through D
a last_validated date, that an actual check happened, not the publish date

The tiers are simple. A is canonical, the official source, you trust it because the vendor wrote it. B is community-proven, high reputation and still maintained. C is useful but verify before you lean on it. D is caution, it's stale or unmaintained, listed on purpose so you don't waste an afternoon rediscovering it's dead.

The freshness part isn't optional, and the English repo is why.

That English repo from the top? Sixteen thousand stars makes it an easy B by the usual logic, maybe higher. The January 2023 last-push makes it a D. Stars said trust it. The date said run.

Same story with a famous interview-prep repo, around three hundred fifty thousand stars, hasn't been touched since last August, so it drops to C. Stars are a lagging signal. People star a thing once and never unstar it when it rots. Stars plus last-push tell the truth that stars alone hide.

That's the actual product. Not the list, the judgment about the list.

To keep it from rotting itself, there's a script that re-checks every source, liveness plus live star counts plus last-push, and a GitHub Action runs it monthly and opens an issue the moment a link dies. An entry that hasn't been re-validated in six months gets treated as "verify before trusting" no matter what tier it claims. The atlas has to hold itself to the same bar it holds everything else, or it becomes the exact thing it warns about.

One more thing that surprised me while building it. For some jobs there is no good public skill, and the honest move is to say so. "How to win on Upwork" doesn't have a trustworthy public skill, because the real one is bespoke, it lives in your own head and your own win/loss history. So the atlas says that out loud instead of padding the slot with generic junk. The whole model is: find the good public starting point, then fork it private and make it yours. The public layer is the floor, not the ceiling.

It's 34 jobs right now. Backend stuff mostly, because that's what I do (Go, Postgres, docker, observability, API design, auth, the usual), plus the agent-specific ones (MCP, prompt engineering) and a few soft ones (interviews, careers). MIT, and it installs as a skill itself so your agent routes to the right vetted entry at the start of a task.

Repo's here if you want to poke at it: https://github.com/luongs3/skill-atlas

The question I actually can't answer yet, and the reason I'm posting this: what other signal would make you trust a skill before loading it? Stars and last-push are what I have. They're not enough. Install counts maybe, but those lie too. If you've got a better trust signal I want to hear it.

I gave my coding agent root on my VPS so it would stop making me deploy by hand

An Nguyễn Hoàng — Tue, 02 Jun 2026 03:38:43 +0000

Last week I built a little dashboard with Claude. Took maybe ten minutes. Then I spent the next hour trying to get it online.

ssh in, install docker, write a Dockerfile, set up nginx, run certbot, certbot fails, read the log, oh the DNS hasn't propagated, wait, run it again, open port 443, realize ufw was blocking it the whole time. By the time it was live I'd forgotten what the app even did.

I've done that maybe a few hundred times by now. I'm a backend guy, I'm fast at it. But fast at something boring still means doing the boring thing.

So at some point I just thought: the AI already wrote the app. Why does it stop right when the annoying part starts? Why doesn't it just deploy the thing itself?

The reason is it has no hands. The model can write you a perfect docker-compose file. It can't ssh into your box and run it. No connection to your server, nowhere to hold your key.

So I gave it hands. It's an MCP server, vibe-deploy. You hook it up once to a VPS you own, and then you just say "deploy this to notes.mydomain.com" and the agent containerizes it, ships it over ssh, sets up nginx, gets a real Let's Encrypt cert. Node, Python, Go, plain static. It figures out the stack and writes the Dockerfile.

No PaaS, no per-seat pricing, no free tier you'll outgrow. A $5 box runs a dozen of my projects and I own the whole thing.

The "you gave an AI root on your server??" reaction is fair, so: it runs locally, your key never leaves your laptop. I used a separate ssh key scoped to deploys, not my real one, and you should too. It checks the server host key before connecting and validates everything you pass it, because a deploy tool that pastes your input straight into a shell is a horror story waiting to happen. I had someone audit the security before I put it out. They found two real bugs. I fixed them.

It's free and MIT, on GitHub and npm as @cgnguyen/vibe-deploy. I built it because I wanted it. If you live in the same gap between "it works on localhost" and "it's online", try it and tell me where it breaks. The stacks it supports right now are the ones I needed. Next ones are whatever you ask for.

DEV Community: An Nguyễn Hoàng

A stale skill is worse than no skill

I gave my coding agent root on my VPS so it would stop making me deploy by hand