skills.sh vs Codex Plugins

Agent ops

1. ai-native userMy agent can author and package a new skill end to end by following the project's own spec, template, or meta-skill

   weight 2 · round to Codex Plugins
   skills.sh✓fullclaimed7/10

   The CLI ships a `skills init [name]` command that scaffolds a new SKILL.md template, the agentskills.io spec defines the file format and fields (e.g. allowed-tools), a `skills-ref validate` tool checks conformance, and a dedicated 'skill-creator' meta-skill is referenced for guided authoring — together covering the author-to-package workflow end to end. Missing for 10: a full worked example showing a new skill going from init through validate to packaged/published output, and independent (non-vendor) confirmation that agents can follow this spec unaided.

   • [github] “Create a new SKILL.md template”
   • [github] “`skills init [name]` | Create a new SKILL.md template”
   • [github] “npx skills init my-skill”
   • [claimed-docs] “skills init [name] | Create a new SKILL.md template”
   • [claimed-docs] “skills-ref validate ./my-skill”
   • [claimed-docs] “| `allowed-tools` | No | Space-separated string of pre-approved tools the skill may use. (Experimental)”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design --skill skill-creator”

   proof ↗⚑ flag

   Codex Plugins✓fullcommunity8/10

   Docs describe a full authoring pipeline: SKILL.md spec with required fields, a plugin-creator/skill-creator meta-skill that scaffolds .codex-plugin/plugin.json and MCP wiring, a recorder that drafts a skill from a demonstration, skill-installer for distribution, and a submission portal for publishing, matching author-and-package-end-to-end via the project's own spec, template, or meta-skill. Community comments corroborate real users creating and customizing skills with the skill-creator skill. Missing for 10: independent hands-on verification of the full creator-to-published-package flow, and more detail on packaging/versioning nuances beyond the manifest.

   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest and can also…”
   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “The plugin-creator skill will create the plugin folder, create the required `.codex-plugin/plugin.json`, and add MCP server wiring for the p…”
   • [claimed-docs] “The recorder captures the workflow, inspects the steps, and drafts a reusable skill from the demonstration.”
   • [claimed-docs] “It scaffolds the required `.codex-plugin/plugin.json` manifest and can also generate a local marketplace entry for testing.”
   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest”
   • [claimed-docs] “For a portable Agent Plugins package, add `plugin.json` at the plugin root and declare the Agent Plugins schema.”
   • [claimed-docs] “Use the plugin submission portal to submit a plugin for review when you're ready to publish it for public use.”
   • [community] “The skills that matter most to me are the ones I create myself (with the skill creator skill) that are very specific and proprietary... I mi…”

   proof ↗⚑ flag

