Update README.md

Delete MEDIUM_ARTICLE_DRAFT.md
merge: incorporate remote README updates (article links for parts 10-11)
2026-04-21 01:26:58 +05:30 · 2026-04-21 01:25:34 +05:30 · 2026-04-20 20:54:59 +01:00 · 2026-04-20 20:52:31 +01:00 · 2026-04-17 16:47:06 +05:30 · 2026-04-17 12:07:27 +01:00
121 changed files with 4942 additions and 3759 deletions
@@ -1,8 +1,8 @@
 {
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "pm-claude-skills",
-  "version": "5.0.0",
-  "description": "80 Claude Skills across 13 professions — product management, marketing, engineering, data, design, leadership, legal, finance, HR, sales, operations, research, and more. Save 10-15 hours per week.",
+  "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.",
  "owner": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
@@ -10,8 +10,8 @@
  "plugins": [
    {
      "name": "pm-essentials",
-      "description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis. The 5 skills every PM needs first.",
-      "version": "3.0.0",
+      "description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, Word Doc Tracked Changes. The essentials every PM needs first.",
+      "version": "3.1.0",
      "category": "productivity",
      "source": "./plugins/pm-essentials",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -34,8 +34,8 @@
    },
    {
      "name": "pm-delivery",
-      "description": "Sprint & delivery skills: Sprint Planning, Technical Spec Template, A/B Test Planner, Go-to-Market Planner, Product Launch Checklist, Sprint Brief, Retro Analysis.",
-      "version": "3.0.0",
+      "description": "Sprint & delivery skills: Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro Analysis, PPTX Slide Auditor.",
+      "version": "3.1.0",
      "category": "productivity",
      "source": "./plugins/pm-delivery",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -83,15 +83,15 @@
    {
      "name": "pm-engineering",
      "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record. Structured outputs for engineering teams and technical PMs.",
-      "version": "1.0.0",
+      "version": "1.1.0",
      "category": "productivity",
      "source": "./plugins/pm-engineering",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
    },
    {
      "name": "pm-data",
-      "description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief. Build North Star metric trees, explain and optimise SQL, and spec dashboards from business questions.",
-      "version": "1.0.0",
+      "description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief, Chart Data Extractor. Build North Star metric trees, explain SQL, spec dashboards, and digitise chart images.",
+      "version": "1.1.0",
      "category": "productivity",
      "source": "./plugins/pm-data",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -122,8 +122,8 @@
    },
    {
      "name": "pm-legal",
-      "description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists. Not a substitute for qualified legal advice.",
-      "version": "1.0.0",
+      "description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists.",
+      "version": "1.1.0",
      "category": "productivity",
      "source": "./plugins/pm-legal",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -170,11 +170,19 @@
    },
    {
      "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 for any audience.",
+      "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",
      "category": "productivity",
      "source": "./plugins/pm-cross",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-figma",
+      "description": "Figma skills for PMs and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter across the full Figma design lifecycle.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-figma",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
    }
  ]
 }
@@ -0,0 +1,65 @@
+---
+name: "🐛 Bug Report"
+about: "A skill isn't triggering correctly, producing wrong output, or something else is broken"
+title: "[BUG] "
+labels: ["bug"]
+assignees: ""
+---
+
+## Which skill is affected?
+
+<!-- e.g. plugins/pm-gtm/skills/go-to-market -->
+
+**Skill path:**
+
+---
+
+## What's the problem?
+
+<!-- Tick all that apply -->
+
+- [ ] Skill isn't triggering when it should
+- [ ] Skill is triggering when it shouldn't
+- [ ] Output is missing a section
+- [ ] Output format is wrong
+- [ ] Skill description is incorrect or misleading
+- [ ] Plugin isn't showing in the marketplace
+- [ ] Installation issue
+- [ ] Other: ___________
+
+---
+
+## What did you expect to happen?
+
+---
+
+## What actually happened?
+
+<!-- Paste the output or describe what went wrong -->
+
+---
+
+## How to reproduce
+
+<!-- Step by step:
+     1. Trigger phrase used: "..."
+     2. Claude Code version: ...
+     3. What happened: ... -->
+
+1.
+2.
+3.
+
+---
+
+## Environment
+
+- **Claude Code version:**
+- **OS:**
+- **Install method:** marketplace / manual / symlink
+
+---
+
+## Any additional context?
+
+<!-- Screenshots, logs, or anything else helpful -->
@@ -0,0 +1,8 @@
+blank_issues_enabled: false
+contact_links:
+  - name: 📚 Read the article series
+    url: https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a
+    about: Full background on the Claude Skills Library and how to use it
+  - name: 💬 Start a Discussion
+    url: https://github.com/mohitagw15856/pm-claude-skills/discussions
+    about: For open-ended conversations, ideas, and community skill sharing
@@ -0,0 +1,21 @@
+---
+name: "💬 Question or Feedback"
+about: "Ask a question about using the skills, or share feedback on the library"
+title: "[QUESTION] "
+labels: ["question"]
+assignees: ""
+---
+
+## What's your question or feedback?
+
+---
+
+## Context
+
+<!-- Which skill or bundle are you asking about? Any relevant details about your setup? -->
+
+---
+
+## What have you already tried?
+
+<!-- If it's a question about getting something working — what have you attempted? -->
@@ -0,0 +1,70 @@
+---
+name: "💡 Skill Request"
+about: "Suggest a new skill you'd like to see added to the library"
+title: "[SKILL REQUEST] "
+labels: ["skill-request"]
+assignees: ""
+---
+
+## What skill are you requesting?
+
+<!-- A short name for the skill, e.g. "Legal Contract Review" or "Sales Battlecard Builder" -->
+
+**Skill name:**
+
+---
+
+## What profession or role is this for?
+
+<!-- Who would use this skill day-to-day? -->
+
+- [ ] Product Management
+- [ ] Marketing & GTM
+- [ ] Engineering & Tech
+- [ ] Data & Analytics
+- [ ] Leadership & People
+- [ ] Design & UX
+- [ ] Business & Strategy
+- [ ] Legal
+- [ ] Finance
+- [ ] HR
+- [ ] Sales
+- [ ] Other: ___________
+
+---
+
+## What workflow does this skill solve?
+
+<!-- Describe the specific task or document this skill should produce.
+     Be as concrete as possible — what do you do today that takes too long? -->
+
+---
+
+## What should the output look like?
+
+<!-- What does a good output from this skill contain?
+     E.g. "A structured contract review with flagged clauses, risk rating, and plain English summary" -->
+
+---
+
+## Example trigger phrases
+
+<!-- How would you naturally ask Claude to use this skill?
+     E.g. "Review this contract", "Flag the key risks in this NDA" -->
+
+-
+-
+
+---
+
+## Are you willing to build this skill yourself?
+
+- [ ] Yes — I'll raise a PR with the SKILL.md
+- [ ] Maybe — I'd like guidance first
+- [ ] No — I'm suggesting it for someone else to build
+
+---
+
+## Any additional context?
+
+<!-- Links, examples, or anything else that would help someone build this skill -->
@@ -0,0 +1,92 @@
+## What does this PR add or change?
+
+<!-- One sentence summary -->
+
+---
+
+## Type of change
+
+- [ ] New skill
+- [ ] Improvement to an existing skill
+- [ ] Bug fix (skill not triggering / wrong output)
+- [ ] Documentation update (README, CONTRIBUTING, etc.)
+- [ ] Marketplace / plugin config change
+- [ ] Other: ___________
+
+---
+
+## New skill checklist
+
+<!-- If you're adding a new skill, tick all of these before requesting review.
+     If this isn't a new skill PR, delete this section. -->
+
+**Skill file**
+- [ ] Skill is in the correct folder: `plugins/[bundle-name]/skills/[skill-name]/SKILL.md`
+- [ ] Frontmatter includes `name` and `description` fields
+- [ ] `description` clearly states when Claude should activate this skill (trigger condition)
+- [ ] `description` clearly states what the skill produces (output description)
+
+**Content quality**
+- [ ] Skill solves a real, recurring professional workflow (not a one-off task)
+- [ ] Output structure is clearly defined with sections and format
+- [ ] Required inputs are listed (what Claude should ask for if not provided)
+- [ ] Quality checks section is included
+- [ ] Example trigger phrases are included (at least 2)
+
+**Safety**
+- [ ] Skill contains no prompt injection attempts or instructions to override Claude's guidelines
+- [ ] Skill does not instruct Claude to collect, store, or transmit personal data
+- [ ] Skill does not contain hardcoded credentials, API keys, or PII
+
+**Testing**
+- [ ] I have tested this skill locally in Claude Code
+- [ ] The skill triggers correctly on the example trigger phrases
+- [ ] The output matches the structure defined in the SKILL.md
+
+---
+
+## What does this skill do?
+
+<!-- 2-3 sentences. What workflow does it solve? Who is it for? -->
+
+---
+
+## Example output
+
+<!-- Paste a real sample output from Claude when this skill was triggered, or describe what it produces.
+     This is the most useful thing you can include for review. -->
+
+---
+
+## Which bundle does this belong in?
+
+<!-- Which existing plugin bundle should this skill be added to?
+     Or are you proposing a new bundle? -->
+
+- [ ] pm-essentials
+- [ ] pm-discovery
+- [ ] pm-planning
+- [ ] pm-delivery
+- [ ] pm-analytics
+- [ ] pm-strategy
+- [ ] pm-advanced
+- [ ] pm-rituals
+- [ ] pm-gtm
+- [ ] pm-engineering
+- [ ] pm-data
+- [ ] pm-people
+- [ ] pm-design
+- [ ] pm-business
+- [ ] New bundle: ___________
+
+---
+
+## Related issue
+
+<!-- If this PR addresses a skill request issue, link it here: "Closes #123" -->
+
+---
+
+## Anything else the reviewer should know?
+
+<!-- Edge cases, limitations, or anything that might need discussion -->
@@ -1,8 +1,10 @@
-# 🧠 Claude Skills Library — 80 Skills for Every Profession
+# 🧠 Claude Skills Library — 100 Skills for Every Profession

-> **Save 8–10 hours per week across 13 professions. Install in 2 minutes.**
+> **Save 8–10 hours per week across 15 professions. Install in 2 minutes. Now with 100 skills and comprehensive quality improvements across every skill.**

-A community-built library of Claude Skills covering product management, marketing, engineering, data, design, 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.
+A community-built library of Claude Skills covering product management, marketing, engineering, 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 (v6.0.0):** 100 skills milestone — 7 new skills added, plus quality improvements across all 93 existing skills (standardised descriptions, Required Inputs sections, and Quality Checks on every skill).

 ---

@@ -10,12 +12,14 @@ A community-built library of Claude Skills covering product management, marketin

 In Claude Code, run:

-/plugin marketplace add https://github.com/mohitagw15856/pm-claude-skills
+/plugin marketplace add mohitagw15856/pm-claude-skills


 Or install by profession:

-claude plugin install pm-essentials@pm-claude-skills     # Core PM
+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-data@pm-claude-skills           # Data + chart data extractor
 claude plugin install pm-legal@pm-claude-skills          # Legal
 claude plugin install pm-finance@pm-claude-skills        # Finance
 claude plugin install pm-hr@pm-claude-skills             # HR
@@ -23,6 +27,7 @@ claude plugin install pm-sales@pm-claude-skills          # Sales
 claude plugin install pm-operations@pm-claude-skills     # Operations
 claude plugin install pm-research@pm-claude-skills       # Research & Healthcare
 claude plugin install pm-cross@pm-claude-skills          # Cross-profession
+claude plugin install pm-figma@pm-claude-skills          # Figma


 Or clone and symlink for auto-updates:
@@ -32,6 +37,29 @@ mkdir -p ~/.claude/skills
 ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/


+---
+
+## 🆕 What's New in v6.0.0 — 100 Skills Milestone
+
+**7 new 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 |
+
+**Quality improvements across all 93 existing skills:**
+- Every skill now has a standardised `description` field using the "Verb the thing. Use when X. Produces Y." format
+- Every skill now has a `Required Inputs` section prompting Claude to ask for missing information before executing
+- Every skill now has a `Quality Checks` section with specific checkboxes Claude verifies before delivering output
+
+**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](#)
+
 ---

 ## 📚 The Article Series
@@ -47,184 +75,219 @@ This repo was built alongside a published article series. Read the full story:
 | Part 5 | What Google, Meta and Anthropic Want From PMs — And the Claude Skills That Deliver It | [Read →](https://medium.com/@mohit15856/what-google-meta-and-anthropic-want-from-pms-and-the-claude-skills-that-deliver-it-b0f2b6cd9340) |
 | Part 6 | I Tested Anthropic's Skill Creator Plugin on My Own Skills | [Read →](https://medium.com/all-about-claude/i-tested-anthropics-skill-creator-plugin-on-my-own-skills-here-s-what-i-found-23ad406b0825) |
 | Part 7 | 33 Claude Skills for PMs Are Now in the Claude Code Marketplace | [Read →](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) |
-| Part 8 | I Added 20 New Claude Skills Beyond Product Management | [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 | *Latest — Link TBC* |
+| Part 8 | I Added 20 New Claude Skills Beyond Product Management | [Read →](https://medium.com/product-powerhouse/i-built-20-new-claude-skills-for-every-profession-heres-the-full-library-50278e00bf72) |
+| Part 9 | 80 Claude Skills for Every Profession — Lawyers, Doctors, Finance, HR, Sales and More | [Read →](https://medium.com/@mohit15856/80-claude-skills-for-every-profession-lawyers-doctors-finance-hr-sales-and-more-3dfde9ec0033) |
+| Part 10 | A Day in the Life With 80 Claude Skills | [Read →](https://medium.com/@mohit15856/a-day-in-the-life-with-80-claude-skills-what-actually-gets-triggered-7caf9f5c159e) |
+| Part 11 | 10 Figma Claude Skills for PMs and Designers | [Read →](https://medium.com/@mohit15856/10-figma-claude-skills-for-pms-and-designers-the-complete-figma-toolkit-784441d07a78)|
+| Part 12 | I Built the Same Skills Library for ChatGPT — Here's What's Different | [Read →](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9) |
+| Part 13 | I Re-Tested My 90 Claude Skills on Opus 4.7 — Here's What Got Better | [Read →](https://medium.com/all-about-claude/i-re-tested-my-90-claude-skills-on-opus-4-7-heres-what-actually-got-better-dd4b9369329e)|
+| Part 14 | I Rebuilt All 93 Skills and Added 7 More: What 100 Skills Taught Me About What Makes a Great Skill | *Latest — Link TBC* |

 ---

-## 🗂️ All 80 Skills
+## 🗂️ All 100 Skills

-### 🛠️ Product Management (Skills 1–33)
+### 🛠️ Product Management (Skills 1–34)
 **Bundles:** `pm-essentials` · `pm-discovery` · `pm-planning` · `pm-delivery` · `pm-analytics` · `pm-strategy` · `pm-advanced` · `pm-rituals`

-> The original toolkit covering the full PM lifecycle — discovery, prioritisation, delivery, strategy, stakeholder comms, and weekly rituals.
+> The original toolkit covering the full PM lifecycle — discovery, prioritisation, delivery, strategy, stakeholder comms, and weekly rituals. Now includes Word tracked changes and PowerPoint slide auditing.

 | # | Skill | What It Does |
 |---|---|---|
-| 1–5 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis |
-| 6–9 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
-| 10–15 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
-| 16–22 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro |
-| 23–25 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
-| 26–31 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
-| 32–33 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |
+| 1–6 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, **Word Doc Tracked Changes** 🆕 |
+| 7–10 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
+| 11–16 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
+| 17–24 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro, **PPTX Slide Auditor** 🆕 |
+| 25–27 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
+| 28–33 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
+| 34 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |

 > See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full PM skills detail.

 ---

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

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 34 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
-| 35 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
-| 36 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
-| 37 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
+| 35 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
+| 36 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
+| 37 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
+| 38 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
+| 39 | **SEO Content Brief** 🆕 | `skills/seo-content-brief/` | Complete SEO briefs with search intent, competitor gap analysis, content outline, and on-page requirements |
+| 40 | **Media Pitch** 🆕 | `skills/media-pitch/` | Story-first journalist pitches with angle development framework and pitch writing rules |

 ---

-### 👩‍💻 Engineering & Tech (Skills 38–41)
+### 👩‍💻 Engineering & Tech (Skills 41–44)
 **Bundle:** `pm-engineering`

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

 ---

-### 📊 Data & Analytics (Skills 42–44)
+### 📊 Data & Analytics (Skills 45–48)
 **Bundle:** `pm-data`

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

 ---

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

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

 ---

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

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

 ---

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

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

 ---

-### ⚖️ Legal (Skills 54–57)
+### ⚖️ Legal (Skills 58–61)
 **Bundle:** `pm-legal`

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

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

 ---

-### 💰 Finance (Skills 58–61)
+### 💰 Finance (Skills 62–66)
 **Bundle:** `pm-finance`

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

 ---

-### 👥 HR (Skills 62–65)
+### 👥 HR (Skills 67–71)
 **Bundle:** `pm-hr`

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

 ---

-### 🤝 Sales (Skills 66–69)
+### 🤝 Sales (Skills 72–76)
 **Bundle:** `pm-sales`

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

 ---

-### ⚙️ Operations (Skills 70–73)
+### ⚙️ Operations (Skills 77–81)
 **Bundle:** `pm-operations`

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

 ---

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

 ---

-### 🌐 Cross-Profession (Skills 78–80)
+### 🌐 Cross-Profession (Skills 86–89)
 **Bundle:** `pm-cross`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 78 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
-| 79 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
-| 80 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 86 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
+| 87 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
+| 88 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 89 | **Teaching Lesson Plan** 🆕 | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
+
+---
+
+### 🖼️ Figma (Skills 90–100 — reaching the milestone)
+**Bundle:** `pm-figma`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 90 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
+| 91 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
+| 92 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
+| 93 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
+| 94 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
+| 95 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
+| 96 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
+| 97 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
+| 98 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
+| 99 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
+| 100 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
+
+claude plugin install pm-figma@pm-claude-skills
+

 ---

@@ -260,14 +323,11 @@ 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).

@@ -280,7 +340,7 @@ Have a skill idea? [Open an issue](../../issues) or raise it in [Discussions](..
 Install the whole library or just the bundles you need:

 # Install everything
-/plugin marketplace add https://github.com/mohitagw15856/pm-claude-skills
+/plugin marketplace add mohitagw15856/pm-claude-skills

 # Install by profession
 claude plugin install pm-essentials@pm-claude-skills
@@ -304,7 +364,36 @@ claude plugin install pm-sales@pm-claude-skills
 claude plugin install pm-operations@pm-claude-skills
 claude plugin install pm-research@pm-claude-skills
 claude plugin install pm-cross@pm-claude-skills
+claude plugin install pm-figma@pm-claude-skills

+---
+
+## 🤖 Companion Repository — ChatGPT Custom GPTs
+
+If you use ChatGPT instead of Claude Code, there's a companion repo with the same professional frameworks built as Custom GPT system prompts:
+
+**[professional-gpt-library](https://github.com/mohitagw15856/professional-gpt-library)** — 10 starter GPTs across 8 professions, MIT licence.
+
+Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGPT](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9)
+
+---
+
+## 🛠️ Custom Skills for Your Team
+
+The 100 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
+
+**What custom skills look like in practice:**
+
+- A law firm's contract review skill trained on their specific clause library and risk tolerance
+- A SaaS company's sprint brief skill that knows their engineering conventions and definition of done
+- A finance team's board pack skill that follows their exact narrative structure and slide format
+- An HR team's job description skill that reflects their values language and includes their specific benefits
+
+The difference between a generic skill and one built for your context is significant. Generic skills eliminate the blank page. Custom skills eliminate the rework.
+
+**If you want skills built for your team's specific workflows — [get in touch](mailto:mohit15856@gmail.com).**
+
+Include a brief description of your team, the workflows you want to automate, and the tools you use. I'll come back to you within 48 hours.

 ---

@@ -1,180 +0,0 @@
-#!/bin/bash
-
-# =============================================================================
-# create-plugin-jsons.sh
-# Run this from the ROOT of your pm-claude-skills repo.
-# Creates .claude-plugin/plugin.json inside each of the 6 new plugin folders.
-# Your skills/ subfolders are already in place — this just adds the missing
-# plugin.json files.
-# =============================================================================
-
-set -e
-
-REPO_ROOT="$(pwd)"
-
-echo "================================================"
-echo " pm-claude-skills — Creating plugin.json files"
-echo " Running from: $REPO_ROOT"
-echo "================================================"
-echo ""
-
-# Sanity check — make sure we're in the right place
-if [ ! -d "$REPO_ROOT/pm-gtm" ] || [ ! -d "$REPO_ROOT/pm-engineering" ]; then
-  echo "ERROR: Cannot find pm-gtm or pm-engineering folders."
-  echo "Make sure you are running this from the ROOT of your pm-claude-skills repo."
-  echo "Example: cd ~/pm-claude-skills && bash create-plugin-jsons.sh"
-  exit 1
-fi
-
-# ---------------------------------------------------------
-# BUNDLE 1: pm-gtm
-# ---------------------------------------------------------
-echo "Creating pm-gtm/.claude-plugin/plugin.json..."
-mkdir -p pm-gtm/.claude-plugin
-cat > pm-gtm/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-gtm",
-  "version": "1.0.0",
-  "description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign. Build positioning statements, messaging pillars, feature lists, use cases, and launch campaigns.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "marketing", "gtm", "positioning", "content-calendar", "competitor-analysis", "email-campaign"]
-}
-EOF
-echo "  ✓ pm-gtm/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 2: pm-engineering
-# ---------------------------------------------------------
-echo "Creating pm-engineering/.claude-plugin/plugin.json..."
-mkdir -p pm-engineering/.claude-plugin
-cat > pm-engineering/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-engineering",
-  "version": "1.0.0",
-  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record. Structured outputs for engineering teams and technical PMs.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture"]
-}
-EOF
-echo "  ✓ pm-engineering/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 3: pm-data
-# ---------------------------------------------------------
-echo "Creating pm-data/.claude-plugin/plugin.json..."
-mkdir -p pm-data/.claude-plugin
-cat > pm-data/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-data",
-  "version": "1.0.0",
-  "description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief. Build North Star metric trees, explain and optimise SQL, and spec dashboards from business questions.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "data", "analytics", "metrics", "north-star", "sql", "dashboard", "kpi"]
-}
-EOF
-echo "  ✓ pm-data/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 4: pm-people
-# ---------------------------------------------------------
-echo "Creating pm-people/.claude-plugin/plugin.json..."
-mkdir -p pm-people/.claude-plugin
-cat > pm-people/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-people",
-  "version": "1.0.0",
-  "description": "Leadership & people skills: Performance Review, Hiring Rubric, Team Offsite Planner. Write structured reviews, build interview scorecards, and plan offsites from goals to minute-by-minute agenda.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "leadership", "management", "performance-review", "hiring", "interview", "offsite", "people"]
-}
-EOF
-echo "  ✓ pm-people/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 5: pm-design
-# ---------------------------------------------------------
-echo "Creating pm-design/.claude-plugin/plugin.json..."
-mkdir -p pm-design/.claude-plugin
-cat > pm-design/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-design",
-  "version": "1.0.0",
-  "description": "Design & UX skills: UX Research Plan, Design Critique, Accessibility Audit. Create research plans with discussion guides, critique designs using JTBD and Gestalt principles, and audit for WCAG 2.2 compliance.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "design", "ux", "user-research", "accessibility", "wcag", "usability", "design-critique"]
-}
-EOF
-echo "  ✓ pm-design/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# BUNDLE 6: pm-business
-# ---------------------------------------------------------
-echo "Creating pm-business/.claude-plugin/plugin.json..."
-mkdir -p pm-business/.claude-plugin
-cat > pm-business/.claude-plugin/plugin.json << 'EOF'
-{
-  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
-  "name": "pm-business",
-  "version": "1.0.0",
-  "description": "Business & strategy skills: Investor Update, Board Deck Narrative, Job Application. Write investor updates investors actually read, structure board presentations, and tailor CVs and cover letters with ATS optimisation.",
-  "author": {
-    "name": "Mohit Aggarwal",
-    "email": "mohit15856@gmail.com"
-  },
-  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
-  "license": "MIT",
-  "keywords": ["product-management", "business", "strategy", "investor-update", "board-deck", "startup", "career", "job-application"]
-}
-EOF
-echo "  ✓ pm-business/.claude-plugin/plugin.json created"
-
-# ---------------------------------------------------------
-# DONE
-# ---------------------------------------------------------
-echo ""
-echo "================================================"
-echo " All 6 plugin.json files created successfully!"
-echo ""
-echo "  pm-gtm/.claude-plugin/plugin.json"
-echo "  pm-engineering/.claude-plugin/plugin.json"
-echo "  pm-data/.claude-plugin/plugin.json"
-echo "  pm-people/.claude-plugin/plugin.json"
-echo "  pm-design/.claude-plugin/plugin.json"
-echo "  pm-business/.claude-plugin/plugin.json"
-echo ""
-echo " Next steps:"
-echo "  1. bash add-plugin-json.sh   (update marketplace.json)"
-echo "  2. git add ."
-echo "  3. git commit -m 'feat: add 6 new plugin bundles (pm-gtm, pm-engineering, pm-data, pm-people, pm-design, pm-business)'"
-echo "  4. git push origin main"
-echo "================================================"
@@ -0,0 +1,136 @@
+# Examples: pm-figma Skills
+
+## What this bundle does
+10 Figma skills covering the full design lifecycle for product managers and designers — from planning what to design, through building components and prototypes, to QA before handoff.
+
+---
+
+## figma-component-audit
+
+### Example 1 — Messy legacy library
+
+**You say:**
+> "Audit our Figma component library. We have buttons, inputs, cards, modals, and navigation components but the naming is all over the place and developers keep asking for states we haven't designed."
+
+**Claude produces:**
+
+**Audit Summary**
+
+| Dimension | Status | Score |
+|---|---|---|
+| Naming consistency | 🔴 Poor | 3/10 |
+| Component coverage | 🟡 Partial | 6/10 |
+| Variant completeness | 🔴 Poor | 4/10 |
+| Overall health | 🟡 Partial | 5/10 |
+
+**Issue: Mixed capitalisation conventions**
+- What's happening: `button-primary`, `Button/Primary`, `btn_primary` all exist in the same library
+- Fix: Adopt PascalCase for components (`Button`), lowercase slash-separated for variants (`type/primary`, `size/large`, `state/default`)
+- Before: `btn_primary_large_hover` → After: `Button` with variants `type/primary`, `size/large`, `state/hover`
+
+**Missing states developers are asking for:**
+| Component | Missing | Priority |
+|---|---|---|
+| Button | Active/pressed state | 🔴 High |
+| Input | Error state with helper text | 🔴 High |
+| Card | Skeleton loading state | 🟡 Medium |
+
+---
+
+## figma-design-brief
+
+### Example 1 — PRD to design brief
+
+**You say:**
+> "Write a design brief for our new notification preferences feature. Users need to control which emails and push notifications they receive. Platform is iOS and Android. We need design ready in 2 weeks."
+
+**Claude produces:**
+
+**Feature:** Notification Preferences
+**Platform:** iOS + Android | **Design due:** [2 weeks from today] | **Dev handoff:** [3 weeks]
+
+**The goal:** Users can control their notification preferences without contacting support.
+
+**Success looks like:** >80% of users who visit settings can update their preferences without a support ticket.
+
+**Flows to design:**
+1. Entry from Settings > Notifications
+2. Toggle individual notification types on/off
+3. Save preferences with confirmation
+4. Error state if save fails
+
+**Missing from current brief — open questions:**
+- [ ] Are email and push controlled separately or together? (PM to confirm)
+- [ ] What's the default state for new users? (PM to confirm)
+
+---
+
+## figma-design-qa
+
+### Example 1 — Pre-handoff check
+
+**You say:**
+> "QA the checkout flow design before we hand it off to engineering. Web, using our custom design system, standard 30-minute QA."
+
+**Claude produces:**
+
+**Design QA Report: Checkout Flow**
+**Overall status:** 🟡 Minor fixes needed
+
+**Section 1: File Hygiene**
+- All layers named semantically ✅
+- No unused layers ✅
+- Components from library ❌ — Order summary card is a detached copy
+- Text uses text styles ✅
+- Colours use variables ❌ — Button label in step 3 uses hardcoded #FFFFFF instead of `color.text.on-primary`
+
+**Issues Found:**
+- **Detached card component — 🟡 Fix before handoff**
+  - What: Order summary card (frame "Step 2 / Summary") is not linked to library
+  - Fix: Re-attach to `Card/Summary` library component
+  - Owner: Designer
+
+---
+
+## figma-design-critique-pm
+
+### Example 1 — PM reviewing a dashboard design
+
+**You say:**
+> "Give me a PM critique of our new analytics dashboard design. User goal is to understand their campaign performance at a glance. Business goal is to reduce support tickets about 'why are my numbers down'."
+
+**Claude produces:**
+
+**PM Critique Summary**
+Verdict: 🟡 Mostly on track with one significant gap
+
+"The design successfully surfaces the top-line metrics above the fold and the date range selector is prominent. However, the design currently shows no contextual explanation for metric changes — a user whose conversions dropped 40% last week will still need to contact support because there's nothing in the design helping them understand why."
+
+**Goal Alignment Check:**
+| Goal | Status | Evidence |
+|---|---|---|
+| Understand performance at a glance | ✅ Yes | Top 4 KPIs are above fold, well-contrasted |
+| Reduce "why are my numbers down" tickets | 🟡 Partial | Metrics shown but no context or anomaly explanation |
+
+**PM Feedback:**
+**Missing: Metric change context — 🔴 High impact**
+- Observation: Metric cards show current value and % change vs prior period but no explanation of what drove the change
+- User impact: A user seeing -40% conversions still has no information to act on without contacting support
+- Business impact: Does not address the core support ticket driver — the "why"
+- Evidence basis: Hypothesis (we should validate with support ticket analysis)
+- Question for designer: Is there data available to surface top contributing factors? Even "top declining campaign" would help.
+
+---
+
+## Tips for best results
+
+- For `figma-design-brief`: paste the actual PRD snippet or ticket — the more specific the requirement, the more useful the brief
+- For `figma-design-qa`: describe the platform and design system explicitly — the checklist adapts to iOS vs Android vs Web
+- For `figma-design-critique-pm`: always state the business metric — without it, feedback stays generic
+- For `figma-variant-matrix`: name the component exactly as it will appear in Figma — Claude uses this for layer naming recommendations
+- For `figma-user-flow-planner`: state the starting point and user type — these determine which edge cases are most likely
+
+## Related skills
+- `design-critique` — General UX critique using Gestalt and Nielsen heuristics (pm-design bundle)
+- `ux-research-plan` — Full research plan for user testing (pm-design bundle)
+- `figma-prototype-plan` — Plan what to prototype before building it (this bundle)
@@ -0,0 +1,36 @@
+#!/bin/bash
+
+# =============================================================================
+# create-plugin-json-pm-figma.sh
+# Run from the ROOT of your pm-claude-skills repo.
+# Creates the .claude-plugin/plugin.json for the pm-figma bundle.
+# =============================================================================
+
+set -e
+
+if [ ! -d "$(pwd)/plugins" ]; then
+  echo "ERROR: Run from the root of pm-claude-skills"
+  exit 1
+fi
+
+mkdir -p plugins/pm-figma/.claude-plugin
+
+cat > plugins/pm-figma/.claude-plugin/plugin.json << 'EOF'
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-figma",
+  "version": "1.0.0",
+  "description": "Figma skills for product managers and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter in Figma across the full design lifecycle.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["figma", "design", "product-management", "design-system", "components", "prototype", "handoff", "ux"]
+}
+EOF
+
+echo "✓ plugins/pm-figma/.claude-plugin/plugin.json created"
+echo ""
+echo "Next: run setup-pm-figma.sh then update-marketplace.sh"
@@ -0,0 +1,95 @@
+---
+name: chart-data-extractor
+description: "Extract pixel-level data from an image of a chart or graph and produce a structured data table. Use when asked to extract data from a chart image, transcribe numbers from a graph, digitise a chart, or turn a screenshot of data into a table. Produces a structured table with extracted values, confidence levels, and a reconstructed chart source. Best used with Claude Opus 4.7 or newer for reliable chart data extraction."
+---
+
+# Chart Data Extractor Skill
+
+Extracts data from images of charts and graphs — bar charts, line charts, pie charts, scatter plots, and tables in images — producing a structured data table that can be used in spreadsheets or rebuilt in any charting tool. Built to leverage Opus 4.7 pixel-level image analysis capabilities.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The chart image** (upload a screenshot or image file)
+- **Chart type** (if ambiguous — bar / line / pie / scatter / other)
+- **What matters most** (approximate trends / precise values / specific data points / categorisation)
+- **Known axis values** (optional — if the user knows the max/min values to anchor the extraction)
+
+## Output Structure
+
+### 1. Chart Identification
+
+| Attribute | Value |
+|---|---|
+| Chart type | [Bar / Line / Pie / Scatter / Area / Other] |
+| Chart title (if visible) | [Title text] |
+| X-axis label | [Label + unit] |
+| Y-axis label | [Label + unit] |
+| Number of series | N |
+| Legend categories | [List] |
+| Data period (if time-based) | [Start — End] |
+
+### 2. Extracted Data Table
+
+| [X axis] | [Series 1] | [Series 2] | ... |
+|---|---|---|---|
+| [Value] | [Value] | [Value] | |
+
+### 3. Confidence Levels
+
+For each data point or series, flag confidence:
+
+- **High confidence:** data points where the value is clearly readable against gridlines or labels
+- **Medium confidence:** data points where the value is interpolated between gridlines
+- **Low confidence:** data points where the value is ambiguous or overlaps with other elements
+
+Low-confidence points should be explicitly listed — not silently included in the main table.
+
+### 4. Notable Observations
+
+Observations that the data itself reveals:
+- Peak value: [Value, when, in which series]
+- Lowest value: [Value, when, in which series]
+- Largest delta between series: [Details]
+- Any anomalies or outliers visible in the chart
+
+### 5. Reconstructed Source
+
+CSV format for direct use:
+
+```csv
+[x_axis],[series_1],[series_2]
+[value],[value],[value]
+```
+
+### 6. Assumptions and Caveats
+
+- Grid resolution: [How precisely values could be read — e.g. "Y-axis has major gridlines every 10 units, minor every 2"]
+- Interpolation used: [Any values that required estimating between gridlines]
+- Unclear data: [Anything in the chart that could not be read reliably]
+- Axis scale: [Linear/logarithmic/etc — note if not obvious]
+
+### 7. Follow-up Options
+
+Ask the user which of these they want:
+- Rebuild the chart in a specified format (Excel formula, Python matplotlib, D3, etc.)
+- Produce a narrative description of what the chart shows
+- Compare this data against another chart or source
+- Flag potentially misleading visual choices in the original (truncated axes, misleading scales, etc.)
+
+## Quality Checks
+- [ ] Every extracted number specifies which series it belongs to
+- [ ] Confidence levels are explicit for ambiguous points
+- [ ] Low-confidence values are flagged separately, not silently included
+- [ ] Assumptions about axis scale and interpolation are stated
+- [ ] CSV output is clean and directly usable
+
+## Example Trigger Phrases
+- "Extract the data from this chart"
+- "Transcribe the numbers in this graph"
+- "Turn this chart image into a spreadsheet"
+- "Digitise this chart so I can rebuild it"
+- "What are the exact values in this bar chart?"
+
+## Why This Works Better on Opus 4.7
+Earlier models struggled with pixel-level data transcription from charts, often hallucinating values or misreading gridline positions. Opus 4.7 uses a higher image resolution (2576px vs 1568px) with coordinates mapping 1:1 to pixels, making chart data extraction reliable for practical use.
@@ -0,0 +1,93 @@
+---
+name: pptx-slide-auditor
+description: "Audit a PowerPoint presentation for layout issues, text overflow, visual hierarchy problems, and consistency gaps. Use when asked to review a slide deck, check a presentation before a meeting, audit slides for layout problems, or QA a deck before sharing. Produces a slide-by-slide report with issues ranked by severity and specific fixes. Best used with Claude Opus 4.7 or newer for reliable slide-level vision analysis."
+---
+
+# PPTX Slide Auditor Skill
+
+Runs a systematic visual and structural audit of a PowerPoint presentation — identifying layout issues, text overflow, inconsistent styling, weak visual hierarchy, and slides that will cause problems in a presentation setting. Built to leverage Opus 4.7 vision improvements for pixel-level layout analysis.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The deck** (upload the .pptx file or individual slide screenshots)
+- **Audience** (internal team / executive / external client / conference / investor)
+- **Presentation mode** (presented live / sent to read / shared async on video)
+- **Areas of concern** (optional — e.g. "I think slide 12 is overcrowded")
+
+## Output Structure
+
+### 1. Deck Overview
+| Metric | Result |
+|---|---|
+| Total slides | N |
+| Overall status | Ready / Minor fixes needed / Major revisions required |
+| Readability score | /10 |
+| Visual consistency score | /10 |
+| Most common issue | [Pattern observed across multiple slides] |
+
+### 2. Slide-by-Slide Audit
+
+For each slide with issues:
+
+**Slide N: [Slide title]**
+- Status: Ready / Fix before sending / Major revision
+- Issues found:
+  - [Specific issue with exact location — e.g. "Body text extends beyond the text frame on the right side"]
+  - [Issue 2]
+- Suggested fix: [Specific action — move element, reduce text, resize]
+
+Slides with no issues: just list the slide numbers. Do not write anything else about them.
+
+### 3. Pattern Issues Across the Deck
+
+Issues that repeat across multiple slides:
+
+**[Pattern title — e.g. "Inconsistent body text size"]**
+- Slides affected: [list]
+- Root cause: [master slide issue / manual overrides / mixed templates]
+- Fix: [Single action to resolve across all affected slides]
+
+### 4. Visual Hierarchy Check
+
+| Dimension | Status | Notes |
+|---|---|---|
+| Title consistency (size, font, colour) | Pass / Fail | |
+| Body text readability at presentation distance | Pass / Fail | |
+| Image placement alignment | Pass / Fail | |
+| Whitespace and breathing room | Pass / Fail | |
+| Data visualisation clarity | Pass / Fail / N/A | |
+
+### 5. Audience-Specific Flags
+
+Based on the stated audience:
+
+- **Executive audience:** flag slides with too much text, complex tables, or unclear bottom-line messages
+- **External client:** flag slides with internal jargon, unfinished placeholder text, or confidentiality concerns
+- **Live presentation:** flag slides that will be hard to read from the back of a room
+- **Async/video:** flag slides that assume a presenter voiceover
+
+### 6. Prioritised Fix List
+
+| # | Fix | Slide | Effort | Impact |
+|---|---|---|---|---|
+| 1 | [Specific fix] | Slide N | Low/Med/High | High |
+
+Order by: fixes before handoff (critical) > consistency fixes (high) > polish (medium).
+
+## Quality Checks
+- [ ] Every issue references a specific slide number and location on the slide
+- [ ] Pattern issues are identified separately from slide-specific issues
+- [ ] Fix list is ordered by impact, not by slide order
+- [ ] Audience-appropriate concerns flagged explicitly
+- [ ] Slides without issues are listed briefly, not ignored
+
+## Example Trigger Phrases
+- "Audit this slide deck before my board meeting"
+- "Review this PowerPoint for layout issues"
+- "Check this presentation for consistency problems"
+- "QA my deck before I send it to the client"
+- "What is wrong with slide 7 in this deck?"
+
+## Why This Works Better on Opus 4.7
+Earlier models struggled with precise spatial analysis of slide layouts — they would hallucinate issues or miss obvious overflow problems. Opus 4.7 vision improvements mean coordinates map 1:1 to pixels, making slide-level issue detection reliable without manual screenshot annotation.
@@ -1,114 +1,107 @@
 ---
 name: code-review-checklist
-description: "Generate a tailored code review checklist for any PR, language, or risk level. Use when asked to create a code review checklist, review guidelines, PR standards, or quality gates for a codebase. Produces a structured, prioritised checklist adapted to the specific language, PR type, and risk level."
+description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation. Optimised for Opus 4.7 and newer models."
 ---

 # Code Review Checklist Skill

-This skill generates a structured, prioritised code review checklist tailored to a specific PR, language, and risk level. It helps reviewers be thorough without being bureaucratic.
+Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.

 ## Required Inputs

 Ask the user for these if not provided:
- **Programming language(s)** (e.g. Python, TypeScript, Go, Java)
- **PR type** (new feature / bug fix / refactor / performance improvement / security patch / infrastructure change)
- **Risk level** (Low: internal tooling, Low traffic / Medium: user-facing feature / High: payment, auth, data pipeline, public API)
- **Team context** (optional: team size, seniority mix, any known recurring issues)
+- **Language and framework** (e.g. TypeScript + React / Python + FastAPI / Go)
+- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
+- **Risk level** (low / medium / high / critical)
+- **PR description** (paste the description or link to the PR)
+- **Author context** (new starter / experienced / external contributor)

 ## Output Structure

-### 1. Checklist Header
+### 1. Review Summary
+**PR:** [Title or reference]
+**Scope assessment:** [Small / Medium / Large / Too large — should be split]
+**Recommended review depth:** [Skim / Standard / Deep dive]
+**Estimated review time:** [Minutes]

-**PR:** [Title if provided]
-**Language:** [Language]
-**Type:** [PR Type]
-**Risk Level:** [Low / Medium / High]
-**Estimated review depth:** [Quick scan ~15 min / Standard ~30 min / Deep review ~60 min+]
+### 2. Correctness Checks

---
+Language-specific correctness checks — choose based on the language stated:

-### 2. The Checklist
+**For TypeScript/JavaScript:**
+- Type definitions match actual usage
+- No implicit `any` in non-test code
+- Async/await used consistently; no unhandled promises
+- Null/undefined handling is explicit

-Organise into sections. Mark each item with a priority indicator:
- 🔴 **MUST** — Blocking. PR should not merge without this.
- 🟡 **SHOULD** — Important. Address before merge unless there's a good reason not to.
- 🟢 **CONSIDER** — Nice to have. Worth a comment but not blocking.
+**For Python:**
+- Type hints present on public functions
+- Exception handling is specific (no bare except)
+- Resources are closed (context managers, with blocks)

-#### Section A: Correctness
- 🔴 Does the code do what the ticket/requirement describes?
- 🔴 Are edge cases handled? (nulls, empty arrays, zero values, max values)
- 🔴 Are error states handled and surfaced appropriately?
- 🟡 Does the happy path have adequate test coverage?
- 🟡 Are failure paths tested?
+**For Go:**
+- Errors are handled or explicitly ignored with a comment
+- Context propagation is correct
+- Goroutine lifetimes are bounded

-#### Section B: Security (scale with risk level — expand for High risk PRs)
- 🔴 [High risk only] Is user input sanitised before use in queries or commands?
- 🔴 [High risk only] Are auth/permission checks in place?
- 🟡 Are secrets/credentials committed anywhere? (check .env handling)
- 🟡 Are third-party dependencies known-safe versions?
+[Include only the section matching the stated language]

-#### Section C: Performance
- 🟡 Are there N+1 query patterns in database calls?
- 🟡 Is there unnecessary work inside loops?
- 🟢 Are database queries indexed appropriately?
- 🟢 Is caching considered where appropriate?
+### 3. Change-Type-Specific Checks

-#### Section D: Readability & Maintainability
- 🟡 Are function and variable names clear without needing a comment to explain them?
- 🟡 Are complex logic blocks explained with inline comments?
- 🟢 Is the code consistent with existing patterns in the codebase?
- 🟢 Are there any magic numbers that should be named constants?
+**For bug fixes:**
+- A test exists that would have caught this bug
+- The fix addresses root cause, not symptom
+- Related code paths checked for the same issue

-#### Section E: Language-Specific Checks
-[Populate this section based on the specified language. Examples below:]
+**For features:**
+- Acceptance criteria met
+- Edge cases handled (empty, large, concurrent)
+- Error paths tested, not just happy path
+- Telemetry/logging added for debugging

-**Python:**
- 🟡 Are type hints used on function signatures?
- 🟡 Are exceptions caught specifically (not bare `except:`)?
- 🟢 Does it follow PEP 8 (or the team's linter config)?
+**For refactors:**
+- Behaviour unchanged (tests still pass)
+- No scope creep — refactor only
+- Complexity reduced, not just moved

-**TypeScript/JavaScript:**
- 🔴 Are there any `any` types that should be properly typed?
- 🟡 Are async/await patterns used consistently (no mixed Promise.then chains)?
- 🟢 Are there unnecessary re-renders in React components?
+**For dependency upgrades:**
+- Breaking changes reviewed
+- Security advisories checked
+- License compatibility verified

-**Go:**
- 🔴 Are errors checked (not ignored with `_`)?
- 🟡 Are goroutines properly managed to prevent leaks?
- 🟢 Are exported functions documented?
+[Include only the section matching the stated change type]

-#### Section F: PR Hygiene
- 🟡 Is the PR a reasonable size? (>500 lines diff suggests it should be split)
- 🟡 Does the PR description explain *why*, not just *what*?
- 🟢 Are there linked tickets or context in the PR description?
- 🟢 Are migration scripts or deployment notes included if needed?
+### 4. Risk-Appropriate Checks

---
+**Low risk:** basic correctness, style conventions, test coverage
+**Medium risk:** above + rollback plan, monitoring updates, performance considerations
+**High risk:** above + security implications, data migration safety, feature flag/gradual rollout
+**Critical risk:** above + staging validation plan, incident response plan, post-deploy verification checklist

-### 3. Risk-Specific Additions
+### 5. Testing Adequacy
+- Unit tests cover new logic
+- Integration tests cover the contract changes
+- Edge cases tested
+- Failure modes tested
+- Performance tests if performance-sensitive

-For **High risk** PRs, always add:
- 🔴 Has this been tested in a staging environment?
- 🔴 Is there a rollback plan?
- 🔴 Has a second reviewer been assigned?
+### 6. Review Decision Framework

-For **Infrastructure / DB changes**, always add:
- 🔴 Are migrations backward-compatible?
- 🔴 Has the migration been tested against production data volume?
+**Approve if:** [2-3 specific conditions based on this PR]
+**Request changes if:** [Specific blockers]
+**Comment (non-blocking) if:** [Items worth discussing but not blocking merge]

---
+### 7. Common Pitfalls for This Change Type
+Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.

 ## Quality Checks
-
- [ ] Checklist is tailored to the specified language (not generic)
- [ ] Risk level is reflected in the MUST vs SHOULD balance
- [ ] Language-specific section covers the most common issues for that language
- [ ] PR hygiene section is always present
- [ ] High-risk additions are included when risk level = High
+- [ ] Checklist is tailored to the stated language (not generic)
+- [ ] Change-type-specific section is included
+- [ ] Risk-appropriate depth matches stated risk level
+- [ ] Decision framework is explicit

 ## Example Trigger Phrases
-
- "Generate a code review checklist for a Python bug fix PR"
- "Give me a review checklist for a high-risk TypeScript auth change"
- "What should I check in this Go PR?"
- "Create PR review standards for our team"
+- "Generate a code review checklist for [PR description]"
+- "What should I check in this pull request?"
+- "Give me a code review checklist for a [language] [change type]"
+- "Review checklist for a high-risk PR in [language]"
@@ -0,0 +1,121 @@
+---
+name: docx-tracked-changes
+description: "Produce properly-formatted tracked changes for a Word document. Use when asked to redline a document, suggest edits to a contract or document, create tracked changes for review, or mark up a document with proposed revisions. Produces a complete redline with insertions, deletions, and margin comments that can be applied to the source document. Best used with Claude Opus 4.7 or newer for reliable tracked changes handling."
+---
+
+# Word Doc Tracked Changes Skill
+
+Produces properly-structured tracked changes for a Word document — insertions, deletions, replacements, and margin comments formatted so they can be applied directly to the source document. Built to leverage Opus 4.7 improvements in .docx redlining and tracked changes generation.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The document** (paste the text or upload the .docx)
+- **Review type** (legal review / copy edit / substantive rewrite / compliance check / plain English rewrite)
+- **Review scope** (full document / specific sections / specific clause type)
+- **Reviewer role** (author / manager / legal counsel / subject matter expert)
+
+## Output Structure
+
+### 1. Redline Summary
+
+**Document:** [Name or identifier]
+**Review type:** [As stated]
+**Reviewer:** [Role]
+**Total changes:** [Insertions: N / Deletions: N / Comments: N]
+**Overall assessment:** [1-2 sentences — is this document close to final, or does it need substantial revision?]
+
+### 2. Top-Level Changes
+
+Changes that affect the meaning or structure of the document:
+
+**Change N — [Section or paragraph reference]**
+- Original: "[Exact original text]"
+- Suggested: "[Proposed new text]"
+- Reason: [Why this change — substantive/legal/clarity]
+
+### 3. Line-by-Line Tracked Changes
+
+For each paragraph that needs changes, format as:
+
+**[Paragraph reference — e.g. "Section 3, Paragraph 2"]**
+
+Original:
+> [Exact original paragraph]
+
+Tracked changes:
+> [Same paragraph with deletions marked as ~~strikethrough~~ and insertions marked as **bold**]
+
+Clean version:
+> [Final clean text after applying changes]
+
+### 4. Margin Comments
+
+Comments that flag issues without proposing a specific wording change:
+
+**Comment N — [Location]**
+"[Comment text — written as the reviewer would write it. Direct, specific, actionable.]"
+
+Comments are for things like:
+- "This clause conflicts with Section 7 — please reconcile"
+- "Missing definition of [term] used throughout"
+- "Confirm figure with finance team"
+
+### 5. Stylistic Edits
+
+Line-level stylistic changes (if scope includes copy editing):
+
+| Location | Before | After | Reason |
+|---|---|---|---|
+| Para 3 | [Text] | [Text] | [Readability/grammar/consistency] |
+
+### 6. Pattern Flags
+
+Issues that repeat across the document:
+
+**[Pattern — e.g. "Passive voice overuse"]**
+- Instances: [count]
+- Examples: [2-3 specific locations]
+- Suggested approach: [How to address]
+
+### 7. Review Completeness
+
+| Review dimension | Covered |
+|---|---|
+| Grammar and syntax | Yes / No |
+| Clarity and readability | Yes / No |
+| Substantive accuracy | Yes / No / N/A |
+| Compliance/legal check | Yes / No / N/A |
+| Consistency with referenced documents | Yes / No / N/A |
+
+### 8. How to Apply These Changes
+
+Instructions for applying the redline:
+
+**In Microsoft Word:**
+1. Enable Track Changes (Review tab → Track Changes)
+2. Apply the changes from Section 3 in order
+3. Add comments from Section 4 using Review → New Comment
+4. Send the redlined document back to the reviewer
+
+**In Google Docs:**
+1. Switch to Suggesting mode (top right pencil icon)
+2. Apply the changes from Section 3
+3. Add comments using the comment button in the margin
+
+## Quality Checks
+- [ ] Every tracked change has the original text preserved exactly
+- [ ] Substantive changes are separated from stylistic changes
+- [ ] Comments are written as the reviewer would write them, not meta-commentary
+- [ ] Pattern issues identified separately from individual changes
+- [ ] Application instructions match the target platform
+
+## Example Trigger Phrases
+- "Redline this contract"
+- "Create tracked changes for this document"
+- "Mark up this document with proposed edits"
+- "Review this and suggest changes in tracked changes format"
+- "Give me a redline version of this draft"
+
+## Why This Works Better on Opus 4.7
+Tracked changes require the model to preserve source text exactly while suggesting alternatives — earlier models would paraphrase the original or lose track of which text was original vs suggested. Opus 4.7 improvements specifically target this workflow.
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-figma",
+  "version": "1.0.0",
+  "description": "Figma skills for PMs and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter across the full Figma design lifecycle.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["figma", "design", "product-management", "design-system", "components", "prototype", "handoff", "ux"]
+}
@@ -0,0 +1,64 @@
+---
+name: figma-annotation-guide
+description: "Generate structured developer handoff annotations for a Figma screen or component. Use when asked to write Figma annotations, create dev handoff notes, document a Figma design for developers, or write specs for a screen. Produces a complete annotation set covering interactions, states, spacing, accessibility, and edge cases."
+---
+
+# Figma Annotation Guide Skill
+
+Produces a complete set of developer handoff annotations for a Figma screen or component — the notes that turn a visual design into a buildable spec.
+
+## Required Inputs
+
+- **Screen or component description** (describe or summarise what was designed)
+- **Platform** (iOS / Android / Web / React Native)
+- **Interaction type** (static / interactive / animated / form)
+- **Developer audience** (mobile / frontend / full-stack)
+
+## Output Structure
+
+### 1. Screen/Component Overview
+Name, purpose, entry points, exit points.
+
+### 2. Interaction Annotations
+
+**[Element name]**
+- Default state: [Visual description]
+- On tap/click: [Exact action — API call, state change, navigation]
+- Loading state: [Description]
+- Success state: [What happens after]
+- Error state: [What error looks like and user options]
+- Disabled condition: [When and why]
+
+### 3. State Inventory
+
+| Element | States Required |
+|---|---|
+| [Element] | Default, Hover, Active, Disabled, Loading, Error, Empty |
+
+Flag missing designs: "Warning: Error state not designed — needed before build"
+
+### 4. Spacing and Layout Notes
+Fixed vs fluid elements, scroll behaviour, breakpoints, safe areas.
+
+### 5. Content and Copy Rules
+Character limits, dynamic vs static content, truncation rules, empty states.
+
+### 6. Accessibility Annotations
+Touch targets, screen reader labels, focus order, colour contrast, motion preferences.
+
+### 7. Edge Cases and Developer Questions
+- [ ] [Unresolved question for developer to flag]
+
+## Quality Checks
+- [ ] Every interactive element has all states defined
+- [ ] State inventory flags missing designs
+- [ ] Accessibility covers touch targets and screen reader labels
+- [ ] Empty states specified
+- [ ] Edge cases listed as actionable questions
+
+## Example Trigger Phrases
+- "Write dev annotations for this Figma screen"
+- "Create developer handoff notes for [screen/component]"
+- "Document this design for the engineering team"
+- "Write the Figma spec for [feature]"
+- "What should I annotate before handing off this design?"
@@ -0,0 +1,74 @@
+---
+name: figma-component-audit
+description: "Audit a Figma component library for consistency, coverage gaps, and naming issues. Use when asked to audit components, review a design system, check component consistency, identify missing components, or assess Figma library health. Produces a structured audit report with issues prioritised by impact, naming recommendations, and a fix plan."
+---
+
+# Figma Component Audit Skill
+
+Produces a structured audit of a Figma component library — identifying inconsistencies, naming problems, coverage gaps, and prioritised recommendations.
+
+## Required Inputs
+
+- **Component list or description** (paste component names or describe what exists)
+- **Product type** (mobile app / web app / desktop / multi-platform)
+- **Design system maturity** (new / growing / mature / legacy)
+- **Primary concern** (optional)
+
+## Output Structure
+
+### 1. Audit Summary
+
+| Dimension | Status | Score |
+|---|---|---|
+| Naming consistency | Red/Amber/Green | /10 |
+| Component coverage | | /10 |
+| Variant completeness | | /10 |
+| Documentation | | /10 |
+| Overall health | | /10 |
+
+**Verdict:** What is the state of this library and the single most important thing to fix?
+
+### 2. Naming Issues
+
+For each problem:
+**Issue: [Problem type]**
+- What is happening: [Specific examples]
+- Why it matters: [Impact on designers and developers]
+- Fix: [Exact naming convention to adopt]
+- Examples: Before / After
+
+Naming convention to enforce:
+- Components: PascalCase (NavigationBar)
+- Variants: Lowercase with slashes (size/large, state/hover)
+- Pages: All caps (COMPONENTS, FOUNDATIONS)
+
+### 3. Coverage Gaps
+
+| Missing Component | Priority | Why Needed |
+|---|---|---|
+| [Component] | High/Medium/Low | [Use case] |
+
+### 4. Variant Completeness Check
+
+| Component | Default | Hover | Active | Disabled | Error | Missing |
+|---|---|---|---|---|---|---|
+| [Button] | Yes | Yes | No | Yes | No | Active, Error |
+
+### 5. Prioritised Fix Plan
+
+| # | Fix | Effort | Impact | Do First? |
+|---|---|---|---|---|
+| 1 | [Fix] | Low/Med/High | High | Yes |
+
+## Quality Checks
+- [ ] Naming recommendations have before/after examples
+- [ ] Coverage gaps are relevant to the product type
+- [ ] Fix plan is ordered by impact-to-effort ratio
+- [ ] Variant completeness covers all interactive states
+
+## Example Trigger Phrases
+- "Audit my Figma component library"
+- "Review our design system for consistency issues"
+- "What components are we missing in our Figma library?"
+- "Our component naming is a mess — help me fix it"
+- "Do a health check on our Figma components"
@@ -0,0 +1,68 @@
+---
+name: figma-design-brief
+description: "Write a structured design brief for a Figma design task from a product requirement or feature request. Use when asked to write a design brief, create a design spec for Figma, turn a PRD into design requirements, or brief a designer on what to build in Figma. Produces a brief with goals, scope, user flows, components needed, constraints, and success criteria."
+---
+
+# Figma Design Brief Skill
+
+Converts a product requirement or feature request into a structured design brief — everything a designer needs to open Figma and start building confidently.
+
+## Required Inputs
+
+- **Feature or requirement** (paste PRD snippet, ticket, or describe the feature)
+- **User goal** (what is the user trying to accomplish?)
+- **Platform** (iOS / Android / Web / Responsive / All)
+- **Existing components available** (optional)
+- **Timeline** (when does design need to be ready?)
+
+## Output Structure
+
+### 1. Brief Header
+Feature, PM, Designer, Platform, Design due, Dev handoff dates.
+
+### 2. What We Are Designing and Why
+- **The goal:** [One sentence — user problem being solved]
+- **Context:** [2-3 sentences. Why now? What triggers this?]
+- **Success looks like:** [Specific observable outcome]
+
+### 3. User Flows to Design
+
+**Flow N: [Flow name]**
+- Entry point: [Where user starts]
+- Steps: [Numbered key steps]
+- Exit point: [Where flow ends]
+- Edge cases: [empty state, error state, loading state]
+
+### 4. Screens Required
+
+| Screen | New / Update | Notes |
+|---|---|---|
+| [Screen] | New | [Key requirement] |
+
+### 5. Components Needed
+
+| Component | In library? | Action |
+|---|---|---|
+| [Component] | Yes/No/Needs variant | Use/Create/Extend |
+
+### 6. Constraints and Requirements
+- Must haves: [Non-negotiable constraints]
+- Must avoid: [Design patterns to not use]
+- Accessibility: [WCAG level, touch target sizes]
+
+### 7. Open Questions
+- [ ] [Question — with owner]
+
+## Quality Checks
+- [ ] Goal is outcome-focused (not "design the feature")
+- [ ] All flows include edge cases
+- [ ] Components table identifies create vs reuse
+- [ ] Constraints include accessibility requirements
+- [ ] Open questions have owners
+
+## Example Trigger Phrases
+- "Write a design brief for [feature]"
+- "Turn this PRD into a Figma design brief"
+- "Brief the designer on what to build for [requirement]"
+- "Create a design spec for [feature] for Figma"
+- "What does the designer need to know to design [feature]?"
@@ -0,0 +1,76 @@
+---
+name: figma-design-critique-pm
+description: "Run a PM-perspective design critique focused on product outcomes, user goals, and business requirements — not aesthetics. Use when asked for a PM design critique, a product review of a design, feedback on a Figma design from a product perspective, or when you want to critique a design without being a designer. Produces structured outcome-based feedback tied to user goals and business metrics."
+---
+
+# Figma Design Critique — PM Perspective Skill
+
+This skill is specifically for product managers critiquing designs — focused on whether the design achieves the user goal and business outcome, not whether it looks good. Different from the general design-critique skill which covers UX aesthetics; this one centres product thinking.
+
+## Required Inputs
+
+- **Design description or screen summary**
+- **User goal** (what is the user trying to accomplish?)
+- **Business goal** (what outcome does the product need?)
+- **Original requirements** (what was this supposed to do?)
+- **Key metric** (what would move if this design works?)
+
+## Output Structure
+
+### 1. PM Critique Summary
+User goal, business goal restated.
+**Verdict:** On track / Mostly on track / Needs rethinking
+
+One-paragraph summary: what works from a product perspective, and the single most important thing to address.
+
+### 2. Goal Alignment Check
+
+| Goal | Design supports it? | Evidence |
+|---|---|---|
+| [User goal] | Yes/Partial/No | [Specific observation] |
+| [Business goal] | Yes/Partial/No | [Observation] |
+| [Key requirement] | Yes/Partial/No | [Observation] |
+
+### 3. PM Feedback (Outcome-Focused)
+
+Every concern must tie to an outcome. "I do not like this layout" is not PM feedback. "This layout puts the primary action below the fold, which will reduce mobile conversion" is PM feedback.
+
+**[Concern] — High/Medium/Low impact**
+- Observation: [Neutral description of what the design does]
+- User impact: [What this means for the user goal]
+- Business impact: [What this means for the metric]
+- Evidence basis: [Research/data/analogous patterns/hypothesis — be honest]
+- Question for designer: [What to explore — not a directive]
+
+### 4. What the Design Does Well
+2-4 specific things working well from a product perspective — with evidence. Not "colours are nice" but "primary CTA is the most prominent element, aligning with conversion goal." Always include this section.
+
+### 5. Questions Before Next Iteration
+
+| Question | Who answers | Why it matters |
+|---|---|---|
+| [Question] | Designer/PM/Eng | [Impact] |
+
+### 6. PM Recommendation
+Approve / Approve with changes (list) / Revise and re-review (one focus area only)
+
+## PM Critique Rules
+- Never reference aesthetics as reason for feedback — only outcomes
+- "I prefer" is not feedback — "users are likely to" is feedback
+- Lead with what is working before what is not
+- Ask questions before giving directives
+- One primary recommendation — not a redesign in bullets
+
+## Quality Checks
+- [ ] Every concern tied to user or business outcome
+- [ ] What is working section is genuine and specific
+- [ ] Questions section included (not just directives)
+- [ ] PM recommendation is explicit
+- [ ] Evidence basis stated honestly
+
+## Example Trigger Phrases
+- "Give me a PM critique of this design"
+- "Review this design from a product perspective"
+- "What product feedback do I have on this Figma design?"
+- "Critique this design without being a designer"
+- "Does this design achieve the user goal?"
@@ -0,0 +1,89 @@
+---
+name: figma-design-qa
+description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
+---
+
+# Figma Design QA Skill
+
+Runs a systematic pre-handoff QA check on a Figma design — catching issues that cause engineering back-and-forth before they become expensive.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature or screen being QA-d** (describe what has been designed)
+- **Platform** (iOS / Android / Web)
+- **Design system** (custom / Material / HIG / None)
+- **Handoff tool** (Figma Inspect / Zeplin / Storybook / Direct link)
+- **QA depth** (quick 15 min / standard 30 min / thorough 60 min)
+
+## Output Structure
+
+QA Report: [Feature] | [Date] | [Platform]
+**Overall status:** Ready / Minor fixes needed / Not ready
+
+### Section 1: File Hygiene
+- All layers named semantically (no "Rectangle 12")
+- No unused/hidden layers in final frames
+- Components from library (not detached copies)
+- All text uses text styles (not manual font settings)
+- All colours use styles or variables (not hex overrides)
+- Frames named to match screen map
+- No leftover prototype wires to wrong frames
+
+### Section 2: Component Usage
+- All buttons use library component
+- All inputs use library component
+- All icons from approved icon library
+- No custom components that should be in library
+- Variants used correctly (right size, state, type)
+
+### Section 3: Content and Copy
+- No placeholder text (Lorem ipsum) in final designs
+- All copy reviewed and approved
+- Realistic content used (not "User Name")
+- Long text edge cases tested
+- Error messages are human-readable
+- Empty states have copy and CTA
+
+### Section 4: States and Coverage
+- Default, Loading, Empty, Error, Success states
+- Interactive elements have hover/active (web)
+- Disabled states designed where applicable
+
+### Section 5: Accessibility
+- All text meets WCAG AA contrast (4.5:1 body, 3:1 large)
+- UI components meet 3:1 contrast against background
+- Touch targets minimum 44x44pt iOS / 48x48dp Android
+- Focus states for keyboard/switch navigation (web)
+- Information not conveyed by colour alone
+- Icons have text labels or accessible names annotated
+
+### Section 6: Handoff Readiness
+- Dev annotations on non-obvious interactions
+- Spacing uses Auto Layout (not absolute positioning)
+- Images/assets exported at correct resolutions
+- Design matches approved requirements
+- Link to prototype included
+
+### Issues Found
+For each fail:
+**[Issue] — Blocking / Fix before handoff / Fix in next iteration**
+- What: [Specific layer/screen/element]
+- Fix: [Exact action needed]
+- Owner: [Designer/PM/Both]
+
+### Handoff Decision
+Status, signed off by, date.
+
+## Quality Checks
+- [ ] All 6 sections completed
+- [ ] Every fail has a specific description and fix action
+- [ ] Blocking issues separated from minor ones
+- [ ] Handoff decision is explicit
+
+## Example Trigger Phrases
+- "QA this Figma design before handoff"
+- "Run a pre-handoff check on [feature] design"
+- "Is this Figma design ready for engineering?"
+- "Do a design QA on [screen/feature]"
+- "What needs fixing before we hand this off?"
@@ -0,0 +1,68 @@
+---
+name: figma-design-review
+description: "Run a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, do a PM design review, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and explicit approval status."
+---
+
+# Figma Design Review Skill
+
+Runs a structured PM design review — checking that a design meets product requirements, covers all user flows, and is ready for engineering. This is a requirements-and-outcomes review, not an aesthetic critique.
+
+## Required Inputs
+
+- **Design description or screen summary**
+- **Original requirements** (PRD snippet, ticket, or acceptance criteria)
+- **User flow being designed**
+- **Review stage** (concept / mid-fidelity / pre-handoff final)
+
+## Output Structure
+
+### 1. Review Header
+Feature, review stage, reviewed by, date.
+**Overall status:** Approved / Approved with changes / Needs revision
+
+### 2. Requirements Coverage Check
+
+| Requirement | Covered? | Notes |
+|---|---|---|
+| [Requirement from PRD] | Yes/No/Partial | [Specific observation] |
+
+Missing coverage summary: [Requirements not addressed — must resolve before approval]
+
+### 3. User Flow Completeness
+
+| Flow step | Designed? | Issues |
+|---|---|---|
+| [Step] | Yes/No/Partial | [Issue] |
+| Error state | Yes/No | |
+| Empty state | Yes/No | |
+| Loading state | Yes/No | |
+
+### 4. PM Concerns
+
+**[Concern] — Blocking / Should fix / Nice to fix**
+- What: [Specific observation]
+- Why it matters: [Business or user impact — not aesthetic preference]
+- Suggested resolution: [What PM wants to see]
+
+### 5. Open Questions
+
+| Question | Owner | Needed by |
+|---|---|---|
+| [Question] | Designer/Eng/PM | [Date] |
+
+### 6. Approval Decision
+Approved / Approved with changes (list) / Needs revision (focus area + next review date)
+
+## Quality Checks
+- [ ] Every requirement assessed
+- [ ] All flow states checked (error, empty, loading)
+- [ ] Concerns are outcome-focused not aesthetic
+- [ ] Open questions have owners
+- [ ] Approval status is explicit
+
+## Example Trigger Phrases
+- "Review this Figma design against the requirements"
+- "Do a PM design review for [feature]"
+- "Check if this design meets the product spec"
+- "Is this design ready to hand off to engineering?"
+- "What is missing from this design before we can build it?"
@@ -0,0 +1,84 @@
+---
+name: figma-prototype-plan
+description: "Plan prototype interactions and flows for user testing in Figma. Use when asked to plan a Figma prototype, set up prototype interactions, define what to prototype for a user test, or prepare a Figma prototype for usability testing. Produces a prototype scope, interaction specification, test task scripts, and Figma setup guide."
+---
+
+# Figma Prototype Plan Skill
+
+Plans what to prototype in Figma and how — scoping to what the user test needs, defining every interaction, and setting up the test scenarios. Prevents over-building and ensures the prototype answers the research question.
+
+## Required Inputs
+
+- **Research question** (what are you trying to learn?)
+- **Feature or flow being prototyped**
+- **Prototype fidelity** (low wireframe / mid functional / high pixel-perfect)
+- **Testing method** (moderated in-person / moderated remote / unmoderated)
+- **Number of test tasks**
+
+## Output Structure
+
+### 1. Prototype Scope
+
+**In scope:** [Flows with real interactions — specific screens listed]
+**Out of scope:** [Screens to show as static — not worth building as interactive]
+**Rationale:** Prototypes should be the minimum needed to test the hypothesis.
+
+### 2. Interaction Specification
+
+**Interaction N: [Description]**
+- Trigger: Tap/Swipe/Hover/Form submit
+- Element: [Figma layer name]
+- Destination: [Figma frame name]
+- Animation: Instant/Dissolve/Push left/Push right/Slide up
+- Timing: [ms]
+- Reset after: Yes/No
+
+### 3. Prototype Flow Diagram
+
+```
+[Start frame]
+  -> Tap "Action"
+[Next frame]
+  -> Tap "Complete" -> [Success frame]
+  -> Tap "Cancel"   -> [Back to start]
+```
+
+### 4. Test Task Scripts
+
+**Task N: [Title]**
+
+Scenario (read to participant):
+"[Realistic scenario giving context without directing the click path]"
+
+Observing:
+- [What to watch for]
+
+Success when: [Specific trigger]
+
+### 5. Figma Setup Guide
+- Starting frame: [Name]
+- Device preview: [Device]
+- Prototype settings: background colour, show device, type
+- Sharing: Can view link, reset process between participants
+
+### 6. Build vs Fake Table
+
+| Element | Build | Fake | Notes |
+|---|---|---|---|
+| Primary CTA flow | Yes | | Core to research |
+| Secondary nav | | Yes | Not being tested |
+| Error state | Yes | | Testing recovery |
+
+## Quality Checks
+- [ ] Scope limited to what the research question requires
+- [ ] Every interaction has a named destination frame
+- [ ] Task scripts are scenario-based (not "click on X")
+- [ ] Success criteria defined for each task
+- [ ] Reset process defined for between participants
+
+## Example Trigger Phrases
+- "Plan the Figma prototype for our user test on [feature]"
+- "What interactions do I need to build for this prototype?"
+- "Help me set up a Figma prototype for [research question]"
+- "Write the test task scripts for our [feature] prototype"
+- "What should I prototype vs leave as static screens?"
@@ -0,0 +1,77 @@
+---
+name: figma-spacing-system
+description: "Design a spacing and layout token system for a Figma design system. Use when asked to create a spacing system, define layout tokens, set up a grid system, build a spacing scale, or establish layout foundations for a Figma file. Produces a complete spacing scale, grid definition, component spacing conventions, and Figma implementation guide."
+---
+
+# Figma Spacing System Skill
+
+Produces a complete spacing and layout token system — the foundation that makes a design system consistent and developer handoff unambiguous.
+
+## Required Inputs
+
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Base unit** (4px / 8px — default to 8px)
+- **Design system name** (for token naming)
+- **Component density** (compact / standard / comfortable)
+- **Grid requirements** (or "derive from platform standard")
+
+## Output Structure
+
+### 1. Base Unit
+[4px or 8px] with rationale. All values must be multiples.
+
+### 2. Spacing Scale
+
+| Token | Value | Use case |
+|---|---|---|
+| spacing.none | 0px | Removing space intentionally |
+| spacing.xs | 4/8px | Icon padding, tight labels |
+| spacing.sm | 8/12px | Internal component padding compact |
+| spacing.md | 12/16px | Internal component padding standard |
+| spacing.lg | 16/24px | Section padding, card internal |
+| spacing.xl | 24/32px | Between components |
+| spacing.2xl | 32/48px | Section separation |
+| spacing.3xl | 48/64px | Page-level breaks |
+| spacing.4xl | 64/96px | Hero sections |
+
+### 3. Layout Grid
+
+Mobile (375px): 4 columns, margin [value], gutter [value]
+Tablet (768px): 8 columns, margin [value], gutter [value]
+Desktop (1440px): 12 columns, margin [value], gutter [value], max content width [value]
+
+### 4. Component Spacing Conventions
+
+| Context | Token | Example |
+|---|---|---|
+| Button horizontal padding | spacing.md | Left/right |
+| Button vertical padding | spacing.sm | Top/bottom |
+| Card internal padding | spacing.lg | All sides |
+| Input padding | spacing.sm vertical, spacing.md horizontal | |
+| Icon gap from label | spacing.xs | |
+| Section gap | spacing.xl | |
+
+### 5. Figma Implementation
+1. Create SPACING page documenting each token visually
+2. Resources > Variables > create Number collection named Spacing
+3. Apply variables to Auto Layout padding/gap values
+4. Share token names with engineers as-is or via Tokens Studio
+
+### 6. Anti-Patterns to Avoid
+- Values not on the scale (13px, 22px) — round to nearest token
+- Absolute pixel values in components instead of tokens
+- Mixing 4px and 8px base units in the same product
+
+## Quality Checks
+- [ ] All token values are multiples of the base unit
+- [ ] Scale covers xs through 4xl
+- [ ] Grid defined for all relevant breakpoints
+- [ ] Component conventions cover common decisions
+- [ ] Figma implementation steps included
+
+## Example Trigger Phrases
+- "Create a spacing system for our Figma design system"
+- "Define our spacing tokens for Figma"
+- "Set up a grid and spacing scale for [product]"
+- "What spacing values should we use in our design system?"
+- "Help me build the layout foundation for our Figma file"
@@ -0,0 +1,76 @@
+---
+name: figma-user-flow-planner
+description: "Plan user flows and screen states for a Figma design before any designing starts. Use when asked to plan a user flow, map out screens for a feature, define screen states, plan a Figma file structure, or work out what needs to be designed before opening Figma. Produces a complete flow map with all screens, states, entry/exit points, and a suggested Figma page structure."
+---
+
+# Figma User Flow Planner Skill
+
+Plans what needs to be designed before a pixel is touched — mapping all screens, states, entry points, and edge cases so designers do not discover missing states mid-build.
+
+## Required Inputs
+
+- **Feature or task being designed**
+- **User type** (who performs this flow?)
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Starting point** (where does the user begin?)
+- **Known edge cases** (optional)
+
+## Output Structure
+
+### 1. Flow Overview
+Feature, user, goal, entry points, success exit, failure exits.
+
+### 2. Screen Map
+
+| # | Screen name | Type | Triggered by | Notes |
+|---|---|---|---|---|
+| 1 | [Screen] | New/Modal/Drawer/Toast | [What triggers] | [Considerations] |
+
+Screen types to cover: entry, happy path, loading, success, error (network/validation/permission), empty, first-time/onboarding, edge cases.
+
+### 3. State Matrix
+
+**[Screen name]**
+
+| State | Trigger | Visual change | Action available |
+|---|---|---|---|
+| Default | Page load | [Description] | [What user can do] |
+| Loading | User taps action | Skeleton/spinner | None |
+| Error | API failure | Error message | Retry/Go back |
+| Empty | No data | Empty state | [CTA] |
+
+### 4. Decision Points
+
+**Decision: [Name]**
+- If yes: [Screen N]
+- If no: [Screen X]
+
+### 5. Suggested Figma File Structure
+
+```
+Feature name/
+- Cover
+- Flow Map
+- Happy Path
+- Error States
+- Empty States
+- Edge Cases
+- Handoff
+```
+
+### 6. What Not to Design Yet
+[Explicit out-of-scope items — prevents scope creep]
+
+## Quality Checks
+- [ ] All three state types covered: loading, error, empty
+- [ ] All decision points mapped with both branches
+- [ ] Entry points include all realistic user paths
+- [ ] Out-of-scope section is explicit
+- [ ] Figma file structure matches screen map
+
+## Example Trigger Phrases
+- "Plan the user flow for [feature] in Figma"
+- "What screens do I need to design for [feature]?"
+- "Map out the states for [feature] before we start designing"
+- "Help me structure my Figma file for [feature]"
+- "What do we need to design before handing this to the developer?"
@@ -0,0 +1,78 @@
+---
+name: figma-variant-matrix
+description: "Define component variants and states systematically for Figma. Use when asked to plan component variants, define states for a component, set up a Figma variant matrix, or work out what properties a component needs before building it. Produces a complete variant matrix with all properties, values, and combinations needed."
+---
+
+# Figma Variant Matrix Skill
+
+Defines all variants, properties, and states a component needs before building it in Figma — preventing missing variants discovered after the component is already used across 40 screens.
+
+## Required Inputs
+
+- **Component name** (Button, Card, Input, Badge, Navigation item, etc.)
+- **Component purpose** (what does it do, where is it used?)
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Design system context** (standalone / part of existing system)
+
+## Output Structure
+
+### 1. Component Overview
+Name, category (Interactive/Display/Layout/Form/Navigation/Feedback), used in contexts.
+
+### 2. Variant Properties
+
+| Property | Values | Notes |
+|---|---|---|
+| Type | Primary, Secondary, Tertiary, Destructive | |
+| Size | Large, Medium, Small | |
+| State | Default, Hover, Active, Disabled, Loading | |
+| Icon | None, Leading, Trailing, Only | |
+
+Total combinations: [N]. Flag if over 50 — consider splitting into multiple components.
+
+### 3. State Definitions
+
+For each state, list only what changes from Default:
+- Default: [Full visual spec]
+- Hover (web): [Delta from default]
+- Active/Pressed: [Delta]
+- Disabled: [Delta — use layer-level properties, not opacity on whole component]
+- Loading: [What replaces label, interactive during loading?]
+- Error (forms): [Border colour, helper text, icon changes]
+
+### 4. Anatomy Breakdown
+
+| Layer name | Purpose | Required? | Notes |
+|---|---|---|---|
+| container | Background and bounds | Yes | |
+| label | Text | Conditional | Hide when icon-only |
+| icon-leading | Leading icon slot | No | |
+
+### 5. Token Mapping
+
+| Property | Token | Fallback |
+|---|---|---|
+| Background default | color.brand.primary | #hex |
+| Border radius | radius.medium | 8px |
+
+### 6. Build Order
+1. Default state, most common variant
+2. Convert to component, add properties
+3. Size variants
+4. State variants
+5. Type variants
+6. Icon slot variants last
+
+## Quality Checks
+- [ ] All interactive states defined
+- [ ] Total variant count calculated, flagged if over 50
+- [ ] Every layer named semantically
+- [ ] Token mapping covers all visual properties
+- [ ] Disabled state uses layer-level properties not opacity
+
+## Example Trigger Phrases
+- "Define the variants for a [component] in Figma"
+- "What states does my [component] need?"
+- "Help me plan the variant matrix for [component]"
+- "Set up the Figma properties for a [button/card/input]"
+- "What are all the combinations I need for my [component]?"
@@ -1,54 +1,107 @@
 ---
 name: compliance-checklist
-description: "Generate a compliance checklist for any regulation, standard, or policy. Use when asked to create a compliance checklist, regulatory review, audit checklist, or policy adherence review. Covers GDPR, ISO 27001, FCA, HIPAA, SOC 2, and other frameworks. Produces a prioritised checklist with pass/fail assessment and remediation actions."
+description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
 ---

 # Compliance Checklist Skill

-Generates a structured compliance checklist for any regulatory framework with a prioritised gap analysis and remediation actions.
+Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
+
+ALWAYS include this disclaimer at the start of every response:
+"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."

 ## Required Inputs
- **Framework or regulation** (e.g. GDPR, HIPAA, SOC 2, ISO 27001, FCA Consumer Duty, PCI DSS)
- **Organisation type** (e.g. SaaS company, financial services, NHS trust, law firm)
- **Scope** (e.g. data handling, customer onboarding, IT security, HR processes)
- **Known gaps or concerns** (optional)
+
+Ask the user for these if not provided:
+- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
+- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
+- **Organisation size** (startup / scaleup / mid-market / enterprise)
+- **Current maturity** (no compliance programme / some controls / formal programme)
+- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)

 ## Output Structure

 ### 1. Framework Overview
