From sysadmin-skills
ITIL change request and CAB review workflow. This skill should be used when the user asks to "create a change request", "write an RFC", "plan a change", "CAB review", "change management", "schedule maintenance", "server migration plan", "upgrade plan", "AI model deployment", "GitOps change", or describes any planned modification to IT infrastructure or services. Produces a complete RFC document following ITIL v5 Change Enablement.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sysadmin-skills:change-request <description of the planned change><description of the planned change>This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Structured change management following ITIL 4 Change Enablement. Produces a complete RFC (Request for Change) document that serves as both the change plan and the CAB review submission.
Structured change management following ITIL 4 Change Enablement. Produces a complete RFC (Request for Change) document that serves as both the change plan and the CAB review submission.
File: {OUTPUT_DIR}/change-request-{YYYY-MM-DD}-{slug}.md
exchange-upgrade, ad-entra-migrationCHG-{YYYYMMDD}-{NNN}): {NNN} is a daily sequence number starting at 001. If the organization uses a ticketing system, use that system's ID instead.Default output directory: ./changes/. If a docs/changes/ directory exists in the project, use that instead. Ask the user if neither exists. A user-specified path takes precedence over all defaults.
All change request documents are written in English. Before writing to file, preview the content for the user in their preferred language.
Collect the following from the user (use AskUserQuestion for missing items):
| Field | Required | Example |
|---|---|---|
| What is being changed? | Yes | "Upgrade Exchange Server 2019 to 2022" |
| Why is this change needed? | Yes | "End of support, security compliance" |
| Which systems/services affected? | Yes | "Email service, Active Directory" |
| Expected downtime? | Yes | "4-hour maintenance window" |
| Proposed schedule? | Yes | "Saturday 02:00-06:00" |
| Who will implement? | Yes | "IT Infrastructure team" |
Determine the change type using the itil skill:
| Question | Standard | Normal | Emergency |
|---|---|---|---|
| Is this a routine, pre-approved procedure? | Yes → Standard | No | No |
| Is there a documented SOP for this? | Yes → Standard | Maybe | No |
| Is this time-critical (active incident)? | No | No | Yes → Emergency |
| Otherwise | — | → Normal | — |
Clarification: Compliance deadlines or business mandates with hard dates are Normal changes (with appropriate urgency), not Emergency. Emergency is reserved for active incidents or immediate security threats requiring same-day implementation.
AI / ML System Changes: If the change involves any AI or ML component (model update, prompt change, training data, RAG index, AI autonomy scope), load
itil/references/change-enablement.mdand follow the "AI / ML System Changes" section. Changes involving Cognition or Coordination capabilities require Normal (Significant) classification at minimum.
GitOps / IaC Changes: Changes delivered via pull request and automated pipeline may qualify as Standard if they meet pre-authorization criteria. See
itil/references/change-enablement.md→ "GitOps / IaC Change Pattern".
For Normal changes, further classify risk level:
Rate each dimension 1-3, multiply for Risk Score:
Impact (if change fails):
Likelihood (of failure):
| Risk Score | Level | Authorization |
|---|---|---|
| 7-9 | High | Full CAB + management approval |
| 4-6 | Medium | CAB review recommended |
| 1-3 | Low | Change Manager approval |
MUST include the risk assessment table in the RFC with this exact format.
Sustainability note: If the change involves significant compute (AI model deployment, server provisioning >10 units, cloud region migration), add the optional Sustainability assessment from
itil/references/sustainability.mdto the Risk Assessment section.
| Dimension | Rating | Justification |
|---|---|---|
| Impact (if failure) | {1-3} | {Reason} |
| Likelihood (of failure) | {1-3} | {Reason} |
| **Risk Score** | **{N}** | **{Low/Medium/High}** |
Present the assessment to the user for validation.
Create the change request file. MUST follow this exact structure — do not rearrange or rename sections:
# Request for Change: {TITLE}
| Field | Value |
|---|---|
| Change ID | CHG-{YYYYMMDD}-{NNN} |
| Change Type | Standard / Normal / Emergency |
| Risk Level | {Low / Medium / High} (Score: {N}) |
| Status | Draft |
| Requester | {NAME} |
| Date Submitted | {YYYY-MM-DD} |
| Proposed Window | {DATE TIME} to {DATE TIME} ({TIMEZONE}) |
## Business Justification
{Why this change is needed. What problem it solves. What happens if not implemented.}
## Scope and Impact
### Systems Affected
{List of systems, services, and configuration items.}
### Users Affected
{Who will experience downtime or changes. Estimated number.}
### Dependencies
{Other systems, teams, or changes this depends on.}
## Risk Assessment
| Dimension | Rating | Justification |
|---|---|---|
| Impact (if failure) | {1-3} | {Reason} |
| Likelihood (of failure) | {1-3} | {Reason} |
| **Risk Score** | **{N}** | **{Low/Medium/High}** |
### Risk Mitigation
{Steps to reduce risk — e.g., tested in staging, phased rollout.}
## Implementation Plan
### Pre-Implementation
| Step | Action | Owner | Est. Duration |
|---|---|---|---|
| 1 | {Pre-check or preparation} | {Name} | {Time} |
### Implementation
| Step | Action | Owner | Est. Duration |
|---|---|---|---|
| 1 | {Step description} | {Name} | {Time} |
### Post-Implementation
| Step | Action | Owner | Est. Duration |
|---|---|---|---|
| 1 | {Verification step} | {Name} | {Time} |
## Test / Validation Plan
| Check | Expected Result | Method |
|---|---|---|
| {What to verify} | {Expected outcome} | {How to check} |
## Rollback Plan
**Trigger criteria:** {When to initiate rollback — specific, measurable conditions.}
**Estimated rollback time:** {Duration}
| Step | Action | Owner | Est. Duration |
|---|---|---|---|
| 1 | {Rollback step} | {Name} | {Time} |
## Communication Plan
| When | Audience | Channel | Message |
|---|---|---|---|
| Before change | {Who} | {Email/Teams/Statuspage} | Maintenance notification |
| During (if issues) | {Who} | {Channel} | Status update |
| After completion | {Who} | {Channel} | Completion confirmation |
## Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Change Manager | | | |
| CAB | | | |
| Technical Lead | | | |
## Related Records
{Linked incidents, problems, or previous changes.}
For Normal (Major) and Emergency changes, prepare the CAB review summary:
itil skill (references/change-enablement.md)Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub bouob/claude-plugins --plugin sysadmin-skills