rollout
rollout — orchestrate a code rollout end-to-end
/rollout is the entry point an agent should reach for whenever the user wants to ship something. It drives the entire lifecycle: read the change → draft a monitoring plan → merge the PR (with consent) → wait for / trigger the deploy → monitor the rollout → hand off cleanly (or pivot into plan mode if a regression lands).
When to use
Whenever the user wants to ship a code change. Triggers include: "ship this", "deploy this", "roll this out", "release this", "merge and watch", "post-deploy monitoring", "let's deploy". /rollout is also the right answer when the user asks how to monitor a deploy that already merged — see the merged-not-deployed phase below.
For the methodology, vocabulary, and limits, read references/overview.md. For the full table of invocation forms, read references/invocation-forms.md. For phase-by-phase decision logic, read references/decision-tree.md. For known limits, read references/limitations.md.
Invocation forms
| Form | Use when |
|---|---|
/rollout |
In-session work; the current branch has an open PR or a recent merge. Most common case. |
/rollout to <env> |
Same as above, but target a specific environment (staging, production, a region, etc.). |
/rollout PR <num> |
Out-of-session; user is in a different checkout (or a fresh session) and wants to orchestrate against a specific PR via gh CLI. Open PRs supported (remote merge with consent); merged PRs go straight to monitoring. |
/rollout PR <num> to <env> |
Combined: out-of-session + env-targeted. |
More from firetiger-oss/skills
install-firetiger
Add OpenTelemetry instrumentation to Node.js, Python, Go, or Rust applications for Firetiger observability—use when asked to "instrument my app", "add observability", "set up tracing", "add telemetry", "configure OpenTelemetry", "otel setup", "firetiger instrumentation", "install firetiger", or send traces/metrics/logs to Firetiger.
9plan-rollout
Adds a multi-environment change-monitoring section to the agent's plan: enumerates target environments (staging, prod, regions, BYOC tenants), picks SLIs (golden signals + intended-effect + business-outcome) per env or shared, queries 24h baselines, sets baseline-referenced thresholds, and chooses a checkpoint schedule based on risk tier. Use when the user is planning a code change that will be deployed, preparing a rollout, asking how to monitor a release, doing post-deploy validation prep, planning a canary, or wants production watched after merging — even when they don't say 'monitoring plan'. Anchored on Google SRE book vocabulary (golden signals, SLI, error budget, blast radius). Companion to monitor-rollout.
8monitor-rollout
Runs a change-monitoring plan in the foreground of the current coding-agent session: polls each environment's deploy system for the rollout, runs each checkpoint against the indicators with per-environment grouping, applies evidence-discipline (≥24h baseline + same-time-of-day prior + analytical reason + variance test), and emits per-env progress reports inline. Sleeps between checkpoints via a background bash sleep + notification. On the first issue detected in any environment, hands off into plan mode so the same session pivots to fixing it (sequential single-issue mode). Use when a deploy has been triggered, the user merged a PR and wants production watched, doing post-deploy validation, watching a canary, or babysitting a multi-environment rollout — even when they don't say 'execute the plan'. Reads a plan produced by plan-rollout.
8