Agent Skills Is Now a Linux Foundation Standard. Your MERN Repo Should Ship One

Every time I open a new agent session on one of my Express projects, I end up typing the same paragraph: "routes go in src/routes, validate with Zod, never touch the Mongo connection directly, run the tests before you tell me you're done." Agent Skills is basically the fix for that paragraph. And as of October 22, it's not just Anthropic's thing anymore.

Anthropic handed the Agent Skills standard (the name, the logo, the GitHub org and the agentskills.io domain) over to the Agentic AI Foundation, the Linux Foundation project that already looks after MCP and AGENTS.md. That changes who you're betting on when you write one. Let's talk about what actually happened, how to write a skill that works across tools, and the security bit nobody wants to think about.

What actually happened (and why you should care)

Quick facts, no hype:

• Agent Skills was one of four projects added to the AAIF at AGNTCon + MCPCon North America. The others were OpenAI's Open Responses, Hugging Face's OpenEnv and Alibaba's OpenSandbox. The foundation now hosts 10 projects, up from three when it launched last December.
• According to the announcement, more than 70 agent platforms have adopted the format since it was published in December 2025, including ChatGPT, Cursor, GitHub Copilot and VS Code. Around a million skills have been published so far. Those are vendor numbers, so take them with the usual pinch of salt.
• The spec is now maintained by engineers from Anthropic, Google, OpenAI and others, working as individuals. The roadmap talks about versioned releases, a formal proposal process and security guidance.
• The format didn't change. Any skill you wrote last month still works.

What this means for us: a skill is now closer to a package.json than to a vendor feature. You write it once, commit it to the repo, and whoever on your team uses Cursor, Copilot, Codex or Claude gets the same instructions. I've been building tooling around skills for a while (I wrote about my TUI package manager for agent skills earlier), and vendor lock-in was always the quiet worry. That worry is mostly gone now.

