Change Request
Package a production or process change with impact, risk, rollback, and comms before you ask for approval or ship.
Overview
change-request is an agent skill most often used in Ship (also Operate) that drafts a structured change management request with impact analysis, risk assessment, rollback steps, and rollout communications.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill change-requestWhat is this skill?
- Structured change request built on assess-plan-execute-sustain
- Impact analysis with Low/Medium/High significance and resistance expectations
- Explicit rollback plan and risk assessment before approval
- Communication, training, and support plans with timeline milestones
- Sustain phase for adoption measurement and lessons learned
- 4-part framework: assess, plan, execute, sustain
Adoption & trust: 1.4k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to change production or a critical process but only have informal notes—no shared risk story, rollback path, or comms plan for approval.
Who is it for?
Indie SaaS or internal-tool maintainers shipping meaningful infra, workflow, or policy changes who need a lightweight CAB-style packet.
Skip if: One-line hotfixes with no approval gate, or teams that already use a mandated enterprise ITSM template you cannot replace.
When should I use this skill?
Proposing a system or process change that needs approval, preparing a change record for CAB review, documenting risk and rollback before deployment, or planning stakeholder communications for a rollout.
What do I get? / Deliverables
You get a complete change request aligned to assess-plan-execute-sustain, ready for CAB or stakeholder review and safer execution.
- Structured change request with impact and risk
- Rollback plan and communication timeline
- Adoption and sustain measurement notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Change requests sit on the canonical Ship shelf because the skill explicitly targets pre-deployment documentation, CAB-style review, and rollout planning—not day-two monitoring. Launch subphase matches stakeholder comms, rollout milestones, and go-live readiness called out in the assess-plan-execute-sustain framework.
Where it fits
Draft a high-significance API migration change packet with training and support before cutover.
Propose a database maintenance window with rollback and who-is-affected analysis.
Document a policy or secrets-handling change with resistance expectations and sustain metrics.
Plan a customer-facing workflow change with FAQ and champion support in the change request.
How it compares
Use instead of pasting a deployment checklist into chat without impact, rollback, and adoption sections.
Common Questions / FAQ
Who is change-request for?
Solo builders and small teams who own releases and need formal change records—impact, risk, rollback, and communications—without a full ITSM department.
When should I use change-request?
In Ship before go-live when documenting risk and rollback; in Operate when planning infra or process changes; and anytime a rollout needs explicit why-first messaging and adoption follow-through.
Is change-request safe to install?
It is procedural documentation guidance; review the Security Audits panel on this Prism page before trusting the plugin source like any other skill.
SKILL.md
READMESKILL.md - Change Request
# /change-request > If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../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 ```markdown ## 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 1. **Be specific about impact** — "Everyone" is not an impact assessment. "200 users in the billing team" is. 2. **Always have a rollback plan** — Even if you're confident, plan for failure. 3. **Communicate early** — Surprises create resistance. Previews create buy-in.