bevel-software/hexis/change-request

change-request

Names like ~~chat or ~~project tracker mean whichever tool of that kind is connected: a tool in one of your Hexis plugins, or one your agent has itself. The knowledge base is this workspace's knowledge base in Hexis, plus any other docs tool that is connected. When a source is not connected, skip it and say what you could not check.

Create a structured change request with impact analysis, risk assessment, and rollback plan.

Usage

Ask your agent for the change-request skill by name, or just describe the job and it will pick the skill up. Give it: <change description>

Change Management Framework

Apply the assess-plan-execute-sustain framework when building the request:

1. Assess

• What is changing?
• Who is affected?
• How significant is the change? (Low / Medium / High)
• What resistance should we expect?

2. 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

3. Execute

• Announce and explain the "why"
• Train and support
• Monitor adoption
• Address resistance

4. 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

1. Be specific about impact — "Everyone" is not an impact assessment. "200 users in the billing team" is.
2. Always have a rollback plan — Even if you're confident, plan for failure.
3. Communicate early — Surprises create resistance. Previews create buy-in.