My Skills Became an Open Standard the Same Week I Archived Them

On 22 October, Anthropic handed Agent Skills to the Agentic AI Foundation, the Linux Foundation project that already looks after MCP and AGENTS.md. SKILL.md stopped being one company's file format and became an open standard.

Eight days later, I moved three of my own skills into a folder called skills-archive.

That timing looks like bad luck. It isn't. The standard and my archive folder are answering the same question: what is a skill actually for, now that the models are this good?

What actually changed on 22 October

Less than the headlines suggest, and that's the point.

According to coverage of the announcement, the donation covers the Agent Skills name, logo, GitHub organisation and the agentskills.io domain. Anthropic says more than 70 agent platforms already read the format, including ChatGPT, Cursor, GitHub Copilot and VS Code. Your existing SKILL.md files keep working. Nobody has to join anything to use them.

The format itself is small. A skill is a folder with a SKILL.md file in it, plus optional scripts and reference files. The specification requires two frontmatter fields, name and description. An agent loads only those two at startup and reads the rest of the file when a task matches.

So the news isn't "skills got better". It's "skills now belong to everyone, so whatever you put in them should be worth carrying between tools". That made me look hard at mine.

Why I wrote skills in the first place

I didn't write skills because they were elegant. I wrote them because I was tired.

Earlier models had much less context and much less memory. Every time I wanted to turn a draft into an X thread, or an article into an Instagram carousel, I had to explain the whole workflow again: the format, the voice, the file paths, the rules I'd learned the hard way. Putting it all in CLAUDE.md wasn't enough to make it stick.

So I wrote it down as skills. Lots of it.

By June I had three content skills doing most of the work:

Skill	Job	Size
koriigami-write-article	Research, outline, draft, humanize, then hand off to the posting skills	498 lines
koriigami-post-x	Turn a finished article into a post or thread, plus two quote tweets	417 lines
koriigami-post-instagram-kagadmodyaa	Turn an article into carousel slides in the studio's design system	805 lines

That's about 11,500 words of instructions. The writing skill even chained into the others: its step 5.7 offered to run the Instagram skill when the Reddit posts were done. I had built a workflow engine out of markdown files, because the model couldn't hold the workflow in its head.

What changed: the model can hold the workflow now

I now run Opus 5.5 on high effort as the orchestrator. It plans, makes the design calls, and keeps track of what happens next. It holds a whole content workflow in context without me spelling it out step by step.

When I restructured my content folder this week, the 11,500 words of skills turned into two short documents: a strategy file (who I write for, what channels I use, how often) and a CLAUDE.md that explains where things live. The model reads those, asks me what it needs, and does the rest.

The skills had been doing two different jobs, and I hadn't noticed:

1. Remembering the workflow. Which step comes next, what the output should look like, what to check.
2. Doing a repeatable job. Producing the same kind of output, the same way, every time.

A strong orchestrator makes the first job unnecessary. It doesn't make the second one go away.

The skills that stay

Most of the skills I still use do implementation work: building and updating parts of a project, or updating the artifacts I track my work in. I run most of them on Sonnet 5.5, not Opus.

That's the split that makes sense to me now:

• Opus 5.5, no skill: planning, judgment, design decisions, deciding what to do next. These change every time, so writing them down as fixed steps makes them worse.
• Sonnet 5.5, with a skill: jobs where I already know exactly what "done" looks like. The skill is a recipe, and a cheaper, faster model follows a good recipe just fine.

The one new skill I wrote this week fits that pattern. It's called /radar: it scans recent news for my content pillars, writes a dated note in a fixed format, and suggests what's worth posting about. Same inputs, same output shape, twice a week. That's a skill.

Deciding which of those news items is worth an article, and what I actually think about it? That's not a skill. That's me and the orchestrator.

Checking my files against the standard

If skills are now portable, the ones I keep should follow the spec. So I checked my three archived skills against it.

Only one of the three was clean. koriigami-write-article uses just name and description, which is exactly what the spec asks for.

The other two had habits I'd picked up along the way:

• koriigami-post-x lists allowed-tools as a YAML list. The spec describes it as a space-separated string, and marks the field as experimental.
• koriigami-post-instagram-kagadmodyaa adds its own top-level type and version fields. The spec has a metadata block for extra information like that. It's also 805 lines long, where the spec recommends keeping SKILL.md under 500 and moving detail into separate reference files.

None of this broke anything in Claude, which is part of the problem. A tool that tolerates your quirks doesn't tell you they're quirks.

I should be honest about the bigger gap. I've only ever run my skills in Claude. I haven't loaded one in Codex, Cursor or anything else, so I can't tell you what transfers cleanly and what doesn't. That's the next thing I'm testing, with /radar first, because it's small and I use it every week.

What I'm changing

1. Workflow and judgment go in plain documents, not skills. A strategy file and CLAUDE.md, read by a model that's good enough to use them.
2. Skills are for repeatable jobs. If I can't describe what "done" looks like in advance, it isn't a skill yet.
3. Repeatable jobs run on Sonnet 5.5. Opus plans; Sonnet executes the recipe.
4. Every skill I keep follows the spec. name and description up front, anything extra under metadata.
5. No portability claims until I've tested one. If a skill only works in one tool, it's a prompt with a filename.

The standard didn't make my old skills obsolete. Better models did. What the standard did was make me ask which of my skills I'd bother taking with me to another tool. For most of them, the honest answer was none. For the few that are left, it's all of them.