Windsurf + Aider targets, MCP server, and demo placement (#33)
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,147 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Create a structured change management plan for any organisational change. Use when asked to write a change management plan, manage a change initiative, plan a system rollout, or lead an organisational transformation. Produces a plan covering stakeholder analysis, impact assessment, communication strategy, and resistance management."
|
||||
---
|
||||
|
||||
# Change Management Plan Skill
|
||||
|
||||
Produces a structured change management plan — because most change initiatives fail not because the change is wrong, but because people aren't brought along with it.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The change** (what is changing, and what is the current state?)
|
||||
- **Scale** (how many people affected, in how many teams/locations?)
|
||||
- **Timeline** (when does the change go live? How long is the transition?)
|
||||
- **Sponsor** (who is accountable at senior level?)
|
||||
- **Key concern** (what is the biggest risk to adoption?)
|
||||
- **What happens if change fails** (consequences of low adoption)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Change Management Plan: [Change Name]
|
||||
|
||||
**Change sponsor:** [Executive owner]
|
||||
**Change manager:** [Who is running this]
|
||||
**Go-live date:** [Date]
|
||||
**Affected population:** [N people, N teams/locations]
|
||||
|
||||
---
|
||||
|
||||
## 1. Change Summary
|
||||
|
||||
**From (current state):** [Specific description of today's situation]
|
||||
**To (future state):** [Specific description of what changes]
|
||||
**Why this change is happening:** [Honest explanation — people adopt change faster when they understand the real reason]
|
||||
**What stays the same:** [Explicitly naming what is NOT changing reduces anxiety]
|
||||
|
||||
---
|
||||
|
||||
## 2. Stakeholder Analysis
|
||||
|
||||
| Stakeholder group | Size | Impact level | Current sentiment | What they need |
|
||||
|---|---|---|---|---|
|
||||
| [Group] | [N] | High/Med/Low | Supportive / Neutral / Resistant | [Specific concern or need] |
|
||||
|
||||
**Key influencers to engage early:**
|
||||
[Name the informal leaders, respected voices, and early adopters who can help. And the resistors who need direct attention.]
|
||||
|
||||
---
|
||||
|
||||
## 3. Impact Assessment
|
||||
|
||||
| Area | Impact | Severity | Action needed |
|
||||
|---|---|---|---|
|
||||
| Daily workflow | [What changes day-to-day] | High/Med/Low | [Training / support / redesign] |
|
||||
| Systems or tools | [What tools are affected] | | |
|
||||
| Roles and responsibilities | [Any role changes] | | |
|
||||
| Processes | [Process changes] | | |
|
||||
| Metrics and targets | [Any KPI changes] | | |
|
||||
|
||||
---
|
||||
|
||||
## 4. Communication Plan
|
||||
|
||||
**Core message:** [The 1-sentence summary everyone should understand and remember]
|
||||
|
||||
| Audience | Message focus | Channel | Timing | Owner |
|
||||
|---|---|---|---|---|
|
||||
| All staff | [Why this is happening + what to expect] | All-hands / Email | [T-6 weeks] | Sponsor |
|
||||
| Managers | [How to support their teams] | Manager briefing | [T-5 weeks] | Change manager |
|
||||
| Directly affected teams | [What changes for them specifically] | Team meeting | [T-4 weeks] | Line manager |
|
||||
| [Other group] | [Tailored message] | | | |
|
||||
|
||||
**Communication principles:**
|
||||
- Over-communicate — people need to hear a message 7 times to internalise it
|
||||
- Use managers to cascade, not just top-down announcements
|
||||
- Create a feedback channel — questions left unanswered become rumours
|
||||
|
||||
---
|
||||
|
||||
## 5. Training and Support Plan
|
||||
|
||||
| Audience | Training type | Timing | Duration | Delivery | Owner |
|
||||
|---|---|---|---|---|---|
|
||||
| [Group] | [e.g. Hands-on system training] | [T-2 weeks] | [2 hours] | [In-person / online] | [Owner] |
|
||||
|
||||
**Go-live support:**
|
||||
- [What support is available on day 1 — helpdesk, floor walkers, champions]
|
||||
- [Escalation path for issues in first 30 days]
|
||||
|
||||
---
|
||||
|
||||
## 6. Resistance Management
|
||||
|
||||
**Anticipated resistance sources:**
|
||||
|
||||
| Concern | Who holds it | Root cause | Response |
|
||||
|---|---|---|---|
|
||||
| [e.g. "This will increase my workload"] | [Middle managers] | [Loss of autonomy] | [Specific action to address] |
|
||||
|
||||
**Resistance management principles:**
|
||||
- Acknowledge concerns genuinely — dismissing resistance amplifies it
|
||||
- Involve resistors in design where possible — converts them into advocates
|
||||
- Distinguish between genuine concerns (worth addressing) and preference for the status quo (to be managed, not solved)
|
||||
|
||||
---
|
||||
|
||||
## 7. Adoption Metrics
|
||||
|
||||
| Metric | Baseline | Target | Measurement point | Owner |
|
||||
|---|---|---|---|---|
|
||||
| [System usage rate] | [0%] | [80%] | [30 days post go-live] | [Owner] |
|
||||
| [Process compliance] | [X%] | [Y%] | [60 days] | [Owner] |
|
||||
| [Staff confidence score] | [Survey score] | [Target] | [90 days] | [Owner] |
|
||||
|
||||
**Adoption milestones:**
|
||||
- D+7: [First check — early issues identified]
|
||||
- D+30: [First adoption review]
|
||||
- D+90: [Sustained adoption confirmed or remediation plan activated]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] "What stays the same" is explicitly addressed
|
||||
- [ ] Stakeholder analysis includes resistors, not just supporters
|
||||
- [ ] Communication plan uses managers to cascade (not just top-down)
|
||||
- [ ] Training is timed before go-live (not after)
|
||||
- [ ] Adoption metrics have a measurement date and owner
|
||||
- [ ] Resistance management has specific responses (not just "communicate more")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not treat communication as a one-time announcement — people need to hear a message multiple times before they internalise it; plan for repeated touchpoints
|
||||
- [ ] Do not assign change management to a single owner without involving line managers — managers are the most effective cascade channel and must be briefed before their teams
|
||||
- [ ] Do not schedule training after go-live — people who learn a new system on the day they need to use it will revert to the old process
|
||||
- [ ] Do not ignore resistors in the stakeholder analysis — resistors who are not explicitly engaged will undermine adoption, especially informal leaders
|
||||
- [ ] Do not measure adoption only at go-live — the real test is sustained adoption at 90 days, when novelty has worn off
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a change management plan for [initiative]"
|
||||
- "Help me plan the rollout of [system change] for [team/org]"
|
||||
- "Create a communication and training plan for [change]"
|
||||
- "How do I manage resistance to [change]?"
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Design an employee engagement survey and analyse results. Use when asked to create an employee survey, engagement questionnaire, pulse survey, or eNPS survey. Also use when asked to analyse survey results. Produces a complete survey with questions, rating scales, and an analysis framework."
|
||||
---
|
||||
|
||||
# Employee Engagement Survey Skill
|
||||
|
||||
Designs complete employee engagement surveys and provides a framework for analysing and acting on results.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Mode** — designing a new survey or analysing existing results
|
||||
- **Survey type** (annual / quarterly pulse / post-onboarding / exit / specific topic)
|
||||
- **Company name** (for personalisation of question text)
|
||||
- **Company size and stage** (startup / scaleup / enterprise — affects question relevance)
|
||||
- **Key areas of concern** (optional — e.g. "we have had high attrition on the engineering team")
|
||||
- **Anonymity approach** — fully anonymous, team-level reporting only, or individual responses visible to HR
|
||||
- **Length target** (short: 5–10 questions / standard: 15–25 / comprehensive: 30+)
|
||||
- **For analysis mode:** survey results data (paste as table, CSV, or summary statistics)
|
||||
|
||||
## Mode Detection
|
||||
- User provides survey results -> Analysis mode
|
||||
- User wants to create a survey -> Design mode
|
||||
|
||||
---
|
||||
|
||||
## Design Mode
|
||||
|
||||
### Required Inputs
|
||||
- Survey type (annual / quarterly pulse / post-onboarding / exit / specific topic)
|
||||
- Company size and stage
|
||||
- Key areas of concern (optional)
|
||||
- Anonymity approach
|
||||
- Length target (short: 5-10 / standard: 15-25 / comprehensive: 30+)
|
||||
|
||||
### Opening Statement (always include)
|
||||
"This survey is anonymous. Your responses help us understand what is working and what to improve. Results will be shared with [who] and we will communicate actions taken by [date]."
|
||||
|
||||
### Core Questions
|
||||
|
||||
**Overall Engagement**
|
||||
1. On a scale of 0-10, how likely are you to recommend [Company] as a great place to work? (eNPS)
|
||||
2. I feel proud to work at [Company]. [1-5]
|
||||
3. I intend to still be working here in 12 months. [1-5]
|
||||
|
||||
**Role and Clarity**
|
||||
4. I understand how my work contributes to company goals. [1-5]
|
||||
5. I have the tools and resources I need to do my job. [1-5]
|
||||
6. My workload is manageable. [1-5]
|
||||
|
||||
**Manager and Team**
|
||||
7. My manager gives useful feedback. [1-5]
|
||||
8. My manager cares about my development. [1-5]
|
||||
9. I feel part of a team that works well together. [1-5]
|
||||
|
||||
**Culture and Belonging**
|
||||
10. I feel I can be myself at work. [1-5]
|
||||
11. People treat each other with respect. [1-5]
|
||||
12. [Company] lives by its stated values. [1-5]
|
||||
|
||||
**Growth and Recognition**
|
||||
13. I have opportunities to grow and develop. [1-5]
|
||||
14. My contributions are recognised. [1-5]
|
||||
15. I have had a meaningful career conversation in the last 6 months. [Yes/No]
|
||||
|
||||
**Open questions (always include)**
|
||||
- What is one thing [Company] should start doing?
|
||||
- What is one thing [Company] should stop doing?
|
||||
- Anything else to share?
|
||||
|
||||
---
|
||||
|
||||
## Analysis Mode
|
||||
|
||||
### Analysis Output
|
||||
|
||||
**1. Headline Scores**
|
||||
| Metric | Score | Benchmark | Trend |
|
||||
|---|---|---|---|
|
||||
| eNPS | [-100 to +100] | Industry avg | vs last survey |
|
||||
|
||||
eNPS: Below 0 = Concerning / 0-30 = Good / 30-70 = Great / 70+ = Excellent
|
||||
|
||||
**2. Strengths** — Top scoring areas with evidence.
|
||||
|
||||
**3. Improvement Areas** — 3 lowest scoring areas with verbatim comment themes.
|
||||
|
||||
**4. Action Planning Template**
|
||||
| Improvement area | Action | Owner | Timeline | Measure |
|
||||
|---|---|---|---|---|
|
||||
|
||||
**5. Communication Template** — Draft message to share results with employees.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Survey includes anonymity statement at the start
|
||||
- [ ] eNPS question (0-10 recommend scale) is included in all survey types
|
||||
- [ ] Open-ended questions are included (not just Likert scales)
|
||||
- [ ] Analysis includes a specific action planning template (not just observations)
|
||||
- [ ] Results communication template commits to sharing back with employees by a specific date
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not launch a survey without committing to a communication-back date — surveys with no follow-through reduce trust and depress future response rates
|
||||
- [ ] Do not use only Likert scale questions — open-text responses surface specific themes that quantitative scores cannot, and are essential for action planning
|
||||
- [ ] Do not design a comprehensive 30+ question survey as a pulse — pulse surveys that take more than 5 minutes see sharply lower completion rates
|
||||
- [ ] Do not present analysis without an action planning template — raw scores without committed actions are the most common reason engagement survey data is ignored
|
||||
- [ ] Do not segment results below teams of 5 when anonymity is promised — small-group breakdowns allow individual identification and destroy psychological safety
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Create an employee engagement survey for our team"
|
||||
- "Design a pulse survey for [topic]"
|
||||
- "Analyse these engagement survey results: [paste]"
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Write a clear, inclusive, and structured job description for any role. Use when asked to write a job description, job posting, JD, or job advert. Produces a complete JD with role summary, responsibilities, requirements, and inclusive language review."
|
||||
---
|
||||
|
||||
# Job Description Writer Skill
|
||||
|
||||
Writes complete, inclusive job descriptions that attract the right candidates and reduce bias in the hiring process.
|
||||
|
||||
## Required Inputs
|
||||
- **Job title and level**
|
||||
- **Team and reporting line**
|
||||
- **Top 5 things this person will actually do**
|
||||
- **Must-have requirements** (be ruthless — only what is truly required)
|
||||
- **Nice-to-have requirements**
|
||||
- **Salary range** (JDs with salary ranges get 30% more applicants)
|
||||
- **Location and remote policy**
|
||||
- **Company description** (2-3 sentences)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### [Job Title]
|
||||
**[Company] | [Location] | [Remote policy] | [Salary range]**
|
||||
|
||||
**About [Company]**
|
||||
[2-3 sentences. Specific and honest — not marketing copy.]
|
||||
|
||||
**The Role**
|
||||
[3-4 sentences. What this person will own, why the role exists now, what success looks like in year one.]
|
||||
|
||||
**What You Will Do**
|
||||
[6-8 bullet points. Outcomes and responsibilities, not activities. Start each with an action verb. Most important first.]
|
||||
|
||||
**What We Are Looking For**
|
||||
|
||||
Must have (4-6 items only):
|
||||
- [Requirement]
|
||||
|
||||
Nice to have (3-4 items):
|
||||
- [Nice to have]
|
||||
|
||||
**What We Offer**
|
||||
[Compensation, benefits, development. Be specific.]
|
||||
|
||||
**How to Apply**
|
||||
[Clear instructions. What to send, where, timeline.]
|
||||
|
||||
---
|
||||
|
||||
### Inclusive Language Review
|
||||
|
||||
**Words to remove or replace:**
|
||||
|
||||
| Original | Replace with | Why |
|
||||
|---|---|---|
|
||||
| "rockstar" | "experienced" | Gendered connotation |
|
||||
| "ninja" | "skilled" | Same issue |
|
||||
| "must have degree" | "relevant experience or qualification" | Excludes qualified non-graduates |
|
||||
|
||||
**Requirement audit:**
|
||||
- Years of experience requirements flagged (screen out women and underrepresented groups disproportionately)
|
||||
- Any requirements potentially discriminating against protected characteristics
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Salary range included
|
||||
- [ ] Must-haves genuinely essential (6 items max)
|
||||
- [ ] Each responsibility starts with action verb
|
||||
- [ ] Inclusive language review completed
|
||||
- [ ] No years-of-experience requirements unless legally required
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not include years-of-experience requirements unless legally necessary — they exclude qualified candidates and may create legal risk
|
||||
- [ ] Do not list "nice to have" items in the requirements section — separate mandatory from desirable clearly
|
||||
- [ ] Do not use gendered or exclusionary language — run the inclusive language check before finalising
|
||||
- [ ] Do not write a responsibilities section with more than 8 items — prioritise the most important duties
|
||||
- [ ] Do not omit compensation range where legally required or culturally expected — hiding salary deters qualified candidates
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a job description for a [role]"
|
||||
- "Create an inclusive job posting for [role]"
|
||||
- "Review and rewrite this JD: [paste]"
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Create a structured 30/60/90-day onboarding plan for any new hire. Use when asked to write an onboarding plan, new hire plan, 30-60-90 day plan, or first 90 days roadmap. Produces a week-by-week plan with milestones, meetings, learning goals, and success criteria."
|
||||
---
|
||||
|
||||
# Onboarding Plan Skill
|
||||
|
||||
Creates a complete, structured onboarding plan tailored to a specific role — covering the first 90 days with clear milestones and success criteria.
|
||||
|
||||
## Required Inputs
|
||||
- **Role and level** of the new hire
|
||||
- **Team and manager**
|
||||
- **Key stakeholders** they will work with
|
||||
- **Top 3 priorities** for their first 90 days
|
||||
- **Tools and systems** they will need access to
|
||||
- **Company stage** (startup / scaleup / enterprise)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Onboarding Plan: [Name] — [Role]
|
||||
**Start date:** [Date] | **Manager:** [Name] | **Buddy:** [Name]
|
||||
|
||||
---
|
||||
|
||||
### Before Day 1 (Manager checklist)
|
||||
- IT setup: laptop, accounts, email, Slack, key tools
|
||||
- Access provisioned to key systems
|
||||
- First week calendar blocked with key meetings
|
||||
- Buddy assigned and briefed
|
||||
- Welcome message sent with Day 1 logistics
|
||||
|
||||
---
|
||||
|
||||
### Week 1: Orient
|
||||
Theme: Listen, learn, do not act yet.
|
||||
|
||||
| Day | Focus | Key activities |
|
||||
|---|---|---|
|
||||
| Day 1 | IT setup, team intro | 1:1 with manager, team lunch |
|
||||
| Day 2 | Product deep dive | Demo, key docs to read |
|
||||
| Day 3 | Process and tools | Shadow key workflows |
|
||||
| Day 4 | Stakeholder intros | 3-4 intro 1:1s |
|
||||
| Day 5 | Week 1 debrief | Check-in, questions logged |
|
||||
|
||||
**Week 1 milestone:** Can describe what the company does, the team role, and their top 3 priorities.
|
||||
|
||||
---
|
||||
|
||||
### Days 8-30: Learn
|
||||
Learning goals:
|
||||
- Deep understanding of product from customer perspective
|
||||
- Know key metrics the team is measured on
|
||||
- Understand current projects and status
|
||||
- Map key stakeholder relationships
|
||||
- Complete all compliance/HR training
|
||||
|
||||
**30-day milestone:** All stakeholder 1:1s complete. 2-3 early observations shared with manager.
|
||||
|
||||
---
|
||||
|
||||
### Days 31-60: Contribute
|
||||
Goals:
|
||||
- Own at least one project end-to-end
|
||||
- Make one meaningful contribution
|
||||
- Build cross-functional relationships
|
||||
- Identify one process improvement
|
||||
|
||||
**60-day milestone:** Delivered one tangible output. Manager says "this person is contributing."
|
||||
|
||||
---
|
||||
|
||||
### Days 61-90: Lead
|
||||
Goals:
|
||||
- Operating independently on core responsibilities
|
||||
- Has formed and shared a point of view on priorities
|
||||
- Building reputation with key stakeholders
|
||||
|
||||
**90-day milestone:** Ready for formal review. Clear 6-month plan in place.
|
||||
|
||||
---
|
||||
|
||||
### 90-Day Review Questions
|
||||
Manager: Meeting expectations? What to double down on? What to develop?
|
||||
New hire: Have the clarity, tools, support needed? What surprised you? What would you change about onboarding?
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Before Day 1 manager checklist is complete (IT, access, buddy, calendar)
|
||||
- [ ] Each phase (orient/learn/contribute/lead) has a clear milestone
|
||||
- [ ] 90-day review questions are included for both manager and new hire
|
||||
- [ ] Plan is tailored to the specific role and level (not generic)
|
||||
- [ ] Key stakeholder 1:1s are listed by name or role
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not produce a generic plan that could apply to any role — the plan must reference the specific role, team, tools, and priorities provided, not use placeholder text
|
||||
- [ ] Do not skip the Before Day 1 manager checklist — IT access and system provisioning failures on day 1 destroy first impressions and waste the new hire's first week
|
||||
- [ ] Do not set milestones without distinguishing between the orient, learn, contribute, and lead phases — collapsing phases produces plans where new hires are expected to lead before they understand the product
|
||||
- [ ] Do not omit the 90-day review questions — the review is the accountability mechanism for the entire plan, and skipping it makes the milestones meaningless
|
||||
- [ ] Do not treat the plan as a task list — each phase should have a clear theme and a milestone that describes an observable capability, not just a set of completed activities
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Create a 30/60/90 day plan for a new [role]"
|
||||
- "Write an onboarding plan for [name] starting as [role]"
|
||||
- "Build a first 90 days roadmap for our new hire"
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Structure a redundancy consultation process and draft key communications. Use when asked to plan a redundancy process, write a redundancy letter, structure a consultation, or manage a reduction in force. UK employment law focus. Always recommend qualified HR/legal advice before proceeding."
|
||||
---
|
||||
|
||||
# Redundancy Consultation Skill
|
||||
|
||||
Structures redundancy processes and drafts communications. Significant legal and human risk — always flag that employment legal advice is essential before proceeding.
|
||||
|
||||
WARNING: Defaults to UK employment law (Employment Rights Act 1996). Always recommend qualified HR/legal advice before any redundancy action.
|
||||
|
||||
## Required Inputs
|
||||
- **Number of roles affected** (1-19 = individual; 20+ = collective consultation required)
|
||||
- **Reason for redundancy** (genuine business reason)
|
||||
- **Jurisdiction** (UK / US / EU / Other)
|
||||
- **Timeline constraints**
|
||||
- **Selection pool** (if multiple people in similar roles)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Process Overview
|
||||
|
||||
**Individual redundancy (fewer than 20):**
|
||||
| Stage | Action | Minimum timeline |
|
||||
|---|---|---|
|
||||
| 1 | Confirm business case internally | Before any communication |
|
||||
| 2 | At-risk notification meeting | Day 1 |
|
||||
| 3 | Individual consultation | Minimum 1 meaningful meeting |
|
||||
| 4 | Redundancy confirmed or alternative found | After genuine consideration |
|
||||
| 5 | Notice period begins | Per contract |
|
||||
| 6 | Final day and payment | Per contract + statutory |
|
||||
|
||||
**Collective redundancy (20+ roles — UK):**
|
||||
- Minimum 45 days consultation before first dismissal
|
||||
- Must notify BEIS (HR1 form) before consultation begins
|
||||
- Employee representatives must be elected if no union recognised
|
||||
- Failure = unlimited protective award per employee
|
||||
|
||||
### 2. Selection Criteria (if pool exists)
|
||||
Objective, non-discriminatory only: skills/qualifications, performance (documented evidence), attendance (exclude disability/pregnancy-related absences), length of service (tiebreaker only).
|
||||
|
||||
NEVER select on: age, disability, pregnancy/maternity, part-time status, trade union membership.
|
||||
|
||||
### 3. At-Risk Letter Draft
|
||||
"Dear [Name], I am writing to inform you that your role of [Job Title] is at risk of redundancy. This is because [specific business reason]. We would like to meet on [date] to discuss the situation and explore alternatives. You have the right to be accompanied by a colleague or trade union representative. No decision has been made. Yours sincerely, [Manager]"
|
||||
|
||||
### 4. Consultation Meeting Script
|
||||
Opening: "No decision has been made. This meeting is to explain the situation and listen to your views."
|
||||
Key questions: Any ways to avoid this? Alternative roles of interest? Anything about selection to challenge?
|
||||
|
||||
### 5. Redundancy Confirmation Letter Draft
|
||||
Issued only after genuine consultation. Must include: statutory pay calculated, notice period, payment for accrued holiday, right of appeal.
|
||||
|
||||
### 6. Statutory Redundancy Pay Guide (UK)
|
||||
- Under 22: 0.5 week per year of service
|
||||
- 22-40: 1 week per year of service
|
||||
- 41+: 1.5 weeks per year of service
|
||||
- Weekly pay capped (verify current rate)
|
||||
- Maximum 20 years counts
|
||||
|
||||
---
|
||||
|
||||
WARNING: Take advice from an employment lawyer or qualified HR professional before beginning any redundancy process.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Number of roles determines consultation type (individual vs collective)
|
||||
- [ ] Selection criteria are objective and non-discriminatory
|
||||
- [ ] At-risk letter states no decision has been made
|
||||
- [ ] Consultation meeting includes genuine exploration of alternatives
|
||||
- [ ] Statutory redundancy pay guidance included
|
||||
- [ ] Legal advice disclaimer is prominent
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not proceed without a prominent disclaimer that qualified HR and legal advice is required before taking any action
|
||||
- [ ] Do not use template letters without customising them for the specific individual and situation
|
||||
- [ ] Do not omit the genuine exploration of alternatives — redundancy consultation must consider alternatives before confirming decisions
|
||||
- [ ] Do not leave out statutory redundancy pay guidance — employees have legal entitlements that must be referenced
|
||||
- [ ] Do not conduct a redundancy process without documenting the selection criteria and scoring — undocumented decisions create legal risk
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Help me structure a redundancy consultation"
|
||||
- "Draft an at-risk letter for [role]"
|
||||
- "What is the process for making someone redundant in the UK?"
|
||||
Reference in New Issue
Block a user