feat: v10.0.0 — 8 new skills across Customer Success and Engineering (500-star milestone)

Two star milestones shipped together:

Customer Success bundle (pm-cs) — 250-star milestone:
- cs-health-scorecard: weighted RAG health score across 5 dimensions with renewal forecast
- qbr-deck: slide-by-slide QBR structure with value narrative and mutual commitments
- cs-escalation-brief: 4-level escalation framework with root cause, impact, and decision required
- churn-analysis: voluntary/unavoidable churn split, early warning signals, prioritised interventions

Engineering expansion (pm-engineering) — 500-star milestone:
- cicd-playbook: full pipeline playbook from build through post-deploy checks and rollback
- slo-error-budget: SLI definitions, burn rate alerts, and error budget policy
- developer-onboarding-doc: first-week guide covering architecture, setup, testing, and contacts
- oncall-runbook: per-alert response procedures, escalation matrix, and handoff template

Also:
- Added pm-cs plugin to marketplace.json
- Updated pm-engineering plugin.json to v3.0.0 (14 skills)
- Updated marketplace.json to v10.0.0 (114 skills, 23 bundles, 16 professions)
- README updated with new CS section, corrected skill numbering (106 → 114)
- Added bug report link to Contributing section
- Star milestones updated to show 250 and 500 as unlocked

.claude-plugin/marketplace.json

@@ -1,8 +1,8 @@
 {
   "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
   "name": "pm-claude-skills",
-  "version": "4.0.0",
-  "description": "53 Claude Skills across 6 professions — product management, marketing, engineering, data, design, and leadership. Save 10-15 hours per week.",
+  "version": "10.0.0",
+  "description": "114 Claude Skills + 4 agent templates across 23 plugin bundles covering 16 professions — product management, engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, and more. Building blocks for the Anthropic agent template architecture.",
   "owner": {
     "name": "Mohit Aggarwal",
     "email": "mohit15856@gmail.com"
@@ -10,8 +10,8 @@
   "plugins": [
     {
       "name": "pm-essentials",
-      "description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis. The 5 skills every PM needs first.",
-      "version": "3.0.0",
+      "description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, Word Doc Tracked Changes. The essentials every PM needs first.",
+      "version": "3.1.0",
       "category": "productivity",
       "source": "./plugins/pm-essentials",
       "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -34,8 +34,8 @@
     },
     {
       "name": "pm-delivery",
-      "description": "Sprint & delivery skills: Sprint Planning, Technical Spec Template, A/B Test Planner, Go-to-Market Planner, Product Launch Checklist, Sprint Brief, Retro Analysis.",
-      "version": "3.0.0",
+      "description": "Sprint & delivery skills: Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro Analysis, PPTX Slide Auditor.",
+      "version": "3.1.0",
       "category": "productivity",
       "source": "./plugins/pm-delivery",
       "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -74,25 +74,33 @@
     },
     {
       "name": "pm-gtm",
-      "description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign. Build positioning statements, messaging pillars, feature lists, use cases, and launch campaigns.",
-      "version": "1.0.0",
+      "description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign, SEO Content Brief, Media Pitch. Build positioning statements, messaging pillars, feature lists, use cases, launch campaigns, SEO briefs, and journalist pitches.",
+      "version": "1.1.0",
       "category": "productivity",
       "source": "./plugins/pm-gtm",
       "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
     },
     {
       "name": "pm-engineering",
-      "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record. Structured outputs for engineering teams and technical PMs.",
-      "version": "1.0.0",
+      "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook. 14 structured skills for engineering teams, SREs, and technical PMs.",
+      "version": "3.0.0",
       "category": "productivity",
       "source": "./plugins/pm-engineering",
       "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
     },
     {
-      "name": "pm-data",
-      "description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief. Build North Star metric trees, explain and optimise SQL, and spec dashboards from business questions.",
+      "name": "pm-cs",
+      "description": "Customer Success skills: Customer Health Scorecard, QBR Deck, Escalation Brief, Churn Analysis. Score account health with a weighted RAG framework, build structured QBR decks with value narratives, write crisp escalation briefs for at-risk accounts, and analyse churn by category and segment with prioritised interventions.",
       "version": "1.0.0",
       "category": "productivity",
+      "source": "./plugins/pm-cs",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-data",
+      "description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief, Chart Data Extractor. Build North Star metric trees, explain SQL, spec dashboards, and digitise chart images.",
+      "version": "1.1.0",
+      "category": "productivity",
       "source": "./plugins/pm-data",
       "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
     },
@@ -119,6 +127,70 @@
       "category": "productivity",
       "source": "./plugins/pm-business",
       "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-legal",
+      "description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-legal",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-finance",
+      "description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence, Tax Planning Checklist. Turn numbers into board-ready narratives, explain variances, structure pitch decks, generate DD checklists, and review year-end tax planning opportunities.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-finance",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-hr",
+      "description": "HR skills: Job Description Writer, Onboarding Plan, Employee Engagement Survey, Redundancy Consultation, Change Management Plan. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, structure redundancy processes, and manage organisational change with stakeholder analysis and adoption metrics.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-hr",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-sales",
+      "description": "Sales skills: Sales Battlecard, Discovery Call Prep, Proposal Writer, Account Plan, Sales Forecasting Model. Build competitive battlecards, prepare discovery calls, write winning proposals, create account plans, and build pipeline-based revenue forecasts with scenario analysis.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-sales",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-operations",
+      "description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report, Workshop Facilitation Guide. Document workflows, write audit-ready SOPs, evaluate vendors, produce RAG status reports, and design facilitated workshops with activity instructions and facilitator moves.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-operations",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-research",
+      "description": "Research and healthcare skills: Clinical Case Summary, Research Protocol, Patient Communication, Literature Review. Write SBAR handovers, design research protocols, draft accessible patient communications, and structure literature reviews.",
+      "version": "1.0.0",
+      "category": "productivity",
+      "source": "./plugins/pm-research",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-cross",
+      "description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary, Teaching Lesson Plan. Write journalist-ready press releases, structure grant applications, produce decision-ready executive summaries, and design complete lesson plans for any subject, audience, or setting.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-cross",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-figma",
+      "description": "Figma skills for PMs and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter across the full Figma design lifecycle.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-figma",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
     }
   ]
 }

.github/ISSUE_TEMPLATE/bug-report.md

@@ -0,0 +1,65 @@
+---
+name: "🐛 Bug Report"
+about: "A skill isn't triggering correctly, producing wrong output, or something else is broken"
+title: "[BUG] "
+labels: ["bug"]
+assignees: ""
+---
+
+## Which skill is affected?
+
+<!-- e.g. plugins/pm-gtm/skills/go-to-market -->
+
+**Skill path:**
+
+---
+
+## What's the problem?
+
+<!-- Tick all that apply -->
+
+- [ ] Skill isn't triggering when it should
+- [ ] Skill is triggering when it shouldn't
+- [ ] Output is missing a section
+- [ ] Output format is wrong
+- [ ] Skill description is incorrect or misleading
+- [ ] Plugin isn't showing in the marketplace
+- [ ] Installation issue
+- [ ] Other: ___________
+
+---
+
+## What did you expect to happen?
+
+---
+
+## What actually happened?
+
+<!-- Paste the output or describe what went wrong -->
+
+---
+
+## How to reproduce
+
+<!-- Step by step:
+     1. Trigger phrase used: "..."
+     2. Claude Code version: ...
+     3. What happened: ... -->
+
+1.
+2.
+3.
+
+---
+
+## Environment
+
+- **Claude Code version:**
+- **OS:**
+- **Install method:** marketplace / manual / symlink
+
+---
+
+## Any additional context?
+
+<!-- Screenshots, logs, or anything else helpful -->

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: 📚 Read the article series
+    url: https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a
+    about: Full background on the Claude Skills Library and how to use it
+  - name: 💬 Start a Discussion
+    url: https://github.com/mohitagw15856/pm-claude-skills/discussions
+    about: For open-ended conversations, ideas, and community skill sharing

.github/ISSUE_TEMPLATE/question-feedback.md

@@ -0,0 +1,21 @@
+---
+name: "💬 Question or Feedback"
+about: "Ask a question about using the skills, or share feedback on the library"
+title: "[QUESTION] "
+labels: ["question"]
+assignees: ""
+---
+
+## What's your question or feedback?
+
+---
+
+## Context
+
+<!-- Which skill or bundle are you asking about? Any relevant details about your setup? -->
+
+---
+
+## What have you already tried?
+
+<!-- If it's a question about getting something working — what have you attempted? -->

.github/ISSUE_TEMPLATE/skill-request.md

@@ -0,0 +1,70 @@
+---
+name: "💡 Skill Request"
+about: "Suggest a new skill you'd like to see added to the library"
+title: "[SKILL REQUEST] "
+labels: ["skill-request"]
+assignees: ""
+---
+
+## What skill are you requesting?
+
+<!-- A short name for the skill, e.g. "Legal Contract Review" or "Sales Battlecard Builder" -->
+
+**Skill name:**
+
+---
+
+## What profession or role is this for?
+
+<!-- Who would use this skill day-to-day? -->
+
+- [ ] Product Management
+- [ ] Marketing & GTM
+- [ ] Engineering & Tech
+- [ ] Data & Analytics
+- [ ] Leadership & People
+- [ ] Design & UX
+- [ ] Business & Strategy
+- [ ] Legal
+- [ ] Finance
+- [ ] HR
+- [ ] Sales
+- [ ] Other: ___________
+
+---
+
+## What workflow does this skill solve?
+
+<!-- Describe the specific task or document this skill should produce.
+     Be as concrete as possible — what do you do today that takes too long? -->
+
+---
+
+## What should the output look like?
+
+<!-- What does a good output from this skill contain?
+     E.g. "A structured contract review with flagged clauses, risk rating, and plain English summary" -->
+
+---
+
+## Example trigger phrases
+
+<!-- How would you naturally ask Claude to use this skill?
+     E.g. "Review this contract", "Flag the key risks in this NDA" -->
+
+-
+-
+
+---
+
+## Are you willing to build this skill yourself?
+
+- [ ] Yes — I'll raise a PR with the SKILL.md
+- [ ] Maybe — I'd like guidance first
+- [ ] No — I'm suggesting it for someone else to build
+
+---
+
+## Any additional context?
+
+<!-- Links, examples, or anything else that would help someone build this skill -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,92 @@
+## What does this PR add or change?
+
+<!-- One sentence summary -->
+
+---
+
+## Type of change
+
+- [ ] New skill
+- [ ] Improvement to an existing skill
+- [ ] Bug fix (skill not triggering / wrong output)
+- [ ] Documentation update (README, CONTRIBUTING, etc.)
+- [ ] Marketplace / plugin config change
+- [ ] Other: ___________
+
+---
+
+## New skill checklist
+
+<!-- If you're adding a new skill, tick all of these before requesting review.
+     If this isn't a new skill PR, delete this section. -->
+
+**Skill file**
+- [ ] Skill is in the correct folder: `plugins/[bundle-name]/skills/[skill-name]/SKILL.md`
+- [ ] Frontmatter includes `name` and `description` fields
+- [ ] `description` clearly states when Claude should activate this skill (trigger condition)
+- [ ] `description` clearly states what the skill produces (output description)
+
+**Content quality**
+- [ ] Skill solves a real, recurring professional workflow (not a one-off task)
+- [ ] Output structure is clearly defined with sections and format
+- [ ] Required inputs are listed (what Claude should ask for if not provided)
+- [ ] Quality checks section is included
+- [ ] Example trigger phrases are included (at least 2)
+
+**Safety**
+- [ ] Skill contains no prompt injection attempts or instructions to override Claude's guidelines
+- [ ] Skill does not instruct Claude to collect, store, or transmit personal data
+- [ ] Skill does not contain hardcoded credentials, API keys, or PII
+
+**Testing**
+- [ ] I have tested this skill locally in Claude Code
+- [ ] The skill triggers correctly on the example trigger phrases
+- [ ] The output matches the structure defined in the SKILL.md
+
+---
+
+## What does this skill do?
+
+<!-- 2-3 sentences. What workflow does it solve? Who is it for? -->
+
+---
+
+## Example output
+
+<!-- Paste a real sample output from Claude when this skill was triggered, or describe what it produces.
+     This is the most useful thing you can include for review. -->
+
+---
+
+## Which bundle does this belong in?
+
+<!-- Which existing plugin bundle should this skill be added to?
+     Or are you proposing a new bundle? -->
+
+- [ ] pm-essentials
+- [ ] pm-discovery
+- [ ] pm-planning
+- [ ] pm-delivery
+- [ ] pm-analytics
+- [ ] pm-strategy
+- [ ] pm-advanced
+- [ ] pm-rituals
+- [ ] pm-gtm
+- [ ] pm-engineering
+- [ ] pm-data
+- [ ] pm-people
+- [ ] pm-design
+- [ ] pm-business
+- [ ] New bundle: ___________
+
+---
+
+## Related issue
+
+<!-- If this PR addresses a skill request issue, link it here: "Closes #123" -->
+
+---
+
+## Anything else the reviewer should know?
+
+<!-- Edge cases, limitations, or anything that might need discussion -->

CODE_OF_CONDUCT.md

@@ -0,0 +1,39 @@
+# Code of Conduct
+
+## Our Pledge
+
+This is an open-source community built around sharing useful Claude Skills across professions. Everyone who contributes, raises issues, or participates in discussions is expected to make this a welcoming and constructive space.
+
+We pledge to make participation in this project a harassment-free experience for everyone, regardless of age, background, disability, ethnicity, gender identity, level of experience, nationality, personal appearance, race, religion, or sexual identity.
+
+## Our Standards
+
+**Behaviour that helps this community thrive:**
+- Sharing skills that solve real workflows, with honest descriptions of what they do
+- Giving constructive feedback on PRs — specific, actionable, and respectful
+- Acknowledging other contributors' work
+- Being direct about limitations or gaps in a skill without being dismissive
+- Helping newcomers get their first PR merged
+
+**Behaviour that is not acceptable:**
+- Harassment, personal attacks, or dismissive comments on contributions
+- Submitting skills that contain malicious instructions or prompt injection attempts
+- Spamming issues or PRs with low-effort or off-topic content
+- Claiming credit for someone else's skill file
+- Any form of discrimination
+
+## Scope
+
+This Code of Conduct applies to all spaces managed by this project — GitHub Issues, Pull Requests, Discussions, and any other forums linked from this repo.
+
+## Reporting
+
+If you experience or witness unacceptable behaviour, contact the maintainer directly at **mohit15856@gmail.com**. All reports will be reviewed and responded to promptly and confidentially.
+
+## Enforcement
+
+The maintainer reserves the right to remove comments, close PRs, or ban contributors who violate this Code of Conduct. Decisions will be made fairly and explained where possible.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1.

README.md

@@ -1,9 +1,17 @@
-# 🧠 Claude Skills Library — 53 Skills for Every Professional
+# 🧠 Claude Skills Library — 114 Skills for Every Profession
 
