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 phuonghx/aim-cli --skill deployment-proceduresgit clone --depth 1 https://github.com/phuonghx/aim-cliWrote 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/phuonghx/aim-cli/deployment-procedures)<a href="https://agentmods.dev/skills/phuonghx/aim-cli/deployment-procedures"><img src="https://agentmods.dev/badge/skills/phuonghx/aim-cli/deployment-procedures/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/phuonghx/aim-cli/deployment-procedures"><img src="https://agentmods.dev/badge/skills/phuonghx/aim-cli/deployment-procedures.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.00085 | $0.01418 |
| Opus 5.5 | $0.00034 | $0.00567 |
| Sonnet 5.5 | $0.00017 | $0.00284 |
| Haiku 4.5 | $0.00009 | $0.00142 |
Grade A, and why
deployment-procedures 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 1mo 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 — 176 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Deployment Procedures
This skill is about how to reason through a release, not a script to run. Two deployments are never quite the same, so the goal is to internalize the principles and translate them to whatever platform is in front of you. Whenever a step appears, ask why it exists before you perform it.
Choosing Where To Run It
What you're shipping decides the platform, and the platform decides the mechanics.
What kind of thing is this?
├─ Static site / JAMstack ........ Vercel · Netlify · Cloudflare Pages
├─ Ordinary web app
│ ├─ want it managed .......... Railway · Render · Fly.io
│ └─ want full control ........ a VPS with PM2 or Docker
├─ Many small services ........... a container orchestrator
└─ Event-driven / functions ...... edge runtimes · Lambda
Each one releases differently:
| Platform | How a release happens |
|---|---|
| Vercel / Netlify | Push to git, it builds and ships |
| Railway / Render | Git push or a CLI command |
| VPS + PM2 | SSH in and run the steps yourself |
| Docker | Push an image, then orchestrate it |
| Kubernetes | kubectl apply the manifests |
Before You Ship
Four things to confirm
Group your pre-flight checks into four buckets, and don't proceed until all four are green:
| Bucket | The question it answers |
|---|---|
| Code health | Do tests pass, is it linted, did someone review it? |
| Build | Does the production build succeed cleanly? |
| Environment | Are env vars present and secrets current? |
| Safety net | Is there a backup and a written rollback path? |
The pre-flight list
- Test suite green
- Reviewed and approved
- Production build clean
- Environment variables confirmed
- Migrations prepared, if any
- Rollback path written down
- Team given a heads-up
- Monitoring open and ready
The Shape Of A Release
Five phases
PREPARE → re-check code, build, and config
SNAPSHOT → capture the current state so you can return to it
SHIP → push the change with dashboards open
INSPECT → health check, scan logs, walk a key flow
SETTLE → looks good? lock it in. trouble? roll back.
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.
- 1mo ago First seen · 176 lines · 85 tokens per session scan A 7f8ac77ce6ea
deployment-procedures is a skill published in the GitHub repository phuonghx/aim-cli (1 stars, last pushed 3mo ago), licensed MIT. It adds 85 tokens to every session and 1,418 once invoked, about $0.0003 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-08-31.
Other skills, from other repositories
release-rollback
Plan and execute authorized release promotion or rollback with exact artifact and data compatibility. Use when deploying versions, changing traffic or recovering a bad release; do not equate reversing code with restoring data.
release-check
Use when cutting an Orchard release (tagging a new version of the FastAPI inventory service) — walks the pre-tag checklist so migrations, verify, changelog, and the tag stay in sync.
shared-tooling-changesets
Versioning and changelog management with @changesets/cli — adding changesets, version bumping, changelog generation, monorepo publishing, pre-release modes, and CI automation.
changelog-tracker
Monitors version changes with semantic versioning analysis and breaking change detection.
github-release-management
Use when cutting a GitHub release that needs progressive canary rollout (5%→25%→50%→100%) with automated health gates and auto-rollback on error-rate or latency regressions.
changelog-automation
Automate changelog generation from commits, PRs, and releases following Keep a Changelog format. Use when setting up release workflows, generating release notes, or standardizing commit conventions.