with one click
release-checklist
Full release checklist for multi-cloud deployment (GCP + AWS)
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Full release checklist for multi-cloud deployment (GCP + AWS)
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Recurring 23-domain enterprise/ISO repository audit — governance, traceability, security, supply chain, reproducibility, observability, architecture, technical debt, DX — produces a findings report with file:line evidence and risk ratings, and preserves the audit bar via anti-patterns Q-01…Q-08
Recurring 23-domain enterprise/ISO repository audit — governance, traceability, security, supply chain, reproducibility, observability, architecture, technical debt, DX — produces a findings report with file:line evidence and risk ratings, and preserves the audit bar via anti-patterns Q-01…Q-08 (Mode: AUTO — AGENTS.md Agent Behavior Protocol applies.)
Review cloud costs against budget and identify optimization opportunities
Debug ML inference issues — latency spikes, wrong predictions, event loop blocking
Scan a service for edge-protection coverage (WAF, DDoS mitigation, rate limiting) against ADR-042/D-38 — produces a PASS/FAIL report with file:line evidence
Scan a service for edge-protection coverage (WAF, DDoS mitigation, rate limiting) against ADR-042/D-38 — produces a PASS/FAIL report with file:line evidence (Mode: AUTO — AGENTS.md Agent Behavior Protocol applies.)
| name | release-checklist |
| description | Full release checklist for multi-cloud deployment (GCP + AWS) |
| allowed-tools | ["Read","Grep","Glob","Bash(git:*)","Bash(docker:*)","Bash(kubectl:*)","Bash(gh:*)","Bash(curl:*)"] |
| when_to_use | Use when preparing a version release to production across GCP and AWS. Examples: 'release v1.2.0', 'prepare production release', 'deploy new version', 'multi-cloud release' |
| argument-hint | <version-tag> [service-name] |
| arguments | ["version-tag"] |
| authorization_mode | {"pre_flight_checks":"AUTO","build_images":"AUTO","deploy_dev":"AUTO","deploy_staging":"CONSULT","deploy_production":"STOP","rollback_invocation":"STOP","escalation_triggers":[{"quality_gate_fail":"STOP"},{"sbom_missing":"STOP"},{"kyverno_policy_fail":"STOP"},{"disagreement_in_metrics":"CONSULT"}]} |
Before tagging, confirm the coherence gate is green — it checks (among
other things, C6) that releases/v{VERSION}.md exists, which is what the
GitHub Release will be built from:
python3 scripts/check_doc_coherence.py
# Update version
export VERSION=v{MAJOR}.{MINOR}.{PATCH}
# Tag and push
git tag -a ${VERSION} -m "Release ${VERSION}: {summary}"
git push origin ${VERSION}
Do not run gh release create / gh release edit after this. Pushing
the tag triggers .github/workflows/release-on-tag.yml (AUTO), which
publishes the GitHub Release automatically — title from
releases/${VERSION}.md's H1, full file as the body, --latest computed
for the active v0.x line. Verify it published correctly instead:
gh release view ${VERSION} # confirm title/body/latest look right
If the published Release has the wrong title/body, the fix is in
release-on-tag.yml or releases/${VERSION}.md — not a manual
gh release edit patching the symptom (rule 16 §"Release publication is
automatic").
# For each service
for SERVICE in service-a service-b service-c; do
# GCP Artifact Registry
docker build -t ${GCP_REGISTRY}/${SERVICE}:${VERSION} ${SERVICE}/
docker push ${GCP_REGISTRY}/${SERVICE}:${VERSION}
# AWS ECR
docker build -t ${AWS_REGISTRY}/${SERVICE}:${VERSION} ${SERVICE}/
docker push ${AWS_REGISTRY}/${SERVICE}:${VERSION}
done
# Update overlays (production environment for release)
# k8s/overlays/gcp-prod/kustomization.yaml → newTag: ${VERSION} (CI replaces with @sha256 digest)
kubectl apply -k k8s/overlays/gcp-prod/
kubectl rollout status deployment --all -n {namespace} --timeout=300s
# Update overlays (production environment for release)
# k8s/overlays/aws-prod/kustomization.yaml → newTag: ${VERSION} (CI replaces with @sha256 digest)
kubectl apply -k k8s/overlays/aws-prod/
kubectl rollout status deployment --all -n {namespace} --timeout=300s
/health returning 200 on all services/predict returning valid predictions/metrics being scraped by PrometheusSmoke tests run inside the deploy chain via deploy-common.yml
(canonical SSOT). Each environment job invokes the smoke test step
against the freshly-deployed pods; failure halts the chain.
# Manual invocation (one service, one cloud) for debugging:
kubectl --context=$CLUSTER -n $NAMESPACE port-forward svc/$SERVICE 8000:8000 &
curl -fsS http://localhost:8000/health # liveness
curl -fsS http://localhost:8000/ready # readiness (gates traffic)
curl -fsS -X POST http://localhost:8000/predict \
-H 'content-type: application/json' \
-d "$(cat tests/fixtures/smoke_payload.json)"
kill %1
For a multi-service / multi-cloud sweep, drive the loop from a
runbook page or a CI workflow-dispatch — the template does not ship
a scripts/smoke_test.py script (would compete with deploy-common.yml
as SSOT).
If any issue detected within 30 minutes:
# Rollback all services
kubectl rollout undo deployment --all -n {namespace}
kubectl rollout status deployment --all -n {namespace}
The release is complete when ALL of the following hold across BOTH clouds:
/health 200, /ready 200, /predict
returns valid response, /metrics scraped by Prometheus)releases/v<version>.md publishedops/audit.jsonl with operation
= release_deploy, result = success for each cloud × env pairIf any of these signals appears, the release is NOT complete and must
be either rolled back via /rollback (STOP) or paused for human review:
agentic/workflows/release.mdrollback (consequence path on any failure mode)security-audit (gate before build)