2. ai-native userMy coding agent can install a skill by itself — a non-interactive, promptless install path an agent can run headlessly end to end

   weight 3 · round to skills.sh
   skills.sh✓fullclaimed8/10

   The CLI documents an explicit non-interactive/CI-CD-friendly install path with a full example (`npx skills add ... --skill frontend-design -g -a claude-code -y`) that specifies target skill, agent, scope, and auto-confirms without prompts, enabling a coding agent to run it headlessly end-to-end. Missing for 10: independent/hands-on confirmation that this exact non-interactive flow works flawlessly in practice (only first-party docs cited).

   • [github] “Non-interactive installation (CI/CD friendly)”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y”
   • [github] “# Non-interactive installation (CI/CD friendly) npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y”
   • [github] “Target specific agents (e.g., `claude-code`, `codex`)”
   • [github] “Install to user directory instead of project”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed5/10

   Docs show a `$skill-installer` skill and a `codex plugin marketplace add` CLI command that let a skill/plugin be installed by name without manual UI browsing (codex-plugins-docs-8, docs-11, docs-14, docs-21, docs-34), suggesting an agent could invoke these programmatically. However, none of the evidence confirms a fully non-interactive, promptless, end-to-end headless flow (e.g., a scripted CLI flag bypassing any session/config prompts, or documentation stating the agent can trigger this without human involvement) — install flows described (docs-25, docs-26) still reference starting a 'new session' via CLI/chat interaction rather than a scripted automation path. Missing for 10: explicit headless/CI-style install command or flag, confirmation the agent can self-invoke skill-installer without any human step, and evidence no interactive confirmation/prompt is required during install.

   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`. For example, to install the `$linear` ski…”
   • [claimed-docs] “$skill-installer linear”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Curated skills can be installed by name (defaults to `skills/.curated`): $skill-installer gh-address-comments ”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   skills.sh~partialprobed5/10

   The product ships an AGENTS.md file (raw.githubusercontent.com/vercel-labs/skills/HEAD/AGENTS.md) containing structured, agent-readable command references (skills-cli-docs-2,5,7,8,9,10,11), which is a recognized agent-oriented docs format a user could point an agent at. However there's no evidence of an llms.txt for skills.sh itself, and a probe for an alternate docs.md path returned 404, suggesting the agent-doc surface is limited to AGENTS.md rather than a broader llms.txt/docs strategy. Missing for 10: a dedicated llms.txt file for skills.sh/agentskills.io, confirmation the AGENTS.md is discoverable/linked from primary docs, and independent evidence an agent was successfully pointed at it.

   • [claimed-docs] “`skills experimental_install` | Restore skills from skills-lock.json”
   • [claimed-docs] “skills list | List installed skills (alias: `ls`)”
   • [claimed-docs] “skills update [skills...] | Update skills to latest versions”
   • [claimed-docs] “skills init [name] | Create a new SKILL.md template”
   • [claimed-docs] “skills experimental_sync | Sync skills from node_modules into agent dirs”
   • [probe] “PROBE docs-md: HTTP 404 at https://github.com/vercel-labs/skills.md”

   proof ↗⚑ flag

   Codex Plugins~partialprobed5/10

   Codex documentation itself is published as llms.txt/agent-oriented markdown (developers.openai.com/llms.txt returns 200 and indexes markdown docs), showing the product's own docs are agent-consumable, but there is no evidence that a Codex plugin/agent can be pointed at an arbitrary external llms.txt or agent-oriented docs site to ingest and act on it as a user-directed capability. missing for 10: explicit feature/skill letting a user supply/point the agent at a third-party llms.txt or docs URL for ingestion, and any hands-on confirmation of this workflow beyond the docs' own self-hosting.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developers.openai.com/llms.txt # OpenAI Developers > Complete documentation hub for OpenAI API, Ads, Pl…”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.openai.com/codex/skills.md # Build skills > For the complete documentation index, see [llms.t…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to skills.sh
   skills.sh✓fullcommunity8/10

   skills.sh's CLI explicitly documents non-interactive, CI/CD-friendly installation flags (--skill, -a, -y, -g) and headless usage via npx skills add/use with flags that avoid interactive prompts, suitable for automation pipelines. missing for 10: no independent CI pipeline case study or official GitHub Actions integration example, and no REST/API-only automation path (a community request notes absence of a REST API).

   • [github] “Non-interactive installation (CI/CD friendly)”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y”
   • [github] “# Non-interactive installation (CI/CD friendly) npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y”
   • [github] “Use the same command for public and private repositories. The CLI uses the authentication already configured for the repository URL”
   • [community] “Please make a rest API!”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   No evidence in the pack addresses running Codex Plugins headlessly or invoking it from CI/automation pipelines; all docs describe interactive install/browse flows (/plugins, /skills, plugin-creator) via CLI or ChatGPT UI. Missing for 10: any mention of a non-interactive/headless invocation mode, CI examples, or automation-friendly APIs for plugins/skills.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Codex Plugins
   skills.sh—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Codex Plugins✓fullclaimed8/10

   Codex Plugins explicitly documents that plugins 'use the Model Context Protocol (MCP) to expose server-backed capabilities to ChatGPT and Codex,' with a plugin browser (/plugins), marketplace add command, and plugin-creator skill that 'adds MCP server wiring' — showing first-party, well-documented support for plugging in MCP servers and using their tools. missing for 10: independent hands-on verification of third-party MCP servers being installed and invoked successfully in Codex, and more detail on runtime tool-call behavior/limits.

   • [claimed-docs] “Plugins use the [Model Context Protocol (MCP)] to expose server-backed capabilities to ChatGPT and Codex.”
   • [claimed-docs] “The plugin-creator skill will create the plugin folder, create the required `.codex-plugin/plugin.json`, and add MCP server wiring for the p…”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest and can also…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to skills.sh
   skills.sh✓fullcommunity9/10

   skills.sh ships a fully documented official CLI (`npx skills`) with rich subcommands—add, use, list, search, update, remove, init, experimental_install/sync—supporting multiple agents (Claude Code, Codex, Cursor, etc.), symlink-based installs, CI/CD-friendly non-interactive mode, and private/public repo auth, all corroborated by first-party GitHub docs and independent HN discussion of real usage. Missing for 10: deeper independent hands-on verification of update/version-pinning reliability (one community comment questioned documentation of these, though the CLI docs do cover them) and no REST API alternative.

   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “Target specific agents (e.g., `claude-code`, `codex`)”
   • [github] “Non-interactive installation (CI/CD friendly)”
   • [github] “List all installed skills. Similar to `npm ls`.”
   • [github] “Update installed skills to latest versions”
   • [github] “Remove installed skills from agents”
   • [github] “Supports **OpenCode**, **Claude Code**, **Codex**, **Cursor**, and [73 more](#supported-agents).”
   • [claimed-docs] “skills list | List installed skills (alias: `ls`)”
   • [claimed-docs] “skills update [skills...] | Update skills to latest versions”
   • [community] “The leaderboard is ranked by the weekly download count from their 'npx skills' command. This is Vercel's new 'standard' skills installer so …”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins✓fullprobed8/10

   Codex Plugins documentation repeatedly references the official Codex CLI, including specific commands (/plugins, /skills, $skill-installer, codex plugin marketplace add) that let an AI-native user browse, install, and manage plugins/skills directly from the CLI, confirming an official CLI workflow exists and is documented as first-class. Missing for 10: independent hands-on confirmation of CLI usage beyond vendor docs, and a full command reference showing breadth of CLI capabilities.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.openai.com/codex/skills.md # Build skills > For the complete documentation index, see [llms.t…”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to skills.sh
   skills.sh~partialcommunity5/10

   skills.sh exposes a well-documented CLI (`npx skills add/use/list/update/remove/init`, non-interactive/CI-friendly flags) that lets automated/agentic callers drive it programmatically, and AGENTS.md/specification.md document the interface in detail. However, this is a CLI, not a public API/SDK, and a community member explicitly requests 'Please make a rest API!' ([skills-cli-comm-5]), indicating no such API exists yet. Missing for 10: a documented REST/programmatic API (not just CLI), SDKs or webhooks, and independent confirmation of API-level access beyond the CLI wrapper.

   • [github] “Non-interactive installation (CI/CD friendly)”
   • [github] “# Non-interactive installation (CI/CD friendly) npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y”
   • [claimed-docs] “skills list | List installed skills (alias: `ls`)”
   • [claimed-docs] “skills update [skills...] | Update skills to latest versions”
   • [claimed-docs] “skills init [name] | Create a new SKILL.md template”
   • [claimed-docs] “skills experimental_sync | Sync skills from node_modules into agent dirs”
   • [community] “Please make a rest API!”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Evidence shows Codex Plugins uses MCP to let plugins expose capabilities *to* Codex/ChatGPT, and offers CLI commands (`codex plugin marketplace add`, `/plugins`) for local plugin management, but there is no documented public REST/GraphQL API for programmatically driving the Codex Plugins product itself — the direct OpenAPI probe returned 404 on all candidate spec paths, confirming no discoverable public API surface.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.openai.com/openapi.json, https://developers.openai.com/swagger.json, https://deve…”
   • [claimed-docs] “Plugins use the [Model Context Protocol (MCP)] to expose server-backed capabilities to ChatGPT and Codex.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”

   proof ↗⚑ flag

6. ai-native userBuild against official SDKs

   weight 2 · round to Codex Plugins
   skills.sh—none0/10

   Evidence shows only a CLI (`skills` npx tool) and a SKILL.md specification/validator, not an official SDK (e.g., a JS/Python library) for programmatic integration; no SDK is mentioned anywhere in the pack.

   ⚑ flag

   Codex Plugins~partialprobed5/10

   Codex Plugins has real developer-facing build documentation (plugin.json manifest schema, MCP-based server wiring, plugin-creator scaffolding tool, submission portal, marketplace CLI) that lets developers build against an official plugin/skill framework, but this is a manifest/CLI-based plugin system rather than a formal client SDK, and the probe found no OpenAPI/API spec artifact. missing for 10: an actual downloadable/importable SDK library (e.g. Python/JS package), versioned API reference, and independent hands-on confirmation that third-party devs successfully build with it.

   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest and can also…”
   • [claimed-docs] “The plugin-creator skill will create the plugin folder, create the required `.codex-plugin/plugin.json`, and add MCP server wiring for the p…”
   • [claimed-docs] “For a portable Agent Plugins package, add `plugin.json` at the plugin root and declare the Agent Plugins schema.”
   • [claimed-docs] “Plugins use the [Model Context Protocol (MCP)] to expose server-backed capabilities to ChatGPT and Codex.”
   • [claimed-docs] “Use the plugin submission portal to submit a plugin for review when you're ready to publish it for public use.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.openai.com/openapi.json, https://developers.openai.com/swagger.json, https://deve…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Codex Plugins
   skills.sh—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Codex Plugins~partialclaimed6/10

   Codex Plugins connects to data sources (Gmail, Drive, Slack, Notion, Figma) and can summarize, draft, and act on that data via plugins/skills, giving AI-generated insights from connected data, but this is framed as tool-use/automation rather than a dedicated analytics/insights feature over the user's own stored data. missing for 10: no evidence of proactive dashboards, analytics summaries, or unprompted 'insights' generation from user data (e.g., trend detection, anomaly surfacing) beyond on-demand chat/skill invocation, and no independent hands-on validation of insight quality.

   • [claimed-docs] “Install the Gmail plugin to work with Gmail.”
   • [claimed-docs] “Install the Google Drive plugin to work across Drive, Docs, Sheets, and Slides.”
   • [claimed-docs] “Install the Slack plugin to summarize channels or draft replies.”
   • [github] “plugins/notion for planning, research, meetings, and knowledge capture”
   • [claimed-docs] “Install the Codex Security plugin to scan authorized code and confirm plausible vulnerability findings.”
   • [claimed-docs] “Plugins use the [Model Context Protocol (MCP)] to expose server-backed capabilities to ChatGPT and Codex.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   skills.sh—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Codex Plugins—none0/10

   The evidence describes installable plugins, skills, and MCP tool wiring, but nothing shows Codex Plugins can be configured to run autonomously in the background without a user-initiated session — sessions must be started manually after installation (docs-25) and skill triggers are described in terms of manual invocation (/skills, $mentions) rather than scheduled/autonomous execution. Missing for 10: any scheduler/cron/trigger mechanism, background/always-on execution mode, or evidence of unattended autonomous runs.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “The creator asks what the skill does, when it should trigger, and whether it should stay instruction-only or include scripts.”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Codex Plugins
   skills.sh—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Codex Plugins✓fullclaimed7/10

   Codex ships a built-in AI assistant (Codex itself) that can be extended via installed plugins to delegate tasks such as summarizing Slack channels, searching Gmail, working across Drive/Docs, or messaging via iMessage, all invoked directly from Codex CLI/chat sessions after installation. Docs also show skills and MCP-backed plugin tools becoming available to Codex for task delegation without leaving the product. missing for 10: independent/hands-on evidence of reliable end-to-end task delegation (community comments focus on skills' pros/cons in general, not on Codex-plugin delegation specifically), and no benchmark of assistant task success rates.

   • [claimed-docs] “Install the Gmail plugin to work with Gmail.”
   • [claimed-docs] “Install the Google Drive plugin to work across Drive, Docs, Sheets, and Slides.”
   • [claimed-docs] “Install the Slack plugin to summarize channels or draft replies.”
   • [claimed-docs] “it can read and search iMessage, SMS, and RCS chats on your Mac and send messages on your behalf through the Messages app”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Codex Plugins
   skills.sh—none0/10

   skills.sh is a structured CLI (npm-style syntax like `npx skills add`, `--skill`, `--agent` flags) with no evidence of a natural-language command interface for operating the tool itself; all documented usage requires exact flag syntax.

   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “Install specific skills by name (use `'*'` for all skills)”
   • [github] “Target specific agents (e.g., `claude-code`, `codex`)”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design --skill skill-creator”
   • [github] “npx skills add vercel-labs/agent-skills -a claude-code -a opencode”

   proof ↗⚑ flag

   Codex Plugins✓fullcommunity7/10

   Docs show plugins/skills are used conversationally in ChatGPT/Codex chat (e.g., 'summarize channels or draft replies', skills auto-triggering based on natural-language description matching) alongside slash commands (/plugins, /skills) for management, indicating natural-language operation is the primary interaction mode. missing for 10: independent/hands-on confirmation that natural-language triggering reliably works, and clarification on how much slash/$ syntax is required vs pure natural language.

   • [claimed-docs] “Install the Slack plugin to summarize channels or draft replies.”
   • [claimed-docs] “The creator asks what the skill does, when it should trigger, and whether it should stay instruction-only or include scripts.”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [community] “Skills are the matrix scene where neo learns kungfu. Imagine they are a database of specialized knowledge that can an agent can instantly ta…”

   proof ↗⚑ flag

Api quality

1. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   skills.sh—none0/10

   Evidence shows a CLI tool and a Skill-format specification (SKILL.md schema, agentskills.io/specification.md), but no OpenAPI or machine-readable API spec for skills.sh itself; a community comment explicitly requests 'Please make a rest API!' implying none currently exists.

   • [claimed-docs] “skills-ref validate ./my-skill”
   • [community] “Please make a rest API!”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   A direct probe for OpenAPI/swagger spec files at all standard paths returned 404, and no other evidence shows a downloadable machine-readable API spec for Codex Plugins; the plugin.json manifest and MCP protocol references describe plugin authoring, not a consumable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.openai.com/openapi.json, https://developers.openai.com/swagger.json, https://deve…”

   proof ↗⚑ flag

2. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   skills.sh—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Codex Plugins—none0/10

   No evidence of a sandbox/staging environment for testing plugins or skills against non-production data; docs only mention 'local marketplace entry for testing' which refers to plugin discovery/distribution, not data isolation from production systems.

   ⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   skills.sh—none0/10

   The evidence pack has no documentation of versioned APIs or a deprecation policy for skills.sh's CLI/registry; the closest matter is `skills update` for updating skill content, which is unrelated to API/version stability guarantees. Community feedback explicitly notes the absence of version-pinning/package-management documentation, reinforcing that no such policy exists.

   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”
   • [community] “Please make a rest API!”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   No evidence of API versioning scheme or a documented deprecation policy for Codex Plugins; the probe for an OpenAPI spec even returned 404s across all candidate paths, and docs only cover plugin/skill creation and usage, not lifecycle/versioning guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.openai.com/openapi.json, https://developers.openai.com/swagger.json, https://deve…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to skills.sh
   skills.sh~partialclaimed6/10

   skills.sh CLI supports bulk-style operations: installing multiple skills with repeated --skill flags, using '*' to install all skills in a repo, targeting multiple agents at once (-a claude-code -a opencode), searching/finding across an entire org's repositories, and listing/updating/removing installed skills in one command. However these are batch operations on skills/repos, not a generalized bulk-operation framework across arbitrary 'many items', and there's no evidence of bulk operations at scale (e.g., hundreds of skills, parallelism, progress reporting) or independent hands-on confirmation of true bulk behavior beyond CLI flag docs. missing for 10: evidence of large-scale/parallel bulk execution, independent hands-on validation of multi-item operations beyond documented flags, and any bulk-editing/config across many installed skills simultaneously.

   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design --skill skill-creator”
   • [github] “npx skills add vercel-labs/agent-skills -a claude-code -a opencode”
   • [github] “Install specific skills by name (use `'*'` for all skills)”
   • [github] “Search across every repository owned by an organization or user”
   • [github] “npx skills find react --owner vercel”
   • [github] “npx skills update frontend-design web-design-guidelines”
   • [github] “npx skills remove --agent claude-code cursor my-skill”
   • [github] “List all installed skills. Similar to `npm ls`.”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Evidence covers plugin/skill installation, marketplace browsing, and per-item workflows (Slack summarization, Drive docs, Notion, etc.), but nothing describes performing an operation across many items/records/files at once (e.g., batch processing, multi-item automation loops). No batch or bulk-operation capability is documented or implied.

   ⚑ flag

2. ai-native userVersion, review, and roll back my automations

   weight 1 · round to skills.sh
   skills.sh!disputedcontradicted4/10

   skills.sh documents an update command and an experimental skills-lock.json restore mechanism (skills experimental_install) that could serve as version/rollback primitives, and skills are stored in project dirs that can be committed to git for review. However, a hands-on community comment explicitly contradicts this, stating that none of these 'npm for Skills' tools document basic package-management features like updates, version-pinning, or uninstalls, undercutting the vendor's implied versioning story. There is no evidence of a review/diff workflow before applying changes, and rollback is only an 'experimental' feature. Missing for 10: documented version-pinning/semver support, a review/diff UI before install, and non-experimental rollback with independent confirmation it works.

   • [claimed-docs] “`skills experimental_install` | Restore skills from skills-lock.json”
   • [claimed-docs] “skills experimental_install | Restore skills from skills-lock.json”
   • [claimed-docs] “skills experimental_install") | Restore skills from skills-lock.json”
   • [github] “Update installed skills to latest versions”
   • [github] “npx skills update # Update a single skill by name npx skills update my-skill”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Evidence describes creating, installing, and browsing skills/plugins (SKILL.md files, `.agents/skills` directories, marketplace add/track commands) but contains no mention of version history, diffing/review workflows, or rollback/undo mechanisms for skills or plugins. Being file-based artifacts implies they could be manually versioned with external tools like git, but no such capability is documented as a product feature.

   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “It scaffolds the required `.codex-plugin/plugin.json` manifest and can also generate a local marketplace entry for testing.”

   proof ↗⚑ flag

Portability

1. developerInstall the same collection into multiple different coding agents — Claude Code, Codex, Cursor, and others — with per-harness instructions

   weight 3 · round to skills.sh
   skills.sh✓fullclaimed8/10

   skills.sh CLI explicitly supports installing a skill collection into multiple named agents (e.g., `-a claude-code -a opencode`, `--agent claude-code cursor`) and lists broad support for Claude Code, Codex, Cursor, OpenCode plus 70+ more, with per-agent directory targeting (`./<agent>/skills/`) and symlink-based single-source-of-truth updates. Cross-agent reuse is also stated in docs ('Build a skill once and use it across any skills-compatible agent'). Missing for 10: independent hands-on verification that per-harness instructions actually differ/adapt correctly across agents beyond directory placement, and community commentary raises unanswered concerns about version-pinning/uninstall completeness.

   • [github] “Target specific agents (e.g., `claude-code`, `codex`)”
   • [github] “npx skills add vercel-labs/agent-skills -a claude-code -a opencode”
   • [github] “npx skills remove --agent claude-code cursor my-skill”
   • [github] “Supports **OpenCode**, **Claude Code**, **Codex**, **Cursor**, and [73 more](#supported-agents).”
   • [github] “Supports **OpenCode**, **Claude Code**, **Codex**, **Cursor**, and [75 more](#supported-agents).”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team | **Global** | `-g` | `~/<agent>/skills/` | Av…”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [claimed-docs] “Cross-product reuse: Build a skill once and use it across any skills-compatible agent.”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   All evidence describes installing plugins/skills within OpenAI's own ecosystem (Codex CLI, ChatGPT desktop/Chat/Work) — there is no evidence of a single collection being installed into Claude Code, Cursor, or other third-party coding agents. In fact docs-32 implies the opposite: migrating an existing Claude Code plugin to OpenAI requires reviewing what needs to change, suggesting formats are not simply portable across harnesses.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [claimed-docs] “If you're migrating an existing Claude Code plugin or connector, first review [Submit your Claude Code plugin to OpenAI] to see what you nee…”

   proof ↗⚑ flag

2. developerSkills are plain markdown files and folders I can read, copy, and carry to another harness — not a proprietary binary format

   weight 2 · round to skills.sh
   skills.sh✓fullclaimed8/10

   Skills are plain SKILL.md files/folders stored in canonical directories with symlinks to agent-specific paths, installable/removable/updatable via CLI, and explicitly designed for 'build once, use across any skills-compatible agent' with 75+ supported agents — this is markdown, not a proprietary binary. missing for 10: independent hands-on confirmation of actually moving a skill folder to a different harness and verifying it works unmodified, and clearer detail on how symlink/canonical-copy structure avoids lock-in on non-supported agents.

   • [github] “Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [github] “Supports **OpenCode**, **Claude Code**, **Codex**, **Cursor**, and [73 more](#supported-agents).”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [claimed-docs] “Cross-product reuse: Build a skill once and use it across any skills-compatible agent.”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [github] “Global | -g | ~/<agent>/skills/ | Available across all projects”
   • [claimed-docs] “Skills can also bundle scripts, reference materials, templates, and other resources.”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed6/10

   Docs confirm skills are plain directories with a SKILL.md file plus optional scripts/references (not a proprietary binary), scanned from `.agents/skills` folders that teams can check into a repo alongside code, which supports the 'read/copy' portability claim. However, there is no explicit evidence describing moving a skill folder to a different harness (e.g., Claude Code) working out-of-the-box, and the plugin.json/MCP wiring layer around plugins is more proprietary/manifest-based than pure markdown. Missing for 10: explicit cross-harness carry demonstration, and clarity that plugin-level packaging (vs skill-level) is also portable.

   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [claimed-docs] “teams can check in skills relevant to a working folder. For example, skills only relevant to a microservice or a module.”
   • [claimed-docs] “A skill packages instructions, resources, and optional scripts so either product can follow a workflow reliably.”
   • [claimed-docs] “If you're migrating an existing Claude Code plugin or connector, first review [Submit your Claude Code plugin to OpenAI] to see what you nee…”

   proof ↗⚑ flag

Discovery

1. developerBrowse or search a catalog of available skills — a registry, leaderboard, or marketplace listing — before installing anything

   weight 2 · round drawn
   skills.sh✓fullcommunity8/10

   skills.sh hosts a public Skills Leaderboard for browsing available skills (skills-cli-docs-6), and the CLI supports interactive/keyword search and listing skills across repos/orgs before installing (skills-cli-gh-6, -11, -12, -25, -33). Community discussion confirms the leaderboard is live and ranks by download count, though some question ranking transparency/fairness. Missing for 10: no independent evidence of catalog breadth/quality beyond Vercel's own skills, and community skepticism about ranking bias (skills-cli-comm-1, -2) slightly undercuts trust in the leaderboard's neutrality.

   • [claimed-docs] “Skills Leaderboard”
   • [github] “List available skills without installing”
   • [github] “Search for skills interactively or by keyword”
   • [github] “Search across every repository owned by an organization or user”
   • [github] “npx skills find react --owner vercel”
   • [github] “Search for skills interactively or by keyword.”
   • [community] “What is this? How does it work? How are skills ranked? Seems fishy that you can only tell it's from Vercel if you click the top left corner,…”
   • [community] “The leaderboard is ranked by the weekly download count from their 'npx skills' command. This is Vercel's new 'standard' skills installer so …”
   • [community] “Nice work! I don't think Vercel is the first to do this...A small UI suggestion: it would be helpful if hovering on a row showed the skill d…”

   proof ↗⚑ flag

   Codex Plugins✓fullclaimed8/10

   Docs describe a `/plugins` command that opens a 'plugin browser' and a 'Plugins tab' to browse and install plugins in ChatGPT/Codex, backed by a marketplace.json listing plugin entries with categories and a `codex plugin marketplace add` CLI command; the openai/plugins GitHub repo also serves as a browsable catalog of available plugins (Figma, Notion, Expo, etc.). Missing for 10: independent/hands-on confirmation of the browsing UI's search/filter experience, and no evidence of ratings, leaderboards, or third-party marketplace aggregation beyond OpenAI's own listing.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “"name": "slack", ... "category": "Communication"”
   • [github] “plugins/figma for `use_figma`, Code to Canvas, Code Connect, and design system rules”
   • [github] “plugins/notion for planning, research, meetings, and knowledge capture”
   • [github] “`plugins/notion` for planning, research, meetings, and knowledge capture”
   • [github] “`plugins/expo` for Expo and React Native apps, SDK upgrades, EAS workflows, and Codex Run actions”

   proof ↗⚑ flag

Distribution

1. engineering-leadDistribute a standard skill set to my whole team — via a marketplace, a shared repo, or files committed to the project

   weight 2 · round drawn
   skills.sh✓fullcommunity8/10

   skills.sh's CLI supports installing skills from GitHub repos (public/private), a marketplace-like registry with search/leaderboard, and project-level installs that are committed to the repo and shared with the team (`./<agent>/skills/` default, symlink mode for single source of truth), plus CI/CD-friendly non-interactive install and update/remove commands for team-wide standardization. Community feedback confirms real-world adoption but raises concerns about package-management maturity (versioning/uninstall docs). missing for 10: no case study of an actual team-wide rollout process, no built-in access-control/marketplace curation features beyond org-wide search, and community skepticism about update/versioning robustness.

   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team | **Global** | `-g` | `~/<agent>/skills/` | Av…”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [github] “Use the same command for public and private repositories. The CLI uses the authentication already configured for the repository URL”
   • [github] “Non-interactive installation (CI/CD friendly)”
   • [github] “Search across every repository owned by an organization or user”
   • [claimed-docs] “Skills Leaderboard”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins✓fullcommunity8/10

   Docs describe all three distribution channels: checking skills into a repo/working folder (`.agents/skills` scanning, docs-9/docs-17), a marketplace mechanism (`codex plugin marketplace add`, marketplace.json, docs-11/docs-35), and a public submission portal for org-wide plugins (docs-31). Community commentary corroborates skills being used for 'cross-team standardization' (comm-3). Missing for 10: independent case study of a team actually rolling out a shared marketplace/repo at scale, and more detail on permissioning/governance for team-wide distribution.

   • [claimed-docs] “teams can check in skills relevant to a working folder. For example, skills only relevant to a microservice or a module.”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “It scaffolds the required `.codex-plugin/plugin.json` manifest and can also generate a local marketplace entry for testing.”
   • [claimed-docs] “Use the plugin submission portal to submit a plugin for review when you're ready to publish it for public use.”
   • [claimed-docs] “"name": "slack", ... "category": "Communication"”
   • [community] “Skills are not useful for single-shot cases. They are for: cross-team standardization (for LLM generated code), and reliable reusability of …”

   proof ↗⚑ flag

Triggering

1. developerInstalled skills trigger automatically from task context, with descriptions engineered so the agent activates the right skill at the right moment

   weight 3 · round to Codex Plugins
   skills.sh~partialclaimed6/10

   The Agent Skills spec/docs describe the underlying discovery mechanism—agents load only name+description at startup 'just enough to know when it might be relevant'—which is the technical basis for auto-triggering, and skills.sh's CLI is the distribution layer for these SKILL.md files. However, there's no first-party guidance on engineering descriptions for reliable activation, and no independent/hands-on evidence confirming skills actually trigger correctly at the right moment (community comments focus on ranking/leaderboard fairness, not trigger accuracy). Missing for 10: documentation on description-engineering best practices, hands-on validation that the right skill activates at the right time, and independent corroboration beyond vendor docs.

   • [claimed-docs] “At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.”
   • [claimed-docs] “Discovery: At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.”
   • [claimed-docs] “Skills can also bundle scripts, reference materials, templates, and other resources.”

   proof ↗⚑ flag

   Codex Plugins~partialcommunity7/10

   Docs describe the mechanics needed for context-triggered skills: SKILL.md requires a `description` field, the skill-creator explicitly asks 'when it should trigger,' and Codex scans `.agents/skills` up the directory tree for applicable skills, implying automatic, description-driven activation. However, evidence is mostly first-party docs plus manual invocation commands (`/skills`, `$mention`), and community commentary voices skepticism about reliability ('you just append more text to prompt and pray') without a concrete hands-on failure, so this stays partial rather than full/disputed. Missing for 10: independent hands-on verification that description-matching reliably picks the correct skill at the correct moment, and quantitative/real-world evidence of trigger accuracy.

   • [claimed-docs] “The creator asks what the skill does, when it should trigger, and whether it should stay instruction-only or include scripts.”
   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”
   • [community] “Skills are the matrix scene where neo learns kungfu. Imagine they are a database of specialized knowledge that can an agent can instantly ta…”
   • [community] “At least MCPs can be unit tested. With Skills however, you just selectively append more text to prompt and pray.”

   proof ↗⚑ flag

Onboarding

1. developerA quickstart takes me from nothing to a working installed skill in under five minutes

   weight 3 · round drawn
   skills.sh~partialcommunity6/10

   The single command `npx skills add owner/repo` installs a working skill quickly and docs show a minimal quickstart flow (list, install, use with an agent), suggesting a fast path to a working skill. However, there's a community complaint that basic package-management docs (updates, version pinning, uninstall) are hard to find, and no independent timed hands-on report confirms the under-5-minutes claim. Missing for 10: an explicit timed quickstart walkthrough, independent confirmation of setup speed, and clearer documentation addressing the community's confusion about basic usage.

   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “# GitHub shorthand (owner/repo) npx skills add vercel-labs/agent-skills”
   • [github] “npx skills use vercel-labs/agent-skills@web-design-guidelines | claude”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed6/10

   Docs describe simple single-command paths to install a skill (`$skill-installer <name>`, `/skills`, `/plugins`) and to scaffold one via `@plugin-creator`, suggesting a fast setup, but no source gives an explicit time-to-first-working-skill benchmark or a hands-on account confirming a sub-five-minute experience. Missing for 10: an explicit quickstart timing claim, a step-by-step first-run walkthrough, and independent/community confirmation that installation actually completes quickly.

   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`. For example, to install the `$linear` ski…”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”
   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”

   proof ↗⚑ flag

