القائمة
Creates change management plans with stakeholder analysis, communication strategy, and transition timelines for smooth business changes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
A demo skill for tests.
Writes website accessibility policies with WCAG compliance commitments and accommodation procedures. Use when creating an accessibility statement for your website.
Creates a complete client onboarding system for agencies and service providers, including welcome email sequence, intake questionnaire, kickoff meeting checklist, and communication guidelines. Use when a user runs an agency, consultancy, or service business and needs to standardize how new clients are brought on board.
Facilitates annual business planning with vision setting, goal cascading, quarterly milestones, and resource allocation for focused execution.
Compiles annual business reviews with year-over-year metrics, milestone highlights, lessons learned, and strategic goals for the upcoming year. Use when a user needs to reflect on their business year, wants to create a year-in-review document for stakeholders, or is setting annual goals and needs to assess where they stand.
Creates API documentation templates with endpoint descriptions, request/response examples, and authentication guides. Use when documenting REST APIs for developers.
استنادا إلى تصنيف SOC المهني
| name | change-management-plan |
| description | Creates change management plans with stakeholder analysis, communication strategy, and transition timelines for smooth business changes. |
| allowed-tools | Read Write Glob |
| metadata | {"author":"Salah-XD","version":"1.0"} |
Use this skill when you need to:
DO NOT use this skill for personal habit changes, product launches, or project management. This is for managing internal business transitions.
PEOPLE DO NOT RESIST CHANGE — THEY RESIST BEING CHANGED WITHOUT INPUT, CONTEXT, OR PREPARATION. A CHANGE MANAGEMENT PLAN ADDRESSES ALL THREE.
Clarify what is changing and why before planning the rollout.
| Input | What to Ask | Default |
|---|---|---|
| Change description | "What is changing? Be specific." | No default |
| Reason for change | "Why is this change happening now?" | No default |
| Scope | "Who is affected? (team, clients, vendors, all)" | Team members |
| Timeline | "When does this need to be fully implemented?" | 30 days |
| Risk of not changing | "What happens if you do NOT make this change?" | No default |
| Previous change attempts | "Has this been tried before? What happened?" | First attempt |
## Change Impact Assessment
**Change:** [Description]
**Type:** [Process / Tool / Structure / Policy / Pricing]
**Urgency:** [Immediate / Planned / Strategic]
| Impact Area | Current State | Future State | Impact Level |
|-------------|-------------|-------------|-------------|
| Daily workflow | [How it works now] | [How it will work] | High/Medium/Low |
| Tools/systems | [Current tools] | [New tools] | High/Medium/Low |
| Team roles | [Current structure] | [New structure] | High/Medium/Low |
| Client experience | [Current experience] | [New experience] | High/Medium/Low |
GATE: Confirm the change definition before stakeholder analysis.
Identify who is affected and how to bring them along.
## Stakeholder Analysis
| Stakeholder | Impact Level | Current Attitude | Desired Attitude | Key Concern | Action |
|-------------|-------------|-----------------|-----------------|-------------|--------|
| [Name/Group] | High/Med/Low | Supportive/Neutral/Resistant | Supportive | [Concern] | [Approach] |
## Change Communication Plan
| Audience | Message | Channel | Timing | Owner |
|----------|---------|---------|--------|-------|
| Core team | Full context + rationale + timeline | Meeting | Week 1 | [Name] |
| Clients | What changes for them + benefits | Email | Week 2 | [Name] |
| Vendors | Operational adjustments | Email | Week 2 | [Name] |
For each audience, structure the message as:
GATE: Present stakeholder plan for review.
Build the phased rollout plan.
## Change Rollout Timeline
### Phase 1: Prepare (Week 1-2)
- [ ] Announce the change to all stakeholders
- [ ] Distribute FAQ document
- [ ] Set up new tools/processes in parallel (not replacing old ones yet)
- [ ] Identify change champions who can support others
- [ ] Schedule training sessions
### Phase 2: Pilot (Week 2-3)
- [ ] Small group tests the new process/tool
- [ ] Collect feedback and fix issues
- [ ] Document common questions and solutions
- [ ] Update training materials based on pilot feedback
### Phase 3: Rollout (Week 3-4)
- [ ] Full team transitions to the new way
- [ ] Old process/tool remains available as fallback (sunset date set)
- [ ] Daily check-ins during first week of rollout
- [ ] Dedicated support channel for questions
### Phase 4: Stabilize (Week 4+)
- [ ] Sunset old process/tool
- [ ] Address remaining issues
- [ ] Document the new process as the standard
- [ ] Celebrate wins and acknowledge the effort
## Change FAQ: [Change Name]
**Q: Why are we making this change?**
A: [Answer]
**Q: When does this take effect?**
A: [Answer]
**Q: What do I need to do differently?**
A: [Answer]
**Q: What if I have problems with the new [tool/process]?**
A: [Answer]
**Q: Can we go back to the old way?**
A: [Answer]
Ensure the change sticks and deliver the intended benefits.
Define 2-3 metrics that prove the change is working:
## Change Success Metrics
| Metric | Before Change | Target (30 days) | Target (90 days) |
|--------|-------------|-----------------|-----------------|
| [Metric] | [Baseline] | [Target] | [Target] |
At 30 and 90 days: