By September 2026, Claude Code, Codex, Cursor, and a string of open-source coding agents share one open format: a directory plus a SKILL.md. A skill is not another plugin marketplace. It is a procedure that loads on demand. Teams still paste release checklists, review steps, and rollback incantations into CLAUDE.md or AGENTS.md, or they one-click install dozens of community packs from GitHub. The buying question is not how many skills you own. It is whether that procedure should enter context on every turn, whether the description will auto-trigger on the wrong job, and whether scripts/ in the folder will run with the same rights as you. This article skips the full standard. It answers install and shortlist: which skills Claude Code and Codex should carry, how to install them, and how to accept them.
Why stuffing procedures into the global prompt is already the wrong 2026 decision
The old path and the new path collide in a concrete way. The old path is prompt-first: one ever-longer manual at the repo root, injected in full on every session. The new path is skill-first: stable facts stay in CLAUDE.md or AGENTS.md; repeatable multi-step work becomes a SKILL.md. The agent starts with the name and the description and loads the body only when it uses the skill. The same request — “ship this release” — bills you for the manual on every turn in the old path, and only on the release task in the new one.
Three things made this a scheduling problem instead of a hobby. First, Claude Code merged custom slash commands into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both become /deploy. Old command files keep working. The new features — supporting files, auto-invocation, sub-agents — live on the skill directory. Second, Codex scans .agents/skills from the working directory up to the repository root. Personal skills live under ~/.agents/skills. The older ~/.codex/skills path is still scanned, so a skill that “installed” in the wrong tree looks like a missing skill. Third, Vercel’s npx skills CLI can write the same pack into Claude Code, Codex, Cursor, and dozens of other agents. Portability holds only if you did not author the skill against one vendor’s private frontmatter.
One layer is easy to skip. Skills are not MCP, and they are not Function Calling. Tool protocols decide how a model calls a live interface. A skill decides when a human procedure is loaded. How the tool loop should be shaped is in What is Function Calling. Dynamic state across sessions does not belong in a skill body; that is a memory-layer problem, covered in self-hosted Agent Memory vs SaaS. Which harness you wrap around the model is a separate buying question in Pi vs Claude Code vs Codex.
How to classify Agent Skills
Lining skill names up as peers guarantees a bloated favorites list. Classify them by who maintains them, when they load, and whether they have side effects. Drop one class and you are left with reputation.
| Class | Example | What you get | What you must add |
|---|---|---|---|
| Bundled | Claude Code /code-review, /verify, /doctor; Codex skill-installer, review-agent | Vendor-maintained flows you slash-invoke in a session | A launch recipe when official inference fails |
| Project flow | .claude/skills/review-change, .agents/skills/release | Release, review, and rollback steps that travel with the repo | A narrow description so “tweak this” does not fire the release skill |
| Cross-repo rules | User-level folders, or npx skills add vercel-labs/agent-skills | Portable React performance, accessibility, or writing rules | An audit of scripts; do not dump them into ~/.claude/skills first |
Claude Code’s bundled skills are prompt orchestration, not fixed binaries: /code-review, /debug, /run, /verify, /run-skill-generator, /doctor. From v2.1.145 the last three can infer a launch from the README or package.json. On a project that needs a database, an env file, or a multi-step build, run /run-skill-generator once and commit the install commands, env vars, and launch script as an in-repo skill so later sessions stop rediscovering the recipe. Codex bundles guides such as skill-installer, skill-creator, review-agent, and openai-docs. Both sides use progressive disclosure: name and description first, body on use. The description field is not decoration. Too short and the skill never fires. Too wide and it fires on every chore.
Core comparison: entry, execution, context, audience
The real difference is the entry, not which lab published a larger skill catalog. Use one set of columns or you cannot decide.
| Tool | Entry | Execution | Context | Best for |
|---|---|---|---|---|
| Claude Code Skills | Terminal /skill-name or description match; project .claude/skills/; personal ~/.claude/skills/; plugin trees | Reads instructions, runs companion scripts, can fork a sub-agent; old .claude/commands/ still works | Preloads name and description; body on demand; can inject a live diff with a ! command before the model sees the skill | People who already pay a Claude seat and want review and release as repo assets |
| Codex Skills | /skills or $skill-name in the CLI or IDE; walks up .agents/skills; personal ~/.agents/skills | Same script and reference support; $skill-installer pulls curated skills | Same progressive disclosure; one account with ChatGPT and Codex Web | People already in the OpenAI ecosystem who want containment and one login |
| Cross-agent installer | npx skills add OWNER/REPO -a claude-code|codex; -g for user-level | Writes into each agent’s folder; can install a single --skill | Does not own runtime permissions; each CLI still loads the files | Teams that run Claude Code, Codex, and Cursor on the same repo |
A second table covers only the “I thought it installed” traps. The headers stay the same so the prose does not turn into empty adjectives.
| Tool | Entry | Execution | Context | Best for |
|---|---|---|---|---|
| Hand-written skill | You create the folder and the SKILL.md | Fully auditable; no hidden installer | The path must match the CLI you are in | People whose release or review flow cannot be a community pack |
Codex $skill-installer | Dollar-prefix inside a Codex session | Fast pull for curated skills such as Linear | Often writes the older ~/.codex/skills path | People who stay in Codex and will check both user trees |
npx skills | A terminal, outside the session | Targets several agents in one command | Symlinks or copies into each tree; updates mean running it again | People who want one React or accessibility rule set to travel with the repo |
# Claude Code — project skill (this repo only) mkdir -p .claude/skills/review-change # Codex — project skill (open .agents/ convention) mkdir -p .agents/skills/review-change # Personal skill, every repo on this machine mkdir -p ~/.claude/skills/review-change mkdir -p ~/.agents/skills/review-change # Cross-agent package manager (Vercel skills CLI) npx skills add vercel-labs/agent-skills --skill react-best-practices -a claude-code npx skills add vercel-labs/agent-skills --skill react-best-practices -a codex # Codex bundled installer (often writes ~/.codex/skills) # Inside a Codex session: # $skill-installer linear
A minimal SKILL.md only needs the open-standard name and description. The file below is enough to test trigger and body load. Do not add scripts/ until that loop is boring.
--- name: review-change description: Reviews an uncommitted diff and lists risks. Use when the user asks what changed, wants a commit message, or asks to review the working tree. Do not use for greenfield feature design. --- ## Current changes Run git diff HEAD and summarize in three bullets. Flag missing tests, hardcoded secrets, and edits outside the named module. If the diff is empty, say so and stop.
Which skills Claude Code and Codex should actually carry
A recommended stack is not a vendor-store top ten. It is a side-effect ladder. Keep bundled skills. Keep only the project flows you repeat every week. Keep cross-repo rules only after someone has read the body.
| Tool | Entry | Execution | Context | Best for |
|---|---|---|---|---|
| Claude Code keep | /doctor, /code-review, /debug | Config diagnosis, review, incident work; vendor-maintained | Almost no fixed context cost | Every Claude Code user |
| Claude Code record per repo | /run-skill-generator then /run and /verify | Turns launch and acceptance into an in-repo recipe | Loads when you drive the app | People whose start command is not a single npm start |
| Codex keep | skill-creator, review-agent, openai-docs | Teaches skill authoring, policy review, official docs | Bundled; do not clone a community copy | Every Codex user |
| Worth it on both | react-best-practices, web-design-guidelines | Vercel engineering rules, portable | Install per agent with npx skills; do not dump the whole repo | React / Next product teams |
| Do not install by default | Community packs whose description says “use for any task,” or unread scripts/ | Wrong-job triggers plus local same-user rights | The wider the description, the more often it is nominated | Nobody should be this user |
A solo developer should land one review-change skill and one release skill before they decide they need React rules. A small product team should encode “checks that must run before a PR” as a project skill and leave personal taste in a user-level CLAUDE.md. Customer paths do not belong in a user-level skill. An enterprise should treat skills as code: pull-request the SKILL.md and the scripts/, and refuse members who symlink unaudited packs into ~/.agents/skills.
How to choose by scene
| If you are | Choose | Why |
|---|---|---|
| Repeating the same release or review steps every week; the manual is already longer than one screen | Project-level Skills instead of a longer CLAUDE.md | The body loads on demand; facts and procedures stay split |
| Still sending “ship it” as a one-liner; almost no docs exist for an agent | Bundled /verify or review-agent first, then record a project skill | Buy the vendor fallback, then freeze your recipe |
| Running Claude Code and Codex; the rules must travel with the repo | One SKILL.md plus npx skills -a | The format ports; the paths still do not |
| Only using Linear or official docs inside Codex | $skill-installer, and remember to inspect ~/.codex/skills | Curation is fast; the folder may split from hand-written skills |
| Shipping a skill with install scripts that touch disk or secrets | A remote Mac or a container before any user-level folder | Same-user rights are a risk, not a convenience |
| Tempted to install dozens of “make the agent smarter” community skills | Install none, or one after you read the scripts | A wide description drags unrelated jobs into a long body |
Recommended combinations
A — Solo developer, one primary CLI: leave bundled skills on. Commit only two project skills: review the uncommitted diff, and ship with the existing script. Write when to use and when not to use into the description. Put file writes and bash in a container or on a remote Mac that isolates the workspace per session. Put API spend and node rent on the same sheet; monthly node cost is on Mac mini pricing.
B — Small product team, Claude Code and Codex together: install rule packs such as react-best-practices or web-design-guidelines per agent with npx skills. Do not dump the whole catalog. Keep release and rollback in the project tree and review them in the PR. Leave personal phrasing in a user-level prompt, not in a skill. Accept both CLIs against the same sample release task. Do not assume a skill that fires in one harness fires in the other.
C — Enterprise or high security: treat skills as code. Directory, scripts, and description go through pull request. Ban unaudited packs in user-level folders. Scripts that open a network or touch secrets run only on a disposable node. Account and delivery boundaries live in the help center. When you need an isolated workspace, start from Mac mini rental instead of using the office laptop as a lab.
Common pitfalls
- Shopping by favorites: “more skills make a smarter agent.” Every wide description is a wrong-trigger budget.
- Leaving procedures in the global prompt: a release checklist that loads every session is a manual you pay for on every turn.
- Assuming paths are universal: Claude Code’s
.claude/skillsis not Codex’s default root. The Codex installer may still write~/.codex/skills. - Installing user-level before reading scripts:
scripts/inherit the launching user. Project directory first, isolated node first. - Replacing tests with a community skill:
/verifyand your CI are not substitutes. A skill cannot replace a red-green suite.
Action plan: 7 steps
- Open
CLAUDE.mdorAGENTS.md. Mark every procedure longer than one paragraph as a candidate: release, review, rollback, changelog. Keep facts. Move steps. - Write one
SKILL.mdwith noscripts/. Put when to use and when not to use in the description. Invoke it once with/review-changeor$review-change. - Ask in ordinary language and see whether it auto-triggers. If it fires on the wrong job, rewrite the description. Do not install a second skill to paper over the first.
- Place Claude Code skills in
.claude/skills/and Codex skills in.agents/skills/. If Cursor or another agent must see the same pack, usenpx skills add … -ainstead of copying the wrong folder by hand. - Stop at bundled skills plus two to four project skills. A community pack enters the project tree only after someone reads the
SKILL.mdand the scripts. It does not enter~/.claude/skillsor~/.agents/skillsfirst. - Run skills that ship
scripts/in a container or on a remote Mac. Keep secrets out of the prompt and out of the skill body. The workspace must wipe at session end. - Accept against one release or review task: did it trigger, which files did it touch, and are the original CI tests green. A warm local cache that “looks green” is not acceptance.
FAQ
How are Skills different from CLAUDE.md or AGENTS.md?
Stable facts belong in CLAUDE.md or AGENTS.md and load every session. Repeatable multi-step procedures belong in Skills and load only when used. Stuffing a release checklist into the global prompt means you pay for the manual on every turn.
Can Claude Code and Codex share the same skill?
They share the SKILL.md open format. They do not share paths or invocation. Claude Code reads .claude/skills/ and ~/.claude/skills/. Codex reads .agents/skills/ and ~/.agents/skills/, and still scans the older ~/.codex/skills path. Use npx skills -a to target an agent.
Should I one-click install every popular GitHub skill?
No. A wide description auto-triggers on the wrong jobs. scripts/ run with the same rights as you. Read the SKILL.md and any scripts, then install into the project directory — not the user-level folder that leaks into every repo.
What is the difference between Codex $skill-installer and npx skills?
$skill-installer is a Codex bundled installer and often writes to ~/.codex/skills. npx skills is a cross-agent package manager and can target claude-code or codex. Hand-written skills belong in .agents/skills or .claude/skills. Check both trees before you decide a skill “did not install.”
Can I run skills with scripts on my daily laptop?
They will run. Do not do that on an unfamiliar repo or production secrets. Put them in a container or a remote Mac node first, confirm trigger scope and write boundaries, then decide whether the skill is ready for the team repo.
Conclusion
In 2026, do not treat a community leaderboard as a shopping cart for Agent Skills. Pick by entry class first: bundled skills for vendor fallback, project skills for the release and review you repeat every week, and cross-repo rules only after someone has read them. Claude Code and Codex share a format. They do not share a default directory. Keep descriptions narrow, install scripts late, and treat the user-level folder as an exception rather than the default. Write the split, the trigger, the path, and the wipeable node into the seven-step acceptance. Remote nodes start on the rental page and the pricing page. Account questions go to the help center.
Further reading
- Pi vs Claude Code vs Codex: how to pick a 2026 harness →
- What is Function Calling: OpenAI, Gemini, Claude →
- Self-hosted Agent Memory vs SaaS Memory →
Skills with scripts edit repos and run commands — isolate them on a Mac node
A SKILL.md is not just prose. Files under scripts/ run with the launching user’s rights. Installing an unaudited community skill on a daily laptop hands bash to a stranger. A remote Mac isolates the repo and secrets per session so you can verify triggers and permissions before the skill lands in the team tree.