feat: v12.0.0 — 150-skill milestone, 15 new skills across 10 bundles
Adds 15 new skills reaching the 150-skill milestone: Data & Analytics (pm-data): - cohort-analysis: retention curves, LTV projection, behavioural segmentation, SQL reference queries - data-pipeline-spec: ETL/ELT design with SLAs, DQ rules, error handling, compliance Customer Success (pm-cs): - renewal-playbook: health snapshot, value story, commercial scenarios, objection responses, 16-week timeline - customer-success-plan: joint success plan with milestones, mutual commitments, escalation path People & Leadership (pm-people): - 360-feedback-template: survey instrument + narrative report with strengths and development themes - team-health-check: Spotify-model assessment across 7 dimensions with facilitation guide Operations (pm-operations): - risk-register: L×I scoring, RAG heat map, mitigation and contingency plans - raci-matrix: role definitions, decision map, anti-pattern guide, communication template Marketing & GTM (pm-gtm): - social-media-strategy: audience profile, content pillars, KPIs, 4-week starter calendar - product-positioning-doc: April Dunford-style positioning, messaging hierarchy, persona messaging Discovery (pm-discovery): - customer-journey-map: stage-by-stage journey with touchpoints, emotions, and prioritised opportunities Delivery (pm-delivery): - user-story-writer: Given/When/Then ACs, edge cases, definition of done, epic decomposition Advanced (pm-advanced): - ai-ethics-review: fairness, bias, transparency, privacy, safety, accountability, societal impact Sales (pm-sales): - partnership-proposal: mutual value, commercial model, joint GTM plan, governance Design (pm-design): - design-system-audit: component coverage, token consistency, WCAG, adoption, remediation roadmap Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
@@ -0,0 +1,211 @@
|
||||
---
|
||||
name: risk-register
|
||||
description: "Build and maintain a project or product risk register. Use when asked to create a risk register, identify project risks, build a risk matrix, or document risks and mitigations for a programme. Produces a complete risk register with likelihood/impact scoring, RAG status, ownership, and prioritised mitigations."
|
||||
---
|
||||
|
||||
# Risk Register Skill
|
||||
|
||||
This skill produces a complete risk register for a project, programme, or product. Output follows standard risk management practice with likelihood × impact scoring, RAG status, a risk heat map, and specific mitigation and contingency plans. Ready to share with a project board, steering committee, or programme office.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Project or product name**
|
||||
- **Project stage** (discovery / delivery / launch / live / programme-level)
|
||||
- **Key objectives** — what is the project trying to achieve?
|
||||
- **Known risks** — anything already on the team's radar (even informal concerns count)
|
||||
- **Key dependencies** — external vendors, teams, systems, or regulatory approvals
|
||||
- **Deadline or milestone sensitivity** — are there hard dates that cannot move?
|
||||
- **Audience** — who will read this? (internal team / executive steering / external board / regulator)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Risk Register: [Project / Product Name]
|
||||
|
||||
**Project stage:** [Discovery / Delivery / Launch / Live / Programme]
|
||||
**Version:** [1.0]
|
||||
**Owner:** [PM / Programme Manager / Risk Lead]
|
||||
**Last reviewed:** [Date]
|
||||
**Next review:** [Date — recommend weekly during delivery, monthly during discovery]
|
||||
**Status:** [Active / Archived]
|
||||
|
||||
---
|
||||
|
||||
## 1. Risk Scoring Framework
|
||||
|
||||
**Likelihood (L)**
|
||||
|
||||
| Score | Label | Definition |
|
||||
|---|---|---|
|
||||
| 5 | Almost certain | >80% probability of occurring |
|
||||
| 4 | Likely | 60–80% probability |
|
||||
| 3 | Possible | 40–60% probability |
|
||||
| 2 | Unlikely | 20–40% probability |
|
||||
| 1 | Rare | <20% probability |
|
||||
|
||||
**Impact (I)**
|
||||
|
||||
| Score | Label | Definition |
|
||||
|---|---|---|
|
||||
| 5 | Critical | Programme failure, regulatory breach, major financial loss, safety event |
|
||||
| 4 | High | Significant schedule delay (>4 weeks), scope reduction, reputational damage |
|
||||
| 3 | Medium | Moderate delay (1–4 weeks), cost overrun, reduced quality |
|
||||
| 2 | Low | Minor delay (<1 week), manageable cost increase |
|
||||
| 1 | Negligible | Minimal impact, easily absorbed |
|
||||
|
||||
**Risk Score = L × I**
|
||||
|
||||
| Score | RAG | Action |
|
||||
|---|---|---|
|
||||
| 20–25 | 🔴 Critical | Immediate escalation; active management required |
|
||||
| 12–19 | 🔴 High | Owner-assigned mitigation; weekly review |
|
||||
| 8–11 | 🟡 Medium | Mitigation planned; fortnightly review |
|
||||
| 4–7 | 🟡 Low | Monitor; monthly review |
|
||||
| 1–3 | 🟢 Negligible | Accept; review if context changes |
|
||||
|
||||
---
|
||||
|
||||
## 2. Risk Register
|
||||
|
||||
| ID | Risk | Category | L | I | Score | RAG | Owner | Status | Mitigation | Contingency | Review date |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| R01 | [Risk description — be specific: "Third-party API may not support required volume, causing X to fail"] | [Schedule / Technical / Resource / Commercial / Compliance / External] | [1–5] | [1–5] | [L×I] | 🔴/🟡/🟢 | [Name] | [Open / Mitigating / Closed] | [What are we doing to reduce likelihood or impact?] | [What do we do if it happens?] | [Date] |
|
||||
| R02 | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] |
|
||||
|
||||
---
|
||||
|
||||
## 3. Risk Categories — Common Risks by Type
|
||||
|
||||
Use these to prompt risk identification. Add, remove, or customise for your project.
|
||||
|
||||
### Schedule & Delivery
|
||||
- Key milestone depends on a dependency that has not confirmed availability
|
||||
- Team capacity reduced by planned or unplanned absence during critical period
|
||||
- Technical complexity is underestimated — story points consistently overrun
|
||||
- External approval (regulator, legal, procurement) takes longer than planned
|
||||
|
||||
### Technical
|
||||
- Integration with a third-party system not yet prototyped or agreed
|
||||
- Existing technical debt makes the change harder or riskier than estimated
|
||||
- Security or compliance review required before launch has not been scoped
|
||||
- Performance under production load untested
|
||||
- Key technical knowledge held by one person (single point of failure)
|
||||
|
||||
### Resource & People
|
||||
- Key SME or engineer leaving or unavailable during critical phase
|
||||
- Budget not confirmed for Phase 2 of the project
|
||||
- Stakeholder sponsor changes role or leaves the organisation
|
||||
- Team not yet at full capacity (hiring lag, access issues, onboarding time)
|
||||
|
||||
### Commercial & Financial
|
||||
- Vendor or partner contract not yet signed
|
||||
- Cost estimate based on assumptions that have not been validated
|
||||
- Revenue or savings case depends on assumptions outside the team's control
|
||||
- Currency exposure or exchange rate risk for international projects
|
||||
|
||||
### Compliance & Regulatory
|
||||
- Data privacy impact assessment (DPIA) not yet complete
|
||||
- Regulatory approval required and timeline is uncertain
|
||||
- GDPR, HIPAA, SOC 2, or sector-specific compliance requirement not yet mapped
|
||||
- Legal review of terms of service or contracts pending
|
||||
|
||||
### Stakeholder & Adoption
|
||||
- Key user group has low awareness or motivation to adopt the change
|
||||
- Internal resistance from a team that will be affected by the change
|
||||
- Executive sponsor not consistently engaged — decisions are slow
|
||||
- Communications plan not yet agreed with change management team
|
||||
|
||||
### External
|
||||
- Market or competitive change could undermine the business case
|
||||
- Macroeconomic conditions affect budget or priority
|
||||
- Supplier or infrastructure provider risk (e.g. cloud provider, hardware)
|
||||
- Geopolitical or regulatory environment change
|
||||
|
||||
---
|
||||
|
||||
## 4. Risk Heat Map
|
||||
|
||||
Plot risks by likelihood (Y axis) and impact (X axis):
|
||||
|
||||
```
|
||||
│ Low Medium High Critical
|
||||
│ (1) (2-3) (4) (5)
|
||||
─────────┼────────────────────────────────────
|
||||
Almost │ 🟡 🟡 🔴 🔴
|
||||
certain │
|
||||
(5) │
|
||||
─────────┼────────────────────────────────────
|
||||
Likely │ 🟡 🟡 🔴 🔴
|
||||
(4) │
|
||||
─────────┼────────────────────────────────────
|
||||
Possible │ 🟢 🟡 🟡 🔴
|
||||
(3) │
|
||||
─────────┼────────────────────────────────────
|
||||
Unlikely │ 🟢 🟢 🟡 🟡
|
||||
(2) │
|
||||
─────────┼────────────────────────────────────
|
||||
Rare │ 🟢 🟢 🟢 🟡
|
||||
(1) │
|
||||
```
|
||||
|
||||
[Plot each risk ID on this grid — e.g. R01 lands at L4/I5 = 🔴 Critical]
|
||||
|
||||
---
|
||||
|
||||
## 5. Top Risks — Executive Summary
|
||||
|
||||
For steering committee or board-level reporting:
|
||||
|
||||
| Rank | Risk | Score | RAG | Owner | Mitigation status |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | [Most critical risk — plain English description] | [X] | 🔴 | [Owner] | [Active / Planned / Not started] |
|
||||
| 2 | [...] | [...] | 🔴 | [...] | [...] |
|
||||
| 3 | [...] | [...] | 🟡 | [...] | [...] |
|
||||
| 4 | [...] | [...] | 🟡 | [...] | [...] |
|
||||
| 5 | [...] | [...] | 🟡 | [...] | [...] |
|
||||
|
||||
**Decisions required from steering:**
|
||||
- [Any risk that requires budget, scope, or timeline decision to mitigate]
|
||||
|
||||
---
|
||||
|
||||
## 6. Risk Changes Since Last Review
|
||||
|
||||
| Risk ID | Change | Detail |
|
||||
|---|---|---|
|
||||
| [R03] | Score increased | [L moved from 2 → 4 — vendor confirmed delay in API availability] |
|
||||
| [R07] | Risk closed | [Legal sign-off received on 12 May] |
|
||||
| [NEW] | New risk identified | [R09 — budget freeze announcement affects Phase 2 funding] |
|
||||
|
||||
---
|
||||
|
||||
## 7. Risk Closure Criteria
|
||||
|
||||
A risk is closed when:
|
||||
- The risk event can no longer occur (e.g. milestone passed, contract signed), OR
|
||||
- The residual risk score drops to Negligible (1–3) AND the team formally accepts it, OR
|
||||
- The risk has materialised and transitioned to an **issue** (tracked separately)
|
||||
|
||||
**Issues log:** [Link to issues log — risks that have materialised and are now active problems being managed]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every risk has a specific owner — not "the team" or "TBD"
|
||||
- [ ] Mitigations describe what is actively being done — not "monitor and review"
|
||||
- [ ] Contingency plans exist for all Critical and High risks
|
||||
- [ ] Risk descriptions are specific — "vendor may be late" is not specific enough; name the vendor and the dependency
|
||||
- [ ] Register has been reviewed in the last [X] days
|
||||
- [ ] Closed risks are archived, not deleted — they provide audit trail
|
||||
- [ ] Risks are distinguished from issues — a risk is something that might happen; an issue is something that has happened
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a risk register for our product launch"
|
||||
- "Create a risk matrix for [project name]"
|
||||
- "What risks should I document for a data migration project?"
|
||||
- "Generate a risk register for our steering committee"
|
||||
- "Help me identify and score risks for our Q3 delivery plan"
|
||||
Reference in New Issue
Block a user