---
name: change-request-writer
description: Turn a plain-English change summary into a CAB-ready ITIL change record with risk rating, rollback plan, and communications draft.
version: 1.0.0
author: VantagePoint Networks
audience: IT Managers, Infrastructure Leads, Service Managers, Change Managers
output_format: Formatted Markdown change record, ready to paste into ServiceNow, Jira Service Management, or email to CAB.
license: MIT
---

# Change Request Writer

A Claude Code skill for IT managers who need to produce a professional, CAB-ready change record without wrestling with ITIL templates.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/change-request-writer`. Describe your change in plain English. The skill will ask a few clarifying questions and then produce a finished change record.

## When to use this

- You need to submit a change to CAB this week and you don't want to start from a blank template.
- A vendor or engineer has described the work and you need to translate it into governance language.
- You want a consistent house style across all RFCs regardless of which team raised it.
- You need to produce the same change in two formats (ticket text + stakeholder email) without rewriting twice.
- You're preparing an emergency change at 10pm and need a defensible record that will pass retrospective review.

## What you'll get

A single Markdown document containing:

- A full ITIL change record (type, category, risk, impact, priority, lead time, planned window, roles, implementation plan, verification steps, rollback plan, communications plan, post-implementation review)
- A weighted **5x5 risk score** derived from likelihood and impact
- A **pre-flight checklist** the implementer signs off before starting
- A **stakeholder email** in plain English, ready to send to the business
- A **CAB summary slide** (3-4 bullets) for the meeting agenda

## Clarifying questions I will ask you

Before producing the record, I will ask:

1. **What is changing, in one sentence?** ("We are replacing the primary core switch in the London data centre.")
2. **Why now?** What business need or technical driver is forcing this? (refresh, incident, compliance, project milestone)
3. **What is the blast radius if this goes wrong?** (one team, one site, global, external customers)
4. **Who has to approve it?** (Change Manager only, CAB, Emergency CAB, Director sign-off)
5. **When do you want to run it?** (date, time, duration, timezone, any business freeze to respect)
6. **What is your rollback?** (restore config, failback to standby, replace hardware, revert VM snapshot)
7. **Who is implementing, and who is on the bridge if it goes wrong?**
8. **Has this been tested in lab or a non-prod site? If not, why not?**

If you skip any of these, I will flag the gap in the record so the CAB sees it rather than filling it with a guess.

## Output template

```markdown
# Change Request: [CHG-YYYY-NNNN] <short title>

## 1. Summary
<One paragraph in business language. No jargon.>

## 2. Classification
| Field | Value |
|---|---|
| Change Type | Standard / Normal / Emergency |
| Category | Infrastructure / Network / Security / Application / Facilities |
| Risk Score | 1-25 (from 5x5 matrix below) |
| Impact | Low / Medium / High / Critical |
| Priority | P1 / P2 / P3 / P4 |
| Lead Time | <hours/days notice given to CAB> |

## 3. Business Justification
- **Driver:** <refresh / incident / project / compliance / cost>
- **Benefit if delivered:** <what improves>
- **Cost of not doing it:** <what breaks, when>
- **Reference:** <linked project / incident / audit finding>

## 4. Risk Assessment (5x5 Matrix)
| Axis | Value | Reasoning |
|---|---|---|
| Likelihood of failure | 1-5 | <why> |
| Impact if it fails | 1-5 | <who is affected, for how long> |
| **Risk Score (L x I)** | **N** | Risk band: Low / Medium / High / Critical |

### Specific risks identified
1. <risk> -> mitigated by <control>
2. <risk> -> mitigated by <control>
3. <risk> -> mitigated by <control>

## 5. Change Window
- **Planned start:** <YYYY-MM-DD HH:MM Timezone>
- **Planned end:** <YYYY-MM-DD HH:MM Timezone>
- **Expected downtime:** <minutes or "no user-facing impact">
- **Business freeze respected?** Yes / No / Exempted because <reason>

