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 agentmods add skills/phuonghx/aim-cli/deployment-proceduresnpx skills add phuonghx/aim-cli --skill deployment-proceduresgit clone --depth 1 https://github.com/phuonghx/aim-cliWhat 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 | $0.00085 | $0.01418 |
| Opus 5 | $0.00043 | $0.00709 |
| Sonnet 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 yesterday.
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.
- yesterday 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 2mo ago), licensed MIT. It adds 85 tokens to every session and 1,418 once invoked, about $0.0004 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-31.
Other skills, from other repositories
postmortem-writing
Template and process for writing incident reports (IRs) with causal chain analysis, action items, and mandatory skill/checklist updates.
lorekeeper-memorize
Memorize important facts, user instructions, unique discoveries, and interesting knowledge into the Lorekeeper knowledge base. Use proactively whenever the agent encounters noteworthy information — domain knowledge, user preferences, architectural decisions, debugging insights, workflow instructions, or any fact worth…
remember
Save something to memory for future sessions. Use when the user says "remember this", "save for later", "don't forget", or wants to persist any preference, fact, lesson, or note across sessions.
reverse-engineering-company-system
Run reverse engineering as a coordinated EVOKORE operating system with expert panels, additive workflows, and lightweight learning loops. Use when the target is complex enough that you want more than isolated tool calls.
reverse-engineering-improvement-loop
Convert completed reverse-engineering work into better future workflows, skills, and panel narratives. Use after meaningful milestones, repeated friction, or major analysis wins.
hindsight-self-hosted
Store team knowledge, project conventions, and learnings from tasks. Use to remember what works and recall context before new tasks. Connects to a self-hosted Hindsight server. (user).