Purpose
Recommend the right deployment pattern for a specific service by weighing its statefulness, traffic profile, rollback cost, and blast radius against the operational overhead each pattern demands — then produce a concrete rollout playbook the team can implement immediately. Ends the guesswork of defaulting every service to the same strategy.
When to Use
Invoke this skill when the user asks to:
- Choose a deployment strategy for a new service or microservice
- Justify why a service should use canary, blue/green, rolling, or feature flags
- Reduce release risk or blast radius for a high-traffic or revenue-critical service
- Standardize how a team or platform ships changes to production
- Reevaluate a deployment approach after an incident or a scaling change
- Decide between two candidate patterns for a specific rollout
Inputs Required
Before starting, collect:
- Service description: What the service does, language/runtime, and whether it's user-facing or internal
- Risk profile: Blast radius if a bad release ships — revenue impact, user count affected, criticality (tier 0/1/2)
- Statefulness: Stateless, session-bound, or holds persistent state (databases, in-flight jobs, long-lived connections)
- Traffic profile: Requests/sec or DAU, peak vs. trough patterns, and whether traffic can be split by percentage
- Infrastructure: Orchestrator/platform (Kubernetes, ECS, serverless, VMs), load balancer/service mesh, and whether feature-flag tooling exists
- Deploy frequency: How often the service ships — multiple/day, weekly, or rarely
- Rollback cost: How hard it is to reverse a release — trivial, requires migration reversal, or effectively irreversible
If risk profile or statefulness is missing, assume tier-1 stateless and note the assumption; flag that a stateful service changes the recommendation materially.
Instructions
Step 1: Establish the Decision Drivers
Extract the four variables that drive pattern choice and rate each Low / Medium / High:
- Blast radius: How much damage a bad release does before it's caught
- Rollback cost: How expensive/slow it is to reverse (schema migrations and irreversible data ops push this High)
- Traffic splittability: Can traffic be routed by percentage or cohort? (Requires a mesh, weighted LB, or flag system)
- Statefulness constraint: Does the service hold state that complicates running two versions simultaneously?
State these four ratings explicitly before recommending — they are the reasoning basis.
Step 2: Score All Four Patterns
For each pattern, give a fit score (Strong / Viable / Poor) against this service, with one-line reasoning tied to Step 1 ratings.
Canary
- Best when: high blast radius + traffic is splittable + you want to catch regressions on a small cohort before full exposure
- Requires: percentage-based routing, per-cohort metrics, automated promotion/abort gates
- Poor when: low traffic (canary cohort too small to be statistically meaningful), or no metric-based abort capability
Blue/Green
- Best when: rollback must be instant, high rollback cost tolerance is low, and you can afford double the infra briefly
- Requires: two full environments, atomic traffic switch (DNS/LB), and a way to drain in-flight requests
- Poor when: stateful with shared datastore that can't run two schema versions, or infra cost of doubling is prohibitive
Rolling
- Best when: stateless, moderate risk, cost-sensitive, and the orchestrator handles it natively (default k8s Deployment)
- Requires: healthy readiness/liveness probes, surge/unavailable budgets, backward-compatible changes during the roll
- Poor when: high blast radius (bad version serves real traffic during the roll) or non-backward-compatible schema changes
Feature Flag / Dark Launch
- Best when: you want to decouple deploy from release, target specific cohorts, or test in production without user exposure
- Requires: a flag management system, kill-switch discipline, and flag cleanup process
- Poor when: no flag tooling exists, or the change is infrastructural (flags govern code paths, not binaries)
Step 3: Name the Primary Recommendation
Pick one primary pattern. Be decisive. Provide:
- The pattern and a 2-3 sentence rationale tied directly to the Step 1 drivers
- A secondary/fallback pattern and the condition under which the team should switch to it
- One combination note if a hybrid applies (e.g., canary the binary + feature-flag the risky code path)
Step 4: Rollout Mechanics Playbook
Concrete mechanics for the recommended pattern:
- Progression: The exact stages (e.g., canary 1% → 5% → 25% → 50% → 100%, with bake time per stage)
- Promotion gates: Metric thresholds that must hold to advance (error rate, p99 latency, saturation)
- Traffic control mechanism: How the split is enforced on this infrastructure
- Duration: Expected total rollout time from first stage to full
Step 5: Rollback Triggers and Abort Conditions
- Automated abort thresholds: Specific signals that trigger auto-rollback (error rate > baseline + X%, p99 latency breach, health check failures)
- Manual rollback procedure: The exact command/action and expected time-to-safe
- Migration/state caveat: If schema or data migrations are involved, state the forward-compatibility requirement (expand/contract pattern) and why a naive rollback fails
Step 6: Observability Requirements
The minimum instrumentation the pattern needs to be safe:
- Golden signals to segment by version/cohort: latency, traffic, errors, saturation
- Comparison view: How to compare new vs. old (or canary vs. baseline) in the dashboard
- Alerting: What must page during a rollout vs. what's informational
Output Format
- Structure: Decision drivers table → four-pattern scorecard → primary recommendation → rollout playbook → rollback triggers → observability requirements
- Length: 800–1,100 words
- Format: Structured document with a scorecard table for the four patterns; playbook and rollback as ordered steps
- Sections: Decision Drivers → Pattern Scorecard → Recommendation → Rollout Mechanics → Rollback Triggers → Observability Requirements
- Tone: Senior platform engineer — decisive, trade-off-aware, no hedging; opinions backed by the service's specific constraints
Quality Checklist
Before delivering output, verify:
- [ ] All four patterns (canary, blue/green, rolling, feature flag) are scored with reasoning — none skipped
- [ ] The four decision drivers are each rated and explicitly used to justify the recommendation
- [ ] Exactly one primary pattern is named, plus a fallback with a switch condition — no "it depends" ending
- [ ] The rollout playbook includes concrete numeric stages and bake times, not just "gradually increase"
- [ ] Rollback triggers include specific metric thresholds, not "roll back if things look bad"
- [ ] If the service is stateful or has migrations, the expand/contract caveat is addressed
Notes
- The single most common mistake is defaulting every service to rolling because it's the orchestrator default — rolling exposes real traffic to the bad version and is a poor fit for tier-0 services.
- Canary is only meaningful with enough traffic for the small cohort to be statistically significant; below a few dozen requests/sec, prefer blue/green or feature flags.
- Database migrations dominate rollback cost — recommend the expand/contract (parallel-change) pattern so the deploy strategy isn't undermined by an irreversible schema step.
- Feature flags and deployment patterns are complementary, not competing: flags govern release; the pattern governs deploy. The strongest setups combine them.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills