Bump version to 9.0.0 and update description

Updated version and description to reflect new features.
Update README.md
2026-05-08 03:08:07 +05:30 · 2026-05-08 03:06:32 +05:30 · 2026-05-07 22:30:34 +01:00 · 2026-05-06 15:22:39 +01:00 · 2026-05-06 09:20:03 +01:00 · 2026-05-05 23:31:59 +01:00
224 changed files with 11780 additions and 1162 deletions
@@ -1,8 +1,8 @@
 {
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "pm-claude-skills",
-  "version": "5.2.0",
-  "description": "93 Claude Skills across 14 professions — product management, legal, finance, HR, sales, engineering, design, Figma, operations, research, and more. Now with Opus 4.7-optimised vision and document skills.",
+  "version": "9.0.0",
+  "description": "106 Claude Skills + 4 templates across 22 plugin bundles plus the first agent template (PM Sprint Agent), covering 15 professions — product management, engineering, 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"
@@ -74,16 +74,16 @@
    },
    {
      "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.1.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. 10 structured skills for engineering teams, SREs, and technical PMs.",
+      "version": "2.0.0",
      "category": "productivity",
      "source": "./plugins/pm-engineering",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -130,32 +130,32 @@
    },
    {
      "name": "pm-finance",
-      "description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence. Turn numbers into board-ready narratives, explain variances, structure pitch decks, and generate DD checklists.",
-      "version": "1.0.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.",
+      "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. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, and structure legally compliant redundancy processes.",
-      "version": "1.0.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.",
+      "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. Build competitive battlecards, prepare structured discovery calls, write winning proposals, and create strategic account plans.",
-      "version": "1.0.0",
+      "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. Document workflows, write audit-ready SOPs, evaluate vendors with weighted scorecards, and produce RAG status reports.",
-      "version": "1.0.0",
+      "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"
@@ -170,8 +170,8 @@
    },
    {
      "name": "pm-cross",
-      "description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary. Write journalist-ready press releases, structure grant applications aligned to funder priorities, and produce decision-ready executive summaries.",
-      "version": "1.0.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.",
+      "version": "1.1.0",
      "category": "productivity",
      "source": "./plugins/pm-cross",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -1,26 +1,30 @@
-# 🧠 Claude Skills Library — 93 Skills for Every Profession
+# 🧠 Claude Skills Library — 106 Skills for Every Profession

-> **Save 8–10 hours per week across 14 professions. Install in 2 minutes. Now with Opus 4.7-optimised vision and document skills.**
+[![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-106-blue)](https://github.com/mohitagw15856/pm-claude-skills)
+[![Version](https://img.shields.io/badge/version-8.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, Figma, leadership, legal, finance, HR, sales, operations, research, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
+> **106 Claude Skills + 4 agent templates across 15 professions. Save 8-10 hours per week.**

-**🆕 Latest release (v5.2.0):** Three new skills that leverage Claude Opus 4.7's improved vision and document capabilities — pptx-slide-auditor, docx-tracked-changes-writer, and chart-data-extractor.
+A community-built library of Claude Skills covering product management, engineering, 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 (v9.0.0):**: The library now includes 106 skills + 4 working agent templates following Anthropic's May 2026 agent template architecture.
 ---

 ## 🚀 Quick Install (2 minutes)

 In Claude Code, run:

-```bash
 /plugin marketplace add mohitagw15856/pm-claude-skills
-```

 Or install by profession:

-```bash
 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 + DevOps (10 skills) 🆕
 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
@@ -30,31 +34,148 @@ 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:

-```bash
 git clone https://github.com/mohitagw15856/pm-claude-skills.git ~/pm-claude-skills
 mkdir -p ~/.claude/skills
 ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/
-```

 ---

-## 🆕 What's New in v5.2.0 — Opus 4.7 Release
+## 🎬 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 v9.0.0
+
+**Three new agent templates added:**
+
+- **PM Discovery Agent** — synthesise customer interviews into actionable discovery reports with theme detection and confidence scoring
+- **PM Stakeholder Communications Agent** — generate audience-tailored updates (executive, investor, cross-functional, board) from your team's recent activity
+- **PM Launch Agent** — coordinate product launches end-to-end with channel-specific content, calendar, metrics, and checklist
+
+The library now includes 106 skills + 4 working agent templates following Anthropic's May 2026 agent template architecture.

-Three new skills designed specifically to leverage Claude Opus 4.7's improved vision and document capabilities:

 | Skill | Bundle | What It Does |
 |---|---|---|
-| **PPTX Slide Auditor** | pm-delivery | Audit a PowerPoint deck for layout issues, text overflow, visual hierarchy problems, and consistency gaps |
-| **Word Doc Tracked Changes** | pm-essentials | Produce properly-formatted tracked changes for Word documents — insertions, deletions, margin comments |
-| **Chart Data Extractor** | pm-data | Extract pixel-level data from chart images and produce a structured data table with confidence levels |
+| **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 |

-Plus three existing skills (figma-design-qa, code-review-checklist, compliance-checklist) updated to remove verification scaffolding that Opus 4.7 no longer needs — faster and cleaner outputs.
+The `pm-engineering` bundle now has **10 skills** — the most complete engineering toolkit in the library.

-**Read the full story:** [Part 13 — I Re-Tested My 90 Claude Skills on Opus 4.7](#)
+**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 |

 ---

@@ -73,14 +194,16 @@ This repo was built alongside a published article series. Read the full story:
 | 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 | [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 | *Link TBC* |
-| Part 11 | 10 Figma Claude Skills for PMs and Designers | *Link TBC* |
+| 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 | *Latest — Link TBC* |
+| 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) |

 ---

-## 🗂️ All 93 Skills
+## 🗂️ All 106 Skills

 ### 🛠️ Product Management (Skills 1–34)
 **Bundles:** `pm-essentials` · `pm-discovery` · `pm-planning` · `pm-delivery` · `pm-analytics` · `pm-strategy` · `pm-advanced` · `pm-rituals`
@@ -101,7 +224,7 @@ This repo was built alongside a published article series. Read the full story:

 ---

-### 📣 Marketing & GTM (Skills 35–38)
+### 📣 Marketing & GTM (Skills 35–40)
 **Bundle:** `pm-gtm`

 | # | Skill | Folder | What It Does |
@@ -110,172 +233,212 @@ This repo was built alongside a published article series. Read the full story:
 | 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 39–42)
+### 👩‍💻 Engineering & Tech (Skills 41–50)
 **Bundle:** `pm-engineering`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 39 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
-| 40 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
-| 41 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs: endpoints, parameters, response schemas, code examples |
-| 42 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options considered, 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 |

 ---

-### 📊 Data & Analytics (Skills 43–46)
+### 📊 Data & Analytics (Skills 51–54)
 **Bundle:** `pm-data`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 43 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
-| 44 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
-| 45 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
-| 46 | **Chart Data Extractor** 🆕 | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
+| 51 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
+| 52 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
+| 53 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
+| 54 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |

 ---

-### 🧑‍💼 Leadership & People (Skills 47–49)
+### 🧑‍💼 Leadership & People (Skills 55–57)
 **Bundle:** `pm-people`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 47 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
-| 48 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
-| 49 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
+| 55 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
+| 56 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
+| 57 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |

 ---

-### 🎨 Design & UX (Skills 50–52)
+### 🎨 Design & UX (Skills 58–60)
 **Bundle:** `pm-design`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 50 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
-| 51 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
-| 52 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
+| 58 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
+| 59 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
+| 60 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |

 ---

-### 🏢 Business & Strategy (Skills 53–55)
+### 🏢 Business & Strategy (Skills 61–63)
 **Bundle:** `pm-business`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 53 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
-| 54 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
-| 55 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
+| 61 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
+| 62 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
+| 63 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |

 ---

-### ⚖️ Legal (Skills 56–59)
+### ⚖️ Legal (Skills 64–67)
 **Bundle:** `pm-legal`

 > ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 56 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
-| 57 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
-| 58 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
-| 59 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
+| 64 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
+| 65 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
+| 66 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
+| 67 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |

 ---

-### 💰 Finance (Skills 60–63)
+### 💰 Finance (Skills 68–72)
 **Bundle:** `pm-finance`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 60 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
-| 61 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
-| 62 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
-| 63 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
+| 68 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
+| 69 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
+| 70 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
+| 71 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
+| 72 | **Tax Planning Checklist** 🆕 | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |

 ---

-### 👥 HR (Skills 64–67)
+### 👥 HR (Skills 73–77)
 **Bundle:** `pm-hr`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 64 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
-| 65 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
-| 66 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
-| 67 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
+| 73 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
+| 74 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
+| 75 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
+| 76 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
+| 77 | **Change Management Plan** 🆕 | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |

 ---

-### 🤝 Sales (Skills 68–71)
+### 🤝 Sales (Skills 78–82)
 **Bundle:** `pm-sales`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 68 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
-| 69 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
-| 70 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
-| 71 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
+| 78 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
+| 79 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
+| 80 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
+| 81 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
+| 82 | **Sales Forecasting Model** 🆕 | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |

 ---

-### ⚙️ Operations (Skills 72–75)
+### ⚙️ Operations (Skills 83–87)
 **Bundle:** `pm-operations`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 72 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
-| 73 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
-| 74 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
-| 75 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
+| 83 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
+| 84 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
+| 85 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
+| 86 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
+| 87 | **Workshop Facilitation Guide** 🆕 | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |

 ---

-### 🏥 Research & Healthcare (Skills 76–79)
+### 🏥 Research & Healthcare (Skills 88–91)
 **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 |
 |---|---|---|---|
-| 76 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
-| 77 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
-| 78 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
-| 79 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
+| 88 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
+| 89 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
+| 90 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
+| 91 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |

 ---

-### 🌐 Cross-Profession (Skills 80–82)
+### 🌐 Cross-Profession (Skills 92–95)
 **Bundle:** `pm-cross`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 80 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
-| 81 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
-| 82 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 92 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
+| 93 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
+| 94 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 95 | **Teaching Lesson Plan** 🆕 | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |

 ---

-### 🖼️ Figma (Skills 83–92)
+### 🖼️ Figma (Skills 96–105)
 **Bundle:** `pm-figma`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 83 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
-| 84 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
-| 85 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
-| 86 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
-| 87 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
-| 88 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
-| 89 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
-| 90 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
-| 91 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
-| 92 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
+| 96 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
+| 97 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
+| 98 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
+| 99 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
+| 100 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
+| 101 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
+| 102 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
+| 103 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
+| 104 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
+| 105 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |

-```bash
 claude plugin install pm-figma@pm-claude-skills
-```
+
+
+---
+
+### 📅 PM Rituals (Skill 106)
+**Bundle:** `pm-rituals`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 106 | **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 106 skills across 22 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.

 ---

@@ -291,7 +454,6 @@ This is an open-source community library. If you've built a skill that saves you
 4. Raise a pull request with a short description of what the skill does and why you built it

 **SKILL.md template:**
-```markdown
 ---
 name: your-skill-name
 description: "One sentence. Use when [trigger condition]. Produces [output description]."
@@ -300,7 +462,7 @@ description: "One sentence. Use when [trigger condition]. Produces [output descr
 # Skill Title

 [Instructions for Claude to follow when this skill is invoked]
-```
+

 **What makes a good skill:**
 - Solves a recurring professional workflow (not a one-off task)
@@ -312,16 +474,13 @@ description: "One sentence. Use when [trigger condition]. Produces [output descr

 | Skill | Profession | Use Case |
 |---|---|---|
-| `teaching-lesson-plan` | Education | Structured lesson plans from curriculum objectives |
-| `seo-content-brief` | Marketing | Content briefs with keyword strategy and outline |
 | `grant-report` | Non-profit | Funder progress reports against grant objectives |
 | `architectural-spec` | Architecture | Project specifications and technical drawing briefs |
-| `media-pitch` | Journalism | Story pitches to editors and commissioning briefs |
 | `clinical-guideline-summary` | Healthcare | Plain English summaries of clinical guidelines |
-| `tax-planning-checklist` | Finance | Year-end tax planning checklist by entity type |
-| `sales-forecasting-model` | Sales | Structured pipeline forecasting and commentary |
+| `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? [Open an issue](../../issues) or raise it in [Discussions](../../discussions).
+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. 🙌

@@ -331,7 +490,6 @@ Have a skill idea? [Open an issue](../../issues) or raise it in [Discussions](..

 Install the whole library or just the bundles you need:

-```bash
 # Install everything
 /plugin marketplace add mohitagw15856/pm-claude-skills

@@ -345,7 +503,7 @@ 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
+claude plugin install pm-engineering@pm-claude-skills    # 10 engineering 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
@@ -358,7 +516,7 @@ 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
-```
+

 ---

@@ -374,7 +532,7 @@ Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGP

 ## 🛠️ Custom Skills for Your Team

-The 93 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.
+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:**

@@ -404,10 +562,21 @@ Learn more: [Anthropic's Skills documentation](https://code.claude.com/docs/en/s

 ---

-## ⭐ If this is useful
+## ⭐ Star Milestones

-Star the repo so others can find it. And if you build something with these skills — 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) | 🔒 Locked |
+| 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns) | 🔒 Locked |
+| 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 Notes 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)*
@@ -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)*
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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*
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-cross",
-  "version": "1.0.0",
-  "description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary. Write journalist-ready press releases, structure grant applications aligned to funder priorities, and produce decision-ready executive summaries for any audience.",
+  "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"]
+  "keywords": ["communications", "press-release", "grant", "executive-summary", "briefing", "funding", "media", "education", "teaching", "lesson-plan", "training"]
 }
