Anthropic Skills vs skills.sh

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 Anthropic Skills
   Anthropic Skills✓fullclaimed9/10

   Anthropic ships a dedicated 'skill-creator' meta-skill for creating new skills and iteratively improving/benchmarking them, plus an official template SKILL.md and the open agentskills.io specification detailing required frontmatter, description rules, and folder structure (scripts/references/assets) — together these let an agent author and package a skill end-to-end per spec. Missing for 10: independent hands-on account of an agent successfully using skill-creator to author a new skill from scratch (community evidence only discusses skill triggering/invocation issues, not authoring/packaging).

   • [claimed-docs] “A skill for creating new skills and iteratively improving them.”
   • [claimed-docs] “benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy”
   • [claimed-docs] “Create new skills, modify and improve existing skills, and measure skill performance.”
   • [claimed-docs] “Replace with description of the skill and when Claude should use it.”
   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”
   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “name: skill-name description: A description of what this skill does and when to use it.”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”
   • [claimed-docs] “scripts/ # Optional: executable code references/ # Optional: documentation assets/ # Optional: templates, resources”
   • [claimed-docs] “add a skill, and test it locally using the \`--plugin-dir\` flag”

   proof ↗⚑ flag

   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

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
   Anthropic Skills~partialclaimed4/10

   Docs show scriptable install commands (`/plugin marketplace add`, `/plugin install ...`) and a Skills API for uploading/managing skills programmatically, which could in principle be run non-interactively by automation. However, none of the evidence explicitly documents a promptless, fully headless end-to-end install flow (e.g., a CLI flag or API call an agent invokes autonomously without any human-run slash command or confirmation step). Missing for 10: explicit non-interactive/headless install documentation, evidence of an agent autonomously choosing and installing a skill without human-issued commands, and confirmation that no interactive confirmation/prompt is required during install.

   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “/plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “Upload and manage through the [Skills API](https://platform.claude.com/docs/en/api/skills/create)”
   • [claimed-docs] “Upload and manage through the [Skills API]”
   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [github] “/plugin install document-skills@anthropic-agent-skills /plugin install example-skills@anthropic-agent-skills”
   • [github] “/plugin marketplace add anthropics/skills”

   proof ↗⚑ flag

   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

Agent access

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

   weight 2 · round to Anthropic Skills
   Anthropic Skills✓fullprobed8/10

   Anthropic's docs site serves a working llms.txt (HTTP 200) plus .md variants of docs pages (e.g. skills.md), explicitly designed for agent/LLM consumption, and Claude Code skills follow the agentskills.io open spec. missing for 10: no independent/community confirmation that agents were actually pointed at llms.txt and successfully used it end-to-end.

   • [probe] “PROBE llms.txt: HTTP 200 at https://code.claude.com/llms.txt # Claude Code Docs > Official documentation for Claude Code, Anthropic's agent…”
   • [probe] “PROBE docs-md: HTTP 200 at https://code.claude.com/docs/en/skills.md > ## Documentation Index > Fetch the complete documentation index at: h…”
   • [claimed-docs] “Claude Code skills follow the [Agent Skills](https://agentskills.io) open standard, which works across multiple AI tools.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to skills.sh
   Anthropic Skills~partialclaimed5/10

   Skills can be invoked programmatically via the Messages API (`container` parameter, Skills API for upload/management), which is inherently headless and scriptable, implying CI/automation use is possible. However, there is no explicit documentation or example of running Skills in a CI pipeline, headless mode, or automated build system — missing for 10: explicit CI/headless workflow examples, CLI flags for non-interactive automation, and independent evidence of production CI usage.

   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “Skills are specified using the `container` parameter in the Messages API. You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API](https://platform.claude.com/docs/en/api/skills/create)”
   • [claimed-docs] “You can include up to 20 Skills for each request.”
   • [claimed-docs] “This guide shows you how to use both pre-built and custom Skills with the Claude API.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Anthropic Skills
   Anthropic Skills~partialcommunity5/10

   Docs show that Claude Code plugins — the packaging mechanism used alongside Skills — can bundle MCP servers together with skills, agents, and hooks (anthropic-skills-docs-6, -7, -21, -35), implying an ai-native user could add an MCP server via the plugin/marketplace system. However, Skills themselves are a separate mechanism (plain SKILL.md instructions), and community commentary explicitly notes skills and MCP are distinct, sometimes competing approaches with skills lacking MCP's tool-calling functionality (anthropic-skills-comm-3, -10). Missing for 10: concrete first-party guide/example of installing an MCP server via a skill or plugin, hands-on confirmation that MCP tools become usable once added this way, and clarity on whether Skills (as opposed to Claude Code plugins broadly) directly expose MCP tool use.

   • [claimed-docs] “Create custom plugins to extend Claude Code with skills, agents, hooks, and MCP servers.”
   • [claimed-docs] “Plugins (self-contained directories with skills, agents, hooks, or a `.claude-plugin/plugin.json` manifest) | `/plugin-name:hello` | Sharing…”
   • [claimed-docs] “Plugins let you extend Claude Code with custom functionality that can be shared across projects and teams. This guide covers creating your o…”
   • [claimed-docs] “Plugins let you extend Claude Code with custom functionality that can be shared across projects and teams.”
   • [community] “A skill is a markdown & yaml file on your filesystem... but skills don't cover a lot of the functionality that MCP offers.”
   • [community] “If you can write a bash or python script, or an API or MCP to do what you want, then write it and include it in the skill. Keep top-level co…”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round to skills.sh
   Anthropic Skills~partialprobed5/10

   Skills are used and managed through Claude Code, which is described as a terminal-based agentic CLI tool, via slash commands like `/skill-name`, `/plugin marketplace add`, and `--plugin-dir` flags for local testing; the `skill-creator` skill also supports building/testing skills. However, there is no evidence of a dedicated standalone 'skills' CLI binary or command set (e.g., `skills create`, `skills validate`) separate from Claude Code's general slash-command interface, and API-based skill management (Skills API) is not CLI-based at all. Missing for 10: a purpose-built skills CLI tool, independent hands-on confirmation of CLI-based skill workflows, and CLI support outside the Claude Code product.

   • [claimed-docs] “Claude uses skills when relevant, or you can invoke one directly with `/skill-name`.”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “add a skill, and test it locally using the \`--plugin-dir\` flag”
   • [claimed-docs] “A skill for creating new skills and iteratively improving them.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://code.claude.com/llms.txt # Claude Code Docs > Official documentation for Claude Code, Anthropic's agent…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Anthropic Skills
   Anthropic Skills✓fullclaimed8/10

   Skills can be driven via the documented Messages API `container` parameter with `skill_id`, uploaded/managed through a dedicated Skills API, and invoked with up to 20 skills per request, giving AI-native users a clear programmatic path distinct from the chat UI. missing for 10: independent/hands-on corroboration of the API workflow itself (community evidence only covers Claude Code skill-triggering reliability, not the Messages/Skills API), and no evidence of API rate limits, SDKs, or error handling specifics.

   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “Skills are specified using the `container` parameter in the Messages API. You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API](https://platform.claude.com/docs/en/api/skills/create)”
   • [claimed-docs] “You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API]”
   • [claimed-docs] “This guide shows you how to use both pre-built and custom Skills with the Claude API.”

   proof ↗⚑ flag

   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

6. ai-native userBuild against official SDKs

   weight 2 · round to Anthropic Skills
   Anthropic Skills✓fullclaimed7/10

   Docs describe a dedicated Skills API and Messages API `container` parameter for programmatically attaching Skills (with `skill_id`, versioning, up to 20 per request), plus upload/management endpoints, which constitutes an official API/SDK surface to build against. Missing for 10: explicit language-specific SDK code samples (Python/TypeScript) and independent hands-on developer reports confirming building production integrations against this API.

   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “Skills are specified using the `container` parameter in the Messages API. You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API](https://platform.claude.com/docs/en/api/skills/create)”
   • [claimed-docs] “You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API]”
   • [claimed-docs] “This guide shows you how to use both pre-built and custom Skills with the Claude API.”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round to Anthropic Skills
   Anthropic Skills~partialcommunity4/10

   Skills can package data-handling capabilities (PDF, xlsx, docx extraction/manipulation) and are pitched for 'analyzing data using your organization's specific workflows,' giving Claude a path to generate insights from user data, but this is a general extensibility framework rather than a built-in insights/dashboard feature, and community reports show skills are frequently not invoked or unreliable in practice. missing for 10: a dedicated insights/analytics feature, proactive suggestion UI, and evidence that skills reliably surface unsolicited insights rather than requiring explicit triggering.

   • [claimed-docs] “Claude already knows a lot about understanding PDFs, but is limited in its ability to manipulate them directly (e.g. to fill out a form). Th…”
   • [claimed-docs] “Skills extend Claude’s capabilities by packaging your expertise into composable resources for Claude, transforming general-purpose agents in…”
   • [github] “whether that's creating documents with your company's brand guidelines, analyzing data using your organization's specific workflows, or auto…”
   • [github] “whether that's creating documents with your company's brand guidelines, analyzing data using your organization's specific workflows, or auto…”
   • [community] “Vercel found: In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the ski…”
   • [community] “Same, I have a bunch of skills defined with proper YAML headers and semantic triggers... it's hit or miss if it picks up on the skill -- usu…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Anthropic Skills—none0/10

   Skills are packaged instructions/capabilities that Claude loads and uses during a session (invoked automatically or via /skill-name), but the evidence pack contains no mention of scheduling, triggers, or background/autonomous execution outside an active user session. Plugins and marketplaces cover distribution, not autonomous background automation.

   • [claimed-docs] “Create a `SKILL.md` file with instructions, and Claude adds it to its toolkit.”
   • [claimed-docs] “Claude uses skills when relevant, or you can invoke one directly with `/skill-name`.”
   • [claimed-docs] “If Claude thinks the skill is relevant to the current task, it will load the skill by reading its full `SKILL.md` into context.”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Anthropic Skills
   Anthropic Skills!disputedcontradicted5/10

   Anthropic's docs claim Claude will autonomously discover and load relevant Skills to perform delegated work ('Claude uses skills when relevant... transforms general-purpose agents into specialized agents'), which matches the story of delegating tasks to a built-in assistant. However, hands-on community reports directly contradict reliable automatic delegation: a Vercel eval found the skill was never invoked in 56% of cases despite being available, and multiple users report invocation is 'hit or miss' even with proper YAML triggers, often requiring explicit manual pointers. Missing for 10: independent benchmarks showing consistent autonomous task delegation, and resolution of the documented invocation-reliability gap.

   • [claimed-docs] “Claude uses skills when relevant, or you can invoke one directly with `/skill-name`.”
   • [claimed-docs] “Skills extend Claude’s capabilities by packaging your expertise into composable resources for Claude, transforming general-purpose agents in…”
   • [community] “Vercel found: In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the ski…”
   • [community] “I have an incredibly hard time getting them to use Skills at all, even when asked. I saw someone's analysis finding their agents were more a…”
   • [community] “Same, I have a bunch of skills defined with proper YAML headers and semantic triggers... it's hit or miss if it picks up on the skill -- usu…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Anthropic Skills
   Anthropic Skills!disputedcontradicted5/10

   Anthropic's docs explicitly promise natural-language operation: Claude 'uses skills when relevant' by matching the task to a skill's description, in addition to explicit `/skill-name` invocation (anthropic-skills-docs-2, -3, -25, -34). However, hands-on community reports concretely contradict this: a Vercel eval found skills were never invoked in 56% of cases despite being available, and multiple practitioners report skills are 'hit or miss' or require explicitly telling Claude to use them even when asked (anthropic-skills-comm-7, -8, -9). Missing for 10: reliable first-party benchmark of natural-language trigger accuracy, and resolution of the discovery/triggering inconsistency reported by users.

   • [claimed-docs] “Claude uses skills when relevant, or you can invoke one directly with `/skill-name`.”
   • [claimed-docs] “Skills add optional features: a directory for supporting files, frontmatter to [control whether you or Claude invokes them]... and the abili…”
   • [claimed-docs] “If Claude thinks the skill is relevant to the current task, it will load the skill by reading its full `SKILL.md` into context.”
   • [claimed-docs] “frontmatter to [control whether you or Claude invokes them](#control-who-invokes-a-skill)”
   • [community] “Vercel found: In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the ski…”
   • [community] “I have an incredibly hard time getting them to use Skills at all, even when asked. I saw someone's analysis finding their agents were more a…”
   • [community] “Same, I have a bunch of skills defined with proper YAML headers and semantic triggers... it's hit or miss if it picks up on the skill -- usu…”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round to Anthropic Skills
   Anthropic Skills~partialclaimed3/10

   The evidence shows an open, machine-readable specification document (agentskills.io/specification.md) defining the SKILL.md format and frontmatter fields, plus references to a 'Skills API' for programmatic upload/management — these are the closest analogs to a downloadable machine-readable spec, but neither is an OpenAPI document nor explicitly offered as a downloadable API spec for the Skills/Messages API itself. Missing for 10: an actual OpenAPI/JSON-schema file for the Skills API endpoints, explicit download link/format, and independent confirmation that AI-native tooling consumes it.

   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”
   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”
   • [claimed-docs] “Upload and manage through the [Skills API](https://platform.claude.com/docs/en/api/skills/create)”
   • [claimed-docs] “This guide shows you how to use both pre-built and custom Skills with the Claude API.”

   proof ↗⚑ flag

   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

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

   weight 1 · round to Anthropic Skills
   Anthropic Skills~partialclaimed4/10

   Skills invoked via the Messages API run inside Anthropic's 'code execution environment' (a sandboxed container), and plugin docs mention testing skills locally with the `--plugin-dir` flag before sharing/distribution, which implies some separation from a live/production setup. However, there is no explicit documentation of a dedicated sandbox/staging environment for testing skills against non-production data, no discussion of data isolation guarantees, and no hands-on validation of this specific safety property. Missing for 10: explicit sandbox/staging environment documentation, data-isolation guarantees, and independent confirmation that local/test skill runs cannot touch production data.

   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “add a skill, and test it locally using the \`--plugin-dir\` flag”
   • [claimed-docs] “Skills are specified using the `container` parameter in the Messages API. You can include up to 20 Skills for each request.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Anthropic Skills—none0/10

   Evidence covers Skills' structure, plugins, marketplaces, and API usage, but there is no mention of API versioning schemes or a documented deprecation policy for Skills/Claude API. Missing for 10: any documentation of API version numbers, backward-compatibility guarantees, or deprecation timelines/policy.

   ⚑ flag

   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

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

   weight 2 · round to skills.sh
   Anthropic Skills~partialcommunity3/10

   Skills can bundle scripts that operate on multiple files (e.g., the PDF skill 'merges multiple PDFs' and fills forms across documents), suggesting some batch/bulk-processing capability, and skills may include arbitrary scripts/executable code for such tasks. However, there is no explicit documentation or example demonstrating bulk operations across many items (e.g., batch-processing hundreds of records/files) as a core Skills feature, and community feedback focuses on skill-triggering reliability rather than bulk-processing performance. Missing for 10: explicit bulk/batch-processing examples or docs, evidence of scale (many items processed reliably), and independent confirmation that bulk workflows work as intended.

   • [claimed-docs] “Claude already knows a lot about understanding PDFs, but is limited in its ability to manipulate them directly (e.g. to fill out a form). Th…”
   • [claimed-docs] “skills can bundle additional files within the skill directory and reference them by name from `SKILL.md`.”
   • [claimed-docs] “scripts/ # Optional: executable code references/ # Optional: documentation assets/ # Optional: templates, resources”
   • [community] “If you can write a bash or python script, or an API or MCP to do what you want, then write it and include it in the skill. Keep top-level co…”

   proof ↗⚑ flag

   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

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

   weight 1 · round to Anthropic Skills
   Anthropic Skills~partialclaimed4/10

   Docs mention plugin marketplaces provide 'version tracking' and 'versioned releases', and the API lets you specify an optional `version` for skill_id, implying some versioning support. However there is no documented review/approval workflow or explicit rollback mechanism — skills are just files/folders, so any versioning or rollback would rely on external git tooling not described as a first-class feature. missing for 10: explicit rollback command/feature, in-product review or approval workflow for skill changes, changelog/diff tooling, independent confirmation of version tracking in practice.

   • [claimed-docs] “A **plugin marketplace** is a catalog that lets you distribute plugins to others. Marketplaces provide centralized discovery, version tracki…”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”
   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “Plugins (self-contained directories with skills, agents, hooks, or a `.claude-plugin/plugin.json` manifest) | `/plugin-name:hello` | Sharing…”

   proof ↗⚑ flag

   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

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
   Anthropic Skills~partialclaimed4/10

   Docs state Claude Code skills follow the open 'Agent Skills' standard which 'works across multiple AI tools' (agentskills.io spec), implying cross-agent portability, and the spec itself defines a tool-agnostic SKILL.md format. However, there is no concrete evidence of per-harness install instructions or documented support for Codex, Cursor, or other named agents — all install/marketplace instructions (plugin marketplace, /plugin install, container skill_id) are Claude-specific. Missing for 10: explicit Codex/Cursor installation docs, per-harness setup instructions, and independent confirmation that the same skill collection actually runs unmodified in non-Anthropic tools.

   • [claimed-docs] “Claude Code skills follow the [Agent Skills](https://agentskills.io) open standard, which works across multiple AI tools.”
   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”
   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”

   proof ↗⚑ flag

   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

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 Anthropic Skills
   Anthropic Skills✓fullclaimed9/10

   Docs confirm skills are just plain folders with a SKILL.md file (YAML frontmatter + markdown) plus optional scripts/references/assets, explicitly following the open Agent Skills standard (agentskills.io) that 'works across multiple AI tools,' and GitHub examples show these as ordinary files/folders anyone can read, copy, or fork. This directly supports the portability claim of non-proprietary, cross-harness markdown format. missing for 10: no independent hands-on report of someone actually carrying a skill folder to a different (non-Anthropic) harness and confirming it works unmodified.

   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”
   • [claimed-docs] “scripts/ # Optional: executable code references/ # Optional: documentation assets/ # Optional: templates, resources”
   • [claimed-docs] “Claude Code skills follow the [Agent Skills](https://agentskills.io) open standard, which works across multiple AI tools.”
   • [github] “Skills are simple to create - just a folder with a `SKILL.md` file containing YAML frontmatter and instructions.”
   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”

   proof ↗⚑ flag

   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

Discovery

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

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

   Anthropic provides a discoverable catalog via the official `anthropics/skills` GitHub repo (browsable list of example skills) and a formal 'plugin marketplace' concept described as providing 'centralized discovery, version tracking, automatic updates' that developers can add and install from (`/plugin marketplace add`, `/plugin install`). However, there's no evidence of a dedicated searchable registry UI, ratings/leaderboard, or cross-marketplace search — discovery is limited to browsing a GitHub repo or manually adding marketplace sources one at a time. Missing for 10: a searchable/filterable registry UI, popularity or leaderboard signals, and evidence of a unified cross-marketplace search experience.

   • [claimed-docs] “A **plugin marketplace** is a catalog that lets you distribute plugins to others. Marketplaces provide centralized discovery, version tracki…”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”
   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [github] “These example skills are all already available to paid plans in Claude.ai.”
   • [github] “/plugin install document-skills@anthropic-agent-skills /plugin install example-skills@anthropic-agent-skills”

   proof ↗⚑ flag

   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

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
   Anthropic Skills✓fullclaimed8/10

   Anthropic Skills supports distribution via plugin marketplaces (git repos or local paths), shared GitHub repos (e.g., anthropics/skills registered as a marketplace), and files committed directly to a project (.claude/skills/SKILL.md), covering all three distribution channels named in the story. Community feedback confirms real-world use of shared skill repos and marketplace installs, though adoption/triggering reliability is debated. missing for 10: independent case study of an engineering team formally rolling out a standardized skill set org-wide, and more detail on permissions/governance controls for enforcing a 'standard' team-wide set.

   • [claimed-docs] “A **plugin marketplace** is a catalog that lets you distribute plugins to others. Marketplaces provide centralized discovery, version tracki…”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”
   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [github] “/plugin install document-skills@anthropic-agent-skills /plugin install example-skills@anthropic-agent-skills”
   • [claimed-docs] “A file at `.claude/commands/deploy.md` and a skill at `.claude/skills/deploy/SKILL.md` both create `/deploy` and work the same way.”
   • [claimed-docs] “Plugins (self-contained directories with skills, agents, hooks, or a `.claude-plugin/plugin.json` manifest) | `/plugin-name:hello` | Sharing…”

   proof ↗⚑ flag

   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

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 skills.sh
   Anthropic Skills!disputedcontradicted5/10

   Anthropic's docs explicitly describe automatic activation via engineered description fields (e.g. docs-17, docs-25, docs-32, docs-44) and even ship a skill-creator tool to optimize descriptions for 'triggering accuracy' (docs-14). However, hands-on community reports directly contradict reliable auto-triggering: Vercel's eval found the skill was never invoked in 56% of cases with no improvement over baseline, and multiple users report skills are 'hit or miss' or 'incredibly hard' to get invoked even with proper YAML descriptions (comm-7, comm-8, comm-9). missing for 10: independent benchmark showing consistent correct auto-activation, and resolution of the documented reliability gap.

   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”
   • [claimed-docs] “If Claude thinks the skill is relevant to the current task, it will load the skill by reading its full `SKILL.md` into context.”
   • [claimed-docs] “benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy”
   • [claimed-docs] “description: Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when…”
   • [community] “Vercel found: In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the ski…”
   • [community] “I have an incredibly hard time getting them to use Skills at all, even when asked. I saw someone's analysis finding their agents were more a…”
   • [community] “Same, I have a bunch of skills defined with proper YAML headers and semantic triggers... it's hit or miss if it picks up on the skill -- usu…”

   proof ↗⚑ flag

   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

Onboarding

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

   weight 3 · round drawn
   Anthropic Skills~partialcommunity6/10

   Docs and GitHub show a genuinely lightweight path — a skill is 'just a folder with a SKILL.md file containing YAML frontmatter and instructions' (anthropic-skills-gh-3), installable via a single 'plugin marketplace add' + 'plugin install' command (anthropic-skills-gh-1, anthropic-skills-gh-4), which plausibly fits a five-minute window. However there's no dedicated timed 'quickstart' tutorial artifact, and community feedback shows friction getting Claude to actually invoke/use a newly installed skill reliably (anthropic-skills-comm-8, anthropic-skills-comm-9), meaning 'installed and working' isn't fully guaranteed in five minutes. Missing for 10: an explicit timed quickstart doc/tutorial, and independent hands-on confirmation of sub-5-minute install-to-working success.

   • [github] “Skills are simple to create - just a folder with a `SKILL.md` file containing YAML frontmatter and instructions.”
   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [github] “/plugin install document-skills@anthropic-agent-skills /plugin install example-skills@anthropic-agent-skills”
   • [claimed-docs] “Create a `SKILL.md` file with instructions, and Claude adds it to its toolkit.”
   • [community] “I have an incredibly hard time getting them to use Skills at all, even when asked. I saw someone's analysis finding their agents were more a…”
   • [community] “Same, I have a bunch of skills defined with proper YAML headers and semantic triggers... it's hit or miss if it picks up on the skill -- usu…”

   proof ↗⚑ flag

   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

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
   Anthropic Skills!disputedcontradicted5/10

   Anthropic's spec strongly documents that every SKILL.md must include a description of what the skill does and when to use it (frontmatter is designed to be both machine- and human-readable for predicting activation), and Claude Code/Claude API docs describe controllable invocation triggers. However, multiple hands-on community reports (Vercel eval: skill never invoked in 56% of cases despite being documented and available; users reporting 'hit or miss' triggering even with well-written descriptions) concretely contradict the promise that documented descriptions reliably predict when the agent will actually activate a skill. missing for 10: consistent, benchmarked activation reliability matching documented triggers, and independent evidence resolving the invocation unpredictability reported by users.

   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”
   • [claimed-docs] “name: skill-name description: A description of what this skill does and when to use it.”
   • [claimed-docs] “description: Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when…”
   • [claimed-docs] “Skills add optional features: a directory for supporting files, frontmatter to [control whether you or Claude invokes them]... and the abili…”
   • [community] “Vercel found: In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the ski…”
   • [community] “I have an incredibly hard time getting them to use Skills at all, even when asked. I saw someone's analysis finding their agents were more a…”
   • [community] “Same, I have a bunch of skills defined with proper YAML headers and semantic triggers... it's hit or miss if it picks up on the skill -- usu…”

   proof ↗⚑ flag

   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

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
   Anthropic Skills~partialclaimed6/10

   Anthropic documents a clear CLI install path — `/plugin marketplace add anthropics/skills` followed by `/plugin install document-skills@anthropic-agent-skills` — which registers and installs a skill collection inside Claude Code, and docs imply skills become part of Claude's toolkit thereafter. However, this is a two-step sequence rather than a single one-liner, and there is no independent/hands-on confirmation that the installed skill persists and is reliably active in the very next session (community reports focus on activation/triggering reliability, not install itself). Missing for 10: a true single-command one-liner, and first-party or community confirmation of session-persistence after install.

   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [github] “/plugin install document-skills@anthropic-agent-skills /plugin install example-skills@anthropic-agent-skills”
   • [github] “/plugin marketplace add anthropics/skills”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “/plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “A **plugin marketplace** is a catalog that lets you distribute plugins to others. Marketplaces provide centralized discovery, version tracki…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to skills.sh
   Anthropic Skills~partialclaimed4/10

   Docs show skills live in project-level directories like `.claude/skills/deploy/SKILL.md` and can be packaged into plugins shareable 'across projects and teams,' implying some notion of local vs shared scope, but there is no explicit documentation of a user-global (e.g. home-directory) skill install path or a direct project-vs-user scope toggle. missing for 10: explicit documentation of a user-global skill directory/location, explicit contrast between project-committed vs user-global install scope, and confirmation that both scopes are simultaneously supported and selectable by the developer.

   • [claimed-docs] “A file at `.claude/commands/deploy.md` and a skill at `.claude/skills/deploy/SKILL.md` both create `/deploy` and work the same way.”
   • [claimed-docs] “Plugins let you extend Claude Code with custom functionality that can be shared across projects and teams. This guide covers creating your o…”
   • [claimed-docs] “Plugins let you extend Claude Code with custom functionality that can be shared across projects and teams.”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”

   proof ↗⚑ flag

   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

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

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

   Docs show marketplace-based installs where a user can add a marketplace and then install just one named plugin (e.g. `/plugin install document-skills@anthropic-agent-skills` vs `example-skills@anthropic-agent-skills`, or `quality-review-plugin@my-plugins`) rather than every plugin in the marketplace, and `disableBundledSkills` can turn off built-in skills en masse. This demonstrates selecting a specific plugin/skill bundle out of a larger marketplace, but there's no documented mechanism to cherry-pick an individual skill from inside a single plugin bundle. Missing for 10: explicit per-skill (sub-bundle) install granularity, and independent confirmation that partial installs work as described.

   • [github] “/plugin install document-skills@anthropic-agent-skills /plugin install example-skills@anthropic-agent-skills”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “/plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “the [`disableBundledSkills`](/docs/en/settings-reference#disablebundledskills) setting, which disables every bundled skill except `/doctor`.”
   • [claimed-docs] “To turn bundled skills off, use the [`disableBundledSkills`](/docs/en/settings-reference#disablebundledskills) setting, which disables every…”

   proof ↗⚑ flag

   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

Lifecycle

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

   weight 1 · round to skills.sh
   Anthropic Skills—none0/10

   The evidence pack shows how to create, add, invoke, and disable skills (e.g., disableBundledSkills, /plugin install), but there is no documentation of a command or workflow to list all installed skills or to cleanly uninstall/remove a skill and its plugin files, hooks, or references without leftovers.

   • [claimed-docs] “the [`disableBundledSkills`](/docs/en/settings-reference#disablebundledskills) setting, which disables every bundled skill except `/doctor`.”
   • [claimed-docs] “To turn bundled skills off, use the [`disableBundledSkills`](/docs/en/settings-reference#disablebundledskills) setting, which disables every…”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [claimed-docs] “A file at `.claude/commands/deploy.md` and a skill at `.claude/skills/deploy/SKILL.md` both create `/deploy` and work the same way.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Anthropic Skills
   Anthropic Skills~partialclaimed5/10

   Docs confirm Skills can be invoked and managed programmatically via the Messages API (container parameter, skill_id/type/version, up to 20 skills per request) and via a dedicated Skills API for upload/management, giving real API-level parity for core skill usage. However, other capabilities visible in the Claude Code/Claude.ai UI — plugin marketplaces, automatic relevance-based skill loading, /plugin and /skill-name invocation, bundled-skill toggling — are documented only as CLI/UI features with no evidence of an equivalent API path. Missing for 10: API equivalents for plugin marketplace distribution, automatic skill discovery/loading parity, and confirmation that all UI-configurable settings (e.g., disableBundledSkills) are reachable via API.

   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “Skills are specified using the `container` parameter in the Messages API. You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API](https://platform.claude.com/docs/en/api/skills/create)”
   • [claimed-docs] “You can include up to 20 Skills for each request.”
   • [claimed-docs] “Upload and manage through the [Skills API]”
   • [claimed-docs] “Availability | Available to all users | Private to your workspace”
   • [claimed-docs] “A **plugin marketplace** is a catalog that lets you distribute plugins to others. Marketplaces provide centralized discovery, version tracki…”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”

   proof ↗⚑ flag

   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

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

   weight 3 · round to skills.sh
   Anthropic Skills—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

   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

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

   weight 2 · round to skills.sh
   Anthropic Skills—none0/10

   While the anthropics/skills GitHub repo makes example skill files (SKILL.md, templates) publicly readable, none of the evidence cites an open-source license for Skills, Claude Code, or the underlying product; core Claude Code/Skills functionality itself is closed, proprietary tooling with no license grant shown.

   ⚑ flag

   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

1. ai-native userControl data retention and deletion

   weight 2 · round to skills.sh
   Anthropic Skills—none0/10

   The evidence pack covers how Skills are created, invoked, packaged, and distributed, but contains no documentation about data retention policies, deletion controls, or privacy settings for skill data/usage. No mention of retention windows, user-initiated deletion, or data handling controls exists in this pack.

   ⚑ flag

   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

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 to Anthropic Skills
   Anthropic Skills~partialclaimed6/10

   Docs confirm skills are transparent, plain-text directories (SKILL.md plus optional scripts/references/assets folders) that a lead can browse in a repo/marketplace and read after installation, and plugins/marketplaces are just git repos or local paths a lead could inspect. However, there is no documented feature for listing or previewing a skill's full file contents specifically before installation (e.g., a dry-run/manifest-diff command), so the 'before install' half of the story is only implicit via manual repo browsing. missing for 10: a dedicated pre-install content-listing/manifest command, any audit/review tooling, and independent confirmation that installs can't run additional undisclosed files.

   • [claimed-docs] “scripts/ # Optional: executable code references/ # Optional: documentation assets/ # Optional: templates, resources”
   • [claimed-docs] “skills can bundle additional files within the skill directory and reference them by name from `SKILL.md`.”
   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”
   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [claimed-docs] “add a skill, and test it locally using the \`--plugin-dir\` flag”

   proof ↗⚑ flag

   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

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 drawn
   Anthropic Skills—none0/10

   The evidence pack shows extensive functional docs (SKILL.md structure, plugin marketplaces, execution environment, disableBundledSkills toggle) but no dedicated security-posture documentation addressing what skills can execute (sandboxing, permissions), a trust model for vetting third-party/marketplace skills, or telemetry/data-collection disclosures tied to skills usage.

   ⚑ flag

   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

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 Anthropic Skills
   Anthropic Skills✓fullcommunity8/10

   There is a documented open specification (agentskills.io) detailing required frontmatter (name, description, length constraints), file structure (SKILL.md plus optional scripts/references/assets folders), and even a template file (template/SKILL.md) with placeholder text, plus a dedicated skill-creator skill for authoring/improving skills without needing to reverse-engineer existing ones. Community evidence (comm-1) shows some users still had to ask others for example SKILL.md files, suggesting the template isn't universally discovered/used. missing for 10: independent hands-on confirmation that a developer successfully authored a skill purely from the template without consulting other examples, and more visibility/discoverability of the template in mainline docs.

   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “Replace with description of the skill and when Claude should use it.”
   • [claimed-docs] “name: skill-name description: A description of what this skill does and when to use it.”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”
   • [claimed-docs] “scripts/ # Optional: executable code references/ # Optional: documentation assets/ # Optional: templates, resources”
   • [claimed-docs] “A skill for creating new skills and iteratively improving them.”
   • [claimed-docs] “Create new skills, modify and improve existing skills, and measure skill performance.”
   • [community] “Github MCP: 39 tools, 30K tokens - had to disable it. Asked if anyone has a good SKILLS.md file to study.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Anthropic Skills
   Anthropic Skills✓fullclaimed8/10

   Anthropic ships a dedicated "skill-creator" meta-skill that explicitly guides creation, iteration, and improvement of skills, including benchmarking performance and optimizing description triggers for accuracy, and there's a template SKILL.md and open spec to follow. This directly matches the story of a meta-skill guiding authoring/improving/packaging skills, backed by first-party GitHub and docs evidence. Missing for 10: independent hands-on validation of the skill-creator workflow itself (community evidence only discusses skills generally, not this meta-skill specifically) and no evidence of a dedicated 'packaging for distribution' step within skill-creator beyond plugin/marketplace mechanisms.

   • [claimed-docs] “A skill for creating new skills and iteratively improving them.”
   • [claimed-docs] “benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy”
   • [claimed-docs] “Create new skills, modify and improve existing skills, and measure skill performance.”
   • [claimed-docs] “Replace with description of the skill and when Claude should use it.”
   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”

   proof ↗⚑ flag

   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

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 drawn
   Anthropic Skills✓fullclaimed8/10

   Anthropic explicitly states Claude Code skills follow the open Agent Skills standard (agentskills.io) that works across multiple AI tools, and the same SKILL.md folder format (frontmatter + markdown, optional scripts/references/assets dirs) is documented both on the vendor docs and the independent agentskills.io spec site. Missing for 10: no third-party/independent tool (outside Anthropic) is shown actually consuming the same folder, and community commentary questions skill invocation reliability rather than spec portability.

   • [claimed-docs] “Claude Code skills follow the [Agent Skills](https://agentskills.io) open standard, which works across multiple AI tools.”
   • [claimed-docs] “A skill is a directory containing, at minimum, a `SKILL.md` file”
   • [claimed-docs] “The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.”
   • [claimed-docs] “scripts/ # Optional: executable code references/ # Optional: documentation assets/ # Optional: templates, resources”
   • [claimed-docs] “The required `description` field: Must be 1-1024 characters, Should describe both what the skill does and when to use it”
   • [claimed-docs] “name: skill-name description: A description of what this skill does and when to use it.”

   proof ↗⚑ flag

   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

Maintenance

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

   weight 2 · round drawn
   Anthropic Skills—none0/10

   Evidence pack covers docs, specification, and usage patterns for Skills, but contains no information about release cadence, issue triage, or acceptance of community contributions to the anthropics/skills repository. No changelog, release notes, contributor stats, or issue-response evidence is present.

   ⚑ flag

   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

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
   Anthropic Skills—none0/10

   The skill-creator skill offers ad-hoc 'benchmark skill performance' tooling for authors (anthropic-skills-docs-14, -30), but there is no evidence of a maintained test suite, CI pipeline, or regression eval framework for the official skills collection itself. The only concrete eval-style evidence (Vercel's finding that skills were never invoked in 56% of cases) is a third-party community critique, not Anthropic's own maintained regression testing.

   • [claimed-docs] “benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy”
   • [claimed-docs] “Create new skills, modify and improve existing skills, and measure skill performance.”
   • [community] “Vercel found: In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Adding the ski…”

   proof ↗⚑ flag

   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

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 Anthropic Skills
   Anthropic Skills~partialclaimed5/10

   The Skills API explicitly supports pinning a specific version via the `container` parameter's optional `version` field when invoking a skill, and plugin manifests include a version field with marketplaces offering 'version tracking' (docs-10, docs-23, docs-27, docs-36). However, for Claude Code's locally-installed/bundled skills there is no lockfile or team-wide pinning mechanism described — marketplaces are instead touted for 'automatic updates', which is the opposite of controlled rollout, and no evidence shows a way to pin or freeze skill versions across a team's Claude Code installs. missing for 10: lockfile or pinned-version mechanism for Claude Code skill/plugin installs, evidence that automatic marketplace updates can be disabled or gated per-team, and any hands-on confirmation that version pinning works as documented.

   • [claimed-docs] “You specify Skills in the `container` parameter with a `skill_id`, `type`, and optional `version`, and they run in the code execution enviro…”
   • [claimed-docs] “Skills are specified using the `container` parameter in the Messages API. You can include up to 20 Skills for each request.”
   • [claimed-docs] “The manifest file at `.claude-plugin/plugin.json` defines your plugin's identity: its name, description, and version.”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”

   proof ↗⚑ flag

   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

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
   Anthropic Skills~partialclaimed6/10

   Docs explicitly state plugin marketplaces provide 'centralized discovery, version tracking, automatic updates' for plugins that can bundle skills, and marketplace/plugin install commands are documented (e.g. /plugin marketplace add, /plugin install). However, this update path is scoped to the plugin-marketplace distribution mechanism rather than a general update command for individually-created or hand-copied skills (e.g. skills dropped into .claude/skills/), and there's no explicit 'update' CLI verb or independent confirmation of update behavior in practice. missing for 10: an explicit 'update' command example/output, confirmation this works for non-marketplace skills, independent/hands-on evidence of auto-update actually firing.

   • [claimed-docs] “A **plugin marketplace** is a catalog that lets you distribute plugins to others. Marketplaces provide centralized discovery, version tracki…”
   • [claimed-docs] “Marketplaces provide centralized discovery, version tracking, automatic updates, and support for multiple source types, including git reposi…”
   • [claimed-docs] “/plugin marketplace add ./my-marketplace /plugin install quality-review-plugin@my-plugins”
   • [github] “You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code: /plugin marketplace a…”
   • [claimed-docs] “A plugin marketplace is a catalog that lets you distribute plugins to others.”

   proof ↗⚑ flag

   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

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
   Anthropic Skills—none0/10

   Evidence shows plugin marketplaces support 'version tracking' and skills/plugins have version fields in manifests, but there is no evidence of actual release notes or a changelog documenting what changed between skill versions before update.

   ⚑ flag

   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