Superpowers vs Anthropic Skills

Agent ops

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills✓fullclaimed9/10

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

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

   proof ↗⚑ flag

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 Anthropic Skills
   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

   Anthropic Skills~partialclaimed4/10

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

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

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to Anthropic Skills
   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

   Anthropic Skills✓fullclaimed8/10

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

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

   proof ↗⚑ flag

4. ai-native userBuild against official SDKs

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills~partialcommunity4/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills—none0/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 1 · round drawn
   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

   Anthropic Skills~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Superpowers
   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

   Anthropic Skills~partialcommunity3/10

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

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

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Superpowers
   Superpowers~partialclaimed5/10

   Superpowers skills auto-trigger on contextual events (session start, failed fix attempts, git conflicts, worktree issues) and users can author new skills that encode conditional trigger/action rules, but this is a semantic skill-matching system rather than a general-purpose 'if event X then action Y' rule engine that AI-native users can freely define for arbitrary events. missing for 10: an explicit user-facing rule/trigger definition interface (vs. embedding logic in skill docs), support for arbitrary custom events beyond built-in dev workflow triggers, and independent confirmation that user-authored triggers reliably fire.

   • [claimed-docs] “**Devin CLI**: `devin plugins install obra/superpowers` now works, and skills auto-trigger at session start.”
   • [claimed-docs] “safeguards that trigger architectural review after three failed fix attempts”
   • [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] “Non-catastrophic conflicts and ambiguities get a recorded ruling and work continues; only destructive or irreversible actions still stop for…”
   • [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] “You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests …”

   proof ↗⚑ flag

   Anthropic Skills!disputedcontradicted4/10

   Anthropic's docs claim skills auto-trigger ('Claude uses skills when relevant... loads it automatically') based on description matching, which is the closest analog to event-driven rule triggering in this product, but this is relevance-based context loading, not true event/webhook/schedule triggers. Hands-on community reports directly contradict reliability of this claimed automation: Vercel's eval found skills were never invoked in 56% of cases despite being applicable, and multiple users report 'hit or miss' triggering even with proper YAML triggers, sometimes requiring explicit manual invocation. Missing for 10: genuine event-based triggers (webhooks, schedules, file-watchers), reliable automatic invocation without manual prompting, and independent confirmation that trigger accuracy is dependable in production.

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

   proof ↗⚑ flag

3. 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

   Anthropic Skills~partialclaimed4/10

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

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

   proof ↗⚑ flag

Portability

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

   weight 3 · round to Superpowers
   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

   Anthropic Skills~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills✓fullclaimed9/10

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

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

   proof ↗⚑ flag

Discovery

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

   weight 2 · round drawn
   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

   Anthropic Skills~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills~partialcommunity6/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills!disputedcontradicted5/10

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

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

   proof ↗⚑ flag

Install

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

   weight 3 · round to Superpowers
   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

   Anthropic Skills~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills~partialclaimed6/10

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

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

   proof ↗⚑ flag

Lifecycle

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

   weight 1 · round drawn
   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

   Anthropic Skills—none0/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills—none0/10

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

   ⚑ flag

1. ai-native userControl data retention and deletion

   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

   Anthropic Skills—none0/10

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

   ⚑ flag

Review

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

   weight 3 · round to Anthropic Skills
   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

   Anthropic Skills~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills—none0/10

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

   ⚑ flag

Authoring

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

   weight 3 · round to Anthropic Skills
   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

   Anthropic Skills✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

   weight 2 · round to Anthropic Skills
   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

   Anthropic Skills✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills✓fullclaimed8/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills—none0/10

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

   ⚑ flag

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

   Anthropic Skills—none0/10

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

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

   proof ↗⚑ flag

Pinning

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

   weight 1 · round to Anthropic Skills
   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

   Anthropic Skills~partialclaimed5/10

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

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

   proof ↗⚑ flag

Updates

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

   weight 3 · round drawn
   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

   Anthropic Skills~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

   Anthropic Skills—none0/10

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

   ⚑ flag