name: symptomsync-release-change description: Guide for making safe changes to SymptomSync infrastructure, CI/CD, deployment, and operational behavior. Use when tasks touch aws/, ansible/, jenkins/, devops/, Dockerfile, .devcontainer/, or .github/workflows/ci.yml, especially for CDK stack changes, blue-green rollout logic, canary deployment behavior, pipeline changes, or production-readiness docs.
SymptomSync Release Change
Use this skill when the task affects deployment or release operations.
Workflow
- Read the nearest
AGENTS.mdplus the repo-rootAGENTS.md. - Determine which surfaces are coupled:
- CDK stack in
aws/ - rollout automation in
ansible/ - Jenkins pipeline
- GitHub Actions pipeline
- runbooks and deployment docs
- CDK stack in
- Make the smallest safe change.
- Update every coupled operational artifact that becomes stale.
Preserve these mechanics unless the task explicitly changes them
- Lambda
livealiases - CodeDeploy canary deployment groups
- API Gateway
blueandgreenstages /healthsmoke path unless intentionally changed- SSM parameter
/symptomsync/active_stage - WAF and alarm wiring
Read references/release-safety-checklist.md when you need the rollout and drift checklist.
Validation
- If possible, run
npx cdk synthinaws/. - Re-read
.github/workflows/ci.ymlandjenkins/Jenkinsfiletogether when build, test, or deploy stages change. - Re-read
DEPLOYMENTS.md,devops/runbooks/progressive-delivery.md, anddevops/runbooks/production-readiness.mdwhen rollout or health semantics change.
Guardrails
- Do not change rollout assumptions in code without updating
ansible/blue-green-rollout.ymland the runbooks. - Treat placeholder or aspirational cloud code skeptically, especially around chatbot integrations.
- Flag drift between Jenkins and GitHub Actions immediately.
Related skills
- Use
$symptomsync-doc-syncwhen code changes force runbook or deployment doc updates. - Use
$symptomsync-reviewfor a release-safety review pass.