feat: Opus 4.7 release — 3 new vision/document skills, 3 updated skills (v5.2.0, 93 skills)

Rename setup-marketplace.sh to scripts/setup-marketplace.sh
Rename add-plugin-json.sh to scripts/add-plugin-json.sh
2026-04-17 12:07:27 +01:00 · 2026-04-13 09:09:06 +01:00 · 2026-04-13 09:08:48 +01:00 · 2026-04-13 09:08:09 +01:00 · 2026-04-13 09:07:17 +01:00 · 2026-04-13 09:07:06 +01:00
114 changed files with 7608 additions and 393 deletions
@@ -1,8 +1,8 @@
 {
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "pm-claude-skills",
-  "version": "4.0.0",
-  "description": "53 Claude Skills across 6 professions — product management, marketing, engineering, data, design, and leadership. Save 10-15 hours per week.",
+  "version": "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"
@@ -119,6 +119,70 @@
      "category": "productivity",
      "source": "./plugins/pm-business",
      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-legal",
+      "description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists.",
+      "version": "1.1.0",
+      "category": "productivity",
+      "source": "./plugins/pm-legal",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-finance",
+      "description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence. Turn numbers into board-ready narratives, explain variances, structure pitch decks, and generate DD checklists.",
+      "version": "1.0.0",
+      "category": "productivity",
+      "source": "./plugins/pm-finance",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-hr",
+      "description": "HR skills: Job Description Writer, Onboarding Plan, Employee Engagement Survey, Redundancy Consultation. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, and structure legally compliant redundancy processes.",
+      "version": "1.0.0",
+      "category": "productivity",
+      "source": "./plugins/pm-hr",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-sales",
+      "description": "Sales skills: Sales Battlecard, Discovery Call Prep, Proposal Writer, Account Plan. Build competitive battlecards, prepare structured discovery calls, write winning proposals, and create strategic account plans.",
+      "version": "1.0.0",
+      "category": "productivity",
+      "source": "./plugins/pm-sales",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-operations",
+      "description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report. Document workflows, write audit-ready SOPs, evaluate vendors with weighted scorecards, and produce RAG status reports.",
+      "version": "1.0.0",
+      "category": "productivity",
+      "source": "./plugins/pm-operations",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-research",
+      "description": "Research and healthcare skills: Clinical Case Summary, Research Protocol, Patient Communication, Literature Review. Write SBAR handovers, design research protocols, draft accessible patient communications, and structure literature reviews.",
+      "version": "1.0.0",
+      "category": "productivity",
+      "source": "./plugins/pm-research",
+      "homepage": "https://github.com/mohitagw15856/pm-claude-skills"
+    },
+    {
+      "name": "pm-cross",
+      "description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary. 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 -->
@@ -0,0 +1,39 @@
+# Code of Conduct
+
+## Our Pledge
+
+This is an open-source community built around sharing useful Claude Skills across professions. Everyone who contributes, raises issues, or participates in discussions is expected to make this a welcoming and constructive space.
+
+We pledge to make participation in this project a harassment-free experience for everyone, regardless of age, background, disability, ethnicity, gender identity, level of experience, nationality, personal appearance, race, religion, or sexual identity.
+
+## Our Standards
+
+**Behaviour that helps this community thrive:**
+- Sharing skills that solve real workflows, with honest descriptions of what they do
+- Giving constructive feedback on PRs — specific, actionable, and respectful
+- Acknowledging other contributors' work
+- Being direct about limitations or gaps in a skill without being dismissive
+- Helping newcomers get their first PR merged
+
+**Behaviour that is not acceptable:**
+- Harassment, personal attacks, or dismissive comments on contributions
+- Submitting skills that contain malicious instructions or prompt injection attempts
+- Spamming issues or PRs with low-effort or off-topic content
+- Claiming credit for someone else's skill file
+- Any form of discrimination
+
+## Scope
+
+This Code of Conduct applies to all spaces managed by this project — GitHub Issues, Pull Requests, Discussions, and any other forums linked from this repo.
+
+## Reporting
+
+If you experience or witness unacceptable behaviour, contact the maintainer directly at **mohit15856@gmail.com**. All reports will be reviewed and responded to promptly and confidentially.
+
+## Enforcement
+
+The maintainer reserves the right to remove comments, close PRs, or ban contributors who violate this Code of Conduct. Decisions will be made fairly and explained where possible.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org), version 2.1.
@@ -1,8 +1,10 @@
-# 🧠 Claude Skills Library — 53 Skills for Every Professional
+# 🧠 Claude Skills Library — 93 Skills for Every Profession

-> **Save 8–10 hours per week across any profession. Install in 2 minutes.**
+> **Save 8–10 hours per week across 14 professions. Install in 2 minutes. Now with Opus 4.7-optimised vision and document skills.**

-A community-built library of Claude Skills covering product management, marketing, engineering, data, design, leadership, and business strategy. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
+A community-built library of Claude Skills covering product management, marketing, engineering, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
+
+**🆕 Latest release (v5.2.0):** Three new skills that leverage Claude Opus 4.7's improved vision and document capabilities — pptx-slide-auditor, docx-tracked-changes-writer, and chart-data-extractor.

 ---

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

 In Claude Code, run:

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

+Or install by profession:
+
+```bash
+claude plugin install pm-essentials@pm-claude-skills     # Core PM + Word tracked changes
+claude plugin install pm-delivery@pm-claude-skills       # Delivery + PowerPoint auditor
+claude plugin install pm-data@pm-claude-skills           # Data + chart data extractor
+claude plugin install pm-legal@pm-claude-skills          # Legal
+claude plugin install pm-finance@pm-claude-skills        # Finance
+claude plugin install pm-hr@pm-claude-skills             # HR
+claude plugin install pm-sales@pm-claude-skills          # Sales
+claude plugin install pm-operations@pm-claude-skills     # Operations
+claude plugin install pm-research@pm-claude-skills       # Research & Healthcare
+claude plugin install pm-cross@pm-claude-skills          # Cross-profession
+claude plugin install pm-figma@pm-claude-skills          # Figma
+```

 Or clone and symlink for auto-updates:

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

+---