- **Regulation/Standard:** [Name and version]
- **Enforcement body:** [Regulator]
- **Overall compliance status:** Red Gaps / Amber Partial / Green Compliant

-### 2. Compliance Checklist
+**Framework:** [Name with version]
+**Applicable because:** [One sentence — why this framework applies to this organisation]
+**Typical timeline to readiness:** [From current maturity to certified/compliant]
+**Key stakeholders needed:** [Roles that must be involved]

-| # | Requirement | Status | Priority | Action Required |
+### 2. Scope Definition
+
+What is in scope for this checklist:
+- [Specific systems / processes / data types]
+
+What is NOT in scope (explicit exclusions):
+- [Specific exclusions]
+
+### 3. Control Categories
+
+For each category relevant to the framework:
+
+**[Category — e.g. "Access Control"]**
+
+| Control | Current State | Gap | Priority | Effort |
 |---|---|---|---|---|
-| 1 | [Plain English requirement] | Met / Gap / Partial / Unknown | Critical / High / Low | [Specific action] |
+| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |

-Priority definitions:
- Critical: Regulatory breach risk. Remediate immediately.
- High: Significant gap. Address within 30 days.
- Low: Best practice. Address in next review cycle.
+### 4. Gap Analysis Summary

-### 3. Critical Gaps Summary
-List only Critical items with: what is missing, regulatory requirement breached, recommended remediation and owner.
+| Priority | Count | Examples |
+|---|---|---|
+| Critical gaps (block certification) | N | [Top 3] |
+| High priority gaps | N | |
+| Medium priority gaps | N | |
+| Quick wins | N | |

