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 vignesh2027/AI-AGENT-SKILLS --skill deployment-strategygit clone --depth 1 https://github.com/vignesh2027/AI-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/vignesh2027/ai-agent-skills/deployment-strategy)<a href="https://agentmods.dev/skills/vignesh2027/ai-agent-skills/deployment-strategy"><img src="https://agentmods.dev/badge/skills/vignesh2027/ai-agent-skills/deployment-strategy/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/vignesh2027/ai-agent-skills/deployment-strategy"><img src="https://agentmods.dev/badge/skills/vignesh2027/ai-agent-skills/deployment-strategy.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.00016 | $0.00698 |
| Opus 5 | $0.00008 | $0.00349 |
| Sonnet 5 | $0.00003 | $0.00140 |
| Haiku 4.5 | $0.00002 | $0.00070 |
Grade A, and why
deployment-strategy 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 10d 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Overview
Deployments fail. The question is not whether, but whether you can recover quickly. This skill makes deployments reversible, observable, and gradual.
When to Use
- Before every production deployment
- When designing a deployment pipeline
- When a deployment caused a production incident
- As part of the
/shipworkflow
Process
Step 1: Write the rollback procedure first
Before deploying, document how to roll back. If you can't write the rollback procedure, you're not ready to deploy.
Step 2: Define the rollout stages
1% → 10% → 50% → 100% for high-risk changes. 10% → 100% for low-risk changes. Never: 0% → 100% for anything that touches user-visible behavior.
Step 3: Choose a deployment strategy
- Blue/green: spin up new environment, switch traffic, keep old environment warm for rollback
- Canary: route a percentage of traffic to new version, measure, expand
- Feature flags: deploy code dark, flip flag to enable for users
- Rolling: replace instances one by one, abort if errors spike
Choose based on: how reversible is the change? How quickly can you detect problems?
Step 4: Define the deployment success criteria
Before deploying: what metrics must hold for the deployment to be considered successful?
- Error rate stays below X%
- p99 latency stays below Y ms
- No new error types in logs
- Key business metric (signups, orders) not regressing
Step 5: Bake time
After deploying to a stage: wait before expanding. Minimum bake time:
- 1% stage: 15 minutes
- 10% stage: 1 hour
- 50% stage: 4 hours
High-risk changes need longer bake times.
Step 6: Database migrations
- Migrations must be backward compatible (old code + new schema must work)
- Deploy migration before new code; keep old code running
- Never delete a column in the same release that stops using it
- Test rollback of the migration
Step 7: Automate the deployment gate
Success criteria from Step 4 must be checked automatically. If they fail, the deployment halts. Not: "someone watches the dashboard." Automatic.
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.
- 10d ago First seen · 80 lines · 16 tokens per session scan A 9f88f581f69d
deployment-strategy is a skill published in the GitHub repository vignesh2027/AI-AGENT-SKILLS (2 stars, last pushed 12d ago), licensed MIT. It adds 16 tokens to every session and 698 once invoked, about $0.0001 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
npm
Publish and manage packages on the npm registry (npmjs.com), publish, dist-tags, deprecate, owners, download stats, private installs. Use when the user asks to publish, release or manage an npm package, or to inspect the registry.
release-verification
A release-verification checklist for software versions and packages. It covers changelogs, tests, packaging, installation smoke checks, version-control actions, publishing, and checks after release.
audit-release
A pre-release review assistant that checks whether a software package or plugin is ready to publish.
github
Interact with GitHub using the gh CLI. Use for issues, PRs, CI runs, releases, and advanced API queries.
git-release-manager
Use when the user explicitly asks to prepare, tag, publish, push, or audit a Git release. Inspect branch, worktree, version metadata, changelog, tests, and release artifacts first, obtain confirmation for irreversible release actions, and record a recovery path.
changelog
Create engaging changelogs for recent merges to main branch.