Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add dayfinggg/openai-codex-agent-skills --skill deployment-verificationgit clone --depth 1 https://github.com/dayfinggg/openai-codex-agent-skillsWrote 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/dayfinggg/openai-codex-agent-skills/deployment-verification)<a href="https://agentmods.dev/skills/dayfinggg/openai-codex-agent-skills/deployment-verification"><img src="https://agentmods.dev/badge/skills/dayfinggg/openai-codex-agent-skills/deployment-verification/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/dayfinggg/openai-codex-agent-skills/deployment-verification"><img src="https://agentmods.dev/badge/skills/dayfinggg/openai-codex-agent-skills/deployment-verification.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.00032 | $0.00359 |
| Opus 5.5 | $0.00013 | $0.00144 |
| Sonnet 5.5 | $0.00006 | $0.00072 |
| Haiku 4.5 | $0.00003 | $0.00036 |
Grade A, and why
deployment-verification 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 today.
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.
What it actually says
Verify the intended application artifact in the intended environment.
- Establish the authorized target, tested commit or artifact digest, deployment mechanism, configuration source, runtime versions, and acceptance criteria. Reuse existing authentication without exposing values.
- Trace the artifact from build to runtime. Confirm immutable identity and environment-specific configuration. Do not rebuild an untracked variant after testing and call it the same release.
- Determine application and schema compatibility during rollout. Use database-migration-rollout when schema changes. Check worker or protocol compatibility with versions that coexist.
- Identify readiness, live-process state, and a user-visible acceptance path separately. A process that starts or a generic health response does not prove the release works.
- Establish the supported restoration path and its data consequences. Distinguish reverting application code from reverting schema or losing writes. Preserve the previous artifact and configuration where the existing release mechanism requires them.
- Perform the authorized release using the existing system. Check graceful shutdown, connection draining, FPM or OPcache refresh, background workers, and cache compatibility only where relevant.
- Verify artifact identity, the changed user path, relevant error path, logs, metrics, and dependent jobs after rollout. Stop and restore within authorization when acceptance fails.
- Clean up only task-owned disposable release materials after no running process needs them.
Do not provision a new platform, change infrastructure ownership, or add manual approval stages unless the task requires it. A request to verify a deployment alone does not authorize initiating a new release.
Finish with the actual deployed revision and observed acceptance result, or an explicit unresolved blocker.
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.
- today First seen · 21 lines · 32 tokens per session scan A 06ccac6f2e32
deployment-verification is a skill published in the GitHub repository dayfinggg/openai-codex-agent-skills (8 stars, last pushed today), licensed MIT. It adds 32 tokens to every session and 359 once invoked, about $0.0001 per session on Opus 5.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-10-30.
Other skills, from other repositories
kirby-performance-and-media
Improves Kirby performance and media delivery (cache tuning, CDN, responsive images, lazy loading). Use when optimizing page speed, caching, or image handling.
databricks
Operate Databricks bundles, jobs, pipelines, and Unity Catalog.
gcloud
Use gcloud for Google Cloud projects, IAM, billing, APIs, and logs.
aws
Operate AWS accounts and SSO profiles with aws and aws-sso-util.
kubernetes
Operate Kubernetes with kubectl, Helm, kustomize, kubeconform, and stern.
factory-deployment
Deployment and infrastructure conventions across builds. Vercel + Neon for web (with PR branch DBs), Cloud Run for Python services (one service per entry-point variant), GitHub Actions matrix-deploy on merge, Terraform with environments/modules layout for AWS / compliance customers, RDS IAM authentication for AWS DBs…