-### 4. Recommended Remediation Plan
+### 5. Quick Wins

-| Action | Owner | Timeline | Effort |
-|---|---|---|---|
-| [Specific action] | [Team/role] | [Timeframe] | Low/Med/High |
+Controls that can be implemented in under 2 weeks with minimal resources:

-### 5. Documentation Gaps
-Policies, records, or evidence needed to demonstrate compliance.
+1. **[Control]** — [Specific action] — [Owner] — [Days to complete]

---
+### 6. Evidence Requirements

-WARNING: This checklist is a starting point based on publicly available guidance. It does not constitute legal or compliance advice.
+For each control area, what documentation will be needed:
+
+| Control area | Evidence types | Where to source |
+|---|---|---|
+| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
+
+### 7. Implementation Roadmap
+
+Phase 1 (Weeks 1-4): Critical gaps and quick wins
+- [Specific deliverables]
+
+Phase 2 (Weeks 5-12): High-priority gaps
+- [Specific deliverables]
+
+Phase 3 (Weeks 13+): Medium priority and continuous improvement
+- [Specific deliverables]
+
+### 8. Ongoing Maintenance
+
+Once certified/compliant, what needs to continue:
+- [Review frequencies]
+- [Periodic testing requirements]
+- [Annual audit expectations]
+- [Staff training cadence]
+
+### 9. Common Pitfalls for This Framework
+
+2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
+
+## Quality Checks
+- [ ] Disclaimer included at start
+- [ ] Framework-specific controls (not generic)
+- [ ] Priorities align with organisation size and maturity
+- [ ] Quick wins clearly separated from complex implementations
+- [ ] Evidence requirements tied to specific controls

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

 # Code Review Checklist Skill

