/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:
- Assess
-
What is changing?
-
Who is affected?
-
How significant is the change? (Low / Medium / High)
-
What resistance should we expect?
- 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
- Execute
-
Announce and explain the "why"
-
Train and support
-
Monitor adoption
-
Address resistance
- 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.