The anatomy of a skill (it's smaller than you think)

A skill is just a folder with a SKILL.md file in it. Scripts, templates and reference docs are optional extras that sit next to it.

The trick is progressive disclosure. At startup the agent reads only the name and description of every installed skill, which costs a few dozen tokens each. It loads the full body of SKILL.md only when the task looks relevant, and it opens the bundled files only when the instructions point to them. So you can install twenty skills without stuffing twenty pages of docs into every prompt.

The spec is strict about two fields and relaxed about the rest:

• name (required): 1 to 64 characters, lowercase letters, numbers and hyphens, with no leading, trailing or double hyphens. It has to match the folder name.
• description (required): up to 1024 characters. This is what the agent uses to decide whether to load your skill, so write it like a search query, not like a tagline.
• Optional: license, compatibility, metadata, and the experimental allowed-tools.

Writing a skill for your Express + Mongo backend

Here's one I actually use, cleaned up a bit. It teaches an agent how this codebase adds an endpoint:

---
name: add-express-endpoint
description: Use when adding or changing a REST endpoint in the Express API (src/routes, src/controllers, src/models). Covers Zod validation, Mongoose models, error handling and the required Supertest test.
license: MIT
metadata:
  owner: backend-team
  version: "1.2.0"
---

# Adding an Express endpoint

## Steps
1. Define the request schema in `src/schemas/<resource>.schema.js` with Zod.
2. Add the route in `src/routes/<resource>.routes.js` and wire `validate(schema)` before the controller.
3. Keep controllers thin. Business logic lives in `src/services/`.
4. Never call `mongoose.connect` anywhere except `src/db.js`.
5. Throw `AppError` from `src/lib/errors.js`. Don't call `res.status(500)` by hand.
6. Add a test in `tests/<resource>.test.js` using the template in `templates/route.test.js`.

## Before you say you're done
Run `npm test -- <resource>` and paste the summary line.

See `reference/error-codes.md` for the error code table.

A few things I've learned the hard way:

1. The description does the routing. "Helps with backend stuff" never fires. Name the folders, the libraries and the verbs ("adding or changing a REST endpoint").
2. Point, don't paste. The error-code table lives in reference/error-codes.md and only gets loaded when it's needed. Keep SKILL.md short.
3. One skill per job. I keep separate skills for add-express-endpoint, react-query-hook and mongo-migration rather than one huge "our-stack" skill. Smaller skills trigger more accurately.

This works the same way for your Python side. If you've got a FastAPI inference service sitting next to your Node API, give it its own add-fastapi-model-route skill and the agent will stop writing Express patterns in your Python code.

Where the folder lives depends on the tool (Claude Code reads .claude/skills/, for example), so check your harness's docs. The contents are what's portable.

The part nobody wants to hear: skills are a supply chain now

Portability works both ways. A bad skill used to be a Claude problem. Now it's a problem for every agent on your team.

The good news is that a recent public scan of 9,930 SKILL.md files from 277 GitHub repos found no malware. The less good news is that it flagged risky patterns, and two of them came up a lot: piping a download straight into a shell, and reading an agent's whole key file just to get one API key. None of it looked malicious. It's just the same sloppiness we spent ten years cleaning out of npm postinstall scripts.

So treat skills like dependencies. Here's a tiny zero-dependency Node script I run in CI. It checks the frontmatter rules from the spec and flags the obvious red flags:

// scripts/lint-skills.mjs
import { readdir, readFile } from "node:fs/promises";
import { join } from "node:path";

const ROOT = process.argv[2] ?? ".claude/skills";
const NAME_RE = /^[a-z0-9]+(-[a-z0-9]+)*$/;
const RED_FLAGS = [
  [/curl[^\n|]*\|\s*(ba|z)?sh/i, "pipes a download into a shell"],
  [/wget[^\n|]*\|\s*(ba|z)?sh/i, "pipes a download into a shell"],
  [/cat\s+[^\n]*\.env\b/i, "reads a whole .env file"],
  [/(skip|disable|bypass)[^\n]{0,30}(permission|approval|confirm)/i, "tells the agent to skip approvals"],
];

let failed = false;
const fail = (dir, msg) => { failed = true; console.error(`✗ ${dir}: ${msg}`); };

for (const dir of await readdir(ROOT)) {
  let src;
  try { src = await readFile(join(ROOT, dir, "SKILL.md"), "utf8"); }
  catch { continue; } // not a skill folder

  const fm = src.match(/^---\n([\s\S]*?)\n---/)?.[1] ?? "";
  const name = fm.match(/^name:\s*(.+)$/m)?.[1].trim();
  const desc = fm.match(/^description:\s*(.+)$/m)?.[1].trim();

  if (!name || name.length > 64 || !NAME_RE.test(name)) fail(dir, "invalid name");
  else if (name !== dir) fail(dir, `name "${name}" doesn't match folder`);
  if (!desc) fail(dir, "missing description");
  else if (desc.length > 1024) fail(dir, "description over 1024 chars");

  for (const [re, why] of RED_FLAGS) if (re.test(src)) fail(dir, why);
}

if (failed) process.exit(1);
console.log("✓ skills look sane");

Add "lint:skills": "node scripts/lint-skills.mjs" to package.json and run it in your pipeline. It's not a security scanner. Someone determined can split a payload across files or fetch it at runtime. What it does is catch the lazy mistakes, and most incidents start with a lazy mistake. For real validation there's also the spec's reference validator, skills-ref (skills-ref validate ./my-skill), so check its README before wiring it in.

The rest is just habit:

• Read every skill you didn't write, including the scripts folder. Pay extra attention to anything that touches the network or your environment variables.
• Keep secrets out of the agent's reach. Your Mongo URI doesn't need to be in a file the agent can cat.
• Pin and review shared skills like you would a dependency. A skill folder in a monorepo should go through code review like everything else.

Takeaways

• Agent Skills is now vendor-neutral and governed by the Linux Foundation. Writing skills for your repo is a safe bet now, not a Claude-only experiment.
• A skill is a folder plus a SKILL.md with name and description. The description decides when it fires, so make it specific.
• Keep skills small and focused, and move the long stuff into reference files.
• Treat third-party skills like npm packages. Lint them, review them, pin them.

Wrapping up

My suggestion for this weekend: take the paragraph you keep pasting into your agent, turn it into one SKILL.md, commit it, and add the lint script. That's a 30-minute job, and every agent on your team gets smarter about your codebase.

If you write a good one for a MERN or FastAPI setup, I'd love to see it. Drop it in the comments.