Blue green deploy visualization pattern
Skill kjuhwa/skills-hub/skills/design/blue-green-deploy-visualization-pattern
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill blue-green-deploy-visualization-patternAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Dual-environment (Blue/Active vs Green/Idle) side-by-side canvas with traffic-router arrow and version badges for blue-green deployment dashboards
SKILL.md
2.1 KB, 383 tokens by cl100k_base, as published. Nobody here has run it
blue-green-deploy-visualization-pattern
Blue-green deployment UIs should render two mirrored environment panels horizontally — Blue (left, currently serving) and Green (right, staging the new version) — each showing a stack of instance cards with version tag (e.g. v1.4.2 vs v1.5.0), health status dot (healthy/warming/draining), and request-per-second counter. Place a load-balancer/router node above or between the panels with an animated directional arrow (or flowing dots) whose thickness or color encodes the traffic split percentage; during cutover, animate the arrow pivoting from Blue→Green over a configurable duration (3–10s) so users visually internalize the switch moment rather than seeing an instant state flip.
Use a color-locked legend: Blue = #3B82F6 and Green = #10B981 regardless of which side is currently active — do not recolor the "active" side, because the whole point of blue-green is that either color can be active. Instead indicate active status with a glowing border, a "LIVE" pill, and a solid (vs dashed) connection line from the router. Reserve red/amber only for failed health checks or rollback state. Always show a timeline/event strip at the bottom recording the last N switches with timestamps so the current active side has historical context.
Include three secondary panels: (1) a "pre-cutover checklist" (smoke tests passed, warm-up complete, DB migrations compatible), (2) a rollback button that is visually prominent only while the new side has been live for less than the rollback-window (e.g. 15 min), and (3) a connection-draining progress bar on the side being retired, since blue-green cutovers are not truly instant — in-flight requests on the old side must complete before it can be reclaimed.