-That's it. All 53 skills are now available in every Claude Code session.
+## 🆕 What's New in v5.2.0 — Opus 4.7 Release
+
+Three new skills designed specifically to leverage Claude Opus 4.7's improved vision and document capabilities:
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **PPTX Slide Auditor** | pm-delivery | Audit a PowerPoint deck for layout issues, text overflow, visual hierarchy problems, and consistency gaps |
+| **Word Doc Tracked Changes** | pm-essentials | Produce properly-formatted tracked changes for Word documents — insertions, deletions, margin comments |
+| **Chart Data Extractor** | pm-data | Extract pixel-level data from chart images and produce a structured data table with confidence levels |
+
+Plus three existing skills (figma-design-qa, code-review-checklist, compliance-checklist) updated to remove verification scaffolding that Opus 4.7 no longer needs — faster and cleaner outputs.
+
+**Read the full story:** [Part 13 — I Re-Tested My 90 Claude Skills on Opus 4.7](#)

 ---

@@ -37,81 +71,211 @@ This repo was built alongside a published article series. Read the full story:
 | Part 5 | What Google, Meta and Anthropic Want From PMs — And the Claude Skills That Deliver It | [Read →](https://medium.com/@mohit15856/what-google-meta-and-anthropic-want-from-pms-and-the-claude-skills-that-deliver-it-b0f2b6cd9340) |
 | Part 6 | I Tested Anthropic's Skill Creator Plugin on My Own Skills | [Read →](https://medium.com/all-about-claude/i-tested-anthropics-skill-creator-plugin-on-my-own-skills-here-s-what-i-found-23ad406b0825) |
 | Part 7 | 33 Claude Skills for PMs Are Now in the Claude Code Marketplace | [Read →](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) |
-| Part 8 | I Added 20 New Claude Skills Beyond Product Management | *Latest — link TBC* |
+| Part 8 | I Added 20 New Claude Skills Beyond Product Management | [Read →](https://medium.com/product-powerhouse/i-built-20-new-claude-skills-for-every-profession-heres-the-full-library-50278e00bf72) |
+| Part 9 | 80 Claude Skills for Every Profession — Lawyers, Doctors, Finance, HR, Sales and More | [Read →](https://medium.com/@mohit15856/80-claude-skills-for-every-profession-lawyers-doctors-finance-hr-sales-and-more-3dfde9ec0033) |
+| Part 10 | A Day in the Life With 80 Claude Skills | *Link TBC* |
+| Part 11 | 10 Figma Claude Skills for PMs and Designers | *Link TBC* |
+| Part 12 | I Built the Same Skills Library for ChatGPT — Here's What's Different | [Read →](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9) |
+| Part 13 | I Re-Tested My 90 Claude Skills on Opus 4.7 — Here's What Got Better | *Latest — Link TBC* |

 ---

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

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

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

 | # | Skill | What It Does |
 |---|---|---|
-| 1–33 | *[Original 33 PM skills]* | See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full list |
+| 1–6 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, **Word Doc Tracked Changes** 🆕 |
+| 7–10 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
+| 11–16 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
+| 17–24 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro, **PPTX Slide Auditor** 🆕 |
+| 25–27 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
+| 28–33 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
+| 34 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |
+
+> See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full PM skills detail.

 ---

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

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 34 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, and role-specific use cases |
-| 35 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with hooks, formats, and repurposing map |
-| 36 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
-| 37 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
+| 35 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
+| 36 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
+| 37 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
+| 38 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |

 ---

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

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

 ---

-### 📊 Data & Analytics (Skills 42–44)
+### 📊 Data & Analytics (Skills 43–46)
+**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 |
+| 43 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
+| 44 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
+| 45 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
+| 46 | **Chart Data Extractor** 🆕 | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |

 ---

-### 🧑‍💼 Leadership & Management (Skills 45–47)
+### 🧑‍💼 Leadership & People (Skills 47–49)
+**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 |
+| 47 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
+| 48 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
+| 49 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |

 ---

-### 🎨 Design & UX (Skills 48–50)
+### 🎨 Design & UX (Skills 50–52)
+**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 |
+| 50 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
+| 51 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
+| 52 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |

 ---

-### 🏢 Business & Strategy (Skills 51–53)
+### 🏢 Business & Strategy (Skills 53–55)
+**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 |
+| 53 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
+| 54 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
+| 55 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
+
+---
+
+### ⚖️ Legal (Skills 56–59)
+**Bundle:** `pm-legal`
+
+> ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 56 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
+| 57 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
+| 58 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
+| 59 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
+
+---
+
+### 💰 Finance (Skills 60–63)
+**Bundle:** `pm-finance`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 60 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
+| 61 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
+| 62 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
+| 63 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
+
+---
+
+### 👥 HR (Skills 64–67)
+**Bundle:** `pm-hr`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 64 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
+| 65 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
+| 66 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
+| 67 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
+
+---
+
+### 🤝 Sales (Skills 68–71)
+**Bundle:** `pm-sales`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 68 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
+| 69 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
+| 70 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
+| 71 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
+
+---
+
+### ⚙️ Operations (Skills 72–75)
+**Bundle:** `pm-operations`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 72 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
+| 73 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
+| 74 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
+| 75 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
+
+---
+
+### 🏥 Research & Healthcare (Skills 76–79)
+**Bundle:** `pm-research`
+
+> ⚠️ Healthcare skills are for documentation and educational purposes only. All clinical content must be reviewed by a qualified professional.
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 76 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
+| 77 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
+| 78 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
+| 79 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
+
+---
+
+### 🌐 Cross-Profession (Skills 80–82)
+**Bundle:** `pm-cross`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 80 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
+| 81 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
+| 82 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+
+---
+
+### 🖼️ Figma (Skills 83–92)
+**Bundle:** `pm-figma`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 83 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
+| 84 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
+| 85 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
+| 86 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
+| 87 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
+| 88 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
+| 89 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
+| 90 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
+| 91 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
+| 92 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
+
+```bash
+claude plugin install pm-figma@pm-claude-skills
+```

 ---

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

 **SKILL.md template:**
+```markdown
 ---
 name: your-skill-name
-description: "One sentence description. Use when [trigger condition]. Does [output description]."
+description: "One sentence. Use when [trigger condition]. Produces [output description]."
 ---

 # Skill Title

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

 **What makes a good skill:**
 - Solves a recurring professional workflow (not a one-off task)
@@ -144,12 +309,17 @@ description: "One sentence description. Use when [trigger condition]. Does [outp
 - Works without needing extensive setup or context

 **Skills wishlist** (most requested — up for grabs):
- `legal-contract-review` — Flag key clauses and risks in contracts
- `financial-model-narrative` — Turn a spreadsheet into a board-ready narrative
- `hr-job-description` — Write inclusive, structured JDs from a role brief
- `onboarding-plan` — 30/60/90-day plan for new hires
- `press-release` — Structured press releases from product announcements
- `seo-content-brief` — Content briefs with keyword strategy and outline
+
+| 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 |

 Have a skill idea? [Open an issue](../../issues) or raise it in [Discussions](../../discussions).

@@ -157,13 +327,78 @@ Have a skill idea? [Open an issue](../../issues) or raise it in [Discussions](..

 ---

+## 📦 All Plugin Bundles
+
+Install the whole library or just the bundles you need:
+
+```bash
+# Install everything
+/plugin marketplace add mohitagw15856/pm-claude-skills
+
+# Install by profession
+claude plugin install pm-essentials@pm-claude-skills
+claude plugin install pm-discovery@pm-claude-skills
+claude plugin install pm-planning@pm-claude-skills
+claude plugin install pm-delivery@pm-claude-skills
+claude plugin install pm-analytics@pm-claude-skills
+claude plugin install pm-strategy@pm-claude-skills
+claude plugin install pm-advanced@pm-claude-skills
+claude plugin install pm-rituals@pm-claude-skills
+claude plugin install pm-gtm@pm-claude-skills
+claude plugin install pm-engineering@pm-claude-skills
+claude plugin install pm-data@pm-claude-skills
+claude plugin install pm-people@pm-claude-skills
+claude plugin install pm-design@pm-claude-skills
+claude plugin install pm-business@pm-claude-skills
+claude plugin install pm-legal@pm-claude-skills
+claude plugin install pm-finance@pm-claude-skills
+claude plugin install pm-hr@pm-claude-skills
+claude plugin install pm-sales@pm-claude-skills
+claude plugin install pm-operations@pm-claude-skills
+claude plugin install pm-research@pm-claude-skills
+claude plugin install pm-cross@pm-claude-skills
+claude plugin install pm-figma@pm-claude-skills
+```
+
+---
+
+## 🤖 Companion Repository — ChatGPT Custom GPTs
+
+If you use ChatGPT instead of Claude Code, there's a companion repo with the same professional frameworks built as Custom GPT system prompts:
+
+**[professional-gpt-library](https://github.com/mohitagw15856/professional-gpt-library)** — 10 starter GPTs across 8 professions, MIT licence.
+
+Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGPT](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9)
+
+---
+
+## 🛠️ Custom Skills for Your Team
+
+The 93 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
+
+**What custom skills look like in practice:**
+
+- A law firm's contract review skill trained on their specific clause library and risk tolerance
+- A SaaS company's sprint brief skill that knows their engineering conventions and definition of done
+- A finance team's board pack skill that follows their exact narrative structure and slide format
+- An HR team's job description skill that reflects their values language and includes their specific benefits
+
+The difference between a generic skill and one built for your context is significant. Generic skills eliminate the blank page. Custom skills eliminate the rework.
+
+**If you want skills built for your team's specific workflows — [get in touch](mailto:mohit15856@gmail.com).**
+
+Include a brief description of your team, the workflows you want to automate, and the tools you use. I'll come back to you within 48 hours.
+
+---
+
 ## 📖 How Skills Work

-Skills are markdown files in `~/.claude/skills/` that Claude reads dynamically. When you describe a task, Claude scans available skill descriptions (~100 tokens) and loads the full skill only when it's relevant. This means:
+Skills are markdown files that Claude reads dynamically. When you describe a task, Claude scans available skill descriptions (~100 tokens) and loads the full skill only when relevant. This means:

 - Skills are efficient — they only use tokens when triggered
 - Multiple skills can coexist without slowing Claude down
 - Personal skills (`~/.claude/skills/`) work across all your projects
+- Plugin skills install via the Claude Code marketplace with one command

 Learn more: [Anthropic's Skills documentation](https://code.claude.com/docs/en/skills)

@@ -171,8 +406,8 @@ Learn more: [Anthropic's Skills documentation](https://code.claude.com/docs/en/s

 ## ⭐ If this is useful

-Star the repo so others can find it. And if you build something with these skills, share it — raise a PR, open a discussion, or tag me in your article.
+Star the repo so others can find it. And if you build something with these skills — raise a PR, open a discussion, or tag me in your article.

 ---

-*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Powerhouse publication](https://medium.com/product-powerhouse)*
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Notes publication](https://medium.com/product-powerhouse)*
@@ -0,0 +1,55 @@
+# Security Policy
+
+## Overview
+
+This repository contains Claude Skill files — plain markdown instruction files that teach Claude how to perform professional tasks. There are no backend services, APIs, authentication systems, or databases in this repo.
+
+That said, security matters here in two specific ways: **skill file safety** and **prompt injection risks**.
+
+## Supported Versions
+
+| Version | Supported |
+|---|---|
+| v4.0.0 (latest) | ✅ Active |
+| v3.0.0 | ✅ Security fixes only |
+| < v3.0.0 | ❌ No longer supported |
+
+## Skill File Safety
+
+All skills in this repo are reviewed before merging to ensure they:
+
+- Do not contain instructions designed to manipulate Claude into ignoring its guidelines
+- Do not attempt prompt injection (e.g. hidden instructions to override system behaviour)
+- Do not instruct Claude to request, store, or transmit personal or sensitive data
+- Do not contain malicious commands disguised as skill instructions
+- Do not include hardcoded credentials, API keys, or personally identifiable information
+
+**If you are installing skills from this repo:** skills are plain text markdown files. They do not execute code, make network requests, or access your file system on their own. Review any skill file before installing if you have concerns.
+
+## Reporting a Vulnerability
+
+If you discover a skill file in this repo that contains malicious instructions, a prompt injection attempt, or any content that could cause harm to users of Claude Code, please report it **privately** before raising a public issue.
+
+**How to report:**
+
+Email: **mohit15856@gmail.com**
+Subject line: `[SECURITY] pm-claude-skills — <brief description>`
+
+Include:
+- The skill file path (e.g. `plugins/pm-gtm/skills/go-to-market/SKILL.md`)
+- A description of the issue
+- Why you believe it is a security concern
+
+**Response time:** You will receive an acknowledgement within 48 hours and a resolution or update within 7 days.
+
+Please do not open a public GitHub Issue for security vulnerabilities — use the email above. Public disclosure before a fix is in place puts other users at risk.
+
+## Community Contributions
+
+All pull requests adding new skill files are reviewed for the safety criteria listed above before merging. If you are submitting a skill, ensure it:
+
+- Only contains instructions relevant to the stated professional workflow
+- Does not include any attempt to override Claude's built-in guidelines
+- Does not ask Claude to collect or relay user data
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) for full contribution guidelines.
@@ -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,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-cross",
+  "version": "1.0.0",
+  "description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary. Write journalist-ready press releases, structure grant applications aligned to funder priorities, and produce decision-ready executive summaries for any audience.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["communications", "press-release", "grant", "executive-summary", "briefing", "funding", "media"]
+}
@@ -0,0 +1,98 @@
+---
+name: executive-summary
+description: "Write an executive summary for any document, report, or proposal. Use when asked to write an executive summary, management summary, briefing paper, or one-pager for senior stakeholders. Produces a structured summary that busy executives can read in under 3 minutes and act on."
+---
+
+# Executive Summary Skill
+
+Writes executive summaries that busy decision-makers actually read — front-loaded with conclusions, structured for skimming, ruthless about what to include.
+
+## Required Inputs
+- **Source document or topic** (paste or describe)
+- **Audience** (CEO / board / investor / minister / client / committee)
+- **Decision or action needed** (what should the reader do after reading?)
+- **Length limit** (1 page / 2 pages / 500 words)
+- **Format** (formal report / slide / email / briefing paper)
+
+## Core Principle
+
+An executive summary is NOT a summary of the document. It is a standalone document that:
+- States the conclusion upfront — not at the end
+- Contains only what the reader needs to make a decision
+- Can be understood without reading anything else
+- Recommends a specific action
+
+## Output Structure
+
+---
+
+### [Title]
+**Executive Summary**
+*Prepared for: [Audience] | Date: [Date] | Author: [Name]*
+
+---
+
+**Bottom line up front:**
+[The most important thing. The recommendation or finding. 2-3 sentences. A reader who only reads this should know what you are asking or telling them.]
+
+---
+
+**Background (why this matters):**
+[2-3 sentences. Minimum context to understand the bottom line. Not the history — just what the reader needs now.]
+
+---
+
+**Key findings / analysis:**
+- **[Finding 1]:** [One sentence — specific and evidence-based]
+- **[Finding 2]:** [One sentence]
+- **[Finding 3]:** [One sentence]
+
+---
+
+**Options considered:** (include only if a decision is being presented)
+
+| Option | Benefit | Risk | Recommendation |
+|---|---|---|---|
+| [Option A] | [Benefit] | [Risk] | Recommended |
+| [Option B] | [Benefit] | [Risk] | Not recommended |
+
+---
+
+**Recommendation:**
+[Specific. "We recommend [action] because [reason]. This will [outcome]." Not "we suggest consideration of options."]
+
+---
+
+**Immediate next steps:**
+- [Action 1 — specific, with owner and date]
+- [Action 2]
+
+---
+
+**Risks of inaction:** [What happens if the reader does nothing]
+
+**Full report:** [Reference to where the full document can be found]
+
+---
+
+## Adapting for Different Audiences
+
+**CEO/MD:** Lead with financial or strategic impact. 1 page. Make the decision binary. Ask in sentence one.
+**Board:** Lead with governance or risk. Frame against organisational objectives. State specifically what you need from them.
+**Investor:** Lead with return or opportunity. Specific numbers. 1 page. Anticipate "why now."
+**Minister/senior public sector:** Lead with public benefit or policy alignment. Include cost-benefit framing.
+**Client:** Lead with their problem. Show you understand before presenting recommendation.
+
+## Quality Checks
+- Bottom line in first 3 sentences
+- Standalone — no need to read full document
+- Recommendation is specific
+- Fits length limit
+- Written for audience priorities not author priorities
+- Next steps have owners and dates
+
+## Example Trigger Phrases
+- "Write an executive summary of this report: [paste]"
+- "Summarise this document for the board: [paste]"
+- "Create a one-pager from this proposal for the CEO"
+- "Turn these findings into an exec summary"
@@ -0,0 +1,99 @@
+---
+name: grant-proposal
+description: "Write a structured grant proposal or funding application for any grant type. Use when asked to write a grant proposal, funding application, research grant, charitable grant, or innovation fund application. Produces a complete proposal with project summary, rationale, methodology, impact, and budget narrative."
+---
+
+# Grant Proposal Skill
+
+Produces structured grant proposals tailored to the funder priorities — the most common reason grants fail is writing about what you want to do rather than what the funder wants to fund.
+
+## Required Inputs
+- **Funder name and grant programme**
+- **Grant amount sought**
+- **Project description** (rough notes are fine)
+- **Your organisation** (type, track record, capacity)
+- **Funder stated priorities** (copy from their guidance — essential)
+- **Word or page limits**
+- **Deadline**
+
+## Output Structure
+
+---
+
+### Project Title
+[Informative and memorable. Should convey the problem being solved and the approach.]
+
+### 1. Project Summary / Abstract (200-300 words — written last, placed first)
+[What you will do, why it matters, who will benefit, measurable outcomes. Every sentence earns its place.]
+
+### 2. Problem Statement / Need
+- **The problem:** [Specific, evidenced — use data]
+- **Who is affected:** [Population, scale, geography]
+- **Current situation:** [What exists and why it is insufficient]
+- **Consequence of inaction:** [What happens if not funded]
+- **Why your organisation:** [Track record, relationships, expertise]
+
+Funder test: does this problem align with [funder] stated priorities? Make the connection explicit.
+
+### 3. Project Objectives
+3-5 SMART objectives:
+- **Objective 1:** [Specific, Measurable, Achievable, Relevant, Time-bound]
+
+### 4. Methodology / Approach
+
+**Phase 1: [Name]** (Months 1-X)
+[What will happen, who will do it, what is produced]
+
+**Key activities:**
+- [Activity — specific]
+
+**What makes this approach innovative or effective:** [Why this over alternatives]
+
+### 5. Impact and Outcomes
+
+| Level | Description | Measure |
+|---|---|---|
+| Output | [Tangible deliverable] | [How counted] |
+| Short-term outcome | [Immediate change] | [How measured] |
+| Medium-term outcome | [Behaviour change] | [How measured] |
+| Long-term impact | [Systemic change] | [How evidenced] |
+
+**Direct beneficiaries:** [Who and how many]
+**Sustainability:** [How work continues beyond grant period]
+
+### 6. Evaluation Plan
+- Who evaluates, how, when, what is measured, how findings are shared
+
+### 7. Budget Narrative
+
+| Budget line | Amount | Justification |
+|---|---|---|
+| Staff costs | £[amount] | [Role, % FTE, duration, salary] |
+| Travel | £[amount] | [Specific journeys named] |
+| Equipment | £[amount] | [Itemised] |
+| Indirect costs | £[amount] | [[X]% of direct — check policy] |
+| **Total** | **£[total]** | |
+
+**Value for money:** [Cost per beneficiary. What could not be done without this grant]
+
+### 8. Organisational Capacity
+[Track record of similar projects, governance, financial management. Name previous grants and outputs — be specific]
+
+### 9. Risk Register
+
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| [Risk] | H/M/L | H/M/L | [Specific mitigation] |
+
+---
+
+## Funder Alignment Check
+- Every section explicitly references funder stated priorities
+- Word limits respected
+- Budget aligns with eligible costs policy
+- Required attachments prepared
+
+## Example Trigger Phrases
+- "Write a grant proposal for [project] applying to [funder]"
+- "Help me write a funding application for [grant programme]"
+- "Turn these project notes into a grant proposal: [paste]"
@@ -0,0 +1,71 @@
+---
+name: press-release
+description: "Write a professional press release for any announcement. Use when asked to write a press release, media announcement, news release, or press statement. Produces a structured press release with headline, dateline, body, boilerplate, and media contact — ready to send to journalists."
+---
+
+# Press Release Skill
+
+Writes press releases that journalists actually read — structured around the news angle, not the desire to promote.
+
+## Required Inputs
+- **The news** (what is actually happening — be specific)
+- **Company name**
+- **Date of announcement / embargo date**
+- **Key quote** (from which executive and approximately what they want to say)
+- **Why this matters** (to the reader, not the company)
+- **Target media** (trade / national / local / consumer / investor)
+- **Media contact details**
+
+## Output Structure
+
+---
+
+FOR IMMEDIATE RELEASE / EMBARGOED UNTIL: [Date and time]
+
+---
+
+# [Headline — active verb, specific news, under 10 words]
+## [Subheadline — the so-what in one sentence, adds context not repetition]
+
+**[City, Date]** — [Opening paragraph: Who, What, When, Where, Why in 2-3 sentences. A journalist should be able to run this paragraph alone. No background, no context, no company history.]
+
+[Second paragraph: the significance. Why does this matter? What does it mean for customers or the industry?]
+
+[Third paragraph: quote from executive. Human and specific. Not a restatement of the headline.]
+
+"[Quote text — specific, adds something the facts do not say]," said [Name], [Title] at [Company]. "[Second sentence extending the thought]."
+
+[Fourth paragraph: supporting detail — data, customer names with permission, additional context]
+
+[Fifth paragraph optional: what happens next, when it goes live, what people can do]
+
+---
+
+ENDS
+
+---
+
+**Notes to editors:**
+
+**About [Company]**
+[Boilerplate: 3-4 sentences. What the company does, when founded, where based, key facts. Factual not promotional.]
+
+**Media contact:**
+[Name] | [Title] | [Email] | [Phone] | [Hours/timezone]
+
+---
+
+## Headline Rules
+- Active voice: "Company launches X" not "X is launched by Company"
+- Specific: "raises 5M" not "secures significant investment"
+- Under 10 words
+- Never start with the company name — lead with the news
+
+## Journalist Test
+Would a journalist care? Is the headline the full story? Is there a human angle? Is the quote something a human would say? Can the first paragraph stand alone?
+
+## Example Trigger Phrases
+- "Write a press release announcing [news]"
+- "Draft a media statement about [event]"
+- "We are launching [product] — write the press release"
+- "Turn this announcement into a press release: [paste notes]"
@@ -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]?"
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-finance",
+  "version": "1.0.0",
+  "description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence. Turn numbers into board-ready narratives, explain variances, structure pitch decks, and generate DD checklists.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["finance", "financial-model", "budget", "variance", "pitch-deck", "due-diligence", "investor"]
+}
@@ -0,0 +1,60 @@
+---
+name: budget-variance-analysis
+description: "Produce a structured budget variance analysis from actual vs budget figures. Use when asked to analyse budget variances, explain underspend or overspend, write a variance commentary, or investigate why actuals differ from plan. Produces a categorised variance table with root cause analysis and management commentary."
+---
+
+# Budget Variance Analysis Skill
+
+Produces a complete variance analysis from numbers through to root cause explanation and management commentary.
+
+## Required Inputs
+- **Actuals and budget figures** (paste as table or describe line by line)
+- **Period** (month / quarter / YTD)
+- **Materiality threshold** (e.g. £10k or 5%)
+- **Known reasons for variances** (if any)
+- **Audience** (CFO / board / management / auditor)
+
+## Output Structure
+
+### 1. Variance Summary Table
+
+| Line Item | Budget | Actual | Variance £ | Variance % | F/A |
+|---|---|---|---|---|---|
+| Revenue | | | | | |
+| Cost of Sales | | | | | |
+| Gross Profit | | | | | |
+| Opex | | | | | |
+| EBITDA | | | | | |
+
+F = Favourable | A = Adverse
+
+### 2. Material Variance Commentary
+
+For each variance above threshold:
+
+**[Line item] — £[amount] F/A ([%])**
+- **Root cause:** [Specific explanation — not "timing" without detail]
+- **Permanent or timing?** Will this reverse next period?
+- **Management action:** What is being done
+- **Forecast impact:** Does this change full-year outlook?
+
+### 3. Top 3 Variances Requiring Attention
+Ranked by materiality and strategic significance.
+
+### 4. Forecast Revision
+Does the full-year forecast need updating? State revised expectation and key assumptions.
+
+### 5. Executive Summary
+3-4 sentences of management commentary suitable for a board pack.
+
+## Quality Checks
+- All variances above threshold explained
+- Root causes specific (not vague)
+- Favourable/Adverse correctly labelled
+- Forecast impact stated for material variances
+
+## Example Trigger Phrases
+- "Write a variance analysis for these actuals vs budget: [paste]"
+- "Explain why we are over budget on [cost line]"
+- "Write the variance commentary for our finance review"
+- "Produce a budget vs actual analysis for Q[N]"
@@ -0,0 +1,76 @@
+---
+name: financial-due-diligence
+description: "Generate a financial due diligence checklist and analysis framework for any investment, acquisition, or partnership. Use when asked for a due diligence checklist, M&A financial review, investment analysis framework, or vendor financial assessment."
+---
+
+# Financial Due Diligence Skill
+
+Produces a structured financial due diligence framework — document request list and analytical questions — for any investment, acquisition, or significant commercial relationship.
+
+## Required Inputs
+- **Transaction type** (acquisition / investment / partnership / supplier / fundraise)
+- **Stage of diligence** (initial screening / full DD / confirmatory)
+- **Target company type** (startup / SME / listed / subsidiary)
+- **Key concerns** (optional — e.g. revenue recognition, customer concentration)
+
+## Output Structure
+
+### 1. Document Request List
+
+**Financial Statements**
+- Audited accounts for last 3 years
+- Management accounts for current year (monthly)
+- Board-approved budget and latest reforecast
+- 3-year financial model with assumptions
+
+**Revenue**
+- Revenue by customer (top 20, % of total)
+- Revenue by product/segment
+- Contracted vs recurring vs one-off breakdown
+- Churn and renewal data
+
+**Costs**
+- Cost of sales breakdown
+- Headcount by department with compensation detail
+- Top 10 supplier contracts
+
+**Cash and Debt**
+- Bank statements (12 months)
+- Debt schedule with covenants and maturity
+- Working capital analysis
+
+**Tax**
+- Last 3 years tax returns
+- Any open enquiries
+- R&D tax credit claims
+
+### 2. Key Analytical Questions
+
+**Revenue quality:** Is revenue growing organically? What % is truly recurring? Customer concentration risk?
+
+**Margin analysis:** Gross margin trend over 3 years? One-off items inflating EBITDA? Normalised EBITDA?
+
+**Cash conversion:** Does profit convert to cash? Cash conversion cycle? Working capital red flags?
+
+**Debt and liabilities:** Net debt position? Contingent liabilities? Covenant headroom?
+
+### 3. Red Flags Checklist
+- Revenue concentration over 30% in one customer
+- Declining gross margins without explanation
+- EBITDA-to-cash conversion below 70%
+- Auditor qualifications or emphasis of matter
+- Related party transactions not at arm length
+- Aggressive revenue recognition
+- Growing debtor days with no explanation
+
+### 4. Summary Output Template
+- Revenue quality: [Assessment]
+- Margin sustainability: [Assessment]
+- Cash generation: [Assessment]
+- Balance sheet risk: [Assessment]
+- Overall: Green Strong / Amber Acceptable / Red Material concerns
+
+## Example Trigger Phrases
+- "Give me a financial due diligence checklist for [company type]"
+- "What documents should I request for financial DD?"
+- "Build a DD framework for our Series A investment"
@@ -0,0 +1,62 @@
+---
+name: financial-model-narrative
+description: "Turn financial model outputs into a clear written narrative. Use when asked to write a financial narrative, explain a financial model, summarise a P&L, or translate spreadsheet numbers into a board-ready story. Produces an executive narrative with key insights, drivers, and forward-looking commentary."
+---
+
+# Financial Model Narrative Skill
+
+Turns financial model outputs into a clear, structured written narrative suitable for board packs, investor updates, or management reporting.
+
+## Required Inputs
+- **Financial data** (paste key figures: revenue, costs, margins, EBITDA, cash)
+- **Period covered** (month / quarter / annual / multi-year)
+- **Audience** (board / investors / management / bank / internal)
+- **Key message** (what is the headline story?)
+- **Actuals vs budget / prior period?** (comparison context)
+
+## Output Structure
+
+### 1. Headline Summary
+3-5 sentences. The financial story in plain English. Lead with the most important insight — not "revenue was X" but what that figure means.
+
+### 2. Revenue
+- Performance vs prior period / budget
+- Key drivers: what caused the movement
+- Risks or opportunities in the revenue line
+
+### 3. Costs and Margins
+- Gross margin: % and trend
+- Key cost movements and why
+- EBITDA performance and drivers
+- One-off items clearly flagged
+
+### 4. Cash and Balance Sheet
+- Cash position and movement
+- Runway (for startups)
+- Key working capital movements
+
+### 5. Variance Analysis
+For each significant variance:
+
+**[Line item] — Over/Under by [amount]**
+- **Cause:** [Plain English explanation]
+- **Permanent or temporary?** One-time / Structural
+- **Action being taken:** [If applicable]
+
+### 6. Forward-Looking Commentary
+- Expected next period
+- Key risks to forecast
+- Key opportunities
+- Any reforecast or guidance change
+
+## Writing Rules
+- Never just restate a number — always explain what it means
+- Flag variances over 10% automatically
+- Use past tense for actuals, conditional for forecast
+- One insight per paragraph
+
+## Example Trigger Phrases
+- "Write a financial narrative for these results: [paste numbers]"
+- "Turn this P&L into a board narrative"
+- "Write the finance section of our board pack"
+- "Explain these financial results in plain English"
@@ -0,0 +1,48 @@
+---
+name: investor-pitch-deck
+description: "Build the narrative and slide structure for an investor pitch deck. Use when asked to create a pitch deck, investor presentation, fundraising deck, or startup pitch. Produces a slide-by-slide structure with narrative beats, key messages, and what each slide must prove to an investor."
+---
+
+# Investor Pitch Deck Skill
+
+Builds the complete narrative and slide structure for an investor pitch deck — focused on what investors need to see, not what founders want to show.
+
+## Required Inputs
+- **Company name and one-line description**
+- **Stage** (Pre-seed / Seed / Series A / Series B)
+- **Ask** (how much raising and what for)
+- **Key metrics** (revenue, growth, users, retention)
+- **Target investors** (generalist / sector-specific / angels)
+- **Deck length** (10 / 12 / 15 slides)
+
+## Output Structure
+
+For each slide:
+- **What this slide must prove** (the investor question it answers)
+- **Content guidance** (specific, not generic)
+- **Common mistake to avoid**
+
+---
+
+**Slide 1: Cover** — Proves you can say what you do in one sentence.
+**Slide 2: Problem** — Proves the problem is real, painful, and large. Lead with the human problem, not market size.
+**Slide 3: Solution** — Proves your solution is meaningfully better. Focus on outcome, not features.
+**Slide 4: Product** — Proves this is real and works. Show the actual product.
+**Slide 5: Traction** — Proves people want this. Show retention and revenue, not signups.
+**Slide 6: Market** — Proves the market is large enough. Use bottoms-up TAM where possible.
+**Slide 7: Business Model** — Proves you understand unit economics. Include CAC and LTV.
+**Slide 8: Go-To-Market** — Proves you can acquire customers efficiently. Focus on what is actually working.
+**Slide 9: Competition** — Proves you understand the landscape. Never say "no competitors."
+**Slide 10: Team** — Proves this team can execute this opportunity. One sentence per person, specific.
+**Slide 11: Financials** — Proves you understand your business. Show assumptions, not just projections.
+**Slide 12: The Ask** — Proves you know exactly what you need. Specific use of funds and 18-month milestones.
+
+## Narrative Principles
+- Every slide answers one investor question
+- Investors decide go/no-go on slides 1-5 — front-load evidence
+- Keep to 10-12 slides for a first meeting
+
+## Example Trigger Phrases
+- "Build a pitch deck structure for [company]"
+- "Help me structure my Series A deck"
+- "What slides should my investor pitch have?"
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-hr",
+  "version": "1.0.0",
+  "description": "HR skills: Job Description Writer, Onboarding Plan, Employee Engagement Survey, Redundancy Consultation. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, and structure legally compliant redundancy processes.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["hr", "people", "job-description", "onboarding", "engagement", "redundancy", "recruitment"]
+}
@@ -0,0 +1,86 @@
+---
+name: employee-engagement-survey
+description: "Design an employee engagement survey and analyse results. Use when asked to create an employee survey, engagement questionnaire, pulse survey, or eNPS survey. Also use when asked to analyse survey results. Produces a complete survey with questions, rating scales, and an analysis framework."
+---
+
+# Employee Engagement Survey Skill
+
+Designs complete employee engagement surveys and provides a framework for analysing and acting on results.
+
+## Mode Detection
+- User provides survey results -> Analysis mode
+- User wants to create a survey -> Design mode
+
+---
+
+## Design Mode
+
+### Required Inputs
+- Survey type (annual / quarterly pulse / post-onboarding / exit / specific topic)
+- Company size and stage
+- Key areas of concern (optional)
+- Anonymity approach
+- Length target (short: 5-10 / standard: 15-25 / comprehensive: 30+)
+
+### Opening Statement (always include)
+"This survey is anonymous. Your responses help us understand what is working and what to improve. Results will be shared with [who] and we will communicate actions taken by [date]."
+
+### Core Questions
+
+**Overall Engagement**
+1. On a scale of 0-10, how likely are you to recommend [Company] as a great place to work? (eNPS)
+2. I feel proud to work at [Company]. [1-5]
+3. I intend to still be working here in 12 months. [1-5]
+
+**Role and Clarity**
+4. I understand how my work contributes to company goals. [1-5]
+5. I have the tools and resources I need to do my job. [1-5]
+6. My workload is manageable. [1-5]
+
+**Manager and Team**
+7. My manager gives useful feedback. [1-5]
+8. My manager cares about my development. [1-5]
+9. I feel part of a team that works well together. [1-5]
+
+**Culture and Belonging**
+10. I feel I can be myself at work. [1-5]
+11. People treat each other with respect. [1-5]
+12. [Company] lives by its stated values. [1-5]
+
+**Growth and Recognition**
+13. I have opportunities to grow and develop. [1-5]
+14. My contributions are recognised. [1-5]
+15. I have had a meaningful career conversation in the last 6 months. [Yes/No]
+
+**Open questions (always include)**
+- What is one thing [Company] should start doing?
+- What is one thing [Company] should stop doing?
+- Anything else to share?
+
+---
+
+## Analysis Mode
+
+### Analysis Output
+
+**1. Headline Scores**
+| Metric | Score | Benchmark | Trend |
+|---|---|---|---|
+| eNPS | [-100 to +100] | Industry avg | vs last survey |
+
+eNPS: Below 0 = Concerning / 0-30 = Good / 30-70 = Great / 70+ = Excellent
+
+**2. Strengths** — Top scoring areas with evidence.
+
+**3. Improvement Areas** — 3 lowest scoring areas with verbatim comment themes.
+
+**4. Action Planning Template**
+| Improvement area | Action | Owner | Timeline | Measure |
+|---|---|---|---|---|
+
+**5. Communication Template** — Draft message to share results with employees.
+
+## Example Trigger Phrases
+- "Create an employee engagement survey for our team"
+- "Design a pulse survey for [topic]"
+- "Analyse these engagement survey results: [paste]"
@@ -0,0 +1,74 @@
+---
+name: job-description-writer
+description: "Write a clear, inclusive, and structured job description for any role. Use when asked to write a job description, job posting, JD, or job advert. Produces a complete JD with role summary, responsibilities, requirements, and inclusive language review."
+---
+
+# Job Description Writer Skill
+
+Writes complete, inclusive job descriptions that attract the right candidates and reduce bias in the hiring process.
+
+## Required Inputs
+- **Job title and level**
+- **Team and reporting line**
+- **Top 5 things this person will actually do**
+- **Must-have requirements** (be ruthless — only what is truly required)
+- **Nice-to-have requirements**
+- **Salary range** (JDs with salary ranges get 30% more applicants)
+- **Location and remote policy**
+- **Company description** (2-3 sentences)
+
+## Output Structure
+
+### [Job Title]
+**[Company] | [Location] | [Remote policy] | [Salary range]**
+
+**About [Company]**
+[2-3 sentences. Specific and honest — not marketing copy.]
+
+**The Role**
+[3-4 sentences. What this person will own, why the role exists now, what success looks like in year one.]
+
+**What You Will Do**
+[6-8 bullet points. Outcomes and responsibilities, not activities. Start each with an action verb. Most important first.]
+
+**What We Are Looking For**
+
+Must have (4-6 items only):
+- [Requirement]
+
+Nice to have (3-4 items):
+- [Nice to have]
+
+**What We Offer**
+[Compensation, benefits, development. Be specific.]
+
+**How to Apply**
+[Clear instructions. What to send, where, timeline.]
+
+---
+
+### Inclusive Language Review
+
+**Words to remove or replace:**
+
+| Original | Replace with | Why |
+|---|---|---|
+| "rockstar" | "experienced" | Gendered connotation |
+| "ninja" | "skilled" | Same issue |
+| "must have degree" | "relevant experience or qualification" | Excludes qualified non-graduates |
+
+**Requirement audit:**
+- Years of experience requirements flagged (screen out women and underrepresented groups disproportionately)
+- Any requirements potentially discriminating against protected characteristics
+
+## Quality Checks
+- Salary range included
+- Must-haves genuinely essential (6 items max)
+- Each responsibility starts with action verb
+- Inclusive language review completed
+- No years-of-experience requirements unless legally required
+
+## Example Trigger Phrases
+- "Write a job description for a [role]"
+- "Create an inclusive job posting for [role]"
+- "Review and rewrite this JD: [paste]"
@@ -0,0 +1,89 @@
+---
+name: onboarding-plan
+description: "Create a structured 30/60/90-day onboarding plan for any new hire. Use when asked to write an onboarding plan, new hire plan, 30-60-90 day plan, or first 90 days roadmap. Produces a week-by-week plan with milestones, meetings, learning goals, and success criteria."
+---
+
+# Onboarding Plan Skill
+
+Creates a complete, structured onboarding plan tailored to a specific role — covering the first 90 days with clear milestones and success criteria.
+
+## Required Inputs
+- **Role and level** of the new hire
+- **Team and manager**
+- **Key stakeholders** they will work with
+- **Top 3 priorities** for their first 90 days
+- **Tools and systems** they will need access to
+- **Company stage** (startup / scaleup / enterprise)
+
+## Output Structure
+
+### Onboarding Plan: [Name] — [Role]
+**Start date:** [Date] | **Manager:** [Name] | **Buddy:** [Name]
+
+---
+
+### Before Day 1 (Manager checklist)
+- IT setup: laptop, accounts, email, Slack, key tools
+- Access provisioned to key systems
+- First week calendar blocked with key meetings
+- Buddy assigned and briefed
+- Welcome message sent with Day 1 logistics
+
+---
+
+### Week 1: Orient
+Theme: Listen, learn, do not act yet.
+
+| Day | Focus | Key activities |
+|---|---|---|
+| Day 1 | IT setup, team intro | 1:1 with manager, team lunch |
+| Day 2 | Product deep dive | Demo, key docs to read |
+| Day 3 | Process and tools | Shadow key workflows |
+| Day 4 | Stakeholder intros | 3-4 intro 1:1s |
+| Day 5 | Week 1 debrief | Check-in, questions logged |
+
+**Week 1 milestone:** Can describe what the company does, the team role, and their top 3 priorities.
+
+---
+
+### Days 8-30: Learn
+Learning goals:
+- Deep understanding of product from customer perspective
+- Know key metrics the team is measured on
+- Understand current projects and status
+- Map key stakeholder relationships
+- Complete all compliance/HR training
+
+**30-day milestone:** All stakeholder 1:1s complete. 2-3 early observations shared with manager.
+
+---
+
+### Days 31-60: Contribute
+Goals:
+- Own at least one project end-to-end
+- Make one meaningful contribution
+- Build cross-functional relationships
+- Identify one process improvement
+
+**60-day milestone:** Delivered one tangible output. Manager says "this person is contributing."
+
+---
+
+### Days 61-90: Lead
+Goals:
+- Operating independently on core responsibilities
+- Has formed and shared a point of view on priorities
+- Building reputation with key stakeholders
+
+**90-day milestone:** Ready for formal review. Clear 6-month plan in place.
+
+---
+
+### 90-Day Review Questions
+Manager: Meeting expectations? What to double down on? What to develop?
+New hire: Have the clarity, tools, support needed? What surprised you? What would you change about onboarding?
+
+## Example Trigger Phrases
+- "Create a 30/60/90 day plan for a new [role]"
+- "Write an onboarding plan for [name] starting as [role]"
+- "Build a first 90 days roadmap for our new hire"
@@ -0,0 +1,68 @@
+---
+name: redundancy-consultation
+description: "Structure a redundancy consultation process and draft key communications. Use when asked to plan a redundancy process, write a redundancy letter, structure a consultation, or manage a reduction in force. UK employment law focus. Always recommend qualified HR/legal advice before proceeding."
+---
+
+# Redundancy Consultation Skill
+
+Structures redundancy processes and drafts communications. Significant legal and human risk — always flag that employment legal advice is essential before proceeding.
+
+WARNING: Defaults to UK employment law (Employment Rights Act 1996). Always recommend qualified HR/legal advice before any redundancy action.
+
+## Required Inputs
+- **Number of roles affected** (1-19 = individual; 20+ = collective consultation required)
+- **Reason for redundancy** (genuine business reason)
+- **Jurisdiction** (UK / US / EU / Other)
+- **Timeline constraints**
+- **Selection pool** (if multiple people in similar roles)
+
+## Output Structure
+
+### 1. Process Overview
+
+**Individual redundancy (fewer than 20):**
+| Stage | Action | Minimum timeline |
+|---|---|---|
+| 1 | Confirm business case internally | Before any communication |
+| 2 | At-risk notification meeting | Day 1 |
+| 3 | Individual consultation | Minimum 1 meaningful meeting |
+| 4 | Redundancy confirmed or alternative found | After genuine consideration |
+| 5 | Notice period begins | Per contract |
+| 6 | Final day and payment | Per contract + statutory |
+
+**Collective redundancy (20+ roles — UK):**
+- Minimum 45 days consultation before first dismissal
+- Must notify BEIS (HR1 form) before consultation begins
+- Employee representatives must be elected if no union recognised
+- Failure = unlimited protective award per employee
+
+### 2. Selection Criteria (if pool exists)
+Objective, non-discriminatory only: skills/qualifications, performance (documented evidence), attendance (exclude disability/pregnancy-related absences), length of service (tiebreaker only).
+
+NEVER select on: age, disability, pregnancy/maternity, part-time status, trade union membership.
+
+### 3. At-Risk Letter Draft
+"Dear [Name], I am writing to inform you that your role of [Job Title] is at risk of redundancy. This is because [specific business reason]. We would like to meet on [date] to discuss the situation and explore alternatives. You have the right to be accompanied by a colleague or trade union representative. No decision has been made. Yours sincerely, [Manager]"
+
+### 4. Consultation Meeting Script
+Opening: "No decision has been made. This meeting is to explain the situation and listen to your views."
+Key questions: Any ways to avoid this? Alternative roles of interest? Anything about selection to challenge?
+
+### 5. Redundancy Confirmation Letter Draft
+Issued only after genuine consultation. Must include: statutory pay calculated, notice period, payment for accrued holiday, right of appeal.
+
+### 6. Statutory Redundancy Pay Guide (UK)
+- Under 22: 0.5 week per year of service
+- 22-40: 1 week per year of service
+- 41+: 1.5 weeks per year of service
+- Weekly pay capped (verify current rate)
+- Maximum 20 years counts
+
+---
+
+WARNING: Take advice from an employment lawyer or qualified HR professional before beginning any redundancy process.
+
+## Example Trigger Phrases
+- "Help me structure a redundancy consultation"
+- "Draft an at-risk letter for [role]"
+- "What is the process for making someone redundant in the UK?"
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-legal",
+  "version": "1.0.0",
+  "description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists. Not a substitute for qualified legal advice.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["legal", "contract-review", "nda", "compliance", "gdpr", "legal-brief", "risk"]
+}
@@ -0,0 +1,107 @@
+---
+name: compliance-checklist
+description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
+---
+
+# Compliance Checklist Skill
+
+Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
+
+ALWAYS include this disclaimer at the start of every response:
+"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
+- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
+- **Organisation size** (startup / scaleup / mid-market / enterprise)
+- **Current maturity** (no compliance programme / some controls / formal programme)
+- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)
+
+## Output Structure
+
+### 1. Framework Overview
+
+**Framework:** [Name with version]
+**Applicable because:** [One sentence — why this framework applies to this organisation]
+**Typical timeline to readiness:** [From current maturity to certified/compliant]
+**Key stakeholders needed:** [Roles that must be involved]
+
+### 2. Scope Definition
+
+What is in scope for this checklist:
+- [Specific systems / processes / data types]
+
+What is NOT in scope (explicit exclusions):
+- [Specific exclusions]
+
+### 3. Control Categories
+
+For each category relevant to the framework:
+
+**[Category — e.g. "Access Control"]**
+
+| Control | Current State | Gap | Priority | Effort |
+|---|---|---|---|---|
+| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |
+
+### 4. Gap Analysis Summary
+
+| Priority | Count | Examples |
+|---|---|---|
+| Critical gaps (block certification) | N | [Top 3] |
+| High priority gaps | N | |
+| Medium priority gaps | N | |
+| Quick wins | N | |
+
+### 5. Quick Wins
+
+Controls that can be implemented in under 2 weeks with minimal resources:
+
+1. **[Control]** — [Specific action] — [Owner] — [Days to complete]
+
+### 6. Evidence Requirements
+
+For each control area, what documentation will be needed:
+
+| Control area | Evidence types | Where to source |
+|---|---|---|
+| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
+
+### 7. Implementation Roadmap
+
+Phase 1 (Weeks 1-4): Critical gaps and quick wins
+- [Specific deliverables]
+
+Phase 2 (Weeks 5-12): High-priority gaps
+- [Specific deliverables]
+
+Phase 3 (Weeks 13+): Medium priority and continuous improvement
+- [Specific deliverables]
+
+### 8. Ongoing Maintenance
+
+Once certified/compliant, what needs to continue:
+- [Review frequencies]
+- [Periodic testing requirements]
+- [Annual audit expectations]
+- [Staff training cadence]
+
+### 9. Common Pitfalls for This Framework
+
+2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
+
+## Quality Checks
+- [ ] Disclaimer included at start
+- [ ] Framework-specific controls (not generic)
+- [ ] Priorities align with organisation size and maturity
+- [ ] Quick wins clearly separated from complex implementations
+- [ ] Evidence requirements tied to specific controls
+
+## Example Trigger Phrases
+- "Create a GDPR compliance checklist for our SaaS"
+- "Generate a SOC 2 Type II readiness checklist"
+- "What do we need for ISO 27001 certification?"
+- "FCA compliance checklist for a fintech startup"
+- "HIPAA gap analysis for a healthtech scaleup"
@@ -0,0 +1,64 @@
+---
+name: contract-review
+description: "Review and summarise any contract or legal agreement. Use when asked to review a contract, check an agreement, flag legal risks, or summarise key clauses. Produces a structured review with key terms, flagged clauses, risk rating, and plain English summary. Not a substitute for qualified legal advice."
+---
+
+# Contract Review Skill
+
+This skill produces a structured contract review identifying key terms, unusual or high-risk clauses, and a plain English summary. Always include the disclaimer that this is not legal advice.
+
+## Required Inputs
+- **Contract text or description** (paste or describe)
+- **Reviewer role** (e.g. the party signing, their legal team, a business owner)
+- **Contract type** (e.g. SaaS agreement, employment contract, NDA, supplier contract)
+- **Key concerns** (optional — e.g. "focus on IP ownership and termination clauses")
+
+## Output Structure
+
+### 1. Contract Overview
+- **Type:** [Contract type]
+- **Parties:** [Party A and Party B]
+- **Effective date / duration:** [If stated]
+- **Governing law:** [Jurisdiction]
+- **Overall risk rating:** Green Low / Amber Medium / Red High
+
+### 2. Key Terms Summary
+
+| Term | Detail |
+|---|---|
+| Payment / fees | |
+| Term and renewal | |
+| Termination rights | |
+| Liability cap | |
+| IP ownership | |
+| Confidentiality | |
+| Dispute resolution | |
+
+### 3. Flagged Clauses
+
+For each flagged clause:
+
+**[Risk level] — [Clause name]**
+- **What it says:** [Plain English summary]
+- **Why it matters:** [Risk or implication]
+- **Suggested action:** [Negotiate / Accept / Seek legal advice / Query]
+
+### 4. Missing Clauses
+List any standard clauses absent but normally expected for this contract type.
+
+### 5. Plain English Summary
+3-5 sentences. What does this contract mean for the party signing it?
+
+### 6. Recommended Next Steps
+- [Action 1]
+- [Action 2]
+
+---
+
+WARNING: This review is for informational purposes only and does not constitute legal advice. Always consult a qualified solicitor or lawyer before signing any legally binding agreement.
+
+## Example Trigger Phrases
+- "Review this contract: [paste]"
+- "Flag the key risks in this agreement"
+- "Summarise this SaaS contract in plain English"
+- "What should I watch out for in this supplier agreement?"
@@ -0,0 +1,63 @@
+---
+name: legal-brief
+description: "Draft a structured legal brief, case summary, or legal argument outline. Use when asked to write a legal brief, case note, legal memo, argument outline, or position paper. Produces a structured document using IRAC format (Issue, Rule, Application, Conclusion)."
+---
+
+# Legal Brief Skill
+
+This skill drafts structured legal briefs and memos using IRAC format — the standard structure for legal writing.
+
+## Required Inputs
+- **Brief type** (legal memo / case summary / argument outline / position paper / letter before action)
+- **Legal issue or question**
+- **Jurisdiction** (England & Wales / US / EU / Other)
+- **Relevant facts**
+- **Relevant law or cases** (if known — otherwise flagged as [RESEARCH NEEDED])
+- **Audience** (internal memo / court submission / client letter)
+
+## Output Structure
+
+### Header
+- **To:** [Recipient]
+- **From:** [Author]
+- **Date:** [Date]
+- **Re:** [Matter reference]
+- **Confidential:** Subject to legal professional privilege
+
+### Issue(s)
+One sentence per legal question:
+- Issue 1: Whether X constitutes Y under [law]
+
+### Brief Answer
+One sentence per issue — conclusion upfront before analysis.
+
+### Facts
+Concise relevant facts only. Flag disputed facts.
+
+### Law (Rule)
+- Relevant statute, regulation, or case law
+- How the rule has been interpreted in key cases
+- Flag [RESEARCH NEEDED] where law is not provided
+
+### Application
+- Arguments in favour
+- Counter-arguments and responses
+- Areas of uncertainty flagged explicitly
+
+### Conclusion
+- Clear answer to each issue
+- Overall recommendation
+- Suggested next steps
+
+### Caveats
+What this memo does not cover. What additional research would change the analysis.
+
+---
+
+WARNING: This draft requires review by a qualified legal professional. It does not constitute legal advice.
+
+## Example Trigger Phrases
+- "Draft a legal memo on [issue]"
+- "Write a legal brief arguing [position]"
+- "Summarise the legal position on [topic]"
+- "Write a letter before action for [situation]"
@@ -0,0 +1,59 @@
+---
+name: nda-analyser
+description: "Analyse a Non-Disclosure Agreement (NDA) and flag key terms, unusual provisions, and negotiation points. Use when asked to review an NDA, mutual NDA, confidentiality agreement, or non-disclosure deed. Produces clause-by-clause analysis with risk flags and a negotiation checklist."
+---
+
+# NDA Analyser Skill
+
+NDAs are often treated as routine paperwork but contain terms with significant long-term consequences. This skill analyses them systematically.
+
+## Required Inputs
+- **NDA text** (paste in full or describe key clauses)
+- **Your party position** (disclosing / receiving / mutual)
+- **Purpose of the NDA** (e.g. pre-sales, hiring, M&A, partnership)
+- **Industry context** (optional)
+
+## Output Structure
+
+### 1. NDA Type and Parties
+- **Type:** Unilateral / Mutual
+- **Disclosing party:** [Name]
+- **Receiving party:** [Name]
+- **Purpose:** [As stated]
+- **Governing law:** [Jurisdiction]
+- **Term:** [Duration of obligations]
+
+### 2. Definition of Confidential Information
+- **How broadly defined?** Narrow / Standard / Very broad
+- **Oral disclosures included?** Yes / No / With conditions
+- **Standard exclusions present?** [public domain, prior knowledge, independently developed, legally required disclosure]
+- **Flag:** [Unusual inclusions or missing exclusions]
+
+### 3. Key Clause Analysis
+
+**[Clause name] — Concern / Watch / Standard**
+- **What it says:** [Plain English]
+- **Issue:** [Why flagged]
+- **Standard position:** [What this typically looks like]
+- **Negotiation suggestion:** [If applicable]
+
+Clauses always covered: permitted use, non-solicitation/non-compete, term and post-termination obligations, return/destruction of information, remedies, liability, residuals clause.
+
+### 4. Negotiation Checklist
+
+| Point | Current position | Suggested ask |
+|---|---|---|
+| [e.g. Confidentiality term] | [e.g. 5 years] | [e.g. Reduce to 2 years] |
+
+### 5. Plain English Verdict
+2-3 sentences. Standard NDA, one-sided, or needs a lawyer?
+
+---
+
+WARNING: This analysis is for informational purposes only and is not legal advice. Consult a qualified solicitor before signing.
+
+## Example Trigger Phrases
+- "Analyse this NDA"
+- "Review this confidentiality agreement"
+- "Is this NDA standard or unusual?"
+- "What should I negotiate in this mutual NDA?"
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-operations",
+  "version": "1.0.0",
+  "description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report. Document workflows, write audit-ready SOPs, evaluate vendors with weighted scorecards, and produce RAG status reports.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["operations", "process", "sop", "vendor", "procurement", "project-management", "rag-status"]
+}
@@ -0,0 +1,81 @@
+---
+name: process-documentation
+description: "Document any business process in a clear, structured format. Use when asked to document a process, write a process guide, create a workflow document, or map out how something works. Produces a complete process document with steps, roles, inputs, outputs, and edge cases."
+---
+
+# Process Documentation Skill
+
+Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions.
+
+## Required Inputs
+- **Process name**
+- **Process description** (rough notes are fine)
+- **Who does this process** (roles involved)
+- **How often it runs** (daily / weekly / monthly / event-triggered)
+- **Tools involved**
+- **Known edge cases**
+
+## Output Structure
+
+---
+
+# Process: [Process Name]
+**Owner:** [Role] | **Frequency:** [How often] | **Estimated time:** [Duration]
+
+---
+
+### Purpose
+[1-2 sentences. Why does this process exist? What breaks if it is not done?]
+
+### Scope
+**In scope:** [What this covers]
+**Out of scope:** [What it does not cover]
+
+### Prerequisites
+- [ ] [Required access or information]
+- [ ] [Any dependency that must be completed first]
+
+---
+
+### Roles and Responsibilities
+
+| Role | Responsibility |
+|---|---|
+| [Role 1] | [What they do] |
+
+---
+
+### Process Steps
+
+**Step 1: [Step name]**
+- **Who:** [Role]
+- **When:** [Trigger or timing]
+- **How:** [Substeps numbered]
+- **Output:** [What exists at end of this step]
+- **Tool:** [System used]
+
+[Continue for all steps]
+
+---
+
+### Edge Cases and Exceptions
+
+| Situation | What to do | Who to contact |
+|---|---|---|
+| [Edge case] | [Action] | [Name/role] |
+
+---
+
+### Common Mistakes
+[2-4 things people get wrong the first time]
+
+### Escalation Path
+[Name/role] → [Next level] → [Final escalation]
+
+### Review
+Next review due: [Date]
+
+## Example Trigger Phrases
+- "Document this process: [description]"
+- "Write a process guide for [workflow]"
+- "Map out how [process] works"
@@ -0,0 +1,109 @@
+---
+name: project-status-report
+description: "Write a structured project status report for any project. Use when asked to write a project update, status report, RAG report, project dashboard narrative, or weekly project communication. Produces a clear status report with RAG ratings, milestone progress, risks, and decisions needed."
+---
+
+# Project Status Report Skill
+
+Produces a clear, structured project status report — the weekly communication that keeps stakeholders informed without requiring a meeting.
+
+## Required Inputs
+- **Project name**
+- **Reporting period**
+- **Current RAG status** (Red / Amber / Green)
+- **Key milestones** (due, delivered, coming)
+- **Issues or blockers**
+- **Decisions needed from stakeholders**
+- **Budget status** (if tracked)
+- **Audience** (steering committee / sponsor / PMO / full team)
+
+## Output Structure
+
+---
+
+# Project Status Report: [Project Name]
+**Period:** [Date range] | **Author:** [PM] | **Next report:** [Date]
+
+---
+
+### Overall Status
+
+| Dimension | Status | Last period | Trend |
+|---|---|---|---|
+| Overall | Red / Amber / Green | [Last] | Improving / Stable / Declining |
+| Schedule | | | |
+| Budget | | | |
+| Scope | | | |
+| Risks | | | |
+
+RAG definitions:
+- Green: On track. No significant issues.
+- Amber: At risk. Issues identified but mitigations in place.
+- Red: Off track. Escalation or decisions required to recover.
+
+---
+
+### Executive Summary
+[3-5 sentences. Headline story. If it is Red, say so immediately and why. Never bury bad news after good news.]
+
+---
+
+### Milestone Progress
+
+| Milestone | Due date | Status | Comment |
+|---|---|---|---|
+| [Milestone] | [Date] | Complete / At risk / Delayed / On track | [One line] |
+
+**Completed this period:** [What was delivered]
+**Due next period:** [What is expected]
+
+---
+
+### Issues and Blockers
+
+**[Issue title] — Critical / High / Low**
+- **Description:** [What the issue is]
+- **Impact:** [What happens if unresolved]
+- **Owner:** [Who is resolving]
+- **Action:** [What is being done]
+- **Resolution date:** [When it will be closed]
+
+---
+
+### Risks
+
+| Risk | Likelihood | Impact | Mitigation | Owner |
+|---|---|---|---|---|
+| [Risk] | H/M/L | H/M/L | [Action] | [Name] |
+
+---
+
+### Decisions Required
+
+| Decision | Background | Options | Recommendation | Needed by |
+|---|---|---|---|---|
+| [Decision] | [Context] | [Options] | [Recommendation] | [Date] |
+
+---
+
+### Budget Summary
+
+| | Budget | Actual to date | Forecast | Variance |
+|---|---|---|---|---|
+| Total | £ | £ | £ | £ F/A |
+
+---
+
+### Next Period Plan
+[3-5 specific bullet points — what will happen next period]
+
+## Writing Rules
+- Never soften a Red status
+- Milestones are binary: complete or not complete
+- Decisions must be genuinely actionable
+- Keep to one page where possible
+
+## Example Trigger Phrases
+- "Write a project status report for [project]"
+- "Generate a RAG status update for [project]"
+- "Write the steering committee report for [project]"
@@ -0,0 +1,93 @@
+---
+name: sop-writer
+description: "Write a Standard Operating Procedure (SOP) for any operational task. Use when asked to write an SOP, standard operating procedure, work instruction, or operating manual. Produces a formal SOP with purpose, scope, procedure steps, quality checks, and version control."
+---
+
+# SOP Writer Skill
+
+Produces formal, audit-ready SOPs suitable for regulated industries, ISO certification, or operational scaling.
+
+## Required Inputs
+- **SOP title** (e.g. "SOP-001: New Client Onboarding")
+- **Department / function**
+- **Process description**
+- **Regulatory or quality standard** (ISO 9001, GMP, CQC, FCA, etc.)
+- **Roles involved**
+- **Tools or equipment used**
+
+## Output Structure
+
+---
+
+**[COMPANY NAME] — Standard Operating Procedure**
+
+| Document ID | [SOP-XXX] |
+|---|---|
+| Title | [Title] |
+| Department | [Department] |
+| Version | 1.0 |
+| Effective date | [Date] |
+| Review date | [Date] |
+| Status | Draft / Under review / Approved |
+
+---
+
+### 1. Purpose
+[1-2 sentences. Why does this SOP exist?]
+
+### 2. Scope
+**Applies to:** [Roles, departments, locations]
+**Does not apply to:** [Explicit exclusions]
+
+### 3. Definitions
+| Term | Definition |
+|---|---|
+| [Term] | [Plain English definition] |
+
+### 4. Responsibilities
+| Role | Responsibility |
+|---|---|
+| [Role] | [Specific responsibility] |
+
+### 5. Required Materials / Tools / Access
+- [Item]
+
+### 6. Procedure
+
+| Step | Action | Responsible | Record/Output |
+|---|---|---|---|
+| 6.1.1 | [Imperative action: "Open [system] and navigate to [location]"] | [Role] | [What to record] |
+
+NOTE: Steps must be written in imperative form. Each step must have one action only.
+
+### 7. Quality Checks
+
+| Check point | What to verify | Pass criteria | If fail |
+|---|---|---|---|
+| [After step X] | [What to check] | [What good looks like] | [What to do] |
+
+### 8. Non-Conformance
+1. [Immediate action]
+2. [Who to notify]
+3. [How to document deviation]
+
+### 9. References
+[Related SOPs, policies, standards]
+
+### 10. Document History
+
+| Version | Date | Author | Changes |
+|---|---|---|---|
+| 1.0 | [Date] | [Name] | Initial release |
+
+## Quality Checks
+- All steps in imperative form
+- Each step has exactly one action
+- Roles specified for every step
+- Quality checkpoints at critical stages
+- Non-conformance process defined
+
+## Example Trigger Phrases
+- "Write an SOP for [process]"
+- "Create a standard operating procedure for [task]"
+- "Write a work instruction for [process]"
@@ -0,0 +1,70 @@
+---
+name: vendor-evaluation
+description: "Create a structured vendor evaluation framework for any procurement decision. Use when asked to evaluate vendors, compare suppliers, run an RFP scoring process, or assess a software or service provider. Produces a weighted scorecard, evaluation criteria, and recommendation framework."
+---
+
+# Vendor Evaluation Skill
+
+Produces a structured vendor evaluation framework — from defining criteria through to a scored comparison and recommendation.
+
+## Required Inputs
+- **What you are procuring**
+- **Vendors being evaluated** (minimum 2)
+- **Key decision criteria** (if known)
+- **Decision makers**
+- **Budget range**
+- **Timeline to decide**
+
+## Output Structure
+
+### 1. Evaluation Criteria and Weights
+
+| Category | Weight | Rationale |
+|---|---|---|
+| Functional fit | [%] | Does it do what we need? |
+| Commercial terms | [%] | Price, flexibility, payment |
+| Implementation | [%] | How hard to get started? |
+| Support and SLA | [%] | What happens when things go wrong? |
+| Security and compliance | [%] | Meets regulatory requirements? |
+| Vendor stability | [%] | Will this company exist in 3 years? |
+| References | [%] | Who else uses this? |
+
+Weights must total 100%.
+
+### 2. Scoring Rubric
+- 5: Exceeds requirements — clear best-in-class
+- 4: Meets requirements — fully satisfies with minor gaps
+- 3: Partially meets — notable gaps requiring workarounds
+- 2: Significant gaps — would require workarounds
+- 1: Does not meet — cannot satisfy requirement
+
+### 3. Vendor Scorecard
+
+| Criterion | Weight | [Vendor A] | Weighted | [Vendor B] | Weighted | [Vendor C] | Weighted |
+|---|---|---|---|---|---|---|---|
+| Functional fit | [%] | /5 | | /5 | | /5 | |
+| [Continue...] | | | | | | | |
+| **Total** | 100% | | **/5** | | **/5** | | **/5** |
+
+### 4. Key Questions for Every Vendor
+Functional: Walk through [most critical use case]. What can your product not do that customers ask for?
+Commercial: What is included vs add-ons? Contract minimum term and notice period? Price protection at renewal?
+Implementation: Typical implementation for our size? What do you need from our team?
+Support: SLA for critical issues? Support included vs charged extra?
+Security: ISO 27001 / SOC 2 certified? Where is data stored? Breach notification process?
+
+### 5. Reference Check Questions
+- How long using [vendor]? Implementation surprises? Support responsiveness? One thing you wish you had known? Would you choose them again?
+
+### 6. Recommendation
+
+**Recommended vendor:** [Name] | **Score:** [X/5]
+**Rationale:** [Specific strengths that matter for this decision]
+**Key risks:** [Risk and mitigation]
+**Conditions:** [Contract terms to negotiate before signing]
+**Runner-up:** [Vendor and why they lost]
+
+## Example Trigger Phrases
+- "Help me evaluate vendors for [procurement]"
+- "Create a vendor scorecard for [software/service]"
+- "Compare [Vendor A] vs [Vendor B] for [use case]"
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-research",
+  "version": "1.0.0",
+  "description": "Research and healthcare skills: Clinical Case Summary, Research Protocol, Patient Communication, Literature Review. Write SBAR handovers, design research protocols, draft accessible patient communications, and structure literature reviews.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["research", "healthcare", "clinical", "patient", "literature-review", "protocol", "academic"]
+}
@@ -0,0 +1,83 @@
+---
+name: clinical-case-summary
+description: "Write a structured clinical case summary or case presentation. Use when asked to write a clinical case summary, case presentation, patient case report, or clinical handover. Produces a structured summary using SBAR or SOAP format. For educational and documentation purposes only — not a substitute for clinical judgement."
+---
+
+# Clinical Case Summary Skill
+
+Produces structured clinical case summaries for educational, documentation, and handover purposes.
+
+WARNING: For documentation and educational purposes only. All clinical content must be reviewed by a qualified healthcare professional. This is not clinical advice.
+
+## Required Inputs
+- **Purpose** (case presentation / handover / case report / educational / MDT summary)
+- **Patient details** (anonymised — age, sex, relevant background)
+- **Presenting complaint and history**
+- **Examination findings**
+- **Investigations and results**
+- **Diagnosis or differential diagnoses**
+- **Management and treatment**
+- **Outcome** (if known)
+- **Format preference** (SBAR / SOAP / Standard clinical / Narrative)
+
+---
+
+## Format A: SBAR (Handover / Referral)
+
+**S — Situation**
+[Patient identifier anonymised, location, reason for contact in one sentence]
+
+**B — Background**
+- Age / sex / relevant past medical history
+- Current admission details
+- Relevant medications and allergies
+- Brief relevant social history
+
+**A — Assessment**
+- Current clinical status
+- Vital signs if relevant
+- Key examination findings
+- Working diagnosis or differential
+- Recent investigations and results
+
+**R — Recommendation**
+- What you need from the recipient
+- Urgency level
+- Immediate actions already taken
+- Questions or concerns
+
+---
+
+## Format B: SOAP Note
+
+**S — Subjective**
+[Presenting complaint in patient words. Symptom history: onset, duration, character, severity, associated symptoms, relieving/aggravating factors]
+
+**O — Objective**
+- Vital signs: [BP, HR, RR, Temp, O2 sats]
+- Examination: [Systematic findings]
+- Investigations: [Results with reference ranges]
+
+**A — Assessment**
+- Primary diagnosis: [With brief rationale]
+- Differential diagnoses: [Ranked with reasoning]
+
+**P — Plan**
+- Immediate management
+- Investigations ordered
+- Treatments initiated with dose, route, frequency
+- Referrals
+- Safety netting: what to watch for, when to escalate
+- Follow-up plan
+
+## Quality Checks
+- Patient details fully anonymised
+- Allergies and medications included in handover formats
+- Safety netting included in SOAP plan
+- Disclaimer included
+
+## Example Trigger Phrases
+- "Write a clinical handover using SBAR for this patient"
+- "Summarise this case in SOAP format"
+- "Write a case report for [clinical scenario]"
+- "Prepare an MDT summary for this patient"
@@ -0,0 +1,71 @@
+---
+name: literature-review
+description: "Structure and write a literature review for any research topic. Use when asked to write a literature review, systematic review summary, narrative review, or research background section. Produces a structured review with thematic organisation, critical analysis, and gap identification."
+---
+
+# Literature Review Skill
+
+Structures and writes literature reviews — from background sections of a dissertation through to standalone narrative reviews for publication.
+
+## Required Inputs
+- **Topic or research question**
+- **Type of review** (narrative / systematic / scoping / integrative / background section)
+- **Sources provided** (paste references, abstracts, or key findings)
+- **Word count target**
+- **Audience** (academic journal / thesis / grant proposal / policy brief)
+- **Time period to cover**
+
+## Output Structure
+
+### 1. Search Strategy Summary (for systematic/scoping reviews)
+**Databases:** [PubMed, EMBASE, PsycINFO, etc.]
+**Search terms:** [Key terms and Boolean combinations]
+**Inclusion criteria:** Study types, population, date range, language
+**Exclusion criteria:** [List]
+**Results:** [n] identified → [n] after deduplication → [n] screened → [n] included
+
+### 2. Literature Review Body
+
+Organised thematically — not chronologically. Each theme = one section.
+
+**Structure per thematic section:**
+
+**[Theme heading]**
+
+[Opening: state what this section covers and what evidence shows overall]
+
+[Evidence synthesis: present what multiple studies found, compare and contrast. Do NOT summarise one paper then the next — synthesise across them: "Three studies found X (Smith, 2019; Jones, 2020; Lee, 2021), while two found Y, with the difference attributable to..."]
+
+[Critical analysis: note methodological strengths and weaknesses — sample sizes, study designs, generalisability, risk of bias]
+
+[Closing: transition to next theme]
+
+### 3. Synthesis Table (systematic/scoping reviews)
+
+| Author, year | Study design | Population | n | Key findings | Quality/Limitations |
+|---|---|---|---|---|---|
+
+### 4. Gap Analysis
+
+**Well-established:** [What literature consistently shows]
+**Contested:** [Areas where evidence is mixed and why]
+**Missing:** [Gaps the field needs to address]
+**How your study addresses the gap:** [If this is for a research proposal]
+
+### 5. Conclusion Paragraph
+[3-5 sentences. Current state of knowledge and what is needed next]
+
+## Critical Analysis Framework
+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
+
+## Example Trigger Phrases
+- "Write a literature review on [topic]"
+- "Synthesise the evidence on [topic] from these papers: [paste]"
+- "Write the background section for my research proposal on [topic]"
@@ -0,0 +1,89 @@
+---
+name: patient-communication
+description: "Write clear, plain English patient communications for any healthcare context. Use when asked to write a patient letter, patient information leaflet, appointment letter, test results letter, discharge summary for patients, or health education content. Targets accessible reading level with clear next steps."
+---
+
+# Patient Communication Skill
+
+Writes patient-facing healthcare communications in plain, accessible language — targeting UK Grade 6 / US Grade 8 reading level.
+
+WARNING: All patient communications must be reviewed and approved by a qualified healthcare professional before sending. This skill produces drafts only.
+
+## Required Inputs
+- **Communication type** (appointment letter / results letter / discharge info / patient leaflet / consent info / health education)
+- **Clinical context**
+- **Key messages** (what the patient must understand and do)
+- **Tone** (reassuring / informative / urgent)
+- **Specific instructions or next steps**
+- **Contact details for queries**
+
+## Output Structure
+
+### Type A: Patient Letter
+
+[Date]
+
+Dear [Patient name],
+
+**Re: [Clear subject line in bold]**
+
+[Opening paragraph: State clearly what this letter is about. No preamble.]
+
+[Main content — short paragraphs, 2-3 sentences each. Bullet points for instructions. Bold anything the patient must do or remember.]
+
+**What happens next:**
+- [Action 1 — specific with timeframe]
+- [Action 2]
+
+**If you have questions:**
+Contact us at [phone] between [hours] or email [address].
+
+If you feel unwell before your appointment, please [specific instruction].
+
+Yours sincerely, [Name, Title, Department]
+
+---
+
+### Type B: Patient Information Leaflet
+
+**[Plain language title]**
+
+**What is [topic]?** [2-3 plain English sentences. Explain technical terms immediately.]
+
+**Why has this been recommended for me?** [Personalised clinical reason in patient terms]
+
+**What will happen?** [Numbered step by step]
+
+**What are the benefits?** [Honest statement]
+
+**What are the risks?** [Common first, then rare but serious. Use frequencies: "About 1 in 10 people..." not "10% incidence"]
+
+**What should I do to prepare?** [Specific instructions]
+
+**When should I contact someone?** [Specific signs — not vague. "Temperature above 38C" not "if you feel unwell"]
+
+---
+
+### Type C: Test Results Letter
+
+**Your [test name] results — [Normal / Abnormal] — stated in the FIRST sentence, never paragraph 3.**
+
+[What this means in plain English]
+
+**What happens next:** [Clear next steps. If no action, say so explicitly.]
+
+---
+
+## Plain Language Rules (apply to all types)
+- Maximum 2 syllables per word where possible
+- Maximum 20 words per sentence
+- Active voice: "We will contact you" not "You will be contacted"
+- Spell out all acronyms on first use
+- No Latin: "twice daily" not "bd"
+- Use "you" and "we" throughout
+- Numbers as digits: "2 tablets" not "two tablets"
+
+## Example Trigger Phrases
+- "Write a patient letter about [topic]"
+- "Create a patient information leaflet for [procedure]"
+- "Write a plain English results letter for [test]"
@@ -0,0 +1,97 @@
+---
+name: research-protocol
+description: "Write a structured research protocol or study design document. Use when asked to write a research protocol, study protocol, research plan, methodology section, or research proposal. Produces a complete protocol with objectives, methodology, ethical considerations, and analysis plan."
+---
+
+# Research Protocol Skill
+
+Produces structured research protocols for academic, clinical, social science, or market research studies.
+
+## Required Inputs
+- **Research type** (clinical trial / observational / qualitative / systematic review / survey)
+- **Research question or hypothesis**
+- **Setting and population**
+- **Proposed methodology**
+- **Timeline**
+- **Funder or institution** (if applicable)
+
+## Output Structure
+
+---
+
+# Research Protocol: [Study Title]
+**Version:** 1.0 | **Date:** [Date] | **PI:** [Name, institution]
+
+---
+
+### 1. Background and Rationale
+- What is already known
+- What the gap in knowledge is
+- Why this study is needed now
+
+### 2. Research Objectives
+**Primary:** [One clear answerable question or hypothesis]
+**Secondary:** [Additional questions]
+
+### 3. Study Design
+- **Design:** [RCT / cohort / qualitative / mixed methods]
+- **Setting:** [Where]
+- **Duration:** [Total period and recruitment window]
+- **Rationale:** [Why this design fits the question]
+
+### 4. Participants
+
+**Inclusion criteria:** [List]
+**Exclusion criteria:** [List]
+**Sample size:** [n] — Basis: [Power calculation or saturation rationale]
+**Recruitment:** [Method and source]
+
+### 5. Methodology / Intervention
+
+For interventional: intervention description, control, randomisation, blinding
+For observational/qualitative: data collection methods, tools, data collectors
+
+### 6. Outcomes / Measures
+**Primary outcome:** [Measure], assessed by [method], at [timepoint]
+**Secondary outcomes:** [Measure], [method], [timepoint]
+
+### 7. Data Management
+- Storage: [Where and anonymisation method]
+- Access controls: [Who can access]
+- Retention: [How long]
+
+### 8. Analysis Plan
+Quantitative: [Statistical test], [missing data handling], [software]
+Qualitative: [Framework — e.g. Braun & Clarke], [quality assurance]
+
+### 9. Ethical Considerations
+- Ethics approval: [Body / reference]
+- Informed consent: [Process]
+- Confidentiality: [How maintained]
+- Risk to participants: [Assessment and mitigation]
+
+### 10. Dissemination Plan
+- Target journals: [2-3 relevant]
+- Conference presentations
+- Public/patient summary
+
+### 11. Timeline
+
+| Phase | Activities | Start | End |
+|---|---|---|---|
+| Setup | Ethics, approvals, tool development | | |
+| Recruitment | | | |
+| Data collection | | | |
+| Analysis | | | |
+| Write-up | | | |
+
+## Quality Checks
+- Primary objective is singular and answerable
+- Sample size has stated basis
+- Ethical considerations complete
+- Analysis plan pre-specified
+
+## Example Trigger Phrases
+- "Write a research protocol for [study]"
+- "Help me design a study to investigate [question]"
+- "Write the methodology for my research proposal"
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-sales",
+  "version": "1.0.0",
+  "description": "Sales skills: Sales Battlecard, Discovery Call Prep, Proposal Writer, Account Plan. Build competitive battlecards, prepare structured discovery calls, write winning proposals, and create strategic account plans.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["sales", "battlecard", "discovery", "proposal", "account-plan", "competitive", "crm"]
+}
@@ -0,0 +1,94 @@
+---
+name: account-plan
+description: "Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan."
+---
+
+# Account Plan Skill
+
+Produces a structured account plan — the document that separates account managers who grow accounts from those who just service them.
+
+## Required Inputs
+- **Account name**
+- **Current ARR / revenue**
+- **Contract renewal date**
+- **Key contacts** (names, roles, relationship strength)
+- **Products/services currently in use**
+- **Known opportunities or expansion areas**
+- **Known risks**
+- **Planning horizon** (6 / 12 / 24 months)
+
+## Output Structure
+
+---
+
+# Account Plan: [Account Name]
+**Account Manager:** [Name] | **Period:** [Date range]
+
+---
+
+### Account Snapshot
+
+| Metric | Current | Target (EOY) |
+|---|---|---|
+| ARR / Revenue | £[amount] | £[target] |
+| NPS / Health score | [Score] | [Target] |
+| Products in use | [List] | [Expansion targets] |
+| Renewal date | [Date] | — |
+| Risk level | Low / Medium / High | — |
+
+---
+
+### Relationship Map
+
+| Name | Title | Influence | Relationship | Notes |
+|---|---|---|---|---|
+| [Name] | [Role] | Decision maker / Influencer / User | Strong / Neutral / Weak | [Insight] |
+
+**Relationship gaps:** [Who we do not have access to that we should]
+**Executive sponsor:** [Do we have one? If not — who could become one?]
+
+---
+
+### Why They Stay (Retention Anchors)
+[2-3 specific reasons this account renews. If the list is short, that is the risk signal.]
+
+---
+
+### Growth Opportunities
+
+| Opportunity | Product | Est. Value | Timeline | Next Action |
+|---|---|---|---|---|
+| [Opportunity] | [Product] | £[value] | [Q/Year] | [Specific action] |
+
+**Whitespace:** What products do we have that this account does not use, and why?
+
+---
+
+### Risks and Mitigation
+
+| Risk | Likelihood | Impact | Mitigation | Owner |
+|---|---|---|---|---|
+| [Risk] | H/M/L | H/M/L | [Action] | [Name] |
+
+---
+
+### 90-Day Action Plan
+
+| Action | Why | Owner | Due |
+|---|---|---|---|
+| [Specific action] | [Why it matters] | [Name] | [Date] |
+
+**Next QBR / EBR:** [Date — if no EBR cadence, flag as a risk]
+
+---
+
+### Success Criteria
+At end of [period]:
+- Renewed at or above current ARR
+- [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]"
@@ -0,0 +1,97 @@
+---
+name: discovery-call-prep
+description: "Prepare a structured discovery call plan for any prospect. Use when asked to prepare for a sales call, discovery call, prospect meeting, or first call with a potential customer. Produces a call brief with research, hypotheses, questions, and success criteria."
+---
+
+# Discovery Call Prep Skill
+
+Produces a complete discovery call brief — research summary, call hypothesis, structured questions, and success criteria — so every call starts with context and ends with a clear next step.
+
+## Required Inputs
+- **Prospect company name**
+- **Contact name and role**
+- **Any known context** (how they found you, prior interaction)
+- **Your product/solution** (one line)
+- **Call duration** (15 / 30 / 45 / 60 min)
+
+## Output Structure
+
+---
+
+# Discovery Call Brief
+**Prospect:** [Company] | **Contact:** [Name, Title] | **Duration:** [X min]
+
+---
+
+### Research Summary
+- What they do: [Product/service, customer, business model]
+- Size: [Headcount, revenue if public]
+- Stage: [Startup / Scaleup / Enterprise]
+- Recent news: [Funding, launches, leadership changes — last 90 days]
+- Contact background: [Role tenure, previous companies, LinkedIn activity]
+- Likely priorities for someone in this role: [Based on title and stage]
+
+---
+
+### Call Hypothesis
+Before the call write your best guess:
+- **Their most likely pain:** [What someone in this role at this company probably has]
+- **Why they would care about us:** [Specific connection to your value]
+- **Biggest risk to the deal:** [What might make this not a fit]
+
+Write it down — then test it on the call.
+
+---
+
+### Call Agenda
+"Here is what I was thinking for our [X] minutes:
+- 2 min: Quick intros
+- [X] min: Learn more about your situation
+- [X] min: Share how we have helped similar companies
+- 5 min: Next steps
+Does that work? Anything specific you would like to cover?"
+
+---
+
+### Discovery Questions
+
+Open with context (not a pitch):
+- "What prompted you to take this call today?"
+- "What does [relevant area] look like for you at the moment?"
+
+Go deeper on pain:
+- "How long has [problem] been an issue?"
+- "What have you tried to solve it?"
+- "What is the impact of not solving this?"
+
+Understand buying context:
+- "Who else would be involved in a decision like this?"
+- "Have you looked at other solutions?"
+- "Is there a reason you are exploring this now?"
+
+Qualify on budget:
+- "Have you set aside budget for this kind of initiative?"
+
+Close discovery:
+- "Based on what you have told me, it sounds like [summary]. Is that right?"
+
+---
+
+### Success Criteria
+This call is successful if we leave with:
+- Understanding of specific pain and business impact
+- Knowledge of buying process and key stakeholders
+- A clear agreed next step (demo / proposal / intro)
+- Sense of timeline
+
+This call is NOT successful if we only pitched and got "sounds interesting, send me some info."
+
+---
+
+### Suggested Next Step
+"Based on what we discussed, the logical next step would be [specific]. Does [day/time] work?"
+
+## Example Trigger Phrases
+- "Prepare me for a discovery call with [company/contact]"
+- "Build a call brief for my meeting with [name] at [company]"
+- "What questions should I ask in a discovery call for [use case]?"
@@ -0,0 +1,92 @@
+---
+name: proposal-writer
+description: "Write a structured sales proposal or commercial proposal for any deal. Use when asked to write a proposal, sales proposal, commercial proposal, statement of work, or quote document. Produces a complete proposal with problem statement, solution, investment, and next steps."
+---
+
+# Proposal Writer Skill
+
+Writes commercial proposals that win business — structured around the prospect problem, not the product.
+
+## Required Inputs
+- **Prospect company and contact**
+- **Their problem or goal** (from discovery — be specific)
+- **Your proposed solution**
+- **Commercial terms** (pricing, payment terms, contract length)
+- **Timeline**
+- **Key stakeholders** who will read this
+- **Tone** (formal / conversational / technical)
+
+## Output Structure
+
+---
+
+# Proposal: [Brief description of what you are solving]
+**Prepared for:** [Contact, Title] | [Company]
+**Prepared by:** [Name] | [Your Company]
+**Date:** [Date] | **Valid until:** [Date]
+
+---
+
+### Understanding Your Situation
+[2-3 paragraphs. Demonstrate you listened. Describe their situation, problem, and impact of not solving it in their words. This section should make them think "yes, exactly." Generic boilerplate here = proposal goes in the bin.]
+
+**The key challenge:** [One sentence — the core problem]
+**The impact:** [What this costs them]
+**What you have tried:** [Acknowledge prior attempts]
+
+---
+
+### Our Proposed Approach
+
+**What we will do** (3-5 deliverables or phases)
+
+**Phase 1: [Name]** (Timeline: [Weeks 1-2])
+[What happens, what is delivered, what customer input is needed]
+
+**Phase 2: [Name]** (Timeline: [Weeks 3-6])
+
+**What you will get** (outcomes, not features)
+- [Outcome 1]
+- [Outcome 2]
+
+**What success looks like**
+[How both parties know this worked]
+
+---
+
+### Why [Your Company]
+[3-4 sentences. Specific to their situation. Reference similar customers. Generic "why us" sections are skipped.]
+
+---
+
+### Investment
+
+| Item | Description | Investment |
+|---|---|---|
+| [Component 1] | [Description] | £[amount] |
+| **Total** | | **£[total]** |
+
+**Payment terms:** [Terms]
+**Included:** [What is in]
+**Not included:** [What is out — prevents scope disputes]
+
+---
+
+### Timeline
+| Milestone | Date |
+|---|---|
+| Contract signed | [Date] |
+| Kickoff | [Date] |
+| Delivery | [Date] |
+
+---
+
+### Next Steps
+1. [Sign / reply / schedule] by [date]
+2. We will send contract and confirm kickoff
+3. [Any immediate action]
+
+## Example Trigger Phrases
+- "Write a proposal for [prospect] to [solve their problem]"
+- "Draft a statement of work for [project]"
+- "Turn my discovery notes into a proposal"
@@ -0,0 +1,79 @@
+---
+name: sales-battlecard
+description: "Create a competitive sales battlecard for any competitor. Use when asked to build a battlecard, competitive comparison, sales cheat sheet, or objection handling guide for a specific competitor. Produces a one-page battlecard with positioning, differentiators, objection responses, and landmines."
+---
+
+# Sales Battlecard Skill
+
+Produces a practical one-page competitive battlecard that sales reps can use in calls — not a theoretical analysis.
+
+## Required Inputs
+- **Your product/company**
+- **Competitor name**
+- **Your target customer** (ICP)
+- **Your top 3 differentiators** vs this competitor
+- **Common objections** when competing against them
+- **Known competitor weaknesses**
+
+## Output Structure
+
+---
+
+# Battlecard: [Your Product] vs [Competitor]
+Updated: [Date] — Review quarterly
+
+---
+
+### In One Sentence
+When a prospect mentions [Competitor], say: "[Your positioning in one sentence]"
+
+---
+
+### Why Customers Choose [Competitor]
+(Be honest about their genuine strengths)
+- [Strength 1]
+- [Strength 2]
+
+---
+
+### Why Customers Choose Us
+(Specific differentiators with proof points)
+- **[Differentiator 1]:** [Proof point — customer outcome or capability]
+- **[Differentiator 2]:** [Proof point]
+
+---
+
+### Objection Responses
+
+**"[Competitor] is cheaper"**
+"You are right their list price is lower. What our customers find is [specific TCO difference]. [Customer] saw [result]. Should we explore total cost of ownership?"
+
+**"We already use [Competitor]"**
+"That is helpful. What is working well? [Listen] And what is one thing you wish was better?"
+
+**"[Competitor] has [feature] you do not"**
+"You are right. What problem are you solving with that feature? [Listen] Here is how our customers solve that..."
+
+---
+
+### Landmines to Plant
+- "How do you currently handle [area where competitor is weak]?"
+- "What happens when you need to [scenario competitor struggles with]?"
+
+---
+
+### Traps to Avoid
+- Never badmouth [Competitor] directly
+- Do not lead with features — lead with the prospect problem
+- Do not claim you do everything better — be specific about where you win
+
+---
+
+### When We Win / When We Lose
+We win when: [Scenario — e.g. customer prioritises outcome over price]
+We lose when: [Honest scenario — e.g. primary driver is lowest upfront cost]
+
+## Example Trigger Phrases
+- "Build a battlecard against [competitor]"
+- "Create a competitive cheat sheet for [competitor]"
+- "Write objection handling for [competitor] comparisons"
@@ -0,0 +1,94 @@
+---
+name: account-plan
+description: "Build a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan."
+---
+
+# Account Plan Skill
+
+Produces a structured account plan — the document that separates account managers who grow accounts from those who just service them.
+
+## Required Inputs
+- **Account name**
+- **Current ARR / revenue**
+- **Contract renewal date**
+- **Key contacts** (names, roles, relationship strength)
+- **Products/services currently in use**
+- **Known opportunities or expansion areas**
+- **Known risks**
+- **Planning horizon** (6 / 12 / 24 months)
+
+## Output Structure
+
+---
+
+# Account Plan: [Account Name]
+**Account Manager:** [Name] | **Period:** [Date range]
+
+---
+
+### Account Snapshot
+
+| Metric | Current | Target (EOY) |
+|---|---|---|
+| ARR / Revenue | £[amount] | £[target] |
+| NPS / Health score | [Score] | [Target] |
+| Products in use | [List] | [Expansion targets] |
+| Renewal date | [Date] | — |
+| Risk level | Low / Medium / High | — |
+
+---
+
+### Relationship Map
+
+| Name | Title | Influence | Relationship | Notes |
+|---|---|---|---|---|
+| [Name] | [Role] | Decision maker / Influencer / User | Strong / Neutral / Weak | [Insight] |
+
+**Relationship gaps:** [Who we do not have access to that we should]
+**Executive sponsor:** [Do we have one? If not — who could become one?]
+
+---
+
+### Why They Stay (Retention Anchors)
+[2-3 specific reasons this account renews. If the list is short, that is the risk signal.]
+
+---
+
+### Growth Opportunities
+
+| Opportunity | Product | Est. Value | Timeline | Next Action |
+|---|---|---|---|---|
+| [Opportunity] | [Product] | £[value] | [Q/Year] | [Specific action] |
+
+**Whitespace:** What products do we have that this account does not use, and why?
+
+---
+
+### Risks and Mitigation
+
+| Risk | Likelihood | Impact | Mitigation | Owner |
+|---|---|---|---|---|
+| [Risk] | H/M/L | H/M/L | [Action] | [Name] |
+
+---
+
+### 90-Day Action Plan
+
+| Action | Why | Owner | Due |
+|---|---|---|---|
+| [Specific action] | [Why it matters] | [Name] | [Date] |
+
+**Next QBR / EBR:** [Date — if no EBR cadence, flag as a risk]
+
+---
+
+### Success Criteria
+At end of [period]:
+- Renewed at or above current ARR
+- [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]"
@@ -0,0 +1,60 @@
+---
+name: budget-variance-analysis
+description: "Produce a structured budget variance analysis from actual vs budget figures. Use when asked to analyse budget variances, explain underspend or overspend, write a variance commentary, or investigate why actuals differ from plan. Produces a categorised variance table with root cause analysis and management commentary."
+---
+
+# Budget Variance Analysis Skill
+
+Produces a complete variance analysis from numbers through to root cause explanation and management commentary.
+
+## Required Inputs
+- **Actuals and budget figures** (paste as table or describe line by line)
+- **Period** (month / quarter / YTD)
+- **Materiality threshold** (e.g. £10k or 5%)
+- **Known reasons for variances** (if any)
+- **Audience** (CFO / board / management / auditor)
+
+## Output Structure
+
+### 1. Variance Summary Table
+
+| Line Item | Budget | Actual | Variance £ | Variance % | F/A |
+|---|---|---|---|---|---|
+| Revenue | | | | | |
+| Cost of Sales | | | | | |
+| Gross Profit | | | | | |
+| Opex | | | | | |
+| EBITDA | | | | | |
+
+F = Favourable | A = Adverse
+
+### 2. Material Variance Commentary
+
+For each variance above threshold:
+
+**[Line item] — £[amount] F/A ([%])**
+- **Root cause:** [Specific explanation — not "timing" without detail]
+- **Permanent or timing?** Will this reverse next period?
+- **Management action:** What is being done
+- **Forecast impact:** Does this change full-year outlook?
+
+### 3. Top 3 Variances Requiring Attention
+Ranked by materiality and strategic significance.
+
+### 4. Forecast Revision
+Does the full-year forecast need updating? State revised expectation and key assumptions.
+
+### 5. Executive Summary
+3-4 sentences of management commentary suitable for a board pack.
+
+## Quality Checks
+- All variances above threshold explained
+- Root causes specific (not vague)
+- Favourable/Adverse correctly labelled
+- Forecast impact stated for material variances
+
+## Example Trigger Phrases
+- "Write a variance analysis for these actuals vs budget: [paste]"
+- "Explain why we are over budget on [cost line]"
+- "Write the variance commentary for our finance review"
+- "Produce a budget vs actual analysis for Q[N]"
@@ -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,83 @@
+---
+name: clinical-case-summary
+description: "Write a structured clinical case summary or case presentation. Use when asked to write a clinical case summary, case presentation, patient case report, or clinical handover. Produces a structured summary using SBAR or SOAP format. For educational and documentation purposes only — not a substitute for clinical judgement."
+---
+
+# Clinical Case Summary Skill
+
+Produces structured clinical case summaries for educational, documentation, and handover purposes.
+
+WARNING: For documentation and educational purposes only. All clinical content must be reviewed by a qualified healthcare professional. This is not clinical advice.
+
+## Required Inputs
+- **Purpose** (case presentation / handover / case report / educational / MDT summary)
+- **Patient details** (anonymised — age, sex, relevant background)
+- **Presenting complaint and history**
+- **Examination findings**
+- **Investigations and results**
+- **Diagnosis or differential diagnoses**
+- **Management and treatment**
+- **Outcome** (if known)
+- **Format preference** (SBAR / SOAP / Standard clinical / Narrative)
+
+---
+
+## Format A: SBAR (Handover / Referral)
+
+**S — Situation**
+[Patient identifier anonymised, location, reason for contact in one sentence]
+
+**B — Background**
+- Age / sex / relevant past medical history
+- Current admission details
+- Relevant medications and allergies
+- Brief relevant social history
+
+**A — Assessment**
+- Current clinical status
+- Vital signs if relevant
+- Key examination findings
+- Working diagnosis or differential
+- Recent investigations and results
+
+**R — Recommendation**
+- What you need from the recipient
+- Urgency level
+- Immediate actions already taken
+- Questions or concerns
+
+---
+
+## Format B: SOAP Note
+
+**S — Subjective**
+[Presenting complaint in patient words. Symptom history: onset, duration, character, severity, associated symptoms, relieving/aggravating factors]
+
+**O — Objective**
+- Vital signs: [BP, HR, RR, Temp, O2 sats]
+- Examination: [Systematic findings]
+- Investigations: [Results with reference ranges]
+
+**A — Assessment**
+- Primary diagnosis: [With brief rationale]
+- Differential diagnoses: [Ranked with reasoning]
+
+**P — Plan**
+- Immediate management
+- Investigations ordered
+- Treatments initiated with dose, route, frequency
+- Referrals
+- Safety netting: what to watch for, when to escalate
+- Follow-up plan
+
+## Quality Checks
+- Patient details fully anonymised
+- Allergies and medications included in handover formats
+- Safety netting included in SOAP plan
+- Disclaimer included
+
+## Example Trigger Phrases
+- "Write a clinical handover using SBAR for this patient"
+- "Summarise this case in SOAP format"
+- "Write a case report for [clinical scenario]"
+- "Prepare an MDT summary for this patient"
@@ -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,107 @@
+---
+name: compliance-checklist
+description: "Generate a prioritised compliance checklist for GDPR, SOC 2, ISO 27001, FCA, HIPAA, or other frameworks with a gap analysis. Use when asked for a compliance checklist, gap analysis, readiness assessment, or audit preparation for any regulatory framework. Produces a structured checklist with prioritised gaps, quick wins, and evidence requirements. Optimised for Opus 4.7 and newer models. Not a substitute for legal or compliance professional advice."
+---
+
+# Compliance Checklist Skill
+
+Produces a prioritised compliance checklist for any regulatory framework — with gap analysis, evidence requirements, and quick wins identified.
+
+ALWAYS include this disclaimer at the start of every response:
+"WARNING: This checklist is for informational and planning purposes only and does not constitute legal or compliance advice. Regulatory requirements change and vary by jurisdiction. Always engage a qualified compliance professional or solicitor before implementing compliance programmes or making regulatory claims."
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Framework** (GDPR / SOC 2 Type I or II / ISO 27001 / FCA / HIPAA / PCI DSS / other)
+- **Organisation type** (SaaS / fintech / healthcare / professional services / retail)
+- **Organisation size** (startup / scaleup / mid-market / enterprise)
+- **Current maturity** (no compliance programme / some controls / formal programme)
+- **Deadline or driver** (upcoming audit / customer requirement / regulatory change / proactive)
+
+## Output Structure
+
+### 1. Framework Overview
+
+**Framework:** [Name with version]
+**Applicable because:** [One sentence — why this framework applies to this organisation]
+**Typical timeline to readiness:** [From current maturity to certified/compliant]
+**Key stakeholders needed:** [Roles that must be involved]
+
+### 2. Scope Definition
+
+What is in scope for this checklist:
+- [Specific systems / processes / data types]
+
+What is NOT in scope (explicit exclusions):
+- [Specific exclusions]
+
+### 3. Control Categories
+
+For each category relevant to the framework:
+
+**[Category — e.g. "Access Control"]**
+
+| Control | Current State | Gap | Priority | Effort |
+|---|---|---|---|---|
+| [Specific control requirement] | Not implemented / Partial / Full | [What is missing] | High/Med/Low | Days/Weeks/Months |
+
+### 4. Gap Analysis Summary
+
+| Priority | Count | Examples |
+|---|---|---|
+| Critical gaps (block certification) | N | [Top 3] |
+| High priority gaps | N | |
+| Medium priority gaps | N | |
+| Quick wins | N | |
+
+### 5. Quick Wins
+
+Controls that can be implemented in under 2 weeks with minimal resources:
+
+1. **[Control]** — [Specific action] — [Owner] — [Days to complete]
+
+### 6. Evidence Requirements
+
+For each control area, what documentation will be needed:
+
+| Control area | Evidence types | Where to source |
+|---|---|---|
+| [Area] | [Policies, logs, screenshots, training records] | [System or team] |
+
+### 7. Implementation Roadmap
+
+Phase 1 (Weeks 1-4): Critical gaps and quick wins
+- [Specific deliverables]
+
+Phase 2 (Weeks 5-12): High-priority gaps
+- [Specific deliverables]
+
+Phase 3 (Weeks 13+): Medium priority and continuous improvement
+- [Specific deliverables]
+
+### 8. Ongoing Maintenance
+
+Once certified/compliant, what needs to continue:
+- [Review frequencies]
+- [Periodic testing requirements]
+- [Annual audit expectations]
+- [Staff training cadence]
+
+### 9. Common Pitfalls for This Framework
+
+2-3 specific traps organisations commonly fall into when pursuing this certification — flagged based on the stated maturity level.
+
+## Quality Checks
+- [ ] Disclaimer included at start
+- [ ] Framework-specific controls (not generic)
+- [ ] Priorities align with organisation size and maturity
+- [ ] Quick wins clearly separated from complex implementations
+- [ ] Evidence requirements tied to specific controls
+
+## Example Trigger Phrases
+- "Create a GDPR compliance checklist for our SaaS"
+- "Generate a SOC 2 Type II readiness checklist"
+- "What do we need for ISO 27001 certification?"
+- "FCA compliance checklist for a fintech startup"
+- "HIPAA gap analysis for a healthtech scaleup"
@@ -0,0 +1,64 @@
+---
+name: contract-review
+description: "Review and summarise any contract or legal agreement. Use when asked to review a contract, check an agreement, flag legal risks, or summarise key clauses. Produces a structured review with key terms, flagged clauses, risk rating, and plain English summary. Not a substitute for qualified legal advice."
+---
+
+# Contract Review Skill
+
+This skill produces a structured contract review identifying key terms, unusual or high-risk clauses, and a plain English summary. Always include the disclaimer that this is not legal advice.
+
+## Required Inputs
+- **Contract text or description** (paste or describe)
+- **Reviewer role** (e.g. the party signing, their legal team, a business owner)
+- **Contract type** (e.g. SaaS agreement, employment contract, NDA, supplier contract)
+- **Key concerns** (optional — e.g. "focus on IP ownership and termination clauses")
+
+## Output Structure
+
+### 1. Contract Overview
+- **Type:** [Contract type]
+- **Parties:** [Party A and Party B]
+- **Effective date / duration:** [If stated]
+- **Governing law:** [Jurisdiction]
+- **Overall risk rating:** Green Low / Amber Medium / Red High
+
+### 2. Key Terms Summary
+
+| Term | Detail |
+|---|---|
+| Payment / fees | |
+| Term and renewal | |
+| Termination rights | |
+| Liability cap | |
+| IP ownership | |
+| Confidentiality | |
+| Dispute resolution | |
+
+### 3. Flagged Clauses
+
+For each flagged clause:
+
+**[Risk level] — [Clause name]**
+- **What it says:** [Plain English summary]
+- **Why it matters:** [Risk or implication]
+- **Suggested action:** [Negotiate / Accept / Seek legal advice / Query]
+
+### 4. Missing Clauses
+List any standard clauses absent but normally expected for this contract type.
+
+### 5. Plain English Summary
+3-5 sentences. What does this contract mean for the party signing it?
+
+### 6. Recommended Next Steps
+- [Action 1]
+- [Action 2]
+
+---
+
+WARNING: This review is for informational purposes only and does not constitute legal advice. Always consult a qualified solicitor or lawyer before signing any legally binding agreement.
+
+## Example Trigger Phrases
+- "Review this contract: [paste]"
+- "Flag the key risks in this agreement"
+- "Summarise this SaaS contract in plain English"
+- "What should I watch out for in this supplier agreement?"
@@ -0,0 +1,97 @@
+---
+name: discovery-call-prep
+description: "Prepare a structured discovery call plan for any prospect. Use when asked to prepare for a sales call, discovery call, prospect meeting, or first call with a potential customer. Produces a call brief with research, hypotheses, questions, and success criteria."
+---
+
+# Discovery Call Prep Skill
+
+Produces a complete discovery call brief — research summary, call hypothesis, structured questions, and success criteria — so every call starts with context and ends with a clear next step.
+
+## Required Inputs
+- **Prospect company name**
+- **Contact name and role**
+- **Any known context** (how they found you, prior interaction)
+- **Your product/solution** (one line)
+- **Call duration** (15 / 30 / 45 / 60 min)
+
+## Output Structure
+
+---
+
+# Discovery Call Brief
+**Prospect:** [Company] | **Contact:** [Name, Title] | **Duration:** [X min]
+
+---
+
+### Research Summary
+- What they do: [Product/service, customer, business model]
+- Size: [Headcount, revenue if public]
+- Stage: [Startup / Scaleup / Enterprise]
+- Recent news: [Funding, launches, leadership changes — last 90 days]
+- Contact background: [Role tenure, previous companies, LinkedIn activity]
+- Likely priorities for someone in this role: [Based on title and stage]
+
+---
+
+### Call Hypothesis
+Before the call write your best guess:
+- **Their most likely pain:** [What someone in this role at this company probably has]
+- **Why they would care about us:** [Specific connection to your value]
+- **Biggest risk to the deal:** [What might make this not a fit]
+
+Write it down — then test it on the call.
+
+---
+
+### Call Agenda
+"Here is what I was thinking for our [X] minutes:
+- 2 min: Quick intros
+- [X] min: Learn more about your situation
+- [X] min: Share how we have helped similar companies
+- 5 min: Next steps
+Does that work? Anything specific you would like to cover?"
+
+---
+
+### Discovery Questions
+
+Open with context (not a pitch):
+- "What prompted you to take this call today?"
+- "What does [relevant area] look like for you at the moment?"
+
+Go deeper on pain:
+- "How long has [problem] been an issue?"
+- "What have you tried to solve it?"
+- "What is the impact of not solving this?"
+
+Understand buying context:
+- "Who else would be involved in a decision like this?"
+- "Have you looked at other solutions?"
+- "Is there a reason you are exploring this now?"
+
+Qualify on budget:
+- "Have you set aside budget for this kind of initiative?"
+
+Close discovery:
+- "Based on what you have told me, it sounds like [summary]. Is that right?"
+
+---
+
+### Success Criteria
+This call is successful if we leave with:
+- Understanding of specific pain and business impact
+- Knowledge of buying process and key stakeholders
+- A clear agreed next step (demo / proposal / intro)
+- Sense of timeline
+
+This call is NOT successful if we only pitched and got "sounds interesting, send me some info."
+
+---
+
+### Suggested Next Step
+"Based on what we discussed, the logical next step would be [specific]. Does [day/time] work?"
+
+## Example Trigger Phrases
+- "Prepare me for a discovery call with [company/contact]"
+- "Build a call brief for my meeting with [name] at [company]"
+- "What questions should I ask in a discovery call for [use case]?"
@@ -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,86 @@
+---
+name: employee-engagement-survey
+description: "Design an employee engagement survey and analyse results. Use when asked to create an employee survey, engagement questionnaire, pulse survey, or eNPS survey. Also use when asked to analyse survey results. Produces a complete survey with questions, rating scales, and an analysis framework."
+---
+
+# Employee Engagement Survey Skill
+
+Designs complete employee engagement surveys and provides a framework for analysing and acting on results.
+
+## Mode Detection
+- User provides survey results -> Analysis mode
+- User wants to create a survey -> Design mode
+
+---
+
+## Design Mode
+
+### Required Inputs
+- Survey type (annual / quarterly pulse / post-onboarding / exit / specific topic)
+- Company size and stage
+- Key areas of concern (optional)
+- Anonymity approach
+- Length target (short: 5-10 / standard: 15-25 / comprehensive: 30+)
+
+### Opening Statement (always include)
+"This survey is anonymous. Your responses help us understand what is working and what to improve. Results will be shared with [who] and we will communicate actions taken by [date]."
+
+### Core Questions
+
+**Overall Engagement**
+1. On a scale of 0-10, how likely are you to recommend [Company] as a great place to work? (eNPS)
+2. I feel proud to work at [Company]. [1-5]
+3. I intend to still be working here in 12 months. [1-5]
+
+**Role and Clarity**
+4. I understand how my work contributes to company goals. [1-5]
+5. I have the tools and resources I need to do my job. [1-5]
+6. My workload is manageable. [1-5]
+
+**Manager and Team**
+7. My manager gives useful feedback. [1-5]
+8. My manager cares about my development. [1-5]
+9. I feel part of a team that works well together. [1-5]
+
+**Culture and Belonging**
+10. I feel I can be myself at work. [1-5]
+11. People treat each other with respect. [1-5]
+12. [Company] lives by its stated values. [1-5]
+
+**Growth and Recognition**
+13. I have opportunities to grow and develop. [1-5]
+14. My contributions are recognised. [1-5]
+15. I have had a meaningful career conversation in the last 6 months. [Yes/No]
+
+**Open questions (always include)**
+- What is one thing [Company] should start doing?
+- What is one thing [Company] should stop doing?
+- Anything else to share?
+
+---
+
+## Analysis Mode
+
+### Analysis Output
+
+**1. Headline Scores**
+| Metric | Score | Benchmark | Trend |
+|---|---|---|---|
+| eNPS | [-100 to +100] | Industry avg | vs last survey |
+
+eNPS: Below 0 = Concerning / 0-30 = Good / 30-70 = Great / 70+ = Excellent
+
+**2. Strengths** — Top scoring areas with evidence.
+
+**3. Improvement Areas** — 3 lowest scoring areas with verbatim comment themes.
+
+**4. Action Planning Template**
+| Improvement area | Action | Owner | Timeline | Measure |
+|---|---|---|---|---|
+
+**5. Communication Template** — Draft message to share results with employees.
+
+## Example Trigger Phrases
+- "Create an employee engagement survey for our team"
+- "Design a pulse survey for [topic]"
+- "Analyse these engagement survey results: [paste]"
@@ -0,0 +1,98 @@
+---
+name: executive-summary
+description: "Write an executive summary for any document, report, or proposal. Use when asked to write an executive summary, management summary, briefing paper, or one-pager for senior stakeholders. Produces a structured summary that busy executives can read in under 3 minutes and act on."
+---
+
+# Executive Summary Skill
+
+Writes executive summaries that busy decision-makers actually read — front-loaded with conclusions, structured for skimming, ruthless about what to include.
+
+## Required Inputs
+- **Source document or topic** (paste or describe)
+- **Audience** (CEO / board / investor / minister / client / committee)
+- **Decision or action needed** (what should the reader do after reading?)
+- **Length limit** (1 page / 2 pages / 500 words)
+- **Format** (formal report / slide / email / briefing paper)
+
+## Core Principle
+
+An executive summary is NOT a summary of the document. It is a standalone document that:
+- States the conclusion upfront — not at the end
+- Contains only what the reader needs to make a decision
+- Can be understood without reading anything else
+- Recommends a specific action
+
+## Output Structure
+
+---
+
+### [Title]
+**Executive Summary**
+*Prepared for: [Audience] | Date: [Date] | Author: [Name]*
+
+---
+
+**Bottom line up front:**
+[The most important thing. The recommendation or finding. 2-3 sentences. A reader who only reads this should know what you are asking or telling them.]
+
+---
+
+**Background (why this matters):**
+[2-3 sentences. Minimum context to understand the bottom line. Not the history — just what the reader needs now.]
+
+---
+
+**Key findings / analysis:**
+- **[Finding 1]:** [One sentence — specific and evidence-based]
+- **[Finding 2]:** [One sentence]
+- **[Finding 3]:** [One sentence]
+
+---
+
+**Options considered:** (include only if a decision is being presented)
+
+| Option | Benefit | Risk | Recommendation |
+|---|---|---|---|
+| [Option A] | [Benefit] | [Risk] | Recommended |
+| [Option B] | [Benefit] | [Risk] | Not recommended |
+
+---
+
+**Recommendation:**
+[Specific. "We recommend [action] because [reason]. This will [outcome]." Not "we suggest consideration of options."]
+
+---
+
+**Immediate next steps:**
+- [Action 1 — specific, with owner and date]
+- [Action 2]
+
+---
+
+**Risks of inaction:** [What happens if the reader does nothing]
+
+**Full report:** [Reference to where the full document can be found]
+
+---
+
+## Adapting for Different Audiences
+
+**CEO/MD:** Lead with financial or strategic impact. 1 page. Make the decision binary. Ask in sentence one.
+**Board:** Lead with governance or risk. Frame against organisational objectives. State specifically what you need from them.
+**Investor:** Lead with return or opportunity. Specific numbers. 1 page. Anticipate "why now."
+**Minister/senior public sector:** Lead with public benefit or policy alignment. Include cost-benefit framing.
+**Client:** Lead with their problem. Show you understand before presenting recommendation.
+
+## Quality Checks
+- Bottom line in first 3 sentences
+- Standalone — no need to read full document
+- Recommendation is specific
+- Fits length limit
+- Written for audience priorities not author priorities
+- Next steps have owners and dates
+
+## Example Trigger Phrases
+- "Write an executive summary of this report: [paste]"
+- "Summarise this document for the board: [paste]"
+- "Create a one-pager from this proposal for the CEO"
+- "Turn these findings into an exec summary"
@@ -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]?"
@@ -0,0 +1,76 @@
+---
+name: financial-due-diligence
+description: "Generate a financial due diligence checklist and analysis framework for any investment, acquisition, or partnership. Use when asked for a due diligence checklist, M&A financial review, investment analysis framework, or vendor financial assessment."
+---
+
+# Financial Due Diligence Skill
+
+Produces a structured financial due diligence framework — document request list and analytical questions — for any investment, acquisition, or significant commercial relationship.
+
+## Required Inputs
+- **Transaction type** (acquisition / investment / partnership / supplier / fundraise)
+- **Stage of diligence** (initial screening / full DD / confirmatory)
+- **Target company type** (startup / SME / listed / subsidiary)
+- **Key concerns** (optional — e.g. revenue recognition, customer concentration)
+
+## Output Structure
+
+### 1. Document Request List
+
+**Financial Statements**
+- Audited accounts for last 3 years
+- Management accounts for current year (monthly)
+- Board-approved budget and latest reforecast
+- 3-year financial model with assumptions
+
+**Revenue**
+- Revenue by customer (top 20, % of total)
+- Revenue by product/segment
+- Contracted vs recurring vs one-off breakdown
+- Churn and renewal data
+
+**Costs**
+- Cost of sales breakdown
+- Headcount by department with compensation detail
+- Top 10 supplier contracts
+
+**Cash and Debt**
+- Bank statements (12 months)
+- Debt schedule with covenants and maturity
+- Working capital analysis
+
+**Tax**
+- Last 3 years tax returns
+- Any open enquiries
+- R&D tax credit claims
+
+### 2. Key Analytical Questions
+
+**Revenue quality:** Is revenue growing organically? What % is truly recurring? Customer concentration risk?
+
+**Margin analysis:** Gross margin trend over 3 years? One-off items inflating EBITDA? Normalised EBITDA?
+
+**Cash conversion:** Does profit convert to cash? Cash conversion cycle? Working capital red flags?
+
+**Debt and liabilities:** Net debt position? Contingent liabilities? Covenant headroom?
+
+### 3. Red Flags Checklist
+- Revenue concentration over 30% in one customer
+- Declining gross margins without explanation
+- EBITDA-to-cash conversion below 70%
+- Auditor qualifications or emphasis of matter
+- Related party transactions not at arm length
+- Aggressive revenue recognition
+- Growing debtor days with no explanation
+
+### 4. Summary Output Template
+- Revenue quality: [Assessment]
+- Margin sustainability: [Assessment]
+- Cash generation: [Assessment]
+- Balance sheet risk: [Assessment]
+- Overall: Green Strong / Amber Acceptable / Red Material concerns
+
+## Example Trigger Phrases
+- "Give me a financial due diligence checklist for [company type]"
+- "What documents should I request for financial DD?"
+- "Build a DD framework for our Series A investment"
@@ -0,0 +1,62 @@
+---
+name: financial-model-narrative
+description: "Turn financial model outputs into a clear written narrative. Use when asked to write a financial narrative, explain a financial model, summarise a P&L, or translate spreadsheet numbers into a board-ready story. Produces an executive narrative with key insights, drivers, and forward-looking commentary."
+---
+
+# Financial Model Narrative Skill
+
+Turns financial model outputs into a clear, structured written narrative suitable for board packs, investor updates, or management reporting.
+
+## Required Inputs
+- **Financial data** (paste key figures: revenue, costs, margins, EBITDA, cash)
+- **Period covered** (month / quarter / annual / multi-year)
+- **Audience** (board / investors / management / bank / internal)
+- **Key message** (what is the headline story?)
+- **Actuals vs budget / prior period?** (comparison context)
+
+## Output Structure
+
+### 1. Headline Summary
+3-5 sentences. The financial story in plain English. Lead with the most important insight — not "revenue was X" but what that figure means.
+
+### 2. Revenue
+- Performance vs prior period / budget
+- Key drivers: what caused the movement
+- Risks or opportunities in the revenue line
+
+### 3. Costs and Margins
+- Gross margin: % and trend
+- Key cost movements and why
+- EBITDA performance and drivers
+- One-off items clearly flagged
+
+### 4. Cash and Balance Sheet
+- Cash position and movement
+- Runway (for startups)
+- Key working capital movements
+
+### 5. Variance Analysis
+For each significant variance:
+
+**[Line item] — Over/Under by [amount]**
+- **Cause:** [Plain English explanation]
+- **Permanent or temporary?** One-time / Structural
+- **Action being taken:** [If applicable]
+
+### 6. Forward-Looking Commentary
+- Expected next period
+- Key risks to forecast
+- Key opportunities
+- Any reforecast or guidance change
+
+## Writing Rules
+- Never just restate a number — always explain what it means
+- Flag variances over 10% automatically
+- Use past tense for actuals, conditional for forecast
+- One insight per paragraph
+
+## Example Trigger Phrases
+- "Write a financial narrative for these results: [paste numbers]"
+- "Turn this P&L into a board narrative"
+- "Write the finance section of our board pack"
+- "Explain these financial results in plain English"
@@ -0,0 +1,99 @@
+---
+name: grant-proposal
+description: "Write a structured grant proposal or funding application for any grant type. Use when asked to write a grant proposal, funding application, research grant, charitable grant, or innovation fund application. Produces a complete proposal with project summary, rationale, methodology, impact, and budget narrative."
+---
+
+# Grant Proposal Skill
+
+Produces structured grant proposals tailored to the funder priorities — the most common reason grants fail is writing about what you want to do rather than what the funder wants to fund.
+
+## Required Inputs
+- **Funder name and grant programme**
+- **Grant amount sought**
+- **Project description** (rough notes are fine)
+- **Your organisation** (type, track record, capacity)
+- **Funder stated priorities** (copy from their guidance — essential)
+- **Word or page limits**
+- **Deadline**
+
+## Output Structure
+
+---
+
+### Project Title
+[Informative and memorable. Should convey the problem being solved and the approach.]
+
+### 1. Project Summary / Abstract (200-300 words — written last, placed first)
+[What you will do, why it matters, who will benefit, measurable outcomes. Every sentence earns its place.]
+
+### 2. Problem Statement / Need
+- **The problem:** [Specific, evidenced — use data]
+- **Who is affected:** [Population, scale, geography]
+- **Current situation:** [What exists and why it is insufficient]
+- **Consequence of inaction:** [What happens if not funded]
+- **Why your organisation:** [Track record, relationships, expertise]
+
+Funder test: does this problem align with [funder] stated priorities? Make the connection explicit.
+
+### 3. Project Objectives
+3-5 SMART objectives:
+- **Objective 1:** [Specific, Measurable, Achievable, Relevant, Time-bound]
+
+### 4. Methodology / Approach
+
+**Phase 1: [Name]** (Months 1-X)
+[What will happen, who will do it, what is produced]
+
+**Key activities:**
+- [Activity — specific]
+
+**What makes this approach innovative or effective:** [Why this over alternatives]
+
+### 5. Impact and Outcomes
+
+| Level | Description | Measure |
+|---|---|---|
+| Output | [Tangible deliverable] | [How counted] |
+| Short-term outcome | [Immediate change] | [How measured] |
+| Medium-term outcome | [Behaviour change] | [How measured] |
+| Long-term impact | [Systemic change] | [How evidenced] |
+
+**Direct beneficiaries:** [Who and how many]
+**Sustainability:** [How work continues beyond grant period]
+
+### 6. Evaluation Plan
+- Who evaluates, how, when, what is measured, how findings are shared
+
+### 7. Budget Narrative
+
+| Budget line | Amount | Justification |
+|---|---|---|
+| Staff costs | £[amount] | [Role, % FTE, duration, salary] |
+| Travel | £[amount] | [Specific journeys named] |
+| Equipment | £[amount] | [Itemised] |
+| Indirect costs | £[amount] | [[X]% of direct — check policy] |
+| **Total** | **£[total]** | |
+
+**Value for money:** [Cost per beneficiary. What could not be done without this grant]
+
+### 8. Organisational Capacity
+[Track record of similar projects, governance, financial management. Name previous grants and outputs — be specific]
+
+### 9. Risk Register
+
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| [Risk] | H/M/L | H/M/L | [Specific mitigation] |
+
+---
+
+## Funder Alignment Check
+- Every section explicitly references funder stated priorities
+- Word limits respected
+- Budget aligns with eligible costs policy
+- Required attachments prepared
+
+## Example Trigger Phrases
+- "Write a grant proposal for [project] applying to [funder]"
+- "Help me write a funding application for [grant programme]"
+- "Turn these project notes into a grant proposal: [paste]"
@@ -0,0 +1,48 @@
+---
+name: investor-pitch-deck
+description: "Build the narrative and slide structure for an investor pitch deck. Use when asked to create a pitch deck, investor presentation, fundraising deck, or startup pitch. Produces a slide-by-slide structure with narrative beats, key messages, and what each slide must prove to an investor."
+---
+
+# Investor Pitch Deck Skill
+
+Builds the complete narrative and slide structure for an investor pitch deck — focused on what investors need to see, not what founders want to show.
+
+## Required Inputs
+- **Company name and one-line description**
+- **Stage** (Pre-seed / Seed / Series A / Series B)
+- **Ask** (how much raising and what for)
+- **Key metrics** (revenue, growth, users, retention)
+- **Target investors** (generalist / sector-specific / angels)
+- **Deck length** (10 / 12 / 15 slides)
+
+## Output Structure
+
+For each slide:
+- **What this slide must prove** (the investor question it answers)
+- **Content guidance** (specific, not generic)
+- **Common mistake to avoid**
+
+---
+
+**Slide 1: Cover** — Proves you can say what you do in one sentence.
+**Slide 2: Problem** — Proves the problem is real, painful, and large. Lead with the human problem, not market size.
+**Slide 3: Solution** — Proves your solution is meaningfully better. Focus on outcome, not features.
+**Slide 4: Product** — Proves this is real and works. Show the actual product.
+**Slide 5: Traction** — Proves people want this. Show retention and revenue, not signups.
+**Slide 6: Market** — Proves the market is large enough. Use bottoms-up TAM where possible.
+**Slide 7: Business Model** — Proves you understand unit economics. Include CAC and LTV.
+**Slide 8: Go-To-Market** — Proves you can acquire customers efficiently. Focus on what is actually working.
+**Slide 9: Competition** — Proves you understand the landscape. Never say "no competitors."
+**Slide 10: Team** — Proves this team can execute this opportunity. One sentence per person, specific.
+**Slide 11: Financials** — Proves you understand your business. Show assumptions, not just projections.
+**Slide 12: The Ask** — Proves you know exactly what you need. Specific use of funds and 18-month milestones.
+
+## Narrative Principles
+- Every slide answers one investor question
+- Investors decide go/no-go on slides 1-5 — front-load evidence
+- Keep to 10-12 slides for a first meeting
+
+## Example Trigger Phrases
+- "Build a pitch deck structure for [company]"
+- "Help me structure my Series A deck"
+- "What slides should my investor pitch have?"
@@ -0,0 +1,74 @@
+---
+name: job-description-writer
+description: "Write a clear, inclusive, and structured job description for any role. Use when asked to write a job description, job posting, JD, or job advert. Produces a complete JD with role summary, responsibilities, requirements, and inclusive language review."
+---
+
+# Job Description Writer Skill
+
+Writes complete, inclusive job descriptions that attract the right candidates and reduce bias in the hiring process.
+
+## Required Inputs
+- **Job title and level**
+- **Team and reporting line**
+- **Top 5 things this person will actually do**
+- **Must-have requirements** (be ruthless — only what is truly required)
+- **Nice-to-have requirements**
+- **Salary range** (JDs with salary ranges get 30% more applicants)
+- **Location and remote policy**
+- **Company description** (2-3 sentences)
+
+## Output Structure
+
+### [Job Title]
+**[Company] | [Location] | [Remote policy] | [Salary range]**
+
+**About [Company]**
+[2-3 sentences. Specific and honest — not marketing copy.]
+
+**The Role**
+[3-4 sentences. What this person will own, why the role exists now, what success looks like in year one.]
+
+**What You Will Do**
+[6-8 bullet points. Outcomes and responsibilities, not activities. Start each with an action verb. Most important first.]
+
+**What We Are Looking For**
+
+Must have (4-6 items only):
+- [Requirement]
+
+Nice to have (3-4 items):
+- [Nice to have]
+
+**What We Offer**
+[Compensation, benefits, development. Be specific.]
+
+**How to Apply**
+[Clear instructions. What to send, where, timeline.]
+
+---
+
+### Inclusive Language Review
+
+**Words to remove or replace:**
+
+| Original | Replace with | Why |
+|---|---|---|
+| "rockstar" | "experienced" | Gendered connotation |
+| "ninja" | "skilled" | Same issue |
+| "must have degree" | "relevant experience or qualification" | Excludes qualified non-graduates |
+
+**Requirement audit:**
+- Years of experience requirements flagged (screen out women and underrepresented groups disproportionately)
+- Any requirements potentially discriminating against protected characteristics
+
+## Quality Checks
+- Salary range included
+- Must-haves genuinely essential (6 items max)
+- Each responsibility starts with action verb
+- Inclusive language review completed
+- No years-of-experience requirements unless legally required
+
+## Example Trigger Phrases
+- "Write a job description for a [role]"
+- "Create an inclusive job posting for [role]"
+- "Review and rewrite this JD: [paste]"
@@ -0,0 +1,63 @@
+---
+name: legal-brief
+description: "Draft a structured legal brief, case summary, or legal argument outline. Use when asked to write a legal brief, case note, legal memo, argument outline, or position paper. Produces a structured document using IRAC format (Issue, Rule, Application, Conclusion)."
+---
+
+# Legal Brief Skill
+
+This skill drafts structured legal briefs and memos using IRAC format — the standard structure for legal writing.
+
+## Required Inputs
+- **Brief type** (legal memo / case summary / argument outline / position paper / letter before action)
+- **Legal issue or question**
+- **Jurisdiction** (England & Wales / US / EU / Other)
+- **Relevant facts**
+- **Relevant law or cases** (if known — otherwise flagged as [RESEARCH NEEDED])
+- **Audience** (internal memo / court submission / client letter)
+
+## Output Structure
+
+### Header
+- **To:** [Recipient]
+- **From:** [Author]
+- **Date:** [Date]
+- **Re:** [Matter reference]
+- **Confidential:** Subject to legal professional privilege
+
+### Issue(s)
+One sentence per legal question:
+- Issue 1: Whether X constitutes Y under [law]
+
+### Brief Answer
+One sentence per issue — conclusion upfront before analysis.
+
+### Facts
+Concise relevant facts only. Flag disputed facts.
+
+### Law (Rule)
+- Relevant statute, regulation, or case law
+- How the rule has been interpreted in key cases
+- Flag [RESEARCH NEEDED] where law is not provided
+
+### Application
+- Arguments in favour
+- Counter-arguments and responses
+- Areas of uncertainty flagged explicitly
+
+### Conclusion
+- Clear answer to each issue
+- Overall recommendation
+- Suggested next steps
+
+### Caveats
+What this memo does not cover. What additional research would change the analysis.
+
+---
+
+WARNING: This draft requires review by a qualified legal professional. It does not constitute legal advice.
+
+## Example Trigger Phrases
+- "Draft a legal memo on [issue]"
+- "Write a legal brief arguing [position]"
+- "Summarise the legal position on [topic]"
+- "Write a letter before action for [situation]"
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
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
mohitagw15856	27d8363f28	Update README.md	2026-04-05 17:29:18 +05:30
mohitagw15856	2e17d68eaa	feat: add 27 new skills across 7 professions — 80 skills, 21 plugins (v5.0.0)	2026-04-05 12:48:16 +01:00
mohitagw15856	380a1dde21	docs: add CODE_OF_CONDUCT and SECURITY policy	2026-04-02 10:37:30 +01:00