justin/pm-claude-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: v12.0.0 — 150-skill milestone, 15 new skills across 10 bundles

Browse Source 
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
2026-05-26 21:58:13 +01:00
parent 94e53d38a8
commit ae6ea4d53e
32 changed files with 6630 additions and 152 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/pm-operations/skills/raci-matrix/SKILL.md
+160
View File
@@ -0,0 +1,160 @@
---
name: raci-matrix
description: "Define a RACI matrix for a cross-functional project or process. Use when asked to build a RACI, create a responsibility matrix, clarify ownership across teams, or document decision rights. Produces a complete RACI matrix with role definitions, decision mapping, and a process for resolving conflicts."
---
# RACI Matrix Skill
This skill produces a complete RACI (Responsible, Accountable, Consulted, Informed) matrix for a project, product launch, or ongoing process. Output is ready to share with teams to clarify ownership, reduce decision bottlenecks, and eliminate duplication of effort.
## Required Inputs
Ask the user for these if not provided:
- **Project or process name**
- **Key activities or decisions** to map (or the user can describe the project and the skill will derive them)
- **Teams or roles involved** (list team names and key individuals if helpful)
- **Primary purpose** — clarifying launch ownership / onboarding a new team / reducing bottlenecks / governance documentation
- **RACI variant** — standard RACI, or RASCI (adds Supportive), or DACI (Driver, Approver, Contributors, Informed)?
## Output Structure
---
# RACI Matrix: [Project / Process Name]
**Version:** [1.0]
**Owner:** [Programme lead / PM]
**Date:** [Date]
**Teams involved:** [List teams]
---
## 1. Role Definitions
Before reading the matrix, agree on what each letter means for this project:
| Letter | Role | Definition | Rules |
|---|---|---|---|
| **R** | Responsible | Does the work. One or more people actually execute the task. | Multiple Rs are allowed — but if there are many, consider splitting the task |
| **A** | Accountable | Owns the outcome. Signs off on decisions. Answers if something goes wrong. | **There must be exactly one A per row.** Never two. Never zero. |
| **C** | Consulted | Provides expertise or input before work is done. Two-way communication. | Consulted parties must be engaged — not just available. Cap at 3 per row or it becomes noise |
| **I** | Informed | Notified of progress or outcomes. One-way communication. | Informed only — they don't review or approve |
**Golden rules:**
- Every row has exactly one **A**
- The same person or team should not be **A** for more than [X] rows — spreads accountability too thin
- **C** is expensive — consulting someone means they must respond. Use it intentionally
- If someone is **R** they cannot also be **A** for the same task unless they are the decision-maker (common in small teams)
---
## 2. RACI Matrix
Columns = teams or roles. Rows = activities or decisions.
| Activity / Decision | [Role 1] | [Role 2] | [Role 3] | [Role 4] | [Role 5] | Notes |
|---|---|---|---|---|---|---|
| **[Phase 1: Discovery]** | | | | | | |
| Define project scope and objectives | A/R | C | I | I | — | PM leads; engineering consulted on technical feasibility |
| Conduct user research | R | A | C | I | — | UX researcher executes; PM accountable |
| Approve discovery findings | C | A | I | R | — | |
| **[Phase 2: Design]** | | | | | | |
| Define solution approach | A | R | C | I | I | |
| Design system / UI designs | C | A/R | I | I | — | |
| Design review and sign-off | C | R | A | I | — | |
| Accessibility review | I | R | A | C | — | |
| **[Phase 3: Build]** | | | | | | |
| Technical architecture decision | C | C | A/R | I | — | |
| Sprint planning | A | C | R | I | I | |
| Code review and merge | I | C | R | A | — | |
| Security review | I | C | C | A/R | — | |
| **[Phase 4: Launch]** | | | | | | |
| Launch go / no-go decision | A | C | C | R | I | PM holds final authority |
| Release to production | C | I | A/R | I | — | |
| Customer communications | A/R | I | I | I | C | |
| Post-launch monitoring | C | I | R | A | — | |
| **[Ongoing / BAU]** | | | | | | |
| Incident response | I | C | R | A | — | |
| Feature prioritisation | A/R | C | C | I | I | |
| Stakeholder reporting | A/R | I | I | I | C | |
---
## 3. Decision Map
For high-stakes decisions, document the decision type, who holds authority, and how disagreements are resolved:
| Decision | Authority (A) | Must consult (C) | Escalation path if disagreed |
|---|---|---|---|
| Scope change >20% effort | [Exec sponsor / Programme lead] | [PM, Engineering lead] | [Steering committee] |
| Budget overrun >10% | [Finance / Exec] | [PM, Programme lead] | [CFO / Board] |
| Architecture pattern change | [Engineering lead] | [Tech lead, Security] | [CTO] |
| Go-live date change | [PM] | [Engineering, Comms, CS] | [Programme sponsor] |
| Feature cut from scope | [PM] | [Product, UX, Engineering] | [CPO] |
---
## 4. Common RACI Anti-Patterns — and Fixes
Review the completed matrix against these failure modes:
| Anti-pattern | Symptom | Fix |
|---|---|---|
| **Multiple As** | Two teams both think they own an outcome | Agree one A; the other becomes C or I |
| **No A** | Decisions stall; no one feels responsible | Assign the most senior stakeholder as A |
| **Everyone is C** | Every decision goes to a committee | Audit each C — does this person actually provide input that changes outcomes? If not, move to I |
| **R without A** | Work gets done but no one owns quality | Add an A; usually the manager of the R |
| **A without R** | Accountability without execution — manager is disconnected | Add an R from the team; or combine A/R if appropriate |
| **Too many Rs** | Diffusion of responsibility | Split the task into sub-tasks, each with one clear R |
| **Key team missing from matrix** | They're affected but not in the RACI | Add them; assign at minimum I for relevant rows |
---
## 5. Communication Template
Once the RACI is agreed, use this template to communicate it to all involved teams:
---
**Subject:** [Project Name] — Roles and Responsibilities Agreed
We've finalised the RACI matrix for [Project Name]. Here's what it means for you:
**[Role 1 team]:** You are **Accountable** for [X, Y, Z activities]. This means you make the final call on those decisions and answer if outcomes are not met.
**[Role 2 team]:** You are **Responsible** for [A, B, C]. You execute the work. For [D], you are **Consulted** — we need your input before decisions are finalised.
**[Role 3 team]:** You are **Informed** on [E, F] — we'll send you updates at [weekly / milestone / launch]. No action required unless you see something that needs escalation.
Please review the full matrix here: [Link]. Raise any concerns by [Date] — after that, we'll treat it as agreed.
---
## 6. RACI Review Cadence
| Trigger | Action |
|---|---|
| New team member joins | Review rows relevant to their role — update R as needed |
| Phase change (e.g. discovery → delivery) | Review full matrix — some Rs and As will shift |
| Escalation or confusion about ownership | Use the matrix to diagnose — find the missing A |
| 3 months into a long programme | Full RACI review — roles drift over time |
| Team restructure or reorganisation | Full rebuild — ownership assumptions change |
---
## Quality Checks
- [ ] Every row has exactly one **A**
- [ ] No individual or team is **A** for more than their realistic sphere of authority
- [ ] **C** columns are sparse — consulting everyone dilutes the process
- [ ] Matrix was reviewed and agreed by at least one representative from each role column
- [ ] A communication plan exists to share the RACI with all involved parties
- [ ] Decision map covers the top 5–10 highest-stakes decisions in the project
## Example Trigger Phrases
- "Build a RACI matrix for our product launch"
- "Create a responsibility matrix for our new cross-functional project"
- "Who owns what on this initiative? Help me build a RACI"
- "Map out decision rights for our engineering and product teams"
- "Generate a RACI for a [migration / launch / process] involving [teams]"
plugins/pm-operations/skills/risk-register/SKILL.md
+211
View File
@@ -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"