-> **Save 8–10 hours per week across any profession. Install in 2 minutes.**
+[![Stars](https://img.shields.io/github/stars/mohitagw15856/pm-claude-skills?style=social)](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
+[![Skills](https://img.shields.io/badge/skills-114-blue)](https://github.com/mohitagw15856/pm-claude-skills)
+[![Version](https://img.shields.io/badge/version-10.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
+[![Install](https://img.shields.io/badge/Install%20in%20Claude%20Code-2%20minutes-orange)](https://github.com/mohitagw15856/pm-claude-skills#-quick-install-2-minutes)
+[![License](https://img.shields.io/badge/license-MIT-lightgrey)](LICENSE)
+[![Sponsor](https://img.shields.io/badge/sponsor-❤️-ff69b4)](https://github.com/sponsors/mohitagw15856)
 
-A community-built library of Claude Skills covering product management, marketing, engineering, data, design, leadership, and business strategy. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
+> **114 Claude Skills + 4 agent templates across 16 professions. Save 8-10 hours per week.**
 
+A community-built library of Claude Skills covering product management, engineering, customer success, marketing, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, education, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
+
+**🆕 Latest release (v10.0.0):** The library now includes 114 skills + 4 working agent templates. Two star milestones unlocked at once — 250 stars brought 4 Customer Success skills, 500 stars brought 4 more Engineering skills.
 ---
 
 ## 🚀 Quick Install (2 minutes)
@@ -12,6 +20,33 @@ In Claude Code, run:
 
 /plugin marketplace add mohitagw15856/pm-claude-skills
 
+Or install by profession:
+
+claude plugin install pm-essentials@pm-claude-skills     # Core PM + Word tracked changes
+
+claude plugin install pm-delivery@pm-claude-skills       # Delivery + PowerPoint auditor
+
+claude plugin install pm-engineering@pm-claude-skills    # Engineering (14 skills) 🆕
+claude plugin install pm-cs@pm-claude-skills             # Customer Success 🆕
+
+claude plugin install pm-data@pm-claude-skills           # Data + chart data extractor
+
+claude plugin install pm-legal@pm-claude-skills          # Legal
+
+claude plugin install pm-finance@pm-claude-skills        # Finance
+
+claude plugin install pm-hr@pm-claude-skills             # HR
+
+claude plugin install pm-sales@pm-claude-skills          # Sales
+
+claude plugin install pm-operations@pm-claude-skills     # Operations
+
+claude plugin install pm-research@pm-claude-skills       # Research & Healthcare
+
+claude plugin install pm-cross@pm-claude-skills          # Cross-profession
+
+claude plugin install pm-figma@pm-claude-skills          # Figma
+
 
 Or clone and symlink for auto-updates:
 
@@ -19,8 +54,154 @@ git clone https://github.com/mohitagw15856/pm-claude-skills.git ~/pm-claude-skil
 mkdir -p ~/.claude/skills
 ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/
 
+---
 
-That's it. All 53 skills are now available in every Claude Code session.
+## 🎬 See It in Action
+
+**Debugging Log Analyser** — paste a stack trace or error log, get a structured root cause diagnosis with probable cause, affected code path, a specific fix, and next debugging steps.
+
+**PR Description Writer** — share your diff or commit list, get a reviewer-friendly PR description with summary, changes made, testing steps, and reviewer notes.
+
+**Sprint Planning Skill** — paste your sprint goals and backlog items, get a complete structured sprint plan with capacity, commitments, risks, and a day-one kickoff agenda.
+
+> 📹 Drop a demo in [Discussions](../../discussions) and we'll feature it here.
+
+---
+
+## 🤖 Building Blocks for Agent Templates
+
+On May 5, 2026, Anthropic [released their first agent templates](https://www.anthropic.com/news/finance-agents) — pre-packaged Claude agents that combine **skills, connectors, and subagents** into ready-to-run workflows for financial services.
+
+This library is the largest open-source collection of professional skills available — covering 15 professions beyond financial services. **The 106 skills here are the building blocks for agent templates outside of finance.**
+
+### What is an agent template?
+
+An agent template packages three things into one runnable workflow:
+
+| Component | What it is | Example from this library |
+|---|---|---|
+| **Skills** | Markdown files that teach Claude how to produce structured professional outputs | `sprint-planning`, `contract-review`, `investor-update` |
+| **Connectors** | Governed access to your team's data sources | Linear, Jira, Slack, Google Drive, Notion |
+| **Subagents** | Focused Claude models for sub-tasks within the larger workflow | Capacity analyst, risk scorer, comparables selector |
+
+A skill alone gives Claude a structured output format. An agent template gives Claude a complete workflow — pulling data, running specialised analysis, producing the output, and routing it where it needs to go.
+
+### How to use this library to build your own agent template
+
+Pick a recurring workflow on your team. Identify which existing skills cover the structured outputs that workflow needs. Add the connectors that let Claude reach the data. Add subagents for the analytical sub-tasks. That's the template.
+
+Examples of agent templates this library supports:
+
+| Template | Skills used | Connectors needed | Subagents |
+|---|---|---|---|
+| **PM Sprint Agent** | sprint-planning, sprint-brief, retro, project-status-report | Linear or Jira, Slack | Capacity analyst, risk scorer |
+| **Legal Contract Review Agent** | contract-review, nda-analyser, compliance-checklist | Google Drive or SharePoint | Clause-by-clause risk scorer |
+| **PM Discovery Agent** | discovery-interview-guide, user-interview-synthesis, assumption-mapper | Granola or Otter, Notion | Theme synthesiser |
+| **Sales Pursuit Agent** | sales-battlecard, discovery-call-prep, proposal-writer, account-plan | Salesforce or HubSpot, Gong | Competitive intel analyst |
+| **HR Onboarding Agent** | onboarding-plan, job-description-writer, change-management-plan | Workday or BambooHR, Slack | First-week scheduler |
+| **Finance Board Pack Agent** | investor-update, board-deck-narrative, financial-model-narrative | NetSuite or Xero, Google Drive | KPI variance analyst |
+| **Marketing Launch Agent** | go-to-market, content-calendar, email-campaign, media-pitch | HubSpot, Notion | Channel strategist |
+
+
+### Available agent templates
+
+The pm-claude-skills library now includes four working agent templates, each built from existing skills in this library combined with subagents and connectors. All four follow the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026.
+
+| Template | What it does | Skills used | Connectors | Time saved |
+|---|---|---|---|---|
+| **[PM Sprint Agent](./templates/pm-sprint-agent/)** | End-to-end sprint planning — pulls backlog, calculates capacity, drafts plan, scores risks | sprint-planning, sprint-brief | Linear, Jira | 90 min → 90 sec |
+| **[PM Discovery Agent](./templates/pm-discovery-agent/)** | Customer discovery synthesis — reads interview notes, finds themes, scores assumption confidence | user-interview-synthesis, job-story-mapper | Notion, Google Drive | 1 day → 5 min |
+| **[PM Stakeholder Comms Agent](./templates/pm-stakeholder-comms-agent/)** | Audience-tailored stakeholder updates — exec, investor, cross-functional, or board | executive-update, investor-update, stakeholder-update, board-deck-narrative | Linear, Jira, Google Drive | 90 min → 1 min |
+| **[PM Launch Agent](./templates/pm-launch-agent/)** | End-to-end launch coordination — content for every channel, calendar, metrics, checklist | go-to-market, content-calendar, media-pitch, email-campaign, launch-checklist | Notion (optional) | 4-6 hours → 3 min |
+
+Each template includes:
+- Working orchestration script
+- Two or more focused subagents
+- Connector configurations with documented setup
+- Working examples (input + output)
+- Smoke test for verifying installations
+
+### How to install a template
+
+All templates are part of the main library — installing the marketplace gives you all four.
+
+/plugin marketplace add mohitagw15856/pm-claude-skills
+
+
+Then navigate to the template you want and follow its README:
+
+cd templates/pm-sprint-agent      # or pm-discovery-agent, etc.
+cat README.md                       # full setup instructions
+
+
+### Building your own template
+
+If you want to build a template for a workflow not covered above — Legal Contract Review, Sales Pursuit, Finance Board Pack, HR Onboarding, Marketing Campaign — see the [template contribution guide](./templates/CONTRIBUTING.md).
+
+The pattern is consistent: pick a multi-step workflow, identify which existing skills cover the structured outputs, add connectors for data access, and define subagents for specialised analysis. The four templates above are reference implementations.
+
+
+It combines four skills, two connectors, and two subagents into a single workflow that handles end-to-end sprint planning.
+
+Documentation, working orchestration script, and example outputs are included in the template folder.
+
+More templates will follow. If you want to contribute one, see the [template contribution guide](./templates/CONTRIBUTING.md).
+
+---
+
+## 🆕 What's New in v10.0.0
+
+**Two star milestones unlocked — 8 new skills shipped:**
+
+**Customer Success bundle (250 ⭐ milestone):**
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **Customer Health Scorecard** 🆕 | pm-cs | Weighted health score across adoption, engagement, outcomes, support, and commercial — with RAG status and renewal forecast |
+| **QBR Deck** 🆕 | pm-cs | Slide-by-slide quarterly business review structure with talking points, value narrative, and mutual commitments |
+| **Escalation Brief** 🆕 | pm-cs | Structured escalation brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
+| **Churn Analysis** 🆕 | pm-cs | Churn rate breakdown by category and segment, early warning signals, and prioritised interventions |
+
+**Engineering expansion (500 ⭐ milestone):**
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **CI/CD Playbook** 🆕 | pm-engineering | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
+| **SLO & Error Budget** 🆕 | pm-engineering | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
+| **Developer Onboarding Doc** 🆕 | pm-engineering | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
+| **On-Call Runbook** 🆕 | pm-engineering | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
+
+The library now includes **114 skills** across **16 professions** + 4 working agent templates.
+
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **Debugging Log Analyser** 🆕 | pm-engineering | Parse stack traces and error logs into a structured root cause diagnosis with a specific fix |
+| **PR Description Writer** 🆕 | pm-engineering | Write reviewer-friendly PR descriptions from a diff, commit list, or change summary |
+| **System Design Interview** 🆕 | pm-engineering | Structure complete system design answers with capacity estimates, component deep-dives, and trade-offs |
+| **Changelog Generator** 🆕 | pm-engineering | Convert git commits into a polished, user-facing changelog following Keep a Changelog format |
+| **Test Strategy Doc** 🆕 | pm-engineering | Write a complete test strategy with risk assessment, test types, coverage targets, and P0/P1 test cases |
+| **Runbook Writer** 🆕 | pm-engineering | Write operational runbooks for deployments, incidents, and maintenance with exact commands and rollback steps |
+
+The `pm-engineering` bundle now has **10 skills** — the most complete engineering toolkit in the library.
+
+**Read the full story:** [Part 14 — I Rebuilt All 93 Skills and Added 7 More: What 100 Skills Taught Me About What Makes a Great Skill](https://medium.com/product-powerhouse/a-pull-request-made-me-rebuild-all-93-of-my-claude-skills-then-i-added-7-more-16d5fe3e7f85)
+
+---
+
+## 📖 v6.0.0 — 100 Skills Milestone
+
+**7 skills added:**
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **Teaching Lesson Plan** | pm-cross | Structured lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
+| **SEO Content Brief** | pm-gtm | Complete SEO briefs with search intent analysis, competitor gaps, content outline, and on-page requirements |
+| **Media Pitch** | pm-gtm | Story-first journalist pitches with angle development framework and pitch rules |
+| **Change Management Plan** | pm-hr | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
+| **Workshop Facilitation Guide** | pm-operations | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
+| **Sales Forecasting Model** | pm-sales | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
+| **Tax Planning Checklist** | pm-finance | Year-end tax planning review framework across income, pension, CGT, business reliefs, and ISAs |
 
 ---
 
@@ -37,81 +218,275 @@ This repo was built alongside a published article series. Read the full story:
 | Part 5 | What Google, Meta and Anthropic Want From PMs — And the Claude Skills That Deliver It | [Read →](https://medium.com/@mohit15856/what-google-meta-and-anthropic-want-from-pms-and-the-claude-skills-that-deliver-it-b0f2b6cd9340) |
 | Part 6 | I Tested Anthropic's Skill Creator Plugin on My Own Skills | [Read →](https://medium.com/all-about-claude/i-tested-anthropics-skill-creator-plugin-on-my-own-skills-here-s-what-i-found-23ad406b0825) |
 | Part 7 | 33 Claude Skills for PMs Are Now in the Claude Code Marketplace | [Read →](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) |
-| Part 8 | I Added 20 New Claude Skills Beyond Product Management | *Latest — link TBC* |
+| Part 8 | I Added 20 New Claude Skills Beyond Product Management | [Read →](https://medium.com/product-powerhouse/i-built-20-new-claude-skills-for-every-profession-heres-the-full-library-50278e00bf72) |
+| Part 9 | 80 Claude Skills for Every Profession — Lawyers, Doctors, Finance, HR, Sales and More | [Read →](https://medium.com/@mohit15856/80-claude-skills-for-every-profession-lawyers-doctors-finance-hr-sales-and-more-3dfde9ec0033) |
+| Part 10 | A Day in the Life With 80 Claude Skills | [Read →](https://medium.com/@mohit15856/a-day-in-the-life-with-80-claude-skills-what-actually-gets-triggered-7caf9f5c159e) |
+| Part 11 | 10 Figma Claude Skills for PMs and Designers | [Read →](https://medium.com/@mohit15856/10-figma-claude-skills-for-pms-and-designers-the-complete-figma-toolkit-784441d07a78)|
+| Part 12 | I Built the Same Skills Library for ChatGPT — Here's What's Different | [Read →](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9) |
+| Part 13 | I Re-Tested My 90 Claude Skills on Opus 4.7 — Here's What Got Better | [Read →](https://medium.com/all-about-claude/i-re-tested-my-90-claude-skills-on-opus-4-7-heres-what-actually-got-better-dd4b9369329e)|
+| Part 14 | I Rebuilt All 93 Skills and Added 7 More: What 100 Skills Taught Me About What Makes a Great Skill | [Read →](https://medium.com/product-powerhouse/a-pull-request-made-me-rebuild-all-93-of-my-claude-skills-then-i-added-7-more-16d5fe3e7f85) |
+| Part 15 | I’m a Product Manager. I Just Shipped 6 Engineering Skills to My Open-Source Claude Library. | [Read →](https://medium.com/product-powerhouse/im-a-product-manager-i-just-shipped-6-engineering-skills-to-my-open-source-claude-library-8745aaa2ecf9) |
+| Part 16 | Anthropic Just Released 10 Agent Templates. Here’s the First One I Built Using My 106 Skills. | [Read →](https://medium.com/product-powerhouse/anthropic-just-released-10-agent-templates-heres-the-first-one-i-built-using-my-106-skills-a6708f9bd3ea) |
 
 ---
 
-## 🗂️ All 53 Skills
+## 🗂️ All 106 Skills
 
-### 🛠️ Product Management (Skills 1–33)
+### 🛠️ Product Management (Skills 1–34)
+**Bundles:** `pm-essentials` · `pm-discovery` · `pm-planning` · `pm-delivery` · `pm-analytics` · `pm-strategy` · `pm-advanced` · `pm-rituals`
 
-> The original toolkit. Discovery, prioritisation, delivery, strategy, stakeholder comms, and more.
+> The original toolkit covering the full PM lifecycle — discovery, prioritisation, delivery, strategy, stakeholder comms, and weekly rituals. Now includes Word tracked changes and PowerPoint slide auditing.
 
 | # | Skill | What It Does |
 |---|---|---|
-| 1–33 | *[Original 33 PM skills]* | See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full list |
+| 1–6 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, **Word Doc Tracked Changes** 🆕 |
+| 7–10 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
+| 11–16 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
+| 17–24 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro, **PPTX Slide Auditor** 🆕 |
+| 25–27 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
+| 28–33 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
+| 34 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |
+
+> See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full PM skills detail.
 
 ---
 
-### 📣 Marketing & Growth (Skills 34–37)
+### 📣 Marketing & GTM (Skills 35–40)
+**Bundle:** `pm-gtm`
 
 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 34 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, and role-specific use cases |
-| 35 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with hooks, formats, and repurposing map |
-| 36 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
-| 37 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
+| 35 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
+| 36 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
+| 37 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
+| 38 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
+| 39 | **SEO Content Brief** 🆕 | `skills/seo-content-brief/` | Complete SEO briefs with search intent, competitor gap analysis, content outline, and on-page requirements |
+| 40 | **Media Pitch** 🆕 | `skills/media-pitch/` | Story-first journalist pitches with angle development framework and pitch writing rules |
 
 ---
 
-### 👩‍💻 Engineering & Tech (Skills 38–41)
+### 👩‍💻 Engineering & Tech (Skills 41–54)
+**Bundle:** `pm-engineering`
 
 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 38 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
-| 39 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
-| 40 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs from raw specs: endpoints, parameters, response schemas, code examples |
-| 41 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options, decision, consequences, and risks |
+| 41 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
+| 42 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
+| 43 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs: endpoints, parameters, response schemas, code examples |
+| 44 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options considered, decision, consequences, and risks |
+| 45 | **Debugging Log Analyser** | `skills/debugging-log-analyser/` | Parse stack traces and error logs into a structured root cause diagnosis with a specific fix |
+| 46 | **PR Description Writer** | `skills/pr-description-writer/` | Write reviewer-friendly PR descriptions from a diff, commit list, or change summary |
+| 47 | **System Design Interview** | `skills/system-design-interview/` | Structure complete system design answers with capacity estimates, component deep-dives, and trade-offs |
+| 48 | **Changelog Generator** | `skills/changelog-generator/` | Convert git commits into a polished, user-facing changelog following Keep a Changelog format |
+| 49 | **Test Strategy Doc** | `skills/test-strategy-doc/` | Write a complete test strategy with risk assessment, test types, coverage targets, and P0/P1 test cases |
+| 50 | **Runbook Writer** | `skills/runbook-writer/` | Write operational runbooks for deployments, incidents, and maintenance with exact commands and rollback steps |
+| 51 | **CI/CD Playbook** 🆕 | `skills/cicd-playbook/` | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
+| 52 | **SLO & Error Budget** 🆕 | `skills/slo-error-budget/` | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
+| 53 | **Developer Onboarding Doc** 🆕 | `skills/developer-onboarding-doc/` | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
+| 54 | **On-Call Runbook** 🆕 | `skills/oncall-runbook/` | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
 
 ---
 
-### 📊 Data & Analytics (Skills 42–44)
+### 🤝 Customer Success (Skills 55–58)
+**Bundle:** `pm-cs`
+
+> 250 ⭐ milestone unlocked. Install:
+
+claude plugin install pm-cs@pm-claude-skills
+
 
 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 42 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
-| 43 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL — in plain English |
-| 44 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
+| 55 | **Customer Health Scorecard** 🆕 | `skills/cs-health-scorecard/` | Weighted health score across adoption, engagement, outcomes, support, and commercial — RAG status and renewal forecast |
+| 56 | **QBR Deck** 🆕 | `skills/qbr-deck/` | Slide-by-slide quarterly business review with talking points, value narrative, and mutual commitments |
+| 57 | **Escalation Brief** 🆕 | `skills/cs-escalation-brief/` | Structured brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
+| 58 | **Churn Analysis** 🆕 | `skills/churn-analysis/` | Churn breakdown by category and segment, early warning signals, and prioritised interventions |
 
 ---
 
-### 🧑‍💼 Leadership & Management (Skills 45–47)
+### 📊 Data & Analytics (Skills 59–62)
+**Bundle:** `pm-data`
 
 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 45 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
-| 46 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
-| 47 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
+| 59 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
+| 60 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
+| 61 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
+| 62 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
 
 ---
 
-### 🎨 Design & UX (Skills 48–50)
+### 🧑‍💼 Leadership & People (Skills 63–65)
+**Bundle:** `pm-people`
 
 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 48 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
-| 49 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
-| 50 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
+| 63 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
+| 64 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
+| 65 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
 
 ---
 
-### 🏢 Business & Strategy (Skills 51–53)
+### 🎨 Design & UX (Skills 66–68)
+**Bundle:** `pm-design`
 
 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 51 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
-| 52 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
-| 53 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
+| 66 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
+| 67 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
+| 68 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
+
+---
+
+### 🏢 Business & Strategy (Skills 69–71)
+**Bundle:** `pm-business`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 69 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
+| 70 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
+| 71 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
+
+---
+
+### ⚖️ Legal (Skills 72–75)
+**Bundle:** `pm-legal`
+
+> ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 72 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
+| 73 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
+| 74 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
+| 75 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
+
+---
+
+### 💰 Finance (Skills 76–80)
+**Bundle:** `pm-finance`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 76 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
+| 77 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
+| 78 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
+| 79 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
+| 80 | **Tax Planning Checklist** | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |
+
+---
+
+### 👥 HR (Skills 81–85)
+**Bundle:** `pm-hr`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 81 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
+| 82 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
+| 83 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
+| 84 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
+| 85 | **Change Management Plan** | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
+
+---
+
+### 🤝 Sales (Skills 86–90)
+**Bundle:** `pm-sales`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 86 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
+| 87 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
+| 88 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
+| 89 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
+| 90 | **Sales Forecasting Model** | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
+
+---
+
+### ⚙️ Operations (Skills 91–95)
+**Bundle:** `pm-operations`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 91 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
+| 92 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
+| 93 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
+| 94 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
+| 95 | **Workshop Facilitation Guide** | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
+
+---
+
+### 🏥 Research & Healthcare (Skills 96–99)
+**Bundle:** `pm-research`
+
+> ⚠️ Healthcare skills are for documentation and educational purposes only. All clinical content must be reviewed by a qualified professional.
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 96 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
+| 97 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
+| 98 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
+| 99 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
+
+---
+
+### 🌐 Cross-Profession (Skills 100–103)
+**Bundle:** `pm-cross`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 100 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
+| 101 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
+| 102 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 103 | **Teaching Lesson Plan** | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
+
+---
+
+### 🖼️ Figma (Skills 104–113)
+**Bundle:** `pm-figma`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 104 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
+| 105 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
+| 106 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
+| 107 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
+| 108 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
+| 109 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
+| 110 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
+| 111 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
+| 112 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
+| 113 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
+
+claude plugin install pm-figma@pm-claude-skills
+
+
+---
+
+### 📅 PM Rituals (Skill 114)
+**Bundle:** `pm-rituals`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 114 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
+
+---
+
+## ❤️ Sponsor This Work
+
+Building and maintaining 114 skills across 23 bundles takes real time — testing skills against new model releases, building new ones from community requests, writing the article series, and keeping documentation current.
+
+If these skills save you time at work, consider sponsoring:
+
+**[💖 Become a Sponsor →](https://github.com/sponsors/mohitagw15856)**
+
+Sponsorships from $5/month (coffee tier) up to $500/month (sustaining sponsor with logo placement). Every sponsor directly funds:
+
+- New skills based on community votes in [SKILL_REQUEST.md](SKILL_REQUEST.md)
+- Updates to existing skills when new Claude models ship
+- Continued free, ad-free Medium articles documenting what works
+- Quality improvements across the library
+
+Higher tiers include custom skill development for your team, direct access for support, and logo placement in this README. See the [sponsor page](https://github.com/sponsors/mohitagw15856) for full tier details.
 
 ---
 
@@ -119,6 +494,8 @@ This repo was built alongside a published article series. Read the full story:
 
 This is an open-source community library. If you've built a skill that saves you time, share it here.
 
+**Found a bug?** [Open a bug report →](../../issues/new?template=bug-report.md) — use the template so it's easy to triage.
+
 **How to contribute:**
 
 1. Fork this repo
@@ -129,7 +506,7 @@ This is an open-source community library. If you've built a skill that saves you
 **SKILL.md template:**
 ---
 name: your-skill-name
-description: "One sentence description. Use when [trigger condition]. Does [output description]."
+description: "One sentence. Use when [trigger condition]. Produces [output description]."
 ---
 
 # Skill Title
@@ -144,35 +521,113 @@ description: "One sentence description. Use when [trigger condition]. Does [outp
 - Works without needing extensive setup or context
 
 **Skills wishlist** (most requested — up for grabs):
-- `legal-contract-review` — Flag key clauses and risks in contracts
-- `financial-model-narrative` — Turn a spreadsheet into a board-ready narrative
-- `hr-job-description` — Write inclusive, structured JDs from a role brief
-- `onboarding-plan` — 30/60/90-day plan for new hires
-- `press-release` — Structured press releases from product announcements
-- `seo-content-brief` — Content briefs with keyword strategy and outline
 
-Have a skill idea? [Open an issue](../../issues) or raise it in [Discussions](../../discussions).
+| Skill | Profession | Use Case |
+|---|---|---|
+| `grant-report` | Non-profit | Funder progress reports against grant objectives |
+| `architectural-spec` | Architecture | Project specifications and technical drawing briefs |
+| `clinical-guideline-summary` | Healthcare | Plain English summaries of clinical guidelines |
+| `pitch-deck-feedback` | Startup | Investor-perspective critique of a pitch deck |
+| `board-minutes` | Governance | Formal board meeting minutes from discussion notes |
+
+Have a skill idea? Add it to [SKILL_REQUEST.md](SKILL_REQUEST.md), [open an issue](../../issues), or raise it in [Discussions](../../discussions). Most-voted requests get built first.
 
 **Contributors** get credited in this README and in the article series. 🙌
 
 ---
 
+## 📦 All Plugin Bundles
+
+Install the whole library or just the bundles you need:
+
+# Install everything
+/plugin marketplace add mohitagw15856/pm-claude-skills
+
+# Install by profession
+claude plugin install pm-essentials@pm-claude-skills
+claude plugin install pm-discovery@pm-claude-skills
+claude plugin install pm-planning@pm-claude-skills
+claude plugin install pm-delivery@pm-claude-skills
+claude plugin install pm-analytics@pm-claude-skills
+claude plugin install pm-strategy@pm-claude-skills
+claude plugin install pm-advanced@pm-claude-skills
+claude plugin install pm-rituals@pm-claude-skills
+claude plugin install pm-gtm@pm-claude-skills
+claude plugin install pm-engineering@pm-claude-skills    # 14 engineering skills 🆕
+claude plugin install pm-cs@pm-claude-skills             # Customer Success (4 skills) 🆕
+claude plugin install pm-data@pm-claude-skills
+claude plugin install pm-people@pm-claude-skills
+claude plugin install pm-design@pm-claude-skills
+claude plugin install pm-business@pm-claude-skills
+claude plugin install pm-legal@pm-claude-skills
+claude plugin install pm-finance@pm-claude-skills
+claude plugin install pm-hr@pm-claude-skills
+claude plugin install pm-sales@pm-claude-skills
+claude plugin install pm-operations@pm-claude-skills
+claude plugin install pm-research@pm-claude-skills
+claude plugin install pm-cross@pm-claude-skills
+claude plugin install pm-figma@pm-claude-skills
+
+
+---
+
+## 🤖 Companion Repository — ChatGPT Custom GPTs
+
+If you use ChatGPT instead of Claude Code, there's a companion repo with the same professional frameworks built as Custom GPT system prompts:
+
+**[professional-gpt-library](https://github.com/mohitagw15856/professional-gpt-library)** — 10 starter GPTs across 8 professions, MIT licence.
+
+Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGPT](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9)
+
+---
+
+## 🛠️ Custom Skills for Your Team
+
+The 106 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
+
+**What custom skills look like in practice:**
+
+- A law firm's contract review skill trained on their specific clause library and risk tolerance
+- A SaaS company's sprint brief skill that knows their engineering conventions and definition of done
+- A finance team's board pack skill that follows their exact narrative structure and slide format
+- An HR team's job description skill that reflects their values language and includes their specific benefits
+
+The difference between a generic skill and one built for your context is significant. Generic skills eliminate the blank page. Custom skills eliminate the rework.
+
+**If you want skills built for your team's specific workflows — [get in touch](mailto:mohit15856@gmail.com).**
+
+Include a brief description of your team, the workflows you want to automate, and the tools you use. I'll come back to you within 48 hours.
+
+---
+
 ## 📖 How Skills Work
 
-Skills are markdown files in `~/.claude/skills/` that Claude reads dynamically. When you describe a task, Claude scans available skill descriptions (~100 tokens) and loads the full skill only when it's relevant. This means:
+Skills are markdown files that Claude reads dynamically. When you describe a task, Claude scans available skill descriptions (~100 tokens) and loads the full skill only when relevant. This means:
 
 - Skills are efficient — they only use tokens when triggered
 - Multiple skills can coexist without slowing Claude down
 - Personal skills (`~/.claude/skills/`) work across all your projects
+- Plugin skills install via the Claude Code marketplace with one command
 
 Learn more: [Anthropic's Skills documentation](https://code.claude.com/docs/en/skills)
 
 ---
 
-## ⭐ If this is useful
+## ⭐ Star Milestones
 
-Star the repo so others can find it. And if you build something with these skills, share it — raise a PR, open a discussion, or tag me in your article.
+Stars unlock the next wave of skills. Here's the roadmap:
+
+| Milestone | Unlocks | Status |
+|---|---|---|
+| 100 ⭐ | 10 Figma skills + quality rebuild across all 93 skills | ✅ Shipped (v6.0.0) |
+| 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) | ✅ Unlocked — coming in next release |
+| 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns) | ✅ Unlocked — coming in next release |
+| 1000 ⭐ | Full Startup Founder kit (fundraising memo, pitch critique, co-founder equity split) | 🔒 Locked |
+
+**[⭐ Star this repo to unlock the next milestone →](https://github.com/mohitagw15856/pm-claude-skills)**
+
+Want a specific skill built? [Vote or request in SKILL_REQUEST.md](SKILL_REQUEST.md).
 
 ---
 
-*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Powerhouse publication](https://medium.com/product-powerhouse)*
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Notes publication](https://medium.com/product-powerhouse) | [💖 Sponsor my work](https://github.com/sponsors/mohitagw15856)*

SECURITY.md

@@ -0,0 +1,55 @@
+# Security Policy
+
+## Overview
+
+This repository contains Claude Skill files — plain markdown instruction files that teach Claude how to perform professional tasks. There are no backend services, APIs, authentication systems, or databases in this repo.
+
+That said, security matters here in two specific ways: **skill file safety** and **prompt injection risks**.
+
+## Supported Versions
+
+| Version | Supported |
+|---|---|
+| v4.0.0 (latest) | ✅ Active |
+| v3.0.0 | ✅ Security fixes only |
+| < v3.0.0 | ❌ No longer supported |
+
+## Skill File Safety
+
+All skills in this repo are reviewed before merging to ensure they:
+
+- Do not contain instructions designed to manipulate Claude into ignoring its guidelines
+- Do not attempt prompt injection (e.g. hidden instructions to override system behaviour)
+- Do not instruct Claude to request, store, or transmit personal or sensitive data
+- Do not contain malicious commands disguised as skill instructions
+- Do not include hardcoded credentials, API keys, or personally identifiable information
+
+**If you are installing skills from this repo:** skills are plain text markdown files. They do not execute code, make network requests, or access your file system on their own. Review any skill file before installing if you have concerns.
+
+## Reporting a Vulnerability
+
+If you discover a skill file in this repo that contains malicious instructions, a prompt injection attempt, or any content that could cause harm to users of Claude Code, please report it **privately** before raising a public issue.
+
+**How to report:**
+
+Email: **mohit15856@gmail.com**
+Subject line: `[SECURITY] pm-claude-skills — <brief description>`
+
+Include:
+- The skill file path (e.g. `plugins/pm-gtm/skills/go-to-market/SKILL.md`)
+- A description of the issue
+- Why you believe it is a security concern
+
+**Response time:** You will receive an acknowledgement within 48 hours and a resolution or update within 7 days.
+
+Please do not open a public GitHub Issue for security vulnerabilities — use the email above. Public disclosure before a fix is in place puts other users at risk.
+
+## Community Contributions
+
+All pull requests adding new skill files are reviewed for the safety criteria listed above before merging. If you are submitting a skill, ensure it:
+
+- Only contains instructions relevant to the stated professional workflow
+- Does not include any attempt to override Claude's built-in guidelines
+- Does not ask Claude to collect or relay user data
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for full contribution guidelines.

SKILL_REQUEST.md

@@ -0,0 +1,65 @@
+# Skill Requests — Community Voting Board
+
+Have an idea for a skill? Add it here or upvote existing requests by leaving a 👍 reaction on the issue.
+
+---
+
+## How to Request a Skill
+
+1. [Open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues/new) with the label `skill-request`
+2. Include:
+   - **Skill name** (what you'd call it)
+   - **Profession** (who uses this)
+   - **Trigger** (when would you invoke it — e.g. "when I need to write X")
+   - **Output** (what should Claude produce)
+3. Drop a 👍 on existing requests you'd use — most-voted get built first
+
+---
+
+## Milestone Unlocks
+
+Stars drive the roadmap. Here's what's queued:
+
+| Milestone | Unlocks |
+|---|---|
+| ✅ 100 ⭐ | 10 Figma skills + quality rebuild across all skills (v6.0.0) |
+| 🔒 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) |
+| 🔒 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, debugging deep-dives, onboarding docs, SLO templates) |
+| 🔒 1000 ⭐ | Full Startup Founder kit (fundraising memo, pitch critique, co-founder agreement framework) |
+
+**[Star this repo →](https://github.com/mohitagw15856/pm-claude-skills)**
+
+---
+
+## Requested Skills (Open)
+
+Add a request by opening an issue — these are current top asks from the community:
+
+| Skill | Profession | Requested By | Votes |
+|---|---|---|---|
+| `customer-health-scorecard` | Customer Success | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `qbr-deck-writer` | Customer Success | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `escalation-brief` | Customer Success | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `fundraising-memo` | Startup / Founder | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `youtube-script-writer` | Content Creator | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `newsletter-issue-writer` | Content Creator | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `analytics-event-taxonomy` | Data / Analytics | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `kpi-tree-builder` | Data / Analytics | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `dissertation-chapter-planner` | Academic | [@mohitagw15856](https://github.com/mohitagw15856) | — |
+| `board-minutes` | Governance | Community | — |
+
+> **To vote:** React with 👍 on the linked issue. To add a new request, open an issue with label `skill-request`.
+
+---
+
+## Recently Shipped
+
+| Version | Skills Added |
+|---|---|
+| v7.0.0 | Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer |
+| v6.0.0 | Teaching Lesson Plan, SEO Content Brief, Media Pitch, Change Management Plan, Workshop Facilitation Guide, Sales Forecasting Model, Tax Planning Checklist |
+| v5.0.0 | 10 Figma skills |
+
+---
+
+*Maintained by [Mohit Aggarwal](https://github.com/mohitagw15856)*

create-plugin-jsons.sh

@@ -1,180 +0,0 @@
-#!/bin/bash
-
-# =============================================================================
-# create-plugin-jsons.sh
-# Run this from the ROOT of your pm-claude-skills repo.
-# Creates .claude-plugin/plugin.json inside each of the 6 new plugin folders.
-# Your skills/ subfolders are already in place — this just adds the missing
-# plugin.json files.
-# =============================================================================
-
-set -e
-
-REPO_ROOT="$(pwd)"
-
-echo "================================================"
-echo " pm-claude-skills — Creating plugin.json files"
-echo " Running from: $REPO_ROOT"
-echo "================================================"
-echo ""
-
-# Sanity check — make sure we're in the right place
-if [ ! -d "$REPO_ROOT/pm-gtm" ] || [ ! -d "$REPO_ROOT/pm-engineering" ]; then
-  echo "ERROR: Cannot find pm-gtm or pm-engineering folders."
-  echo "Make sure you are running this from the ROOT of your pm-claude-skills repo."
-  echo "Example: cd ~/pm-claude-skills && bash create-plugin-jsons.sh"
-  exit 1
-fi
-
-# ---------------------------------------------------------
-# BUNDLE 1: pm-gtm
-# ---------------------------------------------------------
-echo "Creating pm-gtm/.claude-plugin/plugin.json..."
-mkdir -p pm-gtm/.claude-plugin
-cat > pm-gtm/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-gtm",
-  "version": "1.0.0",
-  "description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign. Build positioning statements, messaging pillars, feature lists, use cases, and launch campaigns.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "marketing", "gtm", "positioning", "content-calendar", "competitor-analysis", "email-campaign"]
-}
-EOF
-echo "  ✓ pm-gtm/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 2: pm-engineering
-# ---------------------------------------------------------
-echo "Creating pm-engineering/.claude-plugin/plugin.json..."
-mkdir -p pm-engineering/.claude-plugin
-cat > pm-engineering/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-engineering",
-  "version": "1.0.0",
-  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record. Structured outputs for engineering teams and technical PMs.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture"]
-}
-EOF
-echo "  ✓ pm-engineering/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 3: pm-data
-# ---------------------------------------------------------
-echo "Creating pm-data/.claude-plugin/plugin.json..."
-mkdir -p pm-data/.claude-plugin
-cat > pm-data/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-data",
-  "version": "1.0.0",
-  "description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief. Build North Star metric trees, explain and optimise SQL, and spec dashboards from business questions.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "data", "analytics", "metrics", "north-star", "sql", "dashboard", "kpi"]
-}
-EOF
-echo "  ✓ pm-data/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 4: pm-people
-# ---------------------------------------------------------
-echo "Creating pm-people/.claude-plugin/plugin.json..."
-mkdir -p pm-people/.claude-plugin
-cat > pm-people/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-people",
-  "version": "1.0.0",
-  "description": "Leadership & people skills: Performance Review, Hiring Rubric, Team Offsite Planner. Write structured reviews, build interview scorecards, and plan offsites from goals to minute-by-minute agenda.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "leadership", "management", "performance-review", "hiring", "interview", "offsite", "people"]
-}
-EOF
-echo "  ✓ pm-people/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 5: pm-design
-# ---------------------------------------------------------
-echo "Creating pm-design/.claude-plugin/plugin.json..."
-mkdir -p pm-design/.claude-plugin
-cat > pm-design/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-design",
-  "version": "1.0.0",
-  "description": "Design & UX skills: UX Research Plan, Design Critique, Accessibility Audit. Create research plans with discussion guides, critique designs using JTBD and Gestalt principles, and audit for WCAG 2.2 compliance.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "design", "ux", "user-research", "accessibility", "wcag", "usability", "design-critique"]
-}
-EOF
-echo "  ✓ pm-design/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 6: pm-business
-# ---------------------------------------------------------
-echo "Creating pm-business/.claude-plugin/plugin.json..."
-mkdir -p pm-business/.claude-plugin
-cat > pm-business/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-business",
-  "version": "1.0.0",
-  "description": "Business & strategy skills: Investor Update, Board Deck Narrative, Job Application. Write investor updates investors actually read, structure board presentations, and tailor CVs and cover letters with ATS optimisation.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "business", "strategy", "investor-update", "board-deck", "startup", "career", "job-application"]
-}
-EOF
-echo "  ✓ pm-business/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# DONE
-# ---------------------------------------------------------
-echo ""
-echo "================================================"
-echo " All 6 plugin.json files created successfully!"
-echo ""
-echo "  pm-gtm/.claude-plugin/plugin.json"
-echo "  pm-engineering/.claude-plugin/plugin.json"
-echo "  pm-data/.claude-plugin/plugin.json"
-echo "  pm-people/.claude-plugin/plugin.json"
-echo "  pm-design/.claude-plugin/plugin.json"
-echo "  pm-business/.claude-plugin/plugin.json"
-echo ""
-echo " Next steps:"
-echo "  1. bash add-plugin-json.sh   (update marketplace.json)"
-echo "  2. git add ."
-echo "  3. git commit -m 'feat: add 6 new plugin bundles (pm-gtm, pm-engineering, pm-data, pm-people, pm-design, pm-business)'"
-echo "  4. git push origin main"
-echo "================================================"

examples/pm-figma-example.md

@@ -0,0 +1,136 @@
+# Examples: pm-figma Skills
+
+## What this bundle does
+10 Figma skills covering the full design lifecycle for product managers and designers — from planning what to design, through building components and prototypes, to QA before handoff.
+
+---
+
+## figma-component-audit
+
+### Example 1 — Messy legacy library
+
+**You say:**
+> "Audit our Figma component library. We have buttons, inputs, cards, modals, and navigation components but the naming is all over the place and developers keep asking for states we haven't designed."
+
+**Claude produces:**
+
+**Audit Summary**
+
+| Dimension | Status | Score |
+|---|---|---|
+| Naming consistency | 🔴 Poor | 3/10 |
+| Component coverage | 🟡 Partial | 6/10 |
+| Variant completeness | 🔴 Poor | 4/10 |
+| Overall health | 🟡 Partial | 5/10 |
+
+**Issue: Mixed capitalisation conventions**
+- What's happening: `button-primary`, `Button/Primary`, `btn_primary` all exist in the same library
+- Fix: Adopt PascalCase for components (`Button`), lowercase slash-separated for variants (`type/primary`, `size/large`, `state/default`)
+- Before: `btn_primary_large_hover` → After: `Button` with variants `type/primary`, `size/large`, `state/hover`
+
+**Missing states developers are asking for:**
+| Component | Missing | Priority |
+|---|---|---|
+| Button | Active/pressed state | 🔴 High |
+| Input | Error state with helper text | 🔴 High |
+| Card | Skeleton loading state | 🟡 Medium |
+
+---
+
+## figma-design-brief
+
+### Example 1 — PRD to design brief
+
+**You say:**
+> "Write a design brief for our new notification preferences feature. Users need to control which emails and push notifications they receive. Platform is iOS and Android. We need design ready in 2 weeks."
+
+**Claude produces:**
+
+**Feature:** Notification Preferences
+**Platform:** iOS + Android | **Design due:** [2 weeks from today] | **Dev handoff:** [3 weeks]
+
+**The goal:** Users can control their notification preferences without contacting support.
+
+**Success looks like:** >80% of users who visit settings can update their preferences without a support ticket.
+
+**Flows to design:**
+1. Entry from Settings > Notifications
+2. Toggle individual notification types on/off
+3. Save preferences with confirmation
+4. Error state if save fails
+
+**Missing from current brief — open questions:**
+- [ ] Are email and push controlled separately or together? (PM to confirm)
+- [ ] What's the default state for new users? (PM to confirm)
+
+---
+
+## figma-design-qa
+
+### Example 1 — Pre-handoff check
+
+**You say:**
+> "QA the checkout flow design before we hand it off to engineering. Web, using our custom design system, standard 30-minute QA."
+
+**Claude produces:**
+
+**Design QA Report: Checkout Flow**
+**Overall status:** 🟡 Minor fixes needed
+
+**Section 1: File Hygiene**
+- All layers named semantically ✅
+- No unused layers ✅
+- Components from library ❌ — Order summary card is a detached copy
+- Text uses text styles ✅
+- Colours use variables ❌ — Button label in step 3 uses hardcoded #FFFFFF instead of `color.text.on-primary`
+
+**Issues Found:**
+- **Detached card component — 🟡 Fix before handoff**
+  - What: Order summary card (frame "Step 2 / Summary") is not linked to library
+  - Fix: Re-attach to `Card/Summary` library component
+  - Owner: Designer
+
+---
+
+## figma-design-critique-pm
+
+### Example 1 — PM reviewing a dashboard design
+
+**You say:**
+> "Give me a PM critique of our new analytics dashboard design. User goal is to understand their campaign performance at a glance. Business goal is to reduce support tickets about 'why are my numbers down'."
+
+**Claude produces:**
+
+**PM Critique Summary**
+Verdict: 🟡 Mostly on track with one significant gap
+
+"The design successfully surfaces the top-line metrics above the fold and the date range selector is prominent. However, the design currently shows no contextual explanation for metric changes — a user whose conversions dropped 40% last week will still need to contact support because there's nothing in the design helping them understand why."
+
+**Goal Alignment Check:**
+| Goal | Status | Evidence |
+|---|---|---|
+| Understand performance at a glance | ✅ Yes | Top 4 KPIs are above fold, well-contrasted |
+| Reduce "why are my numbers down" tickets | 🟡 Partial | Metrics shown but no context or anomaly explanation |
+
+**PM Feedback:**
+**Missing: Metric change context — 🔴 High impact**
+- Observation: Metric cards show current value and % change vs prior period but no explanation of what drove the change
+- User impact: A user seeing -40% conversions still has no information to act on without contacting support
+- Business impact: Does not address the core support ticket driver — the "why"
+- Evidence basis: Hypothesis (we should validate with support ticket analysis)
+- Question for designer: Is there data available to surface top contributing factors? Even "top declining campaign" would help.
+
+---
+
+## Tips for best results
+
+- For `figma-design-brief`: paste the actual PRD snippet or ticket — the more specific the requirement, the more useful the brief
+- For `figma-design-qa`: describe the platform and design system explicitly — the checklist adapts to iOS vs Android vs Web
+- For `figma-design-critique-pm`: always state the business metric — without it, feedback stays generic
+- For `figma-variant-matrix`: name the component exactly as it will appear in Figma — Claude uses this for layer naming recommendations
+- For `figma-user-flow-planner`: state the starting point and user type — these determine which edge cases are most likely
+
+## Related skills
+- `design-critique` — General UX critique using Gestalt and Nielsen heuristics (pm-design bundle)
+- `ux-research-plan` — Full research plan for user testing (pm-design bundle)
+- `figma-prototype-plan` — Plan what to prototype before building it (this bundle)

plugins/create-plugin-json-pm-figma.sh

@@ -0,0 +1,36 @@
+#!/bin/bash
+
+# =============================================================================
+# create-plugin-json-pm-figma.sh
+# Run from the ROOT of your pm-claude-skills repo.
+# Creates the .claude-plugin/plugin.json for the pm-figma bundle.
+# =============================================================================
+
+set -e
+
+if [ ! -d "$(pwd)/plugins" ]; then
+  echo "ERROR: Run from the root of pm-claude-skills"
+  exit 1
+fi
+
+mkdir -p plugins/pm-figma/.claude-plugin
+
+cat > plugins/pm-figma/.claude-plugin/plugin.json << 'EOF'
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-figma",
+  "version": "1.0.0",
+  "description": "Figma skills for product managers and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter in Figma across the full design lifecycle.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["figma", "design", "product-management", "design-system", "components", "prototype", "handoff", "ux"]
+}
+EOF
+
+echo "✓ plugins/pm-figma/.claude-plugin/plugin.json created"
+echo ""
+echo "Next: run setup-pm-figma.sh then update-marketplace.sh"

plugins/pm-advanced/skills/ai-product-canvas/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ai-product-canvas
-description: Structures AI and ML product decisions including model selection, data requirements, evaluation frameworks, and responsible AI considerations. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Triggers on "AI product", "LLM feature", "AI canvas", "build with AI", "AI integration", "AI-powered", "machine learning feature".
+description: "Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan."
 ---
 
 # AI Product Canvas Skill
@@ -143,3 +143,19 @@ Before building, flag if any of these apply:
 - Responsible AI checklist must be completed before launch, not after
 - Include latency in success metrics — a 5-second AI response is often worse than no AI at all
 - Recommend starting with a human-in-the-loop design and automating only when accuracy is proven
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature or product description** (what the AI is intended to do)
+- **User problem** (what problem the AI is solving for users)
+- **Available data** (what training/inference data exists)
+- **ML/AI lead** (who owns the technical implementation)
+
+## Quality Checks
+
+- [ ] "Why AI?" is answered clearly (not "because we can")
+- [ ] Minimum acceptable accuracy threshold is defined before build begins
+- [ ] Fallback UX is specified for model failures or low-confidence outputs
+- [ ] Responsible AI checklist is completed (not deferred to post-launch)
+- [ ] Monitoring plan includes both model performance and user engagement metrics

plugins/pm-advanced/skills/design-handoff-brief/SKILL.md

@@ -1,13 +1,20 @@
 ---
 name: design-handoff-brief
-description: Transform feature briefs into structured design briefs that give designers the context they need
-tool_integration: Figma, Notion
+description: "Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries."
 ---
+
 # Design Handoff Brief Skill
 
-## Purpose
 Produce a design brief that sets designers up for success — grounding them in user context and constraints before they open Figma, not after they've gone in the wrong direction.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature brief or PRD** (even rough notes work)
+- **Designer's name or team** (for personalisation)
+- **Technical constraints** (any engineering limitations already known)
+- **Timeline** (when does design need to be done?)
+
 ## What Designers Actually Need (and PMs Often Skip)
 - The user's goal, not the feature name
 - The emotional state of the user at this moment in the journey
@@ -23,8 +30,9 @@ Produce a design brief that sets designers up for success — grounding them in
 4. List edge cases the design must handle
 5. Define success criteria the design should be evaluated against
 6. Write a "not in scope" section to prevent scope creep in design
+7. **Validate** — Confirm every edge case listed is specific enough to design for, and every out-of-scope item is concrete enough to say "no" to
 
-## Output Format
+## Output Structure
 
 ### Design Brief: [Feature Name]
 
@@ -57,3 +65,11 @@ Produce a design brief that sets designers up for success — grounding them in
 - User research: [link]
 - Existing patterns: [Figma component library link]
 - Competitor examples: [links if relevant]
+
+## Quality Checks
+
+- [ ] User goal is written in user language (not feature/product language)
+- [ ] At least one edge case covers an error or failure state
+- [ ] Success criteria are measurable or observable (not "looks good")
+- [ ] Out-of-scope section names at least one thing that might seem in scope but isn't
+- [ ] Technical constraints are specific enough for an engineer to confirm

plugins/pm-advanced/skills/experiment-designer/SKILL.md

@@ -1,55 +1,69 @@
 ---
 name: experiment-designer
-description: Designs A/B tests from hypotheses and interprets experiment results 
-with statistical rigour. Use when user says "run an experiment", "design an A/B 
-test", "test this feature", "interpret these results", "was this experiment 
-successful", or "what sample size do I need".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: data-and-metrics
-  tags: [experimentation, data, analytics, ab-testing]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation."
 ---
+
 # Experiment Designer Skill
 
-## Purpose
-Produce rigorous experiment designs from product hypotheses, and interpret 
-results with statistical and practical significance — so you can defend every 
-decision to a sceptical engineering lead or data scientist.
+Produce rigorous experiment designs from product hypotheses, and interpret results with statistical and practical significance — so you can defend every decision to a sceptical engineering lead or data scientist.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+**For experiment design:**
+- Hypothesis (what change, what metric, what expected movement)
+- Current baseline metric value
+- Minimum detectable effect (MDE) — the smallest lift worth caring about
+- Available daily sample size
+
+**For results interpretation:**
+- Control and variant results (raw numbers or percentages)
+- P-value or confidence interval
+- Run duration (days)
+- Any anomalies observed during the test
 
 ## Two-Phase Process
 
 ### Phase 1: Experiment Design
-**Required inputs:** hypothesis, primary metric, current baseline, minimum 
-detectable effect (MDE), available sample size per day.
-
-**Output:**
-- Hypothesis restated as: "If we [change], we expect [metric] to [move by X%] 
-  because [reason]"
-- Control and variant definitions
-- Primary metric (one only)
-- Secondary guardrail metrics (2-3 max)
-- Required sample size (calculated from MDE and baseline)
-- Estimated run time in days
-- Pre-defined success criteria (before the test runs — no moving goalposts)
-- Design risk flags: novelty effects, seasonal confounds, multiple testing issues,
-  network effects, sample ratio mismatch risks
+1. Restate hypothesis as: "If we [change], we expect [metric] to [move by X%] because [reason]"
+2. Define control and variant clearly
+3. Select primary metric (one only) and secondary guardrail metrics (2-3 max)
+4. Calculate required sample size from MDE and baseline
+5. Estimate run time in days
+6. Set pre-defined success criteria before the test runs — no moving goalposts
+7. Flag design risks: novelty effects, seasonal confounds, multiple testing issues, network effects, sample ratio mismatch
 
 ### Phase 2: Results Interpretation
-**Required inputs:** control results, variant results, p-value or raw numbers, 
-run duration, any anomalies observed.
+1. Assess statistical significance (p < 0.05 threshold)
+2. Assess practical significance: was the lift meaningful for the business, not just real?
+3. Interpret confidence intervals
+4. Investigate confounding factors
+5. Recommend: Ship / Iterate / Kill / Run follow-up test
+6. **Validate** — Confirm the test ran for the full planned duration. Flag if it was stopped early (peeking problem). Confirm sample ratio mismatch did not occur.
 
-**Output:**
-- Statistical significance assessment (p < 0.05 threshold)
-- Practical significance: was the lift meaningful for the business, not just real?
-- Confidence interval interpretation
-- Confounding factors to investigate
-- Recommendation: Ship / Iterate / Kill / Run follow-up test
-- If "Iterate": specific hypotheses to test next
+## Output Structure
+
+**[Design or Results header based on phase]**
+
+*Hypothesis:* "If we [change], we expect [metric] to [move by X%] because [reason]"
+
+*Primary metric:* [One metric only]
+*Guardrail metrics:* [2-3 max]
+*Required sample size:* [n per variant]
+*Estimated run time:* [days]
+*Pre-defined success threshold:* [specific number]
+*Design risk flags:* [any concerns]
+
+**Results (Phase 2 only):**
+*Statistical significance:* [p-value and conclusion]
+*Practical significance:* [lift size vs. business threshold]
+*Recommendation:* Ship / Iterate / Kill / Follow-up — [rationale]
 
 ## Quality Checks
-- Never interpret results from an underpowered test without flagging it
-- Always distinguish statistical from practical significance
-- Flag if test was stopped early (peeking problem)
-- Note if sample ratio mismatch occurred
+
+- [ ] Hypothesis specifies the change, the metric, the direction, and the reason
+- [ ] Primary metric is singular — guardrail metrics are secondary
+- [ ] Success criteria are defined before the test launches (not after seeing results)
+- [ ] Test was not stopped early (or flagged clearly if it was)
+- [ ] Practical significance assessed separately from statistical significance
+- [ ] Sample ratio mismatch is checked in results interpretation

plugins/pm-advanced/skills/multi-source-signal-synthesiser/SKILL.md

@@ -1,62 +1,62 @@
 ---
 name: multi-source-signal-synthesiser
-description: Synthesises user signals from multiple research sources into a 
-unified insight brief, reconciling conflicting feedback. Use when user has data 
-from multiple sources, needs to "make sense of all this user data", "what are 
-users really telling us", "synthesise our research", or has conflicting feedback 
-from different channels.
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: discovery
-  tags: [user-research, synthesis, discovery, insights]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Synthesise user signals from multiple research sources into a unified insight brief, reconciling conflicting feedback. Use when asked to make sense of data from multiple sources, synthesise user research, reconcile conflicting feedback, or when the user says 'what are users really telling us' or 'make sense of all this user data'. Produces ranked insights with confidence ratings, divergent signal analysis, and research gap identification."
 ---
+
 # Multi-Source Signal Synthesiser Skill
 
-## Purpose
-Reconcile user signals from multiple sources — interviews, support tickets, NPS, 
-app reviews, sales calls — into a unified, weighted insight brief that surfaces 
-the underlying need rather than the surface-level request.
+Reconcile user signals from multiple sources — interviews, support tickets, NPS, app reviews, sales calls — into a unified, weighted insight brief that surfaces the underlying need rather than the surface-level request.
 
-## Source Weighting (default — adapt to your context)
-- Direct research (interviews, usability tests): weight 5
-- Support tickets (unprompted pain signals): weight 4
-- NPS verbatims: weight 3
-- App store reviews: weight 2
-- Sales call summaries (filtered through sales lens): weight 2
-- Anecdote or single report: weight 1
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Signal sources** (interviews, support tickets, NPS verbatims, app reviews, sales calls, analytics — any combination)
+- **Time period** covered by the data
+- **Product area or feature** the signals relate to (if scoped)
+
+## Source Weighting (default — adapt to context)
+
+| Source | Weight | Rationale |
+|--------|--------|-----------|
+| Direct research (interviews, usability tests) | 5 | Highest-fidelity, structured |
+| Support tickets (unprompted pain signals) | 4 | Real pain, unfiltered |
+| NPS verbatims | 3 | Broad but shallow |
+| App store reviews | 2 | Public, self-selected |
+| Sales call summaries | 2 | Filtered through sales lens |
+| Anecdote or single report | 1 | Low confidence alone |
 
 ## Process
-1. Accept inputs from any combination of the source types above
-2. Tag each signal by source and apply weight
-3. Look for CONVERGENCE: same underlying need appearing across 3+ sources
-4. Look for DIVERGENCE: contradictory signals suggesting user segmentation
-5. Distinguish surface request from underlying need
-   (e.g. "faster export" may mean "I don't trust the data will be there when 
-   I need it")
-6. Produce ranked insights by weighted frequency
+1. Tag each signal by source and apply weight
+2. Look for **convergence**: same underlying need appearing across 3+ sources
+3. Look for **divergence**: contradictory signals suggesting user segmentation
+4. Distinguish surface request from underlying need (e.g. "faster export" may mean "I don't trust the data will be there when I need it")
+5. Produce ranked insights by weighted frequency
+6. **Validate** — Confirm each insight has evidence from at least 2 source types. Flag any insight resting on a single source as low-confidence.
 
-## Output Format
+## Output Structure
 
 ### User Signal Synthesis — [Date / Period]
-**Sources included:** [list]
+**Sources included:** [list with count per source]
 **Total signals processed:** [n]
 
 #### Insight 1: [Underlying need, not feature request]
 - **Confidence:** High / Medium / Low (based on source diversity and weight)
 - **Evidence:** [Signals from each source supporting this]
 - **Conflicting signals:** [Any contradicting evidence and how to interpret it]
-- **Product implication:** [Specific, not generic]
+- **Product implication:** [Specific next step, not generic]
 
 [Repeat for top 3-5 insights]
 
 #### Divergent Signals (Possible Segmentation)
-[Where user groups appear to have genuinely different needs]
+[Where user groups appear to have genuinely different needs — specify which segments]
 
 #### What the Data Does NOT Tell Us
 [Gaps that require further research before acting]
 
-## OpenClaw Configuration
-Connect to: Notion (research docs), support inbox, NPS tool, app review feed.
-Schedule: weekly synthesis run, diff output showing new signals only.
+## Quality Checks
+
+- [ ] Every insight references at least 2 distinct source types
+- [ ] Surface requests are translated to underlying needs (not just echoed)
+- [ ] Divergent signals identify the specific user segments, not just "some users disagree"
+- [ ] Confidence ratings are consistent with source diversity and weighting
+- [ ] "What the data does NOT tell us" section is honest about gaps

plugins/pm-analytics/skills/data-analysis-standard/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: data-analysis-standard
-description: Structures product data analysis, metric deep-dives, funnel analysis, and cohort studies. Use when asked to analyse product metrics, investigate a drop in conversion, build a dashboard spec, or explain data to stakeholders. Triggers on "analyse metrics", "funnel analysis", "cohort analysis", "data deep dive", "why did X drop".
+description: "Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action."
 ---
 
 # Data Analysis Standard Skill
@@ -100,6 +100,23 @@ Output a cohort retention table and annotate:
 
 ---
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Metric or question** being investigated
+- **Time period** (what changed, from when to when)
+- **Data available** (which segments, sources, or queries you have access to)
+- **Business context** (what decision this analysis informs)
+- **Audience** (who will read this — exec / team / data team)
+
+## Quality Checks
+
+- [ ] Analysis answers all 4 questions: what changed, why, so what, now what
+- [ ] Root cause has evidence (not just hypothesis)
+- [ ] Confidence level is stated and justified
+- [ ] What the data cannot tell us is explicitly named
+- [ ] Recommended action includes an owner and timeline
+
 ## Guidelines
 
 - Always state what the data *cannot* tell you — never oversell confidence

plugins/pm-analytics/skills/product-health-analysis/SKILL.md

@@ -1,13 +1,20 @@
 ---
 name: product-health-analysis
-description: Interpret product metrics against goals and surface actionable signals
-tool_integration: Google Analytics, Mixpanel
+description: "Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions."
 ---
-# Product Health Dashboard Skill
 
-## Purpose
+# Product Health Analysis Skill
+
 Transform raw metrics data into a clear health narrative — what's working, what's not, and what needs immediate attention.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Metrics data** (current values for key metrics — even rough numbers work)
+- **Targets or benchmarks** (OKR targets, historical baselines, or industry benchmarks)
+- **Period** (week / month / quarter being analysed)
+- **Product area or segment** (are we looking at the whole product or a specific feature?)
+
 ## Metrics Framework
 Analyse across four layers:
 1. **Acquisition** — new users, source quality, CAC trends
@@ -21,8 +28,9 @@ Analyse across four layers:
 3. Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
 4. Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
 5. Recommend top 3 areas for immediate investigation with suggested diagnostic steps
+6. **Validate** — Confirm every flagged metric has a plausible root cause hypothesis, not just a raw number, and every recommended action has a specific owner or team
 
-## Output Format
+## Output Structure
 
 ### Product Health Report — [Period]
 **Overall Health:** 🟢 On Track / 🟡 Watch / 🔴 Action Required
@@ -41,3 +49,11 @@ Analyse across four layers:
 
 **Recommended Actions:**
 [Specific next steps with owners and timelines]
+
+## Quality Checks
+
+- [ ] Every metric includes both a target and a trend (not just a snapshot)
+- [ ] At least one correlation is drawn between metrics (e.g., activation → retention)
+- [ ] Every flagged metric has a root cause hypothesis, not just "it dropped"
+- [ ] Observations are written for a non-technical stakeholder (no raw query language or data jargon)
+- [ ] Overall health rating is justified with specific evidence

plugins/pm-analytics/skills/retention-analysis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: retention-analysis
-description: Structures retention analysis, churn investigations, and engagement deep-dives for product teams. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Triggers on "retention analysis", "churn", "DAU/MAU", "user retention", "why are users leaving".
+description: "Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions."
 ---
 
 # Retention Analysis Skill
@@ -108,6 +108,24 @@ Users who [specific action] in first [N] days retain at [X%] vs [Y%] for those w
 
 ---
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product and business model** (SaaS / consumer app / marketplace / other)
+- **Current retention metrics** (D1, D7, D30 if available)
+- **Segment to analyse** (all users / paid / free / a specific cohort)
+- **Key question to answer** (why is retention dropping? what drives retention?)
+- **Available data** (analytics events, churn surveys, interview notes)
+
+## Quality Checks
+
+- [ ] Retention curve shape is diagnosed (flattening vs trending to zero = PMF vs onboarding)
+- [ ] Cohorts are segmented before analysis (not all users lumped together)
+- [ ] "Aha moment" correlation is identified or flagged as unknown
+- [ ] Interventions are specific (not "improve onboarding")
+- [ ] Churned user interviews are recommended (not just data analysis)
+- [ ] Monitoring plan includes an alert threshold
+
 ## Guidelines
 
 - Never recommend "improve onboarding" without specifying *what* to change and *why*

plugins/pm-cross/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-cross",
+  "version": "1.1.0",
+  "description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary, Teaching Lesson Plan. Write journalist-ready press releases, structure grant applications, produce decision-ready executive summaries, and design complete lesson plans for any subject, audience, or setting.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["communications", "press-release", "grant", "executive-summary", "briefing", "funding", "media", "education", "teaching", "lesson-plan", "training"]
+}

plugins/pm-cross/skills/executive-summary/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: executive-summary
+description: "Write an executive summary for any document, report, or proposal. Use when asked to write an executive summary, management summary, briefing paper, or one-pager for senior stakeholders. Produces a structured summary that busy executives can read in under 3 minutes and act on."
+---
+
+# Executive Summary Skill
+
+Writes executive summaries that busy decision-makers actually read — front-loaded with conclusions, structured for skimming, ruthless about what to include.
+
+## Required Inputs
+- **Source document or topic** (paste or describe)
+- **Audience** (CEO / board / investor / minister / client / committee)
+- **Decision or action needed** (what should the reader do after reading?)
+- **Length limit** (1 page / 2 pages / 500 words)
+- **Format** (formal report / slide / email / briefing paper)
+
+## Core Principle
+
+An executive summary is NOT a summary of the document. It is a standalone document that:
+- States the conclusion upfront — not at the end
+- Contains only what the reader needs to make a decision
+- Can be understood without reading anything else
+- Recommends a specific action
+
+## Output Structure
+
+---
+
+### [Title]
+**Executive Summary**
+*Prepared for: [Audience] | Date: [Date] | Author: [Name]*
+
+---
+
+**Bottom line up front:**
+[The most important thing. The recommendation or finding. 2-3 sentences. A reader who only reads this should know what you are asking or telling them.]
+
+---
+
+**Background (why this matters):**
+[2-3 sentences. Minimum context to understand the bottom line. Not the history — just what the reader needs now.]
+
+---
+
+**Key findings / analysis:**
+- **[Finding 1]:** [One sentence — specific and evidence-based]
+- **[Finding 2]:** [One sentence]
+- **[Finding 3]:** [One sentence]
+
+---
+
+**Options considered:** (include only if a decision is being presented)
+
+| Option | Benefit | Risk | Recommendation |
+|---|---|---|---|
+| [Option A] | [Benefit] | [Risk] | Recommended |
+| [Option B] | [Benefit] | [Risk] | Not recommended |
+
+---
+
+**Recommendation:**
+[Specific. "We recommend [action] because [reason]. This will [outcome]." Not "we suggest consideration of options."]
+
+---
+
+**Immediate next steps:**
+- [Action 1 — specific, with owner and date]
+- [Action 2]
+
+---
+
+**Risks of inaction:** [What happens if the reader does nothing]
+
+**Full report:** [Reference to where the full document can be found]
+
+---
+
+## Adapting for Different Audiences
+
+**CEO/MD:** Lead with financial or strategic impact. 1 page. Make the decision binary. Ask in sentence one.
+**Board:** Lead with governance or risk. Frame against organisational objectives. State specifically what you need from them.
+**Investor:** Lead with return or opportunity. Specific numbers. 1 page. Anticipate "why now."
+**Minister/senior public sector:** Lead with public benefit or policy alignment. Include cost-benefit framing.
+**Client:** Lead with their problem. Show you understand before presenting recommendation.
+
+## Quality Checks
+- Bottom line in first 3 sentences
+- Standalone — no need to read full document
+- Recommendation is specific
+- Fits length limit
+- Written for audience priorities not author priorities
+- Next steps have owners and dates
+
+## Example Trigger Phrases
+- "Write an executive summary of this report: [paste]"
+- "Summarise this document for the board: [paste]"
+- "Create a one-pager from this proposal for the CEO"
+- "Turn these findings into an exec summary"

plugins/pm-cross/skills/grant-proposal/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: grant-proposal
+description: "Write a structured grant proposal or funding application for any grant type. Use when asked to write a grant proposal, funding application, research grant, charitable grant, or innovation fund application. Produces a complete proposal with project summary, rationale, methodology, impact, and budget narrative."
+---
+
+# Grant Proposal Skill
+
+Produces structured grant proposals tailored to the funder priorities — the most common reason grants fail is writing about what you want to do rather than what the funder wants to fund.
+
+## Required Inputs
+- **Funder name and grant programme**
+- **Grant amount sought**
+- **Project description** (rough notes are fine)
+- **Your organisation** (type, track record, capacity)
+- **Funder stated priorities** (copy from their guidance — essential)
+- **Word or page limits**
+- **Deadline**
+
+## Output Structure
+
+---
+
+### Project Title
+[Informative and memorable. Should convey the problem being solved and the approach.]
+
+### 1. Project Summary / Abstract (200-300 words — written last, placed first)
+[What you will do, why it matters, who will benefit, measurable outcomes. Every sentence earns its place.]
+
+### 2. Problem Statement / Need
+- **The problem:** [Specific, evidenced — use data]
+- **Who is affected:** [Population, scale, geography]
+- **Current situation:** [What exists and why it is insufficient]
+- **Consequence of inaction:** [What happens if not funded]
+- **Why your organisation:** [Track record, relationships, expertise]
+
+Funder test: does this problem align with [funder] stated priorities? Make the connection explicit.
+
+### 3. Project Objectives
+3-5 SMART objectives:
+- **Objective 1:** [Specific, Measurable, Achievable, Relevant, Time-bound]
+
+### 4. Methodology / Approach
+
+**Phase 1: [Name]** (Months 1-X)
+[What will happen, who will do it, what is produced]
+
+**Key activities:**
+- [Activity — specific]
+
+**What makes this approach innovative or effective:** [Why this over alternatives]
+
+### 5. Impact and Outcomes
+
+| Level | Description | Measure |
+|---|---|---|
+| Output | [Tangible deliverable] | [How counted] |
+| Short-term outcome | [Immediate change] | [How measured] |
+| Medium-term outcome | [Behaviour change] | [How measured] |
+| Long-term impact | [Systemic change] | [How evidenced] |
+
+**Direct beneficiaries:** [Who and how many]
+**Sustainability:** [How work continues beyond grant period]
+
+### 6. Evaluation Plan
+- Who evaluates, how, when, what is measured, how findings are shared
+
+### 7. Budget Narrative
+
+| Budget line | Amount | Justification |
+|---|---|---|
+| Staff costs | £[amount] | [Role, % FTE, duration, salary] |
+| Travel | £[amount] | [Specific journeys named] |
+| Equipment | £[amount] | [Itemised] |
+| Indirect costs | £[amount] | [[X]% of direct — check policy] |
+| **Total** | **£[total]** | |
+
+**Value for money:** [Cost per beneficiary. What could not be done without this grant]
+
+### 8. Organisational Capacity
+[Track record of similar projects, governance, financial management. Name previous grants and outputs — be specific]
+
+### 9. Risk Register
+
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| [Risk] | H/M/L | H/M/L | [Specific mitigation] |
+
+---
+
+## Quality Checks
+
+- [ ] Every section explicitly references funder stated priorities (not just generic language)
+- [ ] Problem statement includes specific data, not just assertions
+- [ ] Objectives are SMART (measurable and time-bound)
+- [ ] Budget narrative justifies every line with specific detail
+- [ ] Sustainability section explains what happens after the grant ends
+- [ ] Word limits respected
+
+## Example Trigger Phrases
+- "Write a grant proposal for [project] applying to [funder]"
+- "Help me write a funding application for [grant programme]"
+- "Turn these project notes into a grant proposal: [paste]"

plugins/pm-cross/skills/press-release/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: press-release
+description: "Write a professional press release for any announcement. Use when asked to write a press release, media announcement, news release, or press statement. Produces a structured press release with headline, dateline, body, boilerplate, and media contact — ready to send to journalists."
+---
+
+# Press Release Skill
+
+Writes press releases that journalists actually read — structured around the news angle, not the desire to promote.
+
+## Required Inputs
+- **The news** (what is actually happening — be specific)
+- **Company name**
+- **Date of announcement / embargo date**
+- **Key quote** (from which executive and approximately what they want to say)
+- **Why this matters** (to the reader, not the company)
+- **Target media** (trade / national / local / consumer / investor)
+- **Media contact details**
+
+## Output Structure
+
+---
+
+FOR IMMEDIATE RELEASE / EMBARGOED UNTIL: [Date and time]
+
+---
+
+# [Headline — active verb, specific news, under 10 words]
+## [Subheadline — the so-what in one sentence, adds context not repetition]
+
+**[City, Date]** — [Opening paragraph: Who, What, When, Where, Why in 2-3 sentences. A journalist should be able to run this paragraph alone. No background, no context, no company history.]
+
+[Second paragraph: the significance. Why does this matter? What does it mean for customers or the industry?]
+
+[Third paragraph: quote from executive. Human and specific. Not a restatement of the headline.]
+
+"[Quote text — specific, adds something the facts do not say]," said [Name], [Title] at [Company]. "[Second sentence extending the thought]."
+
+[Fourth paragraph: supporting detail — data, customer names with permission, additional context]
+
+[Fifth paragraph optional: what happens next, when it goes live, what people can do]
+
+---
+
+ENDS
+
+---
+
+**Notes to editors:**
+
+**About [Company]**
+[Boilerplate: 3-4 sentences. What the company does, when founded, where based, key facts. Factual not promotional.]
+
+**Media contact:**
+[Name] | [Title] | [Email] | [Phone] | [Hours/timezone]
+
+---
+
+## Headline Rules
+- Active voice: "Company launches X" not "X is launched by Company"
+- Specific: "raises 5M" not "secures significant investment"
+- Under 10 words
+- Never start with the company name — lead with the news
+
+## Journalist Test
+Would a journalist care? Is the headline the full story? Is there a human angle? Is the quote something a human would say? Can the first paragraph stand alone?
+
+## Quality Checks
+
+- [ ] Headline uses active voice and is under 10 words
+- [ ] First paragraph stands alone as the complete story
+- [ ] Quote adds something the facts don't say (not a restatement)
+- [ ] Boilerplate is factual, not promotional
+- [ ] Embargo date and media contact are included
+
+## Example Trigger Phrases
+- "Write a press release announcing [news]"
+- "Draft a media statement about [event]"
+- "We are launching [product] — write the press release"
+- "Turn this announcement into a press release: [paste notes]"

plugins/pm-cross/skills/teaching-lesson-plan/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: teaching-lesson-plan
+description: "Design a structured lesson plan for any subject, audience, or format. Use when asked to write a lesson plan, course outline, teaching session, workshop curriculum, or training module. Produces a complete lesson plan with learning objectives, activities, timing, assessment, and differentiation guidance."
+---
+
+# Teaching Lesson Plan Skill
+
+Produces a complete, structured lesson plan for any subject, age group, or setting — from a one-hour corporate training to a full school lesson. Built around clear learning objectives, varied activities, and formative assessment.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Subject or topic**
+- **Audience** (age group, experience level, group size)
+- **Session length** (30 / 45 / 60 / 90 / 120 minutes)
+- **Setting** (classroom / workshop / online / corporate training / one-to-one)
+- **Learning goal** (what should participants know or be able to do by the end?)
+- **Prior knowledge** (what can you assume they already know?)
+
+## Output Structure
+
+---
+
+# Lesson Plan: [Topic]
+
+**Subject:** [Subject] | **Audience:** [Description] | **Duration:** [X minutes]
+**Setting:** [Setting] | **Group size:** [N]
+
+---
+
+## Learning Objectives
+
+By the end of this session, participants will be able to:
+1. [Objective 1 — use Bloom's taxonomy verbs: recall, explain, apply, analyse, evaluate, create]
+2. [Objective 2]
+3. [Objective 3 — maximum 3–4 objectives per session]
+
+**Key vocabulary:** [3–5 terms participants will need to know]
+
+---
+
+## Materials and Preparation
+
+- [ ] [Resource 1 — slides, handout, equipment]
+- [ ] [Resource 2]
+- [ ] Room setup: [configuration — rows / circles / tables / breakout spaces]
+
+---
+
+## Lesson Structure
+
+| Time | Phase | Activity | Format |
+|---|---|---|---|
+| [00:00] | Hook / Opener | [How you grab attention and establish relevance] | [Whole group / Individual / Pairs] |
+| [00:05] | Prior knowledge | [How you connect to what they already know] | [Discussion / Quiz / Think-pair-share] |
+| [00:15] | Instruction | [Direct teaching of new content] | [Explanation / Demo / Video] |
+| [00:30] | Guided practice | [Supported practice with feedback] | [Worked examples / Group task] |
+| [00:50] | Independent practice | [Students apply learning independently] | [Task / Problem / Discussion] |
+| [01:05] | Check for understanding | [Formative assessment] | [Exit ticket / Quiz / Q&A] |
+| [01:15] | Closure | [Summarise, connect to next session] | [Whole group] |
+
+---
+
+## Key Explanations and Worked Examples
+
+### [Concept 1]
+[Clear explanation + one concrete worked example. Explain the concept the way a good teacher would — no jargon without definition, one idea at a time.]
+
+### [Concept 2]
+[Explanation + example]
+
+---
+
+## Differentiation
+
+**For those who need more support:**
+- [Scaffold: e.g. sentence starters, worked examples, vocabulary cards]
+- [Modified task or reduced scope]
+
+**For those ready for a challenge:**
+- [Extension: e.g. apply to a new context, evaluate, create something]
+
+---
+
+## Formative Assessment (Check for Understanding)
+
+**During session:**
+- [Method 1: e.g. Cold calling with no-stakes approach, thumbs up/down, mini whiteboards]
+- [Method 2: e.g. Think-pair-share before moving on]
+
+**Exit ticket (last 5 minutes):**
+[One specific question that directly tests the learning objective — not "what did you enjoy?" but "solve this problem" or "explain this concept in your own words"]
+
+---
+
+## Common Misconceptions to Address
+
+| Misconception | Correct understanding | How to address it |
+|---|---|---|
+| [What learners often get wrong] | [The correct version] | [Specific activity or explanation] |
+
+---
+
+## Quality Checks
+
+- [ ] Learning objectives use action verbs (not "understand" or "know")
+- [ ] Session has a clear hook that establishes relevance
+- [ ] Activities are varied (not all listening)
+- [ ] Formative assessment checks the actual learning objective
+- [ ] Differentiation is specified for both support and extension
+- [ ] Timing adds up to session length
+
+## Example Trigger Phrases
+
+- "Write a lesson plan on [topic] for [audience]"
+- "Design a 60-minute session on [subject]"
+- "Create a training module on [skill]"
+- "Plan a workshop on [topic] for [group]"

plugins/pm-cs/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-cs",
+  "version": "1.0.0",
+  "description": "Customer Success skills: Customer Health Scorecard, QBR Deck, Escalation Brief, Churn Analysis. Score account health with a weighted RAG framework, build structured QBR decks with value narratives, write crisp escalation briefs for at-risk accounts, and analyse churn by category and segment with prioritised interventions.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["customer-success", "account-management", "health-scorecard", "qbr", "quarterly-business-review", "churn", "retention", "escalation", "csm", "renewal"]
+}

plugins/pm-cs/skills/churn-analysis/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: churn-analysis
+description: "Analyse customer churn for a product or cohort and produce a structured churn report. Use when asked to analyse churn, understand why customers are leaving, identify churn patterns, calculate churn rate, or build a churn reduction plan. Produces a churn analysis with rate calculations, categorised reasons, early warning signals, and prioritised interventions."
+---
+
+# Churn Analysis Skill
+
+Produce a structured churn analysis that goes beyond the headline rate — identifying why customers leave, which segments are most at risk, and what interventions will have the highest impact on retention.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Time period** being analysed (e.g. Q1, last 12 months)
+- **Total customers at start of period** and **customers churned**
+- **ARR or revenue lost** to churn
+- **Churn reasons data** — exit survey results, CSM notes, support data, or sales loss reasons
+- **Customer segments** — by tier, industry, cohort, or product line
+- **Current retention rate** if known
+- **Any recent changes** — pricing, product, support model — that may have affected churn
+
+## Churn Categories
+
+Always classify churn before analysing it:
+
+| Category | Definition |
+|---|---|
+| **Voluntary — avoidable** | Customer left due to a problem we could have addressed (product gaps, poor onboarding, relationship failures) |
+| **Voluntary — unavoidable** | Customer left for reasons outside our control (budget cuts, acquisition, company shutdown) |
+| **Involuntary** | Payment failure, contract non-renewal by mistake, admin error |
+
+The interventions for each category are different. Conflating them leads to wrong conclusions.
+
+## Output Format
+
+---
+
+# Churn Analysis: [Product / Segment / Company]
+**Period:** [Start date] — [End date]
+**Prepared by:** [Name] | **Date:** [Date]
+
+---
+
+## Headline Numbers
+
+| Metric | Value |
+|---|---|
+| Customers at start of period | [N] |
+| Customers churned | [N] |
+| **Customer churn rate** | **[X]%** |
+| ARR at start of period | £/$/€[X] |
+| ARR lost to churn | £/$/€[X] |
+| **Revenue churn rate (gross)** | **[X]%** |
+| ARR from expansions (same period) | £/$/€[X] |
+| **Net revenue retention (NRR)** | **[X]%** |
+
+**Benchmark context:**
+- Customer churn rate: [X]% vs. industry benchmark [Y]% — [above / below / in line]
+- NRR: [X]% — [What this means: above 100% = expansion offsets churn; below 100% = shrinking base]
+
+---
+
+## Churn Breakdown by Category
+
+| Category | Customers | % of churn | ARR lost |
+|---|---|---|---|
+| Voluntary — avoidable | [N] | [X]% | £/$/€[X] |
+| Voluntary — unavoidable | [N] | [X]% | £/$/€[X] |
+| Involuntary | [N] | [X]% | £/$/€[X] |
+| **Total** | **[N]** | **100%** | **£/$/€[X]** |
+
+**Avoidable churn as % of total churn:** [X]% — this is the number we can actually influence.
+
+---
+
+## Churn Reasons — Avoidable Churn Only
+
+Rank by frequency. Include ARR weight where data allows.
+
+| Reason | Count | % of avoidable churn | ARR lost | Representative quote |
+|---|---|---|---|---|
+| [Reason 1 — e.g. "Product missing key feature"] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 2] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 3] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 4] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| Other | [N] | [X]% | £/$/€[X] | — |
+
+**Theme synthesis:** [2–3 sentences grouping the top reasons into 2–3 themes. E.g. "The top three reasons cluster around two themes: product gaps in [area] (affecting X% of avoidable churn) and onboarding failures where customers never achieved value (Y%)."]
+
+---
+
+## Churn by Segment
+
+Identify which segments over- or under-index for churn.
+
+### By Tier
+
+| Tier | Churn rate | vs. Overall | Notes |
+|---|---|---|---|
+| Enterprise | [X]% | +/-[X]pp | |
+| Mid-Market | [X]% | +/-[X]pp | |
+| SMB | [X]% | +/-[X]pp | |
+
+### By Cohort (Acquisition Year)
+
+| Cohort | Churn rate | Notes |
+|---|---|---|
+| [Year 1] | [X]% | |
+| [Year 2] | [X]% | |
+| [Year 3] | [X]% | |
+
+### By Industry / Use Case (if data available)
+
+| Segment | Churn rate | Notes |
+|---|---|---|
+| [Segment 1] | [X]% | |
+| [Segment 2] | [X]% | |
+
+**Key pattern:** [Which segment has the highest churn rate and what likely explains it]
+
+---
+
+## Timing Analysis
+
+- **Average contract length before churn:** [X months]
+- **Highest-risk moment:** [e.g. "Month 3 — when trial value has worn off but full adoption hasn't happened"]
+- **Churn timing distribution:**
+
+| When churn occurred | % of churned accounts |
+|---|---|
+| 0–3 months | [X]% |
+| 3–6 months | [X]% |
+| 6–12 months | [X]% |
+| 12+ months | [X]% |
+
+---
+
+## Early Warning Signals
+
+Based on the churned accounts, identify the signals that preceded churn (and could have triggered earlier intervention):
+
+| Signal | Lead time before churn | How to detect |
+|---|---|---|
+| [Signal 1 — e.g. "DAU/MAU dropped below 15%"] | [~X weeks] | [Usage dashboard / alert] |
+| [Signal 2 — e.g. "No QBR in 90+ days"] | [~X weeks] | [CRM flag] |
+| [Signal 3 — e.g. "Champion left the account"] | [~X weeks] | [LinkedIn alert / CSM tracking] |
+| [Signal 4] | [~X weeks] | [Detection method] |
+
+---
+
+## Intervention Recommendations
+
+Ranked by estimated impact × feasibility.
+
+| Intervention | Addresses | Est. churn reduction | Effort | Owner |
+|---|---|---|---|---|
+| [Intervention 1 — e.g. "Improve onboarding for [segment] with dedicated 30-day check-in"] | [Reason 1] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+| [Intervention 2] | [Reason 2] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+| [Intervention 3] | [Reason 3] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+
+**Priority call:** [Which one intervention, if implemented this quarter, would have the biggest impact and why]
+
+---
+
+## What We Don't Know (Data Gaps)
+
+- [Data gap 1 — e.g. "Exit survey response rate is only 30% — the reasons data may not be representative"]
+- [Data gap 2 — e.g. "No product usage data for SMB tier — can't confirm usage signal correlation"]
+- [Data gap 3]
+
+---
+
+## Quality Checks
+
+- [ ] Churn rate is correctly calculated (churned ÷ starting cohort, not end-of-period total)
+- [ ] Avoidable and unavoidable churn are separated — interventions target avoidable churn only
+- [ ] Churn reasons are customer-reported, not internally assumed
+- [ ] Segment analysis identifies which segments over-index — not just averages
+- [ ] Early warning signals are specific and detectable, not generic ("low engagement")
+- [ ] Interventions link directly to the top churn reasons — no recommendations without a root cause match

plugins/pm-cs/skills/cs-escalation-brief/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: cs-escalation-brief
+description: "Write a structured escalation brief for an at-risk customer account. Use when an account has escalated, when a customer is threatening churn, when a P1 customer issue needs executive attention, or when preparing an internal save play. Produces a crisp escalation brief with account context, timeline, root cause, business impact, and a clear resolution plan."
+---
+
+# Customer Escalation Brief Skill
+
+Produce a clear, concise escalation brief that gives internal stakeholders — VP CS, CCO, product leadership, or the CEO — everything they need to understand the situation, make decisions, and act fast.
+
+A good escalation brief is not a complaint. It is a professional document that states the facts, assigns accountability honestly, and proposes a specific resolution plan.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name**, tier, and ARR
+- **CSM name** and account owner
+- **Nature of the escalation** — what happened, what the customer is saying
+- **Timeline** of events leading to escalation
+- **Customer contact** who escalated (name, role, influence level)
+- **What the customer wants** — their stated ask
+- **What we believe the root cause is**
+- **What has already been done** to address the situation
+- **Renewal date** and current renewal risk assessment
+
+## Escalation Levels
+
+Calibrate urgency and audience based on escalation level:
+
+| Level | Trigger | Audience | Response time |
+|---|---|---|---|
+| L1 — Account Risk | Customer expressing dissatisfaction; renewal at risk | CSM + CS Manager | 24 hours |
+| L2 — Executive Escalation | Customer escalated to their exec; requesting vendor exec involvement | VP CS + Account Exec | 4 hours |
+| L3 — Churn Risk | Customer has issued notice or is in active churn conversation | CCO / CEO + Revenue leadership | 1 hour |
+| L4 — Public Risk | Customer threatening public escalation, legal, or press | CCO / Legal / Comms | Immediate |
+
+## Output Format
+
+---
+
+# Escalation Brief: [Account Name]
+
+**Escalation level:** L[1/2/3/4] — [Label]
+**Date raised:** [Date]
+**Raised by:** [CSM name]
+**Escalation owner:** [Name of exec or senior stakeholder now leading response]
+
+---
+
+## Account at a Glance
+
+| Field | Detail |
+|---|---|
+| ARR | £/$/€[X] |
+| Tier | Enterprise / Mid-Market / SMB |
+| Customer since | [Date] |
+| Renewal date | [Date] — [N] days away |
+| Renewal risk (pre-escalation) | Green / Amber / Red |
+| Renewal risk (current) | Green / Amber / Red |
+| Customer contact who escalated | [Name, role, seniority] |
+| Executive sponsor (customer) | [Name, role — active / passive / vacant] |
+| Executive sponsor (vendor) | [Name, role] |
+
+---
+
+## What Happened — Summary
+
+[3–5 sentences. State the facts plainly. What the customer experienced, how they reacted, and how we learned about the escalation. No editorialising. No blame.]
+
+---
+
+## Timeline
+
+List in chronological order. Each entry: `[Date / time] — [What happened. Who did what.]`
+
+Include:
+- When the original issue or trigger event occurred
+- When the customer first raised concerns (informally)
+- When it escalated (formal escalation or exec involvement)
+- Actions taken since escalation
+
+---
+
+## Root Cause
+
+**Primary cause:** [One clear sentence. What specifically went wrong.]
+
+**Contributing factors:**
+- [Factor 1 — be honest about internal failures as well as external ones]
+- [Factor 2]
+
+**Is this a systemic issue or isolated?**
+[ ] Isolated to this account
+[ ] Pattern seen in other accounts — details: [_______]
+[ ] Product or process gap that needs fixing
+
+---
+
+## Customer's Stated Position
+
+**What the customer says happened:** [Their version of events — fair and unfiltered]
+
+**What they are asking for:** [Their explicit ask — compensation, fix by date, exec call, SLA credit, exit clause]
+
+**Sentiment of escalating contact:** [Frustrated but constructive / Angry / Seeking exit / Unknown]
+
+**Risk of public escalation:** Low / Medium / High — [evidence if Medium or High]
+
+---
+
+## Business Impact
+
+| Impact type | Detail |
+|---|---|
+| ARR at risk | £/$/€[X] |
+| Potential churn probability | [X]% |
+| Reputational risk | Low / Medium / High |
+| Reference / case study status | [Was a reference — now at risk / Not a reference] |
+| Expansion pipeline at risk | £/$/€[X] |
+
+---
+
+## What Has Been Done So Far
+
+1. [Action taken — by whom — date — outcome]
+2. [Action taken — by whom — date — outcome]
+3. [Action taken — by whom — date — outcome]
+
+**Has a formal apology or acknowledgement been issued?** Yes / No
+
+---
+
+## Proposed Resolution Plan
+
+**Immediate actions (next 24–48 hours):**
+
+| Action | Owner | By when |
+|---|---|---|
+| [Action] | [Name] | [Date] |
+| [Action] | [Name] | [Date] |
+
+**Medium-term actions (next 2–4 weeks):**
+
+| Action | Owner | By when |
+|---|---|---|
+| [Action] | [Name] | [Date] |
+
+**What we are NOT offering:** [Be explicit about what is not on the table — avoids misaligned expectations]
+
+**Success criteria:** [How will we know the escalation is resolved? What does the customer need to confirm they are satisfied?]
+
+---
+
+## Decision Required from Escalation Owner
+
+[State clearly what decision or resource the escalation owner needs to provide. Be specific — do not make them ask. E.g.: "We need approval to offer a 20% service credit for Q2" or "We need an exec call with [name] within 48 hours."]
+
+---
+
+## Communication Plan
+
+| Audience | Message | Channel | Owner | By when |
+|---|---|---|---|---|
+| Escalating customer contact | [Summary of message] | Email / Call | [Name] | [Date] |
+| Customer exec sponsor | [Summary] | Call | [Name] | [Date] |
+| Internal CS team | [Summary] | Slack / Meeting | CS Manager | [Date] |
+
+---
+
+## Quality Checks
+
+- [ ] Root cause is specific — not "communication breakdown" or "product gap" without detail
+- [ ] Customer's position is stated fairly — not minimised or dismissed
+- [ ] A clear decision is requested from the escalation owner — brief does not end with "what do you think?"
+- [ ] ARR at risk is quantified
+- [ ] Communication plan has owners and dates — not "TBD"
+- [ ] Language is professional and blameless toward individuals

plugins/pm-cs/skills/cs-health-scorecard/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: cs-health-scorecard
+description: "Build a customer health scorecard for a specific account. Use when asked to score account health, assess renewal risk, build a health dashboard, or evaluate an account's likelihood to renew or expand. Produces a structured health scorecard with a RAG status, dimension scores, key risks, and recommended actions."
+---
+
+# Customer Health Scorecard Skill
+
+Produce a structured, data-driven health scorecard for a customer account — giving the CSM and leadership a clear view of renewal risk, expansion potential, and the actions needed to move the account in the right direction.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name** and tier (enterprise / mid-market / SMB)
+- **Contract value** (ARR) and **renewal date**
+- **Product usage data** — logins, DAU/MAU ratio, key feature adoption
+- **Support data** — open tickets, CSAT or NPS score, recent escalations
+- **Engagement data** — last QBR date, executive sponsor status, champion name
+- **Commercial data** — payment history, expansion conversations, seats used vs. licensed
+- **Any known risks or recent changes** at the account
+
+## Scoring Framework
+
+Score each dimension 1–5. Weight as shown. Calculate weighted total out of 100.
+
+| Dimension | Weight | What to Score |
+|---|---|---|
+| **Product Adoption** | 30% | DAU/MAU ratio, breadth of features used, power users identified |
+| **Engagement** | 20% | QBR cadence, executive sponsor active, champion strength |
+| **Outcomes** | 20% | Customer hitting their stated goals / success metrics |
+| **Support Health** | 15% | Ticket volume trend, unresolved escalations, CSAT |
+| **Commercial** | 15% | On-time payments, seats utilised, expansion signals |
+
+**Score → RAG conversion:**
+- 80–100: Green (healthy, renew likely)
+- 60–79: Amber (at risk, needs attention)
+- 0–59: Red (high churn risk, escalate)
+
+## Output Format
+
+---
+
+# Customer Health Scorecard: [Account Name]
+
+**CSM:** [Name] | **Tier:** [Enterprise / Mid-Market / SMB]
+**ARR:** £/$/€[X] | **Renewal date:** [Date] | **Days to renewal:** [N]
+**Overall health:** [Green / Amber / Red] — [Score]/100
+**Last updated:** [Date]
+
+---
+
+## Health Score Summary
+
+| Dimension | Score (1–5) | Weight | Weighted Score | Trend |
+|---|---|---|---|---|
+| Product Adoption | [1–5] | 30% | [X] | ↑ / → / ↓ |
+| Engagement | [1–5] | 20% | [X] | ↑ / → / ↓ |
+| Outcomes | [1–5] | 20% | [X] | ↑ / → / ↓ |
+| Support Health | [1–5] | 15% | [X] | ↑ / → / ↓ |
+| Commercial | [1–5] | 15% | [X] | ↑ / → / ↓ |
+| **Total** | — | 100% | **[X]/100** | |
+
+---
+
+## Dimension Detail
+
+### Product Adoption — [Score]/5
+- **DAU/MAU ratio:** [X]% (benchmark: >25% = healthy)
+- **Key features adopted:** [List features in use]
+- **Features not adopted:** [List unused high-value features]
+- **Power users identified:** [Yes / No — how many]
+- **Assessment:** [1–2 sentences on adoption health]
+
+### Engagement — [Score]/5
+- **Last QBR:** [Date] — [Outcome summary]
+- **Next QBR:** [Scheduled / Overdue]
+- **Executive sponsor:** [Active / Passive / Vacant]
+- **Champion:** [Name, role, strength: strong / moderate / weak]
+- **Assessment:** [1–2 sentences]
+
+### Outcomes — [Score]/5
+- **Customer's stated goals:** [List 2–3 goals from onboarding or last QBR]
+- **Progress against goals:** [On track / Partial / Off track]
+- **Evidence of value:** [Metric or quote that demonstrates ROI]
+- **Assessment:** [1–2 sentences]
+
+### Support Health — [Score]/5
+- **Open tickets:** [N] (priority breakdown: P1: X, P2: X, P3: X)
+- **CSAT / NPS:** [Score] (benchmark: >8 CSAT / >30 NPS = healthy)
+- **Unresolved escalations:** [Yes / No — details if yes]
+- **Ticket trend (last 90 days):** Increasing / Stable / Decreasing
+- **Assessment:** [1–2 sentences]
+
+### Commercial — [Score]/5
+- **Seats licensed:** [N] | **Seats active:** [N] ([X]% utilisation)
+- **Payment history:** [On time / Late — details]
+- **Expansion signals:** [Yes — describe / No]
+- **Downgrade or cancellation signals:** [Yes — describe / No]
+- **Assessment:** [1–2 sentences]
+
+---
+
+## Top Risks
+
+| Risk | Severity | Mitigation |
+|---|---|---|
+| [Risk description] | High / Medium / Low | [Specific action to mitigate] |
+
+---
+
+## Recommended Actions
+
+**Immediate (this week):**
+1. [Action — owner — deadline]
+
+**This month:**
+1. [Action — owner — deadline]
+
+**Before renewal:**
+1. [Action — owner — deadline]
+
+---
+
+## Renewal Forecast
+
+| Scenario | Probability | ARR at risk |
+|---|---|---|
+| Full renewal at current ARR | [X]% | £/$/€0 |
+| Renewal with contraction | [X]% | £/$/€[X] |
+| Churn | [X]% | £/$/€[full ARR] |
+
+**Recommended renewal play:** [Expand / Hold / Save / Manage out]
+
+---
+
+## Quality Checks
+
+- [ ] Score is based on data, not gut feel — each dimension has evidence
+- [ ] Risks are specific (not "low engagement" — something like "executive sponsor left in March, no replacement identified")
+- [ ] Actions have owners and deadlines
+- [ ] Renewal probability is calibrated against pipeline reality
+- [ ] Trend arrows reflect direction of change vs. last scorecard, not just current state

plugins/pm-cs/skills/qbr-deck/SKILL.md

@@ -0,0 +1,218 @@
+---
+name: qbr-deck
+description: "Build a Quarterly Business Review (QBR) deck structure and narrative for a customer account. Use when asked to prepare a QBR, business review meeting, executive review, or quarterly check-in with a customer. Produces a slide-by-slide QBR structure with talking points, metrics review, value narrative, and mutual next steps."
+---
+
+# QBR Deck Skill
+
+Produce a complete Quarterly Business Review deck — structured, data-backed, and customer-focused. A good QBR demonstrates value delivered, aligns on goals for the next quarter, and strengthens the executive relationship. It should never feel like a product demo or a vendor update.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name**, CSM name, and customer stakeholders attending
+- **Contract details** — ARR, contract start date, renewal date
+- **Last quarter's goals** (from previous QBR or kickoff)
+- **Usage and adoption data** — key metrics for the quarter
+- **Support summary** — tickets raised, resolution time, any escalations
+- **Business outcomes the customer cares about** — what success looks like for them
+- **Product updates or new features** relevant to this customer
+- **Goals for next quarter**
+- **Any open commercial conversations** (expansion, renewal, at-risk signals)
+
+## QBR Principles
+
+- Lead with customer outcomes, not product features
+- Every metric should connect to a business result the customer cares about
+- The agenda is a conversation, not a presentation — build in time for customer input at every stage
+- Close with mutual commitments, not just vendor actions
+
+## Output Format
+
+---
+
+# QBR: [Account Name] × [Your Company]
+**[Quarter] [Year] Business Review**
+
+**Date:** [Date] | **Location / Call link:** [TBC]
+**Customer attendees:** [Names and roles]
+**[Your company] attendees:** [Names and roles]
+
+---
+
+## Slide 1: Agenda (5 min)
+
+| Time | Topic | Owner |
+|---|---|---|
+| 0:00 | Welcome and introductions | CSM |
+| 0:05 | [Last quarter] — how did we do? | CSM + Customer |
+| 0:20 | Value delivered — business impact | CSM |
+| 0:35 | What's coming — roadmap preview | CSM / Product |
+| 0:45 | [Next quarter] — goals and priorities | Customer |
+| 0:55 | Actions and mutual commitments | CSM |
+| 1:00 | Close | |
+
+*Talking point: "We've kept today to 60 minutes. We want as much of this to be a conversation as possible — please push back, redirect, and ask questions throughout."*
+
+---
+
+## Slide 2: Where We Are Together (2 min)
+
+**Partnership snapshot:**
+- **Customer since:** [Date]
+- **Contract value:** £/$/€[ARR]/year
+- **Renewal date:** [Date]
+- **Active users:** [N] of [N] licensed seats ([X]% adoption)
+- **Products / modules active:** [List]
+
+*Talking point: "Before we dive in — a quick picture of where we are. [X] months in, [Y] active users, and this is our [Nth] QBR together."*
+
+---
+
+## Slide 3: Last Quarter — Goals We Set Together (5 min)
+
+| Goal | Set in [Last QBR / Kickoff] | Status |
+|---|---|---|
+| [Goal 1] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+| [Goal 2] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+| [Goal 3] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+
+For any partial or missed goal: state what happened and what changes next quarter.
+
+*Talking point: "Let's start with accountability. Here's what we said we'd achieve last quarter — let's be honest about where we landed."*
+
+---
+
+## Slide 4: Usage and Adoption (5 min)
+
+**Quarter-over-quarter trend:**
+
+| Metric | [Q-1] | [Q] | Change |
+|---|---|---|---|
+| Monthly active users | [N] | [N] | +/-X% |
+| Sessions per user per week | [N] | [N] | +/-X% |
+| [Key feature 1] adoption | [X]% | [X]% | +/-X% |
+| [Key feature 2] adoption | [X]% | [X]% | +/-X% |
+
+**Highlights:**
+- [Positive adoption trend to call out]
+- [Feature or workflow with strongest engagement]
+
+**Opportunity:**
+- [Feature with low adoption that could drive more value — link to their goals]
+
+*Talking point: "Usage is [up / stable / something we want to talk about]. The area I'd like to focus on is [feature] — we're not seeing the adoption we'd expect given [their goal], and I want to understand why."*
+
+---
+
+## Slide 5: Business Impact — Value Delivered (10 min)
+
+Lead with outcomes, not activity.
+
+**[Outcome 1: customer's primary success metric]**
+- Before: [baseline]
+- Now: [current state]
+- Impact: [quantified business result — time saved, revenue influenced, cost reduced, risk mitigated]
+
+**[Outcome 2]**
+- [Same structure]
+
+**[Outcome 3]**
+- [Same structure]
+
+**Customer evidence** (use if available):
+> "[Quote from champion or user about value experienced]"
+
+*Talking point: "This is the section I most want your input on. Are these the outcomes that matter to your business? Are there other ways you're measuring success that we should be tracking?"*
+
+---
+
+## Slide 6: Support Summary (3 min)
+
+| Metric | This quarter | Last quarter | Trend |
+|---|---|---|---|
+| Tickets raised | [N] | [N] | ↑ / → / ↓ |
+| Average resolution time | [X hrs] | [X hrs] | ↑ / → / ↓ |
+| P1 / critical issues | [N] | [N] | ↑ / → / ↓ |
+| CSAT score | [X/10] | [X/10] | ↑ / → / ↓ |
+
+**Notable issues this quarter:**
+- [Any escalation or major ticket — brief summary and resolution]
+
+**What we're doing differently:**
+- [Any process change or improvement based on support patterns]
+
+---
+
+## Slide 7: What's Coming — Roadmap Preview (5 min)
+
+Focus only on what's relevant to this customer's goals. Do not dump the full roadmap.
+
+| Feature / Improvement | Expected | Why it matters to [Account Name] |
+|---|---|---|
+| [Feature 1] | [Q+1] | [Direct link to their goal or pain point] |
+| [Feature 2] | [Q+1 / Q+2] | [Direct link] |
+| [Feature 3] | [H2] | [Direct link] |
+
+*Talking point: "I've filtered the roadmap to what I think matters most to your team. I'd love your reaction — are these the right priorities from your perspective?"*
+
+---
+
+## Slide 8: Next Quarter — Your Goals (10 min)
+
+**Customer input section — facilitate, don't present.**
+
+Prompt questions:
+- "What does success look like for your team in [next quarter]?"
+- "What's the biggest challenge you're trying to solve in the next 90 days?"
+- "Is there anything about the way you're using [product] you want to change?"
+
+**Capture live:**
+
+| Goal for next quarter | Owner (customer) | How we'll support it | How we'll measure it |
+|---|---|---|---|
+| [Goal 1] | [Name] | [CSM / product action] | [Metric] |
+| [Goal 2] | [Name] | [CSM / product action] | [Metric] |
+
+---
+
+## Slide 9: Mutual Commitments (5 min)
+
+**[Your company] commits to:**
+1. [Specific action — owner — by when]
+2. [Specific action — owner — by when]
+3. [Specific action — owner — by when]
+
+**[Account Name] commits to:**
+1. [Specific action — owner — by when]
+2. [Specific action — owner — by when]
+
+**Next touchpoint:** [Date of next check-in or mid-quarter review]
+
+---
+
+## Slide 10: Thank You + Open Q&A (5 min)
+
+- Recap the one headline from today: [The single most important thing you want them to remember]
+- Confirm actions are captured and shared after the call
+- Ask: "Is there anything we didn't cover today that you wanted to raise?"
+
+---
+
+## Preparation Checklist
+
+- [ ] Usage data pulled and QoQ comparison calculated
+- [ ] Last QBR goals reviewed — status confirmed before the meeting
+- [ ] Business outcomes framed in customer language (not product language)
+- [ ] Roadmap filtered to this account's specific use cases
+- [ ] Customer's goals for next quarter researched or pre-confirmed with champion
+- [ ] Executive sponsor briefed on any sensitive topics before the call
+- [ ] Actions from previous QBR reviewed — any outstanding items addressed
+
+## Quality Checks
+
+- [ ] Every slide has a talking point, not just a title
+- [ ] Value slide leads with business outcomes, not product activity
+- [ ] Roadmap preview links each item to a customer goal
+- [ ] Mutual commitments section has real owners on both sides
+- [ ] Customer has at least 20 minutes of airtime in the agenda

plugins/pm-data/skills/chart-data-extractor/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: chart-data-extractor
+description: "Extract pixel-level data from an image of a chart or graph and produce a structured data table. Use when asked to extract data from a chart image, transcribe numbers from a graph, digitise a chart, or turn a screenshot of data into a table. Produces a structured table with extracted values, confidence levels, and a reconstructed chart source. Best used with Claude Opus 4.7 or newer for reliable chart data extraction."
+---
+
+# Chart Data Extractor Skill
+
+Extracts data from images of charts and graphs — bar charts, line charts, pie charts, scatter plots, and tables in images — producing a structured data table that can be used in spreadsheets or rebuilt in any charting tool. Built to leverage Opus 4.7 pixel-level image analysis capabilities.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The chart image** (upload a screenshot or image file)
+- **Chart type** (if ambiguous — bar / line / pie / scatter / other)
+- **What matters most** (approximate trends / precise values / specific data points / categorisation)
+- **Known axis values** (optional — if the user knows the max/min values to anchor the extraction)
+
+## Output Structure
+
+### 1. Chart Identification
+
+| Attribute | Value |
+|---|---|
+| Chart type | [Bar / Line / Pie / Scatter / Area / Other] |
+| Chart title (if visible) | [Title text] |
+| X-axis label | [Label + unit] |
+| Y-axis label | [Label + unit] |
+| Number of series | N |
+| Legend categories | [List] |
+| Data period (if time-based) | [Start — End] |
+
+### 2. Extracted Data Table
+
+| [X axis] | [Series 1] | [Series 2] | ... |
+|---|---|---|---|
+| [Value] | [Value] | [Value] | |
+
+### 3. Confidence Levels
+
+For each data point or series, flag confidence:
+
+- **High confidence:** data points where the value is clearly readable against gridlines or labels
+- **Medium confidence:** data points where the value is interpolated between gridlines
+- **Low confidence:** data points where the value is ambiguous or overlaps with other elements
+
+Low-confidence points should be explicitly listed — not silently included in the main table.
+
+### 4. Notable Observations
+
+Observations that the data itself reveals:
+- Peak value: [Value, when, in which series]
+- Lowest value: [Value, when, in which series]
+- Largest delta between series: [Details]
+- Any anomalies or outliers visible in the chart
+
+### 5. Reconstructed Source
+
+CSV format for direct use:
+
+```csv
+[x_axis],[series_1],[series_2]
+[value],[value],[value]
+```
+
+### 6. Assumptions and Caveats
+
+- Grid resolution: [How precisely values could be read — e.g. "Y-axis has major gridlines every 10 units, minor every 2"]
+- Interpolation used: [Any values that required estimating between gridlines]
+- Unclear data: [Anything in the chart that could not be read reliably]
+- Axis scale: [Linear/logarithmic/etc — note if not obvious]
+
+### 7. Follow-up Options
+
+Ask the user which of these they want:
+- Rebuild the chart in a specified format (Excel formula, Python matplotlib, D3, etc.)
+- Produce a narrative description of what the chart shows
+- Compare this data against another chart or source
+- Flag potentially misleading visual choices in the original (truncated axes, misleading scales, etc.)
+
+## Quality Checks
+- [ ] Every extracted number specifies which series it belongs to
+- [ ] Confidence levels are explicit for ambiguous points
+- [ ] Low-confidence values are flagged separately, not silently included
+- [ ] Assumptions about axis scale and interpolation are stated
+- [ ] CSV output is clean and directly usable
+
+## Example Trigger Phrases
+- "Extract the data from this chart"
+- "Transcribe the numbers in this graph"
+- "Turn this chart image into a spreadsheet"
+- "Digitise this chart so I can rebuild it"
+- "What are the exact values in this bar chart?"
+
+## Why This Works Better on Opus 4.7
+Earlier models struggled with pixel-level data transcription from charts, often hallucinating values or misreading gridline positions. Opus 4.7 uses a higher image resolution (2576px vs 1568px) with coordinates mapping 1:1 to pixels, making chart data extraction reliable for practical use.

plugins/pm-delivery/skills/ab-test-planner/SKILL.md

@@ -1,12 +1,21 @@
 ---
 name: ab-test-planner
-description: Designs statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, run an A/B test, calculate sample size, or interpret test results. Triggers on "A/B test", "experiment", "split test", "statistical significance", "sample size".
+description: "Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide."
 ---
 
 # A/B Test Planner Skill
 
 Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **What is being tested** (feature, UI change, copy, pricing, onboarding step)
+- **Hypothesis** (or ask to help formulate one)
+- **Primary metric** (conversion rate, click-through, completion rate, etc.)
+- **Baseline rate** and **minimum detectable effect** (MDE)
+- **Daily eligible users** (to calculate duration)
+
 ## Experiment Design Checklist
 
 Before running any test, confirm:
@@ -93,3 +102,12 @@ Flag if traffic is too low to reach significance in under 8 weeks — recommend
 - If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
 - If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
 - Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
+
+## Quality Checks
+
+- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
+- [ ] Primary metric is singular (guardrail metrics are secondary)
+- [ ] Sample size is calculated from actual MDE and baseline (not guessed)
+- [ ] Test duration accounts for weekly seasonality (minimum 2 weeks)
+- [ ] Guardrail metrics are defined (at least one to protect revenue or core engagement)
+- [ ] Rollback trigger is specified with a concrete threshold

plugins/pm-delivery/skills/go-to-market-planner/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: go-to-market-planner
-description: Builds go-to-market (GTM) plans for product launches, feature releases, and new market entries. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Triggers on "go-to-market", "GTM plan", "product launch plan", "launch strategy", "release plan".
+description: "Build a go-to-market plan for any product launch, feature release, or new market entry. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Produces a tiered GTM plan with messaging, cross-functional activity tracker, success metrics, and launch day checklist."
 ---
 
 # Go-to-Market Planner Skill
@@ -106,9 +106,28 @@ Always confirm tier with the user before proceeding.
 
 ---
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product or feature name**
+- **Target launch date**
+- **Launch tier** (Tier 1 / 2 / 3 — or describe scope and the skill will classify)
+- **Target audience** (who benefits and who it's NOT for)
+- **Key message** (what's the headline outcome for the customer)
+- **PM and launch owner**
+
 ## Guidelines
 
 - Never plan a Tier 1 launch without at least 8 weeks of lead time
 - Always include a "Not for" section — it prevents misdirected sales and support tickets
 - Recommend a soft launch to 5–10% of users before full rollout for any Tier 1 or 2 launch
 - Post-launch retrospective should be scheduled at launch planning time — don't leave it to chance
+
+## Quality Checks
+
+- [ ] Launch tier is confirmed and appropriate for scope
+- [ ] "Not for" section is included to prevent misdirected sales and support
+- [ ] Every function has at least one activity with a named owner and due date
+- [ ] Success metrics include a measurement window (30/60/90 days)
+- [ ] Rollback procedure is confirmed for Tier 1 and 2 launches
+- [ ] Post-launch retrospective is scheduled

plugins/pm-delivery/skills/pptx-slide-auditor/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: pptx-slide-auditor
+description: "Audit a PowerPoint presentation for layout issues, text overflow, visual hierarchy problems, and consistency gaps. Use when asked to review a slide deck, check a presentation before a meeting, audit slides for layout problems, or QA a deck before sharing. Produces a slide-by-slide report with issues ranked by severity and specific fixes. Best used with Claude Opus 4.7 or newer for reliable slide-level vision analysis."
+---
+
+# PPTX Slide Auditor Skill
+
+Runs a systematic visual and structural audit of a PowerPoint presentation — identifying layout issues, text overflow, inconsistent styling, weak visual hierarchy, and slides that will cause problems in a presentation setting. Built to leverage Opus 4.7 vision improvements for pixel-level layout analysis.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The deck** (upload the .pptx file or individual slide screenshots)
+- **Audience** (internal team / executive / external client / conference / investor)
+- **Presentation mode** (presented live / sent to read / shared async on video)
+- **Areas of concern** (optional — e.g. "I think slide 12 is overcrowded")
+
+## Output Structure
+
+### 1. Deck Overview
+| Metric | Result |
+|---|---|
+| Total slides | N |
+| Overall status | Ready / Minor fixes needed / Major revisions required |
+| Readability score | /10 |
+| Visual consistency score | /10 |
+| Most common issue | [Pattern observed across multiple slides] |
+
+### 2. Slide-by-Slide Audit
+
+For each slide with issues:
+
+**Slide N: [Slide title]**
+- Status: Ready / Fix before sending / Major revision
+- Issues found:
+  - [Specific issue with exact location — e.g. "Body text extends beyond the text frame on the right side"]
+  - [Issue 2]
+- Suggested fix: [Specific action — move element, reduce text, resize]
+
+Slides with no issues: just list the slide numbers. Do not write anything else about them.
+
+### 3. Pattern Issues Across the Deck
+
+Issues that repeat across multiple slides:
+
+**[Pattern title — e.g. "Inconsistent body text size"]**
+- Slides affected: [list]
+- Root cause: [master slide issue / manual overrides / mixed templates]
+- Fix: [Single action to resolve across all affected slides]
+
+### 4. Visual Hierarchy Check
+
+| Dimension | Status | Notes |
+|---|---|---|
+| Title consistency (size, font, colour) | Pass / Fail | |
+| Body text readability at presentation distance | Pass / Fail | |
+| Image placement alignment | Pass / Fail | |
+| Whitespace and breathing room | Pass / Fail | |
+| Data visualisation clarity | Pass / Fail / N/A | |
+
+### 5. Audience-Specific Flags
+
+Based on the stated audience:
+
+- **Executive audience:** flag slides with too much text, complex tables, or unclear bottom-line messages
+- **External client:** flag slides with internal jargon, unfinished placeholder text, or confidentiality concerns
+- **Live presentation:** flag slides that will be hard to read from the back of a room
+- **Async/video:** flag slides that assume a presenter voiceover
+
+### 6. Prioritised Fix List
+
+| # | Fix | Slide | Effort | Impact |
+|---|---|---|---|---|
+| 1 | [Specific fix] | Slide N | Low/Med/High | High |
+
+Order by: fixes before handoff (critical) > consistency fixes (high) > polish (medium).
+
+## Quality Checks
+- [ ] Every issue references a specific slide number and location on the slide
+- [ ] Pattern issues are identified separately from slide-specific issues
+- [ ] Fix list is ordered by impact, not by slide order
+- [ ] Audience-appropriate concerns flagged explicitly
+- [ ] Slides without issues are listed briefly, not ignored
+
+## Example Trigger Phrases
+- "Audit this slide deck before my board meeting"
+- "Review this PowerPoint for layout issues"
+- "Check this presentation for consistency problems"
+- "QA my deck before I send it to the client"
+- "What is wrong with slide 7 in this deck?"
+
+## Why This Works Better on Opus 4.7
+Earlier models struggled with precise spatial analysis of slide layouts — they would hallucinate issues or miss obvious overflow problems. Opus 4.7 vision improvements mean coordinates map 1:1 to pixels, making slide-level issue detection reliable without manual screenshot annotation.

plugins/pm-delivery/skills/product-launch-checklist/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: product-launch-checklist
-description: Generates comprehensive pre-launch, launch day, and post-launch checklists for product releases. Use when preparing for a product launch, feature release, or major update. Triggers on "launch checklist", "pre-launch", "launch day", "release checklist", "ship checklist", "go-live checklist".
+description: "Generate a comprehensive pre-launch, launch day, and post-launch checklist for any product release. Use when preparing for a product launch, feature release, or major update. Produces a role-assigned, tiered checklist covering engineering readiness, marketing and comms, support, and post-launch monitoring."
 ---
 
 # Product Launch Checklist Skill
@@ -109,6 +109,14 @@ The skill generates a tiered checklist. Tier 3 launches use only the Essentials
 
 ---
 
+## Quality Checks
+
+- [ ] Launch tier confirmed before generating checklist (scope determines depth)
+- [ ] Go/No-Go decision has a named owner and a specific decision time
+- [ ] Rollback procedure is documented and tested (not just planned)
+- [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once
+- [ ] Post-launch retrospective is scheduled at launch time
+
 ## Guidelines
 
 - The Go/No-Go decision must have a named owner — "the team" is not an owner

plugins/pm-delivery/skills/retro-analysis/SKILL.md

@@ -1,19 +1,20 @@
 ---
 name: retro-analysis
-description: Analyse sprint delivery data and produce a structured retrospective brief
-tool_integration: Jira, Miro
+description: "Analyse sprint delivery data and produce a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint."
 ---
+
 # Retrospective Analysis Skill
 
-## Purpose
 Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
 
 ## Required Inputs
-- Sprint tickets: planned vs. completed
-- Carry-over tickets and reasons
-- Tickets reopened after closing
-- Any incidents or unplanned work
-- Sprint velocity vs. historical average
+
+Ask the user for these if not provided:
+- **Sprint tickets: planned vs. completed**
+- **Carry-over tickets and reasons** (if known)
+- **Tickets reopened after closing** (quality signal)
+- **Any incidents or unplanned work** (scope creep signal)
+- **Sprint velocity vs. historical average** (trend context)
 
 ## Process
 1. Calculate: completion rate, carry-over rate, unplanned work percentage
@@ -21,8 +22,9 @@ Generate a data-grounded retrospective brief that separates facts from feelings,
 3. Note any process or communication breakdowns visible in the data
 4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
 5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
+6. **Validate** — Confirm each prompt is specific to this sprint (not a recycled generic prompt), and that the recommended experiment is concrete and measurable
 
-## Output Format
+## Output Structure
 
 ### Sprint [Number] Retrospective Brief
 
@@ -35,9 +37,17 @@ Generate a data-grounded retrospective brief that separates facts from feelings,
 [2-3 observations grounded in the numbers above]
 
 **Discussion Prompts:**
-- Start: [specific prompt]
-- Stop: [specific prompt]
-- Continue: [specific prompt]
+- Start: [specific prompt based on this sprint's data]
+- Stop: [specific prompt based on this sprint's data]
+- Continue: [specific prompt based on this sprint's data]
 
 **Suggested Experiment for Next Sprint:**
-[One concrete, testable process change]
+[One concrete, testable process change — with a specific success metric]
+
+## Quality Checks
+
+- [ ] Each Start/Stop/Continue prompt names a specific behaviour, not a vague category
+- [ ] The recommended experiment is testable in one sprint
+- [ ] Carry-over analysis identifies the ticket type or cause, not just the count
+- [ ] Data observations don't assign blame — they describe patterns
+- [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?)

plugins/pm-delivery/skills/sprint-brief/SKILL.md

@@ -1,19 +1,20 @@
 ---
 name: sprint-brief
-description: Generate a structured sprint brief from Jira sprint data and goals
-tool_integration: Jira, Slack
+description: "Generate a structured sprint brief from sprint data and goals. Use when asked to write a sprint brief, create a sprint summary, document sprint goals and scope, or produce a team-facing sprint overview. Produces a scannable brief with sprint goal, rationale, grouped work, critical path, risks, and definition of done."
 ---
+
 # Sprint Brief Skill
 
-## Purpose
 Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
 
 ## Required Inputs
-- Sprint name and number
-- Sprint goal (1-2 sentences)
-- Ticket list with owners
-- Known dependencies or blockers
-- Carry-over items from previous sprint
+
+Ask the user for these if not provided:
+- **Sprint name and number**
+- **Sprint goal** (1-2 sentences — flag if too vague)
+- **Ticket list with owners** (or a description of the work)
+- **Known dependencies or blockers**
+- **Carry-over items from previous sprint** (if any)
 
 ## Process
 1. Read sprint goal and check it's specific and measurable — flag if it's too vague
@@ -21,11 +22,12 @@ Produce a clear, scannable sprint brief that every team member — engineer, des
 3. Identify the critical path — which tickets must complete for the sprint goal to be met?
 4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
 5. Note carry-over items and whether they affect this sprint's goal
+6. **Validate** — Confirm the sprint goal is achievable given the ticket scope and capacity. If the critical path items alone would fill the sprint, flag it as overloaded.
 
-## Output Format
+## Output Structure
 
 ### Sprint [Number] Brief — [Dates]
-**Sprint Goal:** [1-2 sentences]
+**Sprint Goal:** [1-2 sentences — specific and measurable]
 **Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
 
 **What We're Building:**
@@ -41,3 +43,11 @@ Produce a clear, scannable sprint brief that every team member — engineer, des
 **Carry-over from Last Sprint:** [List + impact on current goal]
 
 **Definition of Done:** [Specific, agreed criteria for sprint success]
+
+## Quality Checks
+
+- [ ] Sprint goal is specific enough to score pass/fail at the end of the sprint
+- [ ] Critical path items are named — not just "the important ones"
+- [ ] Every risk has a mitigation or owner (not just "this is a risk")
+- [ ] Carry-over items are connected to their impact on this sprint's goal
+- [ ] Definition of Done is agreed criteria, not a task list

plugins/pm-delivery/skills/sprint-planning/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sprint-planning
-description: Structures and facilitates sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning meeting agendas. Triggers on phrases like "plan sprint", "sprint planning", "sprint goal", "sprint backlog".
+description: "Structure and facilitate sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning agendas. Produces a sprint goal, velocity-calibrated backlog, capacity plan, risk flags, and a structured sprint planning meeting agenda."
 ---
 
 # Sprint Planning Skill
@@ -87,3 +87,11 @@ Story points to commit = Historical velocity × Availability factor
 - Recommend the team commits to 80% of available capacity, not 100%
 - If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
 - Highlight any story with unclear ownership as a blocker
+
+## Quality Checks
+
+- [ ] Sprint goal is outcome-focused (not "implement X" — something like "users can do Y")
+- [ ] Team capacity is calculated using actual availability, not theoretical 100%
+- [ ] Every story has an acceptance criterion (flag any that don't)
+- [ ] Stories estimated at 8+ points are flagged for splitting
+- [ ] Carry-overs from last sprint are accounted for in capacity

plugins/pm-delivery/skills/technical-spec-template/SKILL.md

@@ -1,12 +1,20 @@
 ---
 name: technical-spec-template
-description: Creates structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Triggers on "technical spec", "tech spec", "engineering spec", "system design doc", "API spec", "implementation spec".
+description: "Create structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Produces a complete spec with problem statement, proposed solution, data model, API design, alternatives considered, security considerations, testing plan, and rollout strategy."
 ---
 
 # Technical Spec Template Skill
 
 Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature or system description** (what needs to be specced)
+- **Related PRD or product brief** (if available)
+- **Engineering reviewers** (whose sign-off is needed)
+- **Known constraints** (technical limitations, security requirements, performance targets)
+
 ## When to Write a Tech Spec
 
 Write a tech spec when:
@@ -131,3 +139,11 @@ Error codes: [list]
 - Security and privacy sections are never optional for features that touch user data
 - Recommend async review: engineers read first, then a 30-minute sync to resolve questions
 - Keep the spec updated as implementation progresses — stale specs are worse than no specs
+
+## Quality Checks
+
+- [ ] Problem statement contains no solution language
+- [ ] Non-goals explicitly list at least 2 things that might be assumed in scope
+- [ ] At least 2 alternative approaches are documented with reasons for rejection
+- [ ] Security and privacy section is completed for any feature touching user data
+- [ ] All open questions have a named owner and due date (not "TBD")

plugins/pm-discovery/skills/assumption-mapper/SKILL.md

@@ -1,36 +1,59 @@
 ---
 name: assumption-mapper
-description: Extract and risk-rate all hidden assumptions in a product brief or PRD
-tool_integration: Miro
+description: "Extract and risk-rate hidden assumptions in a product brief or PRD. Use when asked to review a product brief for assumptions, audit a PRD for risks, find hidden assumptions, validate product plans, or run an assumption analysis. Produces a prioritised assumption map with confidence and impact scores, recommended validation methods, and critical assumption flags."
 ---
-# Assumption Mapping Skill
 
-## Purpose
+# Assumption Mapper Skill
+
 Surface and prioritize the untested assumptions embedded in any product plan before development begins.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product brief, PRD, or concept description** (even rough notes work)
+- **Stage** (concept / discovery / pre-build / post-launch — affects which assumptions matter most)
+
 ## Process
 1. Read the provided brief, PRD, or concept description
-2. Extract all assumptions across four categories:
+2. Extract assumptions across four categories:
    - **Desirability** (do users want this?)
    - **Feasibility** (can we build it?)
    - **Viability** (will it sustain the business?)
    - **Usability** (can users actually use it?)
-3. For each assumption, score:
+3. Score each assumption:
    - Confidence (1-5): How sure are we this is true?
    - Impact (1-5): How badly does the plan fail if this assumption is wrong?
-   - Priority = Impact minus Confidence (higher score = test this first)
-4. Output a ranked list with recommended validation methods
+   - Priority = Impact − Confidence (higher = test first)
+4. **Validate completeness** — Ensure at least one assumption per category. If a category is empty, re-read the brief looking specifically for that type.
+5. Output a ranked list with recommended validation methods
 
-## Output Format
+## Output Structure
 
 ### Assumption Map: [Feature/Product Name]
-| Assumption | Category | Confidence | Impact | Priority Score | Recommended Validation |
-|------------|----------|------------|--------|----------------|----------------------|
+
+| Assumption | Category | Confidence | Impact | Priority | Validation Method |
+|------------|----------|------------|--------|----------|-------------------|
 | [assumption] | [type] | [1-5] | [1-5] | [score] | [method] |
 
-#### Top 3 Assumptions to Validate First
-[Detailed recommendations for highest-priority items]
+#### Critical Assumptions (Impact 4+ and Confidence 2 or below)
+[Flagged items with detailed validation recommendations]
 
-## Notes
-- Flag any assumption that scores 4+ on Impact and 2 or below on Confidence as CRITICAL
-- Suggest specific research methods: usability test, survey, prototype test, data analysis
+#### Top 3 Assumptions to Validate First
+[Detailed recommendations including specific research method, estimated effort, and what the result would change]
+
+## Example (Partial)
+
+Input: *"We're building a self-serve onboarding flow to reduce time-to-value for SMB customers."*
+
+| Assumption | Category | Confidence | Impact | Priority | Validation Method |
+|------------|----------|------------|--------|----------|-------------------|
+| SMB users can complete onboarding without human help | Usability | 2 | 5 | 3 | Unmoderated usability test (n=8) |
+| Faster onboarding correlates with higher retention | Viability | 3 | 4 | 1 | Cohort analysis of current onboarding times vs. 90-day retention |
+| The current onboarding is the primary reason for slow time-to-value | Desirability | 2 | 4 | 2 | User interviews with recent churned SMB accounts |
+
+## Quality Checks
+
+- [ ] At least one assumption per category (Desirability, Feasibility, Viability, Usability)
+- [ ] All Impact 4+ / Confidence 2− assumptions flagged as CRITICAL
+- [ ] Each validation method is specific (not just "do research" — name the method and sample size)
+- [ ] Priority scores are consistent (Impact − Confidence, higher = more urgent)

plugins/pm-discovery/skills/discovery-interview-guide/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: discovery-interview-guide
-description: Creates structured user discovery interview guides with screener questions, discussion guides, and synthesis frameworks. Use when planning user interviews, customer discovery sessions, Jobs-to-be-Done research, or problem validation. Triggers on "user interview", "discovery interview", "customer research", "JTBD", "problem validation".
+description: "Create a structured user discovery interview guide with screener questions, a discussion guide, and a synthesis framework. Use when planning user interviews, customer discovery sessions, Jobs-to-be-Done research, or problem validation. Produces a complete guide covering warm-up, problem exploration, and a per-session synthesis template."
 ---
 
 # Discovery Interview Guide Skill
@@ -81,6 +81,23 @@ Understand the competitive landscape from their perspective.
 
 ---
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Research topic or question** (what decision will this inform?)
+- **Target participant profile** (role, behaviour, company type)
+- **Session length** (30 / 45 / 60 / 90 minutes)
+- **Number of interviews planned**
+- **Known hypotheses to test or avoid confirming prematurely** (optional)
+
+## Quality Checks
+
+- [ ] No future-tense questions ("would you...") — only past-behaviour questions
+- [ ] Product or solution not mentioned until after pain is confirmed
+- [ ] Questions open-ended (cannot be answered yes/no)
+- [ ] Synthesis template included for per-session notes
+- [ ] Screener questions identify and disqualify wrong participants
+
 ## Guidelines
 
 - Recommend 5–8 interviews to reach thematic saturation for most discovery questions

plugins/pm-discovery/skills/job-story-mapper/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: job-story-mapper
-description: Writes Jobs-to-be-Done (JTBD) job stories and maps customer jobs across functional, social, and emotional dimensions. Use when defining user needs, writing job stories, conducting JTBD research, or reframing features around customer outcomes. Triggers on "job story", "JTBD", "jobs to be done", "when I want to", "user need", "hire a product".
+description: "Write Jobs-to-be-Done (JTBD) job stories and map customer jobs across functional, social, and emotional dimensions. Use when defining user needs, writing job stories, conducting JTBD research, or reframing features around customer outcomes. Produces a job story map with opportunity scoring, pain intensity ratings, and product opportunity analysis."
 ---
 
 # Job Story Mapper Skill
@@ -105,6 +105,15 @@ Rate each job story on:
 
 ---
 
+## Quality Checks
+
+- [ ] Job stories use the "When / I want to / So I can" format (not user story format)
+- [ ] Situation is specific (not "as a user" — a real moment or trigger)
+- [ ] All three dimensions covered: functional, emotional, social
+- [ ] Opportunity score calculated for each job story
+- [ ] Current workaround identified for each high-opportunity story
+- [ ] Product opportunity is distinct from "build the feature" (it's an outcome)
+
 ## Guidelines
 
 - Never write a job story for a feature — write it for the situation that makes the feature valuable

plugins/pm-discovery/skills/user-interview-synthesis/SKILL.md

@@ -1,21 +1,29 @@
 ---
 name: user-interview-synthesis
-description: Synthesise user interview transcripts into structured research findings
-tool_integration: Notion
+description: "Synthesise user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from user interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes, 'so what' implications, and recommended next steps."
 ---
+
 # User Interview Synthesis Skill
 
-## Purpose
 Transform raw interview transcripts into a structured synthesis document that surfaces themes, pain points, and actionable insights.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Interview transcripts or notes** (even rough notes work)
+- **Number of participants and their profiles** (role, company size, context)
+- **Research questions** (what was the study trying to answer?)
+- **Date range** of research (for context)
+
 ## Process
 1. Read all provided transcripts fully before drawing conclusions
 2. Identify recurring themes (minimum 3 mentions to qualify as a theme)
 3. Categorize findings into: Pain Points, Workflow Insights, Feature Requests, Delight Moments
 4. Select 2-3 verbatim quotes per theme that best represent the pattern
 5. Draft "So What" implications for each theme — what does this mean for the product?
+6. **Validate** — Confirm every theme has quotes from at least 3 participants. Flag any insight resting on fewer as low-confidence.
 
-## Output Format
+## Output Structure
 
 ### Research Synthesis: [Study Name]
 **Participants:** [n]
@@ -24,15 +32,21 @@ Transform raw interview transcripts into a structured synthesis document that su
 
 #### Theme 1: [Theme Name]
 - Summary (2-3 sentences)
-- Supporting quotes
+- Supporting quotes (from at least 3 participants)
 - Implication for product
 
 [Repeat for each theme]
 
+#### Low-Confidence Signals (1-2 participants only)
+[Findings worth tracking but not acting on yet — note what further research would confirm or deny]
+
 #### Recommended Next Steps
 [Specific, actionable recommendations based on findings]
 
 ## Quality Checks
-- Every theme must be supported by quotes from at least 3 participants
-- Implications must connect to product decisions, not just observations
-- Avoid researcher bias — let the data lead
+
+- [ ] Every theme is supported by quotes from at least 3 participants
+- [ ] Implications connect to specific product decisions, not just observations
+- [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
+- [ ] Single-source signals are flagged separately, not mixed into main themes
+- [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")

plugins/pm-engineering/.claude-plugin/plugin.json

@@ -1,13 +1,13 @@
 {
   "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
   "name": "pm-engineering",
-  "version": "1.0.0",
-  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record. Structured outputs for engineering teams and technical PMs.",
+  "version": "3.0.0",
+  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook. 14 structured skills for engineering teams and technical PMs.",
   "author": {
     "name": "Mohit Aggarwal",
     "email": "mohit15856@gmail.com"
   },
   "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
   "license": "MIT",
-  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture"]
+  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture", "debugging", "pull-request", "system-design", "changelog", "test-strategy", "runbook", "devops", "cicd", "slo", "error-budget", "onboarding", "oncall", "sre", "reliability"]
 }

plugins/pm-engineering/skills/changelog-generator/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: changelog-generator
+description: "Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes. Optimised for Opus 4.7 and newer models."
+---
+
+# Changelog Generator Skill
+
+Converts raw git commits, a diff summary, or developer release notes into a polished changelog entry — categorised, user-facing, and following Keep a Changelog conventions.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **Commits or release notes** (paste `git log --oneline`, raw commit messages, or a description of what changed)
+- **Version number** (e.g. 2.4.0, v1.0.0-beta.2)
+- **Release date** (or "today")
+- **Audience** (developers using an API / end users of a product / internal team — affects language)
+- **Any breaking changes** (flag these explicitly if known)
+
+## Output Structure
+
+Follow [Keep a Changelog](https://keepachangelog.com) format:
+
+---
+
+## [X.Y.Z] — YYYY-MM-DD
+
+### Breaking Changes ⚠️
+[Only include if there are breaking changes]
+- **[Breaking change]:** [What changed and what it breaks]
+- **Migration required:** [Specific action the user must take]
+
+### Added
+- [New feature or capability, written from the user's perspective]
+- [Another addition]
+
+### Changed
+- [Changed behaviour — what it did before vs. what it does now]
+- [Performance improvement with measurable impact if known]
+
+### Fixed
+- [Bug fixed — describe what was broken, not the fix implementation]
+- [Another fix]
+
+### Deprecated
+- [Deprecated thing] — use [replacement] instead. Will be removed in [version].
+
+### Removed
+- [Removed thing] — was deprecated in [version]
+
+### Security
+- [Security fix — describe the vulnerability class, not exploit details]
+
+---
+
+## Formatting Rules Applied
+
+**Language:** Write for the reader, not the committer. "Add dark mode support" not "implement ThemeProvider with dark palette variant".
+
+**Breaking changes:** Always call these out first with ⚠️. Include a migration path.
+
+**Bug fixes:** Describe what was broken, not what was changed. "Fix crash when user has no profile picture" not "null-check avatar URL before rendering".
+
+**Granularity:** Group related commits into one line. Don't list every micro-commit separately.
+
+**Tone:** Active voice, imperative mood. "Add", "Fix", "Remove" — not "Added", "Fixed", "Removed".
+
+**Empty sections:** Omit any section with no entries. Don't include empty `### Fixed` blocks.
+
+## Quality Checks
+- [ ] Breaking changes are at the top with migration instructions
+- [ ] All entries are user-facing language (no internal variable names or implementation details)
+- [ ] Related commits are grouped into single entries (not listed individually)
+- [ ] Version and date header is correct
+- [ ] Empty sections are omitted
+- [ ] Tone is imperative mood throughout
+
+## Example Trigger Phrases
+- "Write a changelog for version [X]" + [paste commits]
+- "Generate release notes from these commits"
+- "Turn this git log into a CHANGELOG entry"
+- "Write the CHANGELOG.md update for this release"
+- "What changed in this release?" + [paste commit list]

plugins/pm-engineering/skills/cicd-playbook/SKILL.md

@@ -0,0 +1,301 @@
+---
+name: cicd-playbook
+description: "Write a CI/CD pipeline playbook for a service or team. Use when asked to document a CI/CD pipeline, write a deployment process, define release gates, document build and test stages, or create a deployment guide. Produces a structured playbook covering pipeline stages, environment definitions, deployment gates, rollback procedures, and on-call responsibilities."
+---
+
+# CI/CD Playbook Skill
+
+Produce a complete, actionable CI/CD playbook for a service or team — covering everything a new engineer needs to understand, contribute to, and operate the pipeline safely.
+
+A good playbook is not a diagram. It is a document that answers: what runs, when, why, who owns it, and what to do when it breaks.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and brief description
+- **Tech stack** — language, framework, containerisation (Docker, etc.)
+- **Source control** — GitHub / GitLab / Bitbucket, branching strategy
+- **CI platform** — GitHub Actions / CircleCI / Jenkins / BuildKite / other
+- **CD platform / deployment target** — Kubernetes, ECS, Lambda, Heroku, VMs, etc.
+- **Environments** — e.g. dev, staging, production (and any canary / feature environments)
+- **Deployment frequency** — how often does the team ship?
+- **Any existing gates** — manual approvals, smoke tests, feature flags
+- **On-call setup** — who's responsible during deploys?
+
+## Output Format
+
+---
+
+# CI/CD Playbook: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Last updated:** [Date] | **Owner:** [Name / role]
+**Pipeline platform:** [CI tool] → [CD tool / platform]
+
+---
+
+## Overview
+
+[2–3 sentences describing what this service does and why the CI/CD pipeline is structured the way it is. Include the deployment target and how frequently the team ships.]
+
+**Deployment frequency:** [Multiple times per day / Daily / Weekly / On-demand]
+**Average pipeline duration:** [X minutes]
+**Rollback time (p95):** [X minutes]
+
+---
+
+## Pipeline Stages
+
+```
+[Branch push]
+    │
+    ▼
+[1. Build & Lint] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[2. Unit Tests] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[3. Integration Tests] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[4. Security Scan] ──fail──▶ ⚠️ [Block / Warn — specify]
+    │
+    ▼
+[5. Build Artefact / Container Image]
+    │
+    ▼
+[6. Deploy to Staging] ──fail──▶ ❌ Block promotion
+    │
+    ▼
+[7. Smoke Tests (Staging)]
+    │
+    ▼
+[8. Manual Approval Gate] ──(if required)
+    │
+    ▼
+[9. Deploy to Production] ──fail──▶ 🔁 Auto-rollback (if configured)
+    │
+    ▼
+[10. Post-deploy checks]
+```
+
+---
+
+## Stage Definitions
+
+### Stage 1 — Build & Lint
+
+**What runs:** [Build command] + [Linter — e.g. ESLint, golangci-lint, flake8]
+**Trigger:** Every commit to any branch
+**Blocking:** Yes — PR cannot be merged if this fails
+**Typical duration:** [X minutes]
+**Owner if it fails:** PR author
+
+**Common failure causes:**
+- [e.g. Missing dependency — run `npm install` locally before pushing]
+- [e.g. Lint rule violation — run `npm run lint --fix` to auto-fix most issues]
+
+---
+
+### Stage 2 — Unit Tests
+
+**What runs:** [Test command — e.g. `npm test`, `go test ./...`, `pytest`]
+**Coverage gate:** [X]% minimum — pipeline fails below this threshold
+**Trigger:** Every commit
+**Blocking:** Yes
+**Typical duration:** [X minutes]
+
+**Coverage report:** [Where to find it — e.g. uploaded to Codecov, available in CI artifacts]
+
+---
+
+### Stage 3 — Integration Tests
+
+**What runs:** [Test suite description — e.g. "API integration tests against a test database using Docker Compose"]
+**Environment:** [Ephemeral test environment / shared test DB / etc.]
+**Trigger:** Every commit to `main` and feature branches targeting `main`
+**Blocking:** Yes
+**Typical duration:** [X minutes]
+
+**If slow:** [e.g. "Integration tests can be skipped locally with `SKIP_INTEGRATION=true` — never skip in CI"]
+
+---
+
+### Stage 4 — Security Scan
+
+**Tools:** [e.g. Snyk, Trivy, OWASP Dependency Check, Semgrep]
+**What it checks:** [Dependency vulnerabilities / SAST / secrets detection — list what applies]
+**Blocking on:** Critical and High severity findings
+**Non-blocking on:** Medium and Low (flagged, not blocking)
+**Trigger:** Every commit to `main`
+
+**How to handle a flagged vulnerability:**
+1. Check if a fix is available — upgrade the dependency
+2. If no fix available, open a security ticket and add a suppression with justification
+3. Never suppress without a ticket and owner
+
+---
+
+### Stage 5 — Build Artefact
+
+**What is produced:** [Docker image / binary / zip — be specific]
+**Registry:** [ECR / GCR / Docker Hub / Artifactory — URL]
+**Tagging convention:** `[service-name]:[git-sha]` (also tagged `:latest` on `main`)
+**Trigger:** Commits to `main` only (not feature branches)
+
+---
+
+### Stage 6 — Deploy to Staging
+
+**Deployment method:** [e.g. Helm upgrade / kubectl apply / ecs deploy / Terraform apply]
+**Staging URL:** [URL]
+**Trigger:** Automatic on successful artefact build from `main`
+**Who can deploy to staging:** Any engineer (automatic)
+
+**Environment variables:** Managed in [Vault / AWS SSM / GitHub Secrets / etc.]
+**Staging is not production:** [Any differences in config, scale, or data — state them here]
+
+---
+
+### Stage 7 — Smoke Tests (Staging)
+
+**What runs:** [Description — e.g. "10 critical path tests covering login, core API endpoints, and payment flow"]
+**Tool:** [e.g. Playwright / Postman / custom script]
+**Pass criteria:** All smoke tests pass within [X seconds] timeout
+**Blocking:** Yes — production deploy will not proceed if smoke tests fail
+
+**Smoke test suite location:** [Link to test files or folder]
+
+---
+
+### Stage 8 — Manual Approval Gate
+
+**Required for:** [Production deploys / deploys affecting >X% of traffic / deploys to specific regions]
+**Who can approve:** [e.g. Any engineer on the team / Lead engineer / On-call engineer]
+**Approval timeout:** [e.g. 24 hours — auto-cancelled if no approval]
+**How to approve:** [GitHub Actions approve step / Slack command / other — with link]
+
+**When to withhold approval:**
+- Active incident in production
+- Deploy is outside the deployment window (see below)
+- On-call engineer has not been notified
+
+---
+
+### Stage 9 — Deploy to Production
+
+**Deployment method:** [Same as staging or different — specify]
+**Deployment window:** [e.g. Monday–Thursday 09:00–16:00 UTC — no deploys on Fridays or before bank holidays]
+**Canary / progressive rollout:** [Yes — X% initial traffic, full rollout after Y minutes / No — full deploy]
+**Deployment notifications:** [Slack channel — #deployments]
+
+**Who is on-call during deploy:** Deploying engineer is responsible until post-deploy checks pass.
+
+---
+
+### Stage 10 — Post-Deploy Checks
+
+**Automated checks (run for [X minutes] after deploy):**
+- [ ] Error rate: <[X]% (baseline: [Y]%)
+- [ ] P99 latency: <[X]ms (baseline: [Y]ms)
+- [ ] [Key business metric]: within [X]% of baseline
+
+**Where to watch:** [Datadog / Grafana / CloudWatch dashboard — link]
+
+**If a check fails:** See Rollback Procedure below.
+
+---
+
+## Environments
+
+| Environment | Purpose | Deploy trigger | URL | Data |
+|---|---|---|---|---|
+| **Dev** | Local development | Manual | localhost | Seeded test data |
+| **Staging** | Pre-production validation | Automatic (main) | [URL] | Anonymised prod copy |
+| **Production** | Live traffic | Manual approval | [URL] | Live data |
+
+---
+
+## Branching Strategy
+
+**Model:** [Trunk-based / GitFlow / GitHub Flow — describe briefly]
+
+| Branch | Purpose | Who merges | Deploy target |
+|---|---|---|---|
+| `main` | Production-ready code | PR + review | Staging → Production |
+| `feature/*` | Feature development | Author | None (CI only) |
+| `hotfix/*` | Critical production fixes | Lead engineer | Can bypass staging gate with approval |
+
+**Hotfix process:** [Describe when and how to use a hotfix branch — what level of incident justifies bypassing the standard process]
+
+---
+
+## Rollback Procedure
+
+**Automated rollback:** [Yes — triggered if post-deploy error rate exceeds [X]% / No — manual only]
+
+**Manual rollback steps:**
+```bash
+# 1. Identify the last known good image tag
+[command to list recent deployments]
+
+# 2. Deploy the previous version
+[deployment command with previous tag]
+
+# 3. Confirm rollback is live
+[smoke test command or health check URL]
+
+# 4. Notify the team
+[Slack command or template]
+```
+
+**Rollback decision authority:** Any engineer on-call can initiate a rollback without waiting for approval.
+
+**After a rollback:**
+1. Create a post-deploy incident report (see [incident-postmortem skill])
+2. Do not re-deploy the same commit without fixing the root cause
+3. Notify [stakeholder / support team] of the rollback and expected fix timeline
+
+---
+
+## Secrets and Configuration Management
+
+**Secret store:** [Vault / AWS SSM / GitHub Secrets / Doppler — specify]
+**How to add a new secret:**
+1. [Step 1]
+2. [Step 2]
+**Who has access:** [Role or team]
+**Rotation policy:** [How often secrets are rotated and who owns it]
+
+**Never do:** Commit secrets to source control, even in `.env` files. The pipeline includes secret scanning (Stage 4) which will flag this.
+
+---
+
+## Common Failures and Fixes
+
+| Failure | Likely cause | Fix |
+|---|---|---|
+| Build fails with "module not found" | Dependency not installed | Run `[install command]` and commit `lock file` |
+| Integration tests timeout | Test DB not seeded / external service down | Check [service] status; re-run pipeline |
+| Smoke tests fail after staging deploy | Environment variable missing | Check [config location]; compare staging and prod env vars |
+| Production deploy stuck at approval | Approver not notified | Tag `@[on-call handle]` in `#deployments` |
+| Post-deploy error rate spike | Bad deploy / upstream dependency | Check [dashboard]; initiate rollback if >5 min |
+
+---
+
+## On-Call Responsibilities During Deploy
+
+- The deploying engineer is responsible for monitoring post-deploy checks for [X minutes] after a production deploy
+- If you cannot monitor after deploying, hand off explicitly to another engineer in `#deployments`
+- For deploys outside business hours: only hotfixes — always page the on-call engineer before deploying
+
+---
+
+## Quality Checks
+
+- [ ] Every stage has a clear owner when it fails
+- [ ] Rollback procedure is tested — not theoretical
+- [ ] Secrets management section names the actual tool used (not "use secrets management")
+- [ ] Deployment window is specific — not "during business hours"
+- [ ] Post-deploy check thresholds are calibrated to actual baseline metrics

plugins/pm-engineering/skills/code-review-checklist/SKILL.md

@@ -1,114 +1,107 @@
 ---
 name: code-review-checklist
-description: "Generate a tailored code review checklist for any PR, language, or risk level. Use when asked to create a code review checklist, review guidelines, PR standards, or quality gates for a codebase. Produces a structured, prioritised checklist adapted to the specific language, PR type, and risk level."
+description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation. Optimised for Opus 4.7 and newer models."
 ---
 
 # Code Review Checklist Skill
 
-This skill generates a structured, prioritised code review checklist tailored to a specific PR, language, and risk level. It helps reviewers be thorough without being bureaucratic.
+Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.
 
 ## Required Inputs
 
 Ask the user for these if not provided:
-- **Programming language(s)** (e.g. Python, TypeScript, Go, Java)
-- **PR type** (new feature / bug fix / refactor / performance improvement / security patch / infrastructure change)
-- **Risk level** (Low: internal tooling, Low traffic / Medium: user-facing feature / High: payment, auth, data pipeline, public API)
-- **Team context** (optional: team size, seniority mix, any known recurring issues)
+- **Language and framework** (e.g. TypeScript + React / Python + FastAPI / Go)
+- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
+- **Risk level** (low / medium / high / critical)
+- **PR description** (paste the description or link to the PR)
+- **Author context** (new starter / experienced / external contributor)
 
 ## Output Structure
 
-### 1. Checklist Header
+### 1. Review Summary
+**PR:** [Title or reference]
+**Scope assessment:** [Small / Medium / Large / Too large — should be split]
+**Recommended review depth:** [Skim / Standard / Deep dive]
+**Estimated review time:** [Minutes]
 
-**PR:** [Title if provided]
-**Language:** [Language]
-**Type:** [PR Type]
-**Risk Level:** [Low / Medium / High]
-**Estimated review depth:** [Quick scan ~15 min / Standard ~30 min / Deep review ~60 min+]
+### 2. Correctness Checks
 
----
+Language-specific correctness checks — choose based on the language stated:
 
-### 2. The Checklist
+**For TypeScript/JavaScript:**
+- Type definitions match actual usage
+- No implicit `any` in non-test code
+- Async/await used consistently; no unhandled promises
+- Null/undefined handling is explicit
 
-Organise into sections. Mark each item with a priority indicator:
-- 🔴 **MUST** — Blocking. PR should not merge without this.
-- 🟡 **SHOULD** — Important. Address before merge unless there's a good reason not to.
-- 🟢 **CONSIDER** — Nice to have. Worth a comment but not blocking.
+**For Python:**
+- Type hints present on public functions
+- Exception handling is specific (no bare except)
+- Resources are closed (context managers, with blocks)
 
-#### Section A: Correctness
-- 🔴 Does the code do what the ticket/requirement describes?
-- 🔴 Are edge cases handled? (nulls, empty arrays, zero values, max values)
-- 🔴 Are error states handled and surfaced appropriately?
-- 🟡 Does the happy path have adequate test coverage?
-- 🟡 Are failure paths tested?
+**For Go:**
+- Errors are handled or explicitly ignored with a comment
+- Context propagation is correct
+- Goroutine lifetimes are bounded
 
-#### Section B: Security (scale with risk level — expand for High risk PRs)
-- 🔴 [High risk only] Is user input sanitised before use in queries or commands?
-- 🔴 [High risk only] Are auth/permission checks in place?
-- 🟡 Are secrets/credentials committed anywhere? (check .env handling)
-- 🟡 Are third-party dependencies known-safe versions?
+[Include only the section matching the stated language]
 
-#### Section C: Performance
-- 🟡 Are there N+1 query patterns in database calls?
-- 🟡 Is there unnecessary work inside loops?
-- 🟢 Are database queries indexed appropriately?
-- 🟢 Is caching considered where appropriate?
+### 3. Change-Type-Specific Checks
 
-#### Section D: Readability & Maintainability
-- 🟡 Are function and variable names clear without needing a comment to explain them?
-- 🟡 Are complex logic blocks explained with inline comments?
-- 🟢 Is the code consistent with existing patterns in the codebase?
-- 🟢 Are there any magic numbers that should be named constants?
+**For bug fixes:**
+- A test exists that would have caught this bug
+- The fix addresses root cause, not symptom
+- Related code paths checked for the same issue
 
-#### Section E: Language-Specific Checks
-[Populate this section based on the specified language. Examples below:]
+**For features:**
+- Acceptance criteria met
+- Edge cases handled (empty, large, concurrent)
+- Error paths tested, not just happy path
+- Telemetry/logging added for debugging
 
-**Python:**
-- 🟡 Are type hints used on function signatures?
-- 🟡 Are exceptions caught specifically (not bare `except:`)?
-- 🟢 Does it follow PEP 8 (or the team's linter config)?
+**For refactors:**
+- Behaviour unchanged (tests still pass)
+- No scope creep — refactor only
+- Complexity reduced, not just moved
 
-**TypeScript/JavaScript:**
-- 🔴 Are there any `any` types that should be properly typed?
-- 🟡 Are async/await patterns used consistently (no mixed Promise.then chains)?
-- 🟢 Are there unnecessary re-renders in React components?
+**For dependency upgrades:**
+- Breaking changes reviewed
+- Security advisories checked
+- License compatibility verified
 
-**Go:**
-- 🔴 Are errors checked (not ignored with `_`)?
-- 🟡 Are goroutines properly managed to prevent leaks?
-- 🟢 Are exported functions documented?
+[Include only the section matching the stated change type]
 
-#### Section F: PR Hygiene
-- 🟡 Is the PR a reasonable size? (>500 lines diff suggests it should be split)
-- 🟡 Does the PR description explain *why*, not just *what*?
-- 🟢 Are there linked tickets or context in the PR description?
-- 🟢 Are migration scripts or deployment notes included if needed?
+### 4. Risk-Appropriate Checks
 
----
+**Low risk:** basic correctness, style conventions, test coverage
+**Medium risk:** above + rollback plan, monitoring updates, performance considerations
+**High risk:** above + security implications, data migration safety, feature flag/gradual rollout
+**Critical risk:** above + staging validation plan, incident response plan, post-deploy verification checklist
 
-### 3. Risk-Specific Additions
+### 5. Testing Adequacy
+- Unit tests cover new logic
+- Integration tests cover the contract changes
+- Edge cases tested
+- Failure modes tested
+- Performance tests if performance-sensitive
 
-For **High risk** PRs, always add:
-- 🔴 Has this been tested in a staging environment?
-- 🔴 Is there a rollback plan?
-- 🔴 Has a second reviewer been assigned?
+### 6. Review Decision Framework
 
-For **Infrastructure / DB changes**, always add:
-- 🔴 Are migrations backward-compatible?
-- 🔴 Has the migration been tested against production data volume?
+**Approve if:** [2-3 specific conditions based on this PR]
+**Request changes if:** [Specific blockers]
+**Comment (non-blocking) if:** [Items worth discussing but not blocking merge]
 
----
+### 7. Common Pitfalls for This Change Type
+Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.
 
 ## Quality Checks
-
-- [ ] Checklist is tailored to the specified language (not generic)
-- [ ] Risk level is reflected in the MUST vs SHOULD balance
-- [ ] Language-specific section covers the most common issues for that language
-- [ ] PR hygiene section is always present
-- [ ] High-risk additions are included when risk level = High
+- [ ] Checklist is tailored to the stated language (not generic)
+- [ ] Change-type-specific section is included
+- [ ] Risk-appropriate depth matches stated risk level
+- [ ] Decision framework is explicit
 
 ## Example Trigger Phrases
-
-- "Generate a code review checklist for a Python bug fix PR"
-- "Give me a review checklist for a high-risk TypeScript auth change"
-- "What should I check in this Go PR?"
-- "Create PR review standards for our team"
+- "Generate a code review checklist for [PR description]"
+- "What should I check in this pull request?"
+- "Give me a code review checklist for a [language] [change type]"
+- "Review checklist for a high-risk PR in [language]"

plugins/pm-engineering/skills/debugging-log-analyser/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: debugging-log-analyser
+description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when sharing a log, stack trace, error output, or crash dump. Produces a structured diagnosis with probable root cause, affected code path, suggested fix, and next debugging steps. Optimised for Opus 4.7 and newer models."
+---
+
+# Debugging Log Analyser Skill
+
+Parses raw error logs, stack traces, and crash reports into a structured diagnosis with probable root cause, affected code path, and specific next steps — no hand-waving.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **The log / stack trace / error output** (paste directly or describe the error)
+- **Language and framework** (e.g. Node.js + Express, Python + Django, Java Spring, Go)
+- **Context** (what the user was doing when the error occurred)
+- **Environment** (local dev / staging / production)
+- **What they've already tried** (if anything)
+
+## Output Structure
+
+### 1. Error Classification
+**Error type:** [Runtime exception / Build error / Config error / Network error / Memory/resource error / Unknown]
+**Severity:** [Fatal / Critical / Warning / Informational]
+**Recurrence pattern:** [One-off / Intermittent / Consistent / On-startup / Under load]
+
+### 2. Stack Trace Analysis
+
+Walk the stack frame by frame, starting from the origin:
+- **Origin frame:** [File, line, function where it started]
+- **Propagation path:** [How it travelled through the call stack]
+- **Crash point:** [Where it ultimately threw/panicked/exited]
+
+For each significant frame, note whether it is:
+- User code (fixable here)
+- Framework/library code (usually a misuse issue)
+- System/runtime code (usually a config or environment issue)
+
+### 3. Root Cause Assessment
+**Probable root cause:** [1–2 sentence plain English statement]
+**Confidence:** [High / Medium / Low — and why]
+**Alternative causes to rule out:** [If confidence is not high]
+
+### 4. Affected Code Path
+**Entry point:** [Where the triggering call began]
+**Key function(s) involved:** [Specific functions/methods named in the trace]
+**Data that triggered it:** [If inferable from the log — e.g. null value, malformed JSON]
+
+### 5. Suggested Fix
+Provide a concrete, code-level suggestion:
+- What to change (the minimal fix)
+- Why this fixes the root cause
+- Any trade-offs or risks in the fix
+- A short code snippet if helpful
+
+### 6. Next Debugging Steps
+If the root cause is uncertain, provide an ordered list of 3–5 specific debugging actions:
+1. [Specific thing to check — file, log line, config value]
+2. [Specific reproduction step or isolation test]
+3. [Specific tool command — e.g. `strace`, `pprof`, `--verbose`, add logging at X]
+
+### 7. Prevention
+One or two concrete things that would prevent this class of error recurring:
+- Better input validation at [point]
+- Add monitoring/alerting for [condition]
+- Test that covers [scenario]
+
+## Quality Checks
+- [ ] Root cause is specific (not "there might be a null pointer issue")
+- [ ] At least one concrete code-level fix is suggested
+- [ ] Next steps are actionable commands, not vague advice
+- [ ] Language-specific idioms are used correctly
+- [ ] Prevention is proactive (not just "add error handling")
+
+## Example Trigger Phrases
+- "Why is this crashing?" + [paste log]
+- "Can you analyse this stack trace?"
+- "I'm getting this error, what does it mean?"
+- "Debug this log for me"
+- "What's causing this exception?"

plugins/pm-engineering/skills/developer-onboarding-doc/SKILL.md

@@ -0,0 +1,332 @@
+---
+name: developer-onboarding-doc
+description: "Write a developer onboarding document for a service, codebase, or team. Use when asked to write a developer guide, service README, onboarding doc for a new engineer, codebase orientation, or getting-started guide for a technical team. Produces a structured doc covering service overview, architecture, local setup, key patterns, testing, deployment, and who to ask for what."
+---
+
+# Developer Onboarding Document Skill
+
+Produce a complete developer onboarding document for a service or team — covering everything a new engineer needs to be productive within their first week.
+
+A good onboarding doc is not a wiki dump. It answers the questions a new engineer actually has on day one, in the order they'll have them.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Team** responsible for it
+- **Tech stack** — language(s), framework(s), database(s), message queues, etc.
+- **Key external dependencies** — upstream services, third-party APIs
+- **Deployment target** — Kubernetes, ECS, Lambda, bare metal, etc.
+- **Local dev setup** — how to run locally (Docker Compose, local DB, etc.)
+- **Testing approach** — unit, integration, E2E; test commands
+- **Deployment process** — summary of how code gets to production
+- **On-call setup** — who's on-call, how alerts work
+- **Contacts** — tech lead, platform team, related service owners
+
+## Output Format
+
+---
+
+# Developer Onboarding: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Last updated:** [Date] | **Updated by:** [Name]
+
+> If something in this doc is wrong or out of date, fix it now — it will affect every engineer who onboards after you.
+
+---
+
+## What This Service Does
+
+[3–5 sentences. What problem does this service solve? Who calls it, and who does it call? What would break if this service went down?]
+
+**Service type:** [API / Background worker / Event consumer / Data pipeline / etc.]
+**Consumers:** [List internal services or external clients that depend on this service]
+**Dependencies:** [List upstream services, databases, and third-party APIs this service calls]
+
+**Architecture diagram:** [Link or embed — even a rough ASCII diagram helps]
+
+```
+[Caller A] ──→ [This Service] ──→ [Database]
+                      │
+                      └──→ [Downstream Service]
+```
+
+---
+
+## Codebase Orientation
+
+**Repository:** [Link]
+**Main branch:** `[main / master]`
+**Language:** [e.g. Go 1.22 / Node.js 20 / Python 3.12]
+**Framework:** [e.g. Express / FastAPI / Gin / Rails]
+
+### Key directories
+
+```
+[repo-root]/
+├── [src/ or cmd/]          # Application code
+│   ├── [handlers/]         # HTTP handlers / controllers
+│   ├── [services/]         # Business logic
+│   ├── [repository/]       # Database access layer
+│   └── [models/]           # Data models / types
+├── [tests/]                # Test files
+├── [migrations/]           # Database migrations
+├── [scripts/]              # Utility scripts
+├── [.github/workflows/]    # CI/CD pipeline definitions
+└── [docs/]                 # Additional documentation
+```
+
+**Where to start reading:** [Point to 2–3 key files that give the best orientation — e.g. `main.go`, `routes.js`, `app.py`]
+
+### Things that might surprise you
+
+- [Unusual pattern 1 — e.g. "We use event sourcing — state is derived from an event log, not stored directly"]
+- [Unusual pattern 2 — e.g. "Auth is handled by the gateway — this service trusts the `X-User-Id` header"]
+- [Unusual pattern 3 — any non-obvious decisions or legacy choices]
+
+---
+
+## Local Development Setup
+
+**Estimated setup time:** [X minutes for a fresh machine]
+
+### Prerequisites
+
+- [ ] [Tool 1] — version [X] — [install link]
+- [ ] [Tool 2] — version [X] — [install link]
+- [ ] Access to [repo / internal package registry] — request from [who]
+- [ ] [Any secrets or credentials needed] — request from [who]
+
+### Step-by-step setup
+
+```bash
+# 1. Clone the repo
+git clone [repo URL]
+cd [repo-name]
+
+# 2. Copy and configure environment variables
+cp .env.example .env
+# Edit .env — see "Environment Variables" section below
+
+# 3. Start dependencies (database, cache, etc.)
+[docker compose up -d / make deps / etc.]
+
+# 4. Install dependencies
+[npm install / go mod download / pip install -r requirements.txt]
+
+# 5. Run database migrations
+[migration command]
+
+# 6. Start the service
+[start command]
+
+# 7. Verify it's working
+curl http://localhost:[PORT]/health
+# Expected: {"status":"ok"}
+```
+
+**If this doesn't work:** Check [Troubleshooting section below] or ask in `#[channel]`.
+
+### Environment Variables
+
+| Variable | Required | Description | Example |
+|---|---|---|---|
+| `DATABASE_URL` | Yes | Connection string for the primary DB | `postgres://localhost:5432/[db]` |
+| `[VAR_2]` | Yes | [Description] | [Example] |
+| `[VAR_3]` | No | [Description — default value] | [Example] |
+
+**Secrets for local dev:** [Where to get them — e.g. "Run `[command]` to pull from Vault" or "Ask [person] in #[channel]"]
+
+### Useful local commands
+
+```bash
+[start command]           # Start the service
+[test command]            # Run all tests
+[lint command]            # Run linter
+[format command]          # Format code
+[migration command]       # Run pending migrations
+[seed command]            # Seed local database
+```
+
+---
+
+## Testing
+
+**Testing philosophy:** [e.g. "We test at the integration layer — unit tests for pure functions, integration tests for anything touching the DB or external services"]
+
+### Running tests
+
+```bash
+# All tests
+[test command]
+
+# Unit tests only
+[unit test command]
+
+# Integration tests (requires local deps running)
+[integration test command]
+
+# A specific test file or test case
+[test command with filter]
+```
+
+**Test coverage:** [X]% (minimum required to pass CI: [Y]%)
+**Coverage report:** [Where to find it]
+
+### Writing tests
+
+- **Unit tests:** [Where to put them — e.g. alongside source files as `*_test.go`]
+- **Integration tests:** [Where to put them — e.g. `tests/integration/`]
+- **Test database:** [How it works — e.g. "Each test gets a clean transaction that rolls back on teardown — see `tests/helpers/db.go`"]
+- **Mocking:** [Policy — e.g. "We mock at the repository layer — don't mock the DB directly"]
+
+---
+
+## Making Changes
+
+### Branching
+
+[Branch naming convention — e.g. `feature/[ticket-id]-short-description`, `fix/[ticket-id]-short-description`]
+
+### Before opening a PR
+
+- [ ] Tests pass locally
+- [ ] Linter passes (`[lint command]`)
+- [ ] New behaviour has test coverage
+- [ ] Any new environment variables are added to `.env.example` and documented
+- [ ] Database migrations are backward-compatible (old code can run against new schema)
+
+### Code review
+
+- **Reviewers:** [Who to request review from — e.g. "Any engineer on [team]; lead review required for auth changes"]
+- **Expected review time:** [X hours / 1 business day]
+- **PR template:** [Link or auto-generated by GitHub]
+
+### Database migrations
+
+```bash
+# Create a new migration
+[migration create command]
+
+# Apply pending migrations
+[migration up command]
+
+# Roll back last migration
+[migration down command]
+```
+
+**Migration rules:**
+- All migrations must be backward-compatible — old code must run against the new schema
+- Never rename or drop a column in a single migration — do it in two steps (add new, migrate data, drop old)
+- Test your rollback before merging
+
+---
+
+## Deployment
+
+**How code gets to production:** [1–2 sentence summary — link to full CI/CD playbook if it exists]
+
+1. Merge to `main` → automatic deploy to staging
+2. Smoke tests run on staging
+3. Manual approval → deploy to production
+4. Post-deploy monitoring for [X minutes]
+
+**Deployment docs:** [Link to CI/CD playbook or pipeline docs]
+
+**Who can deploy:** [Any engineer / Lead engineer / On-call engineer — specify]
+
+**Deployment channel:** `#[deployments channel]`
+
+---
+
+## Monitoring and Observability
+
+**Dashboard:** [Datadog / Grafana / CloudWatch — link]
+**Logs:** [Log aggregation tool and link — e.g. "Logs are in Datadog under service:[name]"]
+**Traces:** [Tracing tool and link if applicable]
+**Alerts:** [Where alerts fire — e.g. PagerDuty / Slack #alerts-[service]]
+
+**Key metrics to know:**
+- **Error rate:** Should be <[X]% (alert at [Y]%)
+- **P99 latency:** Should be <[X]ms
+- **[Business metric]:** [e.g. "Queue depth should be <100 items"]
+
+---
+
+## On-Call
+
+**On-call schedule:** [PagerDuty / Opsgenie link]
+**Who's on-call now:** [Link to current schedule or `#oncall` channel]
+**Escalation:** [On-call → [team lead] → [EM] — after [X] minutes unacknowledged]
+
+**If you get paged:**
+1. Acknowledge the alert
+2. Check [dashboard link] for the first clue
+3. Common alert runbooks: [link to oncall-runbook or runbook-writer output]
+4. If you can't resolve in [X minutes], escalate to [person/channel]
+
+---
+
+## Key Contacts
+
+| Role | Name | Best way to reach |
+|---|---|---|
+| Tech lead | [Name] | Slack: @[handle] |
+| On-call rotation | [Team] | PagerDuty / `#on-call` |
+| Platform / infra | [Team] | `#platform` Slack channel |
+| Database / DBA | [Name or team] | `#database` Slack channel |
+| [Upstream service] owner | [Name] | Slack: @[handle] |
+
+**Where to ask questions:**
+- General engineering: `#engineering`
+- This service specifically: `#[service-name]`
+- Urgent / production issues: `#incidents`
+
+---
+
+## Troubleshooting
+
+### "The service won't start locally"
+
+1. Check that Docker / dependencies are running: `[command]`
+2. Check `.env` is populated — missing values cause silent failures
+3. Check logs: `[log command]`
+4. Ask in `#[channel]`
+
+### "Tests are failing locally but passing in CI"
+
+- Check your local dependency versions match CI: `[version check command]`
+- Try a clean install: `[clean install command]`
+- Integration tests need local deps running — `[start deps command]`
+
+### "I can't access [internal tool / system]"
+
+- Request access through [process — e.g. Okta self-serve / ask your manager]
+
+### "Something looks wrong in production"
+
+1. Check [dashboard] for the error spike
+2. Check recent deploys in `#deployments`
+3. If it's an active incident, page on-call via [PagerDuty / Slack command]
+
+---
+
+## Further Reading
+
+- [Architecture Decision Records (ADRs)](./docs/decisions/) — why the codebase is the way it is
+- [API documentation](./docs/api/) or [link to external docs]
+- [Incident runbooks](./docs/runbooks/)
+- [CI/CD pipeline documentation](./docs/cicd/)
+- [Team working agreements](./docs/team/)
+
+---
+
+## Quality Checks
+
+- [ ] Local setup instructions work on a fresh machine — tested recently
+- [ ] Environment variables table is complete and accurate
+- [ ] "Things that might surprise you" captures the actual surprises (ask a recent joiner)
+- [ ] On-call section has real links, not placeholders
+- [ ] Contacts are current — team members with real Slack handles
+- [ ] Troubleshooting covers the top 3 actual questions new joiners ask

plugins/pm-engineering/skills/oncall-runbook/SKILL.md

@@ -0,0 +1,364 @@
+---
+name: oncall-runbook
+description: "Write an on-call runbook for a service — covering alert definitions, escalation paths, common incident responses, and on-call handoff procedures. Use when asked to write an on-call guide, create alert runbooks, document escalation procedures, or prepare an on-call handoff document. Produces a structured on-call runbook with per-alert response procedures, escalation matrix, diagnostic commands, and handoff template."
+---
+
+# On-Call Runbook Skill
+
+Produce a complete on-call runbook for a service — giving the on-call engineer everything they need to respond confidently to alerts at 3am, without having to ask anyone for help.
+
+A good on-call runbook reduces mean time to resolution (MTTR) by eliminating the "what do I do first?" problem. It is written for the on-call engineer who has just been paged and needs to act, not for someone calmly reading documentation.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Team** and tech lead name
+- **Alert list** — names of alerts that currently page on-call
+- **Monitoring setup** — Datadog / Grafana / CloudWatch / PagerDuty / etc.
+- **Common failure modes** — what breaks most often, and what fixes it
+- **Escalation contacts** — who to call when on-call can't resolve it
+- **Deployment setup** — can on-call roll back? How?
+- **Service dependencies** — what does this service depend on, and what depends on it?
+
+## Output Format
+
+---
+
+# On-Call Runbook: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**PagerDuty service:** [Link] | **Escalation policy:** [Policy name]
+**Last updated:** [Date] | **Next review:** [Date + 90 days]
+
+> **First time on-call for this service?** Read the [developer onboarding doc] first — it covers the architecture and how things work. This runbook assumes you understand the service.
+
+---
+
+## Quick Reference
+
+**Dashboard:** [Link — the first thing to open when paged]
+**Logs:** [Link — where to find logs]
+**Runbook index:** Jump to the alert that paged you → [Alert list below]
+**Can't resolve in 30 min?** Escalate to: [Name] via [Slack / PagerDuty]
+
+**Rollback command (memorise this):**
+```bash
+[rollback command — e.g. kubectl rollout undo deployment/[service-name]]
+```
+
+---
+
+## Escalation Matrix
+
+| Situation | Escalate to | How | After how long |
+|---|---|---|---|
+| Can't diagnose the alert | [Tech lead name] | Slack DM / Phone | 30 minutes |
+| Alert requires infra change | [Platform team] | `#platform` Slack | Immediately |
+| Customer-facing impact | [CSM / Support lead] | `#incidents` Slack | Immediately (P1) |
+| Database issue | [DBA or data team] | Slack / PagerDuty | Immediately |
+| [Specific dependency] down | [[Dependency] on-call] | PagerDuty / Slack | Immediately |
+| Extended outage (>1 hour) | [Engineering manager] | Phone | 1 hour |
+
+**Contacts:**
+
+| Name | Role | Slack | Phone |
+|---|---|---|---|
+| [Name] | Tech lead | @[handle] | [Number] |
+| [Name] | Engineering manager | @[handle] | [Number] |
+| [Name] | Platform / infra | @[handle] | [Number] |
+| [Platform team] | Infra on-call | `#platform` | PagerDuty |
+
+---
+
+## Service Architecture (Quick View)
+
+```
+[Upstream callers]
+        │
+        ▼
+[This Service]
+        │
+        ├──→ [Primary Database]
+        ├──→ [Cache — e.g. Redis]
+        └──→ [Downstream Service / Queue]
+```
+
+**If this service is down, these are affected:** [List downstream consumers]
+**If these are down, this service is affected:** [List upstream dependencies]
+
+---
+
+## Alert Runbooks
+
+### ALERT: [Alert Name 1 — e.g. HighErrorRate]
+
+**What it means:** [Plain English — e.g. "More than 5% of API requests are returning 5xx errors in the last 5 minutes"]
+**Severity:** P1 / P2 / P3
+**SLO impact:** Yes / No — [If yes: this alert means the error budget is burning at [X]× rate]
+
+**Step 1 — Acknowledge and assess**
+```bash
+# Check current error rate
+[query or dashboard link]
+
+# Check which endpoints are erroring
+[query or command]
+```
+
+**Step 2 — Check recent changes**
+```bash
+# Any deploys in the last hour?
+[command or link to deployment log]
+
+# Recent config changes?
+[where to check]
+```
+
+**Step 3 — Check dependencies**
+```bash
+# Is the database healthy?
+[health check command or link]
+
+# Is [downstream service] healthy?
+[health check command or link]
+```
+
+**Step 4 — Diagnose**
+
+| If you see | It means | Do this |
+|---|---|---|
+| [Error pattern 1] | [Cause] | [Action] |
+| [Error pattern 2] | [Cause] | [Action] |
+| [Error pattern 3] | [Cause] | [Action] |
+| No clear pattern | Unknown cause | Escalate to [name] |
+
+**Step 5 — Fix or mitigate**
+```bash
+# If caused by bad deploy — roll back:
+[rollback command]
+
+# If caused by [specific issue]:
+[fix command]
+
+# If caused by upstream dependency:
+[mitigation — e.g. enable circuit breaker, reduce traffic, etc.]
+```
+
+**After resolving:**
+- [ ] Confirm error rate has returned to baseline
+- [ ] Check no downstream services were affected
+- [ ] If P1: open a post-incident review — see [incident-postmortem skill]
+- [ ] Update `#incidents` with resolution summary
+
+---
+
+### ALERT: [Alert Name 2 — e.g. HighLatency]
+
+**What it means:** [e.g. "P99 response time has exceeded 1s for more than 3 consecutive minutes"]
+**Severity:** P1 / P2 / P3
+**SLO impact:** Yes — latency SLO breach
+
+**Step 1 — Assess scope**
+```bash
+# Check which endpoints are slow
+[query or dashboard — broken down by endpoint]
+
+# Check if latency is across all regions or localised
+[query or command]
+```
+
+**Step 2 — Common causes and fixes**
+
+| Cause | Signal | Fix |
+|---|---|---|
+| Database slow queries | DB latency spike on dashboard | [Check slow query log: `command`] |
+| Cache miss storm | Cache hit rate drops on dashboard | [command or action] |
+| Memory pressure / GC | High memory on service dashboard | [command or action — e.g. restart, scale up] |
+| Upstream service slow | Trace shows time in external call | Escalate to [service] on-call |
+| Traffic spike | Request rate spike on dashboard | [Scale up: `command`] |
+
+**Step 3 — Escalate if unresolved in 20 minutes**
+Page [Tech lead] via PagerDuty / Slack.
+
+---
+
+### ALERT: [Alert Name 3 — e.g. DatabaseConnectionPoolExhausted]
+
+**What it means:** [e.g. "The service has used all available database connections — new requests will fail"]
+**Severity:** P1
+**SLO impact:** Yes — will cause errors immediately
+
+**Immediate mitigation:**
+```bash
+# Restart the service to flush stale connections
+[restart command]
+
+# Check current connection count
+[DB connection query]
+```
+
+**Diagnose root cause after stabilising:**
+```bash
+# Check for long-running queries holding connections
+[query]
+
+# Check if a recent deploy changed connection pool config
+[where to check]
+```
+
+**Resolution:** [e.g. "Increase pool size in config / kill long-running queries / scale the service"]
+
+---
+
+### ALERT: [Alert Name 4 — e.g. QueueBacklogHigh / ConsumerLag]
+
+**What it means:** [e.g. "The message queue backlog exceeds 10,000 messages — consumers are not keeping up"]
+**Severity:** P2
+**SLO impact:** Depends — if queue backs up, downstream systems will receive delayed data
+
+**Step 1 — Check consumer health**
+```bash
+# Are consumers running?
+[command]
+
+# Consumer error rate?
+[dashboard or query]
+```
+
+**Step 2 — Check message contents**
+```bash
+# Are there poison messages causing retries?
+[command to inspect dead-letter queue or failed messages]
+```
+
+**Step 3 — Options**
+
+| If | Then |
+|---|---|
+| Consumers are down | Restart consumers: `[command]` |
+| Poison message in queue | Move to DLQ: `[command]` |
+| Consumers healthy but slow | Scale consumers: `[command]` |
+| Upstream producing too fast | Escalate to [upstream service] owner |
+
+---
+
+### ALERT: [Add additional alerts following the same pattern]
+
+---
+
+## Diagnostic Cheat Sheet
+
+Common commands for quick diagnosis. Paste and run without modification.
+
+```bash
+# Service health
+[health check command]
+
+# Recent logs (last 100 lines)
+[log command]
+
+# Error logs only
+[error log filter command]
+
+# Current pod / instance status
+[kubectl get pods / aws ecs describe-tasks / etc.]
+
+# Restart the service
+[restart command]
+
+# Roll back to previous version
+[rollback command]
+
+# Database connection count
+[DB query]
+
+# Cache hit rate
+[cache stats command]
+
+# Current request rate
+[metrics query]
+```
+
+---
+
+## Useful Dashboard Links
+
+| Dashboard | URL | Use it to |
+|---|---|---|
+| Service overview | [Link] | First stop — error rate, latency, request rate |
+| Database | [Link] | Connection count, slow queries, replication lag |
+| Infrastructure | [Link] | CPU, memory, disk |
+| Queue / consumers | [Link] | Backlog depth, consumer throughput |
+| Upstream dependencies | [Link] | Dependency health at a glance |
+
+---
+
+## Incident Communication
+
+When you declare an incident:
+
+**Post to `#incidents` immediately:**
+```
+🔴 INCIDENT — [Service Name]
+Status: Investigating
+Impact: [Who is affected and how]
+Paged: [Your name]
+Next update: [Time — max 30 min from now]
+```
+
+**Update every 30 minutes while active:**
+```
+🔴 UPDATE — [Service Name] — [Time]
+Status: [Investigating / Identified / Mitigating / Resolved]
+Latest: [One sentence on what you found or did]
+Next update: [Time]
+```
+
+**On resolution:**
+```
+✅ RESOLVED — [Service Name] — [Time]
+Duration: [X minutes]
+Impact: [Summary of who was affected]
+Cause: [One sentence]
+Follow-up: [PIR required? Yes/No — link when created]
+```
+
+---
+
+## On-Call Handoff
+
+Use this template at the end of every on-call shift:
+
+```
+--- ON-CALL HANDOFF: [Service Name] ---
+Date: [Date]
+Outgoing: [Your name]
+Incoming: [Next on-call name]
+
+INCIDENTS THIS SHIFT:
+- [Incident summary — date, duration, cause, resolution, follow-up required]
+
+OPEN ISSUES TO WATCH:
+- [Anything not fully resolved / trending in the wrong direction]
+
+CHANGES SINCE LAST HANDOFF:
+- [Deploys, config changes, infra changes that affect on-call awareness]
+
+RUNBOOK GAPS FOUND:
+- [Anything you had to figure out that isn't documented — please add it]
+
+ANYTHING ELSE:
+- [Notes for incoming on-call]
+```
+
+---
+
+## Quality Checks
+
+- [ ] Every alert that pages on-call has a runbook entry — no alert is missing
+- [ ] Rollback command is accurate and tested recently
+- [ ] Escalation contacts have current phone numbers and Slack handles
+- [ ] Diagnostic commands work — they have been run by at least one person recently
+- [ ] Handoff template is used at every shift change — not just during incidents
+- [ ] "Things I had to figure out that weren't documented" are added to this runbook after every incident

plugins/pm-engineering/skills/pr-description-writer/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: pr-description-writer
+description: "Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance. Optimised for Opus 4.7 and newer models."
+---
+
+# PR Description Writer Skill
+
+Writes structured, reviewer-friendly pull request descriptions from a diff, commit list, or informal notes. Covers the what, why, and how-to-review so reviewers can start immediately.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **What changed** (paste a git diff, `git log --oneline`, or describe the changes in plain English)
+- **Why it was changed** (the problem being solved or feature being added)
+- **How to test it** (any specific steps a reviewer needs to verify it works)
+- **Risk level** (low / medium / high — affects how much reviewer guidance to include)
+- **PR type** (feature / bug fix / refactor / dependency upgrade / config change / hotfix)
+
+## Output Structure
+
+### Title
+A clear, imperative-mood title under 72 characters:
+`[type]: [concise description of what changed]`
+
+Examples:
+- `feat: add rate limiting to the public API`
+- `fix: resolve race condition in session expiry`
+- `refactor: extract payment logic into PaymentService`
+
+### Summary
+2–3 sentences covering:
+- What this PR does (the change)
+- Why it was needed (the problem or goal)
+- The approach taken (at a high level)
+
+### Changes Made
+Bullet list of specific changes — one bullet per logical change, not per file:
+- Added [X] to handle [Y]
+- Refactored [A] to reduce [B]
+- Removed [C] as it was replaced by [D]
+- Updated [E] to fix [F]
+
+### Screenshots / Demo
+[If UI change: include before/after screenshots or a screen recording]
+[If API change: include example request/response]
+[If no visual change: this section can be omitted]
+
+### How to Test
+Step-by-step instructions a reviewer can follow:
+1. [Setup step if needed]
+2. [Action to take]
+3. [What to verify]
+4. [Edge case to check]
+
+Include any specific commands, test data, or environment flags needed.
+
+### Testing Checklist
+- [ ] Unit tests added/updated
+- [ ] Integration tests added/updated
+- [ ] Edge cases covered
+- [ ] Manual testing completed
+- [ ] No regressions in existing tests
+
+### Reviewer Notes
+Flag anything that warrants extra attention:
+- Areas of uncertainty where a second opinion is welcome
+- Deliberate trade-offs made (and why)
+- Out-of-scope items noticed but not addressed
+- Dependencies on other PRs (link them)
+
+### Related
+- Closes #[issue number] (if applicable)
+- Related to #[PR/issue number]
+
+## Quality Checks
+- [ ] Title is imperative mood and under 72 characters
+- [ ] Summary explains what AND why (not just what)
+- [ ] Changes list describes logical changes (not file-by-file changes)
+- [ ] Testing steps are reproducible by someone unfamiliar with the code
+- [ ] Risk-appropriate reviewer guidance is included
+
+## Example Trigger Phrases
+- "Write a PR description for these changes" + [paste diff or description]
+- "Draft a pull request for [feature]"
+- "I need a PR description — here's what I changed"
+- "Summarise these commits into a PR description"
+- "Write the PR body for this branch"

plugins/pm-engineering/skills/runbook-writer/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: runbook-writer
+description: "Write an operational runbook for a service, incident type, or deployment procedure. Use when asked to write a runbook, create an ops guide, document an operational procedure, or prepare an incident response playbook. Produces a runbook with overview, prerequisites, step-by-step procedures, rollback steps, troubleshooting table, and escalation paths. Optimised for Opus 4.7 and newer models."
+---
+
+# Runbook Writer Skill
+
+Produces operational runbooks for services, incident types, and deployment procedures — structured so an on-call engineer who's never touched the system can follow them under pressure.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **What the runbook is for** (e.g. deploying the payment service, responding to a database failover, rotating API keys)
+- **Runbook type** (Deployment / Incident Response / Maintenance / Disaster Recovery)
+- **System/service name and what it does** (brief description)
+- **Audience** (new on-call engineers / experienced SREs / DevOps team)
+- **Tech stack** (where relevant — e.g. Kubernetes, AWS RDS, Node.js)
+
+## Output Structure
+
+---
+**Runbook:** [Runbook Title]
+**Service:** [Service Name]
+**Type:** [Deployment / Incident Response / Maintenance / DR]
+**Last Updated:** [Date]
+**Owner:** [Team or person]
+**Severity:** [P1 / P2 / P3 — if incident-type]
+
+---
+
+### Overview
+**What this runbook covers:**
+[1–2 sentences on the scenario this runbook handles]
+
+**When to use this runbook:**
+- [Specific trigger condition 1 — e.g. PagerDuty alert: `high-error-rate-payment-service`]
+- [Specific trigger condition 2 — e.g. Deploy needed after PR merged to `main`]
+
+**Estimated time to complete:** [X minutes / X–Y minutes depending on outcome]
+
+**Impact if not completed correctly:** [e.g. Payment processing degraded / Data loss risk / Users locked out]
+
+---
+
+### Prerequisites
+
+**Access required:**
+- [ ] [System/tool access — e.g. AWS Console: `production-account`]
+- [ ] [Credential — e.g. `vault read secret/payment-service`]
+- [ ] [VPN / bastion access if needed]
+
+**Tools required:**
+- [ ] [Tool name and version — e.g. `kubectl` v1.28+]
+- [ ] [CLI or dashboard name]
+
+**Before you start:**
+- [ ] [Prerequisite check — e.g. Verify current deployment is healthy in Grafana]
+- [ ] [Prerequisite action — e.g. Announce in `#ops-live` that you're starting]
+
+---
+
+### Procedure
+
+Number every step. Use exact commands. Do not paraphrase tool names or flags.
+
+**Step 1: [Action name]**
+[What you're doing and why — one sentence]
+```bash
+# Exact command
+[command here]
+```
+**Expected output:** `[what should appear if this worked]`
+**If this fails:** [Exact error message to look for] → [What to do, or see Troubleshooting]
+
+**Step 2: [Action name]**
+[Same structure as Step 1]
+
+**Step 3: Verify**
+Always include a verification step after the main procedure:
+```bash
+[verification command]
+```
+**Expected state:** [What a healthy system looks like after this runbook completes]
+
+---
+
+### Rollback
+
+How to undo this procedure if something went wrong:
+
+**Step R1: [Rollback action]**
+```bash
+[rollback command]
+```
+**Verify rollback:** `[command to confirm rollback succeeded]`
+
+---
+
+### Troubleshooting
+
+| Symptom | Likely Cause | Resolution |
+|---|---|---|
+| [Error message or observable symptom] | [Why this happens] | [Exact fix or next step] |
+| [Another symptom] | [Cause] | [Resolution] |
+
+---
+
+### Escalation
+
+If this runbook does not resolve the issue:
+
+| Condition | Who to Contact | How |
+|---|---|---|
+| [e.g. DB unavailable after 10 min] | [DBA on-call] | [PagerDuty policy: `db-oncall`] |
+| [e.g. Payment provider unresponsive] | [Vendor contact] | [Contact in 1Password: `vendor-escalation`] |
+
+**Always update the incident timeline in [tool] before escalating.**
+
+---
+
+### Post-Procedure Checklist
+
+After completing the runbook:
+- [ ] Announce completion in `#ops-live` with outcome
+- [ ] Update the incident ticket / deploy log
+- [ ] Verify alerts have resolved in monitoring dashboard
+- [ ] If this revealed a gap in this runbook — update it now (link to edit process)
+
+---
+
+## Quality Checks
+- [ ] Every step has an exact command (no "run the deploy script")
+- [ ] Expected output is specified for each step so engineer knows if it worked
+- [ ] Failure path is explicit for each step (not "if it fails, investigate")
+- [ ] Rollback procedure is complete and independently testable
+- [ ] Escalation paths name specific contacts, not just team names
+- [ ] Runbook can be followed by someone who has never touched this system
+
+## Example Trigger Phrases
+- "Write a runbook for [service] deployment"
+- "Create an incident response runbook for [alert type]"
+- "I need a runbook for [procedure]"
+- "Document the operational procedure for [X]"
+- "Write an ops playbook for [scenario]"

plugins/pm-engineering/skills/slo-error-budget/SKILL.md

@@ -0,0 +1,231 @@
+---
+name: slo-error-budget
+description: "Define Service Level Objectives (SLOs) and an error budget policy for a service. Use when asked to write SLOs, define SLIs, calculate an error budget, set reliability targets, or create an error budget policy. Produces a complete SLO document with SLI definitions, target calculation, error budget policy, burn rate alerts, and review cadence."
+---
+
+# SLO and Error Budget Skill
+
+Produce a complete, implementable SLO document for a service — covering what to measure, what target to set, how to calculate the error budget, and what to do when it burns.
+
+A good SLO is not a target to hit. It is an agreement about what reliability means for your users — and a framework for making principled trade-offs between reliability and velocity.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and brief description of what it does
+- **Primary users** — who depends on this service and how
+- **User-facing interactions** to protect — e.g. API calls, page loads, transactions
+- **Current reliability data** — error rate, latency, uptime (last 30–90 days if available)
+- **Existing on-call setup** — who responds to alerts?
+- **Deployment frequency** — how often does the team ship?
+- **Any existing SLAs** with customers — these constrain SLO targets
+
+## Key Definitions
+
+Always establish these before writing the SLO:
+
+| Term | Definition |
+|---|---|
+| **SLI** (Service Level Indicator) | The metric being measured — e.g. "% of requests completing successfully in <500ms" |
+| **SLO** (Service Level Objective) | The target for that metric — e.g. "99.5% of requests" |
+| **SLA** (Service Level Agreement) | The contractual commitment to customers — must be looser than the SLO |
+| **Error budget** | The allowed headroom below 100% — the budget for planned and unplanned downtime |
+| **Burn rate** | How fast the error budget is being consumed |
+
+---
+
+## Output Format
+
+---
+
+# SLO Document: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Owner:** [Name / role] | **Approved by:** [Name]
+**Effective date:** [Date] | **Review date:** [Date + 3 months]
+**Version:** [1.0]
+
+---
+
+## Why This SLO Exists
+
+[2–3 sentences. What reliability problem are we solving? What was happening before this SLO that made us need it? What decision-making does this SLO enable?]
+
+---
+
+## Service Overview
+
+**What this service does:** [One sentence]
+**Who depends on it:** [Internal teams / external customers / both — describe]
+**Critical user journeys protected by this SLO:**
+1. [Journey 1 — e.g. "User completes a payment"]
+2. [Journey 2]
+3. [Journey 3]
+
+---
+
+## SLIs — What We Measure
+
+Define one SLI per user journey or reliability dimension. Keep it to 3–5 SLIs maximum.
+
+### SLI 1: [Name — e.g. Request Success Rate]
+
+| Field | Detail |
+|---|---|
+| **What it measures** | [e.g. "% of API requests that return a non-5xx response"] |
+| **Good event definition** | [e.g. "HTTP response with status 2xx or 4xx, completed within 500ms"] |
+| **Bad event definition** | [e.g. "HTTP response with status 5xx, or any response taking >500ms"] |
+| **Measurement source** | [e.g. "Application load balancer access logs / Datadog APM / Prometheus"] |
+| **Measured over** | Rolling 28-day window |
+| **Exclusions** | [e.g. "Health check endpoints excluded / Requests during planned maintenance excluded"] |
+
+### SLI 2: [Name — e.g. Latency]
+
+| Field | Detail |
+|---|---|
+| **What it measures** | [e.g. "P99 response time for the /checkout endpoint"] |
+| **Good event definition** | [e.g. "Request completes in ≤500ms at P99"] |
+| **Bad event definition** | [e.g. "Request takes >500ms at P99"] |
+| **Measurement source** | [Source] |
+| **Measured over** | Rolling 28-day window |
+| **Exclusions** | [Any exclusions] |
+
+### SLI 3: [Name — e.g. Data Freshness / Queue Depth / etc.]
+
+[Same structure]
+
+---
+
+## SLO Targets
+
+| SLI | Target | Window | Error Budget |
+|---|---|---|---|
+| [SLI 1 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+| [SLI 2 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+| [SLI 3 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+
+**How targets were set:**
+- Historical baseline (last 90 days): [X]%
+- Target is set [above / at] historical baseline to [improve reliability / reflect current reality while formalising the commitment]
+- Rationale: [1–2 sentences]
+
+**What 100% is NOT the target:** [Brief explanation of why targeting 100% is counterproductive — it discourages feature development and doesn't reflect user reality]
+
+---
+
+## Error Budget Calculation
+
+**For SLI 1 ([Name]), at [X]% target:**
+
+```
+Error budget = (100% - SLO target) × measurement window
+             = (100% - [X]%) × 28 days × 24 hours × 60 minutes
+             = [Y]% × [Z total minutes]
+             = [N] minutes of allowed failure per 28-day window
+```
+
+**In plain terms:** We can afford [N] minutes of [bad events] in any rolling 28-day window before we breach the SLO.
+
+---
+
+## Burn Rate Alerts
+
+Burn rate = how fast the error budget is being consumed relative to the budget window.
+A burn rate of 1 = consuming the budget at exactly the rate that would exhaust it over 28 days.
+
+| Alert | Burn rate | Window | Severity | Response |
+|---|---|---|---|---|
+| Page (critical) | >14× | 1 hour | P1 | Page on-call immediately — budget exhausted in <2 hours |
+| Page (high) | >6× | 6 hours | P2 | Page on-call — budget exhausted in <5 days |
+| Ticket (warning) | >3× | 3 days | P3 | Create ticket — review at next team meeting |
+| Info | >1× | 28 days | Info | Log only — budget on track to exhaust by end of window |
+
+**Alert implementation:** [Link to alert config in monitoring tool — e.g. Datadog, Prometheus/Alertmanager, Grafana]
+
+---
+
+## Error Budget Policy
+
+This policy defines what to do with the error budget — both when it's healthy and when it's burning.
+
+### When budget is healthy (>50% remaining)
+
+- Feature development and deployments proceed at normal pace
+- The team may take on riskier experiments
+- Reliability improvements are scheduled but not urgent
+
+### When budget is at risk (25–50% remaining)
+
+- Deployment frequency reduced — team ships only well-tested changes
+- One reliability improvement added to current sprint
+- Weekly error budget review added to team standup
+
+### When budget is nearly exhausted (<25% remaining)
+
+- Feature work paused in favour of reliability improvements
+- No new deployments without explicit on-call approval
+- Daily review of error budget burn rate
+- CSM / support notified to manage customer expectations
+
+### When budget is exhausted (0% remaining — SLO breached)
+
+- All feature work stops
+- On-call engineer and engineering manager notified immediately
+- Post-incident review (PIR) required within 5 business days
+- SLO target may be temporarily relaxed (with stakeholder approval) while root cause is addressed
+
+---
+
+## Dashboard and Reporting
+
+**SLO dashboard:** [Link to Datadog / Grafana / etc. dashboard]
+
+**Metrics exposed:**
+- Current SLO compliance (rolling 28-day)
+- Error budget remaining (% and minutes)
+- Burn rate (current and trend)
+- Incident count and MTTR this window
+
+**Reporting cadence:**
+
+| Audience | Frequency | Format |
+|---|---|---|
+| Engineering team | Weekly | Slack summary — #[service]-slo |
+| Engineering manager | Monthly | SLO review meeting |
+| Stakeholders / customers | Quarterly | SLO compliance summary |
+
+---
+
+## Exclusions and Edge Cases
+
+**Planned maintenance:** Error budget is not consumed during pre-announced maintenance windows. Maintenance must be communicated [X hours] in advance via [channel].
+
+**Dependency failures:** If SLO breach is caused by an upstream dependency outside our control, document it — but it still counts against our error budget (our users don't distinguish between our failures and our dependencies' failures).
+
+**Force majeure:** [Policy for cloud provider outages, major infrastructure events]
+
+---
+
+## SLO Review Cadence
+
+| Review | When | Who | Output |
+|---|---|---|---|
+| Error budget review | Weekly | Team | Budget health check — adjust if burning fast |
+| SLO target review | Quarterly | Team + EM | Adjust targets if baseline has shifted significantly |
+| Annual SLO audit | Annually | Team + Stakeholders | Review SLIs — are we measuring the right things? |
+
+**When to change the SLO target:**
+- Historical baseline has improved significantly and target no longer reflects real reliability
+- User feedback indicates the target is misaligned with what users actually experience
+- The SLO is being gamed (metric is healthy but users are unhappy)
+
+---
+
+## Quality Checks
+
+- [ ] SLIs are user-facing — they measure what users experience, not internal system metrics
+- [ ] Good and bad events are precisely defined — no ambiguity about what counts
+- [ ] Targets are based on historical data, not aspirational round numbers
+- [ ] Error budget policy has clear triggers and clear actions — not "discuss as a team"
+- [ ] Burn rate alerts have different windows to catch both fast burns and slow burns
+- [ ] Exclusions are documented so they don't silently inflate the SLO number

plugins/pm-engineering/skills/system-design-interview/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: system-design-interview
+description: "Structure a complete system design answer for interview questions or real architecture sessions. Use when asked to design a system, answer a system design interview question, or architect a solution at scale. Produces a structured answer covering requirements, capacity estimates, high-level design, component deep-dives, trade-offs, and follow-up considerations. Optimised for Opus 4.7 and newer models."
+---
+
+# System Design Interview Skill
+
+Structures a complete, interview-grade system design response — covering clarifying questions, requirements, capacity estimates, architecture, component design, and trade-offs. Works equally well for real architecture sessions.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **The system to design** (e.g. "design a URL shortener", "design a notification service", "design Twitter's feed")
+- **Scope** (interview prep / real architecture decision / practice run)
+- **Scale target** (rough numbers: DAU, requests/sec, data volume — or "assume typical web scale")
+- **Constraints or priorities** (e.g. prioritise availability over consistency, minimise cost, low-latency reads)
+
+## Output Structure
+
+### 1. Clarifying Questions
+Before designing, list 4–6 questions that would change the design. Examples:
+- Read-heavy or write-heavy? (affects caching and DB choice)
+- Global or single-region? (affects latency requirements)
+- Strong or eventual consistency? (affects storage and replication)
+- Acceptable latency targets? (p50 / p99)
+- Any existing infrastructure constraints?
+
+Then proceed with stated assumptions if answering an interview question.
+
+### 2. Functional Requirements
+**Core features (must have):**
+- [Feature 1]
+- [Feature 2]
+- [Feature 3]
+
+**Out of scope (for this design):**
+- [What's deliberately excluded and why]
+
+### 3. Non-Functional Requirements
+| Requirement | Target |
+|---|---|
+| Availability | [e.g. 99.9% / 99.99%] |
+| Latency | [e.g. p95 < 100ms for reads] |
+| Throughput | [e.g. 10k writes/sec peak] |
+| Consistency | [Strong / Eventual] |
+| Durability | [e.g. 99.999% — no data loss] |
+
+### 4. Capacity Estimation
+**Traffic:**
+- DAU: [X]
+- Reads/sec: [X] (peak: [X])
+- Writes/sec: [X] (peak: [X])
+
+**Storage:**
+- Per record size: [X bytes]
+- Records per day: [X]
+- 5-year storage: [X GB/TB]
+
+**Bandwidth:**
+- Inbound: [X MB/s]
+- Outbound: [X MB/s]
+
+### 5. High-Level Architecture
+
+```
+[Client] → [CDN/Edge] → [Load Balancer] → [API Servers] → [Cache] → [DB]
+                                                         → [Message Queue] → [Workers]
+```
+
+Describe each layer in 1–2 sentences explaining its role and technology choice.
+
+### 6. Component Deep-Dive
+
+Pick the 2–3 most critical/interesting components and go deep:
+
+**[Component 1: e.g. Database Layer]**
+- Choice: [Technology and why — e.g. PostgreSQL for ACID guarantees, Cassandra for write throughput]
+- Schema design (high-level): [Key tables/collections and their structure]
+- Indexing strategy: [What gets indexed and why]
+- Replication: [Primary-replica / Multi-primary — and why]
+
+**[Component 2: e.g. Caching Strategy]**
+- Cache type: [Redis / Memcached — and why]
+- What gets cached: [Hot data — e.g. user sessions, frequent reads]
+- Cache invalidation: [TTL / Write-through / Write-behind — trade-offs]
+- Cache hit rate target: [e.g. 95%]
+
+**[Component 3: e.g. API Design]**
+- Key endpoints: [List the 3–5 most important API calls]
+- Authentication: [JWT / OAuth / API keys]
+- Rate limiting: [Where and at what rate]
+
+### 7. Data Flow
+Walk through the two most critical paths end-to-end:
+
+**Write path:** [Step 1 → Step 2 → Step 3...]
+**Read path:** [Step 1 → Step 2 → Step 3...]
+
+### 8. Scaling Bottlenecks and Mitigations
+| Bottleneck | Mitigation |
+|---|---|
+| [e.g. DB write throughput] | [e.g. sharding by user_id, write batching] |
+| [e.g. Hot-key cache misses] | [e.g. local in-process cache, probabilistic early expiry] |
+| [e.g. Single region latency] | [e.g. multi-region deployment, GeoDNS routing] |
+
+### 9. Trade-offs and Alternatives
+Be explicit about what was chosen and what was sacrificed:
+
+| Decision | Why | Trade-off |
+|---|---|---|
+| [e.g. Eventual consistency] | [Higher availability, lower latency] | [Stale reads possible] |
+| [e.g. SQL over NoSQL] | [Complex queries, ACID transactions] | [Harder to shard horizontally] |
+| [e.g. Async processing via queue] | [Decoupled, more resilient] | [Eventual delivery, harder to debug] |
+
+### 10. Follow-up Considerations
+Things to tackle in production but out of scope for this design session:
+- Monitoring and alerting (what metrics matter)
+- Disaster recovery and backup strategy
+- Security (auth, encryption at rest/transit, rate limiting)
+- Cost optimisation at scale
+- Gradual rollout and feature flagging
+
+## Quality Checks
+- [ ] Clarifying questions are design-changing (not generic filler)
+- [ ] Capacity estimates use real numbers (not just "it scales")
+- [ ] At least 2 component deep-dives with technology choices justified
+- [ ] Trade-offs section is honest (not just benefits of chosen approach)
+- [ ] Data flow is described end-to-end for the critical path
+
+## Example Trigger Phrases
+- "Help me answer a system design interview: [question]"
+- "Design [system] for a system design interview"
+- "How would I architect [system] at scale?"
+- "I have a system design interview — the question is [X]"
+- "Design a [URL shortener / chat system / notification service / feed]"

plugins/pm-engineering/skills/test-strategy-doc/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: test-strategy-doc
+description: "Write a test strategy document from a feature spec, PRD, or system description. Use when asked to create a test plan, write a test strategy, define QA approach, or plan testing for a feature or release. Produces a complete test strategy with scope, risk assessment, test types, coverage targets, and a prioritised test case outline. Optimised for Opus 4.7 and newer models."
+---
+
+# Test Strategy Document Skill
+
+Produces a complete test strategy from a feature spec, PRD, or system description — covering scope, test types, risk areas, coverage requirements, and a prioritised test case outline.
+
+## Required Inputs
+
+Ask for these if not provided:
+- **Feature or system being tested** (paste a spec, PRD, or describe it in plain English)
+- **Tech stack** (language, framework, testing tools already in use if known)
+- **Risk level** (low / medium / high / critical — affects depth and coverage requirements)
+- **Timeline** (when does this need to ship — affects prioritisation)
+- **Team context** (who is doing the testing — developers / dedicated QA / both)
+
+## Output Structure
+
+### 1. Test Scope
+
+**In scope:**
+- [Specific functionality being tested]
+- [Integration points covered]
+- [User-facing flows included]
+
+**Out of scope:**
+- [What is deliberately not tested here — and why]
+- [Dependencies owned by other teams]
+
+**Assumptions:**
+- [What the test strategy assumes is true — e.g. mocked services, test data availability]
+
+### 2. Risk Assessment
+
+Identify the highest-risk areas first — these drive depth and coverage:
+
+| Area | Risk Level | Why | Test Priority |
+|---|---|---|---|
+| [e.g. Payment processing] | High | Money movement, regulatory | P0 — exhaustive |
+| [e.g. User authentication] | High | Security boundary | P0 — exhaustive |
+| [e.g. Email notifications] | Medium | External dependency | P1 — happy path + key failures |
+| [e.g. UI copy changes] | Low | Visual only, reversible | P2 — smoke only |
+
+### 3. Test Types and Coverage
+
+**Unit Tests**
+- **What:** Individual functions and methods in isolation
+- **Who writes:** Developer
+- **Coverage target:** [e.g. 80% line coverage on new code / 100% on critical paths]
+- **Tools:** [e.g. Jest, pytest, go test]
+- **Focus areas for this feature:** [Specific logic that needs unit coverage]
+
+**Integration Tests**
+- **What:** Service interactions, database operations, API contracts
+- **Who writes:** Developer / QA
+- **Coverage target:** [All happy paths + key failure modes]
+- **Tools:** [e.g. Supertest, pytest + testcontainers]
+- **Focus areas:** [Specific integrations at risk — e.g. third-party API, DB schema changes]
+
+**End-to-End Tests**
+- **What:** Critical user journeys from browser/client to database
+- **Who writes:** QA / Developer
+- **Coverage target:** [Top N user journeys — list them]
+- **Tools:** [e.g. Playwright, Cypress, Selenium]
+- **Focus areas:** [The 3–5 most critical user flows]
+
+**Performance Tests** *(include only if risk is medium+)*
+- **What:** Load, stress, or latency testing
+- **Targets:** [Specific numbers — e.g. 200 req/sec at p95 < 200ms]
+- **Tools:** [e.g. k6, Locust, JMeter]
+
+**Security Tests** *(include only if risk is high+)*
+- **What:** OWASP Top 10 checks relevant to this feature
+- **Focus:** [Auth bypasses, injection, data exposure]
+- **Tools:** [e.g. OWASP ZAP, manual penetration testing, Snyk]
+
+### 4. Test Case Outline
+
+Priority-ordered list of specific test cases:
+
+**P0 — Must pass before merge:**
+| Test Case | Type | Expected Outcome |
+|---|---|---|
+| [e.g. User can log in with valid credentials] | E2E | [Redirect to dashboard, session created] |
+| [e.g. Invalid login returns 401] | Integration | [Error message displayed, no session] |
+| [e.g. Password is never stored in plain text] | Unit | [bcrypt hash in DB] |
+
+**P1 — Must pass before release:**
+| Test Case | Type | Expected Outcome |
+|---|---|---|
+| [e.g. Login fails gracefully when DB is down] | Integration | [User sees friendly error, 503] |
+| [e.g. Rate limiting blocks after 5 failed attempts] | Integration | [429 returned, account flagged] |
+
+**P2 — Should pass, can ship with known issues tracked:**
+| Test Case | Type | Expected Outcome |
+|---|---|---|
+| [e.g. Login page renders correctly on mobile] | E2E | [Layout matches design] |
+
+### 5. Test Data Requirements
+- [Specific test data needed — e.g. test user accounts with various states]
+- [External service stubs or mocks needed]
+- [Database seed data requirements]
+- [Any PII concerns and how test data handles them]
+
+### 6. Definition of Done
+Testing is complete when:
+- [ ] All P0 test cases pass
+- [ ] All P1 test cases pass
+- [ ] Code coverage meets the stated target
+- [ ] No critical or high severity bugs open
+- [ ] Performance targets met (if applicable)
+- [ ] Security checks completed (if applicable)
+
+## Quality Checks
+- [ ] Risk table is populated and drives test priority (not filled in generically)
+- [ ] P0 test cases cover the highest-risk paths specifically
+- [ ] Each test type names a concrete tool (not "some testing framework")
+- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
+
+## Example Trigger Phrases
+- "Write a test strategy for [feature]" + [paste spec or PRD]
+- "Create a test plan for [system]"
+- "How should we test [feature]?"
+- "I need a QA plan for this sprint"
+- "What tests do we need for [X]?"

plugins/pm-essentials/skills/competitive-analysis/SKILL.md

@@ -1,251 +1,93 @@
 ---
 name: competitive-analysis
-description: Analyze competitors and create competitive landscape documentation. Use when the user asks to analyze competitors, create competitive analysis, compare features with competitors, track competitive landscape, or understand competitive positioning.
+description: "Analyze competitors and create competitive landscape documentation with feature matrices, positioning maps, and strategic recommendations. Use when asked to analyze competitors, create competitive analysis, compare features with competitors, build a competitive landscape, track competitive positioning, or prepare sales battlecard inputs. Produces structured competitor profiles, feature comparison matrix, win/loss analysis, and prioritised strategic recommendations."
 ---
 
 # Competitive Analysis Skill
 
-This skill creates structured competitive analyses for product decision-making.
+Create structured competitive analyses for product decision-making.
 
-## Analysis Framework
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Your product or company** (what you're comparing against)
+- **Competitors to analyze** (or ask to identify the top 3-5)
+- **Analysis focus** (full landscape / feature comparison / pricing / positioning / win-loss)
+- **Audience** (product team / leadership / sales / board)
+
+## Process
+
+1. Gather competitor information from provided inputs and available context
+2. Build profiles for each competitor
+3. Create feature comparison matrix on dimensions that matter to the user's customers
+4. Analyze pricing and positioning
+5. Identify win/loss patterns and strategic implications
+6. **Validate** — Confirm all claims reference a specific source or are flagged as assumptions. Verify feature comparisons note quality differences, not just presence/absence.
+
+## Output Structure
 
 ### 1. Executive Summary
 - **Market Position**: Where we stand relative to competitors
-- **Key Findings**: Top 3-5 insights from analysis
-- **Strategic Implications**: What this means for our roadmap
+- **Key Findings**: Top 3-5 insights
+- **Strategic Implications**: What this means for the roadmap
 
 ### 2. Competitor Profiles
 
-For each major competitor:
-
-**[Competitor Name]**
+For each competitor:
 - **Company Overview**: Size, funding, market position
 - **Target Customer**: Who they serve
-- **Value Proposition**: Their core positioning
-- **Business Model**: How they make money
-- **Strengths**: What they do well
-- **Weaknesses**: Where they fall short
+- **Value Proposition**: Core positioning
+- **Strengths / Weaknesses**: What they do well and where they fall short
 - **Recent Activity**: Major updates, funding, announcements
 
 ### 3. Feature Comparison Matrix
 
 | Feature | Us | Competitor A | Competitor B | Competitor C |
 |---------|-----|--------------|--------------|--------------|
-| Core Feature 1 | ✅ Full | ✅ Full | ⚠️ Limited | ❌ None |
-| Core Feature 2 | ✅ Full | ⚠️ Limited | ✅ Full | ✅ Full |
-| Advanced Feature 1 | ⚠️ Beta | ❌ None | ✅ Full | ❌ None |
+| [Feature] | ✅ Full | ⚠️ Limited | ❌ None | ✅ Full |
 
-Legend:
-- ✅ Full: Complete, production-ready feature
-- ⚠️ Limited/Beta: Partial or in-development
-- ❌ None: Feature not available
+Legend: ✅ Full (production-ready) · ⚠️ Limited/Beta · ❌ None
 
-Include notes on quality/implementation differences where significant.
+Include notes on quality and implementation differences where significant.
 
 ### 4. Pricing Comparison
 
-| Plan Type | Us | Competitor A | Competitor B | Competitor C |
-|-----------|-----|--------------|--------------|--------------|
-| Free/Trial | $0 | $0 | $0 | N/A |
-| Starter | $29/mo | $25/mo | $39/mo | $49/mo |
-| Professional | $79/mo | $89/mo | $79/mo | $99/mo |
-| Enterprise | Custom | Custom | $299/mo | Custom |
+| Plan | Us | Competitor A | Competitor B |
+|------|-----|--------------|--------------|
+| Free/Trial | [price] | [price] | [price] |
+| Pro | [price] | [price] | [price] |
+| Enterprise | [price] | [price] | [price] |
 
-**Pricing Strategy Notes**:
-- How our pricing compares
-- Value perception
-- Packaging differences
+### 5. Market Positioning Map
 
-### 5. Strengths & Weaknesses Analysis
-
-**Our Competitive Advantages:**
-1. [Strength] - [Why it matters]
-2. [Strength] - [Why it matters]
-3. [Strength] - [Why it matters]
-
-**Our Gaps vs. Competition:**
-1. [Gap] - [Impact on customers]
-2. [Gap] - [Impact on customers]
-3. [Gap] - [Impact on customers]
-
-### 6. Customer Perception Analysis
-
-**What Customers Say About Competitors** (from reviews, G2, social media):
-
-**Competitor A:**
-- Most Praised: [Common positive feedback]
-- Most Criticized: [Common complaints]
-- Typical User: [Who uses them]
-
-**Competitor B:**
-- Most Praised: [Common positive feedback]
-- Most Criticized: [Common complaints]
-- Typical User: [Who uses them]
-
-### 7. Market Positioning Map
-
-Describe or diagram positioning on key dimensions:
+Position competitors on two key dimensions relevant to the market:
 - Y-Axis: [e.g., Enterprise vs. SMB]
 - X-Axis: [e.g., Simple vs. Comprehensive]
 
-**Our Position**: [Where we sit and why]
 **Whitespace Opportunities**: [Underserved segments]
 
-### 8. Win/Loss Analysis
+### 6. Win/Loss Analysis
 
-**Why We Win Against Competitors:**
-- Better at: [Specific capabilities]
-- Target customers that value: [What matters]
+**Why We Win:**
+- Better at: [specific capabilities]
+- Customers who value: [what matters to them]
 
-**Why We Lose to Competitors:**
-- When customers need: [Specific requirements]
-- When they prioritize: [What they value]
+**Why We Lose:**
+- When customers need: [specific requirements]
+- Their advantage: [what tips the decision]
 
-### 9. Strategic Implications & Recommendations
+### 7. Strategic Recommendations
 
-**Immediate Actions** (0-3 months):
-1. [Action] - [Rationale]
-2. [Action] - [Rationale]
+**Immediate Actions (0-3 months):**
+1. [Action] — [Rationale]
 
-**Medium-term Strategy** (3-12 months):
-1. [Action] - [Rationale]
-2. [Action] - [Rationale]
+**Medium-term (3-12 months):**
+1. [Action] — [Rationale]
 
-**Long-term Positioning** (12+ months):
-1. [Strategic direction] - [Rationale]
+## Quality Checks
 
-## Analysis Best Practices
-
-**Data Sources:**
-- Competitor websites and documentation
-- G2, Capterra, TrustRadius reviews
-- Customer interviews (especially win/loss)
-- Sales team feedback
-- Social media and community discussions
-- Industry analysts and reports
-- Competitor job postings (reveal strategy)
-
-**Quality Standards:**
-✅ Use recent data (within 3-6 months)
-✅ Include sources for claims
-✅ Focus on verifiable facts over assumptions
-✅ Consider different customer segments
-✅ Update regularly (at least quarterly)
-
-❌ Don't rely solely on competitor marketing
-❌ Don't ignore smaller/emerging competitors
-❌ Don't assume features work well just because they exist
-❌ Don't forget about indirect/substitute competitors
-
-**Ethical Guidelines:**
-- Use only publicly available information
-- Don't misrepresent competitor capabilities
-- Be honest about their strengths
-- Don't disparage competitors personally
-
-## Monitoring Cadence
-
-**Weekly**: Check for major announcements, funding, leadership changes
-**Monthly**: Review feature releases, pricing changes, marketing campaigns
-**Quarterly**: Comprehensive feature comparison, strategic assessment
-**Annually**: Market position analysis, long-term trend evaluation
-
-## Example Analysis Section
-
-```
-## Competitor Profile: DataSync Pro
-
-**Company Overview**
-- Founded 2019, 85 employees, $12M Series A (2023)
-- Fast-growing in mid-market segment
-- Strong presence in Europe
-
-**Target Customer**
-- Mid-market companies (100-1000 employees)
-- Technical users comfortable with APIs
-- Data-intensive operations
-
-**Value Proposition**
-"The fastest way to sync data across your entire stack"
-- Focus on speed and reliability
-- Developer-first approach
-
-**Business Model**
-- Freemium with generous free tier
-- Usage-based pricing above free limits
-- Professional services for enterprise
-
-**Strengths**
-- Superior sync speed (2-3x faster than alternatives)
-- Best-in-class developer documentation
-- Strong developer community (5k+ GitHub stars)
-- Excellent uptime (99.97% vs industry 99.5%)
-- Modern, intuitive API design
-
-**Weaknesses**
-- Limited no-code options (requires technical knowledge)
-- Smaller integration library (45 vs our 120)
-- No dedicated enterprise features
-- Limited customization options
-- Support can be slow (avg 8hr response time)
-
-**Recent Activity**
-- Jan 2026: Released real-time sync capabilities
-- Dec 2025: Raised $12M Series A
-- Nov 2025: Added webhooks and event streaming
-- Hired ex-Stripe engineering lead as CTO
-
-**Strategic Implications**
-- Their focus on speed creates pressure on our performance
-- Developer-first approach winning technical buyers
-- Gaps in no-code and enterprise create opportunities
-- Need to monitor their enterprise moves closely
-```
-
-## Feature Comparison Best Practices
-
-When comparing features:
-
-1. **Group by Category**
-   - Core functionality
-   - Integration capabilities
-   - Analytics/reporting
-   - Security/compliance
-   - Collaboration features
-
-2. **Note Quality Differences**
-   - Not all implementations are equal
-   - Speed, reliability, UX matter
-   - Example: "Both have API, but theirs has rate limits"
-
-3. **Consider the Complete Experience**
-   - Onboarding process
-   - Documentation quality
-   - Support responsiveness
-   - Mobile experience
-
-4. **Identify Gaps That Matter**
-   - What customers actually care about
-   - Not just feature count
-   - Focus on differentiators
-
-## Win/Loss Analysis Template
-
-When analyzing why you win or lose deals:
-
-**Win Against [Competitor]**
-- **Scenarios**: When do we win?
-- **Key Differentiators**: What tips the decision?
-- **Customer Quotes**: What they tell us
-- **Typical Profile**: Who chooses us?
-
-**Loss Against [Competitor]**
-- **Scenarios**: When do we lose?
-- **Their Advantages**: What tips the decision?
-- **Customer Quotes**: What they tell us
-- **Typical Profile**: Who chooses them?
-
-**Lessons Learned**
-- What we need to improve
-- What we need to communicate better
-- Where we should compete differently
+- [ ] All competitor claims cite a source or are flagged as assumptions
+- [ ] Feature comparison notes quality differences, not just feature presence
+- [ ] Strategic recommendations are specific actions, not generic advice
+- [ ] Win/loss analysis reflects customer perspective, not internal assumptions
+- [ ] Different customer segments are considered (not all buyers value the same things)

plugins/pm-essentials/skills/docx-tracked-changes/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: docx-tracked-changes
+description: "Produce properly-formatted tracked changes for a Word document. Use when asked to redline a document, suggest edits to a contract or document, create tracked changes for review, or mark up a document with proposed revisions. Produces a complete redline with insertions, deletions, and margin comments that can be applied to the source document. Best used with Claude Opus 4.7 or newer for reliable tracked changes handling."
+---
+
+# Word Doc Tracked Changes Skill
+
+Produces properly-structured tracked changes for a Word document — insertions, deletions, replacements, and margin comments formatted so they can be applied directly to the source document. Built to leverage Opus 4.7 improvements in .docx redlining and tracked changes generation.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The document** (paste the text or upload the .docx)
+- **Review type** (legal review / copy edit / substantive rewrite / compliance check / plain English rewrite)
+- **Review scope** (full document / specific sections / specific clause type)
+- **Reviewer role** (author / manager / legal counsel / subject matter expert)
+
+## Output Structure
+
+### 1. Redline Summary
+
+**Document:** [Name or identifier]
+**Review type:** [As stated]
+**Reviewer:** [Role]
+**Total changes:** [Insertions: N / Deletions: N / Comments: N]
+**Overall assessment:** [1-2 sentences — is this document close to final, or does it need substantial revision?]
+
+### 2. Top-Level Changes
+
+Changes that affect the meaning or structure of the document:
+
+**Change N — [Section or paragraph reference]**
+- Original: "[Exact original text]"
+- Suggested: "[Proposed new text]"
+- Reason: [Why this change — substantive/legal/clarity]
+
+### 3. Line-by-Line Tracked Changes
+
+For each paragraph that needs changes, format as:
+
+**[Paragraph reference — e.g. "Section 3, Paragraph 2"]**
+
+Original:
+> [Exact original paragraph]
+
+Tracked changes:
+> [Same paragraph with deletions marked as ~~strikethrough~~ and insertions marked as **bold**]
+
+Clean version:
+> [Final clean text after applying changes]
+
+### 4. Margin Comments
+
+Comments that flag issues without proposing a specific wording change:
+
+**Comment N — [Location]**
+"[Comment text — written as the reviewer would write it. Direct, specific, actionable.]"
+
+Comments are for things like:
+- "This clause conflicts with Section 7 — please reconcile"
+- "Missing definition of [term] used throughout"
+- "Confirm figure with finance team"
+
+### 5. Stylistic Edits
+
+Line-level stylistic changes (if scope includes copy editing):
+
+| Location | Before | After | Reason |
+|---|---|---|---|
+| Para 3 | [Text] | [Text] | [Readability/grammar/consistency] |
+
+### 6. Pattern Flags
+
+Issues that repeat across the document:
+
+**[Pattern — e.g. "Passive voice overuse"]**
+- Instances: [count]
+- Examples: [2-3 specific locations]
+- Suggested approach: [How to address]
+
+### 7. Review Completeness
+
+| Review dimension | Covered |
+|---|---|
+| Grammar and syntax | Yes / No |
+| Clarity and readability | Yes / No |
+| Substantive accuracy | Yes / No / N/A |
+| Compliance/legal check | Yes / No / N/A |
+| Consistency with referenced documents | Yes / No / N/A |
+
+### 8. How to Apply These Changes
+
+Instructions for applying the redline:
+
+**In Microsoft Word:**
+1. Enable Track Changes (Review tab → Track Changes)
+2. Apply the changes from Section 3 in order
+3. Add comments from Section 4 using Review → New Comment
+4. Send the redlined document back to the reviewer
+
+**In Google Docs:**
+1. Switch to Suggesting mode (top right pencil icon)
+2. Apply the changes from Section 3
+3. Add comments using the comment button in the margin
+
+## Quality Checks
+- [ ] Every tracked change has the original text preserved exactly
+- [ ] Substantive changes are separated from stylistic changes
+- [ ] Comments are written as the reviewer would write them, not meta-commentary
+- [ ] Pattern issues identified separately from individual changes
+- [ ] Application instructions match the target platform
+
+## Example Trigger Phrases
+- "Redline this contract"
+- "Create tracked changes for this document"
+- "Mark up this document with proposed edits"
+- "Review this and suggest changes in tracked changes format"
+- "Give me a redline version of this draft"
+
+## Why This Works Better on Opus 4.7
+Tracked changes require the model to preserve source text exactly while suggesting alternatives — earlier models would paraphrase the original or lose track of which text was original vs suggested. Opus 4.7 improvements specifically target this workflow.

plugins/pm-essentials/skills/meeting-notes/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: meeting-notes
-description: Structure and format meeting notes following PM best practices. Use when the user needs to create, format, or organize meeting notes, capture action items from meetings, or document discussions and decisions.
+description: "Structure and format meeting notes following PM best practices. Use when asked to create meeting notes, format discussion notes, capture action items, or document decisions from any meeting type. Produces structured notes with decisions, action items (owner + deadline), open questions, and next steps."
 ---
 
 # Meeting Notes Skill
@@ -243,6 +243,14 @@ Template additions:
 **Notes Sent**: January 20, 2026 5:30 PM
 ```
 
+## Quality Checks
+
+- [ ] Every action item has a single named owner (not "team")
+- [ ] Every action item has a concrete deadline
+- [ ] Decisions include context (why the decision was made)
+- [ ] Open questions have an owner and a "by when"
+- [ ] No verbatim transcripts — synthesis only
+
 ## Notes Distribution
 
 **Subject Line Format**: "[Meeting Type] Notes - [Date] - [Key Topic]"

plugins/pm-essentials/skills/prd-template/SKILL.md

@@ -1,12 +1,22 @@
 ---
 name: prd-template
-description: Product Requirements Document creation following proven PM template structure. Use when the user asks to create, write, draft, or help with a PRD, product requirements document, product spec, feature specification, or product documentation for a new feature or product.
+description: "Create a Product Requirements Document following proven PM template structure. Use when asked to write a PRD, product spec, feature specification, or requirements document for a new feature or product. Produces a complete PRD with problem statement, user stories, functional requirements, technical considerations, and success metrics."
 ---
 
 # PRD Template Skill
 
 This skill helps create professional Product Requirements Documents following industry best practices.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature or product name**
+- **Problem being solved** (from the user's perspective)
+- **Target user** (role, context, what they're trying to accomplish)
+- **Success metrics** (how will you know it worked?)
+- **Scope** (MVP vs full vision — what's in and out of scope)
+- **Key stakeholders** (who needs to review and approve)
+
 ## Template Structure
 
 Every PRD should include these sections in order:
@@ -91,6 +101,15 @@ Format: "As a [user type], I want to [action] so that [benefit]"
 - Skip the "why"
 - Forget about accessibility
 
+## Quality Checks
+
+- [ ] Problem statement is written from the user's perspective (not the company's)
+- [ ] Success metrics are specific and measurable
+- [ ] User stories include acceptance criteria
+- [ ] Requirements are testable (not vague)
+- [ ] Open questions are listed explicitly
+- [ ] Implementation plan distinguishes MVP from future phases
+
 ## Example PRD Opening
 
 ```

plugins/pm-essentials/skills/stakeholder-update/SKILL.md

@@ -1,12 +1,21 @@
 ---
 name: stakeholder-update
-description: Create executive stakeholder updates following proven communication frameworks. Use when the user needs to create a status update, progress report, executive summary, or communication for leadership, stakeholders, or executives.
+description: "Create concise executive stakeholder updates using the BLUF (Bottom Line Up Front) framework. Use when asked to write a status update, progress report, project communication, or executive briefing for leadership or stakeholders. Produces a BLUF-led update with status, key metrics, risks, upcoming milestones, and decisions needed — readable in under 2 minutes."
 ---
 
 # Stakeholder Update Skill
 
 This skill creates effective status updates for executives and stakeholders following the BLUF (Bottom Line Up Front) principle.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Project or product being reported on**
+- **Audience** (CEO, board, cross-functional leads, investors — changes depth and format)
+- **Period** (this week / this sprint / this month)
+- **Current status** (on track / at risk / blocked)
+- **Key metrics** and their current values vs. targets
+
 ## Update Structure
 
 ### 1. BLUF (Bottom Line Up Front)
@@ -217,3 +226,11 @@ Only include issues that matter at executive level.
 - Competitive positioning
 - Market opportunities
 - Financial implications
+
+## Quality Checks
+
+- [ ] Update leads with BLUF — status, key takeaway, and action needed before any detail
+- [ ] Every metric has a target comparison (not just a raw number)
+- [ ] Every risk has a mitigation and a "help needed" flag if stakeholder action is required
+- [ ] Decisions needed have specific options and a clear recommendation
+- [ ] Total length is under 1 page / 2 minutes reading time

plugins/pm-essentials/skills/user-research-synthesis/SKILL.md

@@ -1,12 +1,20 @@
 ---
 name: user-research-synthesis
-description: Analyze and synthesize user research findings following PM best practices. Use when the user provides user research data, interview transcripts, survey results, or user feedback that needs to be analyzed, synthesized, or summarized into insights and recommendations.
+description: "Analyze and synthesize user research findings into structured, actionable insights. Use when given user research data, interview transcripts, survey results, or user feedback that needs to be analyzed and summarised. Produces a themed synthesis with prevalence data, supporting quotes, pain points analysis, feature request prioritisation, and recommended next steps."
 ---
 
 # User Research Synthesis Skill
 
 This skill helps analyze user research data and transform it into actionable insights following a structured methodology.
 
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Research data** (transcripts, notes, survey results, or summary bullets)
+- **Research method** (interviews, surveys, usability tests, etc.)
+- **Number of participants** and their profiles (role, context)
+- **Research questions** the study aimed to answer
+
 ## Synthesis Framework
 
 ### 1. Data Collection Overview

plugins/pm-figma/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-figma",
+  "version": "1.0.0",
+  "description": "Figma skills for PMs and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter across the full Figma design lifecycle.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["figma", "design", "product-management", "design-system", "components", "prototype", "handoff", "ux"]
+}

plugins/pm-figma/skills/figma-annotation-guide/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: figma-annotation-guide
+description: "Generate structured developer handoff annotations for a Figma screen or component. Use when asked to write Figma annotations, create dev handoff notes, document a Figma design for developers, or write specs for a screen. Produces a complete annotation set covering interactions, states, spacing, accessibility, and edge cases."
+---
+
+# Figma Annotation Guide Skill
+
+Produces a complete set of developer handoff annotations for a Figma screen or component — the notes that turn a visual design into a buildable spec.
+
+## Required Inputs
+
+- **Screen or component description** (describe or summarise what was designed)
+- **Platform** (iOS / Android / Web / React Native)
+- **Interaction type** (static / interactive / animated / form)
+- **Developer audience** (mobile / frontend / full-stack)
+
+## Output Structure
+
+### 1. Screen/Component Overview
+Name, purpose, entry points, exit points.
+
+### 2. Interaction Annotations
+
+**[Element name]**
+- Default state: [Visual description]
+- On tap/click: [Exact action — API call, state change, navigation]
+- Loading state: [Description]
+- Success state: [What happens after]
+- Error state: [What error looks like and user options]
+- Disabled condition: [When and why]
+
+### 3. State Inventory
+
+| Element | States Required |
+|---|---|
+| [Element] | Default, Hover, Active, Disabled, Loading, Error, Empty |
+
+Flag missing designs: "Warning: Error state not designed — needed before build"
+
+### 4. Spacing and Layout Notes
+Fixed vs fluid elements, scroll behaviour, breakpoints, safe areas.
+
+### 5. Content and Copy Rules
+Character limits, dynamic vs static content, truncation rules, empty states.
+
+### 6. Accessibility Annotations
+Touch targets, screen reader labels, focus order, colour contrast, motion preferences.
+
+### 7. Edge Cases and Developer Questions
+- [ ] [Unresolved question for developer to flag]
+
+## Quality Checks
+- [ ] Every interactive element has all states defined
+- [ ] State inventory flags missing designs
+- [ ] Accessibility covers touch targets and screen reader labels
+- [ ] Empty states specified
+- [ ] Edge cases listed as actionable questions
+
+## Example Trigger Phrases
+- "Write dev annotations for this Figma screen"
+- "Create developer handoff notes for [screen/component]"
+- "Document this design for the engineering team"
+- "Write the Figma spec for [feature]"
+- "What should I annotate before handing off this design?"

plugins/pm-figma/skills/figma-component-audit/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: figma-component-audit
+description: "Audit a Figma component library for consistency, coverage gaps, and naming issues. Use when asked to audit components, review a design system, check component consistency, identify missing components, or assess Figma library health. Produces a structured audit report with issues prioritised by impact, naming recommendations, and a fix plan."
+---
+
+# Figma Component Audit Skill
+
+Produces a structured audit of a Figma component library — identifying inconsistencies, naming problems, coverage gaps, and prioritised recommendations.
+
+## Required Inputs
+
+- **Component list or description** (paste component names or describe what exists)
+- **Product type** (mobile app / web app / desktop / multi-platform)
+- **Design system maturity** (new / growing / mature / legacy)
+- **Primary concern** (optional)
+
+## Output Structure
+
+### 1. Audit Summary
+
+| Dimension | Status | Score |
+|---|---|---|
+| Naming consistency | Red/Amber/Green | /10 |
+| Component coverage | | /10 |
+| Variant completeness | | /10 |
+| Documentation | | /10 |
+| Overall health | | /10 |
+
+**Verdict:** What is the state of this library and the single most important thing to fix?
+
+### 2. Naming Issues
+
+For each problem:
+**Issue: [Problem type]**
+- What is happening: [Specific examples]
+- Why it matters: [Impact on designers and developers]
+- Fix: [Exact naming convention to adopt]
+- Examples: Before / After
+
+Naming convention to enforce:
+- Components: PascalCase (NavigationBar)
+- Variants: Lowercase with slashes (size/large, state/hover)
+- Pages: All caps (COMPONENTS, FOUNDATIONS)
+
+### 3. Coverage Gaps
+
+| Missing Component | Priority | Why Needed |
+|---|---|---|
+| [Component] | High/Medium/Low | [Use case] |
+
+### 4. Variant Completeness Check
+
+| Component | Default | Hover | Active | Disabled | Error | Missing |
+|---|---|---|---|---|---|---|
+| [Button] | Yes | Yes | No | Yes | No | Active, Error |
+
+### 5. Prioritised Fix Plan
+
+| # | Fix | Effort | Impact | Do First? |
+|---|---|---|---|---|
+| 1 | [Fix] | Low/Med/High | High | Yes |
+
+## Quality Checks
+- [ ] Naming recommendations have before/after examples
+- [ ] Coverage gaps are relevant to the product type
+- [ ] Fix plan is ordered by impact-to-effort ratio
+- [ ] Variant completeness covers all interactive states
+
+## Example Trigger Phrases
+- "Audit my Figma component library"
+- "Review our design system for consistency issues"
+- "What components are we missing in our Figma library?"
+- "Our component naming is a mess — help me fix it"
+- "Do a health check on our Figma components"

plugins/pm-figma/skills/figma-design-brief/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: figma-design-brief
+description: "Write a structured design brief for a Figma design task from a product requirement or feature request. Use when asked to write a design brief, create a design spec for Figma, turn a PRD into design requirements, or brief a designer on what to build in Figma. Produces a brief with goals, scope, user flows, components needed, constraints, and success criteria."
+---
+
+# Figma Design Brief Skill
+
+Converts a product requirement or feature request into a structured design brief — everything a designer needs to open Figma and start building confidently.
+
+## Required Inputs
+
+- **Feature or requirement** (paste PRD snippet, ticket, or describe the feature)
+- **User goal** (what is the user trying to accomplish?)
+- **Platform** (iOS / Android / Web / Responsive / All)
+- **Existing components available** (optional)
+- **Timeline** (when does design need to be ready?)
+
+## Output Structure
+
+### 1. Brief Header
+Feature, PM, Designer, Platform, Design due, Dev handoff dates.
+
+### 2. What We Are Designing and Why
+- **The goal:** [One sentence — user problem being solved]
+- **Context:** [2-3 sentences. Why now? What triggers this?]
+- **Success looks like:** [Specific observable outcome]
+
+### 3. User Flows to Design
+
+**Flow N: [Flow name]**
+- Entry point: [Where user starts]
+- Steps: [Numbered key steps]
+- Exit point: [Where flow ends]
+- Edge cases: [empty state, error state, loading state]
+
+### 4. Screens Required
+
+| Screen | New / Update | Notes |
+|---|---|---|
+| [Screen] | New | [Key requirement] |
+
+### 5. Components Needed
+
+| Component | In library? | Action |
+|---|---|---|
+| [Component] | Yes/No/Needs variant | Use/Create/Extend |
+
+### 6. Constraints and Requirements
+- Must haves: [Non-negotiable constraints]
+- Must avoid: [Design patterns to not use]
+- Accessibility: [WCAG level, touch target sizes]
+
+### 7. Open Questions
+- [ ] [Question — with owner]
+
+## Quality Checks
+- [ ] Goal is outcome-focused (not "design the feature")
+- [ ] All flows include edge cases
+- [ ] Components table identifies create vs reuse
+- [ ] Constraints include accessibility requirements
+- [ ] Open questions have owners
+
+## Example Trigger Phrases
+- "Write a design brief for [feature]"
+- "Turn this PRD into a Figma design brief"
+- "Brief the designer on what to build for [requirement]"
+- "Create a design spec for [feature] for Figma"
+- "What does the designer need to know to design [feature]?"

plugins/pm-figma/skills/figma-design-critique-pm/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: figma-design-critique-pm
+description: "Run a PM-perspective design critique focused on product outcomes, user goals, and business requirements — not aesthetics. Use when asked for a PM design critique, a product review of a design, feedback on a Figma design from a product perspective, or when you want to critique a design without being a designer. Produces structured outcome-based feedback tied to user goals and business metrics."
+---
+
+# Figma Design Critique — PM Perspective Skill
+
+This skill is specifically for product managers critiquing designs — focused on whether the design achieves the user goal and business outcome, not whether it looks good. Different from the general design-critique skill which covers UX aesthetics; this one centres product thinking.
+
+## Required Inputs
+
+- **Design description or screen summary**
+- **User goal** (what is the user trying to accomplish?)
+- **Business goal** (what outcome does the product need?)
+- **Original requirements** (what was this supposed to do?)
+- **Key metric** (what would move if this design works?)
+
+## Output Structure
+
+### 1. PM Critique Summary
+User goal, business goal restated.
+**Verdict:** On track / Mostly on track / Needs rethinking
+
+One-paragraph summary: what works from a product perspective, and the single most important thing to address.
+
+### 2. Goal Alignment Check
+
+| Goal | Design supports it? | Evidence |
+|---|---|---|
+| [User goal] | Yes/Partial/No | [Specific observation] |
+| [Business goal] | Yes/Partial/No | [Observation] |
+| [Key requirement] | Yes/Partial/No | [Observation] |
+
+### 3. PM Feedback (Outcome-Focused)
+
+Every concern must tie to an outcome. "I do not like this layout" is not PM feedback. "This layout puts the primary action below the fold, which will reduce mobile conversion" is PM feedback.
+
+**[Concern] — High/Medium/Low impact**
+- Observation: [Neutral description of what the design does]
+- User impact: [What this means for the user goal]
+- Business impact: [What this means for the metric]
+- Evidence basis: [Research/data/analogous patterns/hypothesis — be honest]
+- Question for designer: [What to explore — not a directive]
+
+### 4. What the Design Does Well
+2-4 specific things working well from a product perspective — with evidence. Not "colours are nice" but "primary CTA is the most prominent element, aligning with conversion goal." Always include this section.
+
+### 5. Questions Before Next Iteration
+
+| Question | Who answers | Why it matters |
+|---|---|---|
+| [Question] | Designer/PM/Eng | [Impact] |
+
+### 6. PM Recommendation
+Approve / Approve with changes (list) / Revise and re-review (one focus area only)
+
+## PM Critique Rules
+- Never reference aesthetics as reason for feedback — only outcomes
+- "I prefer" is not feedback — "users are likely to" is feedback
+- Lead with what is working before what is not
+- Ask questions before giving directives
+- One primary recommendation — not a redesign in bullets
+
+## Quality Checks
+- [ ] Every concern tied to user or business outcome
+- [ ] What is working section is genuine and specific
+- [ ] Questions section included (not just directives)
+- [ ] PM recommendation is explicit
+- [ ] Evidence basis stated honestly
+
+## Example Trigger Phrases
+- "Give me a PM critique of this design"
+- "Review this design from a product perspective"
+- "What product feedback do I have on this Figma design?"
+- "Critique this design without being a designer"
+- "Does this design achieve the user goal?"

plugins/pm-figma/skills/figma-design-qa/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: figma-design-qa
+description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
+---
+
+# Figma Design QA Skill
+
+Runs a systematic pre-handoff QA check on a Figma design — catching issues that cause engineering back-and-forth before they become expensive.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature or screen being QA-d** (describe what has been designed)
+- **Platform** (iOS / Android / Web)
+- **Design system** (custom / Material / HIG / None)
+- **Handoff tool** (Figma Inspect / Zeplin / Storybook / Direct link)
+- **QA depth** (quick 15 min / standard 30 min / thorough 60 min)
+
+## Output Structure
+
+QA Report: [Feature] | [Date] | [Platform]
+**Overall status:** Ready / Minor fixes needed / Not ready
+
+### Section 1: File Hygiene
+- All layers named semantically (no "Rectangle 12")
+- No unused/hidden layers in final frames
+- Components from library (not detached copies)
+- All text uses text styles (not manual font settings)
+- All colours use styles or variables (not hex overrides)
+- Frames named to match screen map
+- No leftover prototype wires to wrong frames
+
+### Section 2: Component Usage
+- All buttons use library component
+- All inputs use library component
+- All icons from approved icon library
+- No custom components that should be in library
+- Variants used correctly (right size, state, type)
+
+### Section 3: Content and Copy
+- No placeholder text (Lorem ipsum) in final designs
+- All copy reviewed and approved
+- Realistic content used (not "User Name")
+- Long text edge cases tested
+- Error messages are human-readable
+- Empty states have copy and CTA
+
+### Section 4: States and Coverage
+- Default, Loading, Empty, Error, Success states
+- Interactive elements have hover/active (web)
+- Disabled states designed where applicable
+
+### Section 5: Accessibility
+- All text meets WCAG AA contrast (4.5:1 body, 3:1 large)
+- UI components meet 3:1 contrast against background
+- Touch targets minimum 44x44pt iOS / 48x48dp Android
+- Focus states for keyboard/switch navigation (web)
+- Information not conveyed by colour alone
+- Icons have text labels or accessible names annotated
+
+### Section 6: Handoff Readiness
+- Dev annotations on non-obvious interactions
+- Spacing uses Auto Layout (not absolute positioning)
+- Images/assets exported at correct resolutions
+- Design matches approved requirements
+- Link to prototype included
+
+### Issues Found
+For each fail:
+**[Issue] — Blocking / Fix before handoff / Fix in next iteration**
+- What: [Specific layer/screen/element]
+- Fix: [Exact action needed]
+- Owner: [Designer/PM/Both]
+
+### Handoff Decision
+Status, signed off by, date.
+
+## Quality Checks
+- [ ] All 6 sections completed
+- [ ] Every fail has a specific description and fix action
+- [ ] Blocking issues separated from minor ones
+- [ ] Handoff decision is explicit
+
+## Example Trigger Phrases
+- "QA this Figma design before handoff"
+- "Run a pre-handoff check on [feature] design"
+- "Is this Figma design ready for engineering?"
+- "Do a design QA on [screen/feature]"
+- "What needs fixing before we hand this off?"

plugins/pm-figma/skills/figma-design-review/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: figma-design-review
+description: "Run a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, do a PM design review, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and explicit approval status."
+---
+
+# Figma Design Review Skill
+
+Runs a structured PM design review — checking that a design meets product requirements, covers all user flows, and is ready for engineering. This is a requirements-and-outcomes review, not an aesthetic critique.
+
+## Required Inputs
+
+- **Design description or screen summary**
+- **Original requirements** (PRD snippet, ticket, or acceptance criteria)
+- **User flow being designed**
+- **Review stage** (concept / mid-fidelity / pre-handoff final)
+
+## Output Structure
+
+### 1. Review Header
+Feature, review stage, reviewed by, date.
+**Overall status:** Approved / Approved with changes / Needs revision
+
+### 2. Requirements Coverage Check
+
+| Requirement | Covered? | Notes |
+|---|---|---|
+| [Requirement from PRD] | Yes/No/Partial | [Specific observation] |
+
+Missing coverage summary: [Requirements not addressed — must resolve before approval]
+
+### 3. User Flow Completeness
+
+| Flow step | Designed? | Issues |
+|---|---|---|
+| [Step] | Yes/No/Partial | [Issue] |
+| Error state | Yes/No | |
+| Empty state | Yes/No | |
+| Loading state | Yes/No | |
+
+### 4. PM Concerns
+
+**[Concern] — Blocking / Should fix / Nice to fix**
+- What: [Specific observation]
+- Why it matters: [Business or user impact — not aesthetic preference]
+- Suggested resolution: [What PM wants to see]
+
+### 5. Open Questions
+
+| Question | Owner | Needed by |
+|---|---|---|
+| [Question] | Designer/Eng/PM | [Date] |
+
+### 6. Approval Decision
+Approved / Approved with changes (list) / Needs revision (focus area + next review date)
+
+## Quality Checks
+- [ ] Every requirement assessed
+- [ ] All flow states checked (error, empty, loading)
+- [ ] Concerns are outcome-focused not aesthetic
+- [ ] Open questions have owners
+- [ ] Approval status is explicit
+
+## Example Trigger Phrases
+- "Review this Figma design against the requirements"
+- "Do a PM design review for [feature]"
+- "Check if this design meets the product spec"
+- "Is this design ready to hand off to engineering?"
+- "What is missing from this design before we can build it?"

plugins/pm-figma/skills/figma-prototype-plan/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: figma-prototype-plan
+description: "Plan prototype interactions and flows for user testing in Figma. Use when asked to plan a Figma prototype, set up prototype interactions, define what to prototype for a user test, or prepare a Figma prototype for usability testing. Produces a prototype scope, interaction specification, test task scripts, and Figma setup guide."
+---
+
+# Figma Prototype Plan Skill
+
+Plans what to prototype in Figma and how — scoping to what the user test needs, defining every interaction, and setting up the test scenarios. Prevents over-building and ensures the prototype answers the research question.
+
+## Required Inputs
+
+- **Research question** (what are you trying to learn?)
+- **Feature or flow being prototyped**
+- **Prototype fidelity** (low wireframe / mid functional / high pixel-perfect)
+- **Testing method** (moderated in-person / moderated remote / unmoderated)
+- **Number of test tasks**
+
+## Output Structure
+
+### 1. Prototype Scope
+
+**In scope:** [Flows with real interactions — specific screens listed]
+**Out of scope:** [Screens to show as static — not worth building as interactive]
+**Rationale:** Prototypes should be the minimum needed to test the hypothesis.
+
+### 2. Interaction Specification
+
+**Interaction N: [Description]**
+- Trigger: Tap/Swipe/Hover/Form submit
+- Element: [Figma layer name]
+- Destination: [Figma frame name]
+- Animation: Instant/Dissolve/Push left/Push right/Slide up
+- Timing: [ms]
+- Reset after: Yes/No
+
+### 3. Prototype Flow Diagram
+
+```
+[Start frame]
+  -> Tap "Action"
+[Next frame]
+  -> Tap "Complete" -> [Success frame]
+  -> Tap "Cancel"   -> [Back to start]
+```
+
+### 4. Test Task Scripts
+
+**Task N: [Title]**
+
+Scenario (read to participant):
+"[Realistic scenario giving context without directing the click path]"
+
+Observing:
+- [What to watch for]
+
+Success when: [Specific trigger]
+
+### 5. Figma Setup Guide
+- Starting frame: [Name]
+- Device preview: [Device]
+- Prototype settings: background colour, show device, type
+- Sharing: Can view link, reset process between participants
+
+### 6. Build vs Fake Table
+
+| Element | Build | Fake | Notes |
+|---|---|---|---|
+| Primary CTA flow | Yes | | Core to research |
+| Secondary nav | | Yes | Not being tested |
+| Error state | Yes | | Testing recovery |
+
+## Quality Checks
+- [ ] Scope limited to what the research question requires
+- [ ] Every interaction has a named destination frame
+- [ ] Task scripts are scenario-based (not "click on X")
+- [ ] Success criteria defined for each task
+- [ ] Reset process defined for between participants
+
+## Example Trigger Phrases
+- "Plan the Figma prototype for our user test on [feature]"
+- "What interactions do I need to build for this prototype?"
+- "Help me set up a Figma prototype for [research question]"
+- "Write the test task scripts for our [feature] prototype"
+- "What should I prototype vs leave as static screens?"

plugins/pm-figma/skills/figma-spacing-system/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: figma-spacing-system
+description: "Design a spacing and layout token system for a Figma design system. Use when asked to create a spacing system, define layout tokens, set up a grid system, build a spacing scale, or establish layout foundations for a Figma file. Produces a complete spacing scale, grid definition, component spacing conventions, and Figma implementation guide."
+---
+
+# Figma Spacing System Skill
+
+Produces a complete spacing and layout token system — the foundation that makes a design system consistent and developer handoff unambiguous.
+
+## Required Inputs
+
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Base unit** (4px / 8px — default to 8px)
+- **Design system name** (for token naming)
+- **Component density** (compact / standard / comfortable)
+- **Grid requirements** (or "derive from platform standard")
+
+## Output Structure
+
+### 1. Base Unit
+[4px or 8px] with rationale. All values must be multiples.
+
+### 2. Spacing Scale
+
+| Token | Value | Use case |
+|---|---|---|
+| spacing.none | 0px | Removing space intentionally |
+| spacing.xs | 4/8px | Icon padding, tight labels |
+| spacing.sm | 8/12px | Internal component padding compact |
+| spacing.md | 12/16px | Internal component padding standard |
+| spacing.lg | 16/24px | Section padding, card internal |
+| spacing.xl | 24/32px | Between components |
+| spacing.2xl | 32/48px | Section separation |
+| spacing.3xl | 48/64px | Page-level breaks |
+| spacing.4xl | 64/96px | Hero sections |
+
+### 3. Layout Grid
+
+Mobile (375px): 4 columns, margin [value], gutter [value]
+Tablet (768px): 8 columns, margin [value], gutter [value]
+Desktop (1440px): 12 columns, margin [value], gutter [value], max content width [value]
+
+### 4. Component Spacing Conventions
+
+| Context | Token | Example |
+|---|---|---|
+| Button horizontal padding | spacing.md | Left/right |
+| Button vertical padding | spacing.sm | Top/bottom |
+| Card internal padding | spacing.lg | All sides |
+| Input padding | spacing.sm vertical, spacing.md horizontal | |
+| Icon gap from label | spacing.xs | |
+| Section gap | spacing.xl | |
+
+### 5. Figma Implementation
+1. Create SPACING page documenting each token visually
+2. Resources > Variables > create Number collection named Spacing
+3. Apply variables to Auto Layout padding/gap values
+4. Share token names with engineers as-is or via Tokens Studio
+
+### 6. Anti-Patterns to Avoid
+- Values not on the scale (13px, 22px) — round to nearest token
+- Absolute pixel values in components instead of tokens
+- Mixing 4px and 8px base units in the same product
+
+## Quality Checks
+- [ ] All token values are multiples of the base unit
+- [ ] Scale covers xs through 4xl
+- [ ] Grid defined for all relevant breakpoints
+- [ ] Component conventions cover common decisions
+- [ ] Figma implementation steps included
+
+## Example Trigger Phrases
+- "Create a spacing system for our Figma design system"
+- "Define our spacing tokens for Figma"
+- "Set up a grid and spacing scale for [product]"
+- "What spacing values should we use in our design system?"
+- "Help me build the layout foundation for our Figma file"

plugins/pm-figma/skills/figma-user-flow-planner/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: figma-user-flow-planner
+description: "Plan user flows and screen states for a Figma design before any designing starts. Use when asked to plan a user flow, map out screens for a feature, define screen states, plan a Figma file structure, or work out what needs to be designed before opening Figma. Produces a complete flow map with all screens, states, entry/exit points, and a suggested Figma page structure."
+---
+
+# Figma User Flow Planner Skill
+
+Plans what needs to be designed before a pixel is touched — mapping all screens, states, entry points, and edge cases so designers do not discover missing states mid-build.
+
+## Required Inputs
+
+- **Feature or task being designed**
+- **User type** (who performs this flow?)
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Starting point** (where does the user begin?)
+- **Known edge cases** (optional)
+
+## Output Structure
+
+### 1. Flow Overview
+Feature, user, goal, entry points, success exit, failure exits.
+
+### 2. Screen Map
+
+| # | Screen name | Type | Triggered by | Notes |
+|---|---|---|---|---|
+| 1 | [Screen] | New/Modal/Drawer/Toast | [What triggers] | [Considerations] |
+
+Screen types to cover: entry, happy path, loading, success, error (network/validation/permission), empty, first-time/onboarding, edge cases.
+
+### 3. State Matrix
+
+**[Screen name]**
+
+| State | Trigger | Visual change | Action available |
+|---|---|---|---|
+| Default | Page load | [Description] | [What user can do] |
+| Loading | User taps action | Skeleton/spinner | None |
+| Error | API failure | Error message | Retry/Go back |
+| Empty | No data | Empty state | [CTA] |
+
+### 4. Decision Points
+
+**Decision: [Name]**
+- If yes: [Screen N]
+- If no: [Screen X]
+
+### 5. Suggested Figma File Structure
+
+```
+Feature name/
+- Cover
+- Flow Map
+- Happy Path
+- Error States
+- Empty States
+- Edge Cases
+- Handoff
+```
+
+### 6. What Not to Design Yet
+[Explicit out-of-scope items — prevents scope creep]
+
+## Quality Checks
+- [ ] All three state types covered: loading, error, empty
+- [ ] All decision points mapped with both branches
+- [ ] Entry points include all realistic user paths
+- [ ] Out-of-scope section is explicit
+- [ ] Figma file structure matches screen map
+
+## Example Trigger Phrases
+- "Plan the user flow for [feature] in Figma"
+- "What screens do I need to design for [feature]?"
+- "Map out the states for [feature] before we start designing"
+- "Help me structure my Figma file for [feature]"
+- "What do we need to design before handing this to the developer?"

plugins/pm-figma/skills/figma-variant-matrix/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: figma-variant-matrix
+description: "Define component variants and states systematically for Figma. Use when asked to plan component variants, define states for a component, set up a Figma variant matrix, or work out what properties a component needs before building it. Produces a complete variant matrix with all properties, values, and combinations needed."
+---
+
+# Figma Variant Matrix Skill
+
+Defines all variants, properties, and states a component needs before building it in Figma — preventing missing variants discovered after the component is already used across 40 screens.
+
+## Required Inputs
+
+- **Component name** (Button, Card, Input, Badge, Navigation item, etc.)
+- **Component purpose** (what does it do, where is it used?)
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Design system context** (standalone / part of existing system)
+
+## Output Structure
+
+### 1. Component Overview
+Name, category (Interactive/Display/Layout/Form/Navigation/Feedback), used in contexts.
+
+### 2. Variant Properties
+
+| Property | Values | Notes |
+|---|---|---|
+| Type | Primary, Secondary, Tertiary, Destructive | |
+| Size | Large, Medium, Small | |
+| State | Default, Hover, Active, Disabled, Loading | |
+| Icon | None, Leading, Trailing, Only | |
+
+Total combinations: [N]. Flag if over 50 — consider splitting into multiple components.
+
+### 3. State Definitions
+
+For each state, list only what changes from Default:
+- Default: [Full visual spec]
+- Hover (web): [Delta from default]
+- Active/Pressed: [Delta]
+- Disabled: [Delta — use layer-level properties, not opacity on whole component]
+- Loading: [What replaces label, interactive during loading?]
+- Error (forms): [Border colour, helper text, icon changes]
+
+### 4. Anatomy Breakdown
+
+| Layer name | Purpose | Required? | Notes |
+|---|---|---|---|
+| container | Background and bounds | Yes | |
+| label | Text | Conditional | Hide when icon-only |
+| icon-leading | Leading icon slot | No | |
+
+### 5. Token Mapping
+
+| Property | Token | Fallback |
+|---|---|---|
+| Background default | color.brand.primary | #hex |
+| Border radius | radius.medium | 8px |
+
+### 6. Build Order
+1. Default state, most common variant
+2. Convert to component, add properties
+3. Size variants
+4. State variants
+5. Type variants
+6. Icon slot variants last
+
+## Quality Checks
+- [ ] All interactive states defined
+- [ ] Total variant count calculated, flagged if over 50
+- [ ] Every layer named semantically
+- [ ] Token mapping covers all visual properties
+- [ ] Disabled state uses layer-level properties not opacity
+
+## Example Trigger Phrases
+- "Define the variants for a [component] in Figma"
+- "What states does my [component] need?"
+- "Help me plan the variant matrix for [component]"
+- "Set up the Figma properties for a [button/card/input]"
+- "What are all the combinations I need for my [component]?"

plugins/pm-finance/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-finance",
+  "version": "1.1.0",
+  "description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence, Tax Planning Checklist. Turn numbers into board-ready narratives, explain variances, structure pitch decks, generate DD checklists, and review year-end tax planning opportunities.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["finance", "financial-model", "budget", "variance", "pitch-deck", "due-diligence", "investor", "tax", "tax-planning", "year-end"]
+}

plugins/pm-finance/skills/budget-variance-analysis/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: budget-variance-analysis
+description: "Produce a structured budget variance analysis from actual vs budget figures. Use when asked to analyse budget variances, explain underspend or overspend, write a variance commentary, or investigate why actuals differ from plan. Produces a categorised variance table with root cause analysis and management commentary."
+---
+
+# Budget Variance Analysis Skill
+
+Produces a complete variance analysis from numbers through to root cause explanation and management commentary.
+
+## Required Inputs
+- **Actuals and budget figures** (paste as table or describe line by line)
+- **Period** (month / quarter / YTD)
+- **Materiality threshold** (e.g. £10k or 5%)
+- **Known reasons for variances** (if any)
+- **Audience** (CFO / board / management / auditor)
+
+## Output Structure
+
+### 1. Variance Summary Table
+
+| Line Item | Budget | Actual | Variance £ | Variance % | F/A |
+|---|---|---|---|---|---|
+| Revenue | | | | | |
+| Cost of Sales | | | | | |
+| Gross Profit | | | | | |
+| Opex | | | | | |
+| EBITDA | | | | | |
+
+F = Favourable | A = Adverse
+
+### 2. Material Variance Commentary
+
+For each variance above threshold:
+
+**[Line item] — £[amount] F/A ([%])**
+- **Root cause:** [Specific explanation — not "timing" without detail]
+- **Permanent or timing?** Will this reverse next period?
+- **Management action:** What is being done
+- **Forecast impact:** Does this change full-year outlook?
+
+### 3. Top 3 Variances Requiring Attention
+Ranked by materiality and strategic significance.
+
+### 4. Forecast Revision
+Does the full-year forecast need updating? State revised expectation and key assumptions.
+
+### 5. Executive Summary
+3-4 sentences of management commentary suitable for a board pack.
+
+## Quality Checks
+- All variances above threshold explained
+- Root causes specific (not vague)
+- Favourable/Adverse correctly labelled
+- Forecast impact stated for material variances
+
+## Example Trigger Phrases
+- "Write a variance analysis for these actuals vs budget: [paste]"
+- "Explain why we are over budget on [cost line]"
+- "Write the variance commentary for our finance review"
+- "Produce a budget vs actual analysis for Q[N]"

plugins/pm-finance/skills/financial-due-diligence/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: financial-due-diligence
+description: "Generate a financial due diligence checklist and analysis framework for any investment, acquisition, or partnership. Use when asked for a due diligence checklist, M&A financial review, investment analysis framework, or vendor financial assessment. Produces a document request list, key analytical questions, red flags checklist, and a summarised financial health assessment."
+---
+
+# Financial Due Diligence Skill
+
+Produces a structured financial due diligence framework — document request list and analytical questions — for any investment, acquisition, or significant commercial relationship.
+
+## Required Inputs
+- **Transaction type** (acquisition / investment / partnership / supplier / fundraise)
+- **Stage of diligence** (initial screening / full DD / confirmatory)
+- **Target company type** (startup / SME / listed / subsidiary)
+- **Key concerns** (optional — e.g. revenue recognition, customer concentration)
+
+## Output Structure
+
+### 1. Document Request List
+
+**Financial Statements**
+- Audited accounts for last 3 years
+- Management accounts for current year (monthly)
+- Board-approved budget and latest reforecast
+- 3-year financial model with assumptions
+
+**Revenue**
+- Revenue by customer (top 20, % of total)
+- Revenue by product/segment
+- Contracted vs recurring vs one-off breakdown
+- Churn and renewal data
+
+**Costs**
+- Cost of sales breakdown
+- Headcount by department with compensation detail
+- Top 10 supplier contracts
+
+**Cash and Debt**
+- Bank statements (12 months)
+- Debt schedule with covenants and maturity
+- Working capital analysis
+
+**Tax**
+- Last 3 years tax returns
+- Any open enquiries
+- R&D tax credit claims
+
+### 2. Key Analytical Questions
+
+**Revenue quality:** Is revenue growing organically? What % is truly recurring? Customer concentration risk?
+
+**Margin analysis:** Gross margin trend over 3 years? One-off items inflating EBITDA? Normalised EBITDA?
+
+**Cash conversion:** Does profit convert to cash? Cash conversion cycle? Working capital red flags?
+
+**Debt and liabilities:** Net debt position? Contingent liabilities? Covenant headroom?
+
+### 3. Red Flags Checklist
+- Revenue concentration over 30% in one customer
+- Declining gross margins without explanation
+- EBITDA-to-cash conversion below 70%
+- Auditor qualifications or emphasis of matter
+- Related party transactions not at arm length
+- Aggressive revenue recognition
+- Growing debtor days with no explanation
+
+### 4. Summary Output Template
+- Revenue quality: [Assessment]
+- Margin sustainability: [Assessment]
+- Cash generation: [Assessment]
+- Balance sheet risk: [Assessment]
+- Overall: Green Strong / Amber Acceptable / Red Material concerns
+
+## Example Trigger Phrases
+- "Give me a financial due diligence checklist for [company type]"
+- "What documents should I request for financial DD?"
+- "Build a DD framework for our Series A investment"

plugins/pm-finance/skills/financial-model-narrative/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: financial-model-narrative
+description: "Turn financial model outputs into a clear written narrative. Use when asked to write a financial narrative, explain a financial model, summarise a P&L, or translate spreadsheet numbers into a board-ready story. Produces an executive narrative with key insights, drivers, and forward-looking commentary."
+---
+
+# Financial Model Narrative Skill
+
+Turns financial model outputs into a clear, structured written narrative suitable for board packs, investor updates, or management reporting.
+
+## Required Inputs
+- **Financial data** (paste key figures: revenue, costs, margins, EBITDA, cash)
+- **Period covered** (month / quarter / annual / multi-year)
+- **Audience** (board / investors / management / bank / internal)
+- **Key message** (what is the headline story?)
+- **Actuals vs budget / prior period?** (comparison context)
+
+## Output Structure
+
+### 1. Headline Summary
+3-5 sentences. The financial story in plain English. Lead with the most important insight — not "revenue was X" but what that figure means.
+
+### 2. Revenue
+- Performance vs prior period / budget
+- Key drivers: what caused the movement
+- Risks or opportunities in the revenue line
+
+### 3. Costs and Margins
+- Gross margin: % and trend
+- Key cost movements and why
+- EBITDA performance and drivers
+- One-off items clearly flagged
+
+### 4. Cash and Balance Sheet
+- Cash position and movement
+- Runway (for startups)
+- Key working capital movements
+
+### 5. Variance Analysis
+For each significant variance:
+
+**[Line item] — Over/Under by [amount]**
+- **Cause:** [Plain English explanation]
+- **Permanent or temporary?** One-time / Structural
+- **Action being taken:** [If applicable]
+
+### 6. Forward-Looking Commentary
+- Expected next period
+- Key risks to forecast
+- Key opportunities
+- Any reforecast or guidance change
+
+## Writing Rules
+- Never just restate a number — always explain what it means
+- Flag variances over 10% automatically
+- Use past tense for actuals, conditional for forecast
+- One insight per paragraph
+
+## Quality Checks
+
+- [ ] Headline summary leads with meaning, not just the number
+- [ ] Every significant variance has a cause, permanence, and action
+- [ ] Forward-looking commentary includes specific risks and opportunities
+- [ ] Audience-appropriate language (board vs investor vs management)
+- [ ] One-off items clearly distinguished from recurring items
+
+## Example Trigger Phrases
+- "Write a financial narrative for these results: [paste numbers]"
+- "Turn this P&L into a board narrative"
+- "Write the finance section of our board pack"
+- "Explain these financial results in plain English"

plugins/pm-finance/skills/investor-pitch-deck/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: investor-pitch-deck
+description: "Build the narrative and slide structure for an investor pitch deck. Use when asked to create a pitch deck, investor presentation, fundraising deck, or startup pitch. Produces a slide-by-slide structure with narrative beats, key messages, and what each slide must prove to an investor."
+---
+
+# Investor Pitch Deck Skill
+
+Builds the complete narrative and slide structure for an investor pitch deck — focused on what investors need to see, not what founders want to show.
+
+## Required Inputs
+- **Company name and one-line description**
+- **Stage** (Pre-seed / Seed / Series A / Series B)
+- **Ask** (how much raising and what for)
+- **Key metrics** (revenue, growth, users, retention)
+- **Target investors** (generalist / sector-specific / angels)
+- **Deck length** (10 / 12 / 15 slides)
+
+## Output Structure
+
+For each slide:
+- **What this slide must prove** (the investor question it answers)
+- **Content guidance** (specific, not generic)
+- **Common mistake to avoid**
+
+---
+
+**Slide 1: Cover** — Proves you can say what you do in one sentence.
+**Slide 2: Problem** — Proves the problem is real, painful, and large. Lead with the human problem, not market size.
+**Slide 3: Solution** — Proves your solution is meaningfully better. Focus on outcome, not features.
+**Slide 4: Product** — Proves this is real and works. Show the actual product.
+**Slide 5: Traction** — Proves people want this. Show retention and revenue, not signups.
+**Slide 6: Market** — Proves the market is large enough. Use bottoms-up TAM where possible.
+**Slide 7: Business Model** — Proves you understand unit economics. Include CAC and LTV.
+**Slide 8: Go-To-Market** — Proves you can acquire customers efficiently. Focus on what is actually working.
+**Slide 9: Competition** — Proves you understand the landscape. Never say "no competitors."
+**Slide 10: Team** — Proves this team can execute this opportunity. One sentence per person, specific.
+**Slide 11: Financials** — Proves you understand your business. Show assumptions, not just projections.
+**Slide 12: The Ask** — Proves you know exactly what you need. Specific use of funds and 18-month milestones.
+
+## Narrative Principles
+- Every slide answers one investor question
+- Investors decide go/no-go on slides 1-5 — front-load evidence
+- Keep to 10-12 slides for a first meeting
+
+## Quality Checks
+
+- [ ] Each slide answers one specific investor question
+- [ ] Slides 1-5 front-load the strongest evidence
+- [ ] Traction slide shows retention and revenue, not just signups
+- [ ] Competition slide does not say "no competitors"
+- [ ] Ask slide specifies use of funds and 18-month milestones
+- [ ] TAM is bottoms-up where possible
+
+## Example Trigger Phrases
+- "Build a pitch deck structure for [company]"
+- "Help me structure my Series A deck"
+- "What slides should my investor pitch have?"

plugins/pm-finance/skills/tax-planning-checklist/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: tax-planning-checklist
+description: "Generate a structured tax planning checklist and review framework for any individual or business context. Use when asked to review tax planning, prepare for year-end tax, check tax efficiency, or identify tax-saving opportunities. Produces a checklist of considerations, common reliefs, and a review framework. Not a substitute for qualified tax advice."
+---
+
+# Tax Planning Checklist Skill
+
+Produces a structured tax planning review framework — identifying common reliefs, year-end planning opportunities, and potential gaps. Always recommend a qualified tax adviser for implementation.
+
+WARNING: Tax law changes frequently and varies by jurisdiction. This checklist produces a framework for discussion, not tax advice. Always verify with a qualified accountant or tax adviser before taking action.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Entity type** (individual / sole trader / limited company / partnership / trust)
+- **Jurisdiction** (UK / US / EU / Other — defaults to UK if unspecified)
+- **Approximate income or revenue** (to identify relevant thresholds)
+- **Key concerns** (optional — e.g. capital gains, pension, inheritance, R&D credits)
+- **Time horizon** (year-end planning / ongoing / specific event like sale or exit)
+
+## Output Structure
+
+---
+
+# Tax Planning Checklist — [Entity Type] — [Tax Year / Period]
+
+**Jurisdiction:** [UK / US / Other]
+**Entity type:** [Individual / Limited company / etc.]
+**Key thresholds to note:** [List relevant tax-year thresholds — e.g. personal allowance, basic rate band, VAT threshold]
+
+---
+
+## Section 1: Income and Allowances
+
+- [ ] Personal allowance fully utilised? (UK: £12,570 — check if taper applies above £100k income)
+- [ ] Dividend allowance used where relevant? (UK: £500 2024/25)
+- [ ] Savings interest allowance reviewed?
+- [ ] Salary/dividend split optimised for owner-managed companies?
+- [ ] Any income timing opportunities before year-end?
+- [ ] Spouse or partner allowances — any transfer or use opportunities?
+
+---
+
+## Section 2: Pension and Retirement
+
+- [ ] Annual pension allowance assessed? (UK: £60,000 or 100% of earnings, whichever lower)
+- [ ] Carry forward of unused annual allowances from prior 3 years checked?
+- [ ] Company pension contributions reviewed (corporation tax deductible)?
+- [ ] Salary sacrifice arrangements in place or reviewed?
+- [ ] Lifetime allowance implications assessed? (UK: abolished April 2024 — but transitional protections still relevant for some)
+
+---
+
+## Section 3: Capital Gains Tax
+
+- [ ] Annual CGT exempt amount used? (UK: £3,000 for 2024/25)
+- [ ] Crystallising gains before year-end to use exemption?
+- [ ] Loss harvesting opportunities reviewed?
+- [ ] Business Asset Disposal Relief (BADR) eligibility checked for business sales?
+- [ ] EIS / SEIS investments reviewed for CGT deferral?
+- [ ] Bed-and-ISA / bed-and-SIPP opportunities assessed?
+
+---
+
+## Section 4: Business Reliefs (UK Limited Companies)
+
+- [ ] R&D tax credit eligibility reviewed? (SME scheme vs RDEC depending on size)
+- [ ] Capital allowances claimed on qualifying expenditure?
+- [ ] Annual Investment Allowance (AIA) utilised? (UK: £1m)
+- [ ] Patent Box relief explored for IP-derived profits?
+- [ ] Employment Allowance claimed?
+- [ ] Entrepreneurs' Relief / BADR reviewed for shareholding structure?
+- [ ] Loss reliefs utilised or carried forward optimally?
+
+---
+
+## Section 5: VAT
+
+- [ ] VAT registration threshold monitored? (UK: £90,000 rolling 12 months)
+- [ ] Flat rate scheme vs standard accounting reviewed?
+- [ ] Partial exemption position reviewed if relevant?
+- [ ] VAT on property or mixed-use assets checked?
+
+---
+
+## Section 6: Inheritance Tax and Estate Planning
+
+- [ ] Annual gifting allowances used? (UK: £3,000 per person per year)
+- [ ] Business property relief and agricultural property relief eligibility?
+- [ ] Trust structures reviewed for IHT efficiency?
+- [ ] Life insurance written in trust to prevent estate inclusion?
+- [ ] Nil rate band and residence nil rate band utilised optimally?
+
+---
+
+## Section 7: ISAs and Tax-Efficient Wrappers
+
+- [ ] ISA allowance fully subscribed? (UK: £20,000 per person 2024/25)
+- [ ] Junior ISAs for children considered?
+- [ ] Venture Capital Trusts (VCT) or EIS investments considered for income tax relief?
+- [ ] Lifetime ISA (LISA) reviewed for eligible individuals?
+
+---
+
+## Year-End Action Summary
+
+Based on the above, prioritise these before year-end:
+
+| Action | Potential saving | Deadline | Adviser needed? |
+|---|---|---|---|
+| [Action] | [£ estimate or "significant"] | [Date] | Yes / No |
+
+---
+
+## Quality Checks
+
+- [ ] Jurisdiction confirmed before applying any thresholds or rules
+- [ ] Year-end deadlines identified for time-sensitive opportunities
+- [ ] High-impact items prioritised (not just a long undifferentiated list)
+- [ ] Disclaimer is prominent — this is a framework, not tax advice
+- [ ] Threshold figures are flagged as requiring verification for current tax year
+
+## Example Trigger Phrases
+
+- "Give me a tax planning checklist for [year-end / my situation]"
+- "What tax reliefs should I consider as a [sole trader / limited company / individual]?"
+- "Review my tax efficiency before the end of the tax year"
+- "What should I check for my year-end tax planning?"

plugins/pm-gtm/.claude-plugin/plugin.json

@@ -1,13 +1,13 @@
 {
   "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
   "name": "pm-gtm",
-  "version": "1.0.0",
-  "description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign. Build positioning statements, messaging pillars, feature lists, use cases, and launch campaigns.",
+  "version": "1.1.0",
+  "description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign, SEO Content Brief, Media Pitch. Build positioning statements, messaging pillars, feature lists, use cases, SEO-optimised content briefs, and journalist pitches.",
   "author": {
     "name": "Mohit Aggarwal",
     "email": "mohit15856@gmail.com"
   },
   "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
   "license": "MIT",
-  "keywords": ["product-management", "marketing", "gtm", "positioning", "content-calendar", "competitor-analysis", "email-campaign"]
+  "keywords": ["product-management", "marketing", "gtm", "positioning", "content-calendar", "competitor-analysis", "email-campaign", "seo", "media-pitch", "pr", "journalism"]
 }

plugins/pm-gtm/skills/media-pitch/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: media-pitch
+description: "Write a media pitch or press outreach email for any story or announcement. Use when asked to write a media pitch, journalist outreach email, press pitch, or story angle for PR. Produces a concise pitch with a compelling news angle, journalist-specific hook, and clear call to action."
+---
+
+# Media Pitch Skill
+
+Writes media pitches that journalists actually respond to — built around the story angle, not the company's desire for coverage. Most pitches fail because they are press releases in an email. Good pitches are a human proposing a story to another human.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The story** (what is the actual news or interesting angle?)
+- **Target publication or journalist** (who are you pitching to and what do they cover?)
+- **Company or organisation** (who is behind this?)
+- **Key proof point** (data, customer story, or exclusive that makes this credible)
+- **Why now** (why is this timely?)
+- **What you are offering** (interview / exclusive data / embargoed information / spokespeople)
+
+## Output Structure
+
+---
+
+### Pitch: [Target journalist / outlet]
+
+**Subject line:** [Under 10 words. The story angle, not the company name. Specific, not "Exciting news from [Company]"]
+
+---
+
+Hi [First name],
+
+[Opening sentence — one hook that makes them want to read the next line. Reference their recent work if genuinely relevant: "I read your piece on X last week, which is why I thought you'd be interested in this."]
+
+[Paragraph 1 — The story in 2–3 sentences. Lead with why the reader of [publication] would care. Not what the company does. The news angle, with the most interesting fact first.]
+
+[Paragraph 2 — Why this is a story now. One data point, trend, or timely hook. Be specific: "In the last 6 months, X has increased by Y, according to [source]." Generic claims about "growing trends" are ignored.]
+
+[Paragraph 3 — What you are offering. Interview with [specific person + their relevant credential]. Exclusive data / first look. Access to [specific thing]. One clear offering.]
+
+[Brief company context — 1 sentence maximum. Journalists don't need your history; they need to know you're credible.]
+
+Happy to send more details, connect you with [spokesperson], or share [specific exclusive asset] under embargo.
+
+[Name]
+[Title, Company]
+[Mobile — journalists work on deadline and text faster than email]
+
+---
+
+## Pitch Rules
+
+- Subject line is the pitch — if it doesn't earn a click, nothing else matters
+- The story angle is not "Company launches product" — it is what that product reveals about the world
+- One pitch, one journalist — mass BCC pitches are recognisable and ignored
+- Follow up once, after 3–5 business days, with new information (not "just checking in")
+- If offering an exclusive, name it explicitly and set a response deadline
+
+## Angle Development Framework
+
+If the user doesn't have a strong angle, help them find one:
+
+| Angle type | Example | Works for |
+|---|---|---|
+| Data reveal | "Our research of 10,000 users shows X" | Survey findings, product insights |
+| Trend + proof | "This is happening and here is evidence" | Market trends, behaviour change |
+| Contrarian | "Everyone thinks X but actually Y" | Counter-intuitive findings |
+| Human story | "This person's experience illustrates X" | Customer stories, case studies |
+| Milestone | "First / fastest / largest in [category]" | Launches, records |
+
+## Quality Checks
+
+- [ ] Subject line is the story angle (under 10 words, no company name)
+- [ ] Opening doesn't start with "I'm reaching out" or "I hope this email finds you well"
+- [ ] The story angle is clear in the first two sentences
+- [ ] A specific exclusive or offer is named
+- [ ] Journalist's name is used (not "Hi there")
+- [ ] Mobile number included for deadline follow-up
+
+## Example Trigger Phrases
+
+- "Write a media pitch for [story or announcement]"
+- "Draft a journalist outreach email for [topic]"
+- "Help me pitch [story] to [type of journalist or outlet]"
+- "What is a good angle for a media pitch about [topic]?"

plugins/pm-gtm/skills/seo-content-brief/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: seo-content-brief
+description: "Create a structured SEO content brief for any target keyword or topic. Use when asked to write an SEO brief, content brief, keyword brief, or content strategy document. Produces a complete brief with target keyword, search intent, outline, competitor insights, internal links, and on-page SEO guidance."
+---
+
+# SEO Content Brief Skill
+
+Produces a complete SEO content brief that writers can use to create content that ranks — combining search intent analysis, competitive insights, and on-page optimisation requirements into a single actionable document.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Target keyword or topic**
+- **Target audience** (who is searching for this?)
+- **Website or domain** (for internal linking context)
+- **Content goal** (rank for keyword / drive leads / build authority / support existing content)
+- **Current ranking or page** (if improving existing content — optional)
+- **Word count target or preference** (optional — if not provided, derive from search intent)
+
+## Output Structure
+
+---
+
+# SEO Content Brief: [Target Keyword]
+
+**Target keyword:** [Primary keyword]
+**Secondary keywords:** [Related terms to include naturally]
+**Search intent:** [Informational / Navigational / Commercial / Transactional]
+**Target word count:** [Range — e.g. 1,200–1,800 words]
+**Content type:** [Blog post / Landing page / Guide / Comparison / Listicle]
+**Audience:** [Who will read this]
+**CTA:** [What action should this page drive?]
+
+---
+
+## Search Intent Analysis
+
+**What the searcher wants:** [What someone typing this keyword is actually trying to accomplish]
+
+**What "good" looks like for this query:**
+- Format: [How results typically appear — guide, list, comparison table, etc.]
+- Depth: [Surface-level overview vs. comprehensive deep dive]
+- Tone: [Expert / Conversational / Technical / Beginner-friendly]
+
+**User's next question:** [What they'll search for after reading a good answer — use for internal linking]
+
+---
+
+## Competitor Content Analysis
+
+| Ranking page | Word count | Key sections covered | Gaps or weaknesses |
+|---|---|---|---|
+| [URL or description] | [~N words] | [Sections] | [What they're missing] |
+
+**Opportunity to differentiate:** [Specific angle, data, or depth your content can add that competitors lack]
+
+---
+
+## Recommended Outline
+
+Each heading is the exact H2/H3 to use (these are what Google reads):
+
+**[H1: Title — include primary keyword, under 60 characters]**
+
+**Introduction** (150–200 words)
+- Hook with the problem or question
+- State what the reader will learn
+- Include primary keyword naturally in first 100 words
+
+**[H2: First main section]**
+- [Key points to cover]
+- [Include secondary keyword: X]
+
+**[H2: Second main section]**
+- [Key points]
+
+**[H2: Third main section]**
+- [Key points — consider a table or list here for featured snippet opportunity]
+
+**[H2: FAQ section]** *(recommended for informational queries)*
+- Q: [Question from "People Also Ask" for this keyword]
+- Q: [Question 2]
+
+**Conclusion** (100–150 words)
+- Summarise key takeaways
+- Include CTA
+
+---
+
+## On-Page SEO Requirements
+
+| Element | Requirement |
+|---|---|
+| Title tag | [60 chars max — primary keyword near start] |
+| Meta description | [155 chars max — include keyword + benefit] |
+| H1 | [Match or close to title tag] |
+| Keyword density | [Use primary keyword 3–5x naturally; don't force it] |
+| Image alt text | [Describe image + include keyword where natural] |
+| Internal links | [3–5 internal links — see suggestions below] |
+| External links | [1–2 authoritative sources to cite] |
+
+---
+
+## Internal Linking Suggestions
+
+| Anchor text | Link to | Why |
+|---|---|---|
+| [Relevant phrase] | [/page-path] | [Topic relevance] |
+
+---
+
+## Quality Checks
+
+- [ ] Search intent is correctly identified (informational vs commercial)
+- [ ] Outline addresses the actual user question (not just the keyword)
+- [ ] Competitor gaps are specific and actionable
+- [ ] FAQ section addresses real "People Also Ask" questions
+- [ ] Title tag is under 60 characters and includes the keyword
+- [ ] Internal linking suggestions are relevant and specific
+
+## Example Trigger Phrases
+
+- "Write an SEO brief for the keyword [keyword]"
+- "Create a content brief for [topic]"
+- "What should I include in a blog post about [keyword]?"
+- "Build a content strategy brief for [topic]"

plugins/pm-hr/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-hr",
+  "version": "1.1.0",
+  "description": "HR skills: Job Description Writer, Onboarding Plan, Employee Engagement Survey, Redundancy Consultation, Change Management Plan. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, structure redundancy processes, and manage organisational change with stakeholder analysis and adoption metrics.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["hr", "people", "job-description", "onboarding", "engagement", "redundancy", "recruitment", "change-management", "transformation", "organisational-change"]
+}

plugins/pm-hr/skills/change-management-plan/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: change-management-plan
+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")
+
+## 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]?"

plugins/pm-hr/skills/employee-engagement-survey/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: employee-engagement-survey
+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.
+
+## 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
+
+## Example Trigger Phrases
+- "Create an employee engagement survey for our team"
+- "Design a pulse survey for [topic]"
+- "Analyse these engagement survey results: [paste]"

plugins/pm-hr/skills/job-description-writer/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: job-description-writer
+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
+
+## Example Trigger Phrases
+- "Write a job description for a [role]"
+- "Create an inclusive job posting for [role]"
+- "Review and rewrite this JD: [paste]"

plugins/pm-hr/skills/onboarding-plan/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: onboarding-plan
+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
+
+## 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"

plugins/pm-hr/skills/redundancy-consultation/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: redundancy-consultation
+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
+
+## 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?"

plugins/pm-legal/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-legal",
+  "version": "1.0.0",
+  "description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists. Not a substitute for qualified legal advice.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["legal", "contract-review", "nda", "compliance", "gdpr", "legal-brief", "risk"]
+}

plugins/pm-legal/skills/compliance-checklist/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: compliance-checklist
+description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
+---
+
+# Compliance Checklist Skill
+
+Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
+
+ALWAYS include this disclaimer at the start of every response:
+"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
+- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
+- **Organisation size** (startup / scaleup / mid-market / enterprise)
+- **Current maturity** (no compliance programme / some controls / formal programme)
+- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)
+
+## Output Structure
+
+### 1. Framework Overview
+
+**Framework:** [Name with version]
+**Applicable because:** [One sentence — why this framework applies to this organisation]
+**Typical timeline to readiness:** [From current maturity to certified/compliant]
+**Key stakeholders needed:** [Roles that must be involved]
+
+### 2. Scope Definition
+
+What is in scope for this checklist:
+- [Specific systems / processes / data types]
+
+What is NOT in scope (explicit exclusions):
+- [Specific exclusions]
+
+### 3. Control Categories
+
+For each category relevant to the framework:
+
+**[Category — e.g. "Access Control"]**
+
+| Control | Current State | Gap | Priority | Effort |
+|---|---|---|---|---|
+| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |
+
+### 4. Gap Analysis Summary
+
+| Priority | Count | Examples |
+|---|---|---|
+| Critical gaps (block certification) | N | [Top 3] |
+| High priority gaps | N | |
+| Medium priority gaps | N | |
+| Quick wins | N | |
+
+### 5. Quick Wins
+
+Controls that can be implemented in under 2 weeks with minimal resources:
+
+1. **[Control]** — [Specific action] — [Owner] — [Days to complete]
+
+### 6. Evidence Requirements
+
+For each control area, what documentation will be needed:
+
+| Control area | Evidence types | Where to source |
+|---|---|---|
+| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
+
+### 7. Implementation Roadmap
+
+Phase 1 (Weeks 1-4): Critical gaps and quick wins
+- [Specific deliverables]
+
+Phase 2 (Weeks 5-12): High-priority gaps
+- [Specific deliverables]
+
+Phase 3 (Weeks 13+): Medium priority and continuous improvement
+- [Specific deliverables]
+
+### 8. Ongoing Maintenance
+
+Once certified/compliant, what needs to continue:
+- [Review frequencies]
+- [Periodic testing requirements]
+- [Annual audit expectations]
+- [Staff training cadence]
+
+### 9. Common Pitfalls for This Framework
+
+2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
+
+## Quality Checks
+- [ ] Disclaimer included at start
+- [ ] Framework-specific controls (not generic)
+- [ ] Priorities align with organisation size and maturity
+- [ ] Quick wins clearly separated from complex implementations
+- [ ] Evidence requirements tied to specific controls
+
+## Example Trigger Phrases
+- "Create a GDPR compliance checklist for our SaaS"
+- "Generate a SOC 2 Type II readiness checklist"
+- "What do we need for ISO 27001 certification?"
+- "FCA compliance checklist for a fintech startup"
+- "HIPAA gap analysis for a healthtech scaleup"

plugins/pm-legal/skills/contract-review/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: contract-review
+description: "Review and summarise any contract or legal agreement. Use when asked to review a contract, check an agreement, flag legal risks, or summarise key clauses. Produces a structured review with key terms, flagged clauses, risk rating, and plain English summary. Not a substitute for qualified legal advice."
+---
+
+# Contract Review Skill
+
+This skill produces a structured contract review identifying key terms, unusual or high-risk clauses, and a plain English summary. Always include the disclaimer that this is not legal advice.
+
+## Required Inputs
+- **Contract text or description** (paste or describe)
+- **Reviewer role** (e.g. the party signing, their legal team, a business owner)
+- **Contract type** (e.g. SaaS agreement, employment contract, NDA, supplier contract)
+- **Key concerns** (optional — e.g. "focus on IP ownership and termination clauses")
+
+## Output Structure
+
+### 1. Contract Overview
+- **Type:** [Contract type]
+- **Parties:** [Party A and Party B]
+- **Effective date / duration:** [If stated]
+- **Governing law:** [Jurisdiction]
+- **Overall risk rating:** Green Low / Amber Medium / Red High
+
+### 2. Key Terms Summary
+
+| Term | Detail |
+|---|---|
+| Payment / fees | |
+| Term and renewal | |
+| Termination rights | |
+| Liability cap | |
+| IP ownership | |
+| Confidentiality | |
+| Dispute resolution | |
+
+### 3. Flagged Clauses
+
+For each flagged clause:
+
+**[Risk level] — [Clause name]**
+- **What it says:** [Plain English summary]
+- **Why it matters:** [Risk or implication]
+- **Suggested action:** [Negotiate / Accept / Seek legal advice / Query]
+
+### 4. Missing Clauses
+List any standard clauses absent but normally expected for this contract type.
+
+### 5. Plain English Summary
+3-5 sentences. What does this contract mean for the party signing it?
+
+### 6. Recommended Next Steps
+- [Action 1]
+- [Action 2]
+
+---
+
+WARNING: This review is for informational purposes only and does not constitute legal advice. Always consult a qualified solicitor or lawyer before signing any legally binding agreement.
+
+## Quality Checks
+
+- [ ] Overall risk rating is justified (not just "Medium" without reasons)
+- [ ] All flagged clauses have a specific recommended action (not just "read this")
+- [ ] Missing clauses section is completed for this contract type
+- [ ] Plain English summary can be understood by a non-lawyer
+- [ ] Disclaimer is included
+
+## Example Trigger Phrases
+- "Review this contract: [paste]"
+- "Flag the key risks in this agreement"
+- "Summarise this SaaS contract in plain English"
+- "What should I watch out for in this supplier agreement?"

plugins/pm-legal/skills/legal-brief/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: legal-brief
+description: "Draft a structured legal brief, case summary, or legal argument outline. Use when asked to write a legal brief, case note, legal memo, argument outline, or position paper. Produces a structured document using IRAC format (Issue, Rule, Application, Conclusion)."
+---
+
+# Legal Brief Skill
+
+This skill drafts structured legal briefs and memos using IRAC format — the standard structure for legal writing.
+
+## Required Inputs
+- **Brief type** (legal memo / case summary / argument outline / position paper / letter before action)
+- **Legal issue or question**
+- **Jurisdiction** (England & Wales / US / EU / Other)
+- **Relevant facts**
+- **Relevant law or cases** (if known — otherwise flagged as [RESEARCH NEEDED])
+- **Audience** (internal memo / court submission / client letter)
+
+## Output Structure
+
+### Header
+- **To:** [Recipient]
+- **From:** [Author]
+- **Date:** [Date]
+- **Re:** [Matter reference]
+- **Confidential:** Subject to legal professional privilege
+
+### Issue(s)
+One sentence per legal question:
+- Issue 1: Whether X constitutes Y under [law]
+
+### Brief Answer
+One sentence per issue — conclusion upfront before analysis.
+
+### Facts
+Concise relevant facts only. Flag disputed facts.
+
+### Law (Rule)
+- Relevant statute, regulation, or case law
+- How the rule has been interpreted in key cases
+- Flag [RESEARCH NEEDED] where law is not provided
+
+### Application
+- Arguments in favour
+- Counter-arguments and responses
+- Areas of uncertainty flagged explicitly
+
+### Conclusion
+- Clear answer to each issue
+- Overall recommendation
+- Suggested next steps
+
+### Caveats
+What this memo does not cover. What additional research would change the analysis.
+
+---
+
+WARNING: This draft requires review by a qualified legal professional. It does not constitute legal advice.
+
+## Quality Checks
+
+- [ ] Issue is stated as a specific legal question (not a general topic)
+- [ ] Brief answer appears before the analysis (conclusion upfront)
+- [ ] Disputed facts are explicitly flagged
+- [ ] Areas of legal uncertainty are noted (not hidden in confident language)
+- [ ] Caveats section lists what would change the analysis
+- [ ] Disclaimer is included
+
+## Example Trigger Phrases
+- "Draft a legal memo on [issue]"
+- "Write a legal brief arguing [position]"
+- "Summarise the legal position on [topic]"
+- "Write a letter before action for [situation]"