Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add naderelewa/Product-to-Prod/plugin install product2prodWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/naderelewa/product-to-prod/pm-verify-release-v1)<a href="https://agentmods.dev/skills/naderelewa/product-to-prod/pm-verify-release-v1"><img src="https://agentmods.dev/badge/skills/naderelewa/product-to-prod/pm-verify-release-v1/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/naderelewa/product-to-prod/pm-verify-release-v1"><img src="https://agentmods.dev/badge/skills/naderelewa/product-to-prod/pm-verify-release-v1.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00189 | $0.02931 |
| Opus 5 | $0.00095 | $0.01465 |
| Sonnet 5 | $0.00038 | $0.00586 |
| Haiku 4.5 | $0.00019 | $0.00293 |
Grade A, and why
pm-verify-release-v1 scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 13d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 191 lines — stays where its author put it; the contents beside it link to each section on GitHub.
pm-verify-release-v1, deployed build vs spec → acceptance evidence → feedback pack
Input is a shipped scope: the cycle's handoff package directory and the tier it is deployed on. Output is a scenario-by-scenario verdict table with receipts, an acceptance report prepared for the owner, and a feedback pack that makes the next cycle smarter.
Completion is not acceptance. This verb produces evidence. A named human owns the acceptance decision. This skill never marks anything accepted, never flips a gate, and never softens a verdict to make a release look accepted.
Posture: read-only everywhere. Behavioural probes look; analytics probes query; nothing is written to any tier, flag, dashboard or repository. Where an engineering toolchain is configured, its run records are inputs only, never authored, never edited, never re-minted.
Preflight (run first)
PKG_ROOT="${CLAUDE_PLUGIN_ROOT:-${PKG_ROOT:-}}"
[ -n "$PKG_ROOT" ] && [ -r "$PKG_ROOT/.claude-plugin/plugin.json" ] || { echo "STOP: set PKG_ROOT to this package's root directory, the one holding .claude-plugin/plugin.json, then re-run."; exit 2; }
bash "$PKG_ROOT/scripts/preflight.sh" pm-verify-release-v1 [--stack <keys>]
A miss on a required capability blocks the run and prints its exact one-time fix. Conditional keys
are passed once the scenario scope is assembled: analytics-verification (any analytics-touch
scenario in scope) · eng-handoff (the downstream registry, for deployed coordinates) ·
repo-state (change-request state reads). A selected-conditional miss blocks exactly like a required
one, never silently degrade into a partial verification that reads like a full one.
Standalone vs supercharged. Standalone (python3 only): every pre-declared scenario graded
against the deployed build via behavioural probes, plus the report and the feedback pack;
analytics-touch receipts ride NEEDS-CONFIRMATION rows instead of measured values, and say so.
Supercharged: analytics-verification executes the pre-declared measurement plan and compares
receipts against the declared thresholds; eng-handoff resolves deployed coordinates from the
registry instead of from an answer.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 13d ago First seen · 191 lines · 189 tokens per session scan A 66cad97b27e7
pm-verify-release-v1 is a skill published in the GitHub repository naderelewa/Product-to-Prod (43 stars, last pushed yesterday), licensed MIT. It adds 189 tokens to every session and 2,931 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
phx-work
Execute Elixir/Phoenix plan tasks with progress tracking. Use after phx-plan to implement features with mix compile and mix test verification after each step, or --continue to resume interrupted work.
lab:autoresearch
Self-improving loop for plugin skills. Reads program.md, proposes one mutation per iteration, evaluates against deterministic scorer, keeps improvements via git, reverts failures. Targets weakest skill+dimension. Use with /loop for overnight runs.
review-testing
Review test code for quality, design, and completeness after implementing a feature or fixing a bug. Use when the user asks to "review my tests", "check my test quality", "are these tests good enough", "review testing", or after completing a feature implementation that includes tests. Also use when tests feel brittle…
testing-r-packages
Best practices for writing R package tests using testthat version 3+. Use when writing, organizing, or improving tests for R packages. Covers test structure, expectations, fixtures, snapshots, mocking, and modern testthat 3 patterns including self-sufficient tests, proper cleanup with withr, and snapshot testing.
codex-loop
Fix Elixir/Phoenix code until Codex CLI review comes back clean — bounded review, fix, verify loop before opening a PR. Use when codex is installed and you want an external cross-model critic on your changes before pushing.
verify
Verify Elixir/Phoenix changes — compile, format, and test in one loop. Use after implementation, before PRs, or after fixing bugs.