-This skill generates a structured, prioritised code review checklist tailored to a specific PR, language, and risk level. It helps reviewers be thorough without being bureaucratic.
+Produces a tailored code review checklist for a specific pull request — scaled to the language, type of change, and risk level. Not a generic template.

 ## Required Inputs

 Ask the user for these if not provided:
- **Programming language(s)** (e.g. Python, TypeScript, Go, Java)
- **PR type** (new feature / bug fix / refactor / performance improvement / security patch / infrastructure change)
- **Risk level** (Low: internal tooling, Low traffic / Medium: user-facing feature / High: payment, auth, data pipeline, public API)
- **Team context** (optional: team size, seniority mix, any known recurring issues)
+- **Language and framework** (e.g. TypeScript + React / Python + FastAPI / Go)
+- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
+- **Risk level** (low / medium / high / critical)
+- **PR description** (paste the description or link to the PR)
+- **Author context** (new starter / experienced / external contributor)

 ## Output Structure

-### 1. Checklist Header
+### 1. Review Summary
+**PR:** [Title or reference]
+**Scope assessment:** [Small / Medium / Large / Too large — should be split]
+**Recommended review depth:** [Skim / Standard / Deep dive]
+**Estimated review time:** [Minutes]

-**PR:** [Title if provided]
-**Language:** [Language]
-**Type:** [PR Type]
-**Risk Level:** [Low / Medium / High]
-**Estimated review depth:** [Quick scan ~15 min / Standard ~30 min / Deep review ~60 min+]
+### 2. Correctness Checks

