Deploy a service to the staging environment with health checks and rollback. Use when asked to deploy, push to staging, release to staging, or test a deployment. Do NOT use for production deployments (use deploy:production instead) or for CI/CD pipeline configuration.
The canonical home for this skill is deploy:staging in LuminairPrime/git-worktrees-prime
Deploy a named service to the staging Kubernetes cluster with automated health checks, canary validation, and automatic rollback on failure.
Manual staging deployments are error-prone: engineers forget health checks, skip canary validation, or deploy without verifying the image exists. This skill encodes the team's deployment runbook as a repeatable, validated workflow. It catches the mistakes humans make when deploying at 4pm on a Friday.
Check that the deployment can proceed safely.
deploy/services.yamlskopeo inspect docker://registry.internal/${service}:${tag}kubectl get deploy ${service} -o jsonpath='{.metadata.annotations.deploy-lock}'If --dry-run is set, print what would happen and stop after this step.
Common mistake: Running deploy:staging when the image hasn't been pushed yet. The skill checks the registry first to avoid a ImagePullBackOff loop that takes 5 minutes to surface.
Unless --skip-tests is passed:
./scripts/pre-deploy-check.sh ${service}This runs integration tests against the staging database. If tests fail, stop and report which tests failed. Do not proceed to deployment.
Why not skip tests by default? The staging database has real-ish data that occasionally exposes bugs not caught by unit tests. Skipping tests saved 3 minutes but cost us a 2-hour debugging session twice last quarter.
Apply the deployment manifest with 10% canary traffic:
kubectl apply -f deploy/manifests/${service}-canary.yaml
kubectl rollout status deploy/${service}-canary --timeout=120sWait 60 seconds, then check error rates:
./scripts/check-canary-metrics.sh ${service} --threshold 0.5If canary error rate exceeds 0.5%, initiate rollback (Step 5).
If canary passes, promote to full deployment:
kubectl apply -f deploy/manifests/${service}-full.yaml
kubectl rollout status deploy/${service} --timeout=300sVerify health endpoint returns 200:
curl -sf https://${service}.staging.internal/healthz || echo "HEALTH_CHECK_FAILED"If any step fails after Step 2:
kubectl rollout undo deploy/${service}
kubectl rollout undo deploy/${service}-canaryReport what failed, the last 20 lines of pod logs, and the rollback status.
Gotcha: Rollback does not revert database migrations. If Step 2 included a migration, you need to manually revert it. The skill warns about this but cannot automate it safely.
| Condition | Action |
|---|---|
| Service not in services.yaml | Stop with "Unknown service: ${service}. Available: ..." |
| Image not in registry | Stop with "Image not found. Did you run make push?" |
| Deploy lock active | Stop with "Deployment in progress by ${user} since ${time}" |
| Canary error rate > threshold | Auto-rollback, report error rate and sample errors |
| Health check fails after promote | Auto-rollback, report health check response |
--dry-run: Validate prerequisites only, do not deploy--skip-tests: Skip pre-deploy integration tests (use with caution)LuminairPrime/git-worktrees-prime
49d6ae2
Canonical home
since Oct 9, 2026
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.