2. developerEvery skill documents what it does and when it activates, so I can predict my agent's new behavior before it surprises me

   weight 2 · round to skills.sh
   skills.sh✓fullclaimed7/10

   The SKILL.md spec and docs show skills carry a required name/description that agents load at startup specifically 'to know when it might be relevant,' plus optional fields like allowed-tools for scoping behavior, directly matching the story's ask for documented activation conditions. Missing for 10: independent hands-on confirmation that these descriptions reliably predict agent behavior, and no example showing a rich 'what it does' body beyond the discovery metadata.

   • [claimed-docs] “At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.”
   • [claimed-docs] “Discovery: At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.”
   • [claimed-docs] “| `allowed-tools` | No | Space-separated string of pre-approved tools the skill may use. (Experimental)”
   • [claimed-docs] “Skills can also bundle scripts, reference materials, templates, and other resources.”

   proof ↗⚑ flag

   Codex Plugins~partialcommunity7/10

   Docs describe the SKILL.md format (must include name and description) and state that the skill-creation flow explicitly asks 'what the skill does, when it should trigger, and whether it should stay instruction-only,' directly matching the story's ask for documented behavior and activation conditions. However, there's no evidence of a consistent, enforced convention across all published skills/plugins for describing trigger conditions, and community commentary flags real unpredictability in skill activation ('you just selectively append more text to prompt and pray'), reflecting some doubt about whether documented behavior always matches actual activation. Missing for 10: independent/hands-on verification that documented triggers reliably predict actual activation, and evidence that all shipped skills (not just the creator flow) enforce clear 'when it activates' documentation.

   • [claimed-docs] “The creator asks what the skill does, when it should trigger, and whether it should stay instruction-only or include scripts.”
   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [community] “At least MCPs can be unit tested. With Skills however, you just selectively append more text to prompt and pray.”

   proof ↗⚑ flag

