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

   Superpowers includes a dedicated writing-skills SKILL.md meta-skill describing a full TDD-style workflow for authoring skills (write test cases, watch fail, write skill, watch pass, refactor) and a harness-porting spec/template for extending skills across agents, backed by an eval harness that verifies skill compliance. Community evidence corroborates the skill-authoring and self-review workflow exists and is used in practice, though with some workflow friction noted. Missing for 10: independent hands-on account of an agent actually authoring a brand-new skill end-to-end via this meta-skill, and packaging/publishing steps are only documented, not demonstrated by a third party.

   • [claimed-docs] “You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests …”
   • [claimed-docs] “Invoke relevant or requested skills BEFORE any response or action — including clarifying questions, exploring the codebase, or checking file…”
   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “This guide explains how to add support for a new harness ... so that Superpowers skills auto-trigger there the same way they do natively.”
   • [claimed-docs] “tests/` — does the plugin's non-LLM code work? ... `evals/` — do agents behave correctly on real LLM sessions?”
   • [community] “Superpowers has several skills. Its core workflow is: brainstorm to design a spec, use subagents to adversarially review its own spec/plan, …”

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

   All installation evidence describes human-run commands (`/plugin marketplace add`, `devin plugins install`, git clone steps) that differ per harness and are documented as manual steps a user performs, not a single headless, promptless path the agent runs itself end-to-end. Community commentary even notes the install mechanism is 'curl|bash but with added LLM agents,' underscoring it's not a clean self-serve agent install. No evidence shows an agent autonomously invoking these install commands without human initiation.

   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [community] “The install mechanism for the superpowers plugin for codex and opencode is .... interesting... it's like curl|bash but with added LLM agents…”

   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
   Superpowers~partialprobed5/10

   Superpowers ships extensive agent-oriented documentation (SKILL.md files as harness-agnostic 'source of truth', support for AGENTS.md/CLAUDE.md/GEMINI.md conventions, and a cross-runtime `~/.agents/skills/` alias), which is the spirit of pointing an agent at agent-native docs. However, a direct probe for an actual llms.txt on the project itself returned 404, and the only llms.txt success in evidence is GitHub's own generic file, not one authored by Superpowers. Missing for 10: an official llms.txt endpoint for the Superpowers project/docs, and confirmation that agents are explicitly pointed at it as an entry format.

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [claimed-docs] “User instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take precedence over skills, which in turn override default behavi…”
   • [probe] “PROBE docs-md: HTTP 404 at https://github.com/obra/superpowers.md”
   • [probe] “PROBE llms.txt: HTTP 200 at https://github.com/llms.txt # GitHub > GitHub is a developer platform for building, shipping, and maintaining s…”

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

   Superpowers is described as a Claude-Code-style plugin/skills system that repeatedly pauses for human approval (brainstorming step asks the user what they're trying to do, 'every path still stops for your approval before implementation', worktree conflicts ask rather than force) — this is an interactive workflow, and no evidence pack item mentions a headless mode, CI flag, non-interactive invocation, or automation pipeline usage.

   • [claimed-docs] “Requests are classified as spike, bounded, or architectural; small tasks skip the two-document ritual. Every path still stops for your appro…”
   • [claimed-docs] “Every path still stops for your approval before implementation.”
   • [claimed-docs] “If Claude thinks you're trying to start a project or task, it _should_ default into talking through a plan with you before it starts down th…”
   • [claimed-docs] “When `git worktree remove` refuses because the tree holds uncommitted work, the skill stops, names the files, and asks — instead of reaching…”

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

   weight 3 · round drawn
   Superpowers—none0/10

   Superpowers is a skills/plugin framework installed into various agent harnesses (Claude Code, Devin, Codex, Gemini CLI, etc.), not an agent itself, so an official MCP server is a plausible axis for this kind of product—but no evidence anywhere in the pack mentions Superpowers exposing an MCP server for agents to connect to; installation is via harness-specific plugin mechanisms, not MCP.

   ⚑ 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 userDrive the product through a documented public API

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

   Superpowers ships as skills/plugins consumed via harness-specific install commands and Claude Code slash commands (/brainstorm, /execute-plan) rather than a documented public API (REST, SDK, etc.) that an external AI agent could call to drive the product programmatically; no such API is described anywhere in the evidence.

   ⚑ 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

5. ai-native userBuild against official SDKs

   weight 2 · round to Superpowers
   Superpowers~partialclaimed3/10

   Superpowers is a skills library rather than an API/service product, but its 'porting-to-a-new-harness' docs, harness-agnostic skills format, and tool-mapping/bootstrap injector amount to a quasi-SDK for extending the system to new agent runtimes; there's also a testing/eval harness for building compliant skills. Missing for 10: no formally branded 'SDK', no language-specific client libraries, no versioned API reference, and no independent developer accounts of building against it as an SDK.

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “The harness must let you inject text into the model's context at the start of every session, with no per-session opt-in by your human partne…”
   • [claimed-docs] “Porting adds a tool-mapping reference and a bootstrap injector; it never reaches into `skills/*/SKILL.md` to swap tool names.”
   • [claimed-docs] “Everything ships through the harness's own install mechanism. Never edit the user's files.”
   • [claimed-docs] “Python harness driving real tmux sessions of Claude Code / Codex / Gemini CLI, with an LLM actor and verifier judging skill compliance.”

   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 drawn
   Superpowers—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 userSet up automations that run autonomously in the background

   weight 2 · round to Superpowers
   Superpowers~partialclaimed5/10

   Superpowers enables an agent to work autonomously for extended periods once dispatched—"work autonomously for a couple hours at a time without deviating from the plan" via subagent-driven-development with review loops (gh-6, gh-10, docs-11)—which is real unsupervised agentic execution. But this is autonomy within an active coding session triggered by a user prompt, not a background/scheduled automation that runs independent of an open session (e.g., cron-like triggers, headless unattended jobs). Missing for 10: evidence of scheduling/triggering mechanisms, headless/background execution outside an active session, or automation independent of user-initiated sessions.

   • [github] “It's not uncommon for your agent to work autonomously for a couple hours at a time without deviating from the plan you put together.”
   • [github] “your agent launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing thei…”
   • [claimed-docs] “this month's cool new process, where it dispatches tasks one by one to subagents to implement and then code reviews each task before continu…”
   • [claimed-docs] “The review-fix loop resumes the implementer... installs a five-round circuit breaker with controller adjudication when it trips.”

   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 Superpowers
   Superpowers~partialcommunity6/10

   Superpowers' core workflow explicitly delegates engineering tasks to subagents that implement, review, and iterate autonomously for hours (superpowers-gh-3, superpowers-gh-6, superpowers-gh-10, superpowers-docs-11, superpowers-docs-60), which matches the 'delegate to a built-in AI assistant' story. However, community reports note the self-review subagent step was recently folded back into the main agent (superpowers-comm-3) and mixed real-world effectiveness (superpowers-comm-2), and the 'assistant' is not a standalone built-in AI but relies on an external host agent (Claude Code, Devin, etc.) to run. Missing for 10: independent verification that delegated subagent work is reliably higher quality, and evidence of a fully self-contained assistant not dependent on a third-party host CLI.

   • [github] “your agent launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing thei…”
   • [github] “It's not uncommon for your agent to work autonomously for a couple hours at a time without deviating from the plan you put together.”
   • [github] “your agent launches a *subagent-driven-development* process, having agents work through each engineering task, inspecting and reviewing thei…”
   • [claimed-docs] “this month's cool new process, where it dispatches tasks one by one to subagents to implement and then code reviews each task before continu…”
   • [claimed-docs] “The framework includes a code-reviewer agent that evaluates implementations against plans, coding standards, and architectural principles.”
   • [community] “I personally don't like superpowers very much. My boss does. I think Claude makes more mistakes when using superpowers than when not... Just…”
   • [community] “A recent update got rid of the subagents for the self review and now does the self review in the main agent.”

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

   Superpowers operates entirely via natural-language interaction and slash-commands (/brainstorm, /execute-plan) layered on top of chat-based agents, with users directing tasks conversationally and the system interpreting intent, clarifying goals, and driving implementation without requiring code-level commands. Community evidence corroborates real-world natural-language-driven workflows (brainstorm/spec/TDD loop), though some users find the resulting plans/specs not always intuitive to read. missing for 10: independent third-party benchmarking of NL command robustness across edge cases, and no evidence of non-command free-form conversational control beyond the documented skill/slash-command triggers.

   • [github] “it *doesn't* just jump into trying to write code. Instead, it steps back and asks you what you're really trying to do.”
   • [claimed-docs] “If Claude thinks you're trying to start a project or task, it _should_ default into talking through a plan with you before it starts down th…”
   • [claimed-docs] “Invoke skills with slash commands like `/brainstorming` to explore requirements and design before implementation, or `/execute-plan` to run …”
   • [claimed-docs] “20+ battle-tested skills; `/brainstorm`, `/write-plan`, `/execute-plan` commands; Skills-search tool for discovery; SessionStart context inj…”
   • [community] “Superpowers has several skills. Its core workflow is: brainstorm to design a spec, use subagents to adversarially review its own spec/plan, …”
   • [community] “Yeah I agree with the implementation plan not being that useful for me to read. I often just tell it to go after reading the design doc.”

   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 to Superpowers
   Superpowers~partialclaimed4/10

   Superpowers isolates agent work via git worktrees so parallel tasks 'don't clobber each other' and blocks destructive actions like force-removing trees with uncommitted work, which functions as a code-level sandbox, but there is no evidence of a dedicated staging/test-data environment or safeguards against touching production databases/services. Missing for 10: explicit production-data isolation, staging/test environment support, and evidence of data-level (not just git-worktree) sandboxing.

   • [claimed-docs] “After you're done brainstorming, if you're in a git repo it automatically creates a worktree for the project and changes to that directory.”
   • [claimed-docs] “After you're done brainstorming, if you're in a git repo it automatically creates a worktree for the project and changes to that directory. …”
   • [claimed-docs] “When `git worktree remove` refuses because the tree holds uncommitted work, the skill stops, names the files, and asks — instead of reaching…”
   • [claimed-docs] “Worktree removal no longer destroys untracked files. When `git worktree remove` refuses because the tree holds uncommitted work, the skill s…”
   • [claimed-docs] “NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST”

   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

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

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

   Release notes describe a specific batching capability where 'small same-shape tasks batch into one dispatch, cutting subagent cost sharply on micro-task plans,' with batch reviews verifying every file in the brief made it into the diff — this is a real bulk-operation mechanism for micro-tasks in a plan. However, this is narrow (limited to same-shape subagent task batching within SDD plans) rather than general-purpose bulk operations across arbitrary items, and comes only from first-party release notes with no independent or hands-on corroboration. Missing for 10: evidence of bulk operations beyond same-shape micro-tasks (e.g., bulk file edits, bulk API calls across many independent items), and community/hands-on validation of the batching feature's reliability.

   • [claimed-docs] “Small same-shape tasks batch into one dispatch, cutting subagent cost sharply on micro-task plans; batch reviews verify every file in the br…”
   • [claimed-docs] “Small same-shape tasks batch into one dispatch, cutting subagent cost sharply on micro-task plans.”
   • [claimed-docs] “Small same-shape tasks batch into one dispatch, cutting subagent cost sharply on micro-task plans”

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

   Superpowers uses git worktrees, PR/merge workflows, and review-fix loops with a code-reviewer agent that checks implementations against plans, and states 'git history is the durable record' after workspace cleanup — giving some version/review/rollback capability for code changes it makes. However, this is about versioning the code it produces, not about versioning, reviewing, or rolling back the automations/skills/workflows themselves, and no dedicated rollback or automation-versioning mechanism is documented. Missing for 10: explicit versioning/rollback of the skills/automations themselves (not just git history of generated code), a rollback command or mechanism, and independent evidence that review/rollback works reliably in practice.

   • [claimed-docs] “`sdd-workspace` now requires the plan file and resolves a per-plan directory, `.superpowers/sdd//`; ... the workspace is deleted once the fi…”
   • [claimed-docs] “At the end of the implementation process, Claude will now offer to make a GitHub pull request, merge the worktree back to the source branch …”
   • [claimed-docs] “The framework includes a code-reviewer agent that evaluates implementations against plans, coding standards, and architectural principles.”
   • [claimed-docs] “The review-fix loop resumes the implementer... installs a five-round circuit breaker with controller adjudication when it trips.”
   • [claimed-docs] “When `git worktree remove` refuses because the tree holds uncommitted work, the skill stops, names the files, and asks — instead of reaching…”

   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 drawn
   Superpowers✓fullcommunity8/10

   Superpowers documents skills as harness-agnostic source of truth (docs-13) with explicit per-harness install/porting instructions for Claude Code, Codex, Devin CLI, Hermes Agent, Grok Build CLI, Cursor-class tools, Gemini CLI, Copilot CLI, and Antigravity (docs-7,8,31,54,gh-8), plus a porting guide (docs-37,59) and a testing harness running real tmux sessions across Claude Code/Codex/Gemini CLI (docs-14). It explicitly notes installation differs by harness and must be done separately for each (gh-5), matching the story's 'per-harness instructions' framing. missing for 10: no independent hands-on confirmation that identical behavior/parity is achieved across all these harnesses (only vendor docs and release notes), and community evidence focuses mainly on Claude Code with only a passing, slightly negative mention of the Codex/OpenCode install mechanism (comm-4).

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [claimed-docs] “Grok Build CLI added to the install docs.”
   • [github] “Antigravity runs the plugin's session-start hook, so Superpowers is active from the first message. Reinstall with the same command to update…”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “Porting adds a tool-mapping reference and a bootstrap injector; it never reaches into `skills/*/SKILL.md` to swap tool names.”
   • [claimed-docs] “This guide explains how to add support for a new harness ... so that Superpowers skills auto-trigger there the same way they do natively.”
   • [claimed-docs] “Python harness driving real tmux sessions of Claude Code / Codex / Gemini CLI, with an LLM actor and verifier judging skill compliance.”
   • [community] “The install mechanism for the superpowers plugin for codex and opencode is .... interesting... it's like curl|bash but with added LLM agents…”

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

   Docs explicitly confirm skills are harness-agnostic markdown source-of-truth files (skills/*/SKILL.md) shared verbatim across harnesses, with per-harness install adapters that never modify the skill files themselves, and community/vendor evidence of usage across Claude Code, Codex, Gemini CLI, Devin, Hermes, Grok Build, etc. missing for 10: independent hands-on confirmation of copying skill folders manually into a new harness without the official installer, and explicit statement that no binary/compiled artifacts are involved.

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [claimed-docs] “Porting adds a tool-mapping reference and a bootstrap injector; it never reaches into `skills/*/SKILL.md` to swap tool names.”
   • [claimed-docs] “Everything ships through the harness's own install mechanism. Never edit the user's files.”
   • [claimed-docs] “This guide explains how to add support for a new harness ... so that Superpowers skills auto-trigger there the same way they do natively.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”

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

   The project ships an 'obra/superpowers-marketplace' repo listing 20+ skills plus a 'Skills-search tool for discovery' and a `/plugin marketplace add` command, giving developers a way to see/search available skills before installing individual ones. However, there's no evidence of a rich browsable UI, ratings, leaderboard, or independent confirmation that search works well pre-install — it's mostly first-party doc mentions. Missing for 10: independent/hands-on confirmation of the search tool, a UI or leaderboard-style catalog, and community commentary on discoverability.

   • [claimed-docs] “20+ battle-tested skills; `/brainstorm`, `/write-plan`, `/execute-plan` commands; Skills-search tool for discovery; SessionStart context inj…”
   • [claimed-docs] “20+ battle-tested skills * `/brainstorm`, `/write-plan`, `/execute-plan` commands * Skills-search tool for discovery”
   • [claimed-docs] “Add this marketplace to Claude Code: /plugin marketplace add obra/superpowers-marketplace”

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

   Superpowers ships as skills files (harness-agnostic, source of truth in `skills/`) that can be committed to a project, cloned from a git repo, or installed via the official `obra/superpowers-marketplace` plugin marketplace with a single `/plugin marketplace add` command, supporting many agent harnesses (Claude Code, Devin, Hermes, Codex, Gemini CLI, etc.), which is exactly the distribution story an engineering lead needs. Community evidence (HN) confirms real-world install/adoption across a team, though it also notes the install flow feels 'like curl|bash' — a minor rough edge. Missing for 10: no explicit team-permission/ACL or org-wide governance controls, and no first-party guidance on version-pinning a shared skill set across a team.

   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”
   • [claimed-docs] “Add this marketplace to Claude Code: /plugin marketplace add obra/superpowers-marketplace”
   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [community] “The install mechanism for the superpowers plugin for codex and opencode is .... interesting... it's like curl|bash but with added LLM agents…”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”

   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 Superpowers
   Superpowers✓fullcommunity7/10

   Multiple first-party docs describe automatic, harness-agnostic skill triggering ('skills trigger automatically... you don't need to do anything special', 'Invoke relevant or requested skills BEFORE any response or action', session-start bootstrap injection across Claude Code, Devin CLI, Hermes, Antigravity) and a testing/eval harness that specifically judges skill-compliance triggering. Community discussion confirms the core brainstorm→plan→TDD workflow functions but doesn't contest trigger timing specifically. Missing for 10: independent hands-on verification that skill descriptions reliably select the *correct* skill at the *right* moment across diverse tasks (community comments focus on workflow quality/spec-plan friction rather than mis-triggering), and confirmation this holds uniformly across all listed harnesses rather than mainly Claude Code.

   • [github] “because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Superpowers.”
   • [claimed-docs] “Invoke relevant or requested skills BEFORE any response or action — including clarifying questions, exploring the codebase, or checking file…”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [claimed-docs] “The harness must let you inject text into the model's context at the start of every session, with no per-session opt-in by your human partne…”
   • [github] “Antigravity runs the plugin's session-start hook, so Superpowers is active from the first message. Reinstall with the same command to update…”
   • [claimed-docs] “evals/` — do agents behave correctly on real LLM sessions? Python harness driving real tmux sessions of Claude Code / Codex / Gemini CLI, wi…”
   • [community] “Superpowers has several skills. Its core workflow is: brainstorm to design a spec, use subagents to adversarially review its own spec/plan, …”
   • [community] “A recent update got rid of the subagents for the self review and now does the self review in the main agent.”

   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
   Superpowers~partialcommunity6/10

   Docs show simple one-line install commands across multiple harnesses (e.g. `/plugin marketplace add obra/superpowers-marketplace` + `/plugin install superpowers@superpowers-marketplace`, `devin plugins install obra/superpowers`, git-clone for Hermes) and skills auto-trigger at session start without extra developer action, suggesting a fast path to a working skill. However, no first-party quickstart doc explicitly times the process, and a community comment calls the codex/opencode install mechanism 'interesting... curl|bash but with added LLM agents,' hinting at friction not captured in the marketing copy. missing for 10: an explicit timed quickstart walkthrough, and independent hands-on confirmation of sub-5-minute setup across harnesses.

   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”
   • [claimed-docs] “Add this marketplace to Claude Code: /plugin marketplace add obra/superpowers-marketplace”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [github] “because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Superpowers.”
   • [community] “The install mechanism for the superpowers plugin for codex and opencode is .... interesting... it's like curl|bash but with added LLM agents…”

   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
   Superpowers~partialcommunity7/10

   Each skill ships as a SKILL.md with explicit activation rules (e.g. 'Invoke relevant or requested skills BEFORE any response or action', 'NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST'), a documented precedence order (user instructions > skills > defaults), and an eval harness that tests whether agents actually comply with each skill's documented behavior, which together let a developer predict activation and behavior. However, community reports note skill behavior has changed between updates in ways not obviously reflected to users in the moment (e.g. self-review subagents silently removed), and one experienced user found the plan/implementation docs didn't match what they expected in practice, showing documentation-to-behavior fidelity isn't perfect. Missing for 10: an independent audit confirming every one of the 20+ skills documents activation triggers consistently, and stronger evidence that doc updates keep pace with behavior changes.

   • [claimed-docs] “Invoke relevant or requested skills BEFORE any response or action — including clarifying questions, exploring the codebase, or checking file…”
   • [claimed-docs] “NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST”
   • [claimed-docs] “User instructions (CLAUDE.md, AGENTS.md, GEMINI.md, etc, direct requests) take precedence over skills, which in turn override default behavi…”
   • [claimed-docs] “You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests …”
   • [claimed-docs] “evals/` — do agents behave correctly on real LLM sessions? Python harness driving real tmux sessions of Claude Code / Codex / Gemini CLI, wi…”
   • [community] “A recent update got rid of the subagents for the self review and now does the self review in the main agent.”
   • [community] “Yeah I agree with the implementation plan not being that useful for me to read. I often just tell it to go after reading the design doc.”

   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 drawn
   Superpowers✓fullcommunity8/10

   Superpowers documents a clean one-liner install for Claude Code ('/plugin marketplace add obra/superpowers-marketplace' + '/plugin install superpowers@superpowers-marketplace') and equivalent one-liners for other harnesses (e.g. 'devin plugins install obra/superpowers'), with explicit claims that skills auto-trigger at session start via a SessionStart hook so the collection is active on the very next session without further setup. This is corroborated across multiple harness release notes (Devin, Hermes, Antigravity) and a first-party blog walkthrough. Missing for 10: independent hands-on confirmation that the one-liner installs cleanly on a fresh machine (community notes call the install mechanism for some harnesses 'interesting... like curl|bash but with added LLM agents' and note it must be repeated per-harness), and no non-vendor benchmark of session-start activation timing.

   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”
   • [claimed-docs] “Add this marketplace to Claude Code: /plugin marketplace add obra/superpowers-marketplace”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [github] “Antigravity runs the plugin's session-start hook, so Superpowers is active from the first message. Reinstall with the same command to update…”
   • [github] “because the skills trigger automatically, you don't need to do anything special. Your coding agent just has Superpowers.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [community] “The install mechanism for the superpowers plugin for codex and opencode is .... interesting... it's like curl|bash but with added LLM agents…”

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

   Evidence describes installation via harness-specific plugin managers (Claude Code marketplace, Devin CLI, Hermes) and a global `~/.agents/skills/` alias, but nowhere mentions an explicit choice between project-local (repo-committed) and user-global install scopes as a deliberate feature.

   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”

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

   All installation evidence describes installing the entire Superpowers plugin/skill bundle as one unit (e.g., '/plugin install superpowers@superpowers-marketplace', 'devin plugins install obra/superpowers', 'install from a git clone'), with no mechanism shown for selecting individual skills to install rather than the whole collection.

   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “Add this marketplace to Claude Code: /plugin marketplace add obra/superpowers-marketplace”

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

   Evidence covers installation across many harnesses (plugin marketplace, git clone, devin/hermes/grok CLIs) but there is no mention of a command or mechanism to list installed skills or cleanly uninstall/remove them without leftover files or instructions. missing for 10: a list-installed-skills command, an uninstall/remove workflow, and confirmation that removal leaves no orphaned files or lingering context injections.

   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “Everything ships through the harness's own install mechanism. Never edit the user's files.”
   • [claimed-docs] “This guide explains how to add support for a new harness ... so that Superpowers skills auto-trigger there the same way they do natively.”

   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 skills.sh
   Superpowers—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 userRead the product's source under an open license

   weight 2 · round to Superpowers
   Superpowers~partialprobed5/10

   The product is hosted as a public GitHub repo with source files (skills/*.md, docs/, RELEASE-NOTES.md) directly viewable and clonable, implying open readability, but no evidence pack item cites an explicit OSS license (e.g., MIT/Apache) governing the code. missing for 10: explicit license file/declaration, independent confirmation of license terms, any mention of licensing terms at all.

   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “This guide explains how to add support for a new harness ... so that Superpowers skills auto-trigger there the same way they do natively.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://github.com/llms.txt # GitHub > GitHub is a developer platform for building, shipping, and maintaining s…”

   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

3. ai-native userSelf-host the core product

   weight 3 · round to Superpowers
   Superpowers~partialclaimed6/10

   Superpowers is fully open-source (GitHub repo) and its skills are installed and run entirely locally within whatever agent harness you already run (Claude Code, Devin, Hermes, Codex, etc.) via git clone or plugin install, meaning there's no cloud service to depend on — evidence of harness-agnostic 'skills/' as source of truth and multi-harness install instructions supports this. However, there's no explicit documentation framing this as 'self-hosting' or describing any server/infra component to host, since it's not a hosted service at all. Missing for 10: explicit self-hosting/deployment guide, any discussion of infra/server components, independent confirmation of running fully offline/air-gapped.

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “Everything ships through the harness's own install mechanism. Never edit the user's files.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”

   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
   Superpowers—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

Review

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

   weight 3 · round drawn
   Superpowers~partialcommunity5/10

   Skills are shipped as plain-text SKILL.md files in the public GitHub repo ('skills/' is the source of truth, shared verbatim) and a skills-search tool exists for discovery, so a lead can in principle browse/clone the repo and read every file before and after install. However, there is no dedicated 'list contents before install' review command, and community commentary notes the install mechanism for some harnesses is 'like curl|bash but with added LLM agents,' which cuts against an explicit, structured audit workflow. Missing for 10: a built-in pre-install manifest/listing command, documented post-install file-audit tooling, and independent confirmation that installers don't execute anything before a human can inspect files.

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “20+ battle-tested skills; `/brainstorm`, `/write-plan`, `/execute-plan` commands; Skills-search tool for discovery; SessionStart context inj…”
   • [claimed-docs] “20+ battle-tested skills * `/brainstorm`, `/write-plan`, `/execute-plan` commands * Skills-search tool for discovery”
   • [community] “The install mechanism for the superpowers plugin for codex and opencode is .... interesting... it's like curl|bash but with added LLM agents…”
   • [claimed-docs] “Everything ships through the harness's own install mechanism. Never edit the user's files.”

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

   No evidence pack item documents a security posture statement, execution/permission model for skills, a trust model for vetting third-party skills (e.g., marketplace skills), or any telemetry/data-collection disclosure. Items like 'never edit the user's files' or worktree safety are incidental engineering safeguards, not a documented security posture for engineering-lead review.

   ⚑ 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
   Superpowers~partialclaimed4/10

   The product ships a dedicated 'writing-skills' SKILL.md that documents a TDD-like process for authoring skills (write test cases, watch fail, write skill doc, watch pass, refactor) and there's a 'skill authoring' capability mentioned in the plugin docs, implying some documented authoring path exists. However, no evidence explicitly shows a SKILL.md template with name/description frontmatter fields, nor confirms a developer can author without referencing/reverse-engineering existing skills — missing for 10: an explicit template/schema example with frontmatter fields, and confirmation the process doesn't require studying existing skill files.

   • [claimed-docs] “You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests …”
   • [claimed-docs] “Claude learns brainstorming, subagent development with code review, debugging, TDD, and skill authoring through Superpowers.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”

   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 Superpowers
   Superpowers✓fullclaimed7/10

   The repo ships a dedicated `writing-skills` SKILL.md meta-skill that walks through writing test cases (pressure scenarios), watching them fail, authoring the skill doc, verifying compliance, and refactoring to close loopholes — directly matching the write/improve/package-a-skill workflow — and docs confirm 'Claude learns... skill authoring through Superpowers' plus cross-runtime packaging notes (harness-agnostic skills, `~/.agents/skills/` alias). Missing for 10: independent/community hands-on validation specifically of the skill-authoring meta-skill (community evidence only discusses the brainstorm/plan/TDD workflow, not skill-creation itself), and no concrete example of an end-to-end 'packaged' new skill produced via this meta-skill.

   • [claimed-docs] “You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests …”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [claimed-docs] “Claude learns brainstorming, subagent development with code review, debugging, TDD, and skill authoring through Superpowers.”
   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “20+ battle-tested skills; `/brainstorm`, `/write-plan`, `/execute-plan` commands; Skills-search tool for discovery; SessionStart context inj…”

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

   Docs show skills are harness-agnostic — 'Everything in skills/ is the source of truth, shared verbatim by every harness' (docs-13), porting only adds a bootstrap/tool-mapping layer and 'never reaches into skills/*/SKILL.md to swap tool names' (docs-37), and the same skill folder is confirmed working across Claude Code, Devin, Hermes, Codex, Gemini CLI, Copilot CLI and Grok Build CLI via a cross-runtime `~/.agents/skills/` alias (docs-31, docs-52-54). This directly supports the claim that the skill folder is valid beyond one vendor's tooling. Missing for 10: an explicit citation naming the 'Agent Skills' open specification itself, and independent (non-vendor) confirmation that the folder format is spec-conformant rather than just multi-harness-compatible.

   • [claimed-docs] “Skills (harness-agnostic). Everything in `skills/` is the source of truth, shared verbatim by every harness.”
   • [claimed-docs] “Codex, Copilot CLI, and Gemini CLI all also recognize `~/.agents/skills/` as a cross-runtime alias.”
   • [claimed-docs] “Porting adds a tool-mapping reference and a bootstrap injector; it never reaches into `skills/*/SKILL.md` to swap tool names.”
   • [claimed-docs] “Everything ships through the harness's own install mechanism. Never edit the user's files.”
   • [claimed-docs] “Devin CLI: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “Hermes Agent: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [claimed-docs] “Grok Build CLI added to the install docs.”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”

   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 Superpowers
   Superpowers~partialcommunity5/10

   RELEASE-NOTES.md shows frequent, detailed updates (new harness support, workflow fixes, workspace scoping, TDD doc rewrites) and HN community threads confirm users are tracking recent changes, indicating active maintenance and recent releases. However, there is no evidence of issue triage practices or accepted community pull requests/contributions. Missing for 10: evidence of issue triage process, evidence of merged community PRs/contributions, independent contributor activity beyond the single maintainer.

   • [claimed-docs] “Requests are classified as spike, bounded, or architectural; small tasks skip the two-document ritual. Every path still stops for your appro…”
   • [claimed-docs] “Worktree removal no longer destroys untracked files. When `git worktree remove` refuses because the tree holds uncommitted work, the skill s…”
   • [claimed-docs] “Devin CLI: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “Grok Build CLI added to the install docs.”
   • [community] “A recent update got rid of the subagents for the self review and now does the self review in the main agent.”

   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 to Superpowers
   Superpowers✓fullclaimed8/10

   The repo's testing docs describe a two-tier verification system: `tests/` for non-LLM code (bash/node/python integration tests) and `evals/` — a Python harness driving real tmux sessions across multiple agent CLIs with an LLM actor and verifier judging skill compliance — plus a documented TDD-style process for writing skills themselves (write pressure-scenario tests, watch them fail, write the skill, watch them pass, refactor to close loopholes). This is concrete, specific first-party evidence that skills aren't shipped on vibes but are eval-gated. Missing for 10: independent/community confirmation that the eval suite actually catches regressions in practice, and quantitative pass-rate or CI-run evidence beyond the docs themselves.

   • [claimed-docs] “Python harness driving real tmux sessions of Claude Code / Codex / Gemini CLI, with an LLM actor and verifier judging skill compliance.”
   • [claimed-docs] “You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests …”
   • [claimed-docs] “tests/` — does the plugin's non-LLM code work? Bash + node + python integration tests for brainstorm-server JS, OpenCode plugin loading, cod…”
   • [claimed-docs] “evals/` — do agents behave correctly on real LLM sessions? Python harness driving real tmux sessions of Claude Code / Codex / Gemini CLI, wi…”
   • [claimed-docs] “tests/` — does the plugin's non-LLM code work? ... `evals/` — do agents behave correctly on real LLM sessions?”
   • [claimed-docs] “tests/ — does the plugin's non-LLM code work?... evals/ — do agents behave correctly on real LLM sessions? Python harness driving real tmux …”

   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.sh
   Superpowers—none0/10

   The evidence describes install/update mechanisms (git clone, plugin marketplace, harness-specific installers, manual reinstall to update) but nowhere mentions version pinning, a lockfile, or any mechanism letting a lead control/freeze which skill version reaches the team versus picking up the latest on reinstall or auto-update.

   ⚑ 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
   Superpowers~partialclaimed6/10

   There is a documented update path — for the Antigravity harness, the docs explicitly state 'Reinstall with the same command to update,' and the marketplace install command (`/plugin marketplace add`/`/plugin install`) plus an actively maintained RELEASE-NOTES.md show a real versioning/update cadence. However, this is not a one-click marketplace auto-update: install/update differs by harness (separate reinstall per harness), and there's no first-party 'update' subcommand shown for most integrations. Missing for 10: an explicit auto-update mechanism or dedicated update command (vs. reinstall) that works uniformly across harnesses, and independent confirmation that reinstalling actually preserves user config/state.

   • [github] “Antigravity runs the plugin's session-start hook, so Superpowers is active from the first message. Reinstall with the same command to update…”
   • [github] “Installation differs by harness. If you use more than one, install Superpowers separately for each one.”
   • [claimed-docs] “Add this marketplace to Claude Code: /plugin marketplace add obra/superpowers-marketplace”
   • [claimed-docs] “/plugin marketplace add obra/superpowers-marketplace /plugin install superpowers@superpowers-marketplace”
   • [claimed-docs] “Ceremony now scales to the task. Requests are classified as spike, bounded, or architectural; small tasks skip the two-document ritual.”

   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 to Superpowers
   Superpowers✓fullclaimed7/10

   There is a maintained RELEASE-NOTES.md with per-release entries describing specific changes (worktree removal safety, workspace scoping, batching, TDD doc rewrites) plus new harness support additions like Devin/Hermes/Grok CLI, giving developers real changelog visibility before updating. missing for 10: no independent/community corroboration that release notes are consulted or trusted pre-update, and no explicit versioning scheme (semver/version tags) tying notes to installable releases.

   • [claimed-docs] “Requests are classified as spike, bounded, or architectural; small tasks skip the two-document ritual. Every path still stops for your appro…”
   • [claimed-docs] “Non-catastrophic conflicts and ambiguities get a recorded ruling and work continues; only destructive or irreversible actions still stop for…”
   • [claimed-docs] “Small same-shape tasks batch into one dispatch, cutting subagent cost sharply on micro-task plans; batch reviews verify every file in the br…”
   • [claimed-docs] “When `git worktree remove` refuses because the tree holds uncommitted work, the skill stops, names the files, and asks — instead of reaching…”
   • [claimed-docs] “a follow-up plan in the same working tree could read the previous plan's ledger as its own progress... `sdd-workspace` now requires the plan…”
   • [claimed-docs] “The review-fix loop resumes the implementer... installs a five-round circuit breaker with controller adjudication when it trips.”
   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “**Hermes Agent**: install from a git clone; skills register with Hermes' native loader and the bootstrap loads on the first turn.”
   • [claimed-docs] “`testing-anti-patterns.md` is now `writing-good-tests.md`. The TDD reference doc is rebuilt as a positive catalog — six rules that lead with…”
   • [claimed-docs] “Grok Build CLI added to the install docs.”

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