## 6. Implementation Plan
Step-by-step, numbered, with expected duration and who runs it.

1. T-30: <pre-check> - <owner>
2. T-0: <action> - <owner>
3. T+5: <verification> - <owner>
4. T+15: <handover> - <owner>

## 7. Verification / Success Criteria
Definition of done - measurable, testable.
- [ ] <check 1>
- [ ] <check 2>
- [ ] <check 3>

## 8. Rollback Plan
Triggered if: <specific failure condition>

1. <rollback step 1> - <owner> - <expected duration>
2. <rollback step 2> - <owner> - <expected duration>
3. <rollback step 3> - <owner> - <expected duration>

**Rollback point of no return:** <the moment after which rollback is no longer possible>

## 9. Roles
| Role | Name | Contact |
|---|---|---|
| Change Owner | | |
| Implementer(s) | | |
| Technical Approver | | |
| Business Approver | | |
| Communications Lead | | |
| On-call Escalation | | |

## 10. Communications Plan
| Audience | Message | Channel | When |
|---|---|---|---|
| Affected users | <draft below> | Email / Teams / Slack | T-48h |
| Service Desk | <draft below> | Ticket + briefing | T-24h |
| Executive sponsor | <draft below> | Email | T+0 (completion) |

### Stakeholder email draft
> Subject: Planned work on <system> - <date>
>
> Hi team,
>
> We will be <plain-English action> on <date> between <start> and <end>. You may experience <impact or "no disruption">. If you notice anything unexpected, please raise a ticket / contact <name>.
>
> Why we are doing this: <one sentence>
>
> Thanks,
> <sender>

## 11. Pre-flight Checklist (Implementer signs before starting)
- [ ] Change approved by CAB / Change Manager
- [ ] All stakeholders notified
- [ ] Rollback tested / rollback assets staged
- [ ] Backup / snapshot confirmed current
- [ ] Monitoring / alerting silenced for the window (if appropriate)
- [ ] Implementer has out-of-band access
- [ ] Bridge call open / on standby

## 12. Post-Implementation Review (filled in after the change)
- **Outcome:** Successful / Partial / Rolled back
- **Actual window:** <start> - <end>
- **Issues encountered:** <none / list>
- **Deviations from plan:** <none / list>
- **Lessons learned:** <bullet list>

## 13. CAB Summary (for the agenda slide)
- **What:** <1 line>
- **Why:** <1 line>
- **When:** <date + duration>
- **Risk:** <score + one-word rationale>
- **Rollback confidence:** High / Medium / Low
```

## Example invocation

**User:** "I need to write up a change for swapping the failed PSU on our London core switch next Saturday at 2am."

**What the skill will do:**
1. Ask the 8 clarifying questions (type of change is almost certainly Standard or Emergency; likely low-risk if hot-swap capable; impact depends on single-PSU vs redundant).
2. Produce the complete change record above, with `CHG-YYYY-NNNN` placeholder, plain-English stakeholder email, pre-flight checklist, and a 4-bullet CAB summary.
3. Flag that because it is hardware work inside a running device, rollback is "re-seat or swap back in spare" and note the point of no return.

## Notes for the requester

- **Have the vendor's procedure to hand.** If you paste in the Cisco / Fortinet / Juniper hot-swap procedure, I will inline the specific commands in the Implementation Plan step.
- **Be honest about lab testing.** If it hasn't been tested, say so - the record will explicitly note "not lab-tested, mitigated by <X>". CAB prefers truthful records to polished fiction.
- **Don't hide the rollback point of no return.** The single thing that separates Standard from Normal changes in most organisations is whether you can still back out halfway through. If you're not sure, ask the implementer and note their answer verbatim.
- **"Good" looks like:** a CAB member can read sections 1, 2, 4, 5, and 8 and approve or reject the change in under 90 seconds.