---
+Language-specific correctness checks — choose based on the language stated:

-### 2. The Checklist
+**For TypeScript/JavaScript:**
+- Type definitions match actual usage
+- No implicit `any` in non-test code
+- Async/await used consistently; no unhandled promises
+- Null/undefined handling is explicit

-Organise into sections. Mark each item with a priority indicator:
- 🔴 **MUST** — Blocking. PR should not merge without this.
- 🟡 **SHOULD** — Important. Address before merge unless there's a good reason not to.
- 🟢 **CONSIDER** — Nice to have. Worth a comment but not blocking.
+**For Python:**
+- Type hints present on public functions
+- Exception handling is specific (no bare except)
+- Resources are closed (context managers, with blocks)

-#### Section A: Correctness
- 🔴 Does the code do what the ticket/requirement describes?
- 🔴 Are edge cases handled? (nulls, empty arrays, zero values, max values)
- 🔴 Are error states handled and surfaced appropriately?
- 🟡 Does the happy path have adequate test coverage?
- 🟡 Are failure paths tested?
+**For Go:**
+- Errors are handled or explicitly ignored with a comment
+- Context propagation is correct
+- Goroutine lifetimes are bounded

-#### Section B: Security (scale with risk level — expand for High risk PRs)
- 🔴 [High risk only] Is user input sanitised before use in queries or commands?
- 🔴 [High risk only] Are auth/permission checks in place?
- 🟡 Are secrets/credentials committed anywhere? (check .env handling)
- 🟡 Are third-party dependencies known-safe versions?
+[Include only the section matching the stated language]