@@ -87,11 +87,14 @@ Funder test: does this problem align with [funder] stated priorities? Make the c

 ---

-## Funder Alignment Check
- Every section explicitly references funder stated priorities
- Word limits respected
- Budget aligns with eligible costs policy
- Required attachments prepared
+## 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]"
@@ -64,6 +64,14 @@ ENDS
 ## 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]"
@@ -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]"
@@ -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
@@ -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
@@ -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
@@ -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?)
@@ -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
@@ -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
@@ -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")
@@ -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)
@@ -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
@@ -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
@@ -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")
@@ -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": "2.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. 10 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"]
 }
@@ -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]
@@ -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?"
@@ -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"
@@ -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]"
@@ -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]"
@@ -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]?"
@@ -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)
@@ -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]"
@@ -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

 ```
@@ -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
@@ -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
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-finance",
-  "version": "1.0.0",
-  "description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence. Turn numbers into board-ready narratives, explain variances, structure pitch decks, and generate DD checklists.",
+  "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"]
+  "keywords": ["finance", "financial-model", "budget", "variance", "pitch-deck", "due-diligence", "investor", "tax", "tax-planning", "year-end"]
 }
@@ -1,6 +1,6 @@
 ---
 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."
+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
@@ -55,6 +55,14 @@ For each significant variance:
 - 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"
@@ -42,6 +42,15 @@ For each slide:
 - 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"
@@ -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?"
@@ -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"]
 }
@@ -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]?"
@@ -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]"
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-hr",
-  "version": "1.0.0",
-  "description": "HR skills: Job Description Writer, Onboarding Plan, Employee Engagement Survey, Redundancy Consultation. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, and structure legally compliant redundancy processes.",
+  "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"]
+  "keywords": ["hr", "people", "job-description", "onboarding", "engagement", "redundancy", "recruitment", "change-management", "transformation", "organisational-change"]
 }
@@ -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]?"
@@ -80,6 +80,14 @@ eNPS: Below 0 = Concerning / 0-30 = Good / 30-70 = Great / 70+ = Excellent

 **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]"
@@ -62,11 +62,11 @@ Nice to have (3-4 items):
 - 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
+- [ ] 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]"
@@ -83,6 +83,14 @@ Goals:
 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]"
@@ -62,6 +62,15 @@ Issued only after genuine consultation. Must include: statutory pay calculated,

 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]"
@@ -57,6 +57,14 @@ List any standard clauses absent but normally expected for this contract type.

 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"
@@ -56,6 +56,15 @@ What this memo does not cover. What additional research would change the analysi

 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]"
@@ -52,6 +52,15 @@ Clauses always covered: permitted use, non-solicitation/non-compete, term and po

 WARNING: This analysis is for informational purposes only and is not legal advice. Consult a qualified solicitor before signing.

+## Quality Checks
+
+- [ ] Definition of confidential information assessed for scope (narrow / standard / very broad)
+- [ ] Residuals clause checked (allows memory use of disclosed information — high-risk)
+- [ ] Non-solicitation / non-compete provisions flagged
+- [ ] Post-termination obligations duration noted
+- [ ] Plain English verdict given (standard / one-sided / needs lawyer)
+- [ ] Disclaimer is included
+
 ## Example Trigger Phrases
 - "Analyse this NDA"
 - "Review this confidentiality agreement"
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-operations",
-  "version": "1.0.0",
-  "description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report. Document workflows, write audit-ready SOPs, evaluate vendors with weighted scorecards, and produce RAG status reports.",
+  "version": "1.1.0",
+  "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.",
  "author": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
  },
  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
  "license": "MIT",
-  "keywords": ["operations", "process", "sop", "vendor", "procurement", "project-management", "rag-status"]
+  "keywords": ["operations", "process", "sop", "vendor", "procurement", "project-management", "rag-status", "facilitation", "workshop", "working-session"]
 }
@@ -75,6 +75,14 @@ Produces clear, structured process documentation that someone new to a role can
 ### Review
 Next review due: [Date]

+## Quality Checks
+
+- [ ] Every step has a named role (not "someone" or "the team")
+- [ ] Edge cases and exceptions table is complete
+- [ ] Prerequisites are listed so someone new can prepare before starting
+- [ ] Escalation path is named (specific people or roles, not just "your manager")
+- [ ] Review date is set
+
 ## Example Trigger Phrases
 - "Document this process: [description]"
 - "Write a process guide for [workflow]"
@@ -103,6 +103,14 @@ RAG definitions:
 - Decisions must be genuinely actionable
 - Keep to one page where possible

+## Quality Checks
+
+- [ ] Red status is stated immediately (not buried after positives)
+- [ ] Every issue has a named owner and a resolution date
+- [ ] Decisions required are genuinely actionable by the audience
+- [ ] Milestones are binary (complete or not complete — no "85% done")
+- [ ] Executive summary can stand alone for a stakeholder who reads nothing else
+
 ## Example Trigger Phrases
 - "Write a project status report for [project]"
 - "Generate a RAG status update for [project]"
@@ -81,11 +81,12 @@ NOTE: Steps must be written in imperative form. Each step must have one action o
 | 1.0 | [Date] | [Name] | Initial release |

 ## Quality Checks
- All steps in imperative form
- Each step has exactly one action
- Roles specified for every step
- Quality checkpoints at critical stages
- Non-conformance process defined
+- [ ] All steps written in imperative form ("Open...", "Navigate...", "Confirm...")
+- [ ] Each step has exactly one action
+- [ ] Role specified for every step
+- [ ] Quality checkpoints at critical stages
+- [ ] Non-conformance process defines who to notify and how to document
+- [ ] Document history table and review date are included

 ## Example Trigger Phrases
 - "Write an SOP for [process]"
@@ -64,6 +64,15 @@ Security: ISO 27001 / SOC 2 certified? Where is data stored? Breach notification
 **Conditions:** [Contract terms to negotiate before signing]
 **Runner-up:** [Vendor and why they lost]

+## Quality Checks
+
+- [ ] Evaluation criteria weights total 100%
+- [ ] Scoring rubric is defined before scoring vendors (not post-hoc)
+- [ ] Reference check questions are included
+- [ ] Recommendation includes risks and conditions, not just a winner
+- [ ] Runner-up rationale explains why they lost (enables future conversations)
+- [ ] Contract terms to negotiate are specified
+
 ## Example Trigger Phrases
 - "Help me evaluate vendors for [procurement]"
 - "Create a vendor scorecard for [software/service]"
@@ -0,0 +1,148 @@
+---
+name: workshop-facilitation-guide
+description: "Design and facilitate any workshop, working session, or collaborative meeting. Use when asked to plan a workshop, design a facilitated session, run a ideation session, or create a workshop agenda. Produces a complete facilitation guide with session design, activity instructions, timing, and materials."
+---
+
+# Workshop Facilitation Guide Skill
+
+Produces a complete facilitation guide for any workshop — from a 90-minute problem-solving session to a full-day strategy workshop. Includes step-by-step activity instructions and facilitation moves for when things go off track.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Workshop goal** (what decision or output should exist at the end?)
+- **Participants** (number, roles, mix of seniority)
+- **Duration** (90 min / half day / full day / multi-day)
+- **Format** (in-person / remote / hybrid)
+- **Known tensions** (optional — pre-existing conflicts or disagreements to navigate)
+- **Non-negotiables** (anything that cannot be decided or changed in the room)
+
+## Output Structure
+
+---
+
+# Workshop Facilitation Guide: [Session Name]
+
+**Date:** [TBD / as provided]
+**Duration:** [X hours]
+**Participants:** [N people, roles]
+**Format:** [In-person / Remote / Hybrid]
+**Facilitator:** [Leave for user]
+
+---
+
+## Workshop Objectives
+
+By the end of this session, the group will have:
+1. [Specific output 1 — e.g. "Agreed on the top 3 priorities for Q3"]
+2. [Specific output 2]
+3. [Specific output 3]
+
+**How we will know it worked:** [Observable test for success — e.g. "Everyone can name the agreed priorities without looking at their notes"]
+
+---
+
+## Pre-Workshop Preparation
+
+**Facilitator:**
+- [ ] Confirm objectives with session sponsor (30 min pre-read call recommended)
+- [ ] Send pre-read to participants [X days before] — max 2 pages
+- [ ] Prepare all materials (printed / Miro boards / slides)
+- [ ] Set up room or virtual space
+
+**Participants (pre-work):**
+- [Specific pre-work — max 20 minutes. If more, fewer people do it]
+
+---
+
+## Full Agenda
+
+| Time | Activity | Duration | Format | Output |
+|---|---|---|---|---|
+| [00:00] | Welcome and framing | 10 min | Facilitator-led | Shared expectations |
+| [00:10] | [Activity 1] | [X min] | [Format] | [Output] |
+| [00:X] | [Activity 2] | [X min] | [Format] | [Output] |
+| [00:X] | Break | 15 min | — | — |
+| [00:X] | [Activity 3] | [X min] | [Format] | [Output] |
+| [00:X] | Decisions and next steps | 20 min | Whole group | Committed actions |
+| [00:X] | Close | 10 min | Facilitator-led | Energy and commitment |
+
+---
+
+## Activity Instructions
+
+For each activity:
+
+### Activity [N]: [Name]
+
+**Purpose:** [Why this activity at this moment]
+**Time:** [X minutes]
+**Format:** [Individual / Pairs / Small groups / Whole group]
+**Materials:** [Post-its, Miro, printed sheets, etc.]
+
+**Instructions to give participants:**
+> "[Exact words to say when launching the activity — unambiguous, no jargon]"
+
+**Step-by-step:**
+1. [What happens in minute 0–X]
+2. [What happens next]
+3. [How to consolidate and move forward]
+
+**If the group gets stuck:** [Specific facilitation move — e.g. "Ask each person to write one idea silently before sharing"]
+**Watch out for:** [Common failure mode — e.g. "One voice dominating. Use round-robin to surface quieter participants"]
+**Time warning:** [What to do if running long — e.g. "Skip the prioritisation vote and let facilitator propose the top 3"]
+
+---
+
+## Decision-Making Protocol
+
+Agree this with the group at the start:
+
+**How decisions will be made in this session:**
+- [ ] Consensus (everyone must actively agree)
+- [ ] Consent (no one has a blocking objection)
+- [ ] Majority vote (50%+1)
+- [ ] Facilitator/sponsor decides after hearing input
+
+**What happens with unresolved disagreements:** [Parking lot / escalate to sponsor / decide by [person] after session]
+
+---
+
+## Facilitation Moves (Quick Reference)
+
+| Situation | Move |
+|---|---|
+| Silence after a question | "Take 2 minutes to write your thoughts before we share" |
+| One person dominating | "Let's hear from someone we haven't heard from yet" |
+| Off-topic tangent | "That's important — let me put it in the parking lot. Back to [focus]" |
+| Group stuck, no ideas | "What would [competitor / different industry] do here?" |
+| No consensus, running out of time | "Let's do a quick dot vote to identify the strongest options" |
+| Energy low after lunch | "Stand up and tell the person next to you your one key takeaway so far" |
+
+---
+
+## Close: Commitments and Next Steps
+
+End every session with:
+1. **What did we decide?** — Read back every decision made. Ask: "Does anyone have a concern with how I've captured this?"
+2. **What will we do?** — Specific actions, named owners, concrete deadlines
+3. **Who needs to know?** — Who will communicate outputs to absent stakeholders, and how?
+4. **When do we meet again?** — Schedule the follow-up before the room empties
+
+---
+
+## Quality Checks
+
+- [ ] Workshop objective is a specific output, not a vague goal ("aligned on strategy")
+- [ ] All activities have explicit timing and format
+- [ ] A decision-making protocol is agreed at the start
+- [ ] Activities alternate between individual work and group work
+- [ ] Parking lot is used actively (not a graveyard)
+- [ ] Close captures decisions and actions before the room empties
+
+## Example Trigger Phrases
+
+- "Design a workshop for [goal] with [group]"
+- "Plan a facilitated session to [outcome]"
+- "Help me run a [type] workshop with my team"
+- "Create a facilitation guide for [topic]"
@@ -1,12 +1,20 @@
 ---
 name: feature-prioritisation
-description: Applies prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items. Use when asked to prioritise features, rank a backlog, decide what to build next, or evaluate tradeoffs. Triggers on "prioritise features", "what should we build", "backlog grooming", "RICE score", "MoSCoW".
+description: "Apply prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items. Use when asked to prioritise features, rank a backlog, decide what to build next, or evaluate tradeoffs between competing ideas. Produces a scored, ranked feature list with framework-specific tables, recommended build order, deprioritised items, and assumptions made."
 ---

 # Feature Prioritisation Skill

 Apply the right prioritisation framework to any backlog and produce a clear, defensible ranking with rationale — not just a sorted list.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **List of features or initiatives to prioritise**
+- **Goal or metric** being prioritised against (OKR, launch, sprint)
+- **Preferred framework** (or recommend based on context below)
+- **Team data**: reach estimates, effort estimates, velocity (for RICE)
+
 ## Framework Selection Guide

 Ask the user which framework they prefer, or recommend based on context:
@@ -102,3 +110,11 @@ Recommend building: all Basic features first → Performance features for key us
 - If stakeholder politics are influencing prioritisation, name it explicitly and suggest separating the framework score from the final decision
 - Recommend revisiting priorities every 2 weeks minimum
 - Never produce a single-column ranked list without rationale — explain the top 3 and bottom 3 decisions
+
+## Quality Checks
+
+- [ ] Every item is scored against the same goal or metric (not different goals per item)
+- [ ] Deprioritised items are explicitly listed with reasons (not just absent from the ranked list)
+- [ ] Assumptions used in scoring are documented
+- [ ] Stakeholder politics or personal preferences are separated from framework score
+- [ ] Prioritisation is anchored to a specific scope (sprint / quarter / launch)
@@ -1,6 +1,6 @@
 ---
 name: okr-builder
-description: Creates well-structured OKRs (Objectives and Key Results) for product teams, startups, and individuals. Use when asked to write OKRs, set quarterly goals, define key results, or review existing OKRs. Triggers on "OKR", "objective and key results", "quarterly goals", "north star metric".
+description: "Create well-structured OKRs (Objectives and Key Results) for product teams, startups, and individuals. Use when asked to write OKRs, set quarterly goals, define key results, or review existing OKRs. Produces a complete OKR set with objectives, measurable key results, baselines, and a scoring guide."
 ---

 # OKR Builder Skill
@@ -60,6 +60,15 @@ At quarter end, score each KR:
 - 0.4–0.6 = Made progress but missed
 - 0.0–0.3 = Missed — needs retrospective discussion

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Team or individual** the OKRs are for
+- **Quarter and year**
+- **Company or product North Star metric** (OKRs should connect to this)
+- **Top 3 priorities or goals for this quarter** (rough notes are fine)
+- **Any existing OKRs to review or improve** (optional)
+
 ## Guidelines

 - Always ask for the company-level or product-level North Star metric before writing OKRs
@@ -67,3 +76,11 @@ At quarter end, score each KR:
 - If user provides output-based goals, always reframe as outcomes
 - Include a "health check" section flagging which KRs have no current baseline data
 - Remind user: OKRs are not performance reviews — they should be ambitious enough that missing them is okay
+
+## Quality Checks
+
+- [ ] Each KR is measurable with a baseline and target
+- [ ] No output-based KRs (no "launch X" or "complete Y")
+- [ ] Maximum 4 KRs per objective
+- [ ] OKRs connect to the company or product North Star
+- [ ] Ambitious enough that 0.7 attainment is the expected score
@@ -1,6 +1,6 @@
 ---
 name: pricing-strategy
-description: Structures pricing strategy decisions, packaging options, and pricing page design for SaaS and digital products. Use when reviewing or setting pricing, designing pricing tiers, evaluating freemium vs paid, or preparing a pricing change. Triggers on "pricing strategy", "pricing tiers", "freemium", "pricing page", "how should we price", "pricing change".
+description: "Structure pricing strategy decisions, packaging options, and tier design for SaaS and digital products. Use when reviewing or setting pricing, designing pricing tiers, evaluating freemium vs paid, or preparing a pricing change. Produces a pricing strategy recommendation with model rationale, tier structure, competitive positioning, and rollout plan."
 ---

 # Pricing Strategy Skill
@@ -110,6 +110,25 @@ Positioning options:

 ---

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product or service** being priced
+- **Current pricing** (if any — and why it's being reviewed)
+- **Target customer segments** (size, role, willingness to pay)
+- **Key competitors and their pricing** (if known)
+- **Business model** (SaaS / Marketplace / Usage-based / Other)
+- **Primary goal** (grow adoption / increase ARPU / reduce churn / new market entry)
+
+## Quality Checks
+
+- [ ] Value metric is defined (the unit that scales with customer value)
+- [ ] Free-to-paid upgrade trigger is specific (not "when they need more")
+- [ ] Competitive positioning is chosen and justified (premium / parity / value)
+- [ ] Pricing change rollout plan includes grandfathering decision
+- [ ] Counter-metrics are defined to catch perverse incentives
+- [ ] Risks have specific mitigations (not just listed)
+
 ## Guidelines

 - Never price based on cost — price based on value delivered to the customer
@@ -1,13 +1,21 @@
 ---
 name: rice-impact-matrix
-description: Score features using RICE and plot against strategic alignment for nuanced prioritisation
-tool_integration: Miro, Jira
+description: "Score features using RICE and plot against strategic alignment for nuanced prioritisation. Use when asked to prioritise features, build a priority matrix, combine quantitative scoring with strategic fit, or decide what to build next with multiple competing initiatives. Produces a scored priority matrix with RICE scores, strategic alignment ratings, quadrant placement, and sequencing recommendations."
 ---
+
 # RICE + Strategic Alignment Skill

-## Purpose
 Produce a prioritisation output that balances quantitative RICE scoring with qualitative strategic fit — because the highest RICE score isn't always the right next bet.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **List of initiatives or features to prioritise** (names and brief descriptions)
+- **Current strategic priorities or OKRs** (needed to rate strategic alignment)
+- **Reach estimates** (users affected per quarter — even rough estimates work)
+- **Effort estimates** (person-months — from engineering if available)
+- **Quarter or planning period**
+
 ## Two-Stage Process

 ### Stage 1: RICE Scoring
@@ -18,7 +26,7 @@ Produce a prioritisation output that balances quantitative RICE scoring with qua
 - RICE = (R × I × C) / E

 ### Stage 2: Strategic Alignment Score
-Rate each initiative against your current strategic priorities (provide these as input):
+Rate each initiative against your current strategic priorities (provided as input):
 - Directly supports top OKR: +3
 - Supports secondary OKR: +2
 - Neutral: +1
@@ -27,7 +35,9 @@ Rate each initiative against your current strategic priorities (provide these as
 ### Final Priority Score
 Combined Score = RICE Score + (Strategic Alignment × 10)

-## Output Format
+**Validate** — Flag any initiative where RICE score and strategic alignment conflict sharply (e.g., high RICE, low alignment). These require an explicit team conversation before sequencing.
+
+## Output Structure

 ### Priority Matrix — [Quarter]
 | Initiative | RICE Score | Strategic Alignment | Combined Score | Quadrant | Recommendation |
@@ -42,3 +52,11 @@ Combined Score = RICE Score + (Strategic Alignment × 10)

 #### Recommendations
 [Top 5 initiatives with rationale for sequencing]
+
+## Quality Checks
+
+- [ ] All RICE components have an estimate (even if low confidence — flag those)
+- [ ] Strategic alignment is rated against specific OKRs, not general "feels strategic"
+- [ ] Conflicts between RICE rank and strategic alignment are explicitly flagged
+- [ ] "Drop" recommendations are specific — not just "low priority, deprioritise"
+- [ ] Confidence levels on estimates are noted where weak (drives the 50% confidence flag)
@@ -1,13 +1,21 @@
 ---
 name: rice-prioritisation
-description: Score and rank product initiatives using the RICE framework
-tool_integration: Jira
+description: "Score and rank product initiatives using the RICE framework. Use when asked to prioritise features, rank a backlog using RICE, score initiatives for quarterly planning, or apply an objective framework to a list of competing ideas. Produces a ranked RICE table with scores, quick wins and moonshot flags, dependency notes, and a recommended sequencing order."
 ---
+
 # RICE Prioritisation Skill

-## Purpose
 Apply consistent, criteria-based RICE scoring to a list of features or initiatives to produce an objective prioritisation ranking.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **List of initiatives or features to score** (names and brief descriptions)
+- **Reach estimates** (users affected per quarter — from analytics if available)
+- **Impact estimates** (use the standard scale below)
+- **Effort estimates** (person-months — from engineering if available)
+- **Quarter or planning period**
+
 ## RICE Definitions (adapt to your context)
 - **Reach:** Number of users affected per quarter (use actual DAU/MAU data where available)
 - **Impact:** Effect on your primary metric — use scale: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
@@ -24,8 +32,9 @@ RICE Score = (Reach × Impact × Confidence) / Effort
 4. Rank highest to lowest
 5. Flag any "quick wins" (high RICE score, low effort) and "moonshots" (high impact, high effort)
 6. Note dependencies between items that affect sequencing
+7. **Validate** — Cross-check: if the top-ranked item surprises the team, investigate whether an estimate is inflated. RICE is a tool, not a verdict.

-## Output Format
+## Output Structure

 ### RICE Prioritisation: [Backlog/Quarter]
 | Initiative | Reach | Impact | Confidence | Effort | RICE Score | Notes |
@@ -35,5 +44,16 @@ RICE Score = (Reach × Impact × Confidence) / Effort
 #### Recommended Sequence
 [Top 5 initiatives with rationale]

+#### Quick Wins (high score, low effort)
+[Items to pick up alongside bigger bets]
+
 #### Data Gaps to Address
 [What information would most improve scoring accuracy]
+
+## Quality Checks
+
+- [ ] Every initiative has all four RICE components estimated (even roughly)
+- [ ] Confidence is 50% for anything without data backing (not 100% as a default)
+- [ ] Quick wins and moonshots are explicitly called out
+- [ ] Dependencies that affect sequencing are noted
+- [ ] Any surprising ranking is investigated before accepting it
@@ -1,21 +1,29 @@
 ---
 name: roadmap-narrative
-description: Transform a prioritised initiative list into a compelling strategic roadmap narrative
-tool_integration: Notion, Miro
+description: "Transform a prioritised initiative list into a compelling strategic roadmap narrative. Use when asked to write a roadmap narrative, explain the product roadmap to non-technical stakeholders, connect roadmap items to company goals, or produce an exec-shareable roadmap story. Produces a themed narrative with strategic context, quarter progression arc, an executive summary, and a 'what's not on the roadmap' section."
 ---
+
 # Roadmap Narrative Skill

-## Purpose
 Convert a ranked list of product initiatives into a clear, strategic narrative that connects individual items to company goals and communicates a coherent product direction.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Prioritised initiative list** (with rough timelines or quarters)
+- **Company OKRs or strategic priorities** (to connect roadmap to company goals)
+- **Audience** (all-hands, board, investors, sales team — changes tone and depth)
+- **Items explicitly NOT on the roadmap** (optional but strengthens credibility)
+
 ## Process
 1. Review the prioritised initiative list and company OKRs provided
 2. Identify 2-3 strategic themes that group the initiatives naturally
 3. For each theme, articulate: the problem it addresses, the customer it serves, the metric it moves
 4. Write a quarter-level narrative that shows progression — how does H1 set up H2?
 5. Draft an executive summary (3-4 sentences max) that non-technical stakeholders can repeat
+6. **Validate** — Confirm every initiative maps to a theme. If an initiative is orphaned, either create a theme or flag it as a narrative gap to address

-## Output Format
+## Output Structure

 ### Product Roadmap: [Quarter/Half/Year]
 **Strategic Context:** [1 paragraph: market moment, key challenge, our response]
@@ -28,10 +36,21 @@ Convert a ranked list of product initiatives into a clear, strategic narrative t

 [Repeat for each theme]

+**What's Not on the Roadmap (and Why):**
+[2-3 items with rationale — shows strategic discipline, not just prioritisation]
+
 **Executive Summary (shareable):**
 [3-4 sentences that could be shared in an all-hands or board update]

 ## Tone Guidelines
- Avoid jargon — write for a CFO, not an engineer
+- Write for a CFO, not an engineer
 - Lead with customer outcomes, not features
 - Be honest about what's NOT on the roadmap and why
+
+## Quality Checks
+
+- [ ] Every initiative in the input maps to a strategic theme
+- [ ] The executive summary can stand alone and be repeated correctly after one reading
+- [ ] Progression narrative shows causal links between quarters (not just chronological listing)
+- [ ] "What's not on the roadmap" section includes at least 2 items with clear rationale
+- [ ] Language throughout is free of engineering jargon — tested by asking: "could a CFO repeat this?"
@@ -1,12 +1,20 @@
 ---
 name: roadmap-presentation
-description: Creates structured roadmap presentations and narratives for executive, stakeholder, and team audiences. Use when asked to build a product roadmap, present roadmap to leadership, create a roadmap slide, or communicate quarterly plans. Triggers on "roadmap presentation", "product roadmap", "quarterly roadmap", "roadmap slide", "roadmap for leadership".
+description: "Create structured roadmap presentations calibrated to any audience. Use when asked to build a product roadmap, present roadmap to leadership, create a roadmap slide, or communicate quarterly plans to execs, teams, or customers. Produces an audience-calibrated Now/Next/Later roadmap with strategic context, initiative tables, success metrics, and explicit deprioritisation rationale."
 ---

 # Roadmap Presentation Skill

 Build roadmaps that tell a strategy story — not just a list of features with dates. Every roadmap output is audience-calibrated: executives get outcomes, teams get specificity, customers get value.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Audience** (executive/board, cross-functional, engineering, customers — changes format significantly)
+- **Prioritised initiative list** with rough timelines or quarters
+- **Company OKRs or strategic goals** (to anchor the narrative)
+- **Period covered** (Q1, H1, full year, etc.)
+
 ## Audience Calibration

 Always ask who the audience is before building:
@@ -112,3 +120,11 @@ Every roadmap needs a narrative, not just a timeline. Structure it as:
 - For executive audiences: lead with the outcome the roadmap delivers to the business, not the features
 - Recommend a roadmap review cadence: monthly for Now items, quarterly for Next/Later
 - If dates are demanded for Later items: use quarters (Q3 2026), not specific dates
+
+## Quality Checks
+
+- [ ] Format matches the audience (executives don't get sprint-level detail)
+- [ ] NOW items are committed with owners; NEXT items are directional; LATER items are aspirational
+- [ ] "What We're NOT Building" section has at least 2 items with rationale
+- [ ] Success metrics are specified per theme (not just a list of features)
+- [ ] Language is free of internal jargon — tested by asking: "could an external stakeholder understand this?"
@@ -59,11 +59,11 @@ Organised thematically — not chronologically. Each theme = one section.
 For each paper: internal validity, external validity, bias types, effect size significance vs clinical significance, funding conflicts.

 ## Quality Checks
- Organised thematically not as paper summaries
- Evidence synthesised across papers
- Critical analysis included
- Gaps identified
- All claims cited
+- [ ] Organised thematically (not as individual paper summaries)
+- [ ] Evidence synthesised across papers (not summarised one by one)
+- [ ] Critical analysis of methodology included for key studies
+- [ ] Gaps identified — what the field still needs
+- [ ] All claims cited

 ## Example Trigger Phrases
 - "Write a literature review on [topic]"
@@ -83,6 +83,15 @@ Yours sincerely, [Name, Title, Department]
 - Use "you" and "we" throughout
 - Numbers as digits: "2 tablets" not "two tablets"

+## Quality Checks
+
+- [ ] Written at or below Grade 8 reading level (short words, short sentences)
+- [ ] Active voice used throughout ("We will contact you" not "You will be contacted")
+- [ ] Results letter states the result in the first sentence
+- [ ] Next steps are specific and include timeframes
+- [ ] No Latin or acronyms without explanation
+- [ ] Disclaimer that clinical review is required before sending
+
 ## Example Trigger Phrases
 - "Write a patient letter about [topic]"
 - "Create a patient information leaflet for [procedure]"
@@ -86,10 +86,11 @@ Qualitative: [Framework — e.g. Braun & Clarke], [quality assurance]
 | Write-up | | | |

 ## Quality Checks
- Primary objective is singular and answerable
- Sample size has stated basis
- Ethical considerations complete
- Analysis plan pre-specified
+- [ ] Primary objective is singular and answerable (not compound)
+- [ ] Sample size has a stated basis (power calculation or saturation rationale)
+- [ ] Ethical considerations section is complete
+- [ ] Analysis plan is pre-specified (not "to be determined")
+- [ ] Timeline includes all phases from ethics approval to write-up

 ## Example Trigger Phrases
 - "Write a research protocol for [study]"
@@ -1,6 +1,6 @@
 ---
 name: pm-weekly-review
-description: Structures a PM's weekly review and planning session — synthesising metrics, shipping progress, blockers, and next-week priorities into a shareable update. Use when doing a weekly PM review, writing a weekly update, preparing for a Monday planning session, or reviewing sprint health. Triggers on "weekly review", "weekly update", "PM standup", "weekly planning", "end of week summary".
+description: "Structure a PM's weekly review and planning session. Use when doing a weekly PM review, writing a weekly update, preparing for Monday planning, or reviewing sprint health. Produces a shareable weekly update covering metrics movement, shipping progress, blockers, insights, and next week's top 3 priorities."
 ---

 # PM Weekly Review Skill
@@ -98,6 +98,23 @@ Turn the chaotic end-of-week brain dump into a structured 20-minute ritual that

 ---

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product area or team** you own
+- **Key metrics this week** (with values and prior week comparison)
+- **What shipped, slipped, or is blocked**
+- **Top 3 priorities for next week**
+- **Any customer insights or signals** (optional)
+
+## Quality Checks
+
+- [ ] Metrics include period-over-period comparison (not just raw numbers)
+- [ ] Every blocked item has an owner and a specific unblocking action
+- [ ] Next week's priorities have a "why this week" rationale
+- [ ] Total length is under 400 words (skimmable in 3 minutes)
+- [ ] Reflection section is honest, not aspirational
+
 ## Guidelines

 - Keep the whole document under 400 words — if stakeholders won't read it, it doesn't exist
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-sales",
-  "version": "1.0.0",
-  "description": "Sales skills: Sales Battlecard, Discovery Call Prep, Proposal Writer, Account Plan. Build competitive battlecards, prepare structured discovery calls, write winning proposals, and create strategic account plans.",
+  "version": "1.1.0",
+  "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.",
  "author": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
  },
  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
  "license": "MIT",
-  "keywords": ["sales", "battlecard", "discovery", "proposal", "account-plan", "competitive", "crm"]
+  "keywords": ["sales", "battlecard", "discovery", "proposal", "account-plan", "competitive", "crm", "forecasting", "pipeline", "revenue-model"]
 }
@@ -88,7 +88,10 @@ At end of [period]:
 - [Expansion opportunity] progressed to [stage]
 - Health score moved from [current] to [target]

-## Example Trigger Phrases
- "Build an account plan for [customer]"
- "Create a key account strategy for [account]"
- "Help me plan my approach to renewing [account]"
+## Quality Checks
+
+- [ ] Relationship map identifies decision-makers, influencers, and any relationship gaps
+- [ ] Risks all have mitigation actions and named owners
+- [ ] Growth opportunities include estimated value (even roughly)
+- [ ] 90-day actions are specific (not "have a call" — what call, with whom, to achieve what)
+- [ ] Success criteria are measurable at the end of the planning period
@@ -91,6 +91,14 @@ This call is NOT successful if we only pitched and got "sounds interesting, send
 ### Suggested Next Step
 "Based on what we discussed, the logical next step would be [specific]. Does [day/time] work?"

+## Quality Checks
+
+- [ ] Research summary includes recent news (last 90 days) — not just LinkedIn bio
+- [ ] Call hypothesis is written before the call (not post-rationalised after)
+- [ ] Discovery questions progress from context → pain → business impact → buying process
+- [ ] Success criteria define what "not successful" looks like (not just the ideal outcome)
+- [ ] A specific next step is proposed (not "let's stay in touch")
+
 ## Example Trigger Phrases
 - "Prepare me for a discovery call with [company/contact]"
 - "Build a call brief for my meeting with [name] at [company]"
@@ -86,6 +86,14 @@ Writes commercial proposals that win business — structured around the prospect
 2. We will send contract and confirm kickoff
 3. [Any immediate action]

+## Quality Checks
+
+- [ ] "Understanding Your Situation" reflects what was learned in discovery (not generic)
+- [ ] Outcomes are listed (not just deliverables or features)
+- [ ] "Not included" section is explicit to prevent scope disputes later
+- [ ] Next steps include a specific date and named action
+- [ ] "Valid until" date is included to create urgency
+
 ## Example Trigger Phrases
 - "Write a proposal for [prospect] to [solve their problem]"
 - "Draft a statement of work for [project]"
@@ -73,6 +73,15 @@ When a prospect mentions [Competitor], say: "[Your positioning in one sentence]"
 We win when: [Scenario — e.g. customer prioritises outcome over price]
 We lose when: [Honest scenario — e.g. primary driver is lowest upfront cost]

+## Quality Checks
+
+- [ ] Competitor strengths are listed honestly (not minimised)
+- [ ] Differentiators have proof points (not just claims)
+- [ ] Objection responses are conversational (not scripted-sounding)
+- [ ] Landmine questions are natural and non-confrontational
+- [ ] "When we lose" is included and honest
+- [ ] Battlecard has a review date
+
 ## Example Trigger Phrases
 - "Build a battlecard against [competitor]"
 - "Create a competitive cheat sheet for [competitor]"
@@ -0,0 +1,130 @@
+---
+name: sales-forecasting-model
+description: "Build a structured sales forecast framework for any business or team. Use when asked to build a sales forecast, create a revenue model, project pipeline, or build a bottom-up forecast. Produces a forecast methodology, pipeline model, scenario analysis, and assumption log."
+---
+
+# Sales Forecasting Model Skill
+
+Produces a structured sales forecast framework — from pipeline conversion modelling to scenario analysis. Built for revenue and sales leaders who need a defensible forecast, not a spreadsheet guess.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Business type** (SaaS / Transactional / Services / Marketplace)
+- **Forecast period** (monthly / quarterly / annual)
+- **Sales motion** (inbound / outbound / channel / PLG / mixed)
+- **Current pipeline data** (number of deals, stages, values — rough is fine)
+- **Historical conversion rates** (if available — otherwise model will flag as assumption)
+- **Average deal size and sales cycle length**
+
+## Output Structure
+
+---
+
+# Sales Forecast: [Team / Business] — [Period]
+
+**Forecast type:** [Bottom-up pipeline / Top-down quota / Capacity-based / Hybrid]
+**Period:** [Month / Quarter / Year]
+**Created:** [Date]
+**Forecast owner:** [Name]
+
+---
+
+## 1. Forecast Methodology
+
+**Chosen approach:** [Bottom-up / Top-down / Hybrid] — and why for this context.
+
+Bottom-up (recommended when pipeline data exists):
+> Start from real deals in the pipeline. Apply stage-by-stage conversion rates. Sum to a revenue number.
+
+Top-down (useful for planning, not for calling a number):
+> Start from market or quota. Work backwards to activity targets.
+
+---
+
+## 2. Pipeline Stage Model
+
+Define the sales stages and the expected conversion rate between each:
+
+| Stage | Description | % of deals that advance | Avg time in stage |
+|---|---|---|---|
+| Prospect | Identified, not contacted | — | — |
+| Qualified | Discovery done, confirmed fit | [X%] | [N days] |
+| Proposal | Proposal sent | [X%] | [N days] |
+| Negotiation | Commercial terms being agreed | [X%] | [N days] |
+| Closed Won | Contract signed | [X%] | — |
+
+**Overall pipeline conversion rate:** [X%] (Qualified → Closed Won)
+**Average sales cycle:** [N days from Qualified to Close]
+
+---
+
+## 3. Current Pipeline Snapshot
+
+| Stage | Number of deals | Total value | Expected close (weighted) |
+|---|---|---|---|
+| Qualified | [N] | £[X] | £[X × conversion %] |
+| Proposal | [N] | £[X] | £[X × conversion %] |
+| Negotiation | [N] | £[X] | £[X × conversion %] |
+| **Total** | | **£[X]** | **£[weighted total]** |
+
+**Coverage ratio:** [Weighted pipeline ÷ target = X×]
+*Rule of thumb: 3× pipeline coverage is needed for confident forecast; 2× is tight; below 1.5× is at risk.*
+
+---
+
+## 4. Scenario Analysis
+
+| Scenario | Assumption | Revenue | Probability |
+|---|---|---|---|
+| Upside | All Negotiation + top 50% of Proposal close | £[X] | [%] |
+| Base | Weighted pipeline conversion at historical rates | £[X] | [%] |
+| Downside | Conversion rates drop 20% from historical | £[X] | [%] |
+
+**Committed forecast:** £[X] — [The number the forecast owner is willing to call. Between base and downside.]
+
+---
+
+## 5. Key Assumptions Log
+
+Every forecast is a set of assumptions. Name them explicitly so they can be updated:
+
+| Assumption | Value | Confidence | Source | Last updated |
+|---|---|---|---|---|
+| Avg deal size | £[X] | High/Med/Low | [Last N deals] | [Date] |
+| Sales cycle | [N days] | | | |
+| Close rate from Proposal | [X%] | | | |
+| Seasonal factor | [e.g. Q4 +20%] | | | |
+| Churn/contraction | [X% of ARR at risk] | | | |
+
+---
+
+## 6. Activity-Based Sanity Check
+
+Work backwards from the forecast to check if the required activity is achievable:
+
+To hit £[target]:
+- Deals needed to close: [N] (target ÷ avg deal size)
+- Qualified pipeline needed (at current conversion): [N deals or £value]
+- Discovery calls needed per week to build that pipeline: [N]
+- Outreach needed per week (at [X%] meeting rate): [N]
+
+**Does the team have capacity to generate this?** [Yes / No — flag if not]
+
+---
+
+## Quality Checks
+
+- [ ] Forecast methodology is stated (not just a number)
+- [ ] Stage conversion rates are based on historical data or flagged as assumptions
+- [ ] Coverage ratio is calculated
+- [ ] Three scenarios are modelled (not just one number)
+- [ ] Assumption log is explicit and dated
+- [ ] Activity sanity check confirms the forecast is achievable with current capacity
+
+## Example Trigger Phrases
+
+- "Build a sales forecast for [period]"
+- "Create a pipeline model for [team/business]"
+- "Help me build a bottom-up revenue forecast"
+- "What is our forecast for Q[N] based on current pipeline?"
@@ -1,46 +1,41 @@
 ---
 name: ambiguity-resolver
-description: Structures vague opportunities and unclear briefs into actionable 
-one-page problem statements. Use when user has a vague brief, undefined problem, 
-unclear opportunity, or says "we need to figure out what to do about X", "can 
-you help me make sense of this", or "I've been asked to look into Y".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: discovery
-  tags: [discovery, strategy, problem-framing, ambiguity]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Structure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan."
 ---
+
 # Ambiguity Resolver Skill

-## Purpose
-Turn vague briefs and half-formed opportunities into structured, actionable 
-problem statements — so you can reply with clarity instead of asking for three 
-more meetings.
+Turn vague briefs and half-formed opportunities into structured, actionable problem statements — so you can reply with clarity instead of asking for three more meetings.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The vague brief or opportunity description** (even a single sentence is enough)
+- **Who asked for this** (stakeholder context shapes the framing)
+- **Known constraints** (timeline, budget, team size — if any are known)

 ## Three-Stage Process

 ### Stage 1: Reframe
 - Restate the vague input as 3-5 explicit questions that need answering
 - Identify the unstated assumptions hidden in the brief
- Surface the real decision this feeds into (what will someone do differently 
-  once this is resolved?)
+- Surface the real decision this feeds into (what will someone do differently once this is resolved?)

 ### Stage 2: Scope
 - Define what is explicitly IN scope
 - Define what is explicitly OUT of scope (equally important)
- Identify the deadline pressure: is this urgent/important, important/not urgent,
-  or unclear?
+- Identify the deadline pressure: is this urgent/important, important/not urgent, or unclear?
 - Name who owns the final decision and who needs to be consulted

 ### Stage 3: Action
- Define the minimum viable research: 2-3 activities maximum that would give 
-  enough signal to move forward with confidence
+- Define the minimum viable research: 2-3 activities maximum that would give enough signal to move forward with confidence
 - Time estimate for each activity
 - What each activity would tell you (and what it wouldn't)
 - Proposed check-in point: when to regroup before committing to more

-## Output Format
+**Validate** — Confirm every reframed question maps to at least one research activity. Verify scope boundaries are specific enough to say "no" to something concrete.
+
+## Output Structure

 ### Problem Brief: [Opportunity Area]

@@ -59,9 +54,27 @@ more meetings.
 **Timeline:** [Real deadline if known, or "unclear — recommend setting one"]

 **Minimum viable research:**
-| Activity | Time required | What it tells us |
-|----------|--------------|------------------|
-| [activity] | [time] | [insight] |
+| Activity | Time required | What it tells us | What it won't tell us |
+|----------|--------------|------------------|-----------------------|
+| [activity] | [time] | [insight] | [limitation] |

-**Proposed check-in:** After [activity], regroup to decide whether to proceed 
-or pivot.
+**Proposed check-in:** After [activity], regroup to decide whether to proceed or pivot.
+
+## Example (Partial)
+
+Input: *"We need to figure out what to do about our enterprise customers."*
+
+**Restated as questions:**
+1. Are enterprise customers churning, underperforming on expansion, or both?
+2. Is this a product gap, a support/service gap, or a pricing/packaging issue?
+3. What does "do something" look like — a new initiative, a policy change, or a resource shift?
+
+**In scope:** Enterprise accounts ($50K+ ARR) showing declining health scores in the last two quarters
+**Out of scope:** SMB segment, new enterprise acquisition strategy
+
+## Quality Checks
+
+- [ ] Every reframed question is specific enough to research (not "how do we improve things?")
+- [ ] Scope boundaries name something concrete that is excluded
+- [ ] Research activities are achievable within the stated timeline
+- [ ] Decision owner is identified (not "leadership" — a specific person or role)
@@ -1,21 +1,19 @@
 ---
 name: competitive-intelligence-monitor
-description: Continuously monitors competitor signals and surfaces strategic 
-implications for your roadmap. Use when user asks to "monitor competitors", 
-"track competitive landscape", "what are competitors doing this week", 
-"competitive briefing", or "what has changed in the market".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: strategy
-  tags: [strategy, competitive-intel, roadmapping]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Monitor competitor signals and surface strategic implications for your roadmap. Use when asked to monitor competitors, track the competitive landscape, produce a competitive briefing, or understand what has changed in the market this week or month. Produces a structured intelligence brief with high/medium/low priority signals, roadmap implications, and a strategic landscape summary."
 ---
+
 # Competitive Intelligence Monitor Skill

-## Purpose
-Turn scattered competitor updates into structured weekly intelligence — not just 
-"what they did" but "what changed since last week and what it means for us."
+Turn scattered competitor updates into structured weekly intelligence — not just "what they did" but "what changed since last week and what it means for us."
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Competitors to monitor** (list of company names)
+- **Your current roadmap or strategic priorities** (to assess relevance of signals)
+- **Previous brief or last run summary** (for diff mode — what's new vs. last time)
+- **Time period** (this week, this month)

 ## Signal Categories to Monitor
 - **Product signals:** New features, removals, UX changes, beta programmes
@@ -33,6 +31,7 @@ Turn scattered competitor updates into structured weekly intelligence — not ju
 4. Rate threat level: High / Medium / Low / Watch
 5. Connect each signal to a specific item on the provided roadmap
 6. Recommend response: Accelerate / Deprioritise / Monitor / Investigate
+7. **Validate** — Every High signal must have a specific recommended action and owner. "Monitor" is only acceptable for Low and Watch ratings.

 ### Subsequent Runs (Diff Only)
 1. Compare current signals against previous run summary
@@ -40,7 +39,7 @@ Turn scattered competitor updates into structured weekly intelligence — not ju
 3. Flag if a previously Low signal has escalated to High
 4. Keep output under 300 words — brevity is the point

-## Output Format
+## Output Structure

 ### Competitive Intelligence Brief — [Date]
 **New Since Last Run:** [n signals]
@@ -57,7 +56,10 @@ Turn scattered competitor updates into structured weekly intelligence — not ju
 **This Week's Strategic Summary:**
 [2 sentences max — what is the overall competitive landscape doing?]

-## OpenClaw Configuration
-Add to YAML frontmatter for scheduled runs:
-`schedule: weekly-monday-0800`
-Persistent memory stores last run summary for diff comparison.
+## Quality Checks
+
+- [ ] Every High-priority signal has a specific response action and owner
+- [ ] Signals are categorised (not just listed as "they did X")
+- [ ] Roadmap connections are specific (not "generally relevant")
+- [ ] Diff mode output is under 300 words
+- [ ] Strategic summary describes the landscape trend, not just repeats individual signals
@@ -1,13 +1,19 @@
 ---
 name: competitor-signal-tracker
-description: Analyse competitor moves and surface strategic implications for your product
-tool_integration: Notion
+description: "Analyse competitor moves and surface strategic implications for your product. Use when asked to track competitor signals, analyse a competitor announcement, understand what a competitor is doing strategically, or produce a competitive intelligence report. Produces a categorised signal analysis with threat ratings, roadmap implications, and recommended responses."
 ---
+
 # Competitor Signal Tracker Skill

-## Purpose
 Turn scattered competitor information into structured strategic intelligence — not just "what they did" but "what it means for us."

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Competitor name(s)** and the signals/updates to analyse
+- **Your product's current roadmap or strategic priorities** (to assess relevance)
+- **Time period** the signals cover (this week, this month, etc.)
+
 ## Signal Categories to Track
 - **Product signals:** New features, removals, UX changes, beta programmes
 - **Pricing signals:** Changes to tiers, free limits, enterprise terms
@@ -21,8 +27,9 @@ Turn scattered competitor information into structured strategic intelligence —
 3. Rate strategic threat level: High / Medium / Low / Watch
 4. Connect to your roadmap: does this accelerate, validate, or challenge any of your bets?
 5. Recommend a response: Accelerate existing initiative / Deprioritise / Monitor / Investigate further
+6. **Validate** — Confirm every High threat has a specific recommended response with an owner. "Monitor" is not an acceptable response for High-rated threats.

-## Output Format
+## Output Structure

 ### Competitive Intelligence Report — [Date]

@@ -35,4 +42,12 @@ Turn scattered competitor information into structured strategic intelligence —
 **Recommended Response:** [Action + owner + timeline]

 #### Strategic Summary
-[2-3 sentences on the overall competitive landscape shift this week/month]
+[2-3 sentences on the overall competitive landscape shift this period]
+
+## Quality Checks
+
+- [ ] Every signal is categorised (not just described)
+- [ ] Threat level is justified — not assigned arbitrarily
+- [ ] High-threat signals have specific recommended responses (not "monitor")
+- [ ] Implications connect to specific roadmap items or strategic bets
+- [ ] Strategic summary gives a landscape-level view, not just a list of individual signals
@@ -1,13 +1,20 @@
 ---
 name: executive-update
-description: Transform detailed product updates into concise executive briefings
-tool_integration: Slack, Microsoft Teams
+description: "Transform detailed product updates into concise executive briefings. Use when asked to write an executive update, leadership update, product update for the exec team, or a C-suite product briefing. Produces a structured 250-word briefing with headline, key metrics, progress, risks, decisions needed, and next steps."
 ---
+
 # Executive Update Skill

-## Purpose
 Produce a stakeholder update that busy executives will actually read — structured around what they care about: decisions, risks, and numbers.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product update or notes** (raw input to transform — even bullet points work)
+- **Audience** (CEO, board, specific exec, or general leadership)
+- **Period** (this week / sprint / month / quarter)
+- **Key metrics** (what numbers matter to this audience)
+
 ## Executive Communication Principles
 - Lead with the headline, not the context
 - Every update should answer: "So what does this mean for the business?"
@@ -20,8 +27,9 @@ Produce a stakeholder update that busy executives will actually read — structu
 3. Write in reverse pyramid style — most important first
 4. Limit to 250 words maximum for the main body
 5. Add a "Decisions Needed" section with clear options and your recommendation
+6. **Validate** — Confirm every decision needed has a specific option and recommendation (not just "TBD"), and every risk has a mitigation or watch plan

-## Output Format
+## Output Structure

 ### Product Update — [Date / Sprint / Month]
 **Headline:** [One sentence on the most important thing]
@@ -42,3 +50,11 @@ Produce a stakeholder update that busy executives will actually read — structu

 **What's Next:**
 [2-3 bullets on next period priorities]
+
+## Quality Checks
+
+- [ ] Whole update is under 250 words (if not, cut ruthlessly)
+- [ ] Every metric includes a comparison point (vs. target or last period)
+- [ ] Every risk has a mitigation or watch action
+- [ ] Every decision needed has at least two options and a recommendation
+- [ ] Written for a CFO or CEO — no jargon, all outcomes
@@ -1,38 +1,29 @@
 ---
 name: stakeholder-influence-mapper
-description: Maps stakeholders for a product decision and produces a tailored 
-influence strategy with draft talking points. Use when user needs to "get 
-alignment", "build consensus", "get buy-in from engineering or finance or legal", 
-"present to stakeholders", or "navigate organisational resistance".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: stakeholder-communication
-  tags: [stakeholders, influence, communication, alignment]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Map stakeholders for a product decision and produce a tailored influence strategy with talking points. Use when asked to get alignment, build consensus, get buy-in from engineering or finance or legal, navigate organisational resistance, or plan stakeholder conversations for a major initiative. Produces a stakeholder map, recommended conversation sequence, and tailored talking points per stakeholder."
 ---
+
 # Stakeholder Influence Mapper Skill

-## Purpose
-Turn a product initiative into a structured influence plan — who needs to be 
-aligned, in what order, and exactly what to say to each person in their language.
+Turn a product initiative into a structured influence plan — who needs to be aligned, in what order, and exactly what to say to each person in their language.

 ## Required Inputs
- Initiative description (what you want to do and why)
- List of key stakeholders involved (name, role, relationship to initiative)
- Timeline pressure (when do you need a decision?)
- Any known objections or political context
+
+Ask the user for these if not provided:
+- **Initiative description** (what you want to do and why)
+- **List of key stakeholders** (name, role, relationship to initiative)
+- **Timeline pressure** (when do you need a decision?)
+- **Any known objections or political context** (what you're already aware of)

 ## Process
-1. Build stakeholder map with: role, primary concern, decision authority 
-   (blocker / influencer / informed), current stance (supportive / neutral / 
-   resistant / unknown)
+1. Build stakeholder map with: role, primary concern, decision authority (blocker / influencer / informed), current stance (supportive / neutral / resistant / unknown)
 2. Identify the critical path of conversations — who must be won before others
 3. For each stakeholder, lead with their concern, not your ask
 4. Prepare one likely objection per stakeholder and a prepared response
 5. Flag any stakeholders who should NOT be approached until others are aligned
+6. **Validate** — Confirm every "blocker" stakeholder has a specific tactic (not just "have a conversation"), and that the sequence accounts for political dependencies

-## Output Format
+## Output Structure

 ### Stakeholder Map: [Initiative Name]

@@ -59,3 +50,11 @@ aligned, in what order, and exactly what to say to each person in their language
 - Engineering leads want technical feasibility acknowledged first
 - Finance stakeholders want ROI framing before anything else
 - Legal/compliance stakeholders want risk mitigation addressed upfront
+
+## Quality Checks
+
+- [ ] Every blocker has a specific tactic (not just "have a chat")
+- [ ] Conversation sequence accounts for political dependencies
+- [ ] Each stakeholder's talking points lead with their concern, not your agenda
+- [ ] At least one "do not approach until X is aligned" flag is considered
+- [ ] The ask from each stakeholder is a single, specific thing (not a vague "support")
@@ -1,40 +1,30 @@
 ---
 name: strategic-narrative-generator
-description: Generates the strategic story connecting your roadmap to company 
-goals in a form non-technical stakeholders can repeat. Use when user needs to 
-"explain the roadmap", "present strategy to leadership or the board", "write the 
-why behind the roadmap", "create a narrative for all-hands", or "make the 
-roadmap tell a story".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: roadmapping
-  tags: [strategy, roadmap, executive-communication, narrative]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Generate the strategic story connecting a product roadmap to company goals in a form non-technical stakeholders can repeat. Use when asked to explain the roadmap, present strategy to leadership or the board, write the why behind the roadmap, create a narrative for all-hands, or make the roadmap tell a story. Produces a themed narrative with executive summary, progression arc, hard-question preparation, and what's-not-on-the-roadmap section."
 ---
+
 # Strategic Narrative Generator Skill

-## Purpose
-Turn a prioritised initiative list into a strategic narrative — the story that 
-explains not just what you're building but why, why now, and why this sequence. 
-The kind of narrative a board member can repeat back correctly after one hearing.
+Turn a prioritised initiative list into a strategic narrative — the story that explains not just what you're building but why, why now, and why this sequence.

 ## Required Inputs
- Prioritised initiative list (with rough timelines)
- Current OKRs or strategic priorities (1-3)
- Competitive or market context (optional but improves output significantly)
+
+Ask the user for these if not provided:
+- **Prioritised initiative list** (with rough timelines)
+- **Current OKRs or strategic priorities** (1-3)
+- **Audience** (board, leadership team, all-hands, investors)
+- **Competitive or market context** (optional but improves output significantly)

 ## Process
-1. Read the initiative list and identify 2-3 natural strategic themes
-2. For each theme: articulate the problem it addresses, the customer it serves, 
-   and the metric it moves
+1. Identify 2-3 natural strategic themes from the initiative list
+2. For each theme: articulate the problem, the customer it serves, and the metric it moves
 3. Build the progression narrative: how does Q1 set up Q2? How does H1 set up H2?
 4. Write executive summary in under 100 words (the version someone can repeat)
-5. Anticipate the 3 hardest questions a sceptical board member would ask — 
-   and draft answers
-6. Identify what's NOT on the roadmap and why (this builds credibility)
+5. Anticipate the 3 hardest questions a sceptical board member would ask — draft answers
+6. Identify what's NOT on the roadmap and why
+7. **Validate** — Confirm every initiative maps to a theme. If an initiative is orphaned, either create a theme for it or flag it as a narrative gap.

-## Output Format
+## Output Structure

 ### Product Strategy Narrative: [Period]

@@ -64,8 +54,16 @@ The kind of narrative a board member can repeat back correctly after one hearing
 **What's Not on the Roadmap (and Why):**
 [2-3 items — shows strategic discipline, not just prioritisation]

-## Tone Rules
+## Tone
 - Write for a CFO, not an engineer
 - Lead with outcomes, not features
 - Every sentence should answer "so what?"
 - Avoid jargon — if you can't say it plainly, the strategy isn't clear enough yet
+
+## Quality Checks
+
+- [ ] Executive summary is under 100 words and can stand alone
+- [ ] Every initiative in the input maps to a strategic theme
+- [ ] Each theme has a specific, measurable metric (not "improve engagement")
+- [ ] Progression story shows causal links between quarters, not just chronological listing
+- [ ] "Not on the roadmap" section includes at least 2 items with clear rationale
@@ -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
@@ -88,7 +88,10 @@ At end of [period]:
 - [Expansion opportunity] progressed to [stage]
 - Health score moved from [current] to [target]

-## Example Trigger Phrases
- "Build an account plan for [customer]"
- "Create a key account strategy for [account]"
- "Help me plan my approach to renewing [account]"
+## Quality Checks
+
+- [ ] Relationship map identifies decision-makers, influencers, and any relationship gaps
+- [ ] Risks all have mitigation actions and named owners
+- [ ] Growth opportunities include estimated value (even roughly)
+- [ ] 90-day actions are specific (not "have a call" — what call, with whom, to achieve what)
+- [ ] Success criteria are measurable at the end of the planning period
@@ -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
@@ -1,46 +1,41 @@
 ---
 name: ambiguity-resolver
-description: Structures vague opportunities and unclear briefs into actionable 
-one-page problem statements. Use when user has a vague brief, undefined problem, 
-unclear opportunity, or says "we need to figure out what to do about X", "can 
-you help me make sense of this", or "I've been asked to look into Y".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: discovery
-  tags: [discovery, strategy, problem-framing, ambiguity]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Structure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan."
 ---
+
 # Ambiguity Resolver Skill

-## Purpose
-Turn vague briefs and half-formed opportunities into structured, actionable 
-problem statements — so you can reply with clarity instead of asking for three 
-more meetings.
+Turn vague briefs and half-formed opportunities into structured, actionable problem statements — so you can reply with clarity instead of asking for three more meetings.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The vague brief or opportunity description** (even a single sentence is enough)
+- **Who asked for this** (stakeholder context shapes the framing)
+- **Known constraints** (timeline, budget, team size — if any are known)

 ## Three-Stage Process

 ### Stage 1: Reframe
 - Restate the vague input as 3-5 explicit questions that need answering
 - Identify the unstated assumptions hidden in the brief
- Surface the real decision this feeds into (what will someone do differently 
-  once this is resolved?)
+- Surface the real decision this feeds into (what will someone do differently once this is resolved?)

 ### Stage 2: Scope
 - Define what is explicitly IN scope
 - Define what is explicitly OUT of scope (equally important)
- Identify the deadline pressure: is this urgent/important, important/not urgent,
-  or unclear?
+- Identify the deadline pressure: is this urgent/important, important/not urgent, or unclear?
 - Name who owns the final decision and who needs to be consulted

 ### Stage 3: Action
- Define the minimum viable research: 2-3 activities maximum that would give 
-  enough signal to move forward with confidence
+- Define the minimum viable research: 2-3 activities maximum that would give enough signal to move forward with confidence
 - Time estimate for each activity
 - What each activity would tell you (and what it wouldn't)
 - Proposed check-in point: when to regroup before committing to more

-## Output Format
+**Validate** — Confirm every reframed question maps to at least one research activity. Verify scope boundaries are specific enough to say "no" to something concrete.
+
+## Output Structure

 ### Problem Brief: [Opportunity Area]

@@ -59,9 +54,27 @@ more meetings.
 **Timeline:** [Real deadline if known, or "unclear — recommend setting one"]

 **Minimum viable research:**
-| Activity | Time required | What it tells us |
-|----------|--------------|------------------|
-| [activity] | [time] | [insight] |
+| Activity | Time required | What it tells us | What it won't tell us |
+|----------|--------------|------------------|-----------------------|
+| [activity] | [time] | [insight] | [limitation] |

-**Proposed check-in:** After [activity], regroup to decide whether to proceed 
-or pivot.
+**Proposed check-in:** After [activity], regroup to decide whether to proceed or pivot.
+
+## Example (Partial)
+
+Input: *"We need to figure out what to do about our enterprise customers."*
+
+**Restated as questions:**
+1. Are enterprise customers churning, underperforming on expansion, or both?
+2. Is this a product gap, a support/service gap, or a pricing/packaging issue?
+3. What does "do something" look like — a new initiative, a policy change, or a resource shift?
+
+**In scope:** Enterprise accounts ($50K+ ARR) showing declining health scores in the last two quarters
+**Out of scope:** SMB segment, new enterprise acquisition strategy
+
+## Quality Checks
+
+- [ ] Every reframed question is specific enough to research (not "how do we improve things?")
+- [ ] Scope boundaries name something concrete that is excluded
+- [ ] Research activities are achievable within the stated timeline
+- [ ] Decision owner is identified (not "leadership" — a specific person or role)
@@ -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)
@@ -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]?"
@@ -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]
@@ -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)
@@ -1,21 +1,19 @@
 ---
 name: competitive-intelligence-monitor
-description: Continuously monitors competitor signals and surfaces strategic 
-implications for your roadmap. Use when user asks to "monitor competitors", 
-"track competitive landscape", "what are competitors doing this week", 
-"competitive briefing", or "what has changed in the market".
-metadata:
-  author: Mohit Aggarwal
-  version: 1.0.0
-  category: strategy
-  tags: [strategy, competitive-intel, roadmapping]
-  documentation: https://github.com/mohitagw15856/pm-claude-skills
+description: "Monitor competitor signals and surface strategic implications for your roadmap. Use when asked to monitor competitors, track the competitive landscape, produce a competitive briefing, or understand what has changed in the market this week or month. Produces a structured intelligence brief with high/medium/low priority signals, roadmap implications, and a strategic landscape summary."
 ---
+
 # Competitive Intelligence Monitor Skill

-## Purpose
-Turn scattered competitor updates into structured weekly intelligence — not just 
-"what they did" but "what changed since last week and what it means for us."
+Turn scattered competitor updates into structured weekly intelligence — not just "what they did" but "what changed since last week and what it means for us."
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Competitors to monitor** (list of company names)
+- **Your current roadmap or strategic priorities** (to assess relevance of signals)
+- **Previous brief or last run summary** (for diff mode — what's new vs. last time)
+- **Time period** (this week, this month)

 ## Signal Categories to Monitor
 - **Product signals:** New features, removals, UX changes, beta programmes
@@ -33,6 +31,7 @@ Turn scattered competitor updates into structured weekly intelligence — not ju
 4. Rate threat level: High / Medium / Low / Watch
 5. Connect each signal to a specific item on the provided roadmap
 6. Recommend response: Accelerate / Deprioritise / Monitor / Investigate
+7. **Validate** — Every High signal must have a specific recommended action and owner. "Monitor" is only acceptable for Low and Watch ratings.

 ### Subsequent Runs (Diff Only)
 1. Compare current signals against previous run summary
@@ -40,7 +39,7 @@ Turn scattered competitor updates into structured weekly intelligence — not ju
 3. Flag if a previously Low signal has escalated to High
 4. Keep output under 300 words — brevity is the point

-## Output Format
+## Output Structure

 ### Competitive Intelligence Brief — [Date]
 **New Since Last Run:** [n signals]
@@ -57,7 +56,10 @@ Turn scattered competitor updates into structured weekly intelligence — not ju
 **This Week's Strategic Summary:**
 [2 sentences max — what is the overall competitive landscape doing?]

-## OpenClaw Configuration
-Add to YAML frontmatter for scheduled runs:
-`schedule: weekly-monday-0800`
-Persistent memory stores last run summary for diff comparison.
+## Quality Checks
+
+- [ ] Every High-priority signal has a specific response action and owner
+- [ ] Signals are categorised (not just listed as "they did X")
+- [ ] Roadmap connections are specific (not "generally relevant")
+- [ ] Diff mode output is under 300 words
+- [ ] Strategic summary describes the landscape trend, not just repeats individual signals
@@ -1,13 +1,19 @@
 ---
 name: competitor-signal-tracker
-description: Analyse competitor moves and surface strategic implications for your product
-tool_integration: Notion
+description: "Analyse competitor moves and surface strategic implications for your product. Use when asked to track competitor signals, analyse a competitor announcement, understand what a competitor is doing strategically, or produce a competitive intelligence report. Produces a categorised signal analysis with threat ratings, roadmap implications, and recommended responses."
 ---
+
 # Competitor Signal Tracker Skill

-## Purpose
 Turn scattered competitor information into structured strategic intelligence — not just "what they did" but "what it means for us."

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Competitor name(s)** and the signals/updates to analyse
+- **Your product's current roadmap or strategic priorities** (to assess relevance)
+- **Time period** the signals cover (this week, this month, etc.)
+
 ## Signal Categories to Track
 - **Product signals:** New features, removals, UX changes, beta programmes
 - **Pricing signals:** Changes to tiers, free limits, enterprise terms
@@ -21,8 +27,9 @@ Turn scattered competitor information into structured strategic intelligence —
 3. Rate strategic threat level: High / Medium / Low / Watch
 4. Connect to your roadmap: does this accelerate, validate, or challenge any of your bets?
 5. Recommend a response: Accelerate existing initiative / Deprioritise / Monitor / Investigate further
+6. **Validate** — Confirm every High threat has a specific recommended response with an owner. "Monitor" is not an acceptable response for High-rated threats.

-## Output Format
+## Output Structure

 ### Competitive Intelligence Report — [Date]

@@ -35,4 +42,12 @@ Turn scattered competitor information into structured strategic intelligence —
 **Recommended Response:** [Action + owner + timeline]

 #### Strategic Summary
-[2-3 sentences on the overall competitive landscape shift this week/month]
+[2-3 sentences on the overall competitive landscape shift this period]
+
+## Quality Checks
+
+- [ ] Every signal is categorised (not just described)
+- [ ] Threat level is justified — not assigned arbitrarily
+- [ ] High-threat signals have specific recommended responses (not "monitor")
+- [ ] Implications connect to specific roadmap items or strategic bets
+- [ ] Strategic summary gives a landscape-level view, not just a list of individual signals
@@ -57,6 +57,14 @@ List any standard clauses absent but normally expected for this contract type.

 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"
@@ -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
@@ -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?"
@@ -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
@@ -91,6 +91,14 @@ This call is NOT successful if we only pitched and got "sounds interesting, send
 ### Suggested Next Step
 "Based on what we discussed, the logical next step would be [specific]. Does [day/time] work?"

+## Quality Checks
+
+- [ ] Research summary includes recent news (last 90 days) — not just LinkedIn bio
+- [ ] Call hypothesis is written before the call (not post-rationalised after)
+- [ ] Discovery questions progress from context → pain → business impact → buying process
+- [ ] Success criteria define what "not successful" looks like (not just the ideal outcome)
+- [ ] A specific next step is proposed (not "let's stay in touch")
+
 ## Example Trigger Phrases
 - "Prepare me for a discovery call with [company/contact]"
 - "Build a call brief for my meeting with [name] at [company]"
@@ -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
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
mohitagw15856	450dbde74d	Bump version to 9.0.0 and update description Updated version and description to reflect new features.	2026-05-08 03:08:07 +05:30
mohitagw15856	af23bcc170	Update README.md	2026-05-08 03:06:32 +05:30
mohitagw15856	59c4510055	feat: v9.0.0 — three new agent templates (Discovery, Stakeholder Comms, Launch) This release adds three new agent templates to the library, bringing the total to four. New templates: - PM Discovery Agent: synthesises customer interviews from Notion or Google Drive, identifies cross-interview themes, scores assumption confidence, generates follow-up questions - PM Stakeholder Comms Agent: detects audience type (executive/investor/stakeholder/board), pulls activity from Linear/Jira/Drive, drafts in audience-appropriate format - PM Launch Agent: end-to-end launch coordination with channel-specific content, calendar, success metrics, and launch checklist Each template follows the established pattern: README, AGENT.md, orchestrate.sh, 2 subagents, connectors with example configs, examples, smoke test. Total file count: 37 new files across 3 templates. Updated README to position library as 4-template collection. Bumped marketplace.json from v8.0.0 to v9.0.0.	2026-05-07 22:30:34 +01:00
mohitagw15856	9274b3d378	Add Part 15 to skills list in README	2026-05-06 15:22:39 +01:00
mohitagw15856	a0ed6e52a5	Update version badge from 7.0.0 to 8.0.0	2026-05-06 09:20:03 +01:00
mohitagw15856	84eefcabd6	fix: move templates contributing guide to templates/CONTRIBUTING.md	2026-05-05 23:31:59 +01:00
mohitagw15856	7df025ffaa	Bump version to 8.0.0 and update description Updated version and description to reflect new features and coverage.	2026-05-06 03:57:39 +05:30
mohitagw15856	e5377ca61a	feat: v8.0.0 — first agent template (PM Sprint Agent) following Anthropic's agent template architecture - Added templates/pm-sprint-agent/ directory with full agent template - AGENT.md system prompt with explicit step-by-step workflow - 2 subagents: capacity-analyst and risk-scorer - 2 connectors: linear and jira (with example configs) - Symlinked skills from main library: sprint-planning, sprint-brief - orchestrate.sh end-to-end workflow script - examples/ folder with input and output examples - tests/ folder with smoke test - Updated README to position skills as building blocks for agent templates - Added Anthropic agent templates announcement reference (May 5, 2026) - Bumped marketplace.json to v8.0.0 - Listed 7 candidate agent templates this library supports This is the first agent template in the library. More to follow.	2026-05-05 23:26:08 +01:00
mohitagw15856	bd38a36468	Revise README with new skills and sponsor details Updated README to include new skills and sponsorship information.	2026-04-27 00:54:51 +05:30
mohitagw15856	c1d47fa1ae	update path	2026-04-23 15:36:09 +01:00
mohitagw15856	48be8596d9	Merge pull request #6 from mohitagw15856/feat/v7-engineering-skills feat: v7.0.0 — 6 new engineering skills, star milestone tracker, SKILL_REQUEST.md	2026-04-23 15:24:27 +01:00
mohitagw15856	c0544fb76a	feat: v7.0.0 — 6 new engineering skills, badges, milestone tracker, SKILL_REQUEST.md New skills added to pm-engineering bundle (now 10 skills total): - debugging-log-analyser: stack trace → structured root cause diagnosis + fix - pr-description-writer: diff/commits → reviewer-ready PR description - system-design-interview: full system design with capacity, components, trade-offs - changelog-generator: git log → polished Keep a Changelog entry - test-strategy-doc: spec/PRD → complete test strategy with P0/P1 test cases - runbook-writer: operational runbooks with exact commands, rollback, and escalation README updates: - 5 shields.io badges (stars, skill count, version, install, license) - "See It in Action" demo section - pm-engineering added to Quick Install list - Star Milestone Tracker (100/250/500/1000 stars roadmap) - Engineering table extended from 4 to 10 skills (41–50) - Article 14 link resolved from remote merge Config updates: - marketplace.json: v6.0.0 → v7.0.0, "106 skills" - pm-engineering plugin.json: v1.0.0 → v2.0.0 New file: SKILL_REQUEST.md — community skill voting board Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-23 15:21:43 +01:00
mohitagw15856	ce35e8c5c0	Update link in README for article series	2026-04-22 13:03:21 +05:30
mohitagw15856	a7ee053aac	Merge pull request #5 from mohitagw15856/mohitagw15856-patch-1 Update Part 14 link in README.md	2026-04-21 14:15:24 +01:00
mohitagw15856	5b3eb3ea53	Update Part 14 link in README.md	2026-04-21 14:14:26 +01:00
mohitagw15856	44d211b934	fix: update marketplace.json to v6.0.0 with 100 skills Bumps top-level version from 5.2.0 → 6.0.0, updates description to reflect 100 skills, and syncs 6 plugin entries (pm-gtm, pm-finance, pm-hr, pm-sales, pm-operations, pm-cross) to version 1.1.0 with updated descriptions including the 7 new skills. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-20 21:05:31 +01:00
mohitagw15856	35364c7512	fix: update plugin.json for 6 bundles with new skills and version bumps - pm-gtm v1.1.0: added seo-content-brief, media-pitch - pm-finance v1.1.0: added tax-planning-checklist - pm-hr v1.1.0: added change-management-plan - pm-sales v1.1.0: added sales-forecasting-model - pm-operations v1.1.0: added workshop-facilitation-guide - pm-cross v1.1.0: added teaching-lesson-plan Updated descriptions and keywords in all 6 plugin.json files Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-20 21:02:14 +01:00
mohitagw15856	513e1d3ce7	fix: sync all skill updates and new skills into plugin bundles - Synced 97 existing skill SKILL.md files from skills/ to their plugin bundle copies - Added 7 new skills to plugin bundles: - seo-content-brief, media-pitch -> pm-gtm - tax-planning-checklist -> pm-finance - change-management-plan -> pm-hr - sales-forecasting-model -> pm-sales - workshop-facilitation-guide -> pm-operations - teaching-lesson-plan -> pm-cross Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-20 21:00:08 +01:00
mohitagw15856	d7f6c2cd05	Update README.md	2026-04-21 01:26:58 +05:30
mohitagw15856	844e97f81f	Delete MEDIUM_ARTICLE_DRAFT.md	2026-04-21 01:25:34 +05:30
mohitagw15856	b6e0cbc31b	merge: incorporate remote README updates (article links for parts 10-11) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-20 20:54:59 +01:00
mohitagw15856	f3b9d008fe	feat: 100 skills milestone — 7 new skills + quality improvements across all 93 New skills added: - teaching-lesson-plan: structured lesson plans for any subject/audience/setting - seo-content-brief: complete SEO briefs with intent, competitor gaps, and outline - media-pitch: story-first journalist pitches with angle development framework - change-management-plan: stakeholder analysis, comms strategy, adoption metrics - workshop-facilitation-guide: activity instructions, decision protocols, facilitator moves - sales-forecasting-model: pipeline model, scenario analysis, assumption log - tax-planning-checklist: year-end tax planning across income, pension, CGT, reliefs Quality improvements across all 93 existing skills: - Standardised description format: "Verb the thing. Use when X. Produces Y." - Added Required Inputs section to all skills missing it (prompts for missing info) - Added Quality Checks section to all skills missing it (specific, not generic) - Fixed broken multiline YAML descriptions - Removed non-standard frontmatter keys (tool_integration, metadata blocks) README updated to v6.0.0 with 100-skill count, new skill tables, and article series Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-20 20:52:31 +01:00
mohitagw15856	93c5ab7d71	Update README.md	2026-04-17 16:47:06 +05:30