Borrowing it
Nothing to install: this file belongs to markmhendrickson/ateles. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/markmhendrickson/ateles/main/.claude/skills/verify-deployment/SKILL.mdgit clone --depth 1 https://github.com/markmhendrickson/atelesWrote 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/markmhendrickson/ateles/verify-deployment)<a href="https://agentmods.dev/skills/markmhendrickson/ateles/verify-deployment"><img src="https://agentmods.dev/badge/skills/markmhendrickson/ateles/verify-deployment/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/markmhendrickson/ateles/verify-deployment"><img src="https://agentmods.dev/badge/skills/markmhendrickson/ateles/verify-deployment.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.00000 | $0.00701 |
| Opus 5 | $0.00000 | $0.00351 |
| Sonnet 5 | $0.00000 | $0.00140 |
| Haiku 4.5 | $0.00000 | $0.00070 |
Grade A, and why
verify-deployment 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 5d 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 — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Verify Deployment
After a deployment that uses GitHub Actions (e.g. website submodule push), check the workflow run and repeat fix/re-run until the build succeeds. Do not stop at "you can re-run"; perform the re-run when the fix is in place.
When to Use
Use this skill when:
- User has just pushed a website deploy (e.g. markmhendrickson, hendricksonserrano, dionysiandesigns) and wants confirmation
- User says "check deploy", "verify deployment", "did the build succeed"
- Context indicates a deploy was triggered and outcome is unknown
Required Documents (load first)
- Deployment verification and re-run: docs/development_workflows_rules.mdc (Deployment verification, GitHub Actions re-run)
- Optional pre-step for markmhendrickson: Same doc (Post markdown priority and deploy sync) — ensure Neotoma export current and run
generate_posts_cache.pybefore build when deploying that site
Workflow
- Optional pre-step (website with posts): If deploying a site that uses post cache (e.g. markmhendrickson), ensure Neotoma export is current and run
python3 execution/scripts/generate_posts_cache.py(or--from-neotoma-json <path>) before build when appropriate. - Identify repo and run: Determine the repository that was pushed (e.g. markmhendrickson/markmhendrickson). Use
gh run list --repo <owner/repo>or user-provided run ID; optionally open Actions page. - Check outcome: Use
gh run view <run-id> --repo <owner/repo>to see status and logs. - If succeeded: Report success to user and stop.
- If failed: Identify cause from logs (failed step, config, submodule, dependencies). Fix (code, config, submodule, deps), then either push the fix (triggers new run) or run
gh run rerun <run-id> --repo <owner/repo>. Return to step 3 and repeat until the build succeeds. - Do not tell the user "you can re-run the workflow" without performing the re-run after the fix is applied.
Constraints
- Always check Actions after a deploy that uses GitHub Actions.
- Repeat the check/fix/re-run loop until the build succeeds.
- Perform
gh run rerunwhen the fix is in place; do not leave re-run to the user.
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.
- 5d ago First seen · 47 lines · 0 tokens per session scan A 43458f53c9aa
verify-deployment is a skill published in the GitHub repository markmhendrickson/ateles (6 stars, last pushed today), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 701 tokens. 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-09-03.
Other skills, from other repositories
swarm-migrate
Cross-repo migration swarm — one coordinator + N parallel subagents (one per target repo) that apply the same transformation, open PRs, wait for CI, and report back to a shared JSON ledger. Coordinator handles topology, conflict auto-rebase, and stop-on-novel-failure. Use when bumping a shared dependency, rolling out…
zb-release-pipeline
Generate a GitHub Actions pipeline that builds a zb (Zero Dependencies Builder) project and publishes a GitHub Release with the produced JAR. Use whenever the user wants CI/CD, a build pipeline, a release workflow, or GitHub Actions for a zb-based Java project — phrases like "set up GitHub Actions for this zb…
release-engineering
Design, automate, and operate end-to-end software releases: release process models and pipelines (trunk-based development, CD stages, release trains), progressive delivery and feature flags, versioning and artifact management (SemVer, conventional commits, changelogs, SBOM/provenance), readiness and quality gates…
verified-delivery
Implement and deliver an authorized change end to end — verify, open the PR, merge, and confirm post-merge state — using live-state gates, durable interruption handoffs, and live-state-first resumption. Use when a user grants end-to-end delivery authority for a specific change and the work may cross tool-call limits…
deployment-safety
Production deployment rules, rollback-first recovery, dependency batching, CI cost awareness, framework upgrade verification, fallback observability, and GitHub repo settings standardization.
git-workflow
When the user asks you to perform git operations, create branches, open PRs, manage releases, or resolve conflicts, follow this guide. These are the procedural patterns you should apply consistently.