-#### Section C: Performance
- 🟡 Are there N+1 query patterns in database calls?
- 🟡 Is there unnecessary work inside loops?
- 🟢 Are database queries indexed appropriately?
- 🟢 Is caching considered where appropriate?
+### 3. Change-Type-Specific Checks

-#### Section D: Readability & Maintainability
- 🟡 Are function and variable names clear without needing a comment to explain them?
- 🟡 Are complex logic blocks explained with inline comments?
- 🟢 Is the code consistent with existing patterns in the codebase?
- 🟢 Are there any magic numbers that should be named constants?
+**For bug fixes:**
+- A test exists that would have caught this bug
+- The fix addresses root cause, not symptom
+- Related code paths checked for the same issue

-#### Section E: Language-Specific Checks
-[Populate this section based on the specified language. Examples below:]
+**For features:**
+- Acceptance criteria met
+- Edge cases handled (empty, large, concurrent)
+- Error paths tested, not just happy path
+- Telemetry/logging added for debugging

-**Python:**
- 🟡 Are type hints used on function signatures?
- 🟡 Are exceptions caught specifically (not bare `except:`)?
- 🟢 Does it follow PEP 8 (or the team's linter config)?
+**For refactors:**
+- Behaviour unchanged (tests still pass)
+- No scope creep — refactor only
+- Complexity reduced, not just moved

-**TypeScript/JavaScript:**
- 🔴 Are there any `any` types that should be properly typed?
- 🟡 Are async/await patterns used consistently (no mixed Promise.then chains)?
- 🟢 Are there unnecessary re-renders in React components?
+**For dependency upgrades:**
+- Breaking changes reviewed
+- Security advisories checked
+- License compatibility verified

-**Go:**
- 🔴 Are errors checked (not ignored with `_`)?
- 🟡 Are goroutines properly managed to prevent leaks?
- 🟢 Are exported functions documented?
+[Include only the section matching the stated change type]

-#### Section F: PR Hygiene
- 🟡 Is the PR a reasonable size? (>500 lines diff suggests it should be split)
- 🟡 Does the PR description explain *why*, not just *what*?
- 🟢 Are there linked tickets or context in the PR description?
- 🟢 Are migration scripts or deployment notes included if needed?
+### 4. Risk-Appropriate Checks

---
+**Low risk:** basic correctness, style conventions, test coverage
+**Medium risk:** above + rollback plan, monitoring updates, performance considerations
+**High risk:** above + security implications, data migration safety, feature flag/gradual rollout
+**Critical risk:** above + staging validation plan, incident response plan, post-deploy verification checklist

-### 3. Risk-Specific Additions
+### 5. Testing Adequacy
+- Unit tests cover new logic
+- Integration tests cover the contract changes
+- Edge cases tested
+- Failure modes tested
+- Performance tests if performance-sensitive

-For **High risk** PRs, always add:
- 🔴 Has this been tested in a staging environment?
- 🔴 Is there a rollback plan?
- 🔴 Has a second reviewer been assigned?
+### 6. Review Decision Framework

-For **Infrastructure / DB changes**, always add:
- 🔴 Are migrations backward-compatible?
- 🔴 Has the migration been tested against production data volume?
+**Approve if:** [2-3 specific conditions based on this PR]
+**Request changes if:** [Specific blockers]
+**Comment (non-blocking) if:** [Items worth discussing but not blocking merge]

---
+### 7. Common Pitfalls for This Change Type
+Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.

 ## Quality Checks
-
- [ ] Checklist is tailored to the specified language (not generic)
- [ ] Risk level is reflected in the MUST vs SHOULD balance
- [ ] Language-specific section covers the most common issues for that language
- [ ] PR hygiene section is always present
- [ ] High-risk additions are included when risk level = High
+- [ ] Checklist is tailored to the stated language (not generic)
+- [ ] Change-type-specific section is included
+- [ ] Risk-appropriate depth matches stated risk level
+- [ ] Decision framework is explicit

 ## Example Trigger Phrases
-
- "Generate a code review checklist for a Python bug fix PR"
- "Give me a review checklist for a high-risk TypeScript auth change"
- "What should I check in this Go PR?"
- "Create PR review standards for our team"
+- "Generate a code review checklist for [PR description]"
+- "What should I check in this pull request?"
+- "Give me a code review checklist for a [language] [change type]"
+- "Review checklist for a high-risk PR in [language]"
@@ -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
@@ -1,54 +1,107 @@
 ---
 name: compliance-checklist
-description: "Generate a compliance checklist for any regulation, standard, or policy. Use when asked to create a compliance checklist, regulatory review, audit checklist, or policy adherence review. Covers GDPR, ISO 27001, FCA, HIPAA, SOC 2, and other frameworks. Produces a prioritised checklist with pass/fail assessment and remediation actions."
+description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
 ---

 # Compliance Checklist Skill

-Generates a structured compliance checklist for any regulatory framework with a prioritised gap analysis and remediation actions.
+Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
+
+ALWAYS include this disclaimer at the start of every response:
+"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."

 ## Required Inputs
- **Framework or regulation** (e.g. GDPR, HIPAA, SOC 2, ISO 27001, FCA Consumer Duty, PCI DSS)
- **Organisation type** (e.g. SaaS company, financial services, NHS trust, law firm)
- **Scope** (e.g. data handling, customer onboarding, IT security, HR processes)
- **Known gaps or concerns** (optional)
+
+Ask the user for these if not provided:
+- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
+- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
+- **Organisation size** (startup / scaleup / mid-market / enterprise)
+- **Current maturity** (no compliance programme / some controls / formal programme)
+- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)

 ## Output Structure

 ### 1. Framework Overview
- **Regulation/Standard:** [Name and version]
- **Enforcement body:** [Regulator]
- **Overall compliance status:** Red Gaps / Amber Partial / Green Compliant

-### 2. Compliance Checklist
+**Framework:** [Name with version]
+**Applicable because:** [One sentence — why this framework applies to this organisation]
+**Typical timeline to readiness:** [From current maturity to certified/compliant]
+**Key stakeholders needed:** [Roles that must be involved]

-| # | Requirement | Status | Priority | Action Required |
+### 2. Scope Definition
+
+What is in scope for this checklist:
+- [Specific systems / processes / data types]
+
+What is NOT in scope (explicit exclusions):
+- [Specific exclusions]
+
+### 3. Control Categories
+
+For each category relevant to the framework:
+
+**[Category — e.g. "Access Control"]**
+
+| Control | Current State | Gap | Priority | Effort |
 |---|---|---|---|---|
-| 1 | [Plain English requirement] | Met / Gap / Partial / Unknown | Critical / High / Low | [Specific action] |
+| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |

-Priority definitions:
- Critical: Regulatory breach risk. Remediate immediately.
- High: Significant gap. Address within 30 days.
- Low: Best practice. Address in next review cycle.
+### 4. Gap Analysis Summary

-### 3. Critical Gaps Summary
-List only Critical items with: what is missing, regulatory requirement breached, recommended remediation and owner.
+| Priority | Count | Examples |
+|---|---|---|
+| Critical gaps (block certification) | N | [Top 3] |
+| High priority gaps | N | |
+| Medium priority gaps | N | |
+| Quick wins | N | |

-### 4. Recommended Remediation Plan
+### 5. Quick Wins

-| Action | Owner | Timeline | Effort |
-|---|---|---|---|
-| [Specific action] | [Team/role] | [Timeframe] | Low/Med/High |
+Controls that can be implemented in under 2 weeks with minimal resources:

-### 5. Documentation Gaps
-Policies, records, or evidence needed to demonstrate compliance.
+1. **[Control]** — [Specific action] — [Owner] — [Days to complete]

---
+### 6. Evidence Requirements

-WARNING: This checklist is a starting point based on publicly available guidance. It does not constitute legal or compliance advice.
+For each control area, what documentation will be needed:
+
+| Control area | Evidence types | Where to source |
+|---|---|---|
+| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
+
+### 7. Implementation Roadmap
+
+Phase 1 (Weeks 1-4): Critical gaps and quick wins
+- [Specific deliverables]
+
+Phase 2 (Weeks 5-12): High-priority gaps
+- [Specific deliverables]
+
+Phase 3 (Weeks 13+): Medium priority and continuous improvement
+- [Specific deliverables]
+
+### 8. Ongoing Maintenance
+
+Once certified/compliant, what needs to continue:
+- [Review frequencies]
+- [Periodic testing requirements]
+- [Annual audit expectations]
+- [Staff training cadence]
+
+### 9. Common Pitfalls for This Framework
+
+2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
+
+## Quality Checks
+- [ ] Disclaimer included at start
+- [ ] Framework-specific controls (not generic)
+- [ ] Priorities align with organisation size and maturity
+- [ ] Quick wins clearly separated from complex implementations
+- [ ] Evidence requirements tied to specific controls

 ## Example Trigger Phrases
