change-request

/change-request

No connector required — this skill produces a structured output document.

Generate a complete change request document for IT configuration changes at Chelsea Piers.

Usage

/change-request $ARGUMENTS

Steps

1. Gather the required information (prompt if missing):
   • What is changing?
   • Which system(s) are affected?
   • Who initiated the request?
   • Planned change window (date/time/duration)?
   • Urgency: Standard (planned) or Emergency?
2. Classify the change risk (see matrix below)
3. If HIGH risk: invoke Cerberus council for risk deliberation before finalizing
4. Generate the complete CR document
5. Identify the correct approvers based on system and risk level

Change Risk Classification

Risk	Criteria	Cerberus council?
LOW	Single user, read-only, or reversible in <5 min	No
MEDIUM	<10 users affected, reversible, tested procedure	No
HIGH	Production system, >10 users, firewall/CA policy, or irreversible	Yes — required
EMERGENCY	P1 incident in progress, no change window available	Yes — abbreviated council

See Cerberus wiki general/it-ops-risk-patterns for the full risk classification table.

Output

## Change Request — [CR-YYYY-MM-DD-NNN]

**Date submitted:** [date]
**Submitted by:** [name / role]
**Status:** Pending Approval

---

### 1. Change Description
[Clear, specific description of what will change. Include: system name, component,
current state, and proposed new state.]

### 2. Business Justification
[Why this change is needed. Link to incident ticket, security finding, or business requirement.]

### 3. Systems Affected
- **Primary:** [system name]
- **Secondary / dependent:** [list any downstream dependencies]
- **Users affected:** [estimated count and scope]

### 4. Risk Assessment

**Risk level:** LOW / MEDIUM / HIGH

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|-----------|
| [Risk 1] | Low/Med/High | Low/Med/High | [Mitigation] |
| [Risk 2] | Low/Med/High | Low/Med/High | [Mitigation] |

**Cerberus council verdict:** [APPROVE / CONDITIONAL / BLOCK — include conditions]

### 5. Change Window
- **Planned date:** [YYYY-MM-DD]
- **Start time:** [HH:MM ET]
- **Duration:** [estimated]
- **Blackout check:** [confirm no conflicting events or maintenance]

### 6. Testing Steps
1. [Pre-change validation step]
2. [Change execution step]
3. [Post-change validation step]

**Success criteria:** [How will you confirm the change worked?]

### 7. Rollback Plan
**Rollback trigger:** [What would cause you to roll back?]
**Rollback steps:**
1. [Step 1 — must be specific and executable]
2. [Step 2]
**Rollback time estimate:** [minutes]

### 8. Approval

| Role | Name | Required for |
|------|------|-------------|
| SysAdmin | [name] | All changes |
| IT Manager | [name] | MEDIUM and above |
| Security Analyst | [name] | Firewall, CA, identity changes |
| Cerberus council | [verdict] | HIGH risk changes |

**Approved by:** _____________________ Date: ___________

### 9. Post-Change Review
- [ ] Change completed successfully
- [ ] Success criteria verified
- [ ] Change log entry added to Confluence
- [ ] Jira ticket updated and closed

If Connectors Available

If ~~ticketing (Jira) is connected:

• Check for the triggering incident or request ticket to link this CR to
• After approval: create a Jira change ticket in the IT-Changes project
• Tag with system label and risk level

If ~~knowledge base (Confluence) is connected:

• Search for prior CRs affecting the same system for reference
• After completion: publish the approved CR to the IT Change Log space

CP-Specific Notes

• Change advisory board: CAB meets every Tuesday at 10am ET. Standard changes submitted by Monday noon. Emergency changes can be approved ad hoc with IT Manager + SysAdmin sign-off.
• Blackout periods: no changes during major CP events (sports championships, large corporate events). Check the CP event calendar before scheduling.
• Rollback requirement: every HIGH-risk change must have a tested rollback procedure. If rollback is not possible, the change must be approved by IT Manager AND documented as irreversible.
• Emergency changes: P1 incident changes may proceed with verbal approval from IT Manager, with written CR submitted within 24 hours post-change.
• Cerberus council: required for all HIGH-risk changes. The council verdict (APPROVE / CONDITIONAL / BLOCK) must be included in the CR document verbatim. BLOCK means stop — do not proceed.