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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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 userUse an official CLI

   weight 2 · round to Codex Plugins
   Skills for Real Engineers✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   Codex Plugins✓fullprobed8/10

   Codex Plugins documentation repeatedly references the official Codex CLI, including specific commands (/plugins, /skills, $skill-installer, codex plugin marketplace add) that let an AI-native user browse, install, and manage plugins/skills directly from the CLI, confirming an official CLI workflow exists and is documented as first-class. Missing for 10: independent hands-on confirmation of CLI usage beyond vendor docs, and a full command reference showing breadth of CLI capabilities.

   • [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 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…”
   • [claimed-docs] “To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`.”
   • [probe] “PROBE docs-md: HTTP 200 at https://developers.openai.com/codex/skills.md # Build skills > For the complete documentation index, see [llms.t…”

   proof ↗⚑ flag

4. ai-native userBuild against official SDKs

   weight 2 · round to Codex Plugins
   Skills for Real Engineers—none0/10

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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

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

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

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

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

   proof ↗⚑ flag

   Codex Plugins—none0/10

   No evidence of API versioning scheme or a documented deprecation policy for Codex Plugins; the probe for an OpenAPI spec even returned 404s across all candidate paths, and docs only cover plugin/skill creation and usage, not lifecycle/versioning guarantees.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.openai.com/openapi.json, https://developers.openai.com/swagger.json, https://deve…”

   proof ↗⚑ flag

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

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

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

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

   proof ↗⚑ flag

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

   The product ships a library of manually-invoked skill files triggered by slash commands or explicit user direction ('Install the ones you want, then type a slash command'; 'Use them every time you want to make a change'), not an event-driven rule/automation engine. No evidence describes defining rules that fire automatically on repo events, webhooks, or triggers without user invocation.

   • [claimed-docs] “Install the ones you want, then type a slash command.”
   • [github] “They help you align with the agent before you get started, and think deeply about the change you're making. Use them _every_ time you want t…”
   • [claimed-docs] “Scaffold the per-repo configuration that the engineering skills assume: **Issue tracker**... **Triage labels**... **Domain docs**”

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

   ⚑ flag

   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 userExport all of my data in open formats and leave

   weight 3 · round to Skills for Real Engineers
   Skills for Real Engineers~partialclaimed5/10

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

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

   proof ↗⚑ flag

   Codex Plugins—none0/10

   No evidence of any data export feature, open-format export, or account/data portability mechanism for Codex Plugins; the documentation focuses on plugin/skill installation and creation, not user data export or exit.

   ⚑ flag

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

   weight 2 · round to Skills for Real Engineers
   Skills for Real Engineers✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   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

4. ai-native userSelf-host the core product

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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

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

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

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

   ⚑ flag

   Codex Plugins—none0/10

   The evidence pack covers plugin/skill installation, marketplace, and sign-in data sharing scope, but contains no mention of telemetry or usage-tracking opt-out controls for Codex Plugins.

   ⚑ flag

Review

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

   weight 3 · round to Skills for Real Engineers
   Skills for Real Engineers~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

   ⚑ flag

   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