- "Create a GDPR compliance checklist for our SaaS product"
- "Generate a SOC 2 audit checklist"
- "Review our compliance against FCA Consumer Duty"
- "Build an ISO 27001 gap analysis"
+- "Create a GDPR compliance checklist for our SaaS"
+- "Generate a SOC 2 Type II readiness checklist"
+- "What do we need for ISO 27001 certification?"
+- "FCA compliance checklist for a fintech startup"
+- "HIPAA gap analysis for a healthtech scaleup"
@@ -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
@@ -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
@@ -0,0 +1,121 @@
+---
+name: docx-tracked-changes
+description: "Produce properly-formatted tracked changes for a Word document. Use when asked to redline a document, suggest edits to a contract or document, create tracked changes for review, or mark up a document with proposed revisions. Produces a complete redline with insertions, deletions, and margin comments that can be applied to the source document. Best used with Claude Opus 4.7 or newer for reliable tracked changes handling."
+---
+
+# Word Doc Tracked Changes Skill
+
+Produces properly-structured tracked changes for a Word document — insertions, deletions, replacements, and margin comments formatted so they can be applied directly to the source document. Built to leverage Opus 4.7 improvements in .docx redlining and tracked changes generation.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **The document** (paste the text or upload the .docx)
+- **Review type** (legal review / copy edit / substantive rewrite / compliance check / plain English rewrite)
+- **Review scope** (full document / specific sections / specific clause type)
+- **Reviewer role** (author / manager / legal counsel / subject matter expert)
+
+## Output Structure
+
+### 1. Redline Summary
+
+**Document:** [Name or identifier]
+**Review type:** [As stated]
+**Reviewer:** [Role]
+**Total changes:** [Insertions: N / Deletions: N / Comments: N]
+**Overall assessment:** [1-2 sentences — is this document close to final, or does it need substantial revision?]
+
+### 2. Top-Level Changes
+
+Changes that affect the meaning or structure of the document:
+
+**Change N — [Section or paragraph reference]**
+- Original: "[Exact original text]"
+- Suggested: "[Proposed new text]"
+- Reason: [Why this change — substantive/legal/clarity]
+
+### 3. Line-by-Line Tracked Changes
+
+For each paragraph that needs changes, format as:
+
+**[Paragraph reference — e.g. "Section 3, Paragraph 2"]**
+
+Original:
+> [Exact original paragraph]
+
+Tracked changes:
+> [Same paragraph with deletions marked as ~~strikethrough~~ and insertions marked as **bold**]
+
+Clean version:
+> [Final clean text after applying changes]
+
+### 4. Margin Comments
+
+Comments that flag issues without proposing a specific wording change:
+
+**Comment N — [Location]**
+"[Comment text — written as the reviewer would write it. Direct, specific, actionable.]"
+
+Comments are for things like:
+- "This clause conflicts with Section 7 — please reconcile"
+- "Missing definition of [term] used throughout"
+- "Confirm figure with finance team"
+
+### 5. Stylistic Edits
+
+Line-level stylistic changes (if scope includes copy editing):
+
+| Location | Before | After | Reason |
+|---|---|---|---|
+| Para 3 | [Text] | [Text] | [Readability/grammar/consistency] |
+
+### 6. Pattern Flags
+
+Issues that repeat across the document:
+
+**[Pattern — e.g. "Passive voice overuse"]**
+- Instances: [count]
+- Examples: [2-3 specific locations]
+- Suggested approach: [How to address]
+
+### 7. Review Completeness
+
+| Review dimension | Covered |
+|---|---|
+| Grammar and syntax | Yes / No |
+| Clarity and readability | Yes / No |
+| Substantive accuracy | Yes / No / N/A |
+| Compliance/legal check | Yes / No / N/A |
+| Consistency with referenced documents | Yes / No / N/A |
+
+### 8. How to Apply These Changes
+
+Instructions for applying the redline:
+
+**In Microsoft Word:**
+1. Enable Track Changes (Review tab → Track Changes)
+2. Apply the changes from Section 3 in order
+3. Add comments from Section 4 using Review → New Comment
+4. Send the redlined document back to the reviewer
+
+**In Google Docs:**
+1. Switch to Suggesting mode (top right pencil icon)
+2. Apply the changes from Section 3
+3. Add comments using the comment button in the margin
+
+## Quality Checks
+- [ ] Every tracked change has the original text preserved exactly
+- [ ] Substantive changes are separated from stylistic changes
+- [ ] Comments are written as the reviewer would write them, not meta-commentary
+- [ ] Pattern issues identified separately from individual changes
+- [ ] Application instructions match the target platform
+
+## Example Trigger Phrases
+- "Redline this contract"
+- "Create tracked changes for this document"
+- "Mark up this document with proposed edits"
+- "Review this and suggest changes in tracked changes format"
+- "Give me a redline version of this draft"
+
+## Why This Works Better on Opus 4.7
+Tracked changes require the model to preserve source text exactly while suggesting alternatives — earlier models would paraphrase the original or lose track of which text was original vs suggested. Opus 4.7 improvements specifically target this workflow.
@@ -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]"
@@ -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,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,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)
@@ -0,0 +1,64 @@
+---
+name: figma-annotation-guide
+description: "Generate structured developer handoff annotations for a Figma screen or component. Use when asked to write Figma annotations, create dev handoff notes, document a Figma design for developers, or write specs for a screen. Produces a complete annotation set covering interactions, states, spacing, accessibility, and edge cases."
+---
+
+# Figma Annotation Guide Skill
+
+Produces a complete set of developer handoff annotations for a Figma screen or component — the notes that turn a visual design into a buildable spec.
+
+## Required Inputs
+
+- **Screen or component description** (describe or summarise what was designed)
+- **Platform** (iOS / Android / Web / React Native)
+- **Interaction type** (static / interactive / animated / form)
+- **Developer audience** (mobile / frontend / full-stack)
+
+## Output Structure
+
+### 1. Screen/Component Overview
+Name, purpose, entry points, exit points.
+
+### 2. Interaction Annotations
+
+**[Element name]**
+- Default state: [Visual description]
+- On tap/click: [Exact action — API call, state change, navigation]
+- Loading state: [Description]
+- Success state: [What happens after]
+- Error state: [What error looks like and user options]
+- Disabled condition: [When and why]
+
+### 3. State Inventory
+
+| Element | States Required |
+|---|---|
+| [Element] | Default, Hover, Active, Disabled, Loading, Error, Empty |
+
+Flag missing designs: "Warning: Error state not designed — needed before build"
+
+### 4. Spacing and Layout Notes
+Fixed vs fluid elements, scroll behaviour, breakpoints, safe areas.
+
+### 5. Content and Copy Rules
+Character limits, dynamic vs static content, truncation rules, empty states.
+
+### 6. Accessibility Annotations
+Touch targets, screen reader labels, focus order, colour contrast, motion preferences.
+
+### 7. Edge Cases and Developer Questions
+- [ ] [Unresolved question for developer to flag]
+
+## Quality Checks
+- [ ] Every interactive element has all states defined
+- [ ] State inventory flags missing designs
+- [ ] Accessibility covers touch targets and screen reader labels
+- [ ] Empty states specified
+- [ ] Edge cases listed as actionable questions
+
+## Example Trigger Phrases
+- "Write dev annotations for this Figma screen"
+- "Create developer handoff notes for [screen/component]"
+- "Document this design for the engineering team"
+- "Write the Figma spec for [feature]"
+- "What should I annotate before handing off this design?"
@@ -0,0 +1,74 @@
+---
+name: figma-component-audit
+description: "Audit a Figma component library for consistency, coverage gaps, and naming issues. Use when asked to audit components, review a design system, check component consistency, identify missing components, or assess Figma library health. Produces a structured audit report with issues prioritised by impact, naming recommendations, and a fix plan."
+---
+
+# Figma Component Audit Skill
+
+Produces a structured audit of a Figma component library — identifying inconsistencies, naming problems, coverage gaps, and prioritised recommendations.
+
+## Required Inputs
+
+- **Component list or description** (paste component names or describe what exists)
+- **Product type** (mobile app / web app / desktop / multi-platform)
+- **Design system maturity** (new / growing / mature / legacy)
+- **Primary concern** (optional)
+
+## Output Structure
+
+### 1. Audit Summary
+
+| Dimension | Status | Score |
+|---|---|---|
+| Naming consistency | Red/Amber/Green | /10 |
+| Component coverage | | /10 |
+| Variant completeness | | /10 |
+| Documentation | | /10 |
+| Overall health | | /10 |
+
+**Verdict:** What is the state of this library and the single most important thing to fix?
+
+### 2. Naming Issues
+
+For each problem:
+**Issue: [Problem type]**
+- What is happening: [Specific examples]
+- Why it matters: [Impact on designers and developers]
+- Fix: [Exact naming convention to adopt]
+- Examples: Before / After
+
+Naming convention to enforce:
+- Components: PascalCase (NavigationBar)
+- Variants: Lowercase with slashes (size/large, state/hover)
+- Pages: All caps (COMPONENTS, FOUNDATIONS)
+
+### 3. Coverage Gaps
+
+| Missing Component | Priority | Why Needed |
+|---|---|---|
+| [Component] | High/Medium/Low | [Use case] |
+
+### 4. Variant Completeness Check
+
+| Component | Default | Hover | Active | Disabled | Error | Missing |
+|---|---|---|---|---|---|---|
+| [Button] | Yes | Yes | No | Yes | No | Active, Error |
+
+### 5. Prioritised Fix Plan
+
+| # | Fix | Effort | Impact | Do First? |
+|---|---|---|---|---|
+| 1 | [Fix] | Low/Med/High | High | Yes |
+
+## Quality Checks
+- [ ] Naming recommendations have before/after examples
+- [ ] Coverage gaps are relevant to the product type
+- [ ] Fix plan is ordered by impact-to-effort ratio
+- [ ] Variant completeness covers all interactive states
+
+## Example Trigger Phrases
+- "Audit my Figma component library"
+- "Review our design system for consistency issues"
+- "What components are we missing in our Figma library?"
+- "Our component naming is a mess — help me fix it"
+- "Do a health check on our Figma components"
@@ -0,0 +1,68 @@
+---
+name: figma-design-brief
+description: "Write a structured design brief for a Figma design task from a product requirement or feature request. Use when asked to write a design brief, create a design spec for Figma, turn a PRD into design requirements, or brief a designer on what to build in Figma. Produces a brief with goals, scope, user flows, components needed, constraints, and success criteria."
+---
+
+# Figma Design Brief Skill
+
+Converts a product requirement or feature request into a structured design brief — everything a designer needs to open Figma and start building confidently.
+
+## Required Inputs
+
+- **Feature or requirement** (paste PRD snippet, ticket, or describe the feature)
+- **User goal** (what is the user trying to accomplish?)
+- **Platform** (iOS / Android / Web / Responsive / All)
+- **Existing components available** (optional)
+- **Timeline** (when does design need to be ready?)
+
+## Output Structure
+
+### 1. Brief Header
+Feature, PM, Designer, Platform, Design due, Dev handoff dates.
+
+### 2. What We Are Designing and Why
+- **The goal:** [One sentence — user problem being solved]
+- **Context:** [2-3 sentences. Why now? What triggers this?]
+- **Success looks like:** [Specific observable outcome]
+
+### 3. User Flows to Design
+
+**Flow N: [Flow name]**
+- Entry point: [Where user starts]
+- Steps: [Numbered key steps]
+- Exit point: [Where flow ends]
+- Edge cases: [empty state, error state, loading state]
+
+### 4. Screens Required
+
+| Screen | New / Update | Notes |
+|---|---|---|
+| [Screen] | New | [Key requirement] |
+
+### 5. Components Needed
+
+| Component | In library? | Action |
+|---|---|---|
+| [Component] | Yes/No/Needs variant | Use/Create/Extend |
+
+### 6. Constraints and Requirements
+- Must haves: [Non-negotiable constraints]
+- Must avoid: [Design patterns to not use]
+- Accessibility: [WCAG level, touch target sizes]
+
+### 7. Open Questions
+- [ ] [Question — with owner]
+
+## Quality Checks
+- [ ] Goal is outcome-focused (not "design the feature")
+- [ ] All flows include edge cases
+- [ ] Components table identifies create vs reuse
+- [ ] Constraints include accessibility requirements
+- [ ] Open questions have owners
+
+## Example Trigger Phrases
+- "Write a design brief for [feature]"
+- "Turn this PRD into a Figma design brief"
+- "Brief the designer on what to build for [requirement]"
+- "Create a design spec for [feature] for Figma"
+- "What does the designer need to know to design [feature]?"
@@ -0,0 +1,76 @@
+---
+name: figma-design-critique-pm
+description: "Run a PM-perspective design critique focused on product outcomes, user goals, and business requirements — not aesthetics. Use when asked for a PM design critique, a product review of a design, feedback on a Figma design from a product perspective, or when you want to critique a design without being a designer. Produces structured outcome-based feedback tied to user goals and business metrics."
+---
+
+# Figma Design Critique — PM Perspective Skill
+
+This skill is specifically for product managers critiquing designs — focused on whether the design achieves the user goal and business outcome, not whether it looks good. Different from the general design-critique skill which covers UX aesthetics; this one centres product thinking.
+
+## Required Inputs
+
+- **Design description or screen summary**
+- **User goal** (what is the user trying to accomplish?)
+- **Business goal** (what outcome does the product need?)
+- **Original requirements** (what was this supposed to do?)
+- **Key metric** (what would move if this design works?)
+
+## Output Structure
+
+### 1. PM Critique Summary
+User goal, business goal restated.
+**Verdict:** On track / Mostly on track / Needs rethinking
+
+One-paragraph summary: what works from a product perspective, and the single most important thing to address.
+
+### 2. Goal Alignment Check
+
+| Goal | Design supports it? | Evidence |
+|---|---|---|
+| [User goal] | Yes/Partial/No | [Specific observation] |
+| [Business goal] | Yes/Partial/No | [Observation] |
+| [Key requirement] | Yes/Partial/No | [Observation] |
+
+### 3. PM Feedback (Outcome-Focused)
+
+Every concern must tie to an outcome. "I do not like this layout" is not PM feedback. "This layout puts the primary action below the fold, which will reduce mobile conversion" is PM feedback.
+
+**[Concern] — High/Medium/Low impact**
+- Observation: [Neutral description of what the design does]
+- User impact: [What this means for the user goal]
+- Business impact: [What this means for the metric]
+- Evidence basis: [Research/data/analogous patterns/hypothesis — be honest]
+- Question for designer: [What to explore — not a directive]
+
+### 4. What the Design Does Well
+2-4 specific things working well from a product perspective — with evidence. Not "colours are nice" but "primary CTA is the most prominent element, aligning with conversion goal." Always include this section.
+
+### 5. Questions Before Next Iteration
+
+| Question | Who answers | Why it matters |
+|---|---|---|
+| [Question] | Designer/PM/Eng | [Impact] |
+
+### 6. PM Recommendation
+Approve / Approve with changes (list) / Revise and re-review (one focus area only)
+
+## PM Critique Rules
+- Never reference aesthetics as reason for feedback — only outcomes
+- "I prefer" is not feedback — "users are likely to" is feedback
+- Lead with what is working before what is not
+- Ask questions before giving directives
+- One primary recommendation — not a redesign in bullets
+
+## Quality Checks
+- [ ] Every concern tied to user or business outcome
+- [ ] What is working section is genuine and specific
+- [ ] Questions section included (not just directives)
+- [ ] PM recommendation is explicit
+- [ ] Evidence basis stated honestly
+
+## Example Trigger Phrases
+- "Give me a PM critique of this design"
+- "Review this design from a product perspective"
+- "What product feedback do I have on this Figma design?"
+- "Critique this design without being a designer"
+- "Does this design achieve the user goal?"
@@ -0,0 +1,89 @@
+---
+name: figma-design-qa
+description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
+---
+
+# Figma Design QA Skill
+
+Runs a systematic pre-handoff QA check on a Figma design — catching issues that cause engineering back-and-forth before they become expensive.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Feature or screen being QA-d** (describe what has been designed)
+- **Platform** (iOS / Android / Web)
+- **Design system** (custom / Material / HIG / None)
+- **Handoff tool** (Figma Inspect / Zeplin / Storybook / Direct link)
+- **QA depth** (quick 15 min / standard 30 min / thorough 60 min)
+
+## Output Structure
+
+QA Report: [Feature] | [Date] | [Platform]
+**Overall status:** Ready / Minor fixes needed / Not ready
+
+### Section 1: File Hygiene
+- All layers named semantically (no "Rectangle 12")
+- No unused/hidden layers in final frames
+- Components from library (not detached copies)
+- All text uses text styles (not manual font settings)
+- All colours use styles or variables (not hex overrides)
+- Frames named to match screen map
+- No leftover prototype wires to wrong frames
+
+### Section 2: Component Usage
+- All buttons use library component
+- All inputs use library component
+- All icons from approved icon library
+- No custom components that should be in library
+- Variants used correctly (right size, state, type)
+
+### Section 3: Content and Copy
+- No placeholder text (Lorem ipsum) in final designs
+- All copy reviewed and approved
+- Realistic content used (not "User Name")
+- Long text edge cases tested
+- Error messages are human-readable
+- Empty states have copy and CTA
+
+### Section 4: States and Coverage
+- Default, Loading, Empty, Error, Success states
+- Interactive elements have hover/active (web)
+- Disabled states designed where applicable
+
+### Section 5: Accessibility
+- All text meets WCAG AA contrast (4.5:1 body, 3:1 large)
+- UI components meet 3:1 contrast against background
+- Touch targets minimum 44x44pt iOS / 48x48dp Android
+- Focus states for keyboard/switch navigation (web)
+- Information not conveyed by colour alone
+- Icons have text labels or accessible names annotated
+
+### Section 6: Handoff Readiness
+- Dev annotations on non-obvious interactions
+- Spacing uses Auto Layout (not absolute positioning)
+- Images/assets exported at correct resolutions
+- Design matches approved requirements
+- Link to prototype included
+
+### Issues Found
+For each fail:
+**[Issue] — Blocking / Fix before handoff / Fix in next iteration**
+- What: [Specific layer/screen/element]
+- Fix: [Exact action needed]
+- Owner: [Designer/PM/Both]
+
+### Handoff Decision
+Status, signed off by, date.
+
+## Quality Checks
+- [ ] All 6 sections completed
+- [ ] Every fail has a specific description and fix action
+- [ ] Blocking issues separated from minor ones
+- [ ] Handoff decision is explicit
+
+## Example Trigger Phrases
+- "QA this Figma design before handoff"
+- "Run a pre-handoff check on [feature] design"
+- "Is this Figma design ready for engineering?"
+- "Do a design QA on [screen/feature]"
+- "What needs fixing before we hand this off?"
@@ -0,0 +1,68 @@
+---
+name: figma-design-review
+description: "Run a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, do a PM design review, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and explicit approval status."
+---
+
+# Figma Design Review Skill
+
+Runs a structured PM design review — checking that a design meets product requirements, covers all user flows, and is ready for engineering. This is a requirements-and-outcomes review, not an aesthetic critique.
+
+## Required Inputs
+
+- **Design description or screen summary**
+- **Original requirements** (PRD snippet, ticket, or acceptance criteria)
+- **User flow being designed**
+- **Review stage** (concept / mid-fidelity / pre-handoff final)
+
+## Output Structure
+
+### 1. Review Header
+Feature, review stage, reviewed by, date.
+**Overall status:** Approved / Approved with changes / Needs revision
+
+### 2. Requirements Coverage Check
+
+| Requirement | Covered? | Notes |
+|---|---|---|
+| [Requirement from PRD] | Yes/No/Partial | [Specific observation] |
+
+Missing coverage summary: [Requirements not addressed — must resolve before approval]
+
+### 3. User Flow Completeness
+
+| Flow step | Designed? | Issues |
+|---|---|---|
+| [Step] | Yes/No/Partial | [Issue] |
+| Error state | Yes/No | |
+| Empty state | Yes/No | |
+| Loading state | Yes/No | |
+
+### 4. PM Concerns
+
+**[Concern] — Blocking / Should fix / Nice to fix**
+- What: [Specific observation]
+- Why it matters: [Business or user impact — not aesthetic preference]
+- Suggested resolution: [What PM wants to see]
+
+### 5. Open Questions
+
+| Question | Owner | Needed by |
+|---|---|---|
+| [Question] | Designer/Eng/PM | [Date] |
+
+### 6. Approval Decision
+Approved / Approved with changes (list) / Needs revision (focus area + next review date)
+
+## Quality Checks
+- [ ] Every requirement assessed
+- [ ] All flow states checked (error, empty, loading)
+- [ ] Concerns are outcome-focused not aesthetic
+- [ ] Open questions have owners
+- [ ] Approval status is explicit
+
+## Example Trigger Phrases
+- "Review this Figma design against the requirements"
+- "Do a PM design review for [feature]"
+- "Check if this design meets the product spec"
+- "Is this design ready to hand off to engineering?"
+- "What is missing from this design before we can build it?"
@@ -0,0 +1,84 @@
+---
+name: figma-prototype-plan
+description: "Plan prototype interactions and flows for user testing in Figma. Use when asked to plan a Figma prototype, set up prototype interactions, define what to prototype for a user test, or prepare a Figma prototype for usability testing. Produces a prototype scope, interaction specification, test task scripts, and Figma setup guide."
+---
+
+# Figma Prototype Plan Skill
+
+Plans what to prototype in Figma and how — scoping to what the user test needs, defining every interaction, and setting up the test scenarios. Prevents over-building and ensures the prototype answers the research question.
+
+## Required Inputs
+
+- **Research question** (what are you trying to learn?)
+- **Feature or flow being prototyped**
+- **Prototype fidelity** (low wireframe / mid functional / high pixel-perfect)
+- **Testing method** (moderated in-person / moderated remote / unmoderated)
+- **Number of test tasks**
+
+## Output Structure
+
+### 1. Prototype Scope
+
+**In scope:** [Flows with real interactions — specific screens listed]
+**Out of scope:** [Screens to show as static — not worth building as interactive]
+**Rationale:** Prototypes should be the minimum needed to test the hypothesis.
+
+### 2. Interaction Specification
+
+**Interaction N: [Description]**
+- Trigger: Tap/Swipe/Hover/Form submit
+- Element: [Figma layer name]
+- Destination: [Figma frame name]
+- Animation: Instant/Dissolve/Push left/Push right/Slide up
+- Timing: [ms]
+- Reset after: Yes/No
+
+### 3. Prototype Flow Diagram
+
+```
+[Start frame]
+  -> Tap "Action"
+[Next frame]
+  -> Tap "Complete" -> [Success frame]
+  -> Tap "Cancel"   -> [Back to start]
+```
+
+### 4. Test Task Scripts
+
+**Task N: [Title]**
+
+Scenario (read to participant):
+"[Realistic scenario giving context without directing the click path]"
+
+Observing:
+- [What to watch for]
+
+Success when: [Specific trigger]
+
+### 5. Figma Setup Guide
+- Starting frame: [Name]
+- Device preview: [Device]
+- Prototype settings: background colour, show device, type
+- Sharing: Can view link, reset process between participants
+
+### 6. Build vs Fake Table
+
+| Element | Build | Fake | Notes |
+|---|---|---|---|
+| Primary CTA flow | Yes | | Core to research |
+| Secondary nav | | Yes | Not being tested |
+| Error state | Yes | | Testing recovery |
+
+## Quality Checks
+- [ ] Scope limited to what the research question requires
+- [ ] Every interaction has a named destination frame
+- [ ] Task scripts are scenario-based (not "click on X")
+- [ ] Success criteria defined for each task
+- [ ] Reset process defined for between participants
+
+## Example Trigger Phrases
+- "Plan the Figma prototype for our user test on [feature]"
+- "What interactions do I need to build for this prototype?"
+- "Help me set up a Figma prototype for [research question]"
+- "Write the test task scripts for our [feature] prototype"
+- "What should I prototype vs leave as static screens?"
@@ -0,0 +1,77 @@
+---
+name: figma-spacing-system
+description: "Design a spacing and layout token system for a Figma design system. Use when asked to create a spacing system, define layout tokens, set up a grid system, build a spacing scale, or establish layout foundations for a Figma file. Produces a complete spacing scale, grid definition, component spacing conventions, and Figma implementation guide."
+---
+
+# Figma Spacing System Skill
+
+Produces a complete spacing and layout token system — the foundation that makes a design system consistent and developer handoff unambiguous.
+
+## Required Inputs
+
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Base unit** (4px / 8px — default to 8px)
+- **Design system name** (for token naming)
+- **Component density** (compact / standard / comfortable)
+- **Grid requirements** (or "derive from platform standard")
+
+## Output Structure
+
+### 1. Base Unit
+[4px or 8px] with rationale. All values must be multiples.
+
+### 2. Spacing Scale
+
+| Token | Value | Use case |
+|---|---|---|
+| spacing.none | 0px | Removing space intentionally |
+| spacing.xs | 4/8px | Icon padding, tight labels |
+| spacing.sm | 8/12px | Internal component padding compact |
+| spacing.md | 12/16px | Internal component padding standard |
+| spacing.lg | 16/24px | Section padding, card internal |
+| spacing.xl | 24/32px | Between components |
+| spacing.2xl | 32/48px | Section separation |
+| spacing.3xl | 48/64px | Page-level breaks |
+| spacing.4xl | 64/96px | Hero sections |
+
+### 3. Layout Grid
+
+Mobile (375px): 4 columns, margin [value], gutter [value]
+Tablet (768px): 8 columns, margin [value], gutter [value]
+Desktop (1440px): 12 columns, margin [value], gutter [value], max content width [value]
+
+### 4. Component Spacing Conventions
+
+| Context | Token | Example |
+|---|---|---|
+| Button horizontal padding | spacing.md | Left/right |
+| Button vertical padding | spacing.sm | Top/bottom |
+| Card internal padding | spacing.lg | All sides |
+| Input padding | spacing.sm vertical, spacing.md horizontal | |
+| Icon gap from label | spacing.xs | |
+| Section gap | spacing.xl | |
+
+### 5. Figma Implementation
+1. Create SPACING page documenting each token visually
+2. Resources > Variables > create Number collection named Spacing
+3. Apply variables to Auto Layout padding/gap values
+4. Share token names with engineers as-is or via Tokens Studio
+
+### 6. Anti-Patterns to Avoid
+- Values not on the scale (13px, 22px) — round to nearest token
+- Absolute pixel values in components instead of tokens
+- Mixing 4px and 8px base units in the same product
+
+## Quality Checks
+- [ ] All token values are multiples of the base unit
+- [ ] Scale covers xs through 4xl
+- [ ] Grid defined for all relevant breakpoints
+- [ ] Component conventions cover common decisions
+- [ ] Figma implementation steps included
+
+## Example Trigger Phrases
+- "Create a spacing system for our Figma design system"
+- "Define our spacing tokens for Figma"
+- "Set up a grid and spacing scale for [product]"
+- "What spacing values should we use in our design system?"
+- "Help me build the layout foundation for our Figma file"
@@ -0,0 +1,76 @@
+---
+name: figma-user-flow-planner
+description: "Plan user flows and screen states for a Figma design before any designing starts. Use when asked to plan a user flow, map out screens for a feature, define screen states, plan a Figma file structure, or work out what needs to be designed before opening Figma. Produces a complete flow map with all screens, states, entry/exit points, and a suggested Figma page structure."
+---
+
+# Figma User Flow Planner Skill
+
+Plans what needs to be designed before a pixel is touched — mapping all screens, states, entry points, and edge cases so designers do not discover missing states mid-build.
+
+## Required Inputs
+
+- **Feature or task being designed**
+- **User type** (who performs this flow?)
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Starting point** (where does the user begin?)
+- **Known edge cases** (optional)
+
+## Output Structure
+
+### 1. Flow Overview
+Feature, user, goal, entry points, success exit, failure exits.
+
+### 2. Screen Map
+
+| # | Screen name | Type | Triggered by | Notes |
+|---|---|---|---|---|
+| 1 | [Screen] | New/Modal/Drawer/Toast | [What triggers] | [Considerations] |
+
+Screen types to cover: entry, happy path, loading, success, error (network/validation/permission), empty, first-time/onboarding, edge cases.
+
+### 3. State Matrix
+
+**[Screen name]**
+
+| State | Trigger | Visual change | Action available |
+|---|---|---|---|
+| Default | Page load | [Description] | [What user can do] |
+| Loading | User taps action | Skeleton/spinner | None |
+| Error | API failure | Error message | Retry/Go back |
+| Empty | No data | Empty state | [CTA] |
+
+### 4. Decision Points
+
+**Decision: [Name]**
+- If yes: [Screen N]
+- If no: [Screen X]
+
+### 5. Suggested Figma File Structure
+
+```
+Feature name/
+- Cover
+- Flow Map
+- Happy Path
+- Error States
+- Empty States
+- Edge Cases
+- Handoff
+```
+
+### 6. What Not to Design Yet
+[Explicit out-of-scope items — prevents scope creep]
+
+## Quality Checks
+- [ ] All three state types covered: loading, error, empty
+- [ ] All decision points mapped with both branches
+- [ ] Entry points include all realistic user paths
+- [ ] Out-of-scope section is explicit
+- [ ] Figma file structure matches screen map
+
+## Example Trigger Phrases
+- "Plan the user flow for [feature] in Figma"
+- "What screens do I need to design for [feature]?"
+- "Map out the states for [feature] before we start designing"
+- "Help me structure my Figma file for [feature]"
+- "What do we need to design before handing this to the developer?"
@@ -0,0 +1,78 @@
+---
+name: figma-variant-matrix
+description: "Define component variants and states systematically for Figma. Use when asked to plan component variants, define states for a component, set up a Figma variant matrix, or work out what properties a component needs before building it. Produces a complete variant matrix with all properties, values, and combinations needed."
+---
+
+# Figma Variant Matrix Skill
+
+Defines all variants, properties, and states a component needs before building it in Figma — preventing missing variants discovered after the component is already used across 40 screens.
+
+## Required Inputs
+
+- **Component name** (Button, Card, Input, Badge, Navigation item, etc.)
+- **Component purpose** (what does it do, where is it used?)
+- **Platform** (iOS / Android / Web / Multi-platform)
+- **Design system context** (standalone / part of existing system)
+
+## Output Structure
+
+### 1. Component Overview
+Name, category (Interactive/Display/Layout/Form/Navigation/Feedback), used in contexts.
+
+### 2. Variant Properties
+
+| Property | Values | Notes |
+|---|---|---|
+| Type | Primary, Secondary, Tertiary, Destructive | |
+| Size | Large, Medium, Small | |
+| State | Default, Hover, Active, Disabled, Loading | |
+| Icon | None, Leading, Trailing, Only | |
+
+Total combinations: [N]. Flag if over 50 — consider splitting into multiple components.
+
+### 3. State Definitions
+
+For each state, list only what changes from Default:
+- Default: [Full visual spec]
+- Hover (web): [Delta from default]
+- Active/Pressed: [Delta]
+- Disabled: [Delta — use layer-level properties, not opacity on whole component]
+- Loading: [What replaces label, interactive during loading?]
+- Error (forms): [Border colour, helper text, icon changes]
+
+### 4. Anatomy Breakdown
+
+| Layer name | Purpose | Required? | Notes |
+|---|---|---|---|
+| container | Background and bounds | Yes | |
+| label | Text | Conditional | Hide when icon-only |
+| icon-leading | Leading icon slot | No | |
+
+### 5. Token Mapping
+
+| Property | Token | Fallback |
+|---|---|---|
+| Background default | color.brand.primary | #hex |
+| Border radius | radius.medium | 8px |
+
+### 6. Build Order
+1. Default state, most common variant
+2. Convert to component, add properties
+3. Size variants
+4. State variants
+5. Type variants
+6. Icon slot variants last
+
+## Quality Checks
+- [ ] All interactive states defined
+- [ ] Total variant count calculated, flagged if over 50
+- [ ] Every layer named semantically
+- [ ] Token mapping covers all visual properties
+- [ ] Disabled state uses layer-level properties not opacity
+
+## Example Trigger Phrases
+- "Define the variants for a [component] in Figma"
+- "What states does my [component] need?"
+- "Help me plan the variant matrix for [component]"
+- "Set up the Figma properties for a [button/card/input]"
+- "What are all the combinations I need for my [component]?"
@@ -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"
@@ -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
@@ -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]"
@@ -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"
@@ -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]"
@@ -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,13 +1,20 @@
 ---
 name: launch-readiness
