Superpowers vs Codex Plugins

Agent ops

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

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

   Codex Plugins✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins~partialclaimed5/10

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

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

   proof ↗⚑ flag

Agent access

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

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

   Codex Plugins~partialprobed5/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

4. ai-native userBuild against official SDKs

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

   Codex Plugins~partialprobed5/10

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

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

   proof ↗⚑ flag

Agentic features

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

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

   Codex Plugins~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins✓fullcommunity7/10

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

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

   proof ↗⚑ flag

Api quality

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

   weight 1 · round to Superpowers
   Superpowers~partialclaimed4/10

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

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

   proof ↗⚑ flag

   Codex Plugins—none0/10

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

   ⚑ flag

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

   Codex Plugins—none0/10

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

   ⚑ flag

2. ai-native 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

   Codex Plugins~partialclaimed3/10

   Skill creation asks the author to define 'when it should trigger' (docs-7), implying some contextual auto-invocation logic, but all other evidence shows skills/plugins being invoked manually via `/skills`, `$` mention, or `/plugins` browser rather than firing automatically on external events like schedules, webhooks, or file changes. Missing for 10: explicit event-trigger/automation-rule mechanism (e.g., cron, webhook, file-watch), documentation of autonomous invocation without user prompt, and independent confirmation that trigger conditions actually fire without manual mention.

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

   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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

Portability

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins~partialclaimed6/10

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

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

   proof ↗⚑ flag

Discovery

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

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

   Codex Plugins✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Distribution

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

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

   Codex Plugins✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Triggering

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

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

   Codex Plugins~partialcommunity7/10

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

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

   proof ↗⚑ flag

Onboarding

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

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

   Codex Plugins~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins~partialcommunity7/10

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

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

   proof ↗⚑ flag

Install

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

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

   Codex Plugins✓fullclaimed7/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins~partialclaimed6/10

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

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

   proof ↗⚑ flag

Lifecycle

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

   weight 1 · round to Codex Plugins
   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

   Codex Plugins~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

2. ai-native 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

   Codex Plugins~partialclaimed3/10

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

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

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Superpowers
   Superpowers~partialclaimed6/10

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

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

   proof ↗⚑ flag

   Codex Plugins—none0/10

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

   ⚑ flag

1. ai-native userControl data retention and deletion

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

Review

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

   weight 3 · round drawn
   Superpowers~partialcommunity5/10

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

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

   proof ↗⚑ flag

   Codex Plugins~partialclaimed5/10

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

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

   proof ↗⚑ flag

Trust

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

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

   Codex Plugins~partialclaimed4/10

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

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

   proof ↗⚑ flag

Authoring

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

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

   Codex Plugins✓fullcommunity8/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Spec

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

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

   Codex Plugins~partialcommunity6/10

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

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

   proof ↗⚑ flag

Maintenance

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

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

   Codex Plugins—none0/10

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

   ⚑ flag

Testing

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

Pinning

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

Updates

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

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

   Codex Plugins—none0/10

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

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

   proof ↗⚑ flag

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

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

   Codex Plugins—none0/10

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

   ⚑ flag