avav25/deployment-procedures
plugin/skills/deployment-procedures/SKILL.md
Use this skill when authoring or reviewing a deploy workflow that needs the strategy and rollback knowledge — the deployment strategy reference (rolling, blue-green, canary, recreate) plus rollback decision criteria, pre-deploy checklist, and post-deploy verification, loaded by the `/deploy-production` and `/deploy-staging` workflows; not a workflow itself.
$ install --global
skillsauthnpx skillsauth add avav25/ai-assets deployment-proceduresInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 23, 2026, 4:33 AM151.5s2 files scanned
SKILL.md
- name:
- deployment-procedures
- description:
- Use this skill when authoring or reviewing a deploy workflow that needs the strategy and rollback knowledge — the deployment strategy reference (rolling, blue-green, canary, recreate) plus rollback decision criteria, pre-deploy checklist, and post-deploy verification, loaded by the `/deploy-production` and `/deploy-staging` workflows; not a workflow itself.
- disable-model-invocation:
- true
Deployment Procedures — Strategy & Rollback Reference
Knowledge reference for deployment strategies (rolling, blue-green, canary, recreate) plus rollback decision criteria, pre-deploy checklists, health-check patterns, and post-deploy verification. Loaded by the /deploy-production and /deploy-staging workflows; not a workflow itself.
When to Use
- Deploying application updates to production
- Planning rollback strategies before deployment
- Verifying production health after deployment
- Investigating post-deployment issues
When NOT to Use
- Deploying to staging (use
/deploy-stagingworkflow) - Making infrastructure changes (use
/infra-changeworkflow) - Planning release version and changelog (use
/releaseworkflow)
Deployment Strategies
| Strategy | When to Use | Risk | Downtime | |---|---|---|---| | Rolling update | Standard deploys, stateless services | Low | Zero | | Blue-Green | Critical services, instant rollback needed | Low | Zero | | Canary | High-risk changes, gradual validation | Medium | Zero | | Recreate | Stateful services, breaking schema changes | High | Brief |
Rolling Update (Default)
- Gradually replace old pods with new ones
- Health checks gate the rollout — unhealthy pods stop the rollout
- Configure
maxSurgeandmaxUnavailablefor rollout speed - Monitor error rates during rollout window
Canary Deployment
- Deploy new version to small subset (5–10% traffic)
- Monitor error rate, latency, and business metrics for 5–10 minutes
- If healthy → gradually increase traffic (25% → 50% → 100%)
- If degraded → route all traffic back to stable version
Blue-Green Deployment
- Deploy new version alongside current (green alongside blue)
- Run full smoke tests against green
- Switch traffic from blue to green
- Keep blue running for instant rollback (15–30 minutes)
- Decommission blue after confidence period
Feature-Flag-Coupled Deploys (Decoupled Deploy)
Decoupled deploy ships the new code path dark (flag default off), then flips the flag in a second, independent action. The deploy itself is low-risk because the new code path is gated; risk shifts to the flag flip, which is reversible in seconds.
When to use
- Behavior changes that need progressive rollout regardless of deploy strategy (rolling / blue-green / canary all benefit)
- Risky changes that need fast rollback without redeploy
- A/B tests, regional rollouts, or per-customer enablement
- Database migrations following an expand-contract sequence — flag gates the read-from-new switch
Workflow
- Deploy dark: ship the code with the flag's default value set to OFF. The deploy is low-risk; old behavior continues.
- Verify in production: run synthetics, check logs/metrics — the new code path is reachable but inert.
- Internal-only flip: enable the flag for internal users (test rule on email domain or user ID). Verify behavior.
- Ramp: 1% → 5% → 25% → 50% → 100%. Watch error rate, latency, and business metrics at each step. Pause or rollback the flag at the first regression.
- Cleanup: once the flag has been at 100% for the agreed soak period (typically 1–2 weeks), remove the flag and the old code path in a follow-up PR. Stale flags rot — every flag must have a removal date.
Platforms (vendor-neutral first, then vendor-specific)
| Platform | SDK marker | Notes |
|---|---|---|
| OpenFeature | @openfeature/... packages | Vendor-neutral standard. Pluggable provider (LD/Unleash/Flagsmith/Split). Default choice when starting fresh in 2026. |
| LaunchDarkly | launchdarkly-*-sdk | Mature commercial. Strong UI, good targeting rules. |
| Unleash | unleash-client / @unleash/... | Open-source + commercial. Good fit for self-hosted. |
| Flagsmith | flagsmith | Open-source + commercial. Lightweight. |
| Split.io | @splitsoftware/splitio | Strong experimentation focus (built-in metrics + statistical significance). |
| GrowthBook | @growthbook/growthbook-* | Open-source. Strong A/B-test analysis. |
Anti-patterns
- Flag-only deploys with no kill date: flags accumulate and become permanent state. Track flag age; remove on schedule.
- Reading a flag in a hot path without local cache: flag SDK call inside a per-request loop adds latency and a network failure mode. Cache flag values per request or per session.
- Combining many flags into one big flip: one big-bang flag breaks fast-rollback. One concern → one flag.
Pre-Deployment Checklist
- [ ] All tests pass on release branch
- [ ] Staging deployment verified
- [ ] Database migrations tested (forward and rollback)
- [ ] Feature flags configured
- [ ] Monitoring dashboards ready
- [ ] On-call team notified
- [ ] Rollback plan documented and tested
- [ ] Release notes prepared
Post-Deployment Verification
- [ ] Health endpoint returns 200
- [ ] Error rate ≤ pre-deploy baseline
- [ ] Latency P95 within SLO target
- [ ] No new error patterns in logs
- [ ] Key user journeys functional
- [ ] Database connections stable
- [ ] External integrations responding
- [ ] Alerts not firing
Integration
- Follows rules:
Agent(devops-engineer)(infrastructure),Agent(sre-engineer)(SLOs, monitoring) - Used by workflows:
/deploy-production,/deploy-staging - Companion resources:
rollback-procedure.md
Related Skills
avav25/knowledge-sync
development
VerifiedTrustedCommunity
Use this skill when running the recurring (daily) knowledge-base rescan for a repo that already has knowledge/.knowledge-sync.yml — the main-thread dispatcher that reads the config, computes the git delta since last_scanned_sha, maps changed paths to affected doc areas, early-exits cheaply when nothing changed, then fans out one Agent(content-writer) per affected area, applies the propose/direct update policy, advances the baseline only on success, and writes an L4 run log — all with the G1 untrusted-content choke-point, secret-scan, deny-list, and budget controls woven in. For first-time setup use /knowledge-sync-init.
1SKILL.mdUpdated May 24, 2026
avav25/knowledge-sync-init
development
VerifiedTrustedCommunity
Use this skill when bootstrapping scheduled knowledge-base sync for a repo that has no knowledge/.knowledge-sync.yml yet — to run one-time setup that detects the knowledge_root from CLAUDE.md/AGENTS.md, maps doc areas to source globs, records opt-in external sources (Linear/Notion/WebFetch, all disabled by default), captures a baseline last_scanned_sha, sets the per-area update policy, generates or seeds knowledge/CONVENTIONS.md, provisions the L4 memory dir, and offers to register the daily routine. Routes ongoing recurring sync operations to /knowledge-sync.
1SKILL.mdUpdated May 24, 2026
avav25/ai-skills-init
tools
VerifiedTrustedCommunity
Use this skill when bootstrapping a target repository to be ai-skills-aware — on the first run of any ai-skills workflow in a fresh repo, when adopting the ai-skills plugin in an existing repo, or after upgrading to a plugin version that adds new memory paths or templates, including when the user does not say "init" but asks to "set up" or "onboard" the repo — to detect codebase type, create CLAUDE.md + AGENTS.md scaffolding, initialize the .ai-skills-memory/ directory tree from L1 templates, and configure .gitignore. Idempotent — safe to re-run. Accepts `--codebase-type <type>` and `--overwrite`. Not for re-initializing only memory — use `/memory-init` instead.
1SKILL.mdUpdated May 18, 2026
avav25/plugin-author
tools
VerifiedTrustedCommunity
Use this skill when extending, repairing, or improving plugin assets, when ingesting a `/feedback` report as a fix-cycle backlog, or when you do not remember which lower-level command is right for the job — the umbrella workflow for ai-skills plugin-asset authoring and maintenance: creating, auditing, fixing, improving, refactoring, and migrating skills, agents, rules, hooks, prompts, schemas, and rubrics inside the plugin. Auto-classifies the request, loads the right knowledge skills (`@prompt-engineering`, `@context-engineering`, `@team-protocols`), and spawns the right subagents (`prompt-engineer`, `system-architect`, `python-engineer`, `software-engineer`, `qa-engineer`, `eval-judge`) via the `Agent` tool.
1SKILL.mdUpdated May 14, 2026