-description: Run a comprehensive pre-launch readiness assessment across all functions
-tool_integration: Notion, Jira, Slack
+description: "Run a comprehensive pre-launch readiness assessment across all functions. Use when asked to assess launch readiness, run a pre-launch review, create a go/no-go recommendation, or check if a product or feature is ready to ship. Produces a function-by-function readiness status, blockers list, risk register, and an explicit Go / Conditional Go / No-Go recommendation."
 ---
+
 # Launch Readiness Skill

-## Purpose
 Ensure nothing falls through the cracks before launch by systematically checking readiness across every function — and producing a clear, evidenced go/no-go recommendation.

+## Required Inputs
+
+Ask the user for these if not provided:
+- **Launch name and target date**
+- **Launch tier** (Tier 1 = major launch / Tier 2 = significant feature / Tier 3 = incremental update)
+- **Completed checklist items or self-assessment** (even partial is fine — we'll surface gaps)
+- **Team and role names** (to assign owners to blockers)
+
 ## Readiness Checklist by Function

 ### Product & Engineering
@@ -15,7 +22,7 @@ Ensure nothing falls through the cracks before launch by systematically checking
 - [ ] Performance benchmarks met
 - [ ] Accessibility standards checked
 - [ ] Edge cases documented and handled
- [ ] Rollback plan defined
+- [ ] Rollback plan defined and tested

 ### Marketing & Comms
 - [ ] Launch messaging approved
@@ -45,11 +52,13 @@ Ensure nothing falls through the cracks before launch by systematically checking
 2. Flag any incomplete items as blockers (must fix) or risks (monitor)
 3. Assess overall readiness and produce go/no-go recommendation with rationale
 4. If no-go, specify exactly what must be completed and by when
+5. **Validate** — Confirm every blocker has a named owner and resolution deadline, and that the rollback plan is tested (not just documented)

-## Output Format
+## Output Structure

 ### Launch Readiness Assessment: [Feature/Product Name]
 **Launch Date:** [date]
+**Launch Tier:** [1 / 2 / 3]
 **Overall Status:** ✅ Go / ⚠️ Conditional Go / 🛑 No-Go

 **Blockers (must resolve before launch):**
@@ -63,3 +72,11 @@ Ensure nothing falls through the cracks before launch by systematically checking

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

 ```
@@ -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]"
@@ -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
@@ -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]"
@@ -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: 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
@@ -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]"
@@ -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]"
@@ -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]"
@@ -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: 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,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,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)
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
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
mohitagw15856	34b0f780e6	feat: Opus 4.7 release — 3 new vision/document skills, 3 updated skills (v5.2.0, 93 skills)	2026-04-17 12:07:27 +01:00
mohitagw15856	7dbf5a47a3	Rename setup-marketplace.sh to scripts/setup-marketplace.sh	2026-04-13 09:09:06 +01:00
mohitagw15856	f9d075ce3d	Rename add-plugin-json.sh to scripts/add-plugin-json.sh	2026-04-13 09:08:48 +01:00
mohitagw15856	81bc090869	Delete pm-figma-example.md	2026-04-13 09:08:09 +01:00
mohitagw15856	ff46498e46	Delete setup-pm-figma.sh	2026-04-13 09:07:17 +01:00
mohitagw15856	31c45072ec	Delete setup-80-skills.sh	2026-04-13 09:07:06 +01:00
mohitagw15856	d650957c6a	Delete create-plugin-jsons.sh	2026-04-13 09:06:55 +01:00
mohitagw15856	4dac8817cf	Delete create-plugin-json-pm-figma.sh	2026-04-13 09:06:39 +01:00
mohitagw15856	6deaa51bf6	Delete update-marketplace_new.sh	2026-04-13 09:05:58 +01:00
mohitagw15856	06243650b9	Delete update-marketplace.sh	2026-04-13 09:05:45 +01:00
mohitagw15856	69a319688f	fix: update marketplace.json to v5.1.0 — 22 plugins including pm-figma	2026-04-08 20:07:01 +01:00
mohitagw15856	254e389593	fix: add missing pm-figma plugin.json	2026-04-08 20:00:52 +01:00
mohitagw15856	f23c3a7e10	Update README.md	2026-04-09 00:24:18 +05:30
mohitagw15856	7db88b1a2d	feat: add pm-figma bundle — 10 Figma skills for PMs and designers (v5.1.0, 90 skills total)	2026-04-08 19:48:07 +01:00
mohitagw15856	7720d236ce	Add custom skills section to README Added a section on custom skills tailored for specific teams, highlighting their benefits and providing examples.	2026-04-06 01:47:16 +05:30
mohitagw15856	14d191cda0	chore: remove shell scripts from repo Internal bash scripts don't need to be public — removed from tracking. .gitignore already excludes *.sh going forward. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-05 13:11:44 +01:00
mohitagw15856	fd5b9daa43	Add files via upload	2026-04-05 13:10:04 +01:00
mohitagw15856	adb742a187	Create config.yml	2026-04-05 13:10:04 +01:00
mohitagw15856	dd33b0d416	Add files via upload	2026-04-05 13:10:04 +01:00
mohitagw15856	1fafb44dc2	Update README.md	2026-04-05 17:31:57 +05:30