Install

1. developerInstall a skill collection with one documented command — a package-manager one-liner, CLI, or in-agent marketplace command — and it is active in my next session

   weight 3 · round to skills.sh
   skills.sh✓fullcommunity8/10

   The `npx skills add <repo>` one-liner installs skills directly into the target agent's directory (project or global, via symlink or copy), making them available in the next session without extra steps, and this is documented extensively with concrete CLI examples and flags. missing for 10: independent hands-on confirmation that installed skills are actually picked up in a fresh agent session (only vendor docs/README evidence), and community comments raise concerns about missing version-pinning/uninstall documentation clarity.

   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “# GitHub shorthand (owner/repo) npx skills add vercel-labs/agent-skills”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [github] “Global | -g | ~/<agent>/skills/ | Available across all projects”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [github] “Supports **OpenCode**, **Claude Code**, **Codex**, **Cursor**, and [73 more](#supported-agents).”
   • [claimed-docs] “Cross-product reuse: Build a skill once and use it across any skills-compatible agent.”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins✓fullclaimed7/10

   Docs explicitly describe a one-command install flow — `/plugins` browser or `$skill-installer <name>` — and state that after installing a plugin you should 'start a new session before using its bundled skills or tools,' directly matching the story's install-then-next-session pattern. Additional CLI support (`codex plugin marketplace add`) reinforces multiple documented one-liner paths. Missing for 10: independent/hands-on confirmation that installed skills actually activate reliably in the next session (only vendor docs, no community verification of this specific flow).

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`. For example, to install the `$linear` ski…”
   • [claimed-docs] “$skill-installer linear”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”

   proof ↗⚑ flag

2. developerChoose install scope — project-local files committed with my repo, or user-global across all projects

   weight 2 · round to skills.sh
   skills.sh✓fullclaimed9/10

   Docs explicitly define two install scopes: Project (default, `./<agent>/skills/`, committed with project) and Global (`-g` flag, `~/<agent>/skills/`, available across all projects), with CLI examples using -g flag. This directly matches the story's project-local vs user-global choice. Missing for 10: no independent hands-on report verifying the -g flag behavior in practice beyond docs.

   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [github] “Global | -g | ~/<agent>/skills/ | Available across all projects”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team | **Global** | `-g` | `~/<agent>/skills/` | Av…”
   • [github] “Install to user directory instead of project”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design -g -a claude-code -y”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed5/10

   Evidence shows skills can be committed to a repo (`.agents/skills` scanned from cwd up to repo root, teams can check in module-specific skills) and installed to a local Codex setup via `$skill-installer`, implying both project-local and user-global-like scopes exist, but there's no explicit documentation contrasting a 'project-local vs user-global' install flag or config for plugins/skills. missing for 10: explicit docs on a user-global (all-projects) install location/flag distinct from project-local, and confirmation that plugin (not just skill) installs support both scopes.

   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [claimed-docs] “teams can check in skills relevant to a working folder. For example, skills only relevant to a microservice or a module.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`. For example, to install the `$linear` ski…”

   proof ↗⚑ flag

3. developerInstall only the specific skills I want from a collection instead of taking the whole bundle

   weight 2 · round to skills.sh
   skills.sh✓fullclaimed9/10

   The CLI explicitly supports installing named skills via `--skill` flags (e.g., `--skill frontend-design --skill skill-creator`) or `'*'` for all, plus `--list` to preview skills before installing, directly enabling selective installation instead of a whole bundle. missing for 10: independent/hands-on third-party confirmation beyond the vendor's own docs/README (community commentary is about ranking/versioning, not selective install itself).

   • [github] “Install specific skills by name (use `'*'` for all skills)”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design --skill skill-creator”
   • [github] “npx skills add vercel-labs/agent-skills --list”
   • [github] “List available skills without installing”
   • [github] “# List skills in a repository npx skills add vercel-labs/agent-skills --list”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed6/10

   Docs show `$skill-installer <name>` to install individual curated skills (e.g. `$skill-installer linear`, `$skill-installer gh-address-comments`) rather than a whole bundle, and plugins are installed individually via `/plugins` browser. However, plugins themselves appear to be installed as whole packages (a plugin can bundle multiple skills/tools) with no documented way to cherry-pick a subset of skills from within a single installed plugin. missing for 10: evidence of selecting/excluding individual skills within one plugin bundle at install time, independent hands-on confirmation of partial-bundle installs.

   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`. For example, to install the `$linear` ski…”
   • [claimed-docs] “$skill-installer linear”
   • [claimed-docs] “Curated skills can be installed by name (defaults to `skills/.curated`): $skill-installer gh-address-comments ”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”

   proof ↗⚑ flag

Lifecycle

1. developerList what is installed and remove skills cleanly, without orphaned files or lingering instructions

   weight 1 · round to skills.sh
   skills.sh~partialcommunity6/10

   The CLI ships explicit `skills list`/`ls` (list installed skills, akin to npm ls) and `skills remove` commands, and its symlink-based install architecture ('single source of truth, easy updates') implies removal is straightforward rather than leaving scattered copies. However, no evidence explicitly confirms that removal deletes all agent-specific copies/instructions without orphaned files, and a community commenter specifically questioned whether uninstall/version-pinning is well-documented at all, adding some doubt about thoroughness. missing for 10: explicit documentation or hands-on proof that `skills remove` cleans up all installed files/prompts with zero orphaned artifacts, and a rebuttal to the community claim that uninstall isn't clearly documented.

   • [github] “List all installed skills. Similar to `npm ls`.”
   • [claimed-docs] “skills list | List installed skills (alias: `ls`)”
   • [github] “Remove installed skills from agents”
   • [github] “npx skills remove --agent claude-code cursor my-skill”
   • [github] “Remove installed skills from agents.”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [github] “**Symlink** (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed3/10

   Docs show how to list/browse installed plugins and skills (the /plugins browser, Skills sidebar, /skills command) and how to install them via skill-installer or plugin marketplace add, but there is no documented uninstall/removal command or explanation of how installed skill files, manifests, or config.toml entries are cleaned up. Missing for 10: documented uninstall/remove command, confirmation that removal deletes .agents/skills files and marketplace/config entries without leaving orphaned instructions, and any hands-on evidence of clean removal.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [claimed-docs] “In the ChatGPT desktop app, open **Skills** in the sidebar to view and explore skills created across your projects.”
   • [claimed-docs] “In Codex CLI or the IDE extension, run `/skills` or type `$` to mention a skill.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to skills.sh
   skills.sh~partialcommunity4/10

   The `skills` CLI (search, list, add, update, remove) lets an AI-native user perform most of what the skills.sh leaderboard/browsing UI shows, giving a non-UI, scriptable path to core functionality, but there is no documented REST/HTTP API — a Hacker News commenter explicitly asks 'Please make a rest API!', implying one does not exist and CLI-only access is required. missing for 10: a documented REST/programmatic API mirroring the website's leaderboard/ranking views, independent confirmation that all UI features (e.g., leaderboard filtering, skill descriptions) are reachable via CLI/API.

   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “Search for skills interactively or by keyword”
   • [github] “List all installed skills. Similar to `npm ls`.”
   • [github] “Update installed skills to latest versions”
   • [github] “Remove installed skills from agents”
   • [community] “Please make a rest API!”
   • [claimed-docs] “Skills Leaderboard”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Codex Plugins documentation only describes UI (ChatGPT Plugins tab, desktop Skills sidebar) and CLI (`/plugins`, `$skill-installer`, `codex plugin marketplace add`) workflows for installing and managing plugins/skills; there is no mention of a public API for plugin/skill management, and a direct probe for an OpenAPI/swagger spec returned 404 on all candidate paths, indicating no documented API parity.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”
   • [claimed-docs] “In the ChatGPT desktop app, open **Skills** in the sidebar to view and explore skills created across your projects.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.openai.com/openapi.json, https://developers.openai.com/swagger.json, https://deve…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to skills.sh
   skills.sh~partialclaimed5/10

   Skills are stored locally as plain SKILL.md markdown files (not a proprietary DB), with symlinked canonical copies and a skills-lock.json manifest, so a user's installed skill data is inherently in an open, portable format and never trapped in a hosted service. However, there is no explicit 'export' command, no documented data-portability policy, and no first-party statement addressing leaving/migrating the skill library. missing for 10: explicit export/backup tooling, documented data-portability guarantee, independent confirmation that all state (not just skill files) is locally recoverable.

   • [github] “Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [claimed-docs] “`skills experimental_install` | Restore skills from skills-lock.json”
   • [claimed-docs] “skills experimental_install | Restore skills from skills-lock.json”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team | **Global** | `-g` | `~/<agent>/skills/` | Av…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   No evidence of any data export feature, open-format export, or account/data portability mechanism for Codex Plugins; the documentation focuses on plugin/skill installation and creation, not user data export or exit.

   ⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to skills.sh
   skills.sh~partialprobed4/10

   The CLI's source is publicly hosted and readable on GitHub (github.com/vercel-labs/skills), with docs, code, and even AGENTS.md file linked directly, so an AI-native user can browse and read the source. However, no evidence pack item confirms an explicit open-source license (e.g., MIT/Apache) attached to the repo. Missing for 10: explicit license file/name, confirmation of license terms, any independent audit noting license type.

   • [probe] “official CLI documented at https://github.com/vercel-labs/skills”
   • [github] “npx skills add vercel-labs/agent-skills”
   • [claimed-docs] “skills experimental_install | Restore skills from skills-lock.json”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed3/10

   There is a public GitHub repo (openai/plugins) exposing plugin source code and structure, offering some read access, but none of the evidence cites an explicit open-source license (e.g., MIT/Apache) governing the Codex Plugins product or its source. missing for 10: explicit license declaration, confirmation that core Codex Plugins platform code (not just example plugins) is open-sourced, independent corroboration of license terms.

   • [github] “plugins/figma for `use_figma`, Code to Canvas, Code Connect, and design system rules”
   • [github] “`plugins/notion` for planning, research, meetings, and knowledge capture”
   • [claimed-docs] “"name": "slack", ... "category": "Communication"”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to skills.sh
   skills.sh~partialprobed4/10

   The CLI (`npx skills`) is open-source on GitHub and runs entirely client-side against arbitrary git/HTTP sources with no vendor backend dependency, so a user can effectively run their own copies without a hosted service — but there is no explicit self-hosting guide, deployment doc, or Docker/server setup for the leaderboard site (skills.sh) itself. missing for 10: explicit self-host/deployment instructions for the skills.sh service, confirmation that the leaderboard or discovery backend can be run independently, and any first-party statement framing self-hosting as a supported use case.

   • [probe] “official CLI documented at https://github.com/vercel-labs/skills”
   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “Use the same command for public and private repositories. The CLI uses the authentication already configured for the repository URL”
   • [claimed-docs] “Skills Leaderboard”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round to skills.sh
   skills.sh~partialcommunity4/10

   Skills are installed as local files (project/global dirs or symlinks) and the CLI ships an explicit `remove`/`skills remove` command to delete installed skills per-agent, giving users direct control over what's stored and its removal. However, there's no documented policy on telemetry/usage data retention, no account-level data deletion, and a community comment even claims uninstall/versioning isn't well documented (though contradicted by the gh docs). Missing for 10: explicit data-retention/telemetry policy, account-data deletion guarantees, independent confirmation that remove fully purges data.

   • [github] “Remove installed skills from agents”
   • [github] “npx skills remove --agent claude-code cursor my-skill”
   • [github] “Remove installed skills from agents.”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Evidence only describes what limited profile data is shared during plugin sign-in (name, email, picture) and that this doesn't grant automatic data access, but there is no mention of controls for retaining, exporting, or deleting plugin-related data or conversation history. Missing for 10: any documented retention policy, data deletion mechanism, or user-facing controls to manage stored data for plugins/skills.

   • [claimed-docs] “Signing in shares only your name, email address, and profile picture, when available, with the partner. It doesn't grant the plugin access t…”
   • [claimed-docs] “Signing in shares only your name, email address, and profile picture, when available, with the partner.”

   proof ↗⚑ flag

2. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   skills.sh—none0/10

   No evidence in the pack mentions telemetry, usage tracking, analytics collection, or any opt-out mechanism for skills.sh/the skills CLI.

   ⚑ flag

   Codex Plugins—none0/10

   The evidence pack covers plugin/skill installation, marketplace, and sign-in data sharing scope, but contains no mention of telemetry or usage-tracking opt-out controls for Codex Plugins.

   ⚑ flag

Review

1. engineering-leadReview exactly what instructions and scripts a skill will add — list contents before installing and read every file afterward

   weight 3 · round drawn
   skills.sh~partialcommunity5/10

   skills.sh supports listing skills before installing (`--list`, `skills find`, interactive search) and installs skills as visible files on disk (project or global directories, with symlinks to a canonical copy), so a lead can inspect files after install. However, there is no dedicated command or documented workflow for previewing full skill contents/scripts before installation or for auditing all bundled scripts after install — only skill names/descriptions are surfaced up front, and community discussion flags trust concerns about unreviewed instructions in skills. Missing for 10: a pre-install content/diff preview command, explicit documentation of a post-install file-audit workflow, and resolution of the community-raised trust concern about hidden instructions.

   • [github] “List available skills without installing”
   • [github] “npx skills add vercel-labs/agent-skills --list”
   • [github] “# List skills in a repository npx skills add vercel-labs/agent-skills --list”
   • [github] “**Project** | (default) | `./<agent>/skills/` | Committed with your project, shared with team”
   • [github] “Symlink (Recommended) | Creates symlinks from each agent to a canonical copy. Single source of truth, easy updates.”
   • [claimed-docs] “At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.”
   • [community] “This is a really good implementation, but I don't lean too heavily into skills especially not other people's. If I'm doing design who's to s…”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed5/10

   Skills are documented as plain directories (SKILL.md plus optional scripts/references) and plugins ship with an inspectable manifest (`.codex-plugin/plugin.json`), and curated skills/plugins live in public GitHub repos that can be browsed before installing via `$skill-installer` or the plugin marketplace. However, there is no documented in-product command or UI that explicitly lists a skill/plugin's file contents prior to installation, nor any stated post-install audit/read workflow for engineering leads. Missing for 10: a dedicated 'preview/list contents' command before install, and confirmation that all installed files (scripts, resources) are surfaced for review after install rather than just SKILL.md.

   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [claimed-docs] “It scaffolds the required `.codex-plugin/plugin.json` manifest and can also generate a local marketplace entry for testing.”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [claimed-docs] “Curated skills can be installed by name (defaults to `skills/.curated`): $skill-installer gh-address-comments ”
   • [github] “`plugins/notion` for planning, research, meetings, and knowledge capture”

   proof ↗⚑ flag

Trust

1. engineering-leadThe project documents its security posture — what skills can execute, the trust model for third-party skills, and any telemetry or data collection

   weight 2 · round to Codex Plugins
   skills.sh—none0/10

   The evidence shows only a single experimental 'allowed-tools' field for pre-approving tools a skill may use, but no explicit documentation of a security model, sandboxing/execution boundaries, trust model for third-party skill authors, or telemetry/data-collection disclosure. Community commentary even raises unaddressed trust concerns about running other people's skill instructions, with no vendor response documenting mitigations.

   • [claimed-docs] “| `allowed-tools` | No | Space-separated string of pre-approved tools the skill may use. (Experimental)”
   • [community] “This is a really good implementation, but I don't lean too heavily into skills especially not other people's. If I'm doing design who's to s…”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins~partialclaimed4/10

   Docs disclose some security-relevant details (sign-in only shares name/email/photo, submission/review portal for publishing plugins, MCP-based server capability exposure) but there is no consolidated security posture document covering what skills can execute, an explicit trust model for third-party skills, or telemetry/data collection practices beyond OAuth sign-in scope. Missing for 10: dedicated security/trust-model documentation, explicit execution/sandboxing model for skills, and telemetry/data-collection disclosure beyond sign-in scopes.

   • [claimed-docs] “Signing in shares only your name, email address, and profile picture, when available, with the partner. It doesn't grant the plugin access t…”
   • [claimed-docs] “Signing in shares only your name, email address, and profile picture, when available, with the partner.”
   • [claimed-docs] “Use the plugin submission portal to submit a plugin for review when you're ready to publish it for public use.”
   • [claimed-docs] “Plugins use the [Model Context Protocol (MCP)] to expose server-backed capabilities to ChatGPT and Codex.”
   • [claimed-docs] “If you're migrating an existing Claude Code plugin or connector, first review [Submit your Claude Code plugin to OpenAI] to see what you nee…”

   proof ↗⚑ flag

Authoring

1. developerAuthor a new skill from a documented template — a SKILL.md with name and description frontmatter — without reverse-engineering existing skills

   weight 3 · round to Codex Plugins
   skills.sh✓fullclaimed7/10

   The CLI ships a dedicated `skills init [name]` command that explicitly creates a new SKILL.md template, letting a developer scaffold a skill without copying an existing one, and the companion specification documents required frontmatter fields (name/description used for discovery) that such a template would include. Missing for 10: no example of the actual generated SKILL.md content/frontmatter shown in evidence, and no independent/community confirmation that `skills init` output is complete or bug-free.

   • [github] “Create a new SKILL.md template”
   • [github] “`skills init [name]` | Create a new SKILL.md template”
   • [github] “npx skills init my-skill”
   • [claimed-docs] “skills init [name] | Create a new SKILL.md template”
   • [claimed-docs] “At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.”
   • [claimed-docs] “| `allowed-tools` | No | Space-separated string of pre-approved tools the skill may use. (Experimental)”

   proof ↗⚑ flag

   Codex Plugins✓fullcommunity8/10

   Docs explicitly define the SKILL.md format (name + description frontmatter, directory with optional scripts/references) and describe a guided `@plugin-creator`/skill-creator flow that asks what the skill does, when it triggers, and whether to include scripts — enabling authoring from a documented template rather than reverse-engineering. Community evidence corroborates developers building their own skills this way. Missing for 10: a full worked SKILL.md example/template file shown verbatim and independent hands-on verification of the authoring flow.

   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “The creator asks what the skill does, when it should trigger, and whether it should stay instruction-only or include scripts.”
   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest and can also…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”
   • [community] “The skills that matter most to me are the ones I create myself (with the skill creator skill) that are very specific and proprietary... I mi…”

   proof ↗⚑ flag

2. developerThe collection ships a meta-skill or tool that guides my agent through writing, improving, and packaging new skills

   weight 2 · round to Codex Plugins
   skills.sh~partialclaimed5/10

   The CLI ships `skills init` to scaffold a new SKILL.md template and references a `skill-creator` skill by name as an installable skill, plus a separate `skills-ref validate` tool for checking a skill's structure — together these cover pieces of authoring/packaging support. However there's no detailed documentation of a guided 'writing/improving' workflow or what the skill-creator meta-skill actually instructs the agent to do. missing for 10: full documentation of the skill-creator/meta-skill's guidance content, an explicit 'improve an existing skill' workflow, and independent hands-on corroboration that authoring guidance works as intended.

   • [github] “Create a new SKILL.md template”
   • [github] “`skills init [name]` | Create a new SKILL.md template”
   • [github] “npx skills init my-skill”
   • [github] “npx skills add vercel-labs/agent-skills --skill frontend-design --skill skill-creator”
   • [claimed-docs] “skills-ref validate ./my-skill”

   proof ↗⚑ flag

   Codex Plugins✓fullcommunity8/10

   Codex ships explicit meta-skills for this: the `@plugin-creator` skill scaffolds `.codex-plugin/plugin.json`, wires MCP servers, and generates a marketplace entry (docs-10/15/18/24), a skill-creation flow that interviews the user on triggers/scripts (docs-7), and a recorder that drafts a reusable skill from a demonstrated workflow (docs-16), covering write/improve/package end-to-end. Community commentary corroborates the general pattern of using a 'skill creator skill' to build proprietary skills (comm-1). Missing for 10: independent hands-on account specifically of using @plugin-creator/skill-installer rather than general skills discussion, and no evidence of an 'improve existing skill' iteration workflow beyond initial creation.

   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest and can also…”
   • [claimed-docs] “The plugin-creator skill will create the plugin folder, create the required `.codex-plugin/plugin.json`, and add MCP server wiring for the p…”
   • [claimed-docs] “It scaffolds the required `.codex-plugin/plugin.json` manifest and can also generate a local marketplace entry for testing.”
   • [claimed-docs] “For the fastest setup, use the built-in `@plugin-creator` skill. It scaffolds the required `.codex-plugin/plugin.json` manifest”
   • [claimed-docs] “The creator asks what the skill does, when it should trigger, and whether it should stay instruction-only or include scripts.”
   • [claimed-docs] “The recorder captures the workflow, inspects the steps, and drafts a reusable skill from the demonstration.”
   • [community] “The skills that matter most to me are the ones I create myself (with the skill creator skill) that are very specific and proprietary... I mi…”

   proof ↗⚑ flag

Spec

1. developerSkills follow the open Agent Skills specification so the same skill folder is valid beyond this one vendor's tooling

   weight 2 · round to skills.sh
   skills.sh✓fullclaimed8/10

   The CLI is built around the open Agent Skills specification (agentskills.io) which explicitly promises 'Build a skill once and use it across any skills-compatible agent,' includes a spec validator (skills-ref validate) and a SKILL.md template generator, and the tool itself supports 75+ different agents rather than locking skills to one vendor's runtime. No evidence contradicts spec portability itself (community complaints target leaderboard fairness and package-management UX, not spec compliance). Missing for 10: independent third-party confirmation that a skill authored via this tool works unmodified in a wholly separate, non-Vercel skills implementation.

   • [claimed-docs] “Cross-product reuse: Build a skill once and use it across any skills-compatible agent.”
   • [claimed-docs] “skills-ref validate ./my-skill”
   • [github] “Supports **OpenCode**, **Claude Code**, **Codex**, **Cursor**, and [75 more](#supported-agents).”
   • [github] “Create a new SKILL.md template”
   • [claimed-docs] “| `allowed-tools` | No | Space-separated string of pre-approved tools the skill may use. (Experimental)”

   proof ↗⚑ flag

   Codex Plugins~partialcommunity6/10

   Docs describe skills as a directory with a SKILL.md containing required `name`/`description` fields plus optional scripts/references (docs-13), which matches the general shape of the open Agent Skills format, and community commentary links Codex Skills to the same lineage as Claude Skills (comm-6). However, no evidence explicitly states conformance to a named open 'Agent Skills specification' or demonstrates a skill folder authored elsewhere working unmodified in Codex. Missing for 10: explicit statement of spec compliance/versioning, and a concrete cross-vendor portability example or test.

   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “A skill packages instructions, resources, and optional scripts so either product can follow a workflow reliably.”
   • [community] “Yes! I was raving about Claude Skills a few days ago, and excited they come to Codex as well!”

   proof ↗⚑ flag

Maintenance

1. developerThe collection is actively maintained — recent releases, triaged issues, and accepted community contributions

   weight 2 · round drawn
   skills.sh—none0/10

   The evidence pack contains extensive CLI/feature documentation but no release history, changelog, issue triage activity, or accepted PR/contribution data indicating active maintenance; community comments even question missing package-management basics (updates, version-pinning, uninstalls), but this is skepticism, not concrete evidence of stale maintenance, so it doesn't meet the bar for 'disputed' either.

   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   The evidence pack documents plugin/skill features and how-tos but contains no information about release cadence, issue triage, or accepted community contributions for the openai/plugins repository — no changelog, commit history, issue tracker activity, or PR merge data is cited. Community comments present are about skills vs MCP design tradeoffs, not maintenance activity.

   ⚑ flag

Testing

1. developerThe collection maintains tests or evals for its skills so changes are verified against regressions rather than shipped on vibes

   weight 2 · round drawn
   skills.sh—none0/10

   skills.sh/vercel-labs skills is a CLI for installing, updating, and managing skills packages, but nothing in the evidence pack mentions tests, evals, CI checks, or regression verification for the skills themselves; community comments even criticize lack of basic package-management documentation, and there is no mention of quality assurance for skill content.

   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   The evidence pack documents skill/plugin creation, installation, and marketplace workflows but contains no mention of automated tests, evals, or regression suites for skills; a community comment even contrasts skills unfavorably with MCP by noting skills are 'append more text to prompt and pray' rather than testable. No vendor documentation describes any verification harness for skill quality.

   • [community] “At least MCPs can be unit tested. With Skills however, you just selectively append more text to prompt and pray.”
   • [claimed-docs] “A skill is a directory with a `SKILL.md` file plus optional scripts and references. The `SKILL.md` file must include `name` and `description…”
   • [claimed-docs] “Codex scans `.agents/skills` in every directory from your current working directory up to the repository root.”

   proof ↗⚑ flag

Pinning

1. engineering-leadControl when skill changes reach my team — pinned versions or a lockfile rather than silent behind-the-back updates

   weight 1 · round to skills.sh
   skills.sh!disputedcontradicted3/10

   Docs mention an experimental `skills-lock.json` and `experimental_install`/`experimental_sync` commands that hint at a lockfile mechanism, but these are explicitly labeled experimental and there's no first-party documentation of pinning specific skill versions or preventing silent updates — `skills update` appears to always pull latest. A community reviewer directly disputes this, asking why none of these 'npm for skills' tools document version-pinning or controlled updates at all. missing for 10: documented pin/lock command with team workflow guidance, evidence the lockfile actually prevents silent updates, independent confirmation the experimental restore feature works as a version-control mechanism.

   • [claimed-docs] “`skills experimental_install` | Restore skills from skills-lock.json”
   • [claimed-docs] “skills experimental_install | Restore skills from skills-lock.json”
   • [claimed-docs] “skills experimental_install") | Restore skills from skills-lock.json”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Evidence covers installing plugins/skills, marketplace sources, and manifest scaffolding, but nothing describes version pinning, a lockfile, or any mechanism to prevent automatic/silent skill updates for a team.

   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”

   proof ↗⚑ flag

Updates

1. developerThere is a documented update path — marketplace auto-updates or an explicit update command — so I get fixes without reinstalling from scratch

   weight 3 · round to skills.sh
   skills.sh✓fullcommunity8/10

   The CLI documents an explicit `skills update [skills...]` command that updates installed skills to latest versions, either all at once or by name, and even a lock-file based `skills experimental_install` for restoring versions, giving developers a documented update path without full reinstall (gh-13, gh-26, gh-42, docs-9, docs-2). A HN commenter voices generic skepticism that 'npm for skills' tools lack update docs, but this is not a concrete hands-on failure of skills.sh's actual `update` command, so it reads as skepticism/confusion rather than a contradiction. Missing for 10: independent/hands-on confirmation that `skills update` actually fetches newer versions correctly, and no mention of automatic marketplace-triggered updates (only manual command).

   • [github] “Update installed skills to latest versions”
   • [github] “npx skills update # Update a single skill by name npx skills update my-skill”
   • [github] “npx skills update frontend-design web-design-guidelines”
   • [claimed-docs] “skills update [skills...] | Update skills to latest versions”
   • [claimed-docs] “`skills experimental_install` | Restore skills from skills-lock.json”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   Evidence covers plugin installation (`/plugins`, `codex plugin marketplace add`) and creation/submission workflows, but nowhere documents an explicit update/upgrade command or auto-update behavior for already-installed plugins to receive fixes without reinstalling.

   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser.”
   • [claimed-docs] “Use `codex plugin marketplace add` to add and track a marketplace source instead of editing `config.toml` by hand.”
   • [claimed-docs] “In Codex CLI, enter `/plugins` to open the plugin browser. Install a plugin from a configured marketplace, then start a new session before u…”
   • [claimed-docs] “Open the Plugins tab to browse and install plugins. After installation, you can use plugins in Chat or Work in ChatGPT, or in Codex. Install…”

   proof ↗⚑ flag

2. developerReleases ship with notes or a changelog so I can see what changed in the skills before I take an update

   weight 1 · round drawn
   skills.sh—none0/10

   The CLI has an `update` command and lock-file restore mechanism, but there is no evidence anywhere in the pack of release notes, a changelog, or per-skill version history a developer could review before running an update; a community comment explicitly notes these 'npm for Skills' tools don't document versioning/update details at all.

   • [github] “Update installed skills to latest versions”
   • [github] “npx skills update # Update a single skill by name npx skills update my-skill”
   • [claimed-docs] “skills experimental_install | Restore skills from skills-lock.json”
   • [community] “Why do none of these 'npm for Skills' document any way to do basic package management things like updates, version-pinning, or even uninstal…”

   proof ↗⚑ flag

   Codex Plugins—none0/10

   No evidence in the pack mentions release notes, version changelogs, or any versioning information for plugins or skills before updating; the docs cover installation, creation, and marketplace submission but nothing about update transparency.

   ⚑ flag