How do I install the Change Risk Rollback skill?

Run npx skillmds@latest add tomevault-io/change-risk-rollback in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Change Risk Rollback safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Change Risk Rollback?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Change Risk Rollback free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Change Risk Rollback?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Change Risk Rollback by tomevault-io

Name: Change Risk Rollback
Author: tomevault-io

File contents

Change Risk & Rollback

Overview

Produce explicit risk and rollback analysis before deployment. Enumerate failure modes, assess impact, define rollback procedures, and establish Go/No-Go criteria.

REQUIRED: superpowers:verification-before-completion, superpowers:systematic-debugging

When to Use

Planning release or deployment changes
Requesting assessment of operational risk
Discussing rollback procedures
Planning infrastructure or configuration changes
Preparing production deployment

Core Workflow

Identify change scope (component, dependencies, traffic, window)
Enumerate failure modes (minimum 3 with symptom, detection, impact, probability)
Rate each risk (impact x probability)
Define rollback procedure (detection, Go/No-Go criteria, execution steps, timeline)
List prerequisites (backups, monitoring, on-call, previous version)
Select deployment strategy (Blue-Green, Canary, Rolling, Big-Bang)
Define success criteria (measurable, time-bound)

See references/failure-modes.md, references/rollback-templates.md, and references/deployment-strategies.md for details.

Quick Reference

Risk Level	Impact x Probability	Action Required
Critical	HIGH x HIGH	Executive approval, full plan
High	HIGH x MED	Full rollback plan required
Medium	MED x MED	Standard rollback procedures
Low	LOW x LOW	Minimal documentation

Red Flags - STOP

"Deployment is straightforward"
"Can roll back if needed"
"No time for risk analysis"
"Testing caught everything"
"We'll figure it out if something breaks"

All mean: Apply skill before deployment or document explicit risk acceptance.

Rationalizations Table

Excuse	Reality
"Deployment is simple"	No deployment is risk-free. Even simple changes have unexpected impacts.
"Can roll back if needed"	Rollback must be defined BEFORE deployment, not during incident.
"No time for risk analysis"	15 minutes of analysis prevents hours of incident response.
"Tested in staging"	Staging doesn't replicate production. Risk analysis still required.
"Too much work to back out"	Sunk cost fallacy. Better to delay than rush and fail.

Evidence Checklist

Change scope documented (component, dependencies, traffic)
Minimum 3 failure modes identified with detection criteria
Risk rating for each failure mode
Rollback procedure with timeline
Go/No-Go criteria explicit and measurable
Prerequisites checklist provided
Deployment strategy selected with rationale
Success criteria defined

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: change-risk-rollbackdescription: Use when planning release, deployment, or infrastructure changes. Produces risk assessment with failure modes, impact rating, rollback procedures, and prerequisite execution criteria before deployment.---# Change Risk & Rollback## OverviewProduce explicit risk and rollback analysis **before** deployment. Enumerate failuremodes, assess impact, define rollback procedures, and establish Go/No-Go criteria.**REQUIRED:** superpowers:verification-before-completion,superpowers:systematic-debugging## When to Use- Planning release or deployment changes- Requesting assessment of operational risk- Discussing rollback procedures- Planning infrastructure or configuration changes- Preparing production deployment## Core Workflow1. **Identify change scope** (component, dependencies, traffic, window)2. **Enumerate failure modes** (minimum 3 with symptom, detection, impact, probability)3. **Rate each risk** (impact x probability)4. **Define rollback procedure** (detection, Go/No-Go criteria, execution steps, timeline)5. **List prerequisites** (backups, monitoring, on-call, previous version)6. **Select deployment strategy** (Blue-Green, Canary, Rolling, Big-Bang)7. **Define success criteria** (measurable, time-bound)See `references/failure-modes.md`, `references/rollback-templates.md`,and `references/deployment-strategies.md` for details.## Quick Reference| Risk Level | Impact x Probability | Action Required || ---------- | -------------------- | ----------------------------- || Critical | HIGH x HIGH | Executive approval, full plan || High | HIGH x MED | Full rollback plan required || Medium | MED x MED | Standard rollback procedures || Low | LOW x LOW | Minimal documentation |## Red Flags - STOP- "Deployment is straightforward"- "Can roll back if needed"- "No time for risk analysis"- "Testing caught everything"- "We'll figure it out if something breaks"**All mean: Apply skill before deployment or document explicit risk acceptance.**## Rationalizations Table| Excuse | Reality || --------------------------- | ------------------------------------------------------------------------ || "Deployment is simple" | No deployment is risk-free. Even simple changes have unexpected impacts. || "Can roll back if needed" | Rollback must be defined BEFORE deployment, not during incident. || "No time for risk analysis" | 15 minutes of analysis prevents hours of incident response. || "Tested in staging" | Staging doesn't replicate production. Risk analysis still required. || "Too much work to back out" | Sunk cost fallacy. Better to delay than rush and fail. |## Evidence Checklist- [ ] Change scope documented (component, dependencies, traffic)- [ ] Minimum 3 failure modes identified with detection criteria- [ ] Risk rating for each failure mode- [ ] Rollback procedure with timeline- [ ] Go/No-Go criteria explicit and measurable- [ ] Prerequisites checklist provided- [ ] Deployment strategy selected with rationale- [ ] Success criteria defined---> Converted and distributed by [TomeVault](https://tomevault.io/claim/mcj-coder) — claim your Tome and manage your conversions.

Frequently asked questions

Change Risk Rollback