Add multi-platform export generator (single source of truth)
Make the library multi-platform without duplicating content. Each skills/<name>/SKILL.md body remains the single source of truth; a new generator renders platform-ready exports from it. - scripts/build-exports.mjs — dependency-free Node generator with a PLATFORMS registry so new platforms (Gemini, Cursor, …) are a few lines. Ships ChatGPT exports at exports/chatgpt/<bundle>/<skill>/SYSTEM_PROMPT.md (172 skills), plus generated index READMEs. Supports --platform and --check. - exports/ — generated ChatGPT system prompts, ready to paste into a Custom GPT. - .github/workflows/check-generated.yml — fails a PR if exports or web/skills.json drift from the source skills. - README "Works With" now documents the ready-to-use exports and regen command. - CHANGELOG + SKILL-AUTHORING-STANDARD note the generated artifacts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px
This commit is contained in:
Claude
@@ -0,0 +1,142 @@
|
||||
# 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,109 @@
|
||||
# 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,77 @@
|
||||
# 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,100 @@
|
||||
# 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,80 @@
|
||||
# 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