agentleFS
VoDaiLoczVoDaiLocz/kilo-kit-mcp/skills/operations/deployment-procedures/SKILL.md

deployment-procedures

Skill28 starsChanged 3 months agoApache-2.0View on GitHub

Production deployment principles and decision-making. Safe deployment workflows, rollback strategies, and verification. Teaches thinking, not scripts.

  • Commits and pushes

12 other projects use a version of this, 6 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use intelligent-routing, nextjs-react-expert and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • SKB3002Skill

    intelligent-routing

    Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.

    Also in 6 projects that use this

  • SKB3002Skill

    nextjs-react-expert

    React and Next.js performance optimization from Vercel Engineering. Use when building React components, optimizing performance, eliminating waterfalls, reducing bundle size, reviewing code for performance issues, or implementing server/client-side optimizations.

    Also in 3 projects that use this

  • xfstudioSkill

    rust-pro

    Master Rust 1.75+ with modern async patterns, advanced type system

    Also in 5 projects that use this

  • goca-seSkill

    batch-operations

    Apply a change safely across many files — refactors touching more than 5 files, library or API migrations, project-wide renames of symbols/imports/paths, or adding boilerplate to many files. Use when "do it all at once" risks context overflow or silent failures.

    Also in 3 projects that use this

  • jornalistainclusivoSkill

    design-spec

    How to author a DESIGN.md file — the machine-readable design-token + human-rationale format that must exist before any UI is built. YAML front-matter token schema (colors, typography, spacing, rounded, components), type system, token references, and canonical section order.

    Also in 3 projects that use this

  • sefaertuncSkill

    coordinator-mode

    Multi-agent orchestration patterns: when to use coordinator mode, worker prompts, parallel execution

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

3 rules. 3 are common, 0 are distinctive, and 0 are very specific to this project.

  • 3

    Common

    Most of the 7 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Every deployment is unique

    line 18
  2. Common:

    Rollback: If restart doesn't help

    line 190
  3. Common:

    Test rollback: before you need it

    line 237

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deployment Procedures

Deployment principles and decision-making for safe production releases. Learn to THINK, not memorize scripts.


⚠️ How to Use This Skill

This skill teaches deployment principles, not bash scripts to copy.

  • Every deployment is unique
  • Understand the WHY behind each step
  • Adapt procedures to your platform

1. Platform Selection

Decision Tree

What are you deploying?
│
├── Static site / JAMstack
│   └── Vercel, Netlify, Cloudflare Pages
│
├── Simple web app
│   ├── Managed → Railway, Render, Fly.io
│   └── Control → VPS + PM2/Docker
│
├── Microservices
│   └── Container orchestration
│
└── Serverless
    └── Edge functions, Lambda

Each Platform Has Different Procedures

PlatformDeployment Method
Vercel/NetlifyGit push, auto-deploy
Railway/RenderGit push or CLI
VPS + PM2SSH + manual steps
DockerImage push + orchestration
Kuberneteskubectl apply

2. Pre-Deployment Principles

The 4 Verification Categories

CategoryWhat to Check
Code QualityTests passing, linting clean, reviewed
BuildProduction build works, no warnings
EnvironmentEnv vars set, secrets current
SafetyBackup done, rollback plan ready

Pre-Deployment Checklist

  • All tests passing
  • Code reviewed and approved
  • Production build successful
  • Environment variables verified
  • Database migrations ready (if any)
  • Rollback plan documented
  • Team notified
  • Monitoring ready

3. Deployment Workflow Principles

The 5-Phase Process

1. PREPARE
   └── Verify code, build, env vars

2. BACKUP
   └── Save current state before changing

3. DEPLOY
   └── Execute with monitoring open

4. VERIFY
   └── Health check, logs, key flows

5. CONFIRM or ROLLBACK
   └── All good? Confirm. Issues? Rollback.

Phase Principles

PhasePrinciple
PrepareNever deploy untested code
BackupCan't rollback without backup
DeployWatch it happen, don't walk away
VerifyTrust but verify
ConfirmHave rollback trigger ready

4. Post-Deployment Verification

What to Verify

CheckWhy
Health endpointService is running
Error logsNo new errors
Key user flowsCritical features work
PerformanceResponse times acceptable

Verification Window

  • First 5 minutes: Active monitoring
  • 15 minutes: Confirm stable
  • 1 hour: Final verification
  • Next day: Review metrics

5. Rollback Principles

When to Rollback

SymptomAction
Service downRollback immediately
Critical errorsRollback
Performance >50% degradedConsider rollback
Minor issuesFix forward if quick

Rollback Strategy by Platform

PlatformRollback Method
Vercel/NetlifyRedeploy previous commit
Railway/RenderRollback in dashboard
VPS + PM2Restore backup, restart
DockerPrevious image tag
K8skubectl rollout undo

Rollback Principles

  1. Speed over perfection: Rollback first, debug later
  2. Don't compound errors: One rollback, not multiple changes
  3. Communicate: Tell team what happened
  4. Post-mortem: Understand why after stable

6. Zero-Downtime Deployment

Strategies

StrategyHow It Works
RollingReplace instances one by one
Blue-GreenSwitch traffic between environments
CanaryGradual traffic shift

Selection Principles

ScenarioStrategy
Standard releaseRolling
High-risk changeBlue-green (easy rollback)
Need validationCanary (test with real traffic)

7. Emergency Procedures

Service Down Priority

  1. Assess: What's the symptom?
  2. Quick fix: Restart if unclear
  3. Rollback: If restart doesn't help
  4. Investigate: After stable

Investigation Order

CheckCommon Issues
LogsErrors, exceptions
ResourcesDisk full, memory
NetworkDNS, firewall
DependenciesDatabase, APIs

8. Anti-Patterns

❌ Don't✅ Do
Deploy on FridayDeploy early in week
Rush deploymentFollow the process
Skip stagingAlways test first
Deploy without backupBackup before deploy
Walk away after deployMonitor for 15+ min
Multiple changes at onceOne change at a time

9. Decision Checklist

Before deploying:

  • Platform-appropriate procedure?
  • Backup strategy ready?
  • Rollback plan documented?
  • Monitoring configured?
  • Team notified?
  • Time to monitor after?

10. Best Practices

  1. Small, frequent deploys over big releases
  2. Feature flags for risky changes
  3. Automate repetitive steps
  4. Document every deployment
  5. Review what went wrong after issues
  6. Test rollback before you need it

Remember: Every deployment is a risk. Minimize risk through preparation, not speed.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.