Skills for Real Engineers 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 skills.sh
   Skills for Real Engineers—none0/10

   The evidence pack describes numerous existing skills (tdd, grilling, triage, setup-matt-pocock-skills) and packaging/distribution mechanics (npx skills, Claude plugin marketplace), but nothing documents a meta-skill, spec, or template that an agent would follow to author and package a brand-new SKILL.md from scratch within this project's own conventions.

   ⚑ 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
   Skills for Real Engineers~partialclaimed4/10

   The docs describe simple CLI install commands (`npx skills`, `claude plugins install mattpocock-skills`, `npx skills update`) that could in principle be scripted, but the accompanying setup skill explicitly interviews the user ('Ask you which issue tracker you want to use') and other examples show a human typing a slash command, not a fully headless agent-run flow. missing for 10: explicit non-interactive/CI flag or documented flow for an agent to run install end-to-end without any prompts, and confirmation that the interactive setup step can be skipped or automated.

   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [claimed-docs] “Ask you which issue tracker you want to use (GitHub, Linear, or local files)”
   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”

   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 drawn
   Skills for Real Engineers~partialprobed5/10

   The product's entire mechanism is agent-oriented markdown docs (SKILL.md, CONTEXT.md files) explicitly written for agents to read and act on, and it documents raw.githubusercontent URLs an agent could be pointed at directly. However, there is no evidence of a dedicated llms.txt for this product itself — the probe shows only GitHub's own generic llms.txt (unrelated to this project) and a 404 for skills.md, so the specific llms.txt convention is not supported, only the broader 'agent-readable docs' pattern. missing for 10: a product-specific llms.txt file, and confirmation that agents can be pointed at a single canonical docs entry point rather than individual SKILL.md files.

   • [claimed-docs] “Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user.”
   • [claimed-docs] “Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**”
   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”
   • [github] “Here's an example [`CONTEXT.md`]... Which one is easier to read?”
   • [probe] “PROBE llms.txt: HTTP 200 at https://github.com/llms.txt # GitHub > GitHub is a developer platform for building, shipping, and maintaining s…”
   • [probe] “PROBE docs-md: HTTP 404 at https://github.com/mattpocock/skills.md”

   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
   Skills for Real Engineers—none0/10

   The evidence describes skill files consumed by interactive coding agents (Claude Code, Cursor, etc.) that rely on human interviewing/grilling and manual slash-command invocation, with no mention of a CLI flag, non-interactive mode, or CI/automation pipeline usage. Nothing in the docs, GitHub, or community evidence discusses running the skills headlessly or in a CI pipeline.

   ⚑ 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 userConnect an agent via an official MCP server

   weight 3 · round drawn
   Skills for Real Engineers—none0/10

   Evidence shows distribution via npm CLI, Claude Code plugin marketplace, and file-copy installation, but nowhere does it mention an MCP server for agents to connect to. Since this is a skills/plugin package (not itself an agent), the axis is a fair question, but there is no evidence of an official MCP server offering.

   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”

   proof ↗⚑ flag

   skills.sh—none0/10

   skills.sh is a CLI package manager that installs skill files/prompts into agent directories (via add/use/symlink mechanisms), not an MCP server; no evidence anywhere in the pack mentions an MCP server or MCP protocol integration, only file-based/CLI installation across supported agents.

   • [github] “npx skills add vercel-labs/agent-skills”
   • [github] “Target specific agents (e.g., `claude-code`, `codex`)”
   • [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.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to skills.sh
   Skills for Real Engineers✓fullclaimed7/10

   The product ships an official CLI (`npx skills`, with `npx skills update` to pull latest changes) and is also installable via the Claude Code plugin CLI route (`claude plugins install mattpocock-skills`), matching the AI-native CLI story. Missing for 10: independent hands-on verification of the CLI's full command set and behavior beyond first-party docs.

   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”

   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 userBuild against official SDKs

   weight 2 · round drawn
   Skills for Real Engineers—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—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 Skills for Real Engineers
   Skills for Real Engineers~partialclaimed6/10

   The skill bundle includes several skills that produce AI-generated insights/suggestions from a user's own project data — a visual refactor-worthiness report (docs-18), bug diagnosis from a repro (docs-19), diff review against standards (docs-14), and issue triage/sorting (docs-30, docs-34) — but these are discrete slash-command skills rather than a unified 'insights' surface, and there's no evidence of a dashboard or proactive analytics view. missing for 10: a consolidated insights UI/report aggregating findings, independent hands-on evidence of the insight-generating skills actually producing useful output, and evidence these insights update automatically rather than being invoked per-skill.

   • [claimed-docs] “Find the modules worth refactoring, as a visual report.”
   • [claimed-docs] “Diagnose a hard bug, starting from a repro that fails.”
   • [claimed-docs] “Review a diff against your standards and against the spec.”
   • [claimed-docs] “Sort raw issues into work someone can pick up.”

   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
   Skills for Real Engineers—none0/10

   The skills are built around interactive, human-in-the-loop workflows (grilling/interviewing the user, confirming test seams, triage state machines) rather than unattended background automation; the project's own philosophy explicitly rejects processes that 'take away your control' in favor of user-confirmed steps. No evidence of scheduling, background triggers, or autonomous execution without human interaction is present in the pack.

   • [github] “They help you align with the agent before you get started, and think deeply about the change you're making. Use them _every_ time you want t…”
   • [claimed-docs] “Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**”
   • [claimed-docs] “Verify the claim. Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps.”
   • [github] “Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control”

   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 drawn
   Skills for Real Engineers—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—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 Skills for Real Engineers
   Skills for Real Engineers✓fullclaimed8/10

   The skills are designed to be invoked and operated conversationally: users type slash commands (e.g., /grill-with-docs) and the agent then interviews/grills the user in natural language to reach shared understanding before acting (docs-43, gh-6, docs-6/26/33). This natural-language interaction model is central and repeated across multiple skill docs (grilling, triage, TDD flows). Missing for 10: independent hands-on confirmation that the natural-language command flow works smoothly in practice (community evidence only critiques prose quality, not the interaction mechanism), and no demonstration of free-form (non-slash) natural language command parsing beyond the interview pattern.

   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [github] “getting the agent to ask you detailed questions about what you're building”
   • [claimed-docs] “Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**”
   • [claimed-docs] “Interview the user relentlessly until you reach a shared understanding.”
   • [github] “They help you align with the agent before you get started, and think deeply about the change you're making. Use them _every_ time you want t…”
   • [claimed-docs] “Turn an agreed conversation into a written spec.”

   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 userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Skills for Real Engineers—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—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 userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Skills for Real Engineers—none0/10

   The evidence describes an update mechanism (`npx skills update`, 'nothing updates behind your back') but there is no documentation of semantic versioning, an API surface, or any deprecation policy for skills as they evolve or are removed. Missing for 10: any explicit version numbering scheme, changelog, or documented deprecation/backwards-compatibility policy for the skill files or plugin.

   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   proof ↗⚑ 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
   Skills for Real Engineers—none0/10

   The skill set is built around structured, one-at-a-time workflows (grilling, triage state machine, TDD, spec-to-ticket) rather than any documented bulk/batch processing across many items simultaneously; no evidence describes running a skill across multiple issues, files, or specs in one operation. Missing for 10: any documented bulk/batch command or workflow, evidence of parallel/multi-item processing, and independent confirmation of such usage.

   • [claimed-docs] “Move issues on the project issue tracker through a small state machine of triage roles.”
   • [claimed-docs] “Move issues on the project issue tracker through a small state machine of triage roles, categorise, verify, grill if needed, and write agent…”
   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”

   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 Skills for Real Engineers
   Skills for Real Engineers~partialclaimed4/10

   The product offers two install modes—a locked, read-only bundle that only updates via an explicit `npx skills update` pull, or an editable copy where skills become 'ordinary files you own' in your repo—which gives some control over when changes land and implies normal git-based versioning/rollback, but there is no explicit changelog, diff view, or rollback command for the skills themselves. Missing for 10: dedicated version history or diff/review UI for skill changes, an explicit rollback mechanism, and any evidence of reviewing skill updates before applying them (beyond opting into `update`).

   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   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
   Skills for Real Engineers~partialclaimed6/10

   Docs explicitly claim the collection 'works with any agent' — listing Claude Code, Cursor, Codex, Copilot — and show at least one harness-specific install path (Claude Code plugin marketplace vs. generic `npx skills` copy/subscribe modes), supporting cross-agent installability. However, evidence lacks concrete per-harness instructions for Cursor, Codex, or Copilot individually (only Claude Code's plugin route is documented in detail), and no hands-on confirmation that the same skill set actually functions identically across harnesses. Missing for 10: explicit install/config steps for Cursor, Codex, and Copilot, and independent verification that per-harness behavior matches claims.

   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”

   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 drawn
   Skills for Real Engineers✓fullclaimed8/10

   Docs explicitly state skills are written as ordinary markdown files into the repo that you own and can edit, not a proprietary format, and work across multiple harnesses (Claude Code, Cursor, Codex, Copilot). This directly matches the story's plain-file, portable-across-harness claim. Missing for 10: independent hands-on confirmation that files are literally copy-pasteable markdown (only vendor docs/ADR cited) and no explicit demonstration of moving skills to a different harness in practice.

   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   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
   Skills for Real Engineers~partialclaimed6/10

   The aihero.dev/skills page functions as a lightweight catalog listing all 25 skills with one-line descriptions (docs-11 through docs-23, docs-30/35/37, docs-42/43), and the project is also listed in Claude Code's official plugin marketplace (docs-10), letting a developer browse before installing. However there's no evidence of search, filtering, ratings, or a leaderboard-style comparison across skills/authors. Missing for 10: searchable/filterable registry UI, ratings or usage leaderboard, independent confirmation of the marketplace listing's browsability.

   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “Find out which skill to use for the situation you are in.”
   • [claimed-docs] “Turn an agreed conversation into a written spec.”
   • [claimed-docs] “Sort raw issues into work someone can pick up.”

   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
   Skills for Real Engineers✓fullclaimed8/10

   The product ships via Claude Code's official plugin marketplace (docs-10), as an npx-installed, updatable managed bundle (docs-1, docs-4/31, docs-41), or as editable files committed directly into the project repo (docs-2, docs-24), and is agent-agnostic/MIT-licensed so a lead can standardize it across a whole team's tools (docs-42). This covers all three named distribution paths (marketplace, subscribe/shared-source, and in-repo files). Missing for 10: no explicit 'shared git repo' distribution mode distinct from marketplace/npx, and no independent/community confirmation that team-wide rollout works smoothly in practice beyond first-party docs.

   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”

   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
   Skills for Real Engineers—none0/10

   The evidence describes manual invocation — 'Install the ones you want, then type a slash command' (docs-43) and 'Use them every time you want to make a change' (gh-1/gh-4) — rather than automatic, context-triggered activation via engineered descriptions. There is a 'find out which skill to use' meta-skill (docs-23) but it's itself a skill you must invoke, not evidence of automatic description-based dispatch. No documentation or independent evidence shows the agent autonomously selecting/activating skills from task context.

   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [claimed-docs] “Find out which skill to use for the situation you are in.”
   • [github] “They help you align with the agent before you get started, and think deeply about the change you're making. Use them _every_ time you want t…”
   • [github] “They help you align with the agent before you get started, and think deeply about the change you're making. Use them every time you want to …”

   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
   Skills for Real Engineers~partialclaimed6/10

   Docs show a simple two-step install path ("Install the ones you want, then type a slash command" and `claude plugins install mattpocock-skills`), plus npx-based add/update commands, suggesting a fast setup, but there is no explicit quickstart walkthrough or timed benchmark confirming a five-minute install-to-working-skill experience, and no independent hands-on report timing the process. missing for 10: an actual quickstart guide/tutorial with step timings, independent/hands-on confirmation of install speed, and evidence that a first skill run succeeds quickly without extra config.

   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”

   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 drawn
   Skills for Real Engineers✓fullcommunity7/10

   Each skill ships a SKILL.md/one-line description stating its purpose and trigger (e.g., TDD skill's red-green rules, triage skill's state machine, grilling skill's interview process, and the aihero.dev list of 25 skills each with a one-line 'what it does' summary), and activation is explicit and user-controlled via install + slash command rather than silent background changes ('Nothing updates behind your back', 'Install the ones you want, then type a slash command'). A community thread does critique the prose quality/clarity of some SKILL.md files as having 'little utility,' which tempers confidence but doesn't concretely contradict that each skill documents what/when it activates. missing for 10: independent verification that every one of the 25 skills' docs clearly states activation triggers (not just a sample), and resolution of the community critique about jargon-heavy or low-utility prose in some skill docs.

   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”
   • [claimed-docs] “Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user.”
   • [claimed-docs] “Red before green. Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.”
   • [claimed-docs] “Move issues on the project issue tracker through a small state machine of triage roles.”
   • [claimed-docs] “Move issues on the project issue tracker through a small state machine of triage roles, categorise, verify, grill if needed, and write agent…”
   • [claimed-docs] “Turn an agreed conversation into a written spec.”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [community] “Critique of Matt Pocock's skill files: he has a hand-wavy approach to engineering in a silo, then uses that output as a foundation for tools…”

   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
   Skills for Real Engineers~partialclaimed6/10

   First-party docs give a genuine one-liner (`claude plugins install mattpocock-skills`) now that the pack is in Claude Code's official marketplace, plus an `npx skills update` command for the managed-bundle mode, both documented as first-party. However there's no independent/hands-on confirmation that the skill set is actually active in the next session, and the exact single-command install syntax for the other supported agents (Cursor, Codex, Copilot) beyond Claude Code isn't shown — only 'install the ones you want, then type a slash command' is vague. missing for 10: independent hands-on confirmation of post-install activation, explicit one-liner install commands for non-Claude agents.

   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “Install the ones you want, then type a slash command.”

   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
   Skills for Real Engineers~partialclaimed4/10

   The docs describe two install modes—copying editable skill files into a repo (project-local, committed) versus subscribing to a managed, read-only, auto-updating bundle via the Claude Code plugin marketplace—but never explicitly frame the second mode as 'user-global across all projects' vs project-local; scope (per-project vs per-user) is never directly addressed. Missing for 10: explicit documentation of a user-global/home-directory install option and confirmation that the plugin/subscribe mode applies across all projects rather than just being non-editable.

   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”

   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
   Skills for Real Engineers~partialclaimed5/10

   The docs explicitly state "Install the ones you want, then type a slash command" (mattpocock-skills-docs-43), indicating selective installation is possible, and the file-copy mode writes only the skills you choose as editable files (mattpocock-skills-docs-24). However, the marketplace/plugin route is described as installing 'the whole set as a managed, read-only bundle' (mattpocock-skills-docs-1, docs-41), so whole-bundle install remains the primary documented path and there's no detailed CLI flag or command example showing per-skill selection. Missing for 10: a concrete CLI command/flag demonstrating selecting individual skills, and independent/hands-on confirmation that partial installs work as described.

   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   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
   Skills for Real Engineers—none0/10

   Evidence covers installation modes (editable copy vs. read-only subscribed bundle) and updating via `npx skills update`, but there is no mention of any command or mechanism to list installed skills or cleanly uninstall/remove them without leftover files.

   ⚑ 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 skills.sh
   Skills for Real Engineers—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~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 drawn
   Skills for Real Engineers~partialclaimed5/10

   The product ships skills as plain, MIT-licensed markdown files copied directly into the user's repo (mattpocock-skills-docs-2, docs-24, docs-42), meaning the artifacts themselves are already open, human-readable, and fully owned/editable with no proprietary lock-in or vendor updates without consent (docs-4, docs-31). However, there is no explicit 'export my data' feature or documentation addressing exporting configuration state (issue tracker settings, triage labels, ADRs) generated while using the skills, nor any statement about a formal data-portability/leave process. missing for 10: explicit data-export tooling/documentation, evidence about exporting generated artifacts (ADRs, triage state, configs) beyond the skill files themselves, and any independent confirmation of portability.

   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”

   proof ↗⚑ 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 for Real Engineers
   Skills for Real Engineers✓fullclaimed8/10

   The product's source lives in a public GitHub repo (github.com/mattpocock/skills) and is explicitly described as MIT-licensed with 25 skills, confirming both open-source hosting and license terms; docs also emphasize files are 'ordinary files you own and can edit,' reinforcing readability/openness of the source. Missing for 10: no explicit LICENSE file citation or independent third-party confirmation of the license text.

   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”

   proof ↗⚑ 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

4. ai-native userSelf-host the core product

   weight 3 · round to Skills for Real Engineers
   Skills for Real Engineers✓fullclaimed7/10

   The product is an MIT-licensed, MIT-open GitHub repo of skill files that are copied directly into the user's own repo as editable, ordinary files ('you own and can edit... nothing updates behind your back'), which is effectively full self-hosting since there is no server component to host beyond the files themselves. This is corroborated by both the docs and the ADR describing the plugin/fork model. missing for 10: no independent/hands-on confirmation of a full self-hosted install working end-to-end outside vendor docs, and no explicit statement addressing infrastructure/hosting concerns (e.g., private registries, offline use).

   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   proof ↗⚑ flag

   skills.sh~partialprobed4/10

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

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

   proof ↗⚑ flag

1. ai-native userControl data retention and deletion

   weight 2 · round to skills.sh
   Skills for Real Engineers—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~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

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

   weight 2 · round drawn
   Skills for Real Engineers—none0/10

   The evidence pack covers installation modes, skill content, and community commentary but contains no mention of telemetry, analytics, or usage tracking of any kind, let alone an opt-out mechanism. Since this is a tool a buyer could reasonably ask about data collection, absence of any documentation on the topic means the axis applies but is unaddressed.

   ⚑ flag

   skills.sh—none0/10

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

   ⚑ flag

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 Skills for Real Engineers
   Skills for Real Engineers~partialclaimed6/10

   The skills ship as plain, open-source Markdown SKILL.md files (visible directly via raw GitHub links quoted in evidence) and are described as 'ordinary files you own and can edit' with no silent updates, which supports post-install readability and transparency. However, there is no documented pre-install 'list contents' or dry-run command shown in the evidence — inspection relies on browsing the public GitHub repo rather than a built-in review step. Missing for 10: an explicit CLI/list command to preview a skill's files before installing, and independent confirmation that all installed files match what's shown pre-install.

   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “Test only at pre-agreed seams. Before writing any test, write down the seams under test and confirm them with the user.”
   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   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 to Skills for Real Engineers
   Skills for Real Engineers~partialclaimed4/10

   The docs give some trust-relevant transparency—skills are shipped as plain, ownable files that 'nothing updates behind your back' and can be pulled explicitly via `npx skills update`, plus acceptance into Claude Code's official marketplace as a vetted distribution channel—but there is no explicit security-posture document covering what skills can execute (tool/permission scope), a formal trust model for arbitrary third-party skills, or any statement on telemetry/data collection. missing for 10: explicit execution/permission model for skills, documented telemetry or data-collection policy, formal third-party skill vetting/trust framework beyond marketplace acceptance.

   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   proof ↗⚑ 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 skills.sh
   Skills for Real Engineers—none0/10

   The evidence describes an existing bundle of pre-built skills (tdd, grilling, triage, setup) that you can install, subscribe to, or copy as editable files, but there is no documented template, generator, or guide specifically for authoring a brand-new SKILL.md with frontmatter — the closest thing to a 'template' would be reverse-engineering the shipped example skills, which the story explicitly excludes. Community commentary even critiques the prose quality of existing skill files rather than pointing to any authoring template.

   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”
   • [community] “Critique of Matt Pocock's skill files: he has a hand-wavy approach to engineering in a silo, then uses that output as a foundation for tools…”

   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 skills.sh
   Skills for Real Engineers—none0/10

   The evidence describes many individual skills (TDD, triage, grilling, spec-writing, setup-per-repo config) but none of them describe a meta-skill that guides writing, improving, or packaging new skills for the collection itself — 'setup-matt-pocock-skills' only scaffolds per-repo config for existing skills, not skill authoring.

   ⚑ 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 to skills.sh
   Skills for Real Engineers~partialclaimed6/10

   Evidence shows skill folders are plain, editable files (SKILL.md) that work across multiple agents (Claude Code, Cursor, Codex, Copilot) and were accepted into Claude Code's official plugin marketplace, implying broad cross-tool portability consistent with an open skill format. However, none of the evidence explicitly names or cites conformance to the 'Agent Skills specification' itself, so spec-adherence is inferred rather than documented. Missing for 10: explicit reference to the Agent Skills spec, independent confirmation that the folder validates against that spec outside vendor claims.

   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Works with any agent Claude Code · Cursor · Codex · Copilot · 25 skills · MIT”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”

   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 to Skills for Real Engineers
   Skills for Real Engineers~partialcommunity3/10

   There's some indirect signal of active development — an ADR documenting a recent architectural decision (shipping as a Claude Code plugin) and acceptance into Claude Code's official marketplace, plus an update mechanism (`npx skills update`) implying ongoing releases — but no direct evidence of a release cadence, an issue tracker for the project itself being triaged, or accepted external community contributions/PRs. Community commentary (comm-1/2/3) shows engagement and critique of content quality but says nothing about maintenance cadence or contribution acceptance. missing for 10: changelog/release history, evidence of external PRs being merged, evidence of issues on the repo itself being triaged.

   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [community] “Matt Pocock is still a nice guy with reasonable opinions and shares a lot with us. I've personally learned from reading his skills.”
   • [community] “Critique of Matt Pocock's skill files: he has a hand-wavy approach to engineering in a silo, then uses that output as a foundation for tools…”

   proof ↗⚑ 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
   Skills for Real Engineers—none0/10

   The evidence describes TDD/testing as a discipline the skills teach users to apply to their own code, but nothing shows the maintainer running automated tests, evals, or CI against the skill prompts themselves to catch regressions. A community critique even suggests the SKILL.md prose lacks rigor and 'should be checked... by another LLM,' implying no such verification pipeline exists.

   • [claimed-docs] “Red before green. Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.”
   • [claimed-docs] “Tests verify behavior through public interfaces, not implementation details.”
   • [community] “Critique of Matt Pocock's skill files: he has a hand-wavy approach to engineering in a silo, then uses that output as a foundation for tools…”

   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 Skills for Real Engineers
   Skills for Real Engineers~partialclaimed7/10

   Docs explicitly state skills don't auto-update and changes only land when the user runs `npx skills update`, and offer a 'copy' mode where files become editable local copies you fully own — both give an engineering lead control over rollout timing. However, there is no mention of an actual lockfile, pinned semantic versions, or per-team version pinning mechanism, so the control is manual/all-or-nothing rather than granular version pinning. Missing for 10: explicit lockfile/version-pin mechanism, ability to pin to a specific historical version rather than just delaying `update`, independent confirmation of update-control behavior in practice.

   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”
   • [claimed-docs] “copies editable skill files into your project, so you can hack on them and make them your own”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”

   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 drawn
   Skills for Real Engineers✓fullclaimed8/10

   Docs explicitly document an update path: `npx skills update` pulls latest changes on demand (nothing auto-updates behind your back) for the copy-into-repo mode, and a separate managed/marketplace mode (Claude Code plugin, `claude plugins install mattpocock-skills`) that updates as the author ships. Both paths are documented first-party. missing for 10: independent/hands-on confirmation that `npx skills update` or marketplace auto-update actually works in practice, and no changelog/version-diff evidence showing successful update history.

   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`.”
   • [claimed-docs] “Nothing updates behind your back; pull my latest changes when you want them with `npx skills update`”
   • [claimed-docs] “It writes the skills into your repo as ordinary files you own and can edit. Nothing updates behind your back”
   • [claimed-docs] “`mattpocock-skills` was accepted into **Claude Code's official marketplace**... `claude plugins install mattpocock-skills` is now the docume…”
   • [claimed-docs] “subscribe to the set as a read-only, always-current bundle you don't edit, rather than a fork you own”
   • [claimed-docs] “installs the whole set as a managed, read-only bundle that updates when I ship, so you subscribe rather than fork”

   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
   Skills for Real Engineers—none0/10

   Evidence describes an update mechanism (`npx skills update`, subscribing to a read-only bundle) but nothing about release notes, a changelog, or version history that would let a developer see what changed before updating.

   ⚑ 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