45ck blue-green-readiness-reviewer
Purpose
Review whether a service is actually ready for blue/green or similar low-downtime deployment patterns.
Trigger this skill when
- A cloud or platform decision needs operationally realistic review rather than generic best-practice talk.
- You need outputs that can feed architecture, operations, release, migration, or governance work.
- The team risks hand-waving ownership, drift, rollback, timing, or lifecycle constraints.
Expected inputs
- deployment topology
- traffic switching method
- state handling approach
- observability setup
- rollback expectations
Deliverables
- blue-green readiness summary
- blocking gaps
- state or data risks
- traffic cutover notes
- recommendation
Operating procedure
- Clarify the actual workload, platform boundary, environment scope, and operational ownership.
- Separate what is observed, measured, or approved from what is merely assumed.
- Produce the skill-specific artifact or review output.
- Surface lifecycle risks, drift, dependency timing, rollback gaps, and hidden ops burden explicitly.
- Recommend the next best handoff instead of trying to solve the whole platform strategy at once.
Quality gates
- The result is specific to the real workload and operating context.
- Ownership, timing, and rollback assumptions are visible.
- The output is usable by engineers, platform owners, ops staff, architects, or assessors.
- The recommendation reflects operational safety and maintainability, not only implementation speed.
Handoff targets
- update-rollback-planner
- maintenance-window-planner
- migration-wave-planner
Output style
- Be explicit about control, ownership, reversibility, and operational cost.
- Prefer concrete decision artifacts over general cloud prose.
- Surface evidence gaps instead of inventing certainty.
- Keep outputs reusable inside runbooks, ADRs, tickets, migration plans, and platform docs.
Failure modes to avoid
- Do not assume “cloud-native” means operationally simple.
- Do not ignore drift, tagging gaps, or unowned resources.
- Do not treat rollback as optional for risky updates or migrations.
- Do not bury customer impact or support timing behind architecture language.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Risks / blockers
## Open questions
## Recommended next skill