change-management
starsforks
How to install change-management?
bagelhole/devops-security-agent-skills/change-management
$npx -y skills add BagelHole/DevOps-Security-Agent-Skills --skill change-managementImplement change management processes. Configure CAB reviews, change windows, and rollback procedures. Use when managing production changes.
SKILL.md
| 1 | # Change Management |
| 2 | |
| 3 | Implement structured change management processes covering change classification, CAB workflows, emergency change procedures, and automation for compliance with SOC 2, ITIL, and regulatory frameworks. |
| 4 | |
| 5 | ## When to Use |
| 6 | |
| 7 | - Establishing change management processes for production environments |
| 8 | - Implementing change advisory board (CAB) workflows |
| 9 | - Defining change classification and approval requirements |
| 10 | - Configuring automated change tracking in CI/CD pipelines |
| 11 | - Handling emergency changes with proper controls and documentation |
| 12 | |
| 13 | ## Change Classification |
| 14 | |
| 15 | ```yaml |
| 16 | change_types: |
| 17 | standard: |
| 18 | risk: Low |
| 19 | approval: Pre-approved (no per-change approval needed) |
| 20 | lead_time: None (within maintenance window) |
| 21 | examples: |
| 22 | - Routine patching within tested patch sets |
| 23 | - Certificate rotation with established procedure |
| 24 | - Scaling operations (adding/removing instances within limits) |
| 25 | - Pre-approved configuration changes |
| 26 | - Log rotation and archival |
| 27 | requirements: |
| 28 | - Change must match an approved Standard Change template |
| 29 | - Automated testing must pass |
| 30 | - Documented rollback procedure exists |
| 31 | - Within defined maintenance window |
| 32 | |
| 33 | normal_low: |
| 34 | risk: Low |
| 35 | approval: Peer review (1 approver) |
| 36 | lead_time: 2 business days |
| 37 | examples: |
| 38 | - Non-critical configuration changes |
| 39 | - Feature flag toggles |
| 40 | - Documentation updates to production systems |
| 41 | - Adding monitoring dashboards or alerts |
| 42 | |
| 43 | normal_medium: |
| 44 | risk: Medium |
| 45 | approval: Team lead + peer review (2 approvers) |
| 46 | lead_time: 5 business days |
| 47 | examples: |
| 48 | - Application deployments with new features |
| 49 | - Database schema changes (non-breaking) |
| 50 | - Network rule modifications |
| 51 | - Integration endpoint changes |
| 52 | - Dependency version upgrades |
| 53 | |
| 54 | normal_high: |
| 55 | risk: High |
| 56 | approval: CAB review required |
| 57 | lead_time: 10 business days |
| 58 | examples: |
| 59 | - Infrastructure migrations |
| 60 | - Breaking database schema changes |
| 61 | - Major version upgrades (OS, runtime, database engine) |
| 62 | - Changes to authentication or authorization systems |
| 63 | - Multi-service coordinated deployments |
| 64 | - Changes affecting data processing or compliance controls |
| 65 | |
| 66 | emergency: |
| 67 | risk: Variable |
| 68 | approval: Emergency CAB (minimum 2 approvers from on-call) |
| 69 | lead_time: None (immediate implementation) |
| 70 | examples: |
| 71 | - Security vulnerability remediation (active exploitation) |
| 72 | - Production outage resolution |
| 73 | - Data integrity emergency fixes |
| 74 | - Regulatory compliance deadline fixes |
| 75 | requirements: |
| 76 | - Retroactive full documentation within 48 hours |
| 77 | - Post-implementation review required |
| 78 | - CAB retroactive review at next meeting |
| 79 | ``` |
| 80 | |
| 81 | ## Change Request Template |
| 82 | |
| 83 | ```yaml |
| 84 | change_request: |
| 85 | metadata: |
| 86 | id: "CR-YYYY-NNNN" |
| 87 | title: "" |
| 88 | requestor: "" |
| 89 | date_submitted: "" |
| 90 | target_date: "" |
| 91 | change_type: "" # standard | normal_low | normal_medium | normal_high | emergency |
| 92 | |
| 93 | description: |
| 94 | summary: "Brief description of the change" |
| 95 | detailed_description: "Full technical details of what will change" |
| 96 | business_justification: "Why this change is needed" |
| 97 | affected_systems: [] |
| 98 | affected_services: [] |
| 99 | affected_users: "Description of user impact" |
| 100 | |
| 101 | risk_assessment: |
| 102 | risk_level: "" # low | medium | high |
| 103 | impact_if_failed: "What happens if the change fails" |
| 104 | likelihood_of_failure: "" # low | medium | high |
| 105 | risk_mitigation: "Steps to reduce risk" |
| 106 | dependencies: "Other systems or changes this depends on" |
| 107 | |
| 108 | implementation: |
| 109 | change_window: |
| 110 | start: "" |
| 111 | end: "" |
| 112 | maintenance_window: true |
| 113 | implementation_steps: |
| 114 | - step: "Step 1 description" |
| 115 | responsible: "Person/team" |
| 116 | estimated_duration: "X minutes" |
| 117 | - step: "Step 2 description" |
| 118 | responsible: "Person/team" |
| 119 | estimated_duration: "X minutes" |
| 120 | |
| 121 | testing: |
| 122 | pre_change_testing: |
| 123 | - "Unit tests pass" |
| 124 | - "Integration tests pass" |
| 125 | - "Staging deployment verified" |
| 126 | post_change_verification: |
| 127 | - "Health check endpoints responding" |
| 128 | - "Key transactions processing successfully" |
| 129 | - "No error rate increase in monitoring" |
| 130 | - "Performance metrics within baseline" |
| 131 | |
| 132 | rollback: |
| 133 | rollback_plan: "Detailed steps to revert the change" |
| 134 | rollback_trigger: "Conditions that trigger rollback" |
| 135 | rollback_estimated_time: "X minutes" |
| 136 | rollback_steps: |
| 137 | - "Step 1: Revert deployment to previous version" |
| 138 | - "Step 2: Verify rollback successful" |
| 139 | - "Step 3: Notify stakeholders" |
| 140 | data_rollback: "Describe any data migration rollback needed" |
| 141 | |
| 142 | communication: |
| 143 | stakeholders_notified: [] |
| 144 | notification_sent_date: "" |
| 145 | status_page |
People who liked this also viewed
6 picksType
- microsoft-foundryDeploy, evaluate, fine-tune, and manage Foundry agents end-to-end with azd: hosted agent scaffold/run/deploy, prompt agent create, batch eval, continuous eval, prompt optimizer, Agent Optimizer scaffoSkillsJul 2026
- azure-deployExecute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application SkillsJul 2026
- azure-preparePrepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wSkillsJul 2026
- azure-validate--- name: azure-validate description: "Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity pSkillsJul 2026
- azure-aigatewayConfigure Azure API Management as an AI Gateway for AI models, MCP tools, and agents. WHEN: semantic caching, token limit, content safety, load balancing, AI model governance, MCP rate limiting, jailbSkillsJul 2026
- azure-hosted-copilot-sdkOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026
