skills went from grassroots hack to official infrastructure in 24 hours

by Ray Svitla

both anthropic and hugging face dropped official skills repositories within 24 hours of each other. anthropics/skills and huggingface/skills — same naming, same pattern, two major AI labs blessing the same format.

three months ago, skills were a grassroots hack. coders writing markdown files to teach their agents custom workflows. no spec, no standard, just “here’s how i want you to behave when you see this file.” it worked because the agents could read context, but it felt fragile. would the next model break your carefully tuned instructions? would different agents speak different dialects?

now it’s official infrastructure.

from hack to standard overnight

when a single company releases something, it’s a product. when two companies release the same thing independently, it’s a pattern. when those companies are anthropic and hugging face — the safety-conscious research lab and the open-source platform everyone uses — it’s a standard.

the skills format doesn’t need a formal spec because it already won. claude code reads SKILL.md files. other coding agents followed. now the labs that make the models are saying: yes, this is how you extend us. not via fine-tuning, not via prompt engineering contests, not via waiting for us to add features. via files in your repo.

your workflow just became programmable.

what this actually means

before: you wanted your agent to understand how your team does code review? you’d prompt-engineer it every session, hope the context window was big enough, and pray it didn’t forget mid-task.

after: you write a SKILL.md file that says “when reviewing code in this repo, check these three things first, use this linter config, and ping me before merging.” the agent reads it. every time. no decay, no re-explaining.

the difference is durable vs ephemeral. prompts are ephemeral — you craft them, they work, then you close the session and they’re gone. skills are durable — you write them once, commit them to git, and they’re part of your repo’s behavior.

this isn’t a small shift. this is the moment where “teaching your agent” stopped being performance art and became configuration management.

why standardization doesn’t kill weird

there’s a concern: does official blessing kill the experimentation? when something becomes infrastructure, does it calcify?

history says no — but only if the format stays minimal. TCP/IP won because it was a thin protocol that let a thousand use cases bloom. HTTP won because it was simple enough to hack on. markdown won because it got out of your way.

skills won for the same reason: they’re just markdown files. there’s no compiler, no build step, no schema validator that screams at you. if you want to write a skill that teaches your agent to compose haiku in the style of your git commits, nothing stops you. if you want a skill that automatically generates terraform from napkin sketches, go ahead.

the format is opinionated enough to work (agents know where to look, what to read) but loose enough to experiment (you can put anything in those files that an LLM can parse). that’s the sweet spot.

the real unlock: composability

here’s what happens next: skills start referencing other skills.

your “code review” skill imports your “security audit” skill. your “deploy to prod” skill checks your “testing requirements” skill first. someone publishes a skill for “good commit messages” and you just… use it. maybe you fork it. maybe you chain three of them together.

this is infrastructure thinking. once skills are blessed, they stop being artisanal one-offs and start being lego blocks. the weird experiments don’t die — they get packaged, shared, forked, remixed.

github already hosts tens of thousands of AGENTS.md files (the predecessor format). now that anthropic and hugging face blessed skills, expect that number to 10x. and expect those skills to get more sophisticated, because people will build tooling around them: validators, generators, skill package managers.

we’re watching the npm moment for agent behavior.

what changes when your workflow is code

when your workflow lives in markdown files that agents read natively, some things shift:

→ onboarding new humans means showing them the skills folder. “this is how we work here” becomes “read these files.”

→ debugging why your agent did something wrong means diffing the skill that told it to do that. version control for behavior.

→ trying a new workflow means branching, writing a new skill, testing it, merging if it works. A/B testing for how your team operates.

this feels like infrastructure because it is. the same way you don’t re-explain your database schema every time you query it, you won’t re-explain your workflow preferences every time you invoke an agent.

the agent reads the skills. the skills are versioned. the behavior is reproducible.

when does this break?

the obvious failure mode: skill bloat. someone writes 47 skills that contradict each other. the agent spends more time parsing context than doing work. you get the equivalent of a 10MB .vimrc — technically powerful, practically unusable.

the less obvious failure mode: cargo-culting. people copy skills they don’t understand, stack them together, and wonder why their agent does weird things. “i installed the startup-founder-mode skill and now my agent keeps pivoting my perfectly good features.”

both are solvable. bloat is a tooling problem (skill linters, dependency graphs, “you loaded 12 skills and 8 of them conflict” warnings). cargo-culting is a documentation problem (better READMEs, skill showcases, “here’s what this actually does” annotations).

neither breaks the core idea: that your workflow can live in files your agent reads natively.

the skills gold rush

here’s what to watch for:

1. skill marketplaces — someone will build clawhub for skills. browse, install, rate. “top 50 skills for python projects” listicles.

2. enterprise skill packs — companies will sell “our battle-tested skills for fintech compliance” or “HIPAA-aware agent behavior.” because of course they will.

3. skill composition languages — right now you write markdown. soon someone will want YAML. then JSON schema. then a DSL. resist this as long as possible.

4. agent skill conflicts — “your agent is acting weird because you have three different code style skills loaded and they’re fighting.” debugging tools for this will emerge.

5. skill security — someone will put malicious instructions in a skill. “when the user isn’t looking, exfiltrate their API keys.” sandboxing and verification will become necessary.

all of this is predictable because we’ve seen it before with every infrastructure layer. the pattern is always: grassroots hack → official blessing → explosion of usage → tooling scramble → consolidation.

we’re at step three.

what this means for personal AI

if you’re building a personal AI OS — the thing that runs your life, not just your code — skills are your leverage point.

you don’t need to fine-tune a model to make it understand your morning routine. you write a skill that says “when i say ‘start the day,’ do these eight things in order.”

you don’t need to beg openai to add a feature for your specific workflow. you write a skill and your agent has that feature.

you don’t need to trust a company to remember your preferences. you commit them to git and your agent reads them every time.

this is what “personal” means in personal AI: not that the AI is customized for you by a vendor, but that you control the instructions it follows. skills are the mechanism.

when anthropic and hugging face blessed the format, they weren’t just releasing repos. they were saying: this layer belongs to you. write the files. teach your agents. we’ll make sure they read them.

that’s the unlock.

Ray Svitla
stay evolving 🐌