.agents/skills/deploy-production/SKILL.md
--- name: deploy-production description: Deploy to production workflow — final checks, approval gate, deploy, verify, rollback plan. Uses the `deployment-procedures` skill. Requires explicit APPROVE before any production mutation. disable-model-invocation: true argument-hint: [service-name] [version] --- # Deploy to Production Production deployment with mandatory approval gates, verification, and rollback plan. Every step that mutates production requires explicit user APPROVE. **⚠️ SAFETY: No
npx skillsauth add avav25/ai-assets .agents/skills/deploy-productionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Production deployment with mandatory approval gates, verification, and rollback plan. Every step that mutates production requires explicit user APPROVE.
⚠️ SAFETY: No production mutation runs without explicit user APPROVE.
Read AGENTS.md at the project root to identify:
This determines which deployment commands and health checks apply.
Confirm that staging deployment was successful:
/deploy-staging completed successfullyIf staging was not verified — STOP. Run /deploy-staging first.
/release completed)| Factor | Assessment |
|---|---|
| Breaking changes | Yes/No — migration guide ready? |
| Database migrations | Yes/No — reversible? |
| Infrastructure changes | Yes/No — /infra-change completed? |
| Third-party dependencies | Yes/No — API compatibility verified? |
| Traffic impact | Low/Medium/High |
| Rollback complexity | Simple (revert image) / Complex (DB migration) |
If Risk = HIGH, apply Agent(sre-engineer) for SLO impact assessment.
Same as /deploy-staging Step 1c — but with production configuration.
# Record current deployment state for rollback
kubectl get deployment -n production -o yaml > pre-deploy-state.yaml
Or for Helm:
helm get values <release> -n production > pre-deploy-values.yaml
helm history <release> -n production
Present the deployment plan:
## Production Deployment Plan
- **Version**: [current] → [new]
- **Method**: [K8s/Helm/Docker/Platform]
- **Migrations**: [list if any]
- **Config changes**: [list if any]
- **Expected downtime**: [none / X minutes]
- **Rollback plan**: [documented in Step 5]
- **Monitoring**: [dashboards to watch]
⚠️ STOP. Request APPROVE before proceeding to Step 3.
Only after the user explicitly approves:
# Database migration
<migration-command>
Verify migration completed successfully before proceeding.
Kubernetes / Helm:
helm upgrade --install <release> <chart> \
-n production \
-f values-production.yaml \
--set image.tag=<tag>
Rolling update strategy — monitor pod rollout:
kubectl rollout status deployment/<name> -n production --timeout=300s
If using canary deployment:
// turbo
kubectl get pods -n production -o wide
curl -s <production-url>/health
Watch for:
// turbo
kubectl logs -n production -l app=<app-name> --tail=100 --since=5m
// turbo
kubectl get events -n production --sort-by='.lastTimestamp' --field-selector type!=Normal
If issues detected — execute rollback immediately:
Helm:
helm rollback <release> <previous-revision> -n production
Kubernetes:
kubectl rollout undo deployment/<name> -n production
Database migration rollback:
<rollback-migration-command>
After rollback:
## Production Deployment Summary
- **Version**: [old] → [new]
- **Deployed at**: [timestamp]
- **Method**: [K8s/Helm/Docker/Platform]
- **Migrations**: [applied/N/A]
- **Health check**: [pass/fail]
- **Smoke tests**: [pass/fail]
- **Monitoring**: [stable/issues detected]
- **Rollback**: [not needed / executed at timestamp]
- **Production URL**: [url]
- **Next steps**: [monitoring period, team notification, release announcement]
/deploy-staging (staging verification), /release (version tag)Agent(devops-engineer), Agent(sre-engineer), Agent(devops-architect) (deployment strategy design)deployment-procedures skilldevelopment
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.
development
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.
tools
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.
tools
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.