$ ~/registry/skill/anthropics-operations-skills-change-request

SKILL

change-request

Name: change-request
Author: anthropics

Create approval-ready change requests with impact analysis and rollback planning.

Stars

★ 29,577

Source

GitHub

Updated

2026-10-14

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 29.6k

Running security audit…

Credentials
Network egress
Code execution
Data access
Supply chain

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "change-request" skill from askskill:
1. Download https://raw.githubusercontent.com/anthropics/knowledge-work-plugins/main/operations/skills/change-request/SKILL.md
2. Save it as ~/.claude/skills/change-request/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Submit a pre-deployment change request

Prompt

Draft a production change request for upgrading the payment service from v2.3 to v2.4 this Saturday from 23:00 to 24:00. The impact scope includes the checkout API and order confirmation page. Include objectives, implementation steps, impact analysis, risks, rollback plan, validation plan, and approval recommendations.

Expected

A complete release change request ready for approval or CAB review.

Assess risks of a process change

Prompt

We plan to change customer support ticket escalation from manual routing to rule-based automatic routing. Generate a change request focusing on affected teams, potential risks, failure scenarios, communication plan, and how to revert to the original process if results are poor.

Expected

A process change document highlighting business impact, risk controls, and rollback steps.

Prepare materials for CAB review

Prompt

Turn the following change details into a formal record suitable for CAB review: adjust database parameters to improve query performance, with no expected downtime but possible short-term impact on report generation; notify the data team and customer support in advance; if monitoring metrics become abnormal, restore the original parameters within 30 minutes. Also add an approval summary and validation criteria.

Expected

A formal CAB-ready change record with summary, impact, communications, and rollback details.

// docs

/change-request

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Create a structured change request with impact analysis, risk assessment, and rollback plan.

Usage

/change-request $ARGUMENTS

Change Management Framework

Apply the assess-plan-execute-sustain framework when building the request:

1. Assess

What is changing?
Who is affected?
How significant is the change? (Low / Medium / High)
What resistance should we expect?

2. Plan

Communication plan (who, what, when, how)
Training plan (what skills are needed, how to deliver)
Support plan (help desk, champions, FAQs)
Timeline with milestones

3. Execute

Announce and explain the "why"
Train and support
Monitor adoption
Address resistance

4. Sustain

Measure adoption and effectiveness
Reinforce new behaviors
Address lingering issues
Document lessons learned

Communication Principles

Explain the why before the what
Communicate early and often
Use multiple channels
Acknowledge what's being lost, not just what's being gained
Provide a clear path for questions and concerns

Output

## Change Request: [Title]
**Requester:** [Name] | **Date:** [Date] | **Priority:** [Critical/High/Medium/Low]
**Status:** Draft | Pending Approval | Approved | In Progress | Complete

### Description
[What is changing and why]

### Business Justification
[Why this change is needed — cost savings, compliance, efficiency, risk reduction]

### Impact Analysis
| Area | Impact | Details |
|------|--------|---------|
| Users | [High/Med/Low/None] | [Who is affected and how] |
| Systems | [High/Med/Low/None] | [What systems are affected] |
| Processes | [High/Med/Low/None] | [What workflows change] |
| Cost | [High/Med/Low/None] | [Budget impact] |

### Risk Assessment
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| [Risk] | [H/M/L] | [H/M/L] | [How to mitigate] |

### Implementation Plan
| Step | Owner | Timeline | Dependencies |
|------|-------|----------|--------------|
| [Step] | [Person] | [Date] | [What it depends on] |

### Communication Plan
| Audience | Message | Channel | Timing |
|----------|---------|---------|--------|
| [Who] | [What to tell them] | [How] | [When] |

### Rollback Plan
[Step-by-step plan to reverse the change if needed]
- Trigger: [When to roll back]
- Steps: [How to roll back]
- Verification: [How to confirm rollback worked]

### Approvals Required
| Approver | Role | Status |
|----------|------|--------|
| [Name] | [Role] | Pending |

If Connectors Available

If ~~ITSM is connected:

Create the change request ticket automatically
Pull change advisory board schedule and approval workflows

If ~~project tracker is connected:

Link to related implementation tasks and dependencies
Track change progress against milestones

If ~~chat is connected:

Draft stakeholder notifications for the communication plan
Post change updates to the relevant team channels

Tips

Be specific about impact — "Everyone" is not an impact assessment. "200 users in the billing team" is.
Always have a rollback plan — Even if you're confident, plan for failure.
Communicate early — Surprises create resistance. Previews create buy-in.