Compare commits
54 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 mohitagw15856
|
c0544fb76a | ||
 mohitagw15856
|
ce35e8c5c0 | ||
|
mohitagw15856
|
a7ee053aac | ||
|
mohitagw15856
|
5b3eb3ea53 | ||
|
mohitagw15856
|
44d211b934 | ||
|
mohitagw15856
|
35364c7512 | ||
|
mohitagw15856
|
513e1d3ce7 | ||
|
mohitagw15856
|
d7f6c2cd05 | ||
|
mohitagw15856
|
844e97f81f | ||
|
mohitagw15856
|
b6e0cbc31b | ||
|
mohitagw15856
|
f3b9d008fe | ||
|
mohitagw15856
|
93c5ab7d71 | ||
|
mohitagw15856
|
34b0f780e6 | ||
|
mohitagw15856
|
7dbf5a47a3 | ||
|
mohitagw15856
|
f9d075ce3d | ||
|
mohitagw15856
|
81bc090869 | ||
|
mohitagw15856
|
ff46498e46 | ||
|
mohitagw15856
|
31c45072ec | ||
|
mohitagw15856
|
d650957c6a | ||
|
mohitagw15856
|
4dac8817cf | ||
|
mohitagw15856
|
6deaa51bf6 | ||
|
mohitagw15856
|
06243650b9 | ||
|
mohitagw15856
|
69a319688f | ||
|
mohitagw15856
|
254e389593 | ||
|
mohitagw15856
|
f23c3a7e10 | ||
|
mohitagw15856
|
7db88b1a2d | ||
|
mohitagw15856
|
7720d236ce | ||
|
mohitagw15856
|
14d191cda0 | ||
|
mohitagw15856
|
fd5b9daa43 | ||
|
mohitagw15856
|
adb742a187 | ||
|
mohitagw15856
|
dd33b0d416 | ||
|
mohitagw15856
|
1fafb44dc2 | ||
|
mohitagw15856
|
27d8363f28 | ||
|
mohitagw15856
|
2e17d68eaa | ||
|
mohitagw15856
|
380a1dde21 | ||
|
mohitagw15856
|
e612ba45b1 | ||
|
mohitagw15856
|
fb235be09a | ||
|
mohitagw15856
|
f9b79a48b9 | ||
|
mohitagw15856
|
7ad6ec62fa | ||
|
mohitagw15856
|
c3efe0cdef | ||
|
mohitagw15856
|
e501288bfc | ||
|
mohitagw15856
|
093d0e0061 | ||
|
mohitagw15856
|
e49327205f | ||
|
mohitagw15856
|
6af3f21689 | ||
|
mohitagw15856
|
22c9e33861 | ||
|
mohitagw15856
|
8ac9266aec | ||
|
mohitagw15856
|
05a4af1c27 | ||
|
mohitagw15856
|
e9e9f08c96 | ||
|
mohitagw15856
|
d1b06591cb | ||
|
mohitagw15856
|
6113761ecb | ||
|
mohitagw15856
|
6b42687fde | ||
|
mohitagw15856
|
4f14c7cd7c | ||
|
mohitagw15856
|
96109f1cdd | ||
|
mohitagw15856
|
cbd22b57a6 |
@@ -0,0 +1,188 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "pm-claude-skills",
|
||||
"version": "7.0.0",
|
||||
"description": "106 Claude Skills across 15 professions — product management, engineering, legal, finance, HR, sales, design, Figma, operations, research, and more. Includes 6 new engineering skills: debugging, PR descriptions, system design, changelogs, test strategy, and runbooks.",
|
||||
"owner": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "pm-essentials",
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"name": "pm-discovery",
|
||||
"description": "Discovery & research skills: Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper. Structure user research from screener to synthesis.",
|
||||
"version": "3.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-discovery",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-planning",
|
||||
"description": "Planning & strategy skills: OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy, RICE + Impact Matrix, Roadmap Narrative.",
|
||||
"version": "3.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-planning",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-delivery",
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"name": "pm-analytics",
|
||||
"description": "Data & metrics skills: Data Analysis Standard, Retention Analysis, Product Health Analysis. Structure metric deep-dives, funnel analysis, cohort studies and churn investigations.",
|
||||
"version": "3.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-analytics",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-strategy",
|
||||
"description": "Strategy & stakeholder skills: Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative Generator, Executive Update, Ambiguity Resolver.",
|
||||
"version": "3.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-strategy",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-advanced",
|
||||
"description": "Advanced PM skills: AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief, Stakeholder Update. For senior PMs working on complex products.",
|
||||
"version": "3.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-advanced",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-rituals",
|
||||
"description": "Weekly PM ritual skill: PM Weekly Review. A 20-minute structured ritual covering metrics, shipping progress, insights, and next week's top 3 priorities.",
|
||||
"version": "3.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-rituals",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-gtm",
|
||||
"description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign, SEO Content Brief, Media Pitch. Build positioning statements, messaging pillars, feature lists, use cases, launch campaigns, SEO briefs, and journalist pitches.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-gtm",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-engineering",
|
||||
"description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer. 10 structured skills for engineering teams, SREs, and technical PMs.",
|
||||
"version": "2.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-engineering",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-data",
|
||||
"description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief, Chart Data Extractor. Build North Star metric trees, explain SQL, spec dashboards, and digitise chart images.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-data",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-people",
|
||||
"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.",
|
||||
"version": "1.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-people",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-design",
|
||||
"description": "Design & UX skills: UX Research Plan, Design Critique, Accessibility Audit. Create research plans with discussion guides, critique designs using JTBD and Gestalt principles, audit for WCAG 2.2 compliance.",
|
||||
"version": "1.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-design",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-business",
|
||||
"description": "Business & strategy skills: Investor Update, Board Deck Narrative, Job Application. Write investor updates investors actually read, structure board presentations, and tailor CVs with ATS optimisation.",
|
||||
"version": "1.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-business",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-legal",
|
||||
"description": "Legal skills: Contract Review, NDA Analyser, Legal Brief, Compliance Checklist. Flag risks in contracts and NDAs, draft legal memos in IRAC format, and generate GDPR, SOC 2, FCA and other compliance checklists.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-legal",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-finance",
|
||||
"description": "Finance skills: Financial Model Narrative, Budget Variance Analysis, Investor Pitch Deck, Financial Due Diligence, Tax Planning Checklist. Turn numbers into board-ready narratives, explain variances, structure pitch decks, generate DD checklists, and review year-end tax planning opportunities.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-finance",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-hr",
|
||||
"description": "HR skills: Job Description Writer, Onboarding Plan, Employee Engagement Survey, Redundancy Consultation, Change Management Plan. Write inclusive JDs, build 30/60/90-day plans, design engagement surveys, structure redundancy processes, and manage organisational change with stakeholder analysis and adoption metrics.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-hr",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-sales",
|
||||
"description": "Sales skills: Sales Battlecard, Discovery Call Prep, Proposal Writer, Account Plan, Sales Forecasting Model. Build competitive battlecards, prepare discovery calls, write winning proposals, create account plans, and build pipeline-based revenue forecasts with scenario analysis.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-sales",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-operations",
|
||||
"description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report, Workshop Facilitation Guide. Document workflows, write audit-ready SOPs, evaluate vendors, produce RAG status reports, and design facilitated workshops with activity instructions and facilitator moves.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-operations",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-research",
|
||||
"description": "Research and healthcare skills: Clinical Case Summary, Research Protocol, Patient Communication, Literature Review. Write SBAR handovers, design research protocols, draft accessible patient communications, and structure literature reviews.",
|
||||
"version": "1.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-research",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-cross",
|
||||
"description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary, Teaching Lesson Plan. Write journalist-ready press releases, structure grant applications, produce decision-ready executive summaries, and design complete lesson plans for any subject, audience, or setting.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-cross",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-figma",
|
||||
"description": "Figma skills for PMs and designers: Component Audit, Design Brief, Annotation Guide, Design Review, User Flow Planner, Variant Matrix, Spacing System, Prototype Plan, Design QA, PM Design Critique. Work smarter across the full Figma design lifecycle.",
|
||||
"version": "1.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-figma",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -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.
|
||||
+131
-164
@@ -1,197 +1,164 @@
|
||||
# Contributing to PM Claude Skills
|
||||
# Contributing to pm-claude-skills
|
||||
|
||||
Thank you for considering contributing to PM Claude Skills! This document provides guidelines for contributing.
|
||||
Thank you for wanting to contribute. This repo grows through community submissions — every profession added makes it more useful for everyone.
|
||||
|
||||
## Ways to Contribute
|
||||
|
||||
### 1. Report Bugs 🐛
|
||||
|
||||
If you find a bug in a Skill:
|
||||
|
||||
1. Check if the issue already exists in [Issues](https://github.com/mohitagw15856/pm-claude-skills/issues)
|
||||
2. If not, create a new issue using the Bug Report template
|
||||
3. Include:
|
||||
- Which Skill has the issue
|
||||
- What you expected to happen
|
||||
- What actually happened
|
||||
- Steps to reproduce
|
||||
- Your Claude version (Pro/Team/Enterprise)
|
||||
|
||||
### 2. Request Skills 💡
|
||||
|
||||
Have an idea for a new Skill?
|
||||
|
||||
1. Check [existing issues](https://github.com/mohitagw15856/pm-claude-skills/issues?q=is%3Aissue+label%3Aenhancement) to avoid duplicates
|
||||
2. Create a new issue using the Skill Request template
|
||||
3. Describe:
|
||||
- What PM task the Skill would help with
|
||||
- How you currently do this task
|
||||
- Time you spend on it
|
||||
- Example outputs
|
||||
|
||||
### 3. Improve Documentation 📚
|
||||
|
||||
Documentation improvements are always welcome:
|
||||
|
||||
- Fix typos or unclear instructions
|
||||
- Add examples
|
||||
- Improve installation guides
|
||||
- Share your use cases
|
||||
|
||||
### 4. Submit Skills 🎁
|
||||
|
||||
Want to contribute a Skill you've created?
|
||||
|
||||
**Requirements:**
|
||||
- Skill must be PM-related
|
||||
- Include complete SKILL.md with proper frontmatter
|
||||
- Provide examples of outputs
|
||||
- Must be tested and working
|
||||
- Include documentation
|
||||
|
||||
**Process:**
|
||||
1. Fork the repository
|
||||
2. Create a new branch: `git checkout -b skill/your-skill-name`
|
||||
3. Add your Skill to `skills/your-skill-name/`
|
||||
4. Update main README.md to list your Skill
|
||||
5. Submit a Pull Request
|
||||
|
||||
### 5. Improve Existing Skills 🔧
|
||||
|
||||
Found a way to make a Skill better?
|
||||
|
||||
1. Fork the repository
|
||||
2. Make your improvements
|
||||
3. Test thoroughly
|
||||
4. Submit a Pull Request with:
|
||||
- Clear description of changes
|
||||
- Why the change improves the Skill
|
||||
- Before/after examples if applicable
|
||||
|
||||
## Skill Contribution Guidelines
|
||||
|
||||
### Structure
|
||||
|
||||
Every Skill must follow this structure:
|
||||
|
||||
```
|
||||
skill-name/
|
||||
├── SKILL.md (required)
|
||||
└── [other resources as needed]
|
||||
```
|
||||
|
||||
### SKILL.md Format
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: skill-name
|
||||
description: Clear description of what the skill does and when to use it. This is critical - Claude uses this to decide when to trigger the skill.
|
||||
---
|
||||
|
||||
# Skill Name
|
||||
## What We're Looking For
|
||||
|
||||
[Detailed instructions for using the skill]
|
||||
Good skills have three things in common:
|
||||
|
||||
## Structure/Template
|
||||
1. **They solve a recurring workflow** — not a one-off task. If you do this thing more than once a week and it follows a consistent structure, it's probably a good skill candidate.
|
||||
2. **They have a clear trigger** — Claude needs to know when to activate the skill. The `description` in your frontmatter is what Claude reads to decide if your skill is relevant. Make it specific.
|
||||
3. **They produce structured, useful output** — the output should be something you'd actually use at work, not a generic response.
|
||||
|
||||
[The format/structure the skill should follow]
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
## How to Submit a Skill
|
||||
|
||||
[Best practices and tips]
|
||||
### Step 1: Fork the repo
|
||||
|
||||
## Examples
|
||||
Click **Fork** in the top right of the GitHub repo. This creates your own copy.
|
||||
|
||||
[Example outputs]
|
||||
```
|
||||
### Step 2: Clone your fork
|
||||
|
||||
### Quality Standards
|
||||
git clone https://github.com/YOUR_USERNAME/pm-claude-skills.git
|
||||
cd pm-claude-skills
|
||||
|
||||
Skills should:
|
||||
- ✅ Be well-documented and clear
|
||||
- ✅ Include concrete examples
|
||||
- ✅ Follow PM best practices
|
||||
- ✅ Save meaningful time (not trivial tasks)
|
||||
- ✅ Be tested and working
|
||||
- ✅ Be general enough for others to use
|
||||
- ❌ Not include proprietary company information
|
||||
- ❌ Not require external tools (unless clearly documented)
|
||||
|
||||
## Pull Request Process
|
||||
### Step 3: Create your skill folder
|
||||
|
||||
1. **Fork & Branch**
|
||||
```bash
|
||||
git clone https://github.com/mohitagw15856/pm-claude-skills.git
|
||||
cd pm-claude-skills
|
||||
git checkout -b feature/your-feature-name
|
||||
```
|
||||
Skills live in the `skills/` directory. Create a folder named after your skill using lowercase and hyphens:
|
||||
|
||||
2. **Make Changes**
|
||||
- Follow existing code style
|
||||
- Update documentation
|
||||
- Add examples
|
||||
mkdir skills/your-skill-name
|
||||
|
||||
3. **Test**
|
||||
- Test the Skill in Claude
|
||||
- Verify it works as expected
|
||||
- Check for edge cases
|
||||
|
||||
4. **Commit**
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Add: Brief description of changes"
|
||||
```
|
||||
**Naming rules:**
|
||||
- Lowercase only
|
||||
- Hyphens between words (no underscores, no spaces)
|
||||
- Descriptive but concise: `legal-contract-review` not `skill-for-reviewing-legal-contracts`
|
||||
|
||||
5. **Push & Create PR**
|
||||
```bash
|
||||
git push origin feature/your-feature-name
|
||||
```
|
||||
Then create a Pull Request on GitHub
|
||||
### Step 4: Create your SKILL.md
|
||||
|
||||
6. **PR Description Should Include:**
|
||||
- What changes you made
|
||||
- Why you made them
|
||||
- How to test them
|
||||
- Screenshots/examples (if applicable)
|
||||
Every skill needs exactly one file: `SKILL.md` (uppercase, `.md` extension).
|
||||
|
||||
## Code of Conduct
|
||||
**Minimum required structure:**
|
||||
|
||||
### Our Standards
|
||||
---
|
||||
name: your-skill-name
|
||||
description: "One sentence. Use when [trigger condition]. Produces [output description]."
|
||||
---
|
||||
|
||||
- Be respectful and inclusive
|
||||
- Welcome newcomers
|
||||
- Accept constructive criticism
|
||||
- Focus on what's best for the community
|
||||
- Show empathy towards others
|
||||
# Skill Title
|
||||
|
||||
### Unacceptable Behavior
|
||||
[Your skill instructions here]
|
||||
|
||||
- Harassment or discriminatory language
|
||||
- Trolling or insulting comments
|
||||
- Personal or political attacks
|
||||
- Publishing private information
|
||||
- Unprofessional conduct
|
||||
|
||||
### Enforcement
|
||||
**The description field is the most important part.** It's what Claude reads (~100 tokens) to decide if your skill is relevant. Write it like this:
|
||||
|
||||
Violations may result in:
|
||||
1. Warning
|
||||
2. Temporary ban
|
||||
3. Permanent ban
|
||||
✅ Good: `"Write structured incident postmortems. Use when asked for a postmortem, RCA, incident report, or P1/P2 review. Produces a blameless postmortem with timeline, root cause, impact, and action items."`
|
||||
|
||||
Report violations to: [mohit15856@gmail.com]
|
||||
❌ Too vague: `"Helps with incident reports."`
|
||||
|
||||
**Full recommended structure for a quality skill:**
|
||||
|
||||
---
|
||||
name: your-skill-name
|
||||
description: "..."
|
||||
---
|
||||
|
||||
# Skill Title
|
||||
|
||||
Brief description of what this skill does.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
What Claude should ask for if the user doesn't provide it.
|
||||
|
||||
## Output Structure
|
||||
|
||||
The exact format and sections Claude should produce.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
A checklist Claude runs before delivering output.
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Example phrase that would activate this skill"
|
||||
- "Another example"
|
||||
|
||||
|
||||
### Step 5: Test your skill locally
|
||||
|
||||
Before submitting:
|
||||
|
||||
1. Copy your skill folder to `~/.claude/skills/`
|
||||
2. Open Claude Code
|
||||
3. Try your example trigger phrases
|
||||
4. Verify the output matches what your SKILL.md describes
|
||||
5. Adjust and refine until it's working well
|
||||
|
||||
### Step 6: Commit and push
|
||||
|
||||
git add skills/your-skill-name/SKILL.md
|
||||
git commit -m "feat: add [skill-name] skill for [profession/use case]"
|
||||
git push origin main
|
||||
|
||||
|
||||
### Step 7: Open a Pull Request
|
||||
|
||||
Go to your fork on GitHub and click **"Compare & pull request"**.
|
||||
|
||||
In your PR description, include:
|
||||
- **What the skill does** (1–2 sentences)
|
||||
- **Who it's for** (profession or role)
|
||||
- **Why you built it** (what workflow pain does it solve?)
|
||||
- **Example output** (paste a sample or screenshot — helps with review)
|
||||
|
||||
---
|
||||
|
||||
## Review Process
|
||||
|
||||
- PRs are reviewed weekly (usually Fridays)
|
||||
- Feedback will be left as PR comments — usually requesting a description improvement or output structure refinement
|
||||
- Once approved, your skill is merged and added to the README
|
||||
- Your GitHub handle is added to the Contributors section
|
||||
|
||||
---
|
||||
|
||||
## What Gets Rejected
|
||||
|
||||
- Skills with vague descriptions that would trigger on too many unrelated tasks
|
||||
- Skills that just wrap a single simple prompt (a skill should have structure and logic)
|
||||
- Duplicate skills — check the existing skills list before submitting
|
||||
- Skills that require external API keys or services not everyone has access to (unless clearly documented)
|
||||
|
||||
---
|
||||
|
||||
## Skills Wishlist
|
||||
|
||||
These have been requested but not yet built. Pick one up if you have the expertise:
|
||||
|
||||
| Skill | Use case |
|
||||
|---|---|
|
||||
| `legal-contract-review` | Flag key clauses and risks in contracts |
|
||||
| `financial-model-narrative` | Turn spreadsheet outputs into 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 |
|
||||
| `grant-proposal` | Structure grant applications for nonprofits and researchers |
|
||||
| `sales-battlecard` | Competitive battlecards for sales teams |
|
||||
|
||||
Suggest a new skill: [Open an issue](../../issues/new) with the label `skill-request`.
|
||||
|
||||
---
|
||||
|
||||
## Questions?
|
||||
|
||||
- 💬 Start a [Discussion](https://github.com/mohitagw15856/pm-claude-skills/discussions)
|
||||
- ✉️ Email: [mohit15856@gmail.com]
|
||||
- 🐦 Twitter: [@yourhandle]
|
||||
Open a [Discussion](../../discussions) or raise an [Issue](../../issues). Happy to help you get a skill PR-ready.
|
||||
|
||||
## Recognition
|
||||
---
|
||||
|
||||
Contributors will be:
|
||||
- Listed in the project README
|
||||
- Credited in the Skill they contributed
|
||||
- Mentioned in release notes
|
||||
|
||||
Thank you for contributing! 🙏
|
||||
*Thank you for contributing. Every skill added here saves someone an hour they'd rather spend on something else.*
|
||||
|
||||
+1
-2
@@ -40,10 +40,9 @@ Get your first PM Skill working in 5 minutes.
|
||||
|
||||
Start a new conversation and try:
|
||||
|
||||
```
|
||||
Help me write a PRD for a mobile app feature
|
||||
that lets users save articles for later reading
|
||||
```
|
||||
|
||||
|
||||
Claude should automatically use the PRD Template Skill and create a structured PRD.
|
||||
|
||||
|
||||
@@ -1,266 +1,467 @@
|
||||
# Product Management Claude Skills
|
||||
# 🧠 Claude Skills Library — 106 Skills for Every Profession
|
||||
|
||||
**Transform your PM workflow with specialized Claude Skills for common product management tasks.**
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/releases)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills#-quick-install-2-minutes)
|
||||
[](LICENSE)
|
||||
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
|
||||
> **Save 8–10 hours per week across 15 professions. Install in 2 minutes. Now with 106 skills including 6 new engineering skills.**
|
||||
|
||||
A community-built library of Claude Skills covering product management, engineering, marketing, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, education, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
|
||||
|
||||
> 📖 **Background**: Built across a four-part Medium series:
|
||||
> - [Part 1 — How Skills changed my PM workflow](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
> - [Part 2 — The complete 12-skill toolkit](https://medium.com/@mohit15856/12-claude-skills-for-product-managers-the-complete-toolkit-with-skill-files-for-jira-figma-fcc73a4c1e58)
|
||||
> - [Part 3 — Building Skills the right way (official guide)](https://medium.com/@mohit15856/claude-skills-advanced-guide-what-3-months-of-daily-pm-use-actually-taught-me-18324d6ef7bc)
|
||||
> - [Part 4 — Advanced skills based on what top companies want](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
>
|
||||
> Product Management Skills for Claude AI — 18 skills across the full PM lifecycle. Save 10+ hours per week.
|
||||
|
||||
|
||||
## What Are These Skills?
|
||||
|
||||
Claude Skills are reusable, specialized procedures that teach Claude your exact workflows. Instead of re-explaining your PRD format or meeting notes structure every time, you create a Skill once and Claude automatically applies it whenever relevant.
|
||||
|
||||
Think of Skills as "onboarding guides" for Claude—they package your best practices, templates, and processes so Claude consistently delivers outputs the way you want them.
|
||||
|
||||
## 🎯 Who Is This For?
|
||||
|
||||
- **Product Managers** looking to automate repetitive documentation tasks
|
||||
- **PM Teams** wanting to standardize processes and share best practices
|
||||
- **Anyone** tired of reformatting Claude's outputs to match their standards
|
||||
|
||||
## ⚡ Quick Start (5 Minutes)
|
||||
|
||||
1. **Prerequisites**: You need Claude Pro, Team, or Enterprise account
|
||||
2. **Enable Code Execution**: Settings → Features → Enable "Code Execution and File Creation"
|
||||
3. **Install Your First Skill**:
|
||||
- Download the [`prd-template`](skills/prd-template) folder
|
||||
- Zip the folder (it should contain SKILL.md and any other files)
|
||||
- Rename the .zip to .skill (e.g., `prd-template.skill`)
|
||||
- Go to claude.ai → Settings → Skills → Upload Skill
|
||||
- Try it: "Help me write a PRD for a mobile app onboarding feature"
|
||||
|
||||
That's it! Claude now knows your PRD format.
|
||||
|
||||
## 📦 Available Skills
|
||||
|
||||
### Free Essential Skills (Included)
|
||||
|
||||
| Skill | Purpose | Time Saved | Folder |
|
||||
|-------|---------|------------|--------|
|
||||
| **PRD Template** | Standardized product requirements | 2-3 hrs/PRD | [View](skills/prd-template) |
|
||||
| **Meeting Notes** | Structured meeting documentation | 15-30 min/meeting | [View](skills/meeting-notes) |
|
||||
| **Stakeholder Update** | Executive status updates | 30-45 min/update | [View](skills/stakeholder-update) |
|
||||
| **User Research Synthesis** | Analyze and synthesize research findings | 2-3 hrs/study | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | 1-2 hrs/analysis | [View](skills/competitive-analysis) |
|
||||
|
||||
### Discovery & User Research
|
||||
| **User Interview Synthesis** | Synthesise transcripts into structured findings | Notion | [View](skills/user-interview-synthesis) |
|
||||
| **Assumption Mapper** | Risk-rate hidden assumptions in any PRD | Miro | [View](skills/assumption-mapper) |
|
||||
|
||||
### Roadmapping & Prioritisation
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **RICE Prioritisation** | Score and rank initiatives objectively | Jira | [View](skills/rice-prioritisation) |
|
||||
| **Roadmap Narrative** | Turn ranked lists into strategic narratives | Notion, Miro | [View](skills/roadmap-narrative) |
|
||||
| **RICE + Impact Matrix** | RICE scoring + strategic alignment combined | Miro, Jira | [View](skills/rice-impact-matrix) |
|
||||
|
||||
### Sprint & Delivery
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Sprint Brief** | Generate sprint briefs from Jira data | Jira, Slack | [View](skills/sprint-brief) |
|
||||
| **Retro Analysis** | Data-grounded retrospective briefs | Jira, Miro | [View](skills/retro-analysis) |
|
||||
|
||||
### Data & Metrics
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Product Health Analysis** | Interpret metrics and surface signals | Analytics | [View](skills/product-health-analysis) |
|
||||
|
||||
### Strategy & Competitive Intel
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Competitor Signal Tracker** | Analyse competitor moves strategically | Notion | [View](skills/competitor-signal-tracker) |
|
||||
|
||||
### Stakeholder Communication
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **PRD Template** | Standardized product requirements | — | [View](skills/prd-template) |
|
||||
| **Meeting Notes** | Structured meeting documentation | — | [View](skills/meeting-notes) |
|
||||
| **Stakeholder Update** | Executive status updates | — | [View](skills/stakeholder-update) |
|
||||
| **Executive Update** | Sharp executive briefings | Slack, Teams | [View](skills/executive-update) |
|
||||
|
||||
### Go-to-Market & Launch
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Launch Readiness** | Pre-launch go/no-go assessment | Notion, Jira, Slack | [View](skills/launch-readiness) |
|
||||
|
||||
### Cross-functional Collaboration
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **User Research Synthesis** | Analyze and synthesize research findings | Notion | [View](skills/user-research-synthesis) |
|
||||
| **Competitive Analysis** | Structured competitive assessments | — | [View](skills/competitive-analysis) |
|
||||
| **Design Handoff Brief** | PM-to-designer structured briefs | Figma, Notion | [View](skills/design-handoff-brief) |
|
||||
|
||||
### 🧠 Advanced Skills (Part 4 — Role-Based Capabilities)
|
||||
| Skill | Purpose | Tool | Folder |
|
||||
|-------|---------|------|--------|
|
||||
| **Competitive Intelligence Monitor** | Weekly diff-based competitor tracking | Notion, OpenClaw | [View](skills/competitive-intelligence-monitor) |
|
||||
| **Experiment Designer** | A/B test design + results interpretation | Analytics | [View](skills/experiment-designer) |
|
||||
| **Stakeholder Influence Mapper** | Influence strategy + tailored talking points | Slack | [View](skills/stakeholder-influence-mapper) |
|
||||
| **Ambiguity Resolver** | Structures vague briefs into actionable problem statements | Notion | [View](skills/ambiguity-resolver) |
|
||||
| **Multi-Source Signal Synthesiser** | Reconciles user signals across all research channels | Notion, OpenClaw | [View](skills/multi-source-signal-synthesiser) |
|
||||
| **Strategic Narrative Generator** | Roadmap-to-strategy storytelling for executives | Notion | [View](skills/strategic-narrative-generator) |
|
||||
|
||||
|
||||
|
||||
Want a specific Skill? [Request it here](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=skill-request.md)
|
||||
|
||||
## 💡 Real Results
|
||||
|
||||
> "These Skills have become indispensable. I used to spend 3-4 hours every Friday on stakeholder updates. Now it takes 20 minutes to compile everything and let Claude format it. Game-changer."
|
||||
> — **Mohit Aggarwal, Senior PM**
|
||||
|
||||
**Time savings per week:**
|
||||
- PRD creation: -2.5 hours
|
||||
- Meeting notes: -1.5 hours
|
||||
- Stakeholder updates: -2.0 hours
|
||||
- Research synthesis: -2.5 hours
|
||||
- **Total: ~8-9 hours/week back in your schedule**
|
||||
|
||||
## 📚 Documentation
|
||||
|
||||
- [Installation Guide](docs/installation.md) - Step-by-step setup
|
||||
- [Customization Guide](docs/customization.md) - Adapt Skills to your workflow
|
||||
- [Troubleshooting](docs/troubleshooting.md) - Common issues and fixes
|
||||
- [Creating Your Own Skills](docs/creating-skills.md) - Build custom Skills
|
||||
|
||||
## 🛠️ Installation
|
||||
|
||||
### Method 1: Download Individual Skills (Easiest)
|
||||
|
||||
1. Navigate to the skill folder (e.g., `skills/prd-template`)
|
||||
2. Download all files in that folder
|
||||
3. Create a zip file containing those files
|
||||
4. Rename from `.zip` to `.skill`
|
||||
5. Upload to Claude via Settings → Skills
|
||||
|
||||
### Method 2: Clone the Repo
|
||||
|
||||
bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/mohitagw15856/pm-claude-skills.git
|
||||
cd pm-claude-skills
|
||||
|
||||
# Package a skill (creates .skill file)
|
||||
cd skills/prd-template
|
||||
zip -r ../../prd-template.skill .
|
||||
cd ../..
|
||||
|
||||
# Now upload prd-template.skill to Claude
|
||||
|
||||
|
||||
### Method 3: Direct Download (When Available)
|
||||
|
||||
Check the [Releases](https://github.com/mohitagw15856/pm-claude-skills/releases) page for pre-packaged `.skill` files.
|
||||
|
||||
## 🎓 How to Use
|
||||
|
||||
1. **Upload a Skill**: Follow installation instructions above
|
||||
2. **Just ask Claude**: Claude will automatically recognize when to use the Skill
|
||||
- "Help me write a PRD for X"
|
||||
- "Take notes from this meeting transcript"
|
||||
- "Create a competitive analysis of X, Y, Z"
|
||||
3. **No special commands needed**: Skills activate automatically based on context
|
||||
|
||||
## 🔧 Customization
|
||||
|
||||
Every company has different formats and processes. These Skills are designed to be customized:
|
||||
|
||||
1. Download the Skill folder
|
||||
2. Edit the `SKILL.md` file to match your standards
|
||||
3. Add your company's examples to the instructions
|
||||
4. Re-package and upload
|
||||
|
||||
See the [Customization Guide](docs/customization.md) for detailed instructions.
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
Found a bug? Want to suggest an improvement? Contributions are welcome!
|
||||
|
||||
- 🐛 [Report an Issue](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=bug-report.md)
|
||||
- 💡 [Request a Skill](https://github.com/mohitagw15856/pm-claude-skills/issues/new?template=skill-request.md)
|
||||
- 🔀 [Submit a Pull Request](https://github.com/mohitagw15856/pm-claude-skills/pulls)
|
||||
- 💬 [Join Discussions](https://github.com/mohitagw15856/pm-claude-skills/discussions)
|
||||
|
||||
See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.
|
||||
|
||||
## ⭐ Show Your Support
|
||||
|
||||
If these Skills save you time, please:
|
||||
1. ⭐ Star this repository
|
||||
2. 📢 Share with fellow PMs
|
||||
3. 🐛 Report bugs or suggest improvements
|
||||
4. ✍️ Write about your experience
|
||||
|
||||
## 📈 Roadmap
|
||||
|
||||
**Q1 2026:**
|
||||
- [ ] Add Data Analysis Standard Skill
|
||||
- [ ] Add Roadmap Presentation Skill
|
||||
- [ ] Create video tutorials
|
||||
- [ ] Pre-packaged .skill files in Releases
|
||||
|
||||
**Q2 2026:**
|
||||
- [ ] Domain-specific Skills (SaaS PM, B2B PM, Growth PM)
|
||||
- [ ] Team collaboration Skills
|
||||
- [ ] Notion/Confluence template packs
|
||||
|
||||
**Long-term:**
|
||||
- [ ] Interactive Skill builder tool
|
||||
- [ ] Integration examples with PM tools
|
||||
- [ ] Community-contributed Skills library
|
||||
|
||||
## 📄 License
|
||||
|
||||
This project is licensed under the MIT License - see [LICENSE](LICENSE) for details.
|
||||
|
||||
You're free to use, modify, and distribute these Skills. Attribution appreciated but not required.
|
||||
|
||||
## 🙋 FAQ
|
||||
|
||||
**Q: Do I need a paid Claude account?**
|
||||
A: Yes, Skills require Claude Pro, Team, or Enterprise.
|
||||
|
||||
**Q: Can I customize these Skills for my team?**
|
||||
A: Absolutely! See our [Customization Guide](docs/customization.md).
|
||||
|
||||
**Q: Do Skills work with the Claude API?**
|
||||
A: Yes! Skills work in claude.ai, Claude Code, and via the API.
|
||||
|
||||
**Q: What if a Skill doesn't work?**
|
||||
A: Check [Troubleshooting](docs/troubleshooting.md) or [open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues).
|
||||
|
||||
**Q: How do I create my own Skills?**
|
||||
A: See [Creating Your Own Skills](docs/creating-skills.md) for a complete guide.
|
||||
|
||||
**Q: Can I use these commercially?**
|
||||
A: Yes! MIT license allows commercial use.
|
||||
|
||||
## 🔗 Links
|
||||
|
||||
- 📝 [Original Medium Article](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a)
|
||||
- 💼 [Connect on LinkedIn](www.linkedin.com/in/mohitaggarwal4)
|
||||
- ✉️ [Email me](mailto:mohit15856@gmail.com)
|
||||
- Writing these up and refining them took a fair few evenings. If they saved you some time, a [coffee](https://buymeacoffee.com/mohit15856) is always appreciated
|
||||
|
||||
## 🙏 Acknowledgments
|
||||
|
||||
Thank you to everyone who read and shared my Medium article, and to the Anthropic team for building such a powerful feature.
|
||||
|
||||
Special thanks to the early testers who provided feedback on these Skills.
|
||||
**🆕 Latest release (v7.0.0):** 6 new engineering skills added — Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, and Runbook Writer. The `pm-engineering` bundle now has 10 skills.
|
||||
|
||||
---
|
||||
|
||||
**Made with ☕ by [Mohit Aggarwal](https://mohit-pm.netlify.app/)**
|
||||
## 🚀 Quick Install (2 minutes)
|
||||
|
||||
*Helping product managers work smarter with AI*
|
||||
In Claude Code, run:
|
||||
|
||||
⭐ **Star this repo to get updates as new Skills are added!**
|
||||
/plugin marketplace add mohitagw15856/pm-claude-skills
|
||||
|
||||
|
||||
Or install by profession:
|
||||
|
||||
claude plugin install pm-essentials@pm-claude-skills # Core PM + Word tracked changes
|
||||
claude plugin install pm-delivery@pm-claude-skills # Delivery + PowerPoint auditor
|
||||
claude plugin install pm-engineering@pm-claude-skills # Engineering + DevOps (10 skills) 🆕
|
||||
claude plugin install pm-data@pm-claude-skills # Data + chart data extractor
|
||||
claude plugin install pm-legal@pm-claude-skills # Legal
|
||||
claude plugin install pm-finance@pm-claude-skills # Finance
|
||||
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:
|
||||
|
||||
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/
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 🎬 See It in Action
|
||||
|
||||
**Debugging Log Analyser** — paste a stack trace or error log, get a structured root cause diagnosis with probable cause, affected code path, a specific fix, and next debugging steps.
|
||||
|
||||
**PR Description Writer** — share your diff or commit list, get a reviewer-friendly PR description with summary, changes made, testing steps, and reviewer notes.
|
||||
|
||||
**Sprint Planning Skill** — paste your sprint goals and backlog items, get a complete structured sprint plan with capacity, commitments, risks, and a day-one kickoff agenda.
|
||||
|
||||
> 📹 Drop a demo in [Discussions](../../discussions) and we'll feature it here.
|
||||
|
||||
---
|
||||
|
||||
## 🆕 What's New in v7.0.0 — Engineering Skills Expansion
|
||||
|
||||
**6 new engineering skills added to `pm-engineering`:**
|
||||
|
||||
| Skill | Bundle | What It Does |
|
||||
|---|---|---|
|
||||
| **Debugging Log Analyser** 🆕 | pm-engineering | Parse stack traces and error logs into a structured root cause diagnosis with a specific fix |
|
||||
| **PR Description Writer** 🆕 | pm-engineering | Write reviewer-friendly PR descriptions from a diff, commit list, or change summary |
|
||||
| **System Design Interview** 🆕 | pm-engineering | Structure complete system design answers with capacity estimates, component deep-dives, and trade-offs |
|
||||
| **Changelog Generator** 🆕 | pm-engineering | Convert git commits into a polished, user-facing changelog following Keep a Changelog format |
|
||||
| **Test Strategy Doc** 🆕 | pm-engineering | Write a complete test strategy with risk assessment, test types, coverage targets, and P0/P1 test cases |
|
||||
| **Runbook Writer** 🆕 | pm-engineering | Write operational runbooks for deployments, incidents, and maintenance with exact commands and rollback steps |
|
||||
|
||||
The `pm-engineering` bundle now has **10 skills** — the most complete engineering toolkit in the library.
|
||||
|
||||
**Read the full story:** [Part 14 — I Rebuilt All 93 Skills and Added 7 More: What 100 Skills Taught Me About What Makes a Great Skill](https://medium.com/product-powerhouse/a-pull-request-made-me-rebuild-all-93-of-my-claude-skills-then-i-added-7-more-16d5fe3e7f85)
|
||||
|
||||
---
|
||||
|
||||
## 📖 v6.0.0 — 100 Skills Milestone
|
||||
|
||||
**7 skills added:**
|
||||
|
||||
| Skill | Bundle | What It Does |
|
||||
|---|---|---|
|
||||
| **Teaching Lesson Plan** | pm-cross | Structured lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
|
||||
| **SEO Content Brief** | pm-gtm | Complete SEO briefs with search intent analysis, competitor gaps, content outline, and on-page requirements |
|
||||
| **Media Pitch** | pm-gtm | Story-first journalist pitches with angle development framework and pitch rules |
|
||||
| **Change Management Plan** | pm-hr | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
|
||||
| **Workshop Facilitation Guide** | pm-operations | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
|
||||
| **Sales Forecasting Model** | pm-sales | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
|
||||
| **Tax Planning Checklist** | pm-finance | Year-end tax planning review framework across income, pension, CGT, business reliefs, and ISAs |
|
||||
|
||||
---
|
||||
|
||||
## 📚 The Article Series
|
||||
|
||||
This repo was built alongside a published article series. Read the full story:
|
||||
|
||||
| Part | Title | Link |
|
||||
|---|---|---|
|
||||
| Part 1 | Claude Skills: The AI Feature That's Quietly Changing How PMs Work | [Read →](https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a) |
|
||||
| Part 2 | Claude Skills vs Prompts: How PMs and Developers Can 10x Their AI Productivity | [Read →](https://medium.com/@mohit15856/claude-skills-vs-prompts-how-pms-and-developers-can-10x-their-ai-productivity-facb5eed5b12) |
|
||||
| Part 3 | 12 Claude Skills for Product Managers: The Complete Toolkit | [Read →](https://medium.com/@mohit15856/12-claude-skills-for-product-managers-the-complete-toolkit-with-skill-files-for-jira-figma-fcc73a4c1e58) |
|
||||
| Part 4 | Claude Skills: Advanced Guide — What 3 Months of Daily PM Use Actually Taught Me | [Read →](https://medium.com/@mohit15856/claude-skills-advanced-guide-what-3-months-of-daily-pm-use-actually-taught-me-18324d6ef7bc) |
|
||||
| Part 5 | What Google, Meta and Anthropic Want From PMs — And the Claude Skills That Deliver It | [Read →](https://medium.com/@mohit15856/what-google-meta-and-anthropic-want-from-pms-and-the-claude-skills-that-deliver-it-b0f2b6cd9340) |
|
||||
| Part 6 | I Tested Anthropic's Skill Creator Plugin on My Own Skills | [Read →](https://medium.com/all-about-claude/i-tested-anthropics-skill-creator-plugin-on-my-own-skills-here-s-what-i-found-23ad406b0825) |
|
||||
| Part 7 | 33 Claude Skills for PMs Are Now in the Claude Code Marketplace | [Read →](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) |
|
||||
| Part 8 | I Added 20 New Claude Skills Beyond Product Management | [Read →](https://medium.com/product-powerhouse/i-built-20-new-claude-skills-for-every-profession-heres-the-full-library-50278e00bf72) |
|
||||
| Part 9 | 80 Claude Skills for Every Profession — Lawyers, Doctors, Finance, HR, Sales and More | [Read →](https://medium.com/@mohit15856/80-claude-skills-for-every-profession-lawyers-doctors-finance-hr-sales-and-more-3dfde9ec0033) |
|
||||
| Part 10 | A Day in the Life With 80 Claude Skills | [Read →](https://medium.com/@mohit15856/a-day-in-the-life-with-80-claude-skills-what-actually-gets-triggered-7caf9f5c159e) |
|
||||
| Part 11 | 10 Figma Claude Skills for PMs and Designers | [Read →](https://medium.com/@mohit15856/10-figma-claude-skills-for-pms-and-designers-the-complete-figma-toolkit-784441d07a78)|
|
||||
| Part 12 | I Built the Same Skills Library for ChatGPT — Here's What's Different | [Read →](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9) |
|
||||
| Part 13 | I Re-Tested My 90 Claude Skills on Opus 4.7 — Here's What Got Better | [Read →](https://medium.com/all-about-claude/i-re-tested-my-90-claude-skills-on-opus-4-7-heres-what-actually-got-better-dd4b9369329e)|
|
||||
| Part 14 | I Rebuilt All 93 Skills and Added 7 More: What 100 Skills Taught Me About What Makes a Great Skill | [Read →](https://medium.com/product-powerhouse/a-pull-request-made-me-rebuild-all-93-of-my-claude-skills-then-i-added-7-more-16d5fe3e7f85) |
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ All 106 Skills
|
||||
|
||||
### 🛠️ Product Management (Skills 1–34)
|
||||
**Bundles:** `pm-essentials` · `pm-discovery` · `pm-planning` · `pm-delivery` · `pm-analytics` · `pm-strategy` · `pm-advanced` · `pm-rituals`
|
||||
|
||||
> 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–6 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, **Word Doc Tracked Changes** 🆕 |
|
||||
| 7–10 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper |
|
||||
| 11–16 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy |
|
||||
| 17–24 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro, **PPTX Slide Auditor** 🆕 |
|
||||
| 25–27 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
|
||||
| 28–33 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
|
||||
| 34 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief |
|
||||
|
||||
> See [Part 7 article](https://medium.com/product-powerhouse/33-claude-skills-for-pms-are-now-in-the-claude-code-marketplace-heres-how-to-install-them-7968ab6bb1e1) for full PM skills detail.
|
||||
|
||||
---
|
||||
|
||||
### 📣 Marketing & GTM (Skills 35–40)
|
||||
**Bundle:** `pm-gtm`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 35 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
|
||||
| 36 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
|
||||
| 37 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
|
||||
| 38 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
|
||||
| 39 | **SEO Content Brief** 🆕 | `skills/seo-content-brief/` | Complete SEO briefs with search intent, competitor gap analysis, content outline, and on-page requirements |
|
||||
| 40 | **Media Pitch** 🆕 | `skills/media-pitch/` | Story-first journalist pitches with angle development framework and pitch writing rules |
|
||||
|
||||
---
|
||||
|
||||
### 👩💻 Engineering & Tech (Skills 41–50)
|
||||
**Bundle:** `pm-engineering`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 41 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
|
||||
| 42 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
|
||||
| 43 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs: endpoints, parameters, response schemas, code examples |
|
||||
| 44 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options considered, decision, consequences, and risks |
|
||||
| 45 | **Debugging Log Analyser** 🆕 | `skills/debugging-log-analyser/` | Parse stack traces and error logs into a structured root cause diagnosis with a specific fix |
|
||||
| 46 | **PR Description Writer** 🆕 | `skills/pr-description-writer/` | Write reviewer-friendly PR descriptions from a diff, commit list, or change summary |
|
||||
| 47 | **System Design Interview** 🆕 | `skills/system-design-interview/` | Structure complete system design answers with capacity estimates, component deep-dives, and trade-offs |
|
||||
| 48 | **Changelog Generator** 🆕 | `skills/changelog-generator/` | Convert git commits into a polished, user-facing changelog following Keep a Changelog format |
|
||||
| 49 | **Test Strategy Doc** 🆕 | `skills/test-strategy-doc/` | Write a complete test strategy with risk assessment, test types, coverage targets, and P0/P1 test cases |
|
||||
| 50 | **Runbook Writer** 🆕 | `skills/runbook-writer/` | Write operational runbooks for deployments, incidents, and maintenance with exact commands and rollback steps |
|
||||
|
||||
---
|
||||
|
||||
### 📊 Data & Analytics (Skills 45–48)
|
||||
**Bundle:** `pm-data`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 45 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
|
||||
| 46 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
|
||||
| 47 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
|
||||
| 48 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
|
||||
|
||||
---
|
||||
|
||||
### 🧑💼 Leadership & People (Skills 49–51)
|
||||
**Bundle:** `pm-people`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 49 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
|
||||
| 50 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
|
||||
| 51 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
|
||||
|
||||
---
|
||||
|
||||
### 🎨 Design & UX (Skills 52–54)
|
||||
**Bundle:** `pm-design`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 52 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
|
||||
| 53 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
|
||||
| 54 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
|
||||
|
||||
---
|
||||
|
||||
### 🏢 Business & Strategy (Skills 55–57)
|
||||
**Bundle:** `pm-business`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 55 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
|
||||
| 56 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
|
||||
| 57 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
|
||||
|
||||
---
|
||||
|
||||
### ⚖️ Legal (Skills 58–61)
|
||||
**Bundle:** `pm-legal`
|
||||
|
||||
> ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 58 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
|
||||
| 59 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
|
||||
| 60 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
|
||||
| 61 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
|
||||
|
||||
---
|
||||
|
||||
### 💰 Finance (Skills 62–66)
|
||||
**Bundle:** `pm-finance`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 62 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
|
||||
| 63 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
|
||||
| 64 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
|
||||
| 65 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
|
||||
| 66 | **Tax Planning Checklist** 🆕 | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |
|
||||
|
||||
---
|
||||
|
||||
### 👥 HR (Skills 67–71)
|
||||
**Bundle:** `pm-hr`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 67 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
|
||||
| 68 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
|
||||
| 69 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
|
||||
| 70 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
|
||||
| 71 | **Change Management Plan** 🆕 | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
|
||||
|
||||
---
|
||||
|
||||
### 🤝 Sales (Skills 72–76)
|
||||
**Bundle:** `pm-sales`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 72 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
|
||||
| 73 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
|
||||
| 74 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
|
||||
| 75 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
|
||||
| 76 | **Sales Forecasting Model** 🆕 | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Operations (Skills 77–81)
|
||||
**Bundle:** `pm-operations`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 77 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
|
||||
| 78 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
|
||||
| 79 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
|
||||
| 80 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
|
||||
| 81 | **Workshop Facilitation Guide** 🆕 | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
|
||||
|
||||
---
|
||||
|
||||
### 🏥 Research & Healthcare (Skills 82–85)
|
||||
**Bundle:** `pm-research`
|
||||
|
||||
> ⚠️ Healthcare skills are for documentation and educational purposes only. All clinical content must be reviewed by a qualified professional.
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 82 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
|
||||
| 83 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
|
||||
| 84 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
|
||||
| 85 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
|
||||
|
||||
---
|
||||
|
||||
### 🌐 Cross-Profession (Skills 86–89)
|
||||
**Bundle:** `pm-cross`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 86 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
|
||||
| 87 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
|
||||
| 88 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
|
||||
| 89 | **Teaching Lesson Plan** 🆕 | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
|
||||
|
||||
---
|
||||
|
||||
### 🖼️ Figma (Skills 90–100 — reaching the milestone)
|
||||
**Bundle:** `pm-figma`
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 90 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
|
||||
| 91 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
|
||||
| 92 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
|
||||
| 93 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
|
||||
| 94 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
|
||||
| 95 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
|
||||
| 96 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
|
||||
| 97 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
|
||||
| 98 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
|
||||
| 99 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
|
||||
| 100 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
|
||||
|
||||
claude plugin install pm-figma@pm-claude-skills
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contributing — Add Your Skill
|
||||
|
||||
This is an open-source community library. If you've built a skill that saves you time, share it here.
|
||||
|
||||
**How to contribute:**
|
||||
|
||||
1. Fork this repo
|
||||
2. Create a new folder: `skills/your-skill-name/`
|
||||
3. Add a `SKILL.md` file following the template below
|
||||
4. Raise a pull request with a short description of what the skill does and why you built it
|
||||
|
||||
**SKILL.md template:**
|
||||
---
|
||||
name: your-skill-name
|
||||
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)
|
||||
- Has a clear trigger description so Claude knows when to activate it
|
||||
- Produces consistent, structured output
|
||||
- Works without needing extensive setup or context
|
||||
|
||||
**Skills wishlist** (most requested — up for grabs):
|
||||
|
||||
| Skill | Profession | Use Case |
|
||||
|---|---|---|
|
||||
| `grant-report` | Non-profit | Funder progress reports against grant objectives |
|
||||
| `architectural-spec` | Architecture | Project specifications and technical drawing briefs |
|
||||
| `clinical-guideline-summary` | Healthcare | Plain English summaries of clinical guidelines |
|
||||
| `pitch-deck-feedback` | Startup | Investor-perspective critique of a pitch deck |
|
||||
| `board-minutes` | Governance | Formal board meeting minutes from discussion notes |
|
||||
|
||||
Have a skill idea? Add it to [SKILL_REQUEST.md](SKILL_REQUEST.md), [open an issue](../../issues), or raise it in [Discussions](../../discussions). Most-voted requests get built first.
|
||||
|
||||
**Contributors** get credited in this README and in the article series. 🙌
|
||||
|
||||
---
|
||||
|
||||
## 📦 All Plugin Bundles
|
||||
|
||||
Install the whole library or just the bundles you need:
|
||||
|
||||
# Install everything
|
||||
/plugin marketplace add mohitagw15856/pm-claude-skills
|
||||
|
||||
# Install by profession
|
||||
claude plugin install pm-essentials@pm-claude-skills
|
||||
claude plugin install pm-discovery@pm-claude-skills
|
||||
claude plugin install pm-planning@pm-claude-skills
|
||||
claude plugin install pm-delivery@pm-claude-skills
|
||||
claude plugin install pm-analytics@pm-claude-skills
|
||||
claude plugin install pm-strategy@pm-claude-skills
|
||||
claude plugin install pm-advanced@pm-claude-skills
|
||||
claude plugin install pm-rituals@pm-claude-skills
|
||||
claude plugin install pm-gtm@pm-claude-skills
|
||||
claude plugin install pm-engineering@pm-claude-skills # 10 engineering skills 🆕
|
||||
claude plugin install pm-data@pm-claude-skills
|
||||
claude plugin install pm-people@pm-claude-skills
|
||||
claude plugin install pm-design@pm-claude-skills
|
||||
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 100 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
|
||||
|
||||
**What custom skills look like in practice:**
|
||||
|
||||
- A law firm's contract review skill trained on their specific clause library and risk tolerance
|
||||
- A SaaS company's sprint brief skill that knows their engineering conventions and definition of done
|
||||
- A finance team's board pack skill that follows their exact narrative structure and slide format
|
||||
- An HR team's job description skill that reflects their values language and includes their specific benefits
|
||||
|
||||
The difference between a generic skill and one built for your context is significant. Generic skills eliminate the blank page. Custom skills eliminate the rework.
|
||||
|
||||
**If you want skills built for your team's specific workflows — [get in touch](mailto:mohit15856@gmail.com).**
|
||||
|
||||
Include a brief description of your team, the workflows you want to automate, and the tools you use. I'll come back to you within 48 hours.
|
||||
|
||||
---
|
||||
|
||||
## 📖 How Skills Work
|
||||
|
||||
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)
|
||||
|
||||
---
|
||||
|
||||
## ⭐ Star Milestones
|
||||
|
||||
Stars unlock the next wave of skills. Here's the roadmap:
|
||||
|
||||
| Milestone | Unlocks | Status |
|
||||
|---|---|---|
|
||||
| 100 ⭐ | 10 Figma skills + quality rebuild across all 93 skills | ✅ Shipped (v6.0.0) |
|
||||
| 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) | 🔒 Locked |
|
||||
| 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns) | 🔒 Locked |
|
||||
| 1000 ⭐ | Full Startup Founder kit (fundraising memo, pitch critique, co-founder equity split) | 🔒 Locked |
|
||||
|
||||
**[⭐ Star this repo to unlock the next milestone →](https://github.com/mohitagw15856/pm-claude-skills)**
|
||||
|
||||
Want a specific skill built? [Vote or request in SKILL_REQUEST.md](SKILL_REQUEST.md).
|
||||
|
||||
---
|
||||
|
||||
*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Notes publication](https://medium.com/product-powerhouse)*
|
||||
|
||||
+55
@@ -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.
|
||||
@@ -0,0 +1,65 @@
|
||||
# Skill Requests — Community Voting Board
|
||||
|
||||
Have an idea for a skill? Add it here or upvote existing requests by leaving a 👍 reaction on the issue.
|
||||
|
||||
---
|
||||
|
||||
## How to Request a Skill
|
||||
|
||||
1. [Open an issue](../../issues/new) with the label `skill-request`
|
||||
2. Include:
|
||||
- **Skill name** (what you'd call it)
|
||||
- **Profession** (who uses this)
|
||||
- **Trigger** (when would you invoke it — e.g. "when I need to write X")
|
||||
- **Output** (what should Claude produce)
|
||||
3. Drop a 👍 on existing requests you'd use — most-voted get built first
|
||||
|
||||
---
|
||||
|
||||
## Milestone Unlocks
|
||||
|
||||
Stars drive the roadmap. Here's what's queued:
|
||||
|
||||
| Milestone | Unlocks |
|
||||
|---|---|
|
||||
| ✅ 100 ⭐ | 10 Figma skills + quality rebuild across all skills (v6.0.0) |
|
||||
| 🔒 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) |
|
||||
| 🔒 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, debugging deep-dives, onboarding docs, SLO templates) |
|
||||
| 🔒 1000 ⭐ | Full Startup Founder kit (fundraising memo, pitch critique, co-founder agreement framework) |
|
||||
|
||||
**[Star this repo →](https://github.com/mohitagw15856/pm-claude-skills)**
|
||||
|
||||
---
|
||||
|
||||
## Requested Skills (Open)
|
||||
|
||||
Add a request by opening an issue — these are current top asks from the community:
|
||||
|
||||
| Skill | Profession | Requested By | Votes |
|
||||
|---|---|---|---|
|
||||
| `customer-health-scorecard` | Customer Success | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `qbr-deck-writer` | Customer Success | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `escalation-brief` | Customer Success | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `fundraising-memo` | Startup / Founder | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `youtube-script-writer` | Content Creator | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `newsletter-issue-writer` | Content Creator | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `analytics-event-taxonomy` | Data / Analytics | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `kpi-tree-builder` | Data / Analytics | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `dissertation-chapter-planner` | Academic | [@mohitagw15856](https://github.com/mohitagw15856) | — |
|
||||
| `board-minutes` | Governance | Community | — |
|
||||
|
||||
> **To vote:** React with 👍 on the linked issue. To add a new request, open an issue with label `skill-request`.
|
||||
|
||||
---
|
||||
|
||||
## Recently Shipped
|
||||
|
||||
| Version | Skills Added |
|
||||
|---|---|
|
||||
| v7.0.0 | Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer |
|
||||
| v6.0.0 | Teaching Lesson Plan, SEO Content Brief, Media Pitch, Change Management Plan, Workshop Facilitation Guide, Sales Forecasting Model, Tax Planning Checklist |
|
||||
| v5.0.0 | 10 Figma skills |
|
||||
|
||||
---
|
||||
|
||||
*Maintained by [Mohit Aggarwal](https://github.com/mohitagw15856)*
|
||||
@@ -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)
|
||||
Vendored
BIN
Binary file not shown.
Executable
+36
@@ -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"
|
||||
Executable
+180
@@ -0,0 +1,180 @@
|
||||
#!/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 "================================================"
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-advanced",
|
||||
"version": "3.0.0",
|
||||
"description": "Advanced PM skills: AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief. For senior PMs working on complex or AI-powered products.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["product-management", "ai-product", "experiment-design", "design-handoff", "signal-synthesis"]
|
||||
}
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,161 @@
|
||||
---
|
||||
name: ai-product-canvas
|
||||
description: "Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan."
|
||||
---
|
||||
|
||||
# AI Product Canvas Skill
|
||||
|
||||
Define AI products with the same rigour as any product decision — but with additional layers for data, model, evaluation, and responsible AI. This canvas prevents the most common AI product failure: building a technically impressive feature that doesn't solve a real problem.
|
||||
|
||||
## AI Product Anti-Patterns to Check First
|
||||
|
||||
Before building, flag if any of these apply:
|
||||
- ❌ "We should add AI to [existing feature]" — with no user problem defined
|
||||
- ❌ Accuracy target undefined before build begins
|
||||
- ❌ No plan for what happens when the model is wrong
|
||||
- ❌ User-facing AI output with no human review or fallback
|
||||
- ❌ Training data not audited for bias or quality
|
||||
- ❌ No evaluation metric — "we'll know it when we see it"
|
||||
|
||||
---
|
||||
|
||||
## AI Product Canvas Output Format
|
||||
|
||||
### AI Product Canvas — [Feature Name] — [Date]
|
||||
|
||||
**PM Owner:** [Name]
|
||||
**ML/AI Lead:** [Name]
|
||||
**Status:** Discovery / Design / Build / Evaluation / Live
|
||||
|
||||
---
|
||||
|
||||
#### 1. Problem Definition
|
||||
**User problem being solved:**
|
||||
> [What specific situation is the user in? What job are they trying to get done?]
|
||||
|
||||
**Why AI?**
|
||||
> [What makes this problem require AI vs a deterministic solution? If the answer is "because we can," stop here.]
|
||||
|
||||
**Success for the user looks like:**
|
||||
> [What outcome does the user experience when the AI feature is working well?]
|
||||
|
||||
---
|
||||
|
||||
#### 2. AI Approach
|
||||
|
||||
**Task type:**
|
||||
- [ ] Classification
|
||||
- [ ] Generation (text, image, code)
|
||||
- [ ] Summarisation / extraction
|
||||
- [ ] Recommendation
|
||||
- [ ] Search / retrieval
|
||||
- [ ] Prediction / forecasting
|
||||
- [ ] Conversation / agent
|
||||
|
||||
**Model approach:**
|
||||
- [ ] LLM API (GPT-4, Claude, Gemini, etc.) — specify: [Model name + version]
|
||||
- [ ] Fine-tuned model on own data
|
||||
- [ ] Custom model trained from scratch
|
||||
- [ ] RAG (retrieval-augmented generation)
|
||||
- [ ] Embedding + vector search
|
||||
|
||||
**Rationale for chosen approach:** [Why this, not alternatives]
|
||||
|
||||
---
|
||||
|
||||
#### 3. Data Requirements
|
||||
|
||||
| Data Type | Source | Volume | Quality Status | Bias Risk |
|
||||
|---|---|---|---|---|
|
||||
| [Training data] | [Where it comes from] | [Volume] | [Audit status] | H/M/L |
|
||||
| [Evaluation data] | [Where it comes from] | [Volume] | [Audit status] | H/M/L |
|
||||
|
||||
**Data gaps:** [What's missing and plan to get it]
|
||||
**Privacy considerations:** [Any PII in training or inference data]
|
||||
**Data ownership:** [Do we own this data? Can we use it for training?]
|
||||
|
||||
---
|
||||
|
||||
#### 4. Evaluation Framework
|
||||
|
||||
**Primary metric:** [The number that defines success — accuracy, F1, BLEU, user rating, task completion rate]
|
||||
**Minimum acceptable threshold:** [Below X, the feature does not ship]
|
||||
**Human evaluation plan:** [How will humans review model outputs? Sampling rate? Review panel?]
|
||||
|
||||
| Evaluation Type | Method | Cadence | Owner |
|
||||
|---|---|---|---|
|
||||
| Offline (pre-launch) | [Test set, benchmark] | Pre-launch | ML Lead |
|
||||
| Online (post-launch) | [A/B test, user feedback] | Weekly | PM + ML |
|
||||
| Adversarial | [Red-team, edge cases] | Pre-launch | Safety reviewer |
|
||||
|
||||
---
|
||||
|
||||
#### 5. User Experience Design
|
||||
|
||||
**How is AI output presented?**
|
||||
- [ ] Direct output shown to user (high trust required)
|
||||
- [ ] AI-assisted with user confirmation
|
||||
- [ ] Suggestion user can accept/reject
|
||||
- [ ] Background action with audit log
|
||||
|
||||
**Confidence and uncertainty handling:**
|
||||
- What happens when confidence is low? [Show alternative, ask for clarification, fallback to manual]
|
||||
- How is uncertainty communicated to the user? [UI pattern]
|
||||
|
||||
**Fallback plan:**
|
||||
- If the model fails or returns an error: [Specific fallback behaviour]
|
||||
- If accuracy degrades below threshold: [Kill switch or graceful degradation plan]
|
||||
|
||||
---
|
||||
|
||||
#### 6. Responsible AI Checklist
|
||||
|
||||
- [ ] Bias audit completed on training data
|
||||
- [ ] Demographic fairness evaluated (does performance differ by user group?)
|
||||
- [ ] Hallucination / confabulation risk assessed and mitigated
|
||||
- [ ] User can see and correct AI output
|
||||
- [ ] Opt-out mechanism exists (can user disable the AI feature?)
|
||||
- [ ] Output provenance visible when relevant (does user know AI generated this?)
|
||||
- [ ] PII not used in ways user didn't consent to
|
||||
- [ ] Regulatory review completed (GDPR, AI Act, sector-specific)
|
||||
- [ ] Model cards / documentation completed
|
||||
|
||||
---
|
||||
|
||||
#### 7. Launch & Monitoring Plan
|
||||
|
||||
**Rollout:** [% of users, with staged expansion criteria]
|
||||
**Monitoring metrics:**
|
||||
- Model performance: [Metric + alert threshold]
|
||||
- User engagement with AI output: [Acceptance rate, override rate, feedback score]
|
||||
- Error rate: [% of failed inferences]
|
||||
- Latency: [P95 target]
|
||||
|
||||
**Model refresh cadence:** [How often is the model retrained or updated?]
|
||||
**Drift detection:** [How will you know when model performance degrades in production?]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never skip the "Why AI?" section — it's the most important question in AI product development
|
||||
- The fallback UX is not optional — what happens when AI fails defines your product's trustworthiness
|
||||
- Responsible AI checklist must be completed before launch, not after
|
||||
- Include latency in success metrics — a 5-second AI response is often worse than no AI at all
|
||||
- Recommend starting with a human-in-the-loop design and automating only when accuracy is proven
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Feature or product description** (what the AI is intended to do)
|
||||
- **User problem** (what problem the AI is solving for users)
|
||||
- **Available data** (what training/inference data exists)
|
||||
- **ML/AI lead** (who owns the technical implementation)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] "Why AI?" is answered clearly (not "because we can")
|
||||
- [ ] Minimum acceptable accuracy threshold is defined before build begins
|
||||
- [ ] Fallback UX is specified for model failures or low-confidence outputs
|
||||
- [ ] Responsible AI checklist is completed (not deferred to post-launch)
|
||||
- [ ] Monitoring plan includes both model performance and user engagement metrics
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
name: design-handoff-brief
|
||||
description: "Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries."
|
||||
---
|
||||
|
||||
# Design Handoff Brief Skill
|
||||
|
||||
Produce a design brief that sets designers up for success — grounding them in user context and constraints before they open Figma, not after they've gone in the wrong direction.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Feature brief or PRD** (even rough notes work)
|
||||
- **Designer's name or team** (for personalisation)
|
||||
- **Technical constraints** (any engineering limitations already known)
|
||||
- **Timeline** (when does design need to be done?)
|
||||
|
||||
## What Designers Actually Need (and PMs Often Skip)
|
||||
- The user's goal, not the feature name
|
||||
- The emotional state of the user at this moment in the journey
|
||||
- What success looks like — how will we know the design worked?
|
||||
- Constraints: technical, legal, brand, accessibility
|
||||
- Edge cases that must be handled
|
||||
- What we're explicitly NOT solving for
|
||||
|
||||
## Process
|
||||
1. Read the feature brief or PRD provided
|
||||
2. Extract user goal (reframe from feature language to user outcome language)
|
||||
3. Identify constraints — technical limitations, brand guidelines, accessibility requirements
|
||||
4. List edge cases the design must handle
|
||||
5. Define success criteria the design should be evaluated against
|
||||
6. Write a "not in scope" section to prevent scope creep in design
|
||||
7. **Validate** — Confirm every edge case listed is specific enough to design for, and every out-of-scope item is concrete enough to say "no" to
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Design Brief: [Feature Name]
|
||||
|
||||
**User Goal:** (in the user's words, not ours)
|
||||
"When I [situation], I want to [motivation] so that I can [outcome]."
|
||||
|
||||
**Context & Emotional State:**
|
||||
[Where is the user in their journey? What are they feeling? What just happened?]
|
||||
|
||||
**Design Success Criteria:**
|
||||
- [Criterion 1 — measurable where possible]
|
||||
- [Criterion 2]
|
||||
- [Criterion 3]
|
||||
|
||||
**Constraints:**
|
||||
- Technical: [limitations engineering has flagged]
|
||||
- Brand: [relevant brand guidelines]
|
||||
- Accessibility: [WCAG level required, any specific requirements]
|
||||
- Legal/Compliance: [if applicable]
|
||||
|
||||
**Edge Cases to Design For:**
|
||||
- [Edge case 1]
|
||||
- [Edge case 2]
|
||||
- [Edge case 3]
|
||||
|
||||
**Explicitly Out of Scope:**
|
||||
- [What we are NOT solving in this design iteration]
|
||||
|
||||
**Reference Material:**
|
||||
- User research: [link]
|
||||
- Existing patterns: [Figma component library link]
|
||||
- Competitor examples: [links if relevant]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] User goal is written in user language (not feature/product language)
|
||||
- [ ] At least one edge case covers an error or failure state
|
||||
- [ ] Success criteria are measurable or observable (not "looks good")
|
||||
- [ ] Out-of-scope section names at least one thing that might seem in scope but isn't
|
||||
- [ ] Technical constraints are specific enough for an engineer to confirm
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
name: experiment-designer
|
||||
description: "Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation."
|
||||
---
|
||||
|
||||
# Experiment Designer Skill
|
||||
|
||||
Produce rigorous experiment designs from product hypotheses, and interpret results with statistical and practical significance — so you can defend every decision to a sceptical engineering lead or data scientist.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
**For experiment design:**
|
||||
- Hypothesis (what change, what metric, what expected movement)
|
||||
- Current baseline metric value
|
||||
- Minimum detectable effect (MDE) — the smallest lift worth caring about
|
||||
- Available daily sample size
|
||||
|
||||
**For results interpretation:**
|
||||
- Control and variant results (raw numbers or percentages)
|
||||
- P-value or confidence interval
|
||||
- Run duration (days)
|
||||
- Any anomalies observed during the test
|
||||
|
||||
## Two-Phase Process
|
||||
|
||||
### Phase 1: Experiment Design
|
||||
1. Restate hypothesis as: "If we [change], we expect [metric] to [move by X%] because [reason]"
|
||||
2. Define control and variant clearly
|
||||
3. Select primary metric (one only) and secondary guardrail metrics (2-3 max)
|
||||
4. Calculate required sample size from MDE and baseline
|
||||
5. Estimate run time in days
|
||||
6. Set pre-defined success criteria before the test runs — no moving goalposts
|
||||
7. Flag design risks: novelty effects, seasonal confounds, multiple testing issues, network effects, sample ratio mismatch
|
||||
|
||||
### Phase 2: Results Interpretation
|
||||
1. Assess statistical significance (p < 0.05 threshold)
|
||||
2. Assess practical significance: was the lift meaningful for the business, not just real?
|
||||
3. Interpret confidence intervals
|
||||
4. Investigate confounding factors
|
||||
5. Recommend: Ship / Iterate / Kill / Run follow-up test
|
||||
6. **Validate** — Confirm the test ran for the full planned duration. Flag if it was stopped early (peeking problem). Confirm sample ratio mismatch did not occur.
|
||||
|
||||
## Output Structure
|
||||
|
||||
**[Design or Results header based on phase]**
|
||||
|
||||
*Hypothesis:* "If we [change], we expect [metric] to [move by X%] because [reason]"
|
||||
|
||||
*Primary metric:* [One metric only]
|
||||
*Guardrail metrics:* [2-3 max]
|
||||
*Required sample size:* [n per variant]
|
||||
*Estimated run time:* [days]
|
||||
*Pre-defined success threshold:* [specific number]
|
||||
*Design risk flags:* [any concerns]
|
||||
|
||||
**Results (Phase 2 only):**
|
||||
*Statistical significance:* [p-value and conclusion]
|
||||
*Practical significance:* [lift size vs. business threshold]
|
||||
*Recommendation:* Ship / Iterate / Kill / Follow-up — [rationale]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Hypothesis specifies the change, the metric, the direction, and the reason
|
||||
- [ ] Primary metric is singular — guardrail metrics are secondary
|
||||
- [ ] Success criteria are defined before the test launches (not after seeing results)
|
||||
- [ ] Test was not stopped early (or flagged clearly if it was)
|
||||
- [ ] Practical significance assessed separately from statistical significance
|
||||
- [ ] Sample ratio mismatch is checked in results interpretation
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
name: multi-source-signal-synthesiser
|
||||
description: "Synthesise user signals from multiple research sources into a unified insight brief, reconciling conflicting feedback. Use when asked to make sense of data from multiple sources, synthesise user research, reconcile conflicting feedback, or when the user says 'what are users really telling us' or 'make sense of all this user data'. Produces ranked insights with confidence ratings, divergent signal analysis, and research gap identification."
|
||||
---
|
||||
|
||||
# Multi-Source Signal Synthesiser Skill
|
||||
|
||||
Reconcile user signals from multiple sources — interviews, support tickets, NPS, app reviews, sales calls — into a unified, weighted insight brief that surfaces the underlying need rather than the surface-level request.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Signal sources** (interviews, support tickets, NPS verbatims, app reviews, sales calls, analytics — any combination)
|
||||
- **Time period** covered by the data
|
||||
- **Product area or feature** the signals relate to (if scoped)
|
||||
|
||||
## Source Weighting (default — adapt to context)
|
||||
|
||||
| Source | Weight | Rationale |
|
||||
|--------|--------|-----------|
|
||||
| Direct research (interviews, usability tests) | 5 | Highest-fidelity, structured |
|
||||
| Support tickets (unprompted pain signals) | 4 | Real pain, unfiltered |
|
||||
| NPS verbatims | 3 | Broad but shallow |
|
||||
| App store reviews | 2 | Public, self-selected |
|
||||
| Sales call summaries | 2 | Filtered through sales lens |
|
||||
| Anecdote or single report | 1 | Low confidence alone |
|
||||
|
||||
## Process
|
||||
1. Tag each signal by source and apply weight
|
||||
2. Look for **convergence**: same underlying need appearing across 3+ sources
|
||||
3. Look for **divergence**: contradictory signals suggesting user segmentation
|
||||
4. Distinguish surface request from underlying need (e.g. "faster export" may mean "I don't trust the data will be there when I need it")
|
||||
5. Produce ranked insights by weighted frequency
|
||||
6. **Validate** — Confirm each insight has evidence from at least 2 source types. Flag any insight resting on a single source as low-confidence.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### User Signal Synthesis — [Date / Period]
|
||||
**Sources included:** [list with count per source]
|
||||
**Total signals processed:** [n]
|
||||
|
||||
#### Insight 1: [Underlying need, not feature request]
|
||||
- **Confidence:** High / Medium / Low (based on source diversity and weight)
|
||||
- **Evidence:** [Signals from each source supporting this]
|
||||
- **Conflicting signals:** [Any contradicting evidence and how to interpret it]
|
||||
- **Product implication:** [Specific next step, not generic]
|
||||
|
||||
[Repeat for top 3-5 insights]
|
||||
|
||||
#### Divergent Signals (Possible Segmentation)
|
||||
[Where user groups appear to have genuinely different needs — specify which segments]
|
||||
|
||||
#### What the Data Does NOT Tell Us
|
||||
[Gaps that require further research before acting]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every insight references at least 2 distinct source types
|
||||
- [ ] Surface requests are translated to underlying needs (not just echoed)
|
||||
- [ ] Divergent signals identify the specific user segments, not just "some users disagree"
|
||||
- [ ] Confidence ratings are consistent with source diversity and weighting
|
||||
- [ ] "What the data does NOT tell us" section is honest about gaps
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-analytics",
|
||||
"version": "3.0.0",
|
||||
"description": "Data & metrics skills: Data Analysis Standard, Retention Analysis, Product Health Analysis. Structure metric deep-dives, funnel analysis, cohort studies and churn investigations.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["product-management", "analytics", "retention", "metrics", "funnel", "cohort", "churn"]
|
||||
}
|
||||
BIN
Binary file not shown.
@@ -0,0 +1,126 @@
|
||||
---
|
||||
name: data-analysis-standard
|
||||
description: "Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action."
|
||||
---
|
||||
|
||||
# Data Analysis Standard Skill
|
||||
|
||||
Turn raw numbers into product decisions. Structure every analysis with a clear question, methodology, finding, and recommended action.
|
||||
|
||||
## Analysis Framework: The 4-Question Method
|
||||
|
||||
Every analysis starts here:
|
||||
1. **What changed?** (describe the metric and its movement)
|
||||
2. **Why did it change?** (root cause — segment, funnel step, cohort, channel)
|
||||
3. **So what?** (business or product impact)
|
||||
4. **Now what?** (recommended action with confidence level)
|
||||
|
||||
Never deliver data without answering all four. A chart with no narrative is not an analysis.
|
||||
|
||||
---
|
||||
|
||||
## Metric Triage Template
|
||||
|
||||
Use when a metric has moved unexpectedly:
|
||||
|
||||
```
|
||||
METRIC: [Name]
|
||||
MOVEMENT: [X% change over Y period]
|
||||
BASELINE: [What was normal]
|
||||
|
||||
SEGMENTATION CHECK:
|
||||
- By platform (iOS / Android / Web)?
|
||||
- By user cohort (new / returning / power users)?
|
||||
- By acquisition channel?
|
||||
- By geography?
|
||||
- By plan/tier?
|
||||
|
||||
ROOT CAUSE HYPOTHESIS:
|
||||
1. [Most likely explanation] — Evidence: [data point]
|
||||
2. [Alternative explanation] — Evidence: [data point]
|
||||
3. [Ruling out] — Eliminated because: [reason]
|
||||
|
||||
CONCLUSION: [Single sentence answer to "why did this change?"]
|
||||
CONFIDENCE: [High / Medium / Low] — based on [data available]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Funnel Analysis Structure
|
||||
|
||||
| Stage | Metric | Current | Benchmark/Target | Drop-off % | Notes |
|
||||
|---|---|---|---|---|---|
|
||||
| [Top of funnel] | [Users] | [N] | [N] | — | |
|
||||
| [Step 2] | [Users] | [N] | [N] | [X%] | |
|
||||
| [Step 3] | [Users] | [N] | [N] | [X%] | |
|
||||
| [Conversion] | [Users] | [N] | [N] | [X%] | |
|
||||
|
||||
**Biggest drop-off:** [Step X → Step Y] — Hypothesis: [reason]
|
||||
**Recommended investigation:** [specific query or test]
|
||||
|
||||
---
|
||||
|
||||
## Cohort Analysis Guidelines
|
||||
|
||||
Always define:
|
||||
- **Cohort definition:** [What groups users — signup week, first action, plan type]
|
||||
- **Retention metric:** [What counts as retained — login, core action, revenue]
|
||||
- **Retention window:** [D1, D7, D30, W4, M3, etc.]
|
||||
|
||||
Output a cohort retention table and annotate:
|
||||
- Baseline retention for each cohort
|
||||
- Cohorts that over/underperform and why (feature launch? campaign? seasonal?)
|
||||
- Trend direction across cohorts (improving / declining / stable)
|
||||
|
||||
---
|
||||
|
||||
## Stakeholder Analysis Output Format
|
||||
|
||||
### [Analysis Title] — [Date]
|
||||
|
||||
**Question being answered:** [Specific question in plain English]
|
||||
**Time period:** [Date range]
|
||||
**Data source:** [Where data comes from]
|
||||
|
||||
**Finding:**
|
||||
> [1–2 sentence plain-English summary of what the data shows]
|
||||
|
||||
**Key chart / table:** [Include or describe]
|
||||
|
||||
**Root cause:** [Best explanation with evidence]
|
||||
|
||||
**Confidence level:** [High / Medium / Low] — [reason]
|
||||
|
||||
**Recommended action:**
|
||||
1. [Immediate action — owner, timeline]
|
||||
2. [Investigation needed — what to check next]
|
||||
3. [Monitoring — what metric to watch and at what cadence]
|
||||
|
||||
**What this analysis does NOT tell us:** [Important caveat — what data is missing or what can't be concluded]
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Metric or question** being investigated
|
||||
- **Time period** (what changed, from when to when)
|
||||
- **Data available** (which segments, sources, or queries you have access to)
|
||||
- **Business context** (what decision this analysis informs)
|
||||
- **Audience** (who will read this — exec / team / data team)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Analysis answers all 4 questions: what changed, why, so what, now what
|
||||
- [ ] Root cause has evidence (not just hypothesis)
|
||||
- [ ] Confidence level is stated and justified
|
||||
- [ ] What the data cannot tell us is explicitly named
|
||||
- [ ] Recommended action includes an owner and timeline
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always state what the data *cannot* tell you — never oversell confidence
|
||||
- Correlations are not causation — flag this every time
|
||||
- If the user has no baseline, recommend establishing one before drawing conclusions
|
||||
- Recommend the simplest chart for each finding: bar for comparison, line for trends, scatter for correlation, table for detailed breakdowns
|
||||
- Always specify the time window — "conversion dropped" is meaningless without "from X to Y over Z period"
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: product-health-analysis
|
||||
description: "Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions."
|
||||
---
|
||||
|
||||
# Product Health Analysis Skill
|
||||
|
||||
Transform raw metrics data into a clear health narrative — what's working, what's not, and what needs immediate attention.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Metrics data** (current values for key metrics — even rough numbers work)
|
||||
- **Targets or benchmarks** (OKR targets, historical baselines, or industry benchmarks)
|
||||
- **Period** (week / month / quarter being analysed)
|
||||
- **Product area or segment** (are we looking at the whole product or a specific feature?)
|
||||
|
||||
## Metrics Framework
|
||||
Analyse across four layers:
|
||||
1. **Acquisition** — new users, source quality, CAC trends
|
||||
2. **Activation** — time to first value, onboarding completion rates
|
||||
3. **Engagement** — DAU/MAU, feature adoption, session depth
|
||||
4. **Retention** — D1/D7/D30 retention, churn rate, resurrection rate
|
||||
|
||||
## Process
|
||||
1. For each metric, compare: current period vs. previous period, current vs. target
|
||||
2. Flag anything more than 10% off target as requiring investigation
|
||||
3. Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
|
||||
4. Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
|
||||
5. Recommend top 3 areas for immediate investigation with suggested diagnostic steps
|
||||
6. **Validate** — Confirm every flagged metric has a plausible root cause hypothesis, not just a raw number, and every recommended action has a specific owner or team
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Product Health Report — [Period]
|
||||
**Overall Health:** 🟢 On Track / 🟡 Watch / 🔴 Action Required
|
||||
|
||||
| Metric | Current | Target | vs. Last Period | Status |
|
||||
|--------|---------|--------|-----------------|--------|
|
||||
| [metric] | [value] | [target] | [+/-%] | [🟢/🟡/🔴] |
|
||||
|
||||
**Key Observations:**
|
||||
[3-5 bullet observations written in plain English]
|
||||
|
||||
**Areas Requiring Investigation:**
|
||||
1. [Metric + hypothesis + suggested diagnostic]
|
||||
2. [Metric + hypothesis + suggested diagnostic]
|
||||
3. [Metric + hypothesis + suggested diagnostic]
|
||||
|
||||
**Recommended Actions:**
|
||||
[Specific next steps with owners and timelines]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every metric includes both a target and a trend (not just a snapshot)
|
||||
- [ ] At least one correlation is drawn between metrics (e.g., activation → retention)
|
||||
- [ ] Every flagged metric has a root cause hypothesis, not just "it dropped"
|
||||
- [ ] Observations are written for a non-technical stakeholder (no raw query language or data jargon)
|
||||
- [ ] Overall health rating is justified with specific evidence
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
name: retention-analysis
|
||||
description: "Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions."
|
||||
---
|
||||
|
||||
# Retention Analysis Skill
|
||||
|
||||
Diagnose why users leave, identify what keeps them, and recommend specific, testable interventions — not vague "improve onboarding" suggestions.
|
||||
|
||||
## Retention Fundamentals
|
||||
|
||||
**The retention curve has two components:**
|
||||
1. **Steepness of initial drop** (D1–D7) — onboarding problem
|
||||
2. **Long-term floor level** — product-market fit indicator
|
||||
|
||||
A product with PMF has a retention curve that flattens. If it trends to zero, you have a PMF problem, not an onboarding problem. Name this distinction explicitly.
|
||||
|
||||
---
|
||||
|
||||
## Retention Metrics Definitions
|
||||
|
||||
| Metric | Formula | What It Tells You |
|
||||
|---|---|---|
|
||||
| D1 Retention | Users who return on day 2 ÷ new users day 1 | Quality of first experience |
|
||||
| D7 Retention | Users active on day 8 ÷ users who joined 7 days ago | Early habit formation |
|
||||
| D30 Retention | Users active on day 31 ÷ users who joined 30 days ago | Product-market fit signal |
|
||||
| DAU/MAU Ratio | Daily active users ÷ monthly active users | Stickiness (>20% good, >50% excellent) |
|
||||
| Churn Rate | Users lost in period ÷ users at start of period | Monthly or annual |
|
||||
| Net Revenue Retention | MRR at end of period ÷ MRR at start (same cohort) | Revenue health including expansion |
|
||||
|
||||
---
|
||||
|
||||
## Retention Investigation Framework
|
||||
|
||||
### Step 1: Segment the problem
|
||||
Don't analyse "retention" — analyse retention for specific cohorts:
|
||||
- New vs returning users
|
||||
- Paid vs free
|
||||
- Acquisition channel (organic vs paid vs referral)
|
||||
- Onboarding path completed vs not
|
||||
- Feature usage (power users vs lurkers)
|
||||
|
||||
### Step 2: Find the inflection points
|
||||
Where does the drop happen? D1? D7? Month 3?
|
||||
- D1 drop → First session experience
|
||||
- D7 drop → Habit loop not formed
|
||||
- D30 drop → Value not delivered at depth
|
||||
- Month 3+ drop → Boredom, competition, or lifecycle event
|
||||
|
||||
### Step 3: Identify the "aha moment" correlation
|
||||
Which early behaviour predicts long-term retention?
|
||||
- Run correlation: users who did [X] in first 7 days vs 30-day retention
|
||||
- Common patterns: connected an integration, invited a teammate, completed a core action N times
|
||||
|
||||
### Step 4: Qualify the churn
|
||||
Interview churned users — never skip this. Survey data alone is insufficient.
|
||||
- "What was the trigger that led you to cancel/stop?"
|
||||
- "What were you trying to accomplish that you couldn't?"
|
||||
- "What would need to change for you to come back?"
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Retention Analysis — [Product/Segment] — [Date]
|
||||
|
||||
**Question:** [Specific retention question being answered]
|
||||
**Period Analysed:** [Date range]
|
||||
**Segment:** [Which users]
|
||||
|
||||
---
|
||||
|
||||
**Current Retention Snapshot:**
|
||||
|
||||
| Metric | Current | Industry Benchmark | Status |
|
||||
|---|---|---|---|
|
||||
| D1 Retention | [X%] | 25–40% | 🔴/🟡/🟢 |
|
||||
| D7 Retention | [X%] | 10–25% | 🔴/🟡/🟢 |
|
||||
| D30 Retention | [X%] | 5–15% | 🔴/🟡/🟢 |
|
||||
| DAU/MAU | [X%] | 10–20% typical | 🔴/🟡/🟢 |
|
||||
|
||||
**Retention Curve Shape:** [Flattening / Still declining / Trending to zero]
|
||||
**PMF Signal:** [Strong / Weak / Absent — based on curve shape]
|
||||
|
||||
---
|
||||
|
||||
**Root Cause Hypotheses:**
|
||||
|
||||
| Hypothesis | Evidence | Confidence | Test |
|
||||
|---|---|---|---|
|
||||
| [Cause] | [Data point] | H/M/L | [How to validate] |
|
||||
|
||||
**"Aha Moment" Correlation:**
|
||||
Users who [specific action] in first [N] days retain at [X%] vs [Y%] for those who don't.
|
||||
|
||||
---
|
||||
|
||||
**Recommended Interventions:**
|
||||
|
||||
| Intervention | Target Drop | Expected Lift | Effort | Priority |
|
||||
|---|---|---|---|---|
|
||||
| [Specific change] | D1 / D7 / D30 | [X%] | S/M/L | 1/2/3 |
|
||||
|
||||
**Monitoring Plan:**
|
||||
- Metric to track: [X]
|
||||
- Review cadence: [Weekly / Monthly]
|
||||
- Alert threshold: [If X drops below Y, investigate immediately]
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product and business model** (SaaS / consumer app / marketplace / other)
|
||||
- **Current retention metrics** (D1, D7, D30 if available)
|
||||
- **Segment to analyse** (all users / paid / free / a specific cohort)
|
||||
- **Key question to answer** (why is retention dropping? what drives retention?)
|
||||
- **Available data** (analytics events, churn surveys, interview notes)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Retention curve shape is diagnosed (flattening vs trending to zero = PMF vs onboarding)
|
||||
- [ ] Cohorts are segmented before analysis (not all users lumped together)
|
||||
- [ ] "Aha moment" correlation is identified or flagged as unknown
|
||||
- [ ] Interventions are specific (not "improve onboarding")
|
||||
- [ ] Churned user interviews are recommended (not just data analysis)
|
||||
- [ ] Monitoring plan includes an alert threshold
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never recommend "improve onboarding" without specifying *what* to change and *why*
|
||||
- Benchmark against industry — consumer apps, SaaS, and marketplaces have very different retention norms
|
||||
- If DAU/MAU is below 5%, that's a PMF conversation, not a retention tactics conversation
|
||||
- Always recommend talking to churned users — no amount of data replaces understanding the *reason*
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$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"]
|
||||
}
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
name: board-deck-narrative
|
||||
description: "Build the storyline and slide structure for a board presentation. Use when asked to create a board deck, board presentation narrative, board meeting slides, or quarterly board update. Produces a complete slide-by-slide structure with narrative beats, talking points, and slide content guidance."
|
||||
---
|
||||
|
||||
# Board Deck Narrative Skill
|
||||
|
||||
This skill builds the complete narrative and slide structure for a board presentation — from opening framing to closing asks. It produces slide-by-slide content guidance, not just a list of topics.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Company stage and context** (Seed / Series A / Growth — and where you are in the year)
|
||||
- **Board meeting type** (Regular quarterly / Annual / Special / Fundraise-related)
|
||||
- **Key themes for this meeting** (e.g. strong growth quarter / pivoting strategy / hiring challenge / fundraise update)
|
||||
- **Key metrics to feature**
|
||||
- **Decisions needed from the board** (if any)
|
||||
- **Time available** (e.g. 60 min / 90 min)
|
||||
- **Audience** (investors only / investors + independent directors / mixed)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Board Deck Narrative: [Company] — [Quarter/Period]
|
||||
|
||||
**Meeting type:** [Regular quarterly / Special]
|
||||
**Time:** [X minutes]
|
||||
**Narrative theme:** [The one-sentence story of this quarter — e.g. "We hit our revenue target, but activation is the problem we need to solve together."]
|
||||
|
||||
---
|
||||
|
||||
## Opening Frame (Slide 1–2)
|
||||
|
||||
**Slide 1: Title**
|
||||
- Company name, quarter, date
|
||||
- One-sentence framing of the meeting's narrative arc
|
||||
|
||||
**Slide 2: Agenda**
|
||||
- List of sections + time allocation
|
||||
- Flag which sections need board input vs. are informational
|
||||
|
||||
*Presenter note: Board members are busy. Tell them in the first 2 minutes what you need from them today. It changes how they listen.*
|
||||
|
||||
---
|
||||
|
||||
## Business Performance (Slides 3–6, ~15 min)
|
||||
|
||||
**Slide 3: Scorecard / KPI Dashboard**
|
||||
- Content: Key metrics vs. targets for the quarter. No more than 6 metrics.
|
||||
- Format: Traffic-light table (Green / Amber / Red against plan)
|
||||
- Narrative: [1–2 sentences — the headline story of the quarter in numbers]
|
||||
- *Don't hide reds. Boards lose trust when they discover hidden problems later.*
|
||||
|
||||
**Slide 4: Revenue / Growth Deep Dive**
|
||||
- Content: Revenue breakdown by segment, cohort retention, growth drivers
|
||||
- Key message: [What the data shows about the health of growth]
|
||||
- Call out: [Any trend that needs board context or discussion]
|
||||
|
||||
**Slide 5: Unit Economics**
|
||||
- Content: CAC, LTV, payback period, gross margin — vs. last quarter and vs. plan
|
||||
- Flag: Any metric moving in the wrong direction and what's causing it
|
||||
|
||||
**Slide 6: Operational Highlights**
|
||||
- Content: 3–5 bullet points of the most significant things that happened this quarter
|
||||
- Format: Each bullet = outcome, not activity. ("Signed 3 enterprise contracts worth £400K ARR" not "Continued enterprise sales motion")
|
||||
|
||||
---
|
||||
|
||||
## Strategic Update (Slides 7–9, ~15 min)
|
||||
|
||||
**Slide 7: Strategy Snapshot**
|
||||
- Content: Where you said you'd be vs. where you are against the annual plan
|
||||
- Narrative: [Honest assessment — what's on track, what's shifted and why]
|
||||
|
||||
**Slide 8: Key Strategic Decision or Update**
|
||||
- Content: The one strategic topic that most needs board input this meeting
|
||||
- Format: Context → Options considered → Recommendation → Question for board
|
||||
- *This is the highest-value 10 minutes of the meeting. Frame it as a real question.*
|
||||
|
||||
**Slide 9: Product & Roadmap (if relevant)**
|
||||
- Content: Top 3 product bets this quarter — what shipped, what's coming, why these bets
|
||||
- Tailored for: What the board needs to understand to support strategic decisions, not a sprint review
|
||||
|
||||
---
|
||||
|
||||
## People & Organisation (Slide 10, ~5 min)
|
||||
|
||||
**Slide 10: Team Update**
|
||||
- Content: Headcount (start vs. end of quarter), key hires made, open roles, any org changes
|
||||
- Flag: Any people risks or leadership gaps the board should know about
|
||||
- *Don't skip this slide. Board members often have network value here.*
|
||||
|
||||
---
|
||||
|
||||
## Financial Update (Slides 11–12, ~10 min)
|
||||
|
||||
**Slide 11: P&L Summary**
|
||||
- Content: Revenue, gross margin, opex by category, EBITDA/net burn — actual vs. budget
|
||||
- Include: Year-to-date vs. annual plan
|
||||
|
||||
**Slide 12: Cash & Runway**
|
||||
- Content: Cash on hand, monthly burn rate, runway at current burn
|
||||
- Include: Scenario if burn increases (e.g. key hire made), scenario if growth accelerates
|
||||
- Flag immediately: If runway is < 18 months — this needs board awareness and planning
|
||||
|
||||
---
|
||||
|
||||
## Closing & Asks (Slides 13–14, ~10 min)
|
||||
|
||||
**Slide 13: Priorities for Next Quarter**
|
||||
- Content: Top 3–5 priorities and what success looks like for each
|
||||
- Format: Priority | What we're doing | How we'll know it worked
|
||||
- *Keeps board accountability consistent across meetings*
|
||||
|
||||
**Slide 14: Board Asks**
|
||||
- Content: Specific things you need from board members before next meeting
|
||||
- Format: Each ask = specific, named if possible ("Looking for an intro to [Company] — [Board member X], do you have a connection?")
|
||||
- *A board meeting without specific asks is a missed opportunity*
|
||||
|
||||
---
|
||||
|
||||
## Appendix (Optional)
|
||||
|
||||
- Detailed cohort analysis
|
||||
- Competitive landscape update
|
||||
- Full P&L
|
||||
- Team org chart
|
||||
- Any supporting data referenced in the main deck
|
||||
|
||||
*Appendix slides are available but not presented. Board members who want detail can ask.*
|
||||
|
||||
---
|
||||
|
||||
## Narrative Principles
|
||||
|
||||
- **Lead with honesty.** If it was a hard quarter, say so in the first slide. Don't bury bad news after the wins.
|
||||
- **One slide = one idea.** If a slide has two messages, split it.
|
||||
- **Fewer slides, more depth.** A 14-slide deck presented well beats a 35-slide deck rushed through.
|
||||
- **Every slide has a "so what."** A slide that just shows data without a takeaway wastes board time.
|
||||
- **Leave time for discussion.** Board value is in the conversation, not the presentation. Aim to spend 40% of the meeting presenting and 60% in discussion.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Opening frame states the meeting's narrative theme
|
||||
- [ ] Scorecard slide uses traffic-light format (not just green metrics)
|
||||
- [ ] Strategic decision slide frames a real question for the board
|
||||
- [ ] Financial slide includes runway explicitly
|
||||
- [ ] Board asks are specific and actionable
|
||||
- [ ] Deck is ≤ 15 slides (excluding appendix)
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a board deck structure for our Q[N] board meeting"
|
||||
- "Help me create the narrative for our board presentation"
|
||||
- "Write the slide structure for our annual board review"
|
||||
- "Design a board deck for [specific context — e.g. fundraise update]"
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
name: investor-update
|
||||
description: "Write a structured monthly or quarterly investor update. Use when asked to write an investor update, investor newsletter, board update, or startup progress report for investors. Produces a clear, credible update with highlights, metrics, challenges, and asks — in the format investors actually want to read."
|
||||
---
|
||||
|
||||
# Investor Update Skill
|
||||
|
||||
This skill writes a complete investor update — structured for clarity, honest about challenges, and specific about asks. Output follows the format preferred by most early-stage and growth investors.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Company name and stage** (Seed / Series A / Series B / etc.)
|
||||
- **Period covered** (month or quarter)
|
||||
- **Key metrics this period** (revenue, MRR, users, churn, burn, runway — whatever's relevant)
|
||||
- **Biggest wins**
|
||||
- **Biggest challenges or misses**
|
||||
- **Specific asks from investors** (intros, advice, talent, partnerships)
|
||||
- **What's coming next period**
|
||||
- **Tone** (formal / conversational — most investors prefer conversational)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
**[Company Name] — [Month/Quarter] Update**
|
||||
*[Date]*
|
||||
|
||||
---
|
||||
|
||||
Hi [Investor names or "all"],
|
||||
|
||||
[One or two sentence opener — a specific highlight or honest framing of the period. Don't open with "Hope you're well." Open with the most important thing that happened.]
|
||||
|
||||
---
|
||||
|
||||
## The Numbers
|
||||
|
||||
| Metric | This Period | Last Period | Change |
|
||||
|---|---|---|---|
|
||||
| [MRR / ARR] | [Value] | [Value] | [+/- %] |
|
||||
| [Active users / customers] | | | |
|
||||
| [Churn rate] | | | |
|
||||
| [Burn rate] | | | |
|
||||
| [Runway] | | | |
|
||||
| [Other key metric] | | | |
|
||||
|
||||
[1–2 sentences of narrative on the numbers — what's the story behind the movement? Don't just repeat the table.]
|
||||
|
||||
---
|
||||
|
||||
## Highlights
|
||||
|
||||
**[Highlight 1 — 4–6 word title]**
|
||||
[2–4 sentences. What happened. Why it matters. Be specific — name the customer, the number, the milestone.]
|
||||
|
||||
**[Highlight 2]**
|
||||
[2–4 sentences]
|
||||
|
||||
**[Highlight 3 — optional]**
|
||||
|
||||
---
|
||||
|
||||
## Challenges
|
||||
|
||||
[This section is what separates trustworthy updates from self-promotional ones. Investors know you have challenges. Being direct builds trust.]
|
||||
|
||||
**[Challenge 1]**
|
||||
[2–4 sentences. What the problem is. What you've tried. What you're doing about it. Don't spin — investors see through it.]
|
||||
|
||||
**[Challenge 2 — if applicable]**
|
||||
|
||||
---
|
||||
|
||||
## Focus for Next [Month/Quarter]
|
||||
|
||||
[3–5 bullet points. What you're concentrating on next period and why. Keep it tight — not an exhaustive roadmap.]
|
||||
|
||||
- [Priority 1]
|
||||
- [Priority 2]
|
||||
- [Priority 3]
|
||||
|
||||
---
|
||||
|
||||
## Asks
|
||||
|
||||
[Be specific. "Let me know if you can help" is not an ask. These should be actionable items an investor can act on immediately.]
|
||||
|
||||
1. **[Ask type: e.g. Intro]** — [Specific request. e.g. "Looking for an intro to procurement leads at mid-market SaaS companies. Happy to share a warm intro note."]
|
||||
2. **[Ask type: e.g. Advice]** — [Specific question you want input on]
|
||||
3. **[Ask type: e.g. Talent]** — [Specific hire you're looking for — title, key requirements]
|
||||
|
||||
---
|
||||
|
||||
[Closing line — 1 sentence. Forward-looking or a genuine thanks. Not "as always, let me know if you have questions."]
|
||||
|
||||
[Signature]
|
||||
[Name]
|
||||
[Company]
|
||||
[One way to reply — email / Calendly / reply to this thread]
|
||||
|
||||
---
|
||||
|
||||
## Writing Rules
|
||||
|
||||
- Updates should take an investor 3–4 minutes to read. If it's longer, trim it.
|
||||
- Never lead with process ("This month we focused on...") — lead with outcomes
|
||||
- Challenges section must be honest. A missing challenges section signals the founder isn't self-aware or isn't being transparent.
|
||||
- Metrics table must include comparison to last period — a number without context is meaningless
|
||||
- Asks must be specific enough that an investor knows within 5 seconds if they can help
|
||||
- No jargon or buzzwords ("synergies," "crushing it," "hockey stick") — plain language only
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Opens with a specific highlight or honest framing (not a pleasantry)
|
||||
- [ ] Numbers include period-over-period comparison
|
||||
- [ ] Challenges section is present and honest
|
||||
- [ ] Asks are specific and actionable
|
||||
- [ ] Total length is skimmable in 3–4 minutes
|
||||
- [ ] No spin or buzzwords
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write an investor update for [month/quarter]"
|
||||
- "Draft a monthly update for our investors based on these notes: [paste notes]"
|
||||
- "Help me write a board update for Q[N]"
|
||||
- "Write our Series A investor newsletter"
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
name: job-application
|
||||
description: "Tailor a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter."
|
||||
---
|
||||
|
||||
# Job Application Skill
|
||||
|
||||
This skill tailors a CV and cover letter to a specific job description — optimising for ATS keyword matching while keeping the writing human and compelling. It also flags gaps between the candidate's profile and the role requirements.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Job description** (paste in full)
|
||||
- **Current CV / resume** (paste or describe key experience, roles, and skills)
|
||||
- **The specific thing that excites them about this role** (used in the cover letter — must be genuine)
|
||||
- **Any particular strengths to emphasise** (optional)
|
||||
- **Any gaps they're worried about** (optional — helps address them proactively)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
## Part 1: JD Analysis
|
||||
|
||||
Before writing anything, analyse the job description and output:
|
||||
|
||||
### Must-Have Requirements
|
||||
[List explicit requirements from the JD — qualifications, years of experience, specific skills]
|
||||
|
||||
### Key Themes in the JD
|
||||
[3–5 themes that repeat or are emphasised — these are the keywords and priorities the hiring manager cares about most]
|
||||
|
||||
### ATS Keywords to Include
|
||||
[List 10–15 specific keywords and phrases from the JD that should appear in the CV and cover letter. Include: tools, methodologies, job titles, skills]
|
||||
|
||||
### Gaps Assessment
|
||||
[Honest comparison between the candidate's profile and the JD requirements. Flag: "Strong match" / "Partial match — can be positioned as X" / "Gap — address in cover letter or don't apply"]
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Tailored CV Summary / Profile Section
|
||||
|
||||
Rewrite or create the candidate's CV summary/profile section (the 3–5 lines at the top of a CV) specifically for this role:
|
||||
|
||||
**Rules:**
|
||||
- Open with the job title or a near-match (ATS reward)
|
||||
- Include 2–3 keywords from the JD naturally
|
||||
- Reference years of experience in the relevant area
|
||||
- End with a forward-looking line connecting their background to what this role needs
|
||||
- Keep to 60–80 words maximum
|
||||
|
||||
**Tailored CV Summary:**
|
||||
[Write the summary]
|
||||
|
||||
---
|
||||
|
||||
## Part 3: Experience Bullet Point Rewrites
|
||||
|
||||
For the 2–3 most relevant roles on the CV, suggest how to reframe existing bullet points to better match this JD:
|
||||
|
||||
**[Role Title] at [Company]**
|
||||
|
||||
| Original Bullet | Tailored Version | Why |
|
||||
|---|---|---|
|
||||
| [Candidate's original text] | [Improved version with JD keywords and stronger impact framing] | [Brief note on what changed] |
|
||||
|
||||
**Rules for bullet point rewrites:**
|
||||
- Lead with an action verb
|
||||
- Include a quantified outcome where possible (%, £, time saved, users impacted)
|
||||
- Weave in JD keywords naturally — not forced
|
||||
- Keep to one line (2 max)
|
||||
|
||||
---
|
||||
|
||||
## Part 4: Cover Letter
|
||||
|
||||
**Format:** 3 paragraphs + closing. Target: 250–350 words. Anything longer won't be read.
|
||||
|
||||
---
|
||||
|
||||
[Hiring Manager's name if known, otherwise "Hiring Team"]
|
||||
|
||||
**Paragraph 1 — The Hook (Why this role, specifically)**
|
||||
[2–4 sentences. Reference something specific about the company or role — not generic enthusiasm. The candidate's genuine reason for applying goes here. This is what makes it human. Generic openers like "I am writing to apply for..." are filtered out mentally within 3 seconds.]
|
||||
|
||||
**Paragraph 2 — The Evidence (Why them)**
|
||||
[3–5 sentences. 2–3 specific examples from their background that directly address the JD's key themes. Use the language of the JD. Include at least one quantified achievement. Don't list everything — pick the 2–3 strongest matches and go deep, not broad.]
|
||||
|
||||
**Paragraph 3 — The Forward Bridge (Why now)**
|
||||
[2–3 sentences. Connect their trajectory to this role. Why is this the logical next step? What do they want to learn or build that this role enables? This should feel like the natural continuation of their career, not just "I want a new challenge."]
|
||||
|
||||
---
|
||||
|
||||
I'd welcome the chance to discuss how my background could contribute to [Company/Team]. Thank you for your time.
|
||||
|
||||
[Name]
|
||||
[Email] | [LinkedIn URL] | [Location if relevant]
|
||||
|
||||
---
|
||||
|
||||
## Part 5: Application Checklist
|
||||
|
||||
Before submitting:
|
||||
- [ ] CV summary updated with tailored version above
|
||||
- [ ] ATS keywords appear in CV body (not just summary)
|
||||
- [ ] Cover letter is under 400 words
|
||||
- [ ] Company name is spelled correctly throughout (sounds obvious — it happens)
|
||||
- [ ] No generic phrases: "passionate about," "results-driven," "team player" without evidence
|
||||
- [ ] LinkedIn profile updated to match CV (recruiters cross-check)
|
||||
- [ ] Role title in subject line if emailing directly
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] JD analysis completed before writing (not skipped)
|
||||
- [ ] ATS keywords are integrated naturally (not stuffed)
|
||||
- [ ] Cover letter opens with something specific (not a generic opener)
|
||||
- [ ] Paragraph 2 includes at least one quantified achievement
|
||||
- [ ] Cover letter is 250–350 words
|
||||
- [ ] Gaps are either addressed or strategically omitted
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Help me apply for this job: [paste JD]"
|
||||
- "Tailor my CV for this role: [paste JD + CV]"
|
||||
- "Write a cover letter for [role] at [company]"
|
||||
- "Optimise my application for ATS for this job description"
|
||||
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-cross",
|
||||
"version": "1.1.0",
|
||||
"description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary, Teaching Lesson Plan. Write journalist-ready press releases, structure grant applications, produce decision-ready executive summaries, and design complete lesson plans for any subject, audience, or setting.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["communications", "press-release", "grant", "executive-summary", "briefing", "funding", "media", "education", "teaching", "lesson-plan", "training"]
|
||||
}
|
||||
@@ -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,102 @@
|
||||
---
|
||||
name: grant-proposal
|
||||
description: "Write a structured grant proposal or funding application for any grant type. Use when asked to write a grant proposal, funding application, research grant, charitable grant, or innovation fund application. Produces a complete proposal with project summary, rationale, methodology, impact, and budget narrative."
|
||||
---
|
||||
|
||||
# Grant Proposal Skill
|
||||
|
||||
Produces structured grant proposals tailored to the funder priorities — the most common reason grants fail is writing about what you want to do rather than what the funder wants to fund.
|
||||
|
||||
## Required Inputs
|
||||
- **Funder name and grant programme**
|
||||
- **Grant amount sought**
|
||||
- **Project description** (rough notes are fine)
|
||||
- **Your organisation** (type, track record, capacity)
|
||||
- **Funder stated priorities** (copy from their guidance — essential)
|
||||
- **Word or page limits**
|
||||
- **Deadline**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
### Project Title
|
||||
[Informative and memorable. Should convey the problem being solved and the approach.]
|
||||
|
||||
### 1. Project Summary / Abstract (200-300 words — written last, placed first)
|
||||
[What you will do, why it matters, who will benefit, measurable outcomes. Every sentence earns its place.]
|
||||
|
||||
### 2. Problem Statement / Need
|
||||
- **The problem:** [Specific, evidenced — use data]
|
||||
- **Who is affected:** [Population, scale, geography]
|
||||
- **Current situation:** [What exists and why it is insufficient]
|
||||
- **Consequence of inaction:** [What happens if not funded]
|
||||
- **Why your organisation:** [Track record, relationships, expertise]
|
||||
|
||||
Funder test: does this problem align with [funder] stated priorities? Make the connection explicit.
|
||||
|
||||
### 3. Project Objectives
|
||||
3-5 SMART objectives:
|
||||
- **Objective 1:** [Specific, Measurable, Achievable, Relevant, Time-bound]
|
||||
|
||||
### 4. Methodology / Approach
|
||||
|
||||
**Phase 1: [Name]** (Months 1-X)
|
||||
[What will happen, who will do it, what is produced]
|
||||
|
||||
**Key activities:**
|
||||
- [Activity — specific]
|
||||
|
||||
**What makes this approach innovative or effective:** [Why this over alternatives]
|
||||
|
||||
### 5. Impact and Outcomes
|
||||
|
||||
| Level | Description | Measure |
|
||||
|---|---|---|
|
||||
| Output | [Tangible deliverable] | [How counted] |
|
||||
| Short-term outcome | [Immediate change] | [How measured] |
|
||||
| Medium-term outcome | [Behaviour change] | [How measured] |
|
||||
| Long-term impact | [Systemic change] | [How evidenced] |
|
||||
|
||||
**Direct beneficiaries:** [Who and how many]
|
||||
**Sustainability:** [How work continues beyond grant period]
|
||||
|
||||
### 6. Evaluation Plan
|
||||
- Who evaluates, how, when, what is measured, how findings are shared
|
||||
|
||||
### 7. Budget Narrative
|
||||
|
||||
| Budget line | Amount | Justification |
|
||||
|---|---|---|
|
||||
| Staff costs | £[amount] | [Role, % FTE, duration, salary] |
|
||||
| Travel | £[amount] | [Specific journeys named] |
|
||||
| Equipment | £[amount] | [Itemised] |
|
||||
| Indirect costs | £[amount] | [[X]% of direct — check policy] |
|
||||
| **Total** | **£[total]** | |
|
||||
|
||||
**Value for money:** [Cost per beneficiary. What could not be done without this grant]
|
||||
|
||||
### 8. Organisational Capacity
|
||||
[Track record of similar projects, governance, financial management. Name previous grants and outputs — be specific]
|
||||
|
||||
### 9. Risk Register
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|---|---|---|---|
|
||||
| [Risk] | H/M/L | H/M/L | [Specific mitigation] |
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every section explicitly references funder stated priorities (not just generic language)
|
||||
- [ ] Problem statement includes specific data, not just assertions
|
||||
- [ ] Objectives are SMART (measurable and time-bound)
|
||||
- [ ] Budget narrative justifies every line with specific detail
|
||||
- [ ] Sustainability section explains what happens after the grant ends
|
||||
- [ ] Word limits respected
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a grant proposal for [project] applying to [funder]"
|
||||
- "Help me write a funding application for [grant programme]"
|
||||
- "Turn these project notes into a grant proposal: [paste]"
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
name: press-release
|
||||
description: "Write a professional press release for any announcement. Use when asked to write a press release, media announcement, news release, or press statement. Produces a structured press release with headline, dateline, body, boilerplate, and media contact — ready to send to journalists."
|
||||
---
|
||||
|
||||
# Press Release Skill
|
||||
|
||||
Writes press releases that journalists actually read — structured around the news angle, not the desire to promote.
|
||||
|
||||
## Required Inputs
|
||||
- **The news** (what is actually happening — be specific)
|
||||
- **Company name**
|
||||
- **Date of announcement / embargo date**
|
||||
- **Key quote** (from which executive and approximately what they want to say)
|
||||
- **Why this matters** (to the reader, not the company)
|
||||
- **Target media** (trade / national / local / consumer / investor)
|
||||
- **Media contact details**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
FOR IMMEDIATE RELEASE / EMBARGOED UNTIL: [Date and time]
|
||||
|
||||
---
|
||||
|
||||
# [Headline — active verb, specific news, under 10 words]
|
||||
## [Subheadline — the so-what in one sentence, adds context not repetition]
|
||||
|
||||
**[City, Date]** — [Opening paragraph: Who, What, When, Where, Why in 2-3 sentences. A journalist should be able to run this paragraph alone. No background, no context, no company history.]
|
||||
|
||||
[Second paragraph: the significance. Why does this matter? What does it mean for customers or the industry?]
|
||||
|
||||
[Third paragraph: quote from executive. Human and specific. Not a restatement of the headline.]
|
||||
|
||||
"[Quote text — specific, adds something the facts do not say]," said [Name], [Title] at [Company]. "[Second sentence extending the thought]."
|
||||
|
||||
[Fourth paragraph: supporting detail — data, customer names with permission, additional context]
|
||||
|
||||
[Fifth paragraph optional: what happens next, when it goes live, what people can do]
|
||||
|
||||
---
|
||||
|
||||
ENDS
|
||||
|
||||
---
|
||||
|
||||
**Notes to editors:**
|
||||
|
||||
**About [Company]**
|
||||
[Boilerplate: 3-4 sentences. What the company does, when founded, where based, key facts. Factual not promotional.]
|
||||
|
||||
**Media contact:**
|
||||
[Name] | [Title] | [Email] | [Phone] | [Hours/timezone]
|
||||
|
||||
---
|
||||
|
||||
## Headline Rules
|
||||
- Active voice: "Company launches X" not "X is launched by Company"
|
||||
- Specific: "raises 5M" not "secures significant investment"
|
||||
- Under 10 words
|
||||
- Never start with the company name — lead with the news
|
||||
|
||||
## Journalist Test
|
||||
Would a journalist care? Is the headline the full story? Is there a human angle? Is the quote something a human would say? Can the first paragraph stand alone?
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Headline uses active voice and is under 10 words
|
||||
- [ ] First paragraph stands alone as the complete story
|
||||
- [ ] Quote adds something the facts don't say (not a restatement)
|
||||
- [ ] Boilerplate is factual, not promotional
|
||||
- [ ] Embargo date and media contact are included
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a press release announcing [news]"
|
||||
- "Draft a media statement about [event]"
|
||||
- "We are launching [product] — write the press release"
|
||||
- "Turn this announcement into a press release: [paste notes]"
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: teaching-lesson-plan
|
||||
description: "Design a structured lesson plan for any subject, audience, or format. Use when asked to write a lesson plan, course outline, teaching session, workshop curriculum, or training module. Produces a complete lesson plan with learning objectives, activities, timing, assessment, and differentiation guidance."
|
||||
---
|
||||
|
||||
# Teaching Lesson Plan Skill
|
||||
|
||||
Produces a complete, structured lesson plan for any subject, age group, or setting — from a one-hour corporate training to a full school lesson. Built around clear learning objectives, varied activities, and formative assessment.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Subject or topic**
|
||||
- **Audience** (age group, experience level, group size)
|
||||
- **Session length** (30 / 45 / 60 / 90 / 120 minutes)
|
||||
- **Setting** (classroom / workshop / online / corporate training / one-to-one)
|
||||
- **Learning goal** (what should participants know or be able to do by the end?)
|
||||
- **Prior knowledge** (what can you assume they already know?)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Lesson Plan: [Topic]
|
||||
|
||||
**Subject:** [Subject] | **Audience:** [Description] | **Duration:** [X minutes]
|
||||
**Setting:** [Setting] | **Group size:** [N]
|
||||
|
||||
---
|
||||
|
||||
## Learning Objectives
|
||||
|
||||
By the end of this session, participants will be able to:
|
||||
1. [Objective 1 — use Bloom's taxonomy verbs: recall, explain, apply, analyse, evaluate, create]
|
||||
2. [Objective 2]
|
||||
3. [Objective 3 — maximum 3–4 objectives per session]
|
||||
|
||||
**Key vocabulary:** [3–5 terms participants will need to know]
|
||||
|
||||
---
|
||||
|
||||
## Materials and Preparation
|
||||
|
||||
- [ ] [Resource 1 — slides, handout, equipment]
|
||||
- [ ] [Resource 2]
|
||||
- [ ] Room setup: [configuration — rows / circles / tables / breakout spaces]
|
||||
|
||||
---
|
||||
|
||||
## Lesson Structure
|
||||
|
||||
| Time | Phase | Activity | Format |
|
||||
|---|---|---|---|
|
||||
| [00:00] | Hook / Opener | [How you grab attention and establish relevance] | [Whole group / Individual / Pairs] |
|
||||
| [00:05] | Prior knowledge | [How you connect to what they already know] | [Discussion / Quiz / Think-pair-share] |
|
||||
| [00:15] | Instruction | [Direct teaching of new content] | [Explanation / Demo / Video] |
|
||||
| [00:30] | Guided practice | [Supported practice with feedback] | [Worked examples / Group task] |
|
||||
| [00:50] | Independent practice | [Students apply learning independently] | [Task / Problem / Discussion] |
|
||||
| [01:05] | Check for understanding | [Formative assessment] | [Exit ticket / Quiz / Q&A] |
|
||||
| [01:15] | Closure | [Summarise, connect to next session] | [Whole group] |
|
||||
|
||||
---
|
||||
|
||||
## Key Explanations and Worked Examples
|
||||
|
||||
### [Concept 1]
|
||||
[Clear explanation + one concrete worked example. Explain the concept the way a good teacher would — no jargon without definition, one idea at a time.]
|
||||
|
||||
### [Concept 2]
|
||||
[Explanation + example]
|
||||
|
||||
---
|
||||
|
||||
## Differentiation
|
||||
|
||||
**For those who need more support:**
|
||||
- [Scaffold: e.g. sentence starters, worked examples, vocabulary cards]
|
||||
- [Modified task or reduced scope]
|
||||
|
||||
**For those ready for a challenge:**
|
||||
- [Extension: e.g. apply to a new context, evaluate, create something]
|
||||
|
||||
---
|
||||
|
||||
## Formative Assessment (Check for Understanding)
|
||||
|
||||
**During session:**
|
||||
- [Method 1: e.g. Cold calling with no-stakes approach, thumbs up/down, mini whiteboards]
|
||||
- [Method 2: e.g. Think-pair-share before moving on]
|
||||
|
||||
**Exit ticket (last 5 minutes):**
|
||||
[One specific question that directly tests the learning objective — not "what did you enjoy?" but "solve this problem" or "explain this concept in your own words"]
|
||||
|
||||
---
|
||||
|
||||
## Common Misconceptions to Address
|
||||
|
||||
| Misconception | Correct understanding | How to address it |
|
||||
|---|---|---|
|
||||
| [What learners often get wrong] | [The correct version] | [Specific activity or explanation] |
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Learning objectives use action verbs (not "understand" or "know")
|
||||
- [ ] Session has a clear hook that establishes relevance
|
||||
- [ ] Activities are varied (not all listening)
|
||||
- [ ] Formative assessment checks the actual learning objective
|
||||
- [ ] Differentiation is specified for both support and extension
|
||||
- [ ] Timing adds up to session length
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a lesson plan on [topic] for [audience]"
|
||||
- "Design a 60-minute session on [subject]"
|
||||
- "Create a training module on [skill]"
|
||||
- "Plan a workshop on [topic] for [group]"
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$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"]
|
||||
}
|
||||
@@ -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,122 @@
|
||||
---
|
||||
name: dashboard-brief
|
||||
description: "Convert a business question into a complete dashboard specification. Use when asked to design a dashboard, create a dashboard spec or brief, plan a BI report, or define what charts and metrics a dashboard should include. Produces a structured spec with metrics, dimensions, chart types, filters, and layout guidance."
|
||||
---
|
||||
|
||||
# Dashboard Brief Skill
|
||||
|
||||
This skill converts a business question or monitoring need into a complete, implementation-ready dashboard specification. The output gives a data engineer or BI developer everything they need to build without a follow-up meeting.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The business question this dashboard should answer** (e.g. "How is our activation funnel performing this week?")
|
||||
- **Primary audience** (exec / product team / operations / customer success / engineering)
|
||||
- **Refresh cadence** (real-time / hourly / daily / weekly)
|
||||
- **Data sources available** (e.g. Postgres, BigQuery, Mixpanel, Salesforce, Jira)
|
||||
- **BI tool being used** (Looker / Metabase / Tableau / Power BI / Grafana / Custom / Unknown)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Dashboard Brief: [Dashboard Name]
|
||||
|
||||
**Business Question:** [The question this dashboard answers — verbatim from inputs or refined]
|
||||
**Audience:** [Who uses this]
|
||||
**Refresh Rate:** [Real-time / Hourly / Daily / Weekly]
|
||||
**Data Sources:** [List]
|
||||
**BI Tool:** [Tool or Unknown]
|
||||
|
||||
---
|
||||
|
||||
## Section 1: Key Metrics (KPI Cards)
|
||||
|
||||
List the headline numbers that should appear at the top of the dashboard as KPI cards.
|
||||
|
||||
| Metric | Definition | Data Source | Comparison |
|
||||
|---|---|---|---|
|
||||
| [Metric name] | [How it's calculated] | [Table/source] | [vs. last week / vs. target / MoM] |
|
||||
|
||||
Aim for 3–6 KPI cards. More than 6 is noise.
|
||||
|
||||
---
|
||||
|
||||
## Section 2: Charts & Visualisations
|
||||
|
||||
For each chart, specify:
|
||||
|
||||
### Chart [N]: [Chart Title]
|
||||
|
||||
- **Chart type:** [Line / Bar / Stacked bar / Pie / Funnel / Heatmap / Table / Scatter]
|
||||
- **Why this chart type:** [One sentence — why this type suits this data]
|
||||
- **X-axis / Rows:** [Dimension — e.g. Date, User segment, Product]
|
||||
- **Y-axis / Values:** [Metric — e.g. Count of active users, Revenue]
|
||||
- **Breakdown/colour:** [Optional secondary dimension — e.g. by Plan tier, by Channel]
|
||||
- **Data source:** [Table or source]
|
||||
- **Filters:** [Any default filters applied — e.g. "Exclude internal test accounts"]
|
||||
- **Key insight to surface:** [What pattern or signal this chart should help the viewer spot]
|
||||
|
||||
---
|
||||
|
||||
## Section 3: Filters & Controls
|
||||
|
||||
Global filters available to dashboard viewers:
|
||||
|
||||
| Filter | Type | Default | Options |
|
||||
|---|---|---|---|
|
||||
| Date range | Date picker | Last 30 days | Custom |
|
||||
| [Segment filter] | Dropdown | All | [List relevant values] |
|
||||
| [Other filter] | Multi-select | All | [List relevant values] |
|
||||
|
||||
---
|
||||
|
||||
## Section 4: Layout Recommendation
|
||||
|
||||
Describe the dashboard layout in plain terms:
|
||||
|
||||
```
|
||||
[ROW 1 — KPI Cards]: [Metric 1] | [Metric 2] | [Metric 3] | [Metric 4]
|
||||
[ROW 2 — Primary chart, full width]: [Chart name]
|
||||
[ROW 3 — Two charts side by side]: [Chart A] | [Chart B]
|
||||
[ROW 4 — Supporting table, full width]: [Table name]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Section 5: Data Requirements
|
||||
|
||||
List any data transformations, joins, or derived fields needed:
|
||||
|
||||
| Derived Field | Logic | Source Tables |
|
||||
|---|---|---|
|
||||
| [Field name] | [How it's calculated] | [Tables involved] |
|
||||
|
||||
Flag any fields that may not exist in current data infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## Section 6: Access & Ownership
|
||||
|
||||
- **Dashboard owner:** [Leave for user to fill]
|
||||
- **Who can edit:** [Leave for user to fill]
|
||||
- **Who can view:** [Leave for user to fill]
|
||||
- **Review cadence:** [When should this dashboard be reviewed for relevance?]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every chart has a stated "key insight to surface" — not just "show the data"
|
||||
- [ ] KPI cards are 3–6 (not more)
|
||||
- [ ] Chart types are justified
|
||||
- [ ] Layout follows visual hierarchy (summary → detail)
|
||||
- [ ] Data requirements section flags any missing fields
|
||||
- [ ] Filters are practical and don't require IT to configure
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Design a dashboard to track [business process]"
|
||||
- "Give me a spec for a [team] performance dashboard"
|
||||
- "What should go on a [topic] dashboard?"
|
||||
- "Write a dashboard brief for our [metric] monitoring"
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: metrics-framework
|
||||
description: "Build a metrics framework for any product, team, or business. Use when asked for a metrics tree, KPI framework, North Star metric, AARRR funnel, HEART framework, or OKR metrics. Produces a structured metrics hierarchy from North Star down to leading indicators, with measurement guidance."
|
||||
---
|
||||
|
||||
# Metrics Framework Skill
|
||||
|
||||
This skill builds a complete metrics framework tailored to a product or business. It connects the North Star metric to actionable leading indicators, making it clear which metrics to track, which to optimise, and how they relate to each other.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or business description** (one paragraph is enough)
|
||||
- **Business model** (SaaS / Marketplace / E-commerce / Consumer app / B2B / Other)
|
||||
- **Stage** (Pre-PMF / Growth / Scale / Mature)
|
||||
- **Framework preference** (if they have one): North Star + Metric Tree / AARRR / HEART / OKRs / Custom
|
||||
- **Primary goal this quarter** (e.g. grow activation, reduce churn, increase revenue)
|
||||
|
||||
If no framework preference is given, recommend the best fit based on stage and business model.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Framework Recommendation (if not specified)
|
||||
|
||||
Explain in 2–3 sentences why you're recommending this framework for their context.
|
||||
|
||||
---
|
||||
|
||||
### 2. North Star Metric
|
||||
|
||||
**[Metric Name]:** [Definition — exactly what is measured and how]
|
||||
|
||||
**Why this is the right North Star for this business:**
|
||||
[2–3 sentences. It should reflect customer value delivered, not just revenue or activity. Explain what behaviour it captures and why maximising it correlates with long-term business health.]
|
||||
|
||||
**How to measure it:** [Formula or data source]
|
||||
**Current baseline:** [Leave as [ADD BASELINE] for user to fill]
|
||||
**Target:** [Leave as [ADD TARGET] for user to fill]
|
||||
|
||||
---
|
||||
|
||||
### 3. Metric Tree
|
||||
|
||||
Show how supporting metrics roll up to the North Star. Format as a hierarchy:
|
||||
|
||||
```
|
||||
[North Star Metric]
|
||||
├── [Driver 1: e.g. Acquisition]
|
||||
│ ├── [L2 metric: e.g. Organic signups / week]
|
||||
│ └── [L2 metric: e.g. Paid CAC by channel]
|
||||
├── [Driver 2: e.g. Activation]
|
||||
│ ├── [L2 metric: e.g. % users completing onboarding within 7 days]
|
||||
│ └── [L2 metric: e.g. Time to first value action]
|
||||
└── [Driver 3: e.g. Retention]
|
||||
├── [L2 metric: e.g. Day 30 retention rate]
|
||||
└── [L2 metric: e.g. Feature adoption depth]
|
||||
```
|
||||
|
||||
For each L2 metric, provide:
|
||||
- **Definition:** [What exactly is measured]
|
||||
- **Why it matters:** [How it connects to the North Star]
|
||||
- **Leading or lagging?** [Leading = predictive / Lagging = outcome]
|
||||
- **How to measure:** [Data source or calculation]
|
||||
|
||||
---
|
||||
|
||||
### 4. Counter-Metrics
|
||||
|
||||
[2–3 metrics to watch that prevent optimising the North Star in ways that damage the business. E.g. "If we optimise for signups, we need to watch spam account rate. If we optimise for engagement, we need to watch support ticket volume."]
|
||||
|
||||
---
|
||||
|
||||
### 5. Dashboard Recommendation
|
||||
|
||||
Suggest a 3-tier dashboard structure:
|
||||
- **Exec view (weekly):** [3–5 metrics — outcomes only]
|
||||
- **Team view (daily):** [7–10 metrics — leading indicators + outputs]
|
||||
- **Diagnostic view (on demand):** [Metrics to drill into when something looks wrong]
|
||||
|
||||
---
|
||||
|
||||
### 6. Metric Health Check Questions
|
||||
|
||||
[5 questions the team should ask in their weekly metrics review to turn numbers into insights. e.g. "Is our activation rate improving while retention stays flat? That suggests onboarding quality issue, not a product-market fit problem."]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] North Star reflects customer value, not just business activity
|
||||
- [ ] Metric tree has 3–4 distinct drivers (not all one category)
|
||||
- [ ] Each L2 metric is classified as leading or lagging
|
||||
- [ ] Counter-metrics are included to prevent perverse incentives
|
||||
- [ ] Dashboard tiers are tailored to the product stage
|
||||
- [ ] All metric definitions are unambiguous (formula or clear description)
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a metrics framework for [product]"
|
||||
- "What should our North Star metric be?"
|
||||
- "Create a KPI tree for [business]"
|
||||
- "Give me an AARRR breakdown for [product]"
|
||||
- "What metrics should our [team type] team track?"
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
name: sql-query-explainer
|
||||
description: "Explain, optimise, or translate SQL queries into plain language. Use when asked to explain a SQL query, optimise slow SQL, write a data dictionary, translate SQL to plain English for non-technical stakeholders, or review a query for correctness and performance. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
|
||||
---
|
||||
|
||||
# SQL Query Explainer Skill
|
||||
|
||||
This skill explains SQL queries in plain language, identifies optimisation opportunities, and helps communicate data logic to non-technical stakeholders. It also writes and documents new queries from natural language descriptions.
|
||||
|
||||
## Modes
|
||||
|
||||
Detect which mode the user needs based on their request:
|
||||
|
||||
1. **Explain** — Translate existing SQL into plain English
|
||||
2. **Optimise** — Review SQL for performance issues and suggest improvements
|
||||
3. **Write** — Generate SQL from a natural language description
|
||||
4. **Document** — Produce a data dictionary or query documentation
|
||||
|
||||
---
|
||||
|
||||
## Mode 1: Explain
|
||||
|
||||
When given a SQL query, produce:
|
||||
|
||||
### Plain English Summary
|
||||
[1–3 sentences. What does this query do? What data does it return? Write as if explaining to a business analyst, not a developer.]
|
||||
|
||||
### Step-by-Step Walkthrough
|
||||
|
||||
Break the query into logical sections. For each section:
|
||||
- Quote the SQL clause
|
||||
- Explain what it does in plain English
|
||||
- Flag any complexity (e.g. window functions, subqueries, CTEs)
|
||||
|
||||
### What the Result Looks Like
|
||||
|
||||
[Describe the shape of the output: "Returns one row per user, with columns for X, Y, Z. Ordered by [field] descending."]
|
||||
|
||||
### Potential Issues to Flag
|
||||
|
||||
- [Gotchas, edge cases, or implicit assumptions in this query]
|
||||
- [e.g. "This will include NULLs in the user_id column if the LEFT JOIN finds no match"]
|
||||
|
||||
---
|
||||
|
||||
## Mode 2: Optimise
|
||||
|
||||
When asked to optimise a query, produce:
|
||||
|
||||
### Performance Assessment
|
||||
|
||||
Rate overall: 🟢 Well-optimised / 🟡 Some improvements possible / 🔴 Significant issues
|
||||
|
||||
### Issues Found
|
||||
|
||||
For each issue:
|
||||
|
||||
**Issue [N]: [Short name, e.g. "Missing index on join column"]**
|
||||
- **What it is:** [Plain explanation]
|
||||
- **Why it matters:** [Performance impact — e.g. "Full table scan on a 10M row table"]
|
||||
- **Fix:**
|
||||
```sql
|
||||
-- Before
|
||||
[original snippet]
|
||||
|
||||
-- After
|
||||
[improved snippet]
|
||||
```
|
||||
- **Expected improvement:** [Estimate if possible]
|
||||
|
||||
### Optimisation Checklist
|
||||
|
||||
- [ ] SELECT * used? (Replace with specific columns)
|
||||
- [ ] Implicit type conversions on JOIN/WHERE columns?
|
||||
- [ ] Missing indexes on JOIN or WHERE columns?
|
||||
- [ ] N+1 patterns (queries inside loops)?
|
||||
- [ ] DISTINCT used where GROUP BY would be faster?
|
||||
- [ ] Window functions used where a subquery would be clearer/faster?
|
||||
- [ ] CTEs re-used or materialised unnecessarily?
|
||||
- [ ] Large IN() lists that could use a JOIN instead?
|
||||
|
||||
---
|
||||
|
||||
## Mode 3: Write
|
||||
|
||||
When given a natural language description, generate the SQL query and then explain it using Mode 1.
|
||||
|
||||
Ask the user to confirm:
|
||||
- **Database/dialect** (PostgreSQL / MySQL / BigQuery / Snowflake / SQLite / Standard SQL)
|
||||
- **Table and column names** (if known; otherwise use descriptive placeholder names like `users`, `orders`, `user_id`)
|
||||
- **Any filters, sorting, or aggregation requirements**
|
||||
|
||||
Produce:
|
||||
1. The SQL query with inline comments
|
||||
2. Plain English explanation (Mode 1 format)
|
||||
|
||||
---
|
||||
|
||||
## Mode 4: Document
|
||||
|
||||
When asked to create documentation for a query or table:
|
||||
|
||||
### Query Documentation
|
||||
|
||||
```
|
||||
Query: [Name]
|
||||
Purpose: [One sentence — what business question this answers]
|
||||
Author: [If provided]
|
||||
Last reviewed: [If provided]
|
||||
|
||||
Inputs:
|
||||
- Table: [table_name] — [what it contains]
|
||||
- Filter: [any WHERE conditions and their business meaning]
|
||||
|
||||
Output columns:
|
||||
| Column | Type | Description |
|
||||
|--------|------|-------------|
|
||||
| [name] | [type] | [plain English description] |
|
||||
|
||||
Assumptions:
|
||||
- [Any implicit assumptions the query makes]
|
||||
|
||||
Known limitations:
|
||||
- [Edge cases not handled, data quality dependencies, etc.]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Plain English explanation avoids SQL jargon
|
||||
- [ ] Optimisation suggestions include before/after SQL
|
||||
- [ ] Written queries include inline comments
|
||||
- [ ] Output shape is described (columns, row grain, ordering)
|
||||
- [ ] Dialect-specific syntax is flagged when non-standard
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Explain this SQL query: [paste query]"
|
||||
- "Optimise this slow query: [paste query]"
|
||||
- "Write a SQL query that [natural language description]"
|
||||
- "Document this query for my non-technical stakeholders"
|
||||
- "Why is this query returning unexpected results?"
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-delivery",
|
||||
"version": "3.0.0",
|
||||
"description": "Sprint & delivery skills: Sprint Planning, Technical Spec Template, A/B Test Planner, Go-to-Market Planner, Product Launch Checklist, Sprint Brief, Retro Analysis.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["product-management", "sprint", "agile", "ab-testing", "go-to-market", "launch", "technical-spec"]
|
||||
}
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,113 @@
|
||||
---
|
||||
name: ab-test-planner
|
||||
description: "Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide."
|
||||
---
|
||||
|
||||
# A/B Test Planner Skill
|
||||
|
||||
Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **What is being tested** (feature, UI change, copy, pricing, onboarding step)
|
||||
- **Hypothesis** (or ask to help formulate one)
|
||||
- **Primary metric** (conversion rate, click-through, completion rate, etc.)
|
||||
- **Baseline rate** and **minimum detectable effect** (MDE)
|
||||
- **Daily eligible users** (to calculate duration)
|
||||
|
||||
## Experiment Design Checklist
|
||||
|
||||
Before running any test, confirm:
|
||||
- [ ] Clear hypothesis with predicted direction
|
||||
- [ ] Single primary metric (plus up to 2 guardrail metrics)
|
||||
- [ ] Minimum detectable effect (MDE) defined
|
||||
- [ ] Sample size calculated
|
||||
- [ ] Test duration estimated
|
||||
- [ ] Segment isolated (no overlap with other running tests)
|
||||
- [ ] Rollback plan defined
|
||||
|
||||
## Hypothesis Template
|
||||
|
||||
> "We believe that [change] will cause [primary metric] to [increase/decrease] by [X%] for [user segment], because [rationale based on data or insight]."
|
||||
|
||||
Never run a test without a directional hypothesis. "Let's just see what happens" is not a hypothesis.
|
||||
|
||||
## Sample Size Calculator Logic
|
||||
|
||||
Use this formula (provide the output, not the formula, to the user):
|
||||
|
||||
- **Baseline conversion rate:** Current rate of primary metric
|
||||
- **MDE:** Smallest change worth detecting (recommend 10–20% relative lift for most features)
|
||||
- **Statistical power:** 80% (standard)
|
||||
- **Significance level:** 95% (p < 0.05)
|
||||
|
||||
For common scenarios, provide pre-calculated estimates:
|
||||
|
||||
| Baseline Rate | MDE (Relative) | Required Sample per Variant |
|
||||
|---|---|---|
|
||||
| 5% | 20% | ~19,000 |
|
||||
| 10% | 15% | ~14,000 |
|
||||
| 20% | 10% | ~15,000 |
|
||||
| 40% | 10% | ~9,500 |
|
||||
| 60% | 5% | ~42,000 |
|
||||
|
||||
Always warn: "These are estimates. Use a tool like Evan Miller's calculator or Statsig for precision."
|
||||
|
||||
## Test Duration Guidance
|
||||
|
||||
Minimum: 2 full weeks (to capture weekly seasonality)
|
||||
Maximum: 4 weeks (novelty effect distorts results beyond this)
|
||||
|
||||
`Duration = Required sample ÷ (Daily traffic × % exposed)`
|
||||
|
||||
Flag if traffic is too low to reach significance in under 8 weeks — recommend a different approach (e.g., holdout test, qualitative research).
|
||||
|
||||
## Output Format
|
||||
|
||||
### A/B Test Plan — [Test Name] — [Date]
|
||||
|
||||
**Hypothesis:**
|
||||
> [Filled hypothesis template]
|
||||
|
||||
**Variants:**
|
||||
- Control (A): [Current experience]
|
||||
- Treatment (B): [Changed experience — be specific]
|
||||
|
||||
**Primary Metric:** [Metric name + how measured]
|
||||
**Guardrail Metrics:** [Metrics that must not degrade]
|
||||
|
||||
**Target Segment:** [Who sees the test — % of traffic, user type]
|
||||
**Traffic Split:** [50/50 recommended unless ramp-up needed]
|
||||
|
||||
**Sample Size Required:** ~[N] users per variant
|
||||
**Estimated Duration:** [X] weeks (based on [Y] daily eligible users)
|
||||
**Significance Threshold:** 95% confidence, 80% power
|
||||
|
||||
**Exclusions:** [Any user segments to exclude and why]
|
||||
|
||||
**Rollback Trigger:** If [guardrail metric] degrades by [X%], stop the test immediately.
|
||||
|
||||
**Results Interpretation Guide:**
|
||||
- ✅ Ship if: Treatment shows [X%]+ lift on primary metric at 95% confidence AND guardrail metrics are stable
|
||||
- 🔄 Iterate if: Direction is positive but not significant — consider extending or redesigning
|
||||
- ❌ Reject if: No lift or negative direction at significance
|
||||
- ⚠️ Inconclusive: Do not ship. Do not call it a win.
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always recommend against peeking at results before the test reaches planned sample size — explain p-hacking risk
|
||||
- If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
|
||||
- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
|
||||
- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
|
||||
- [ ] Primary metric is singular (guardrail metrics are secondary)
|
||||
- [ ] Sample size is calculated from actual MDE and baseline (not guessed)
|
||||
- [ ] Test duration accounts for weekly seasonality (minimum 2 weeks)
|
||||
- [ ] Guardrail metrics are defined (at least one to protect revenue or core engagement)
|
||||
- [ ] Rollback trigger is specified with a concrete threshold
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
name: go-to-market-planner
|
||||
description: "Build a go-to-market plan for any product launch, feature release, or new market entry. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Produces a tiered GTM plan with messaging, cross-functional activity tracker, success metrics, and launch day checklist."
|
||||
---
|
||||
|
||||
# Go-to-Market Planner Skill
|
||||
|
||||
Produce a complete, cross-functional GTM plan that aligns product, marketing, sales, and support around a single launch — with clear owners, timelines, and success metrics.
|
||||
|
||||
## Launch Tier Framework
|
||||
|
||||
Before planning, classify the launch:
|
||||
|
||||
| Tier | Scope | Typical Effort | Examples |
|
||||
|---|---|---|---|
|
||||
| **Tier 1 — Major Launch** | New product / significant platform change | 8–12 weeks | New pricing model, platform rebrand, new product line |
|
||||
| **Tier 2 — Feature Launch** | Significant new capability | 4–6 weeks | Major feature, API release, new integration |
|
||||
| **Tier 3 — Incremental Release** | Improvement, bug fix, minor feature | 1–2 weeks | UI tweak, performance improvement, small enhancement |
|
||||
|
||||
Always confirm tier with the user before proceeding.
|
||||
|
||||
---
|
||||
|
||||
## GTM Plan Output Format
|
||||
|
||||
### GTM Plan — [Product/Feature Name] — [Launch Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner (PM):** [Name]
|
||||
**Target Launch Date:** [Date]
|
||||
**Soft Launch Date (Beta/Limited):** [Date, if applicable]
|
||||
|
||||
---
|
||||
|
||||
### 1. What We're Launching
|
||||
**One-line description:** [What it is, for whom, and why now]
|
||||
**Key customer problem solved:** [Specific pain point]
|
||||
**Key differentiator:** [Why ours, why now]
|
||||
|
||||
---
|
||||
|
||||
### 2. Target Audience
|
||||
**Primary segment:** [Who benefits most — be specific]
|
||||
**Secondary segment:** [Who else benefits]
|
||||
**Not for:** [Who this is NOT for — helps sales and support]
|
||||
|
||||
---
|
||||
|
||||
### 3. Messaging
|
||||
|
||||
**Headline:** [Customer-facing headline — lead with outcome, not feature]
|
||||
**Sub-headline:** [Supporting context — how it works or why it matters]
|
||||
**3 key messages:**
|
||||
1. [Problem solved]
|
||||
2. [How it works / what's new]
|
||||
3. [Proof / social proof / data]
|
||||
|
||||
**Elevator pitch (30 seconds):**
|
||||
> [For [target user] who [has this problem], [product/feature] is a [category] that [key benefit]. Unlike [alternative], we [differentiator].]
|
||||
|
||||
---
|
||||
|
||||
### 4. Launch Activities by Function
|
||||
|
||||
| Function | Activity | Owner | Due Date | Status |
|
||||
|---|---|---|---|---|
|
||||
| Product | Feature flagging / rollout plan | PM | [date] | |
|
||||
| Marketing | Blog post / landing page | Marketing | [date] | |
|
||||
| Marketing | Email campaign to existing users | Marketing | [date] | |
|
||||
| Marketing | Social media content | Marketing | [date] | |
|
||||
| Sales | Sales enablement deck | PM + Sales | [date] | |
|
||||
| Sales | FAQ for sales team | PM | [date] | |
|
||||
| Support | Help centre articles | Support | [date] | |
|
||||
| Support | Support team training | Support | [date] | |
|
||||
| Engineering | Monitoring/alerting in place | Eng | [date] | |
|
||||
|
||||
---
|
||||
|
||||
### 5. Success Metrics
|
||||
|
||||
| Metric | Baseline | Target | Measurement Window |
|
||||
|---|---|---|---|
|
||||
| [Adoption metric] | [X] | [Y] | 30 days post-launch |
|
||||
| [Engagement metric] | [X] | [Y] | 60 days post-launch |
|
||||
| [Business metric] | [X] | [Y] | 90 days post-launch |
|
||||
|
||||
---
|
||||
|
||||
### 6. Risks & Contingencies
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|---|---|---|---|
|
||||
| [Risk] | H/M/L | H/M/L | [Action if it happens] |
|
||||
|
||||
---
|
||||
|
||||
### 7. Launch Day Checklist
|
||||
- [ ] Feature live for [X%] of users
|
||||
- [ ] Monitoring dashboard active
|
||||
- [ ] Support team briefed
|
||||
- [ ] Blog post published
|
||||
- [ ] Email sent / scheduled
|
||||
- [ ] Sales team notified
|
||||
- [ ] Executive announcement sent (if Tier 1)
|
||||
- [ ] Rollback procedure confirmed
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or feature name**
|
||||
- **Target launch date**
|
||||
- **Launch tier** (Tier 1 / 2 / 3 — or describe scope and the skill will classify)
|
||||
- **Target audience** (who benefits and who it's NOT for)
|
||||
- **Key message** (what's the headline outcome for the customer)
|
||||
- **PM and launch owner**
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never plan a Tier 1 launch without at least 8 weeks of lead time
|
||||
- Always include a "Not for" section — it prevents misdirected sales and support tickets
|
||||
- Recommend a soft launch to 5–10% of users before full rollout for any Tier 1 or 2 launch
|
||||
- Post-launch retrospective should be scheduled at launch planning time — don't leave it to chance
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Launch tier is confirmed and appropriate for scope
|
||||
- [ ] "Not for" section is included to prevent misdirected sales and support
|
||||
- [ ] Every function has at least one activity with a named owner and due date
|
||||
- [ ] Success metrics include a measurement window (30/60/90 days)
|
||||
- [ ] Rollback procedure is confirmed for Tier 1 and 2 launches
|
||||
- [ ] Post-launch retrospective is scheduled
|
||||
@@ -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.
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
name: product-launch-checklist
|
||||
description: "Generate a comprehensive pre-launch, launch day, and post-launch checklist for any product release. Use when preparing for a product launch, feature release, or major update. Produces a role-assigned, tiered checklist covering engineering readiness, marketing and comms, support, and post-launch monitoring."
|
||||
---
|
||||
|
||||
# Product Launch Checklist Skill
|
||||
|
||||
Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
|
||||
|
||||
## How to Use This Skill
|
||||
|
||||
Provide:
|
||||
- Launch name and date
|
||||
- Launch tier (1 = major, 2 = feature, 3 = incremental)
|
||||
- Team members and their roles
|
||||
|
||||
The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Launch Checklist — [Feature/Product Name] — Target Date: [Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner:** [PM Name]
|
||||
**Engineering Lead:** [Name]
|
||||
**Go/No-Go Decision By:** [Date and time — typically 24 hours before launch]
|
||||
|
||||
---
|
||||
|
||||
### 🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks)
|
||||
- [ ] Feature flag created and tested in staging
|
||||
- [ ] All acceptance criteria signed off by PM
|
||||
- [ ] Code reviewed and merged to main
|
||||
- [ ] QA sign-off completed (regression + new feature)
|
||||
- [ ] Performance testing completed (load, latency)
|
||||
- [ ] Security review completed (if data or auth changes)
|
||||
- [ ] Rollback procedure documented and tested
|
||||
- [ ] Monitoring and alerting configured
|
||||
- [ ] Error logging in place with correct severity levels
|
||||
- [ ] Database migrations tested on staging with production data volume
|
||||
|
||||
### 📢 PRE-LAUNCH — Marketing & Comms (T-1 week)
|
||||
- [ ] Blog post written, reviewed, and scheduled
|
||||
- [ ] In-app announcement or tooltip configured
|
||||
- [ ] Email campaign drafted and QA'd
|
||||
- [ ] Social media posts drafted and scheduled
|
||||
- [ ] Landing page or feature page live in staging
|
||||
- [ ] Press outreach sent (Tier 1 only)
|
||||
- [ ] Product Hunt / community posts prepared (Tier 1 only)
|
||||
|
||||
### 🎓 PRE-LAUNCH — Sales & Support (T-1 week)
|
||||
- [ ] Sales enablement one-pager completed
|
||||
- [ ] FAQ document shared with sales and support teams
|
||||
- [ ] Help centre articles written and published
|
||||
- [ ] Support team demo / training completed
|
||||
- [ ] Customer success team briefed on top accounts
|
||||
- [ ] Pricing updated (if applicable)
|
||||
- [ ] Contracts / ToS updated (if applicable)
|
||||
|
||||
### 📊 PRE-LAUNCH — Analytics (T-1 week)
|
||||
- [ ] Analytics events firing correctly in staging
|
||||
- [ ] Dashboard configured for launch metrics
|
||||
- [ ] Baseline metrics documented
|
||||
- [ ] Success criteria documented and shared with team
|
||||
- [ ] A/B test configured (if applicable)
|
||||
|
||||
---
|
||||
|
||||
### ✅ GO / NO-GO DECISION — T-24 hours
|
||||
|
||||
| Criteria | Status | Owner |
|
||||
|---|---|---|
|
||||
| All critical bugs resolved | 🟢 / 🔴 | Eng Lead |
|
||||
| QA sign-off complete | 🟢 / 🔴 | QA |
|
||||
| Rollback tested | 🟢 / 🔴 | Eng Lead |
|
||||
| Help centre articles live | 🟢 / 🔴 | Support |
|
||||
| Monitoring active | 🟢 / 🔴 | Eng Lead |
|
||||
| PM sign-off | 🟢 / 🔴 | PM |
|
||||
|
||||
**Go / No-Go Decision:** [GO / NO-GO]
|
||||
**Decision Owner:** [PM + Eng Lead jointly]
|
||||
|
||||
---
|
||||
|
||||
### 🚀 LAUNCH DAY
|
||||
- [ ] Feature flag enabled for [X%] of users (start low — 5–10%)
|
||||
- [ ] Launch confirmed in team Slack/channel
|
||||
- [ ] Metrics dashboard open and being monitored
|
||||
- [ ] Error rate checked at T+15 min, T+1 hr, T+4 hr
|
||||
- [ ] Blog post published / email sent
|
||||
- [ ] Social posts live
|
||||
- [ ] Support team on standby for first 4 hours
|
||||
- [ ] PM available and reachable all day
|
||||
- [ ] Feature flag expanded to 50% if T+2hr checks pass
|
||||
- [ ] Feature flag expanded to 100% if T+4hr checks pass
|
||||
|
||||
---
|
||||
|
||||
### 📈 POST-LAUNCH (D+7, D+30)
|
||||
- [ ] D+7 metrics review: adoption, errors, support tickets
|
||||
- [ ] D+7 customer feedback synthesised
|
||||
- [ ] Retrospective scheduled
|
||||
- [ ] Learnings documented
|
||||
- [ ] D+30 success metrics reviewed against targets
|
||||
- [ ] Feature flag removed from codebase (clean up)
|
||||
- [ ] Follow-up features added to backlog based on feedback
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Launch tier confirmed before generating checklist (scope determines depth)
|
||||
- [ ] Go/No-Go decision has a named owner and a specific decision time
|
||||
- [ ] Rollback procedure is documented and tested (not just planned)
|
||||
- [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once
|
||||
- [ ] Post-launch retrospective is scheduled at launch time
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The Go/No-Go decision must have a named owner — "the team" is not an owner
|
||||
- Never launch on a Friday unless you have weekend engineering coverage
|
||||
- Recommend starting all launches at <10% traffic — even for simple features
|
||||
- Document rollback time: "We can revert this in X minutes" should be known before launch
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
description: "Analyse sprint delivery data and produce a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint."
|
||||
---
|
||||
|
||||
# Retrospective Analysis Skill
|
||||
|
||||
Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Sprint tickets: planned vs. completed**
|
||||
- **Carry-over tickets and reasons** (if known)
|
||||
- **Tickets reopened after closing** (quality signal)
|
||||
- **Any incidents or unplanned work** (scope creep signal)
|
||||
- **Sprint velocity vs. historical average** (trend context)
|
||||
|
||||
## Process
|
||||
1. Calculate: completion rate, carry-over rate, unplanned work percentage
|
||||
2. Identify patterns: which ticket types were most likely to carry over? Which caused blockers?
|
||||
3. Note any process or communication breakdowns visible in the data
|
||||
4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
|
||||
5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
|
||||
6. **Validate** — Confirm each prompt is specific to this sprint (not a recycled generic prompt), and that the recommended experiment is concrete and measurable
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Sprint [Number] Retrospective Brief
|
||||
|
||||
**By the Numbers:**
|
||||
- Planned: [n] tickets | Completed: [n] | Carry-over: [n] | Completion rate: [%]
|
||||
- Unplanned work: [n] tickets ([%] of capacity)
|
||||
- Velocity: [points] vs. [average] average
|
||||
|
||||
**What the Data Suggests:**
|
||||
[2-3 observations grounded in the numbers above]
|
||||
|
||||
**Discussion Prompts:**
|
||||
- Start: [specific prompt based on this sprint's data]
|
||||
- Stop: [specific prompt based on this sprint's data]
|
||||
- Continue: [specific prompt based on this sprint's data]
|
||||
|
||||
**Suggested Experiment for Next Sprint:**
|
||||
[One concrete, testable process change — with a specific success metric]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Each Start/Stop/Continue prompt names a specific behaviour, not a vague category
|
||||
- [ ] The recommended experiment is testable in one sprint
|
||||
- [ ] Carry-over analysis identifies the ticket type or cause, not just the count
|
||||
- [ ] Data observations don't assign blame — they describe patterns
|
||||
- [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?)
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: sprint-brief
|
||||
description: "Generate a structured sprint brief from sprint data and goals. Use when asked to write a sprint brief, create a sprint summary, document sprint goals and scope, or produce a team-facing sprint overview. Produces a scannable brief with sprint goal, rationale, grouped work, critical path, risks, and definition of done."
|
||||
---
|
||||
|
||||
# Sprint Brief Skill
|
||||
|
||||
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Sprint name and number**
|
||||
- **Sprint goal** (1-2 sentences — flag if too vague)
|
||||
- **Ticket list with owners** (or a description of the work)
|
||||
- **Known dependencies or blockers**
|
||||
- **Carry-over items from previous sprint** (if any)
|
||||
|
||||
## Process
|
||||
1. Read sprint goal and check it's specific and measurable — flag if it's too vague
|
||||
2. Group tickets by theme or feature area
|
||||
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
|
||||
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
|
||||
5. Note carry-over items and whether they affect this sprint's goal
|
||||
6. **Validate** — Confirm the sprint goal is achievable given the ticket scope and capacity. If the critical path items alone would fill the sprint, flag it as overloaded.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Sprint [Number] Brief — [Dates]
|
||||
**Sprint Goal:** [1-2 sentences — specific and measurable]
|
||||
**Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
|
||||
|
||||
**What We're Building:**
|
||||
- [Theme 1]: [tickets and owners]
|
||||
- [Theme 2]: [tickets and owners]
|
||||
|
||||
**Critical Path:** [The 2-3 tickets everything else depends on]
|
||||
|
||||
**Risks to Flag:**
|
||||
- [Risk 1 + mitigation]
|
||||
- [Risk 2 + mitigation]
|
||||
|
||||
**Carry-over from Last Sprint:** [List + impact on current goal]
|
||||
|
||||
**Definition of Done:** [Specific, agreed criteria for sprint success]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Sprint goal is specific enough to score pass/fail at the end of the sprint
|
||||
- [ ] Critical path items are named — not just "the important ones"
|
||||
- [ ] Every risk has a mitigation or owner (not just "this is a risk")
|
||||
- [ ] Carry-over items are connected to their impact on this sprint's goal
|
||||
- [ ] Definition of Done is agreed criteria, not a task list
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
name: sprint-planning
|
||||
description: "Structure and facilitate sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning agendas. Produces a sprint goal, velocity-calibrated backlog, capacity plan, risk flags, and a structured sprint planning meeting agenda."
|
||||
---
|
||||
|
||||
# Sprint Planning Skill
|
||||
|
||||
Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.
|
||||
|
||||
## What This Skill Produces
|
||||
|
||||
- **Sprint Goal** — single, outcome-focused sentence the whole team can rally around
|
||||
- **Sprint Backlog** — prioritised list of user stories with story point estimates and acceptance criteria
|
||||
- **Capacity Plan** — team availability breakdown accounting for holidays, meetings, and focus time
|
||||
- **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings
|
||||
- **Risk Flags** — blockers or dependencies that could derail the sprint
|
||||
|
||||
## Inputs to Request From User
|
||||
|
||||
Ask for (if not already provided):
|
||||
- Sprint duration (1 or 2 weeks)
|
||||
- Team size and velocity (average story points per sprint)
|
||||
- Top 3–5 backlog items or epics to pull from
|
||||
- Any known absences, holidays, or team events
|
||||
- Previous sprint's incomplete items (carry-overs)
|
||||
|
||||
## Sprint Goal Formula
|
||||
|
||||
Use this structure:
|
||||
> "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]."
|
||||
|
||||
Never write sprint goals as task lists. Always outcome-first.
|
||||
|
||||
## Story Point Calibration
|
||||
|
||||
| Complexity | Points | Description |
|
||||
|---|---|---|
|
||||
| Trivial | 1 | Clearly understood, no unknowns |
|
||||
| Small | 2 | Straightforward, minor effort |
|
||||
| Medium | 3 | Some complexity, clear path |
|
||||
| Large | 5 | Complex, needs design or research |
|
||||
| Very Large | 8 | High uncertainty, may need splitting |
|
||||
| Epic | 13+ | Too large — must be split before sprint |
|
||||
|
||||
Flag any item estimated at 8+ and recommend splitting.
|
||||
|
||||
## Capacity Formula
|
||||
|
||||
```
|
||||
Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor
|
||||
Focus hours/day: 6 (accounting for meetings, Slack, admin)
|
||||
Availability factor: 0.7–0.85 depending on holidays/events
|
||||
Story points to commit = Historical velocity × Availability factor
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [N] — [Start Date] to [End Date]
|
||||
|
||||
**Sprint Goal:**
|
||||
> [Goal statement]
|
||||
|
||||
**Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability)
|
||||
|
||||
**Sprint Backlog:**
|
||||
|
||||
| Priority | Story | Points | Owner | Acceptance Criteria |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Story title] | [N] | [Team member] | [When X then Y] |
|
||||
|
||||
**Carry-Overs from Previous Sprint:**
|
||||
- [Item] — Reason for carry-over: [brief explanation]
|
||||
|
||||
**Risks & Dependencies:**
|
||||
- [Risk description] → Mitigation: [action]
|
||||
|
||||
**Sprint Planning Agenda:**
|
||||
- 00:00–00:10 — Review sprint goal and team capacity
|
||||
- 00:10–00:40 — Walk through backlog items, confirm estimates
|
||||
- 00:40–01:20 — Assign stories, identify dependencies
|
||||
- 01:20–01:50 — Review acceptance criteria per story
|
||||
- 01:50–02:00 — Confirm sprint commitment and close
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always challenge stories missing acceptance criteria — flag them explicitly
|
||||
- Recommend the team commits to 80% of available capacity, not 100%
|
||||
- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
|
||||
- Highlight any story with unclear ownership as a blocker
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Sprint goal is outcome-focused (not "implement X" — something like "users can do Y")
|
||||
- [ ] Team capacity is calculated using actual availability, not theoretical 100%
|
||||
- [ ] Every story has an acceptance criterion (flag any that don't)
|
||||
- [ ] Stories estimated at 8+ points are flagged for splitting
|
||||
- [ ] Carry-overs from last sprint are accounted for in capacity
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
name: technical-spec-template
|
||||
description: "Create structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Produces a complete spec with problem statement, proposed solution, data model, API design, alternatives considered, security considerations, testing plan, and rollout strategy."
|
||||
---
|
||||
|
||||
# Technical Spec Template Skill
|
||||
|
||||
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Feature or system description** (what needs to be specced)
|
||||
- **Related PRD or product brief** (if available)
|
||||
- **Engineering reviewers** (whose sign-off is needed)
|
||||
- **Known constraints** (technical limitations, security requirements, performance targets)
|
||||
|
||||
## When to Write a Tech Spec
|
||||
|
||||
Write a tech spec when:
|
||||
- The feature requires changes to 2+ systems
|
||||
- There are significant architectural decisions to make
|
||||
- More than one engineer will work on the implementation
|
||||
- The feature has security, privacy, or compliance implications
|
||||
- Estimated effort is >5 story points
|
||||
|
||||
Skip the spec for trivial bug fixes or 1-2 hour changes.
|
||||
|
||||
---
|
||||
|
||||
## Technical Spec Output Format
|
||||
|
||||
### Technical Specification — [Feature Name]
|
||||
|
||||
**Author:** [Name]
|
||||
**Status:** Draft | In Review | Approved | Implemented
|
||||
**Created:** [Date] | **Last Updated:** [Date]
|
||||
**Reviewers:** [Eng Lead, Architect, PM, Security if needed]
|
||||
**Related PRD:** [Link] | **Jira Epic:** [Link]
|
||||
|
||||
---
|
||||
|
||||
#### 1. Problem Statement
|
||||
> [2–3 sentences. What problem are we solving and why now? No solution language here.]
|
||||
|
||||
#### 2. Goals & Non-Goals
|
||||
|
||||
**Goals (in scope):**
|
||||
- [Specific, measurable outcome]
|
||||
- [Specific, measurable outcome]
|
||||
|
||||
**Non-Goals (explicitly out of scope):**
|
||||
- [What this spec does NOT cover]
|
||||
- [Common assumption to shut down early]
|
||||
|
||||
#### 3. Background & Context
|
||||
[Any prior art, related systems, or context engineers need to understand the decision space. Link to previous specs, ADRs, or research.]
|
||||
|
||||
#### 4. Proposed Solution
|
||||
|
||||
**High-Level Approach:**
|
||||
[2–4 sentences describing the chosen solution. Why this approach vs alternatives?]
|
||||
|
||||
**System Architecture Diagram:**
|
||||
[Describe or embed: which services are involved, how data flows, what APIs are called]
|
||||
|
||||
**Data Model Changes:**
|
||||
```sql
|
||||
-- New tables or schema changes
|
||||
[Include DDL or schema definition]
|
||||
```
|
||||
|
||||
**API Design:**
|
||||
```
|
||||
[Endpoint] [Method]
|
||||
Request: { [fields and types] }
|
||||
Response: { [fields and types] }
|
||||
Error codes: [list]
|
||||
```
|
||||
|
||||
**Key Implementation Details:**
|
||||
- [Important technical constraint or approach]
|
||||
- [Edge case handling]
|
||||
- [Third-party dependency and version]
|
||||
|
||||
#### 5. Alternative Approaches Considered
|
||||
|
||||
| Option | Pros | Cons | Why Rejected |
|
||||
|---|---|---|---|
|
||||
| [Alt 1] | [Benefits] | [Drawbacks] | [Reason not chosen] |
|
||||
| [Alt 2] | [Benefits] | [Drawbacks] | [Reason not chosen] |
|
||||
|
||||
#### 6. Security & Privacy Considerations
|
||||
- Data stored: [What PII or sensitive data is involved]
|
||||
- Authentication: [How is access controlled]
|
||||
- Authorisation: [What permissions are required]
|
||||
- Encryption: [At rest / in transit requirements]
|
||||
- Compliance implications: [GDPR, SOC2, etc. if relevant]
|
||||
|
||||
#### 7. Performance & Scalability
|
||||
- Expected load: [Requests/second, data volume]
|
||||
- Latency requirements: [P50 / P95 targets]
|
||||
- Caching strategy: [If applicable]
|
||||
- Database indexing: [New indexes required]
|
||||
- Known bottlenecks: [Where to watch]
|
||||
|
||||
#### 8. Testing Plan
|
||||
- Unit tests: [Key scenarios to cover]
|
||||
- Integration tests: [System boundaries to test]
|
||||
- Load tests: [If performance-critical]
|
||||
- Edge cases: [Known tricky scenarios]
|
||||
- Rollback plan: [How to revert if something goes wrong]
|
||||
|
||||
#### 9. Rollout Plan
|
||||
- Feature flag: [Yes / No — name of flag]
|
||||
- Rollout stages: [% of users at each stage]
|
||||
- Monitoring: [Metrics and alerts to set up]
|
||||
- Success criteria to progress rollout: [What needs to be true]
|
||||
- Rollback trigger: [What would cause immediate rollback]
|
||||
|
||||
#### 10. Open Questions
|
||||
| Question | Owner | Due Date | Resolution |
|
||||
|---|---|---|---|
|
||||
| [Unresolved question] | [Name] | [Date] | [Pending] |
|
||||
|
||||
#### 11. Implementation Timeline (Rough)
|
||||
| Phase | Work | Estimated Effort |
|
||||
|---|---|---|
|
||||
| [Phase 1] | [What gets built] | [X days/points] |
|
||||
| [Phase 2] | [What gets built] | [X days/points] |
|
||||
| Total | | [X story points] |
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The spec is a decision record, not a task list — document *why* decisions were made
|
||||
- All open questions must have an owner and due date
|
||||
- Security and privacy sections are never optional for features that touch user data
|
||||
- Recommend async review: engineers read first, then a 30-minute sync to resolve questions
|
||||
- Keep the spec updated as implementation progresses — stale specs are worse than no specs
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Problem statement contains no solution language
|
||||
- [ ] Non-goals explicitly list at least 2 things that might be assumed in scope
|
||||
- [ ] At least 2 alternative approaches are documented with reasons for rejection
|
||||
- [ ] Security and privacy section is completed for any feature touching user data
|
||||
- [ ] All open questions have a named owner and due date (not "TBD")
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$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"]
|
||||
}
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,175 @@
|
||||
---
|
||||
name: accessibility-audit
|
||||
description: "Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes."
|
||||
---
|
||||
|
||||
# Accessibility Audit Skill
|
||||
|
||||
This skill produces a structured accessibility audit based on WCAG 2.2 guidelines. It covers visual, motor, cognitive, and screen reader accessibility — with prioritised remediation for each issue found.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **What is being audited** (screen, component, full product, design spec)
|
||||
- **Description or image** of the UI
|
||||
- **Target WCAG level** (A / AA / AAA — default to AA, which is the legal standard in most jurisdictions)
|
||||
- **Known assistive technology users?** (Yes/No — if yes, which: screen reader / switch access / voice control / magnification)
|
||||
- **Platform** (Web / iOS / Android / Desktop app)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Accessibility Audit: [Component or Screen Name]
|
||||
**Target standard:** WCAG 2.2 Level [AA]
|
||||
**Platform:** [Platform]
|
||||
**Date:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Audit Summary
|
||||
|
||||
| Category | Issues Found | Critical | Moderate | Minor |
|
||||
|---|---|---|---|---|
|
||||
| Perceivable | | | | |
|
||||
| Operable | | | | |
|
||||
| Understandable | | | | |
|
||||
| Robust | | | | |
|
||||
| **Total** | | | | |
|
||||
|
||||
**Overall compliance status:** ✅ Compliant / 🟡 Minor issues / 🔴 Fails AA standard
|
||||
|
||||
---
|
||||
|
||||
## Perceivable
|
||||
|
||||
### 1.1 Text Alternatives
|
||||
- [ ] All images have descriptive alt text (not filename or "image")
|
||||
- [ ] Decorative images have `alt=""` to be skipped by screen readers
|
||||
- [ ] Icons without visible labels have accessible names
|
||||
- [ ] Complex images (charts, diagrams) have extended descriptions
|
||||
|
||||
**Issues found:** [List specific issues or "None"]
|
||||
|
||||
### 1.3 Adaptable
|
||||
- [ ] Content structure uses semantic HTML (headings, lists, landmarks) — not just visual formatting
|
||||
- [ ] Reading order in DOM matches visual order
|
||||
- [ ] Form inputs have associated labels (not placeholder text as label)
|
||||
- [ ] Data tables have proper headers and scope
|
||||
|
||||
**Issues found:**
|
||||
|
||||
### 1.4 Distinguishable
|
||||
- [ ] Text contrast ratio ≥ 4.5:1 (normal text) or ≥ 3:1 (large text 18px+)
|
||||
- [ ] UI component contrast ratio ≥ 3:1 against background
|
||||
- [ ] Information is not conveyed by colour alone
|
||||
- [ ] Text can be resized to 200% without loss of content
|
||||
- [ ] No content that auto-plays audio
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Operable
|
||||
|
||||
### 2.1 Keyboard Accessible
|
||||
- [ ] All interactive elements are reachable by keyboard (Tab key)
|
||||
- [ ] No keyboard traps
|
||||
- [ ] Custom components have keyboard interactions (arrow keys for menus, Escape to close modals)
|
||||
- [ ] Skip navigation link available for pages with repeated navigation
|
||||
|
||||
**Issues found:**
|
||||
|
||||
### 2.4 Navigable
|
||||
- [ ] Focus is visible at all times (not removed with `outline: none` without replacement)
|
||||
- [ ] Focus order is logical and predictable
|
||||
- [ ] Page/screen has a descriptive title
|
||||
- [ ] Link text is descriptive (not "click here" or "read more")
|
||||
- [ ] Headings are hierarchical (H1 → H2 → H3, no skips)
|
||||
|
||||
**Issues found:**
|
||||
|
||||
### 2.5 Input Modalities
|
||||
- [ ] Touch targets are at least 44x44px
|
||||
- [ ] No functionality requires complex gestures (pinch, multi-touch) without a simple alternative
|
||||
- [ ] Motion or dragging interactions have button alternatives
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Understandable
|
||||
|
||||
### 3.1 Readable
|
||||
- [ ] Language of the page is set (`lang` attribute)
|
||||
- [ ] Unusual words, abbreviations, or jargon are explained
|
||||
|
||||
### 3.2 Predictable
|
||||
- [ ] Navigation is consistent across screens
|
||||
- [ ] Components behave consistently (same button does the same thing)
|
||||
- [ ] No unexpected context changes on focus or input
|
||||
|
||||
### 3.3 Input Assistance
|
||||
- [ ] Error messages identify the field and describe the error in plain language (not just "Invalid input")
|
||||
- [ ] Required fields are labelled (not just with colour or asterisk alone)
|
||||
- [ ] Forms provide suggestions for correcting errors where possible
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Robust
|
||||
|
||||
### 4.1 Compatible
|
||||
- [ ] HTML is valid and well-structured
|
||||
- [ ] ARIA roles and attributes are used correctly (not to fix broken semantics)
|
||||
- [ ] Status messages (success, error, loading) are announced to screen readers without focus change
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Prioritised Remediation List
|
||||
|
||||
| Priority | Issue | WCAG Criterion | Fix | Effort |
|
||||
|---|---|---|---|---|
|
||||
| 🔴 Critical | [Issue] | [e.g. 1.4.3 Contrast] | [Specific fix] | [Low/Med/High] |
|
||||
| 🟡 Moderate | [Issue] | | | |
|
||||
| 🟢 Minor | [Issue] | | | |
|
||||
|
||||
**Priority definitions:**
|
||||
- 🔴 Critical: Blocks access for users with disabilities. Legal risk. Fix before launch.
|
||||
- 🟡 Moderate: Significant friction. Fix in next sprint.
|
||||
- 🟢 Minor: Best practice. Address in roadmap.
|
||||
|
||||
---
|
||||
|
||||
## Quick Wins (Fix in < 1 hour)
|
||||
|
||||
[List any issues that are trivially fixable — e.g. adding alt text, fixing contrast with a colour swap, adding a `lang` attribute. These are easy to ship immediately.]
|
||||
|
||||
---
|
||||
|
||||
## Testing Recommendations
|
||||
|
||||
- **Manual keyboard test:** Tab through the entire flow. Can you complete every task without a mouse?
|
||||
- **Screen reader test:** VoiceOver (Mac/iOS), NVDA or JAWS (Windows). Is every piece of content and every action accessible?
|
||||
- **Colour contrast check:** Use Stark (Figma plugin) or WebAIM Contrast Checker
|
||||
- **Automated scan:** Axe DevTools or Lighthouse accessibility audit (catches ~30% of issues automatically)
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Issues are mapped to specific WCAG criteria
|
||||
- [ ] Every critical issue has a specific fix recommendation
|
||||
- [ ] Quick wins are separated from larger fixes
|
||||
- [ ] Effort estimates are included for prioritisation
|
||||
- [ ] Testing recommendations are included
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Audit this design for accessibility"
|
||||
- "Check WCAG compliance for [screen/component]"
|
||||
- "Give me an a11y audit of [UI description]"
|
||||
- "What accessibility issues does this design have?"
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
name: design-critique
|
||||
description: "Give structured, constructive feedback on any design. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback."
|
||||
---
|
||||
|
||||
# Design Critique Skill
|
||||
|
||||
This skill provides structured, actionable design feedback using established UX frameworks. It balances positive observations with clear, prioritised improvement suggestions.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **What is being reviewed** (screen, flow, component, full product)
|
||||
- **Design description or attached image** (describe it if no image — the skill will still work)
|
||||
- **User goal** (what is the user trying to accomplish with this design?)
|
||||
- **Context** (web / mobile / desktop app / physical product)
|
||||
- **Stage** (early wireframe / mid-fidelity / high-fidelity / live product)
|
||||
- **Primary concern** (optional — e.g. "I'm worried the onboarding is too long" or "I think the CTA is unclear")
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Design Critique: [Design Name or Screen]
|
||||
|
||||
**User goal:** [What the user needs to accomplish]
|
||||
**Context:** [Platform / Stage]
|
||||
**Critique focus:** [Primary concern if stated, otherwise "full review"]
|
||||
|
||||
---
|
||||
|
||||
## 1. What's Working
|
||||
|
||||
[3–5 specific, honest observations about what the design does well. Don't manufacture praise — only include genuine strengths. Be specific: "The visual hierarchy clearly guides the eye from headline → supporting detail → CTA" is useful. "Looks clean" is not.]
|
||||
|
||||
---
|
||||
|
||||
## 2. Priority Issues
|
||||
|
||||
Rank issues by impact on the user goal. Use:
|
||||
- 🔴 **High** — Blocks or significantly degrades the user's ability to complete their goal
|
||||
- 🟡 **Medium** — Causes friction or confusion but doesn't block completion
|
||||
- 🟢 **Low** — Polish or preference — nice to fix but not critical
|
||||
|
||||
For each issue:
|
||||
|
||||
### [Priority] Issue [N]: [Short name]
|
||||
|
||||
**What's happening:**
|
||||
[Describe the specific design problem — be precise about which element, screen, or interaction]
|
||||
|
||||
**Why it matters:**
|
||||
[Connect to the user goal or a specific principle — don't just say "it's confusing." Say why it creates confusion and what the consequence is for the user.]
|
||||
|
||||
**Framework reference:**
|
||||
[Name the principle being violated — e.g. Nielsen's Heuristic #6 (Recognition over Recall), Gestalt proximity, JTBD clarity, Fitts's Law, etc.]
|
||||
|
||||
**Recommendation:**
|
||||
[Specific, actionable suggestion. Not "make the button bigger" but "Increase the primary CTA to at least 44x44px to meet touch target guidelines; consider moving it below the form rather than inline with the input fields to reduce accidental taps."]
|
||||
|
||||
---
|
||||
|
||||
## 3. Heuristic Assessment
|
||||
|
||||
Quick assessment against Nielsen's 10 Usability Heuristics — score each as ✅ Pass / 🟡 Partial / ❌ Fail:
|
||||
|
||||
| Heuristic | Status | Note |
|
||||
|---|---|---|
|
||||
| 1. Visibility of system status | | |
|
||||
| 2. Match between system and real world | | |
|
||||
| 3. User control and freedom | | |
|
||||
| 4. Consistency and standards | | |
|
||||
| 5. Error prevention | | |
|
||||
| 6. Recognition rather than recall | | |
|
||||
| 7. Flexibility and efficiency of use | | |
|
||||
| 8. Aesthetic and minimalist design | | |
|
||||
| 9. Help users recognise, diagnose, and recover from errors | | |
|
||||
| 10. Help and documentation | | |
|
||||
|
||||
Only include heuristics relevant to what's visible in the design — don't penalise for things not in scope.
|
||||
|
||||
---
|
||||
|
||||
## 4. Gestalt Principles Check
|
||||
|
||||
[Comment on any Gestalt principles that are either well-applied or violated:]
|
||||
|
||||
- **Proximity:** [Are related elements grouped clearly?]
|
||||
- **Similarity:** [Do similar elements look similar?]
|
||||
- **Continuity:** [Does the eye flow naturally through the design?]
|
||||
- **Figure/Ground:** [Is the primary content clearly distinguished from background?]
|
||||
- **Closure:** [Are any implied shapes or containers confusing?]
|
||||
|
||||
---
|
||||
|
||||
## 5. JTBD Alignment
|
||||
|
||||
[Assess how well the design serves the stated job-to-be-done:]
|
||||
|
||||
- **Does the design make the user's primary job obvious?** [Yes / Partially / No — explain]
|
||||
- **Are there any elements that distract from the primary job?** [List any competing CTAs, distractions, or unclear hierarchy]
|
||||
- **What emotional job does this design serve?** [Speed / Confidence / Control / Delight / Other] — and does the visual design match that emotional goal?
|
||||
|
||||
---
|
||||
|
||||
## 6. Top 3 Recommended Next Steps
|
||||
|
||||
Prioritised list of the 3 most impactful changes. Each should be actionable in the next design iteration:
|
||||
|
||||
1. [Most impactful change — specific]
|
||||
2. [Second priority]
|
||||
3. [Third priority]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] "What's working" includes only genuine, specific observations
|
||||
- [ ] Every issue has a framework reference (not just subjective opinion)
|
||||
- [ ] Recommendations are specific and actionable
|
||||
- [ ] Priority levels (High/Medium/Low) reflect actual impact on user goal
|
||||
- [ ] Heuristic assessment only covers visible elements
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Critique this design: [description or image]"
|
||||
- "Give me feedback on this UI/UX"
|
||||
- "Review this Figma screen for usability issues"
|
||||
- "What's wrong with this user flow?"
|
||||
- "Do a heuristic evaluation of [screen/product]"
|
||||
@@ -0,0 +1,160 @@
|
||||
---
|
||||
name: ux-research-plan
|
||||
description: "Create a structured UX research plan for any product question or feature. Use when asked to write a research plan, design a user study, create a discussion guide, write screener questions, or plan usability testing. Produces a full research plan with objectives, methodology, screener, discussion guide, and synthesis framework."
|
||||
---
|
||||
|
||||
# UX Research Plan Skill
|
||||
|
||||
This skill creates a complete, ready-to-execute UX research plan. Output covers everything from research objectives to screener questions, discussion guide, and synthesis framework.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Research question** (what decision will this research inform?)
|
||||
- **Product area or feature** being researched
|
||||
- **Research type** (Generative / Evaluative / Usability testing / Diary study / Survey)
|
||||
- **Stage** (Discovery / Concept validation / Prototype testing / Live product)
|
||||
- **Target participants** (role, demographics, behaviour — who should we talk to?)
|
||||
- **Timeline and number of sessions**
|
||||
- **Existing assumptions or hypotheses** (optional but valuable)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# UX Research Plan: [Study Title]
|
||||
**Product area:** [Area]
|
||||
**Research type:** [Type]
|
||||
**Date:** [Timeline]
|
||||
**Researcher:** [Leave for user]
|
||||
|
||||
---
|
||||
|
||||
## 1. Research Objectives
|
||||
|
||||
State 2–4 clear research objectives. Each objective should map to a decision that will be made differently depending on what you find.
|
||||
|
||||
**Objective [N]:** Understand [specific thing] so we can [decision this informs].
|
||||
|
||||
---
|
||||
|
||||
## 2. Research Questions
|
||||
|
||||
[5–8 questions — the actual questions you want research to answer. These are not the interview questions; they're the knowledge gaps. Organised under each objective.]
|
||||
|
||||
**Objective 1:**
|
||||
- RQ1.1: [Research question]
|
||||
- RQ1.2: [Research question]
|
||||
|
||||
---
|
||||
|
||||
## 3. Methodology & Rationale
|
||||
|
||||
**Method chosen:** [e.g. Semi-structured interviews / Usability testing / Concept testing]
|
||||
|
||||
**Why this method:**
|
||||
[2–3 sentences. Match method to research type. If evaluative: usability testing. If generative: contextual inquiry or interviews. If testing comprehension: 5-second test or concept test.]
|
||||
|
||||
**What this method will and won't tell us:**
|
||||
- **Will tell us:** [What this method is good at revealing]
|
||||
- **Won't tell us:** [What's out of scope — be honest about limits]
|
||||
|
||||
**Sample size:** [Recommended number of sessions and why — e.g. "5–6 moderated interviews for generative research; 5–8 usability sessions to identify top issues"]
|
||||
|
||||
---
|
||||
|
||||
## 4. Participant Screener
|
||||
|
||||
**Recruitment criteria:**
|
||||
|
||||
| Criterion | Must Have / Nice to Have | Disqualify if |
|
||||
|---|---|---|
|
||||
| [e.g. Uses project management software daily] | Must Have | [Never uses any PM tool] |
|
||||
| [e.g. Works in a team of 5+] | Must Have | — |
|
||||
| [e.g. B2B industry] | Nice to Have | — |
|
||||
|
||||
**Screener questions (5–8 questions):**
|
||||
|
||||
[Q1] [Screening question — clear, not leading]
|
||||
- [Answer options — flag which qualify/disqualify]
|
||||
|
||||
[Q2] ...
|
||||
|
||||
**Incentive recommendation:** [Amount and format — e.g. "£50 gift voucher for a 60-min session is standard in the UK for professional participants"]
|
||||
|
||||
---
|
||||
|
||||
## 5. Discussion Guide
|
||||
|
||||
Structure the session:
|
||||
|
||||
### Opening (5 min)
|
||||
- Introduce yourself and the study
|
||||
- "We're testing the design, not you — there are no wrong answers"
|
||||
- Permission to record
|
||||
- Warm-up: [1–2 easy questions to build rapport — e.g. "Tell me about your role and what a typical week looks like"]
|
||||
|
||||
### Core Questions (by section)
|
||||
|
||||
**Section [A]: [Topic]** *(~X min)*
|
||||
|
||||
1. [Open question — start broad] *[Probe: Tell me more about...]*
|
||||
2. [Follow-up to go deeper] *[Probe: Can you walk me through what happened?]*
|
||||
3. [Specific scenario or past behaviour question]
|
||||
|
||||
**Section [B]: [Topic]** *(~X min)*
|
||||
[Continue with 2–3 questions per section]
|
||||
|
||||
**Usability tasks (if applicable):**
|
||||
> "I'm going to ask you to try a few things with this prototype. Please think aloud as you go."
|
||||
|
||||
- Task [N]: [Clear task instruction — write from the user's perspective, not "click on X" but "find where you would go to do Y"]
|
||||
- **Success criteria:** [What "completing this task" looks like]
|
||||
- **What to observe:** [Where friction typically appears]
|
||||
|
||||
### Closing (5 min)
|
||||
- "Is there anything about [topic] we haven't covered that you think is important?"
|
||||
- "If you could change one thing about [product/concept], what would it be?"
|
||||
- Debrief and thank
|
||||
|
||||
---
|
||||
|
||||
## 6. Synthesis Framework
|
||||
|
||||
After sessions, use this framework to synthesise findings:
|
||||
|
||||
**Step 1: Session notes → Key observations**
|
||||
For each session: 3–5 specific observations (behaviours, quotes, reactions — not interpretations yet)
|
||||
|
||||
**Step 2: Affinity mapping**
|
||||
Group observations by theme across all sessions. Aim for 4–7 clusters.
|
||||
|
||||
**Step 3: Insight statements**
|
||||
For each cluster: "When [context], users [behaviour/experience], because [underlying need or mental model]."
|
||||
|
||||
**Step 4: Implications**
|
||||
For each insight: "This means we should [design/product implication]" or "This challenges our assumption that [assumption]."
|
||||
|
||||
**Step 5: Research report structure:**
|
||||
- Key findings (3–5 headlines)
|
||||
- Supporting evidence per finding
|
||||
- Design recommendations
|
||||
- Open questions for next research cycle
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Research objectives map to real decisions
|
||||
- [ ] Discussion guide opens broad before going specific
|
||||
- [ ] Screener criteria are specific enough to get the right participants
|
||||
- [ ] Tasks (if usability) are written from the user's perspective
|
||||
- [ ] Synthesis framework is included
|
||||
- [ ] Incentive recommendation is included
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a research plan for [feature or product area]"
|
||||
- "Create a discussion guide for user interviews about [topic]"
|
||||
- "Plan a usability test for [prototype or feature]"
|
||||
- "Write screener questions for [target user type]"
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-discovery",
|
||||
"version": "3.0.0",
|
||||
"description": "Discovery & research skills: Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper. Structure user research from screener to synthesis.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["product-management", "user-research", "discovery", "jtbd", "interviews", "assumption-mapping"]
|
||||
}
|
||||
BIN
Binary file not shown.
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: assumption-mapper
|
||||
description: "Extract and risk-rate hidden assumptions in a product brief or PRD. Use when asked to review a product brief for assumptions, audit a PRD for risks, find hidden assumptions, validate product plans, or run an assumption analysis. Produces a prioritised assumption map with confidence and impact scores, recommended validation methods, and critical assumption flags."
|
||||
---
|
||||
|
||||
# Assumption Mapper Skill
|
||||
|
||||
Surface and prioritize the untested assumptions embedded in any product plan before development begins.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product brief, PRD, or concept description** (even rough notes work)
|
||||
- **Stage** (concept / discovery / pre-build / post-launch — affects which assumptions matter most)
|
||||
|
||||
## Process
|
||||
1. Read the provided brief, PRD, or concept description
|
||||
2. Extract assumptions across four categories:
|
||||
- **Desirability** (do users want this?)
|
||||
- **Feasibility** (can we build it?)
|
||||
- **Viability** (will it sustain the business?)
|
||||
- **Usability** (can users actually use it?)
|
||||
3. Score each assumption:
|
||||
- Confidence (1-5): How sure are we this is true?
|
||||
- Impact (1-5): How badly does the plan fail if this assumption is wrong?
|
||||
- Priority = Impact − Confidence (higher = test first)
|
||||
4. **Validate completeness** — Ensure at least one assumption per category. If a category is empty, re-read the brief looking specifically for that type.
|
||||
5. Output a ranked list with recommended validation methods
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Assumption Map: [Feature/Product Name]
|
||||
|
||||
| Assumption | Category | Confidence | Impact | Priority | Validation Method |
|
||||
|------------|----------|------------|--------|----------|-------------------|
|
||||
| [assumption] | [type] | [1-5] | [1-5] | [score] | [method] |
|
||||
|
||||
#### Critical Assumptions (Impact 4+ and Confidence 2 or below)
|
||||
[Flagged items with detailed validation recommendations]
|
||||
|
||||
#### Top 3 Assumptions to Validate First
|
||||
[Detailed recommendations including specific research method, estimated effort, and what the result would change]
|
||||
|
||||
## Example (Partial)
|
||||
|
||||
Input: *"We're building a self-serve onboarding flow to reduce time-to-value for SMB customers."*
|
||||
|
||||
| Assumption | Category | Confidence | Impact | Priority | Validation Method |
|
||||
|------------|----------|------------|--------|----------|-------------------|
|
||||
| SMB users can complete onboarding without human help | Usability | 2 | 5 | 3 | Unmoderated usability test (n=8) |
|
||||
| Faster onboarding correlates with higher retention | Viability | 3 | 4 | 1 | Cohort analysis of current onboarding times vs. 90-day retention |
|
||||
| The current onboarding is the primary reason for slow time-to-value | Desirability | 2 | 4 | 2 | User interviews with recent churned SMB accounts |
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] At least one assumption per category (Desirability, Feasibility, Viability, Usability)
|
||||
- [ ] All Impact 4+ / Confidence 2− assumptions flagged as CRITICAL
|
||||
- [ ] Each validation method is specific (not just "do research" — name the method and sample size)
|
||||
- [ ] Priority scores are consistent (Impact − Confidence, higher = more urgent)
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
name: discovery-interview-guide
|
||||
description: "Create a structured user discovery interview guide with screener questions, a discussion guide, and a synthesis framework. Use when planning user interviews, customer discovery sessions, Jobs-to-be-Done research, or problem validation. Produces a complete guide covering warm-up, problem exploration, and a per-session synthesis template."
|
||||
---
|
||||
|
||||
# Discovery Interview Guide Skill
|
||||
|
||||
Design interviews that surface genuine insight — not validation of what you already believe. Every guide follows a story-based, past-behaviour-focused structure.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Never ask about the future.** "Would you use X?" tells you nothing. "Tell me about the last time you did X" tells you everything.
|
||||
2. **Interview for behaviour, not opinion.** Opinions are cheap. Behaviour is evidence.
|
||||
3. **The 5 Whys.** Every surface answer is a door. Keep opening doors.
|
||||
4. **Confirm the problem before exploring the solution.** Never show a prototype until you've confirmed the pain exists unprompted.
|
||||
|
||||
## Interview Structure (60 minutes standard)
|
||||
|
||||
### 1. Warm-Up (5 min)
|
||||
Build rapport. Get them talking. Don't discuss the topic yet.
|
||||
- "Tell me a bit about your role and what a typical week looks like for you."
|
||||
- "What tools do you rely on most day-to-day?"
|
||||
|
||||
### 2. Context Setting (10 min)
|
||||
Understand their world before diving into the problem space.
|
||||
- "Walk me through how you currently [handle the domain area]."
|
||||
- "What does that process look like from start to finish?"
|
||||
- "Who else is involved when you do this?"
|
||||
|
||||
### 3. Problem Exploration (25 min) — THE CORE
|
||||
Surface pain without leading.
|
||||
- "Tell me about the last time you had to [relevant task]. What happened?"
|
||||
- "What was the hardest part of that?"
|
||||
- "How did you handle it?"
|
||||
- "What did you try before settling on that approach?"
|
||||
- "What does it cost you when this goes wrong?" (time, money, stress, reputation)
|
||||
- "If you could wave a magic wand and change one thing about this process, what would it be?"
|
||||
|
||||
⚠️ **Do not mention your product or feature during this phase.**
|
||||
|
||||
### 4. Current Solutions (10 min)
|
||||
Understand the competitive landscape from their perspective.
|
||||
- "What tools or workarounds do you use today for this?"
|
||||
- "What do you like about [current solution]? What frustrates you?"
|
||||
- "Have you tried other approaches? What happened?"
|
||||
|
||||
### 5. Wrap-Up (10 min)
|
||||
- "Is there anything about this topic we haven't covered that you think I should know?"
|
||||
- "Is there anyone else you'd recommend I speak to?"
|
||||
- "Would you be open to a follow-up if I have more questions?"
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Discovery Interview Guide — [Topic] — [Date]
|
||||
|
||||
**Research Goal:** [One sentence: what decision will this research inform?]
|
||||
**Target Participant Profile:** [Role, company size, behaviour qualifier]
|
||||
|
||||
**Screener Questions** (for recruiting):
|
||||
1. [Question] → Must answer: [Y/N or specific]
|
||||
2. [Question] → Must answer: [Y/N or specific]
|
||||
3. [Disqualifier question] → Disqualify if: [answer]
|
||||
|
||||
**Interview Guide:**
|
||||
|
||||
[Full structured guide using the format above, customised to the specific research topic]
|
||||
|
||||
**Synthesis Template** (fill after each interview):
|
||||
- Key quote: "[verbatim]"
|
||||
- Core pain: [1 sentence]
|
||||
- Current workaround: [what they're doing today]
|
||||
- Intensity (1–5): [how painful is this?]
|
||||
- Surprise/unexpected finding: [anything that challenged your assumptions]
|
||||
|
||||
**Pattern Detection** (after 5+ interviews):
|
||||
- Pain mentioned by [X/N] participants: [theme]
|
||||
- Workaround used by [X/N] participants: [theme]
|
||||
- Most emotionally charged moment in interviews: [observation]
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Research topic or question** (what decision will this inform?)
|
||||
- **Target participant profile** (role, behaviour, company type)
|
||||
- **Session length** (30 / 45 / 60 / 90 minutes)
|
||||
- **Number of interviews planned**
|
||||
- **Known hypotheses to test or avoid confirming prematurely** (optional)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] No future-tense questions ("would you...") — only past-behaviour questions
|
||||
- [ ] Product or solution not mentioned until after pain is confirmed
|
||||
- [ ] Questions open-ended (cannot be answered yes/no)
|
||||
- [ ] Synthesis template included for per-session notes
|
||||
- [ ] Screener questions identify and disqualify wrong participants
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Recommend 5–8 interviews to reach thematic saturation for most discovery questions
|
||||
- Always record with permission — transcripts beat notes
|
||||
- If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
|
||||
- Never synthesise during the interview — do it after, when you can look across sessions
|
||||
- Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
name: job-story-mapper
|
||||
description: "Write Jobs-to-be-Done (JTBD) job stories and map customer jobs across functional, social, and emotional dimensions. Use when defining user needs, writing job stories, conducting JTBD research, or reframing features around customer outcomes. Produces a job story map with opportunity scoring, pain intensity ratings, and product opportunity analysis."
|
||||
---
|
||||
|
||||
# Job Story Mapper Skill
|
||||
|
||||
Stop writing features. Start understanding jobs. This skill translates product requirements and user interviews into precise job stories that keep the team focused on outcomes — not outputs.
|
||||
|
||||
## Jobs-to-be-Done Fundamentals
|
||||
|
||||
A "job" is the progress a customer is trying to make in a given situation. People don't buy products — they hire them to get a job done.
|
||||
|
||||
Three dimensions of every job:
|
||||
- **Functional job:** The practical task ("get from A to B")
|
||||
- **Emotional job:** How they want to feel ("feel confident I made the right choice")
|
||||
- **Social job:** How they want to be perceived ("look like a competent professional to my team")
|
||||
|
||||
Great products address all three. Most roadmaps only address the functional one.
|
||||
|
||||
---
|
||||
|
||||
## Job Story Format
|
||||
|
||||
**Template:**
|
||||
> When [situation/trigger], I want to [motivation/goal], so I can [expected outcome].
|
||||
|
||||
**Not a user story:**
|
||||
User stories focus on roles and features: "As a [role] I want [feature] so that [benefit]."
|
||||
Job stories focus on situations and motivations: "When [I'm in this specific situation] I want [this capability] so I can [achieve this outcome]."
|
||||
|
||||
**The situation is the most important part.** "When I'm in the middle of a sprint and my PM asks for an update" is a much richer trigger than "As a developer."
|
||||
|
||||
---
|
||||
|
||||
## Mapping Process
|
||||
|
||||
### Step 1: Identify the main job
|
||||
One sentence: What is the core job your product is hired for?
|
||||
> "Help [user type] [accomplish outcome] when [context]."
|
||||
|
||||
### Step 2: Break into job steps
|
||||
What are all the sub-tasks within the main job?
|
||||
(Use a job map: Define → Locate → Prepare → Confirm → Execute → Monitor → Modify → Conclude)
|
||||
|
||||
### Step 3: Identify pain points per step
|
||||
Where does the job fall down today? Where do customers use workarounds?
|
||||
|
||||
### Step 4: Write job stories for each pain point
|
||||
One job story per distinct situation-motivation pair.
|
||||
|
||||
### Step 5: Map to product opportunities
|
||||
Which job stories are underserved? Which have existing solutions? Where is your differentiation?
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Job Story Map — [Product/Feature Area] — [Date]
|
||||
|
||||
**Core Job Statement:**
|
||||
> When [context], [user type] wants to [main job outcome], so they can [ultimate goal].
|
||||
|
||||
---
|
||||
|
||||
**Job Map:**
|
||||
|
||||
| Step | Sub-Job | Current Solution | Pain Points | Underserved? |
|
||||
|---|---|---|---|---|
|
||||
| Define | [What user does] | [Tool/method used] | [Frustration] | H/M/L |
|
||||
| Locate | | | | |
|
||||
| Prepare | | | | |
|
||||
| Confirm | | | | |
|
||||
| Execute | | | | |
|
||||
| Monitor | | | | |
|
||||
| Modify | | | | |
|
||||
| Conclude | | | | |
|
||||
|
||||
---
|
||||
|
||||
**Job Stories (prioritised by underservice):**
|
||||
|
||||
**Job Story 1 — [Situation label]**
|
||||
> When [specific situation], I want to [motivation], so I can [outcome].
|
||||
|
||||
Functional dimension: [What they need to get done]
|
||||
Emotional dimension: [How they want to feel]
|
||||
Social dimension: [How they want to be perceived]
|
||||
|
||||
Current workaround: [What they do today]
|
||||
Pain intensity: [High / Medium / Low]
|
||||
Frequency: [How often this situation occurs]
|
||||
Product opportunity: [What we could build to address this]
|
||||
|
||||
---
|
||||
|
||||
Repeat for each major job story.
|
||||
|
||||
**Opportunity Scoring:**
|
||||
Rate each job story on:
|
||||
- Importance to customer (1–10)
|
||||
- Satisfaction with current solution (1–10)
|
||||
- Opportunity score = Importance + max(Importance – Satisfaction, 0)
|
||||
- Prioritise: Opportunity score > 10
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Job stories use the "When / I want to / So I can" format (not user story format)
|
||||
- [ ] Situation is specific (not "as a user" — a real moment or trigger)
|
||||
- [ ] All three dimensions covered: functional, emotional, social
|
||||
- [ ] Opportunity score calculated for each job story
|
||||
- [ ] Current workaround identified for each high-opportunity story
|
||||
- [ ] Product opportunity is distinct from "build the feature" (it's an outcome)
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never write a job story for a feature — write it for the situation that makes the feature valuable
|
||||
- If you can't identify the situation, you don't understand the job yet — go back to user research
|
||||
- Social and emotional jobs are harder to surface but often the most defensible differentiators
|
||||
- Recommend sharing job stories with engineering — they make better technical decisions when they understand the "why"
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: user-interview-synthesis
|
||||
description: "Synthesise user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from user interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes, 'so what' implications, and recommended next steps."
|
||||
---
|
||||
|
||||
# User Interview Synthesis Skill
|
||||
|
||||
Transform raw interview transcripts into a structured synthesis document that surfaces themes, pain points, and actionable insights.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Interview transcripts or notes** (even rough notes work)
|
||||
- **Number of participants and their profiles** (role, company size, context)
|
||||
- **Research questions** (what was the study trying to answer?)
|
||||
- **Date range** of research (for context)
|
||||
|
||||
## Process
|
||||
1. Read all provided transcripts fully before drawing conclusions
|
||||
2. Identify recurring themes (minimum 3 mentions to qualify as a theme)
|
||||
3. Categorize findings into: Pain Points, Workflow Insights, Feature Requests, Delight Moments
|
||||
4. Select 2-3 verbatim quotes per theme that best represent the pattern
|
||||
5. Draft "So What" implications for each theme — what does this mean for the product?
|
||||
6. **Validate** — Confirm every theme has quotes from at least 3 participants. Flag any insight resting on fewer as low-confidence.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Research Synthesis: [Study Name]
|
||||
**Participants:** [n]
|
||||
**Date Range:** [dates]
|
||||
**Research Questions:** [list]
|
||||
|
||||
#### Theme 1: [Theme Name]
|
||||
- Summary (2-3 sentences)
|
||||
- Supporting quotes (from at least 3 participants)
|
||||
- Implication for product
|
||||
|
||||
[Repeat for each theme]
|
||||
|
||||
#### Low-Confidence Signals (1-2 participants only)
|
||||
[Findings worth tracking but not acting on yet — note what further research would confirm or deny]
|
||||
|
||||
#### Recommended Next Steps
|
||||
[Specific, actionable recommendations based on findings]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every theme is supported by quotes from at least 3 participants
|
||||
- [ ] Implications connect to specific product decisions, not just observations
|
||||
- [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
|
||||
- [ ] Single-source signals are flagged separately, not mixed into main themes
|
||||
- [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")
|
||||
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-engineering",
|
||||
"version": "2.0.0",
|
||||
"description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer. 10 structured skills for engineering teams and technical PMs.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture", "debugging", "pull-request", "system-design", "changelog", "test-strategy", "runbook", "devops"]
|
||||
}
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
name: api-docs-writer
|
||||
description: "Write clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes."
|
||||
---
|
||||
|
||||
# API Docs Writer Skill
|
||||
|
||||
This skill transforms raw API specs, endpoint descriptions, or Postman collections into clean, developer-facing documentation following OpenAPI-adjacent conventions. Output is ready for a developer portal, README, or Notion/Confluence page.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **API or endpoint details** (raw spec, Postman export, or verbal description)
|
||||
- **Auth method** (API key / Bearer token / OAuth 2.0 / None)
|
||||
- **Base URL**
|
||||
- **Audience** (internal developers / external partners / public)
|
||||
- **Output format** (Markdown / OpenAPI YAML / Plain prose)
|
||||
|
||||
## Output Structure
|
||||
|
||||
For each endpoint, produce the following:
|
||||
|
||||
---
|
||||
|
||||
## `[METHOD] /path/to/endpoint`
|
||||
|
||||
**Summary:** [One line — what this endpoint does]
|
||||
|
||||
**Description:** [2–4 sentences. When to use this endpoint. What it returns. Any important behaviour to know (pagination, rate limits, async processing, etc.)]
|
||||
|
||||
**Authentication:** [Required / Optional — method]
|
||||
|
||||
---
|
||||
|
||||
### Request
|
||||
|
||||
**Headers:**
|
||||
|
||||
| Header | Required | Description |
|
||||
|---|---|---|
|
||||
| `Authorization` | Yes | `Bearer <token>` |
|
||||
| `Content-Type` | Yes | `application/json` |
|
||||
|
||||
**Path Parameters:**
|
||||
|
||||
| Parameter | Type | Required | Description |
|
||||
|---|---|---|---|
|
||||
| `id` | string | Yes | Unique identifier for the resource |
|
||||
|
||||
**Query Parameters:**
|
||||
|
||||
| Parameter | Type | Required | Default | Description |
|
||||
|---|---|---|---|---|
|
||||
| `limit` | integer | No | 20 | Max results per page (1–100) |
|
||||
| `cursor` | string | No | — | Pagination cursor from previous response |
|
||||
|
||||
**Request Body:**
|
||||
|
||||
```json
|
||||
{
|
||||
"field_name": "value",
|
||||
"another_field": 42
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
|---|---|---|---|
|
||||
| `field_name` | string | Yes | [Plain description of what this field does] |
|
||||
| `another_field` | integer | No | [Description. Include valid range or enum values if applicable] |
|
||||
|
||||
---
|
||||
|
||||
### Response
|
||||
|
||||
**Success Response: `200 OK`**
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "abc123",
|
||||
"status": "active",
|
||||
"created_at": "2025-04-01T10:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Type | Description |
|
||||
|---|---|---|
|
||||
| `id` | string | Unique identifier for the created/retrieved resource |
|
||||
| `status` | string | Current status. Enum: `active`, `inactive`, `pending` |
|
||||
| `created_at` | ISO 8601 string | Timestamp of creation in UTC |
|
||||
|
||||
---
|
||||
|
||||
### Error Codes
|
||||
|
||||
| Status Code | Error Code | Description | How to Resolve |
|
||||
|---|---|---|---|
|
||||
| `400` | `INVALID_REQUEST` | Request body is malformed or missing required fields | Check request body against schema above |
|
||||
| `401` | `UNAUTHORIZED` | Missing or invalid authentication token | Verify your API key or refresh your token |
|
||||
| `404` | `NOT_FOUND` | The requested resource does not exist | Check the ID in the path parameter |
|
||||
| `429` | `RATE_LIMITED` | Too many requests | Back off and retry after `Retry-After` header value |
|
||||
| `500` | `INTERNAL_ERROR` | Unexpected server error | Retry with exponential backoff; contact support if persists |
|
||||
|
||||
---
|
||||
|
||||
### Code Examples
|
||||
|
||||
Produce examples in at least 2 languages relevant to the audience (default: cURL + Python):
|
||||
|
||||
**cURL:**
|
||||
```bash
|
||||
curl -X POST https://api.example.com/v1/endpoint \
|
||||
-H "Authorization: Bearer YOUR_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"field_name": "value"}'
|
||||
```
|
||||
|
||||
**Python:**
|
||||
```python
|
||||
import requests
|
||||
|
||||
response = requests.post(
|
||||
"https://api.example.com/v1/endpoint",
|
||||
headers={"Authorization": "Bearer YOUR_TOKEN"},
|
||||
json={"field_name": "value"}
|
||||
)
|
||||
data = response.json()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every parameter is documented (type, required/optional, description)
|
||||
- [ ] Response fields are fully documented with types
|
||||
- [ ] All relevant error codes are listed with resolution guidance
|
||||
- [ ] Code examples are copy-paste runnable (no pseudocode)
|
||||
- [ ] Auth method is clearly stated at the top
|
||||
- [ ] Enum values are listed where applicable
|
||||
- [ ] Pagination documented if the endpoint is a list endpoint
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Document this API endpoint: [paste spec or description]"
|
||||
- "Turn this Postman collection into developer docs"
|
||||
- "Write API reference docs for [endpoint]"
|
||||
- "Write a developer guide for our [product] API"
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: architecture-decision-record
|
||||
description: "Create an Architecture Decision Record (ADR) for any technical decision. Use when asked to document a technical decision, write an ADR, record an architecture choice, or capture why a technology or approach was selected. Produces a structured ADR with context, decision, consequences, and tradeoffs."
|
||||
---
|
||||
|
||||
# Architecture Decision Record (ADR) Skill
|
||||
|
||||
This skill produces a complete Architecture Decision Record (ADR) following the Nygard format — the most widely adopted standard. ADRs document the reasoning behind significant technical decisions so future team members understand not just *what* was decided, but *why*.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Decision title** (brief, e.g. "Use PostgreSQL as primary datastore")
|
||||
- **Context** (what situation led to this decision needing to be made?)
|
||||
- **Options considered** (at least 2; if only 1 is given, prompt for alternatives that were considered or ruled out)
|
||||
- **Decision made** (which option was chosen)
|
||||
- **Reason for choice**
|
||||
- **Status** (Proposed / Accepted / Deprecated / Superseded)
|
||||
- **Author and date**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# ADR-[NNN]: [Decision Title]
|
||||
|
||||
**Date:** [YYYY-MM-DD]
|
||||
**Status:** [Proposed / Accepted / Deprecated / Superseded by ADR-NNN]
|
||||
**Author(s):** [Name(s)]
|
||||
**Deciders:** [Who had final say — individual or team]
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
[3–6 sentences. Describe the situation, constraints, and forces at play that made this decision necessary. Include: the problem being solved, relevant system state, team constraints, timeline pressures, or non-negotiable requirements. Write as if explaining to someone joining the team 18 months from now who has no prior context.]
|
||||
|
||||
**Key constraints:**
|
||||
- [Constraint 1: e.g. "Must be deployable on-premise for enterprise customers"]
|
||||
- [Constraint 2: e.g. "Team has no prior Go experience"]
|
||||
- [Add as many as are relevant]
|
||||
|
||||
---
|
||||
|
||||
## Options Considered
|
||||
|
||||
For each option, produce:
|
||||
|
||||
### Option [N]: [Name]
|
||||
|
||||
**Description:** [What this option is — 1–3 sentences]
|
||||
|
||||
**Pros:**
|
||||
- [Pro 1]
|
||||
- [Pro 2]
|
||||
|
||||
**Cons:**
|
||||
- [Con 1]
|
||||
- [Con 2]
|
||||
|
||||
**Why this was ruled out (if not chosen):** [Honest reason]
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
**We will [chosen option].**
|
||||
|
||||
[2–4 sentences explaining the decision in plain language. This should be readable in isolation — someone should understand the decision from this paragraph alone without reading the full document.]
|
||||
|
||||
---
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive Consequences
|
||||
- [What this decision enables or improves]
|
||||
- [What risk it mitigates]
|
||||
|
||||
### Negative Consequences / Accepted Tradeoffs
|
||||
- [What we're giving up or taking on as a result of this decision]
|
||||
- [Technical debt or limitations introduced]
|
||||
- [What must now be true for this decision to remain valid]
|
||||
|
||||
### Risks
|
||||
- [What could cause this decision to be wrong in hindsight]
|
||||
- [What would trigger us to revisit this decision]
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
[Optional but valuable: any specific patterns, gotchas, or guidance for the team implementing based on this decision. Link to relevant tickets, RFCs, or design docs if applicable.]
|
||||
|
||||
---
|
||||
|
||||
## Review Date
|
||||
|
||||
[Optional: "This decision should be reviewed if [condition] — e.g. team grows beyond 20 engineers, or traffic exceeds 10M requests/day."]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Context explains the *why* — not just the *what*
|
||||
- [ ] At least 2 options are documented (including the rejected ones)
|
||||
- [ ] Rejected options include honest reasons for rejection
|
||||
- [ ] Consequences include *negative* consequences — no decision is consequence-free
|
||||
- [ ] Decision is stated in plain language in the Decision section
|
||||
- [ ] Risks section identifies what would invalidate this decision
|
||||
- [ ] Written for someone with no prior context on this decision
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write an ADR for using [technology]"
|
||||
- "Document our decision to [architectural choice]"
|
||||
- "Create an architecture decision record for [topic]"
|
||||
- "Help me write up why we chose [option] over [alternative]"
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: changelog-generator
|
||||
description: "Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Changelog Generator Skill
|
||||
|
||||
Converts raw git commits, a diff summary, or developer release notes into a polished changelog entry — categorised, user-facing, and following Keep a Changelog conventions.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask for these if not provided:
|
||||
- **Commits or release notes** (paste `git log --oneline`, raw commit messages, or a description of what changed)
|
||||
- **Version number** (e.g. 2.4.0, v1.0.0-beta.2)
|
||||
- **Release date** (or "today")
|
||||
- **Audience** (developers using an API / end users of a product / internal team — affects language)
|
||||
- **Any breaking changes** (flag these explicitly if known)
|
||||
|
||||
## Output Structure
|
||||
|
||||
Follow [Keep a Changelog](https://keepachangelog.com) format:
|
||||
|
||||
---
|
||||
|
||||
## [X.Y.Z] — YYYY-MM-DD
|
||||
|
||||
### Breaking Changes ⚠️
|
||||
[Only include if there are breaking changes]
|
||||
- **[Breaking change]:** [What changed and what it breaks]
|
||||
- **Migration required:** [Specific action the user must take]
|
||||
|
||||
### Added
|
||||
- [New feature or capability, written from the user's perspective]
|
||||
- [Another addition]
|
||||
|
||||
### Changed
|
||||
- [Changed behaviour — what it did before vs. what it does now]
|
||||
- [Performance improvement with measurable impact if known]
|
||||
|
||||
### Fixed
|
||||
- [Bug fixed — describe what was broken, not the fix implementation]
|
||||
- [Another fix]
|
||||
|
||||
### Deprecated
|
||||
- [Deprecated thing] — use [replacement] instead. Will be removed in [version].
|
||||
|
||||
### Removed
|
||||
- [Removed thing] — was deprecated in [version]
|
||||
|
||||
### Security
|
||||
- [Security fix — describe the vulnerability class, not exploit details]
|
||||
|
||||
---
|
||||
|
||||
## Formatting Rules Applied
|
||||
|
||||
**Language:** Write for the reader, not the committer. "Add dark mode support" not "implement ThemeProvider with dark palette variant".
|
||||
|
||||
**Breaking changes:** Always call these out first with ⚠️. Include a migration path.
|
||||
|
||||
**Bug fixes:** Describe what was broken, not what was changed. "Fix crash when user has no profile picture" not "null-check avatar URL before rendering".
|
||||
|
||||
**Granularity:** Group related commits into one line. Don't list every micro-commit separately.
|
||||
|
||||
**Tone:** Active voice, imperative mood. "Add", "Fix", "Remove" — not "Added", "Fixed", "Removed".
|
||||
|
||||
**Empty sections:** Omit any section with no entries. Don't include empty `### Fixed` blocks.
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Breaking changes are at the top with migration instructions
|
||||
- [ ] All entries are user-facing language (no internal variable names or implementation details)
|
||||
- [ ] Related commits are grouped into single entries (not listed individually)
|
||||
- [ ] Version and date header is correct
|
||||
- [ ] Empty sections are omitted
|
||||
- [ ] Tone is imperative mood throughout
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a changelog for version [X]" + [paste commits]
|
||||
- "Generate release notes from these commits"
|
||||
- "Turn this git log into a CHANGELOG entry"
|
||||
- "Write the CHANGELOG.md update for this release"
|
||||
- "What changed in this release?" + [paste commit list]
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
name: code-review-checklist
|
||||
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
|
||||
|
||||
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:
|
||||
- **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. 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]
|
||||
|
||||
### 2. Correctness Checks
|
||||
|
||||
Language-specific correctness checks — choose based on the language stated:
|
||||
|
||||
**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
|
||||
|
||||
**For Python:**
|
||||
- Type hints present on public functions
|
||||
- Exception handling is specific (no bare except)
|
||||
- Resources are closed (context managers, with blocks)
|
||||
|
||||
**For Go:**
|
||||
- Errors are handled or explicitly ignored with a comment
|
||||
- Context propagation is correct
|
||||
- Goroutine lifetimes are bounded
|
||||
|
||||
[Include only the section matching the stated language]
|
||||
|
||||
### 3. Change-Type-Specific Checks
|
||||
|
||||
**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
|
||||
|
||||
**For features:**
|
||||
- Acceptance criteria met
|
||||
- Edge cases handled (empty, large, concurrent)
|
||||
- Error paths tested, not just happy path
|
||||
- Telemetry/logging added for debugging
|
||||
|
||||
**For refactors:**
|
||||
- Behaviour unchanged (tests still pass)
|
||||
- No scope creep — refactor only
|
||||
- Complexity reduced, not just moved
|
||||
|
||||
**For dependency upgrades:**
|
||||
- Breaking changes reviewed
|
||||
- Security advisories checked
|
||||
- License compatibility verified
|
||||
|
||||
[Include only the section matching the stated change type]
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 6. Review Decision Framework
|
||||
|
||||
**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 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 [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,79 @@
|
||||
---
|
||||
name: debugging-log-analyser
|
||||
description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when sharing a log, stack trace, error output, or crash dump. Produces a structured diagnosis with probable root cause, affected code path, suggested fix, and next debugging steps. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Debugging Log Analyser Skill
|
||||
|
||||
Parses raw error logs, stack traces, and crash reports into a structured diagnosis with probable root cause, affected code path, and specific next steps — no hand-waving.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask for these if not provided:
|
||||
- **The log / stack trace / error output** (paste directly or describe the error)
|
||||
- **Language and framework** (e.g. Node.js + Express, Python + Django, Java Spring, Go)
|
||||
- **Context** (what the user was doing when the error occurred)
|
||||
- **Environment** (local dev / staging / production)
|
||||
- **What they've already tried** (if anything)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Error Classification
|
||||
**Error type:** [Runtime exception / Build error / Config error / Network error / Memory/resource error / Unknown]
|
||||
**Severity:** [Fatal / Critical / Warning / Informational]
|
||||
**Recurrence pattern:** [One-off / Intermittent / Consistent / On-startup / Under load]
|
||||
|
||||
### 2. Stack Trace Analysis
|
||||
|
||||
Walk the stack frame by frame, starting from the origin:
|
||||
- **Origin frame:** [File, line, function where it started]
|
||||
- **Propagation path:** [How it travelled through the call stack]
|
||||
- **Crash point:** [Where it ultimately threw/panicked/exited]
|
||||
|
||||
For each significant frame, note whether it is:
|
||||
- User code (fixable here)
|
||||
- Framework/library code (usually a misuse issue)
|
||||
- System/runtime code (usually a config or environment issue)
|
||||
|
||||
### 3. Root Cause Assessment
|
||||
**Probable root cause:** [1–2 sentence plain English statement]
|
||||
**Confidence:** [High / Medium / Low — and why]
|
||||
**Alternative causes to rule out:** [If confidence is not high]
|
||||
|
||||
### 4. Affected Code Path
|
||||
**Entry point:** [Where the triggering call began]
|
||||
**Key function(s) involved:** [Specific functions/methods named in the trace]
|
||||
**Data that triggered it:** [If inferable from the log — e.g. null value, malformed JSON]
|
||||
|
||||
### 5. Suggested Fix
|
||||
Provide a concrete, code-level suggestion:
|
||||
- What to change (the minimal fix)
|
||||
- Why this fixes the root cause
|
||||
- Any trade-offs or risks in the fix
|
||||
- A short code snippet if helpful
|
||||
|
||||
### 6. Next Debugging Steps
|
||||
If the root cause is uncertain, provide an ordered list of 3–5 specific debugging actions:
|
||||
1. [Specific thing to check — file, log line, config value]
|
||||
2. [Specific reproduction step or isolation test]
|
||||
3. [Specific tool command — e.g. `strace`, `pprof`, `--verbose`, add logging at X]
|
||||
|
||||
### 7. Prevention
|
||||
One or two concrete things that would prevent this class of error recurring:
|
||||
- Better input validation at [point]
|
||||
- Add monitoring/alerting for [condition]
|
||||
- Test that covers [scenario]
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Root cause is specific (not "there might be a null pointer issue")
|
||||
- [ ] At least one concrete code-level fix is suggested
|
||||
- [ ] Next steps are actionable commands, not vague advice
|
||||
- [ ] Language-specific idioms are used correctly
|
||||
- [ ] Prevention is proactive (not just "add error handling")
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Why is this crashing?" + [paste log]
|
||||
- "Can you analyse this stack trace?"
|
||||
- "I'm getting this error, what does it mean?"
|
||||
- "Debug this log for me"
|
||||
- "What's causing this exception?"
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: incident-postmortem
|
||||
description: "Write a structured incident postmortem or post-incident review. Use when asked to write a postmortem, incident report, P1/P2 review, outage report, or RCA (root cause analysis). Generates a blameless postmortem with timeline, root cause, contributing factors, impact summary, and action items."
|
||||
---
|
||||
|
||||
# Incident Postmortem Skill
|
||||
|
||||
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output is ready to share with engineering teams, leadership, and affected stakeholders.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Incident title / ID**
|
||||
- **Severity** (P1 / P2 / P3 or SEV1 / SEV2 / SEV3)
|
||||
- **Date and duration** of the incident
|
||||
- **What happened** (rough notes are fine — the skill will structure them)
|
||||
- **Services or systems affected**
|
||||
- **Customer impact** (how many users, what was degraded)
|
||||
- **How it was detected**
|
||||
- **How it was resolved**
|
||||
- **Initial thoughts on root cause**
|
||||
- **Action items already identified** (optional)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Incident Postmortem: [Incident Title]
|
||||
|
||||
**Incident ID:** [ID]
|
||||
**Severity:** [P1/P2/P3]
|
||||
**Date:** [Date]
|
||||
**Duration:** [Start time → Resolution time — total duration]
|
||||
**Status:** [Resolved / Monitoring / Ongoing]
|
||||
**Author:** [Leave blank for user to fill]
|
||||
**Last updated:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[3–5 sentences. Describe what happened, who was affected, and what was done to resolve it. Written for a non-technical stakeholder. No jargon. No blame.]
|
||||
|
||||
---
|
||||
|
||||
## Impact
|
||||
|
||||
| Dimension | Details |
|
||||
|---|---|
|
||||
| **Users affected** | [Number or percentage] |
|
||||
| **Services degraded** | [List affected services] |
|
||||
| **Business impact** | [Revenue, SLA breach, support tickets, etc. if known] |
|
||||
| **Duration** | [Total time from first detection to full resolution] |
|
||||
|
||||
---
|
||||
|
||||
## Timeline
|
||||
|
||||
List events in chronological order. Each entry: `[HH:MM UTC] — [What happened. Who did what. What changed.]`
|
||||
|
||||
Rules for timeline entries:
|
||||
- Use passive or system-focused language — avoid "X made a mistake"
|
||||
- Include: first symptom, detection, escalation, hypothesis tested, fix applied, confirmation of resolution
|
||||
- Note time between key events (e.g. "22 minutes between detection and escalation")
|
||||
|
||||
---
|
||||
|
||||
## Root Cause
|
||||
|
||||
**Primary root cause:** [One clear sentence. Technical but plain. "A misconfigured deployment config caused..."]
|
||||
|
||||
**Contributing factors:**
|
||||
- [Factor 1 — e.g. lack of canary deployment meant change hit 100% of traffic immediately]
|
||||
- [Factor 2 — e.g. alert threshold was set too high to catch the initial degradation]
|
||||
- [Factor 3 — add as many as are relevant]
|
||||
|
||||
**Why did our existing safeguards not prevent this?**
|
||||
[Honest paragraph explaining why monitoring, tests, or processes didn't catch this earlier. This is where blameless analysis matters most — focus on system gaps, not individual failures.]
|
||||
|
||||
---
|
||||
|
||||
## Detection
|
||||
|
||||
- **How was it first detected?** [Customer report / automated alert / internal monitoring / manual observation]
|
||||
- **Time from incident start to detection:** [X minutes]
|
||||
- **Should we have detected this faster?** [Yes / No — and why]
|
||||
|
||||
---
|
||||
|
||||
## Resolution
|
||||
|
||||
**What fixed it?** [Clear description of the actual fix — one paragraph]
|
||||
**Why did this work?** [Brief technical explanation]
|
||||
**Was there a temporary mitigation before full resolution?** [Yes/No — describe if yes]
|
||||
|
||||
---
|
||||
|
||||
## Action Items
|
||||
|
||||
| # | Action | Owner | Due Date | Priority |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Specific, testable action] | [Team or person] | [Date] | P1/P2/P3 |
|
||||
|
||||
Rules for action items:
|
||||
- Each action must be specific enough to close as "done" or "not done" — no vague items like "improve monitoring"
|
||||
- Distinguish between: **Prevent recurrence** (fix the root cause), **Improve detection** (catch it faster next time), **Improve response** (resolve it faster next time)
|
||||
- Assign a real owner — not "team" or "TBD" if avoidable
|
||||
- Flag P1 actions as items that block the incident from being marked fully closed
|
||||
|
||||
---
|
||||
|
||||
## What Went Well
|
||||
|
||||
[3–5 honest observations about the response. Include: fast collaboration, good runbooks used, effective escalation, clear communication. This section builds team confidence and reinforces good habits.]
|
||||
|
||||
---
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
[3–5 key insights from this incident that are worth sharing beyond this team. Write these as transferable lessons — e.g. "Our runbook for database failover didn't account for read-replica lag. All runbooks involving database failover should be reviewed."]
|
||||
|
||||
---
|
||||
|
||||
## Communication Log
|
||||
|
||||
[Optional — list external communications sent: status page updates, customer emails, support responses. Include timestamps.]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Timeline has no blame-focused language
|
||||
- [ ] Root cause is specific (not "human error")
|
||||
- [ ] Contributing factors explain the systemic gaps
|
||||
- [ ] Every action item has an owner and due date
|
||||
- [ ] "What went well" section is genuine, not token
|
||||
- [ ] Executive summary is readable by non-technical leadership
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a postmortem for the [incident name] outage"
|
||||
- "Help me write a P1 incident report"
|
||||
- "Generate an RCA document for [service] going down on [date]"
|
||||
- "Draft a blameless postmortem from these notes: [paste notes]"
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
name: pr-description-writer
|
||||
description: "Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# PR Description Writer Skill
|
||||
|
||||
Writes structured, reviewer-friendly pull request descriptions from a diff, commit list, or informal notes. Covers the what, why, and how-to-review so reviewers can start immediately.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask for these if not provided:
|
||||
- **What changed** (paste a git diff, `git log --oneline`, or describe the changes in plain English)
|
||||
- **Why it was changed** (the problem being solved or feature being added)
|
||||
- **How to test it** (any specific steps a reviewer needs to verify it works)
|
||||
- **Risk level** (low / medium / high — affects how much reviewer guidance to include)
|
||||
- **PR type** (feature / bug fix / refactor / dependency upgrade / config change / hotfix)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Title
|
||||
A clear, imperative-mood title under 72 characters:
|
||||
`[type]: [concise description of what changed]`
|
||||
|
||||
Examples:
|
||||
- `feat: add rate limiting to the public API`
|
||||
- `fix: resolve race condition in session expiry`
|
||||
- `refactor: extract payment logic into PaymentService`
|
||||
|
||||
### Summary
|
||||
2–3 sentences covering:
|
||||
- What this PR does (the change)
|
||||
- Why it was needed (the problem or goal)
|
||||
- The approach taken (at a high level)
|
||||
|
||||
### Changes Made
|
||||
Bullet list of specific changes — one bullet per logical change, not per file:
|
||||
- Added [X] to handle [Y]
|
||||
- Refactored [A] to reduce [B]
|
||||
- Removed [C] as it was replaced by [D]
|
||||
- Updated [E] to fix [F]
|
||||
|
||||
### Screenshots / Demo
|
||||
[If UI change: include before/after screenshots or a screen recording]
|
||||
[If API change: include example request/response]
|
||||
[If no visual change: this section can be omitted]
|
||||
|
||||
### How to Test
|
||||
Step-by-step instructions a reviewer can follow:
|
||||
1. [Setup step if needed]
|
||||
2. [Action to take]
|
||||
3. [What to verify]
|
||||
4. [Edge case to check]
|
||||
|
||||
Include any specific commands, test data, or environment flags needed.
|
||||
|
||||
### Testing Checklist
|
||||
- [ ] Unit tests added/updated
|
||||
- [ ] Integration tests added/updated
|
||||
- [ ] Edge cases covered
|
||||
- [ ] Manual testing completed
|
||||
- [ ] No regressions in existing tests
|
||||
|
||||
### Reviewer Notes
|
||||
Flag anything that warrants extra attention:
|
||||
- Areas of uncertainty where a second opinion is welcome
|
||||
- Deliberate trade-offs made (and why)
|
||||
- Out-of-scope items noticed but not addressed
|
||||
- Dependencies on other PRs (link them)
|
||||
|
||||
### Related
|
||||
- Closes #[issue number] (if applicable)
|
||||
- Related to #[PR/issue number]
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Title is imperative mood and under 72 characters
|
||||
- [ ] Summary explains what AND why (not just what)
|
||||
- [ ] Changes list describes logical changes (not file-by-file changes)
|
||||
- [ ] Testing steps are reproducible by someone unfamiliar with the code
|
||||
- [ ] Risk-appropriate reviewer guidance is included
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a PR description for these changes" + [paste diff or description]
|
||||
- "Draft a pull request for [feature]"
|
||||
- "I need a PR description — here's what I changed"
|
||||
- "Summarise these commits into a PR description"
|
||||
- "Write the PR body for this branch"
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: runbook-writer
|
||||
description: "Write an operational runbook for a service, incident type, or deployment procedure. Use when asked to write a runbook, create an ops guide, document an operational procedure, or prepare an incident response playbook. Produces a runbook with overview, prerequisites, step-by-step procedures, rollback steps, troubleshooting table, and escalation paths. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Runbook Writer Skill
|
||||
|
||||
Produces operational runbooks for services, incident types, and deployment procedures — structured so an on-call engineer who's never touched the system can follow them under pressure.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask for these if not provided:
|
||||
- **What the runbook is for** (e.g. deploying the payment service, responding to a database failover, rotating API keys)
|
||||
- **Runbook type** (Deployment / Incident Response / Maintenance / Disaster Recovery)
|
||||
- **System/service name and what it does** (brief description)
|
||||
- **Audience** (new on-call engineers / experienced SREs / DevOps team)
|
||||
- **Tech stack** (where relevant — e.g. Kubernetes, AWS RDS, Node.js)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
**Runbook:** [Runbook Title]
|
||||
**Service:** [Service Name]
|
||||
**Type:** [Deployment / Incident Response / Maintenance / DR]
|
||||
**Last Updated:** [Date]
|
||||
**Owner:** [Team or person]
|
||||
**Severity:** [P1 / P2 / P3 — if incident-type]
|
||||
|
||||
---
|
||||
|
||||
### Overview
|
||||
**What this runbook covers:**
|
||||
[1–2 sentences on the scenario this runbook handles]
|
||||
|
||||
**When to use this runbook:**
|
||||
- [Specific trigger condition 1 — e.g. PagerDuty alert: `high-error-rate-payment-service`]
|
||||
- [Specific trigger condition 2 — e.g. Deploy needed after PR merged to `main`]
|
||||
|
||||
**Estimated time to complete:** [X minutes / X–Y minutes depending on outcome]
|
||||
|
||||
**Impact if not completed correctly:** [e.g. Payment processing degraded / Data loss risk / Users locked out]
|
||||
|
||||
---
|
||||
|
||||
### Prerequisites
|
||||
|
||||
**Access required:**
|
||||
- [ ] [System/tool access — e.g. AWS Console: `production-account`]
|
||||
- [ ] [Credential — e.g. `vault read secret/payment-service`]
|
||||
- [ ] [VPN / bastion access if needed]
|
||||
|
||||
**Tools required:**
|
||||
- [ ] [Tool name and version — e.g. `kubectl` v1.28+]
|
||||
- [ ] [CLI or dashboard name]
|
||||
|
||||
**Before you start:**
|
||||
- [ ] [Prerequisite check — e.g. Verify current deployment is healthy in Grafana]
|
||||
- [ ] [Prerequisite action — e.g. Announce in `#ops-live` that you're starting]
|
||||
|
||||
---
|
||||
|
||||
### Procedure
|
||||
|
||||
Number every step. Use exact commands. Do not paraphrase tool names or flags.
|
||||
|
||||
**Step 1: [Action name]**
|
||||
[What you're doing and why — one sentence]
|
||||
```bash
|
||||
# Exact command
|
||||
[command here]
|
||||
```
|
||||
**Expected output:** `[what should appear if this worked]`
|
||||
**If this fails:** [Exact error message to look for] → [What to do, or see Troubleshooting]
|
||||
|
||||
**Step 2: [Action name]**
|
||||
[Same structure as Step 1]
|
||||
|
||||
**Step 3: Verify**
|
||||
Always include a verification step after the main procedure:
|
||||
```bash
|
||||
[verification command]
|
||||
```
|
||||
**Expected state:** [What a healthy system looks like after this runbook completes]
|
||||
|
||||
---
|
||||
|
||||
### Rollback
|
||||
|
||||
How to undo this procedure if something went wrong:
|
||||
|
||||
**Step R1: [Rollback action]**
|
||||
```bash
|
||||
[rollback command]
|
||||
```
|
||||
**Verify rollback:** `[command to confirm rollback succeeded]`
|
||||
|
||||
---
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
| Symptom | Likely Cause | Resolution |
|
||||
|---|---|---|
|
||||
| [Error message or observable symptom] | [Why this happens] | [Exact fix or next step] |
|
||||
| [Another symptom] | [Cause] | [Resolution] |
|
||||
|
||||
---
|
||||
|
||||
### Escalation
|
||||
|
||||
If this runbook does not resolve the issue:
|
||||
|
||||
| Condition | Who to Contact | How |
|
||||
|---|---|---|
|
||||
| [e.g. DB unavailable after 10 min] | [DBA on-call] | [PagerDuty policy: `db-oncall`] |
|
||||
| [e.g. Payment provider unresponsive] | [Vendor contact] | [Contact in 1Password: `vendor-escalation`] |
|
||||
|
||||
**Always update the incident timeline in [tool] before escalating.**
|
||||
|
||||
---
|
||||
|
||||
### Post-Procedure Checklist
|
||||
|
||||
After completing the runbook:
|
||||
- [ ] Announce completion in `#ops-live` with outcome
|
||||
- [ ] Update the incident ticket / deploy log
|
||||
- [ ] Verify alerts have resolved in monitoring dashboard
|
||||
- [ ] If this revealed a gap in this runbook — update it now (link to edit process)
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Every step has an exact command (no "run the deploy script")
|
||||
- [ ] Expected output is specified for each step so engineer knows if it worked
|
||||
- [ ] Failure path is explicit for each step (not "if it fails, investigate")
|
||||
- [ ] Rollback procedure is complete and independently testable
|
||||
- [ ] Escalation paths name specific contacts, not just team names
|
||||
- [ ] Runbook can be followed by someone who has never touched this system
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a runbook for [service] deployment"
|
||||
- "Create an incident response runbook for [alert type]"
|
||||
- "I need a runbook for [procedure]"
|
||||
- "Document the operational procedure for [X]"
|
||||
- "Write an ops playbook for [scenario]"
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
name: system-design-interview
|
||||
description: "Structure a complete system design answer for interview questions or real architecture sessions. Use when asked to design a system, answer a system design interview question, or architect a solution at scale. Produces a structured answer covering requirements, capacity estimates, high-level design, component deep-dives, trade-offs, and follow-up considerations. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# System Design Interview Skill
|
||||
|
||||
Structures a complete, interview-grade system design response — covering clarifying questions, requirements, capacity estimates, architecture, component design, and trade-offs. Works equally well for real architecture sessions.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask for these if not provided:
|
||||
- **The system to design** (e.g. "design a URL shortener", "design a notification service", "design Twitter's feed")
|
||||
- **Scope** (interview prep / real architecture decision / practice run)
|
||||
- **Scale target** (rough numbers: DAU, requests/sec, data volume — or "assume typical web scale")
|
||||
- **Constraints or priorities** (e.g. prioritise availability over consistency, minimise cost, low-latency reads)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Clarifying Questions
|
||||
Before designing, list 4–6 questions that would change the design. Examples:
|
||||
- Read-heavy or write-heavy? (affects caching and DB choice)
|
||||
- Global or single-region? (affects latency requirements)
|
||||
- Strong or eventual consistency? (affects storage and replication)
|
||||
- Acceptable latency targets? (p50 / p99)
|
||||
- Any existing infrastructure constraints?
|
||||
|
||||
Then proceed with stated assumptions if answering an interview question.
|
||||
|
||||
### 2. Functional Requirements
|
||||
**Core features (must have):**
|
||||
- [Feature 1]
|
||||
- [Feature 2]
|
||||
- [Feature 3]
|
||||
|
||||
**Out of scope (for this design):**
|
||||
- [What's deliberately excluded and why]
|
||||
|
||||
### 3. Non-Functional Requirements
|
||||
| Requirement | Target |
|
||||
|---|---|
|
||||
| Availability | [e.g. 99.9% / 99.99%] |
|
||||
| Latency | [e.g. p95 < 100ms for reads] |
|
||||
| Throughput | [e.g. 10k writes/sec peak] |
|
||||
| Consistency | [Strong / Eventual] |
|
||||
| Durability | [e.g. 99.999% — no data loss] |
|
||||
|
||||
### 4. Capacity Estimation
|
||||
**Traffic:**
|
||||
- DAU: [X]
|
||||
- Reads/sec: [X] (peak: [X])
|
||||
- Writes/sec: [X] (peak: [X])
|
||||
|
||||
**Storage:**
|
||||
- Per record size: [X bytes]
|
||||
- Records per day: [X]
|
||||
- 5-year storage: [X GB/TB]
|
||||
|
||||
**Bandwidth:**
|
||||
- Inbound: [X MB/s]
|
||||
- Outbound: [X MB/s]
|
||||
|
||||
### 5. High-Level Architecture
|
||||
|
||||
```
|
||||
[Client] → [CDN/Edge] → [Load Balancer] → [API Servers] → [Cache] → [DB]
|
||||
→ [Message Queue] → [Workers]
|
||||
```
|
||||
|
||||
Describe each layer in 1–2 sentences explaining its role and technology choice.
|
||||
|
||||
### 6. Component Deep-Dive
|
||||
|
||||
Pick the 2–3 most critical/interesting components and go deep:
|
||||
|
||||
**[Component 1: e.g. Database Layer]**
|
||||
- Choice: [Technology and why — e.g. PostgreSQL for ACID guarantees, Cassandra for write throughput]
|
||||
- Schema design (high-level): [Key tables/collections and their structure]
|
||||
- Indexing strategy: [What gets indexed and why]
|
||||
- Replication: [Primary-replica / Multi-primary — and why]
|
||||
|
||||
**[Component 2: e.g. Caching Strategy]**
|
||||
- Cache type: [Redis / Memcached — and why]
|
||||
- What gets cached: [Hot data — e.g. user sessions, frequent reads]
|
||||
- Cache invalidation: [TTL / Write-through / Write-behind — trade-offs]
|
||||
- Cache hit rate target: [e.g. 95%]
|
||||
|
||||
**[Component 3: e.g. API Design]**
|
||||
- Key endpoints: [List the 3–5 most important API calls]
|
||||
- Authentication: [JWT / OAuth / API keys]
|
||||
- Rate limiting: [Where and at what rate]
|
||||
|
||||
### 7. Data Flow
|
||||
Walk through the two most critical paths end-to-end:
|
||||
|
||||
**Write path:** [Step 1 → Step 2 → Step 3...]
|
||||
**Read path:** [Step 1 → Step 2 → Step 3...]
|
||||
|
||||
### 8. Scaling Bottlenecks and Mitigations
|
||||
| Bottleneck | Mitigation |
|
||||
|---|---|
|
||||
| [e.g. DB write throughput] | [e.g. sharding by user_id, write batching] |
|
||||
| [e.g. Hot-key cache misses] | [e.g. local in-process cache, probabilistic early expiry] |
|
||||
| [e.g. Single region latency] | [e.g. multi-region deployment, GeoDNS routing] |
|
||||
|
||||
### 9. Trade-offs and Alternatives
|
||||
Be explicit about what was chosen and what was sacrificed:
|
||||
|
||||
| Decision | Why | Trade-off |
|
||||
|---|---|---|
|
||||
| [e.g. Eventual consistency] | [Higher availability, lower latency] | [Stale reads possible] |
|
||||
| [e.g. SQL over NoSQL] | [Complex queries, ACID transactions] | [Harder to shard horizontally] |
|
||||
| [e.g. Async processing via queue] | [Decoupled, more resilient] | [Eventual delivery, harder to debug] |
|
||||
|
||||
### 10. Follow-up Considerations
|
||||
Things to tackle in production but out of scope for this design session:
|
||||
- Monitoring and alerting (what metrics matter)
|
||||
- Disaster recovery and backup strategy
|
||||
- Security (auth, encryption at rest/transit, rate limiting)
|
||||
- Cost optimisation at scale
|
||||
- Gradual rollout and feature flagging
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Clarifying questions are design-changing (not generic filler)
|
||||
- [ ] Capacity estimates use real numbers (not just "it scales")
|
||||
- [ ] At least 2 component deep-dives with technology choices justified
|
||||
- [ ] Trade-offs section is honest (not just benefits of chosen approach)
|
||||
- [ ] Data flow is described end-to-end for the critical path
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Help me answer a system design interview: [question]"
|
||||
- "Design [system] for a system design interview"
|
||||
- "How would I architect [system] at scale?"
|
||||
- "I have a system design interview — the question is [X]"
|
||||
- "Design a [URL shortener / chat system / notification service / feed]"
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
name: test-strategy-doc
|
||||
description: "Write a test strategy document from a feature spec, PRD, or system description. Use when asked to create a test plan, write a test strategy, define QA approach, or plan testing for a feature or release. Produces a complete test strategy with scope, risk assessment, test types, coverage targets, and a prioritised test case outline. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Test Strategy Document Skill
|
||||
|
||||
Produces a complete test strategy from a feature spec, PRD, or system description — covering scope, test types, risk areas, coverage requirements, and a prioritised test case outline.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask for these if not provided:
|
||||
- **Feature or system being tested** (paste a spec, PRD, or describe it in plain English)
|
||||
- **Tech stack** (language, framework, testing tools already in use if known)
|
||||
- **Risk level** (low / medium / high / critical — affects depth and coverage requirements)
|
||||
- **Timeline** (when does this need to ship — affects prioritisation)
|
||||
- **Team context** (who is doing the testing — developers / dedicated QA / both)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Test Scope
|
||||
|
||||
**In scope:**
|
||||
- [Specific functionality being tested]
|
||||
- [Integration points covered]
|
||||
- [User-facing flows included]
|
||||
|
||||
**Out of scope:**
|
||||
- [What is deliberately not tested here — and why]
|
||||
- [Dependencies owned by other teams]
|
||||
|
||||
**Assumptions:**
|
||||
- [What the test strategy assumes is true — e.g. mocked services, test data availability]
|
||||
|
||||
### 2. Risk Assessment
|
||||
|
||||
Identify the highest-risk areas first — these drive depth and coverage:
|
||||
|
||||
| Area | Risk Level | Why | Test Priority |
|
||||
|---|---|---|---|
|
||||
| [e.g. Payment processing] | High | Money movement, regulatory | P0 — exhaustive |
|
||||
| [e.g. User authentication] | High | Security boundary | P0 — exhaustive |
|
||||
| [e.g. Email notifications] | Medium | External dependency | P1 — happy path + key failures |
|
||||
| [e.g. UI copy changes] | Low | Visual only, reversible | P2 — smoke only |
|
||||
|
||||
### 3. Test Types and Coverage
|
||||
|
||||
**Unit Tests**
|
||||
- **What:** Individual functions and methods in isolation
|
||||
- **Who writes:** Developer
|
||||
- **Coverage target:** [e.g. 80% line coverage on new code / 100% on critical paths]
|
||||
- **Tools:** [e.g. Jest, pytest, go test]
|
||||
- **Focus areas for this feature:** [Specific logic that needs unit coverage]
|
||||
|
||||
**Integration Tests**
|
||||
- **What:** Service interactions, database operations, API contracts
|
||||
- **Who writes:** Developer / QA
|
||||
- **Coverage target:** [All happy paths + key failure modes]
|
||||
- **Tools:** [e.g. Supertest, pytest + testcontainers]
|
||||
- **Focus areas:** [Specific integrations at risk — e.g. third-party API, DB schema changes]
|
||||
|
||||
**End-to-End Tests**
|
||||
- **What:** Critical user journeys from browser/client to database
|
||||
- **Who writes:** QA / Developer
|
||||
- **Coverage target:** [Top N user journeys — list them]
|
||||
- **Tools:** [e.g. Playwright, Cypress, Selenium]
|
||||
- **Focus areas:** [The 3–5 most critical user flows]
|
||||
|
||||
**Performance Tests** *(include only if risk is medium+)*
|
||||
- **What:** Load, stress, or latency testing
|
||||
- **Targets:** [Specific numbers — e.g. 200 req/sec at p95 < 200ms]
|
||||
- **Tools:** [e.g. k6, Locust, JMeter]
|
||||
|
||||
**Security Tests** *(include only if risk is high+)*
|
||||
- **What:** OWASP Top 10 checks relevant to this feature
|
||||
- **Focus:** [Auth bypasses, injection, data exposure]
|
||||
- **Tools:** [e.g. OWASP ZAP, manual penetration testing, Snyk]
|
||||
|
||||
### 4. Test Case Outline
|
||||
|
||||
Priority-ordered list of specific test cases:
|
||||
|
||||
**P0 — Must pass before merge:**
|
||||
| Test Case | Type | Expected Outcome |
|
||||
|---|---|---|
|
||||
| [e.g. User can log in with valid credentials] | E2E | [Redirect to dashboard, session created] |
|
||||
| [e.g. Invalid login returns 401] | Integration | [Error message displayed, no session] |
|
||||
| [e.g. Password is never stored in plain text] | Unit | [bcrypt hash in DB] |
|
||||
|
||||
**P1 — Must pass before release:**
|
||||
| Test Case | Type | Expected Outcome |
|
||||
|---|---|---|
|
||||
| [e.g. Login fails gracefully when DB is down] | Integration | [User sees friendly error, 503] |
|
||||
| [e.g. Rate limiting blocks after 5 failed attempts] | Integration | [429 returned, account flagged] |
|
||||
|
||||
**P2 — Should pass, can ship with known issues tracked:**
|
||||
| Test Case | Type | Expected Outcome |
|
||||
|---|---|---|
|
||||
| [e.g. Login page renders correctly on mobile] | E2E | [Layout matches design] |
|
||||
|
||||
### 5. Test Data Requirements
|
||||
- [Specific test data needed — e.g. test user accounts with various states]
|
||||
- [External service stubs or mocks needed]
|
||||
- [Database seed data requirements]
|
||||
- [Any PII concerns and how test data handles them]
|
||||
|
||||
### 6. Definition of Done
|
||||
Testing is complete when:
|
||||
- [ ] All P0 test cases pass
|
||||
- [ ] All P1 test cases pass
|
||||
- [ ] Code coverage meets the stated target
|
||||
- [ ] No critical or high severity bugs open
|
||||
- [ ] Performance targets met (if applicable)
|
||||
- [ ] Security checks completed (if applicable)
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Risk table is populated and drives test priority (not filled in generically)
|
||||
- [ ] P0 test cases cover the highest-risk paths specifically
|
||||
- [ ] Each test type names a concrete tool (not "some testing framework")
|
||||
- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a test strategy for [feature]" + [paste spec or PRD]
|
||||
- "Create a test plan for [system]"
|
||||
- "How should we test [feature]?"
|
||||
- "I need a QA plan for this sprint"
|
||||
- "What tests do we need for [X]?"
|
||||
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/plugin.schema.json",
|
||||
"name": "pm-essentials",
|
||||
"version": "3.0.0",
|
||||
"description": "Core PM skills: PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, and Competitive Analysis. The 5 skills every PM needs first.",
|
||||
"author": {
|
||||
"name": "Mohit Aggarwal",
|
||||
"email": "mohit15856@gmail.com"
|
||||
},
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills",
|
||||
"license": "MIT",
|
||||
"keywords": ["product-management", "prd", "meeting-notes", "stakeholder", "user-research", "competitive-analysis"]
|
||||
}
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
name: competitive-analysis
|
||||
description: "Analyze competitors and create competitive landscape documentation with feature matrices, positioning maps, and strategic recommendations. Use when asked to analyze competitors, create competitive analysis, compare features with competitors, build a competitive landscape, track competitive positioning, or prepare sales battlecard inputs. Produces structured competitor profiles, feature comparison matrix, win/loss analysis, and prioritised strategic recommendations."
|
||||
---
|
||||
|
||||
# Competitive Analysis Skill
|
||||
|
||||
Create structured competitive analyses for product decision-making.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Your product or company** (what you're comparing against)
|
||||
- **Competitors to analyze** (or ask to identify the top 3-5)
|
||||
- **Analysis focus** (full landscape / feature comparison / pricing / positioning / win-loss)
|
||||
- **Audience** (product team / leadership / sales / board)
|
||||
|
||||
## Process
|
||||
|
||||
1. Gather competitor information from provided inputs and available context
|
||||
2. Build profiles for each competitor
|
||||
3. Create feature comparison matrix on dimensions that matter to the user's customers
|
||||
4. Analyze pricing and positioning
|
||||
5. Identify win/loss patterns and strategic implications
|
||||
6. **Validate** — Confirm all claims reference a specific source or are flagged as assumptions. Verify feature comparisons note quality differences, not just presence/absence.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Executive Summary
|
||||
- **Market Position**: Where we stand relative to competitors
|
||||
- **Key Findings**: Top 3-5 insights
|
||||
- **Strategic Implications**: What this means for the roadmap
|
||||
|
||||
### 2. Competitor Profiles
|
||||
|
||||
For each competitor:
|
||||
- **Company Overview**: Size, funding, market position
|
||||
- **Target Customer**: Who they serve
|
||||
- **Value Proposition**: Core positioning
|
||||
- **Strengths / Weaknesses**: What they do well and where they fall short
|
||||
- **Recent Activity**: Major updates, funding, announcements
|
||||
|
||||
### 3. Feature Comparison Matrix
|
||||
|
||||
| Feature | Us | Competitor A | Competitor B | Competitor C |
|
||||
|---------|-----|--------------|--------------|--------------|
|
||||
| [Feature] | ✅ Full | ⚠️ Limited | ❌ None | ✅ Full |
|
||||
|
||||
Legend: ✅ Full (production-ready) · ⚠️ Limited/Beta · ❌ None
|
||||
|
||||
Include notes on quality and implementation differences where significant.
|
||||
|
||||
### 4. Pricing Comparison
|
||||
|
||||
| Plan | Us | Competitor A | Competitor B |
|
||||
|------|-----|--------------|--------------|
|
||||
| Free/Trial | [price] | [price] | [price] |
|
||||
| Pro | [price] | [price] | [price] |
|
||||
| Enterprise | [price] | [price] | [price] |
|
||||
|
||||
### 5. Market Positioning Map
|
||||
|
||||
Position competitors on two key dimensions relevant to the market:
|
||||
- Y-Axis: [e.g., Enterprise vs. SMB]
|
||||
- X-Axis: [e.g., Simple vs. Comprehensive]
|
||||
|
||||
**Whitespace Opportunities**: [Underserved segments]
|
||||
|
||||
### 6. Win/Loss Analysis
|
||||
|
||||
**Why We Win:**
|
||||
- Better at: [specific capabilities]
|
||||
- Customers who value: [what matters to them]
|
||||
|
||||
**Why We Lose:**
|
||||
- When customers need: [specific requirements]
|
||||
- Their advantage: [what tips the decision]
|
||||
|
||||
### 7. Strategic Recommendations
|
||||
|
||||
**Immediate Actions (0-3 months):**
|
||||
1. [Action] — [Rationale]
|
||||
|
||||
**Medium-term (3-12 months):**
|
||||
1. [Action] — [Rationale]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] All competitor claims cite a source or are flagged as assumptions
|
||||
- [ ] Feature comparison notes quality differences, not just feature presence
|
||||
- [ ] Strategic recommendations are specific actions, not generic advice
|
||||
- [ ] Win/loss analysis reflects customer perspective, not internal assumptions
|
||||
- [ ] Different customer segments are considered (not all buyers value the same things)
|
||||
@@ -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,268 @@
|
||||
---
|
||||
name: meeting-notes
|
||||
description: "Structure and format meeting notes following PM best practices. Use when asked to create meeting notes, format discussion notes, capture action items, or document decisions from any meeting type. Produces structured notes with decisions, action items (owner + deadline), open questions, and next steps."
|
||||
---
|
||||
|
||||
# Meeting Notes Skill
|
||||
|
||||
This skill structures meeting notes to maximize value and ensure follow-through.
|
||||
|
||||
## Standard Meeting Notes Template
|
||||
|
||||
### Meeting Header
|
||||
**Meeting**: [Meeting Title]
|
||||
**Date**: [Date]
|
||||
**Attendees**: [Names/Roles]
|
||||
**Note Taker**: [Name]
|
||||
**Duration**: [Actual duration]
|
||||
|
||||
### Agenda
|
||||
- [ ] Topic 1
|
||||
- [ ] Topic 2
|
||||
- [ ] Topic 3
|
||||
|
||||
*(Check off items as discussed)*
|
||||
|
||||
### Decisions Made
|
||||
Clear documentation of decisions:
|
||||
|
||||
**Decision**: [What was decided]
|
||||
**Context**: [Why this decision]
|
||||
**Owner**: [Who's responsible for executing]
|
||||
**Deadline**: [When if applicable]
|
||||
|
||||
Use this format for each decision made.
|
||||
|
||||
### Action Items
|
||||
All action items should be:
|
||||
- [ ] **[Action item]** - @Owner - Due: [Date]
|
||||
- [ ] **[Action item]** - @Owner - Due: [Date]
|
||||
|
||||
Format:
|
||||
- Clear, specific action
|
||||
- Single owner (no "team" ownership)
|
||||
- Concrete deadline
|
||||
- Checkbox for tracking
|
||||
|
||||
### Discussion Notes
|
||||
Key points discussed organized by topic:
|
||||
|
||||
**Topic 1: [Name]**
|
||||
- Key point or discussion highlight
|
||||
- Important context or concern raised
|
||||
- Any data or information shared
|
||||
|
||||
**Topic 2: [Name]**
|
||||
- Key discussion points
|
||||
- Decisions or conclusions reached
|
||||
|
||||
### Open Questions / Follow-Up
|
||||
Questions that couldn't be answered:
|
||||
- **Question**: [What we need to know]
|
||||
- **Owner**: [Who will find out]
|
||||
- **By When**: [Deadline]
|
||||
|
||||
### Next Steps
|
||||
Clear summary of what happens next:
|
||||
1. [Immediate next action]
|
||||
2. [Follow-up meeting if needed]
|
||||
3. [Any broader process to start]
|
||||
|
||||
## Best Practices
|
||||
|
||||
**During the meeting:**
|
||||
- Focus on decisions and action items over dialogue
|
||||
- Capture specific commitments, not general discussion
|
||||
- Note dissenting opinions on important decisions
|
||||
- Ask for clarity on vague commitments ("I'll look into it" → "I'll analyze the data and share findings by Friday")
|
||||
|
||||
**After the meeting:**
|
||||
- Send notes within 2 hours while fresh
|
||||
- Tag action item owners (@mention them)
|
||||
- Include links to relevant documents
|
||||
- Follow up on overdue action items
|
||||
|
||||
**What to capture:**
|
||||
✅ Decisions made
|
||||
✅ Action items with owners and deadlines
|
||||
✅ Key points of discussion
|
||||
✅ Open questions
|
||||
✅ Next steps
|
||||
|
||||
**What to skip:**
|
||||
❌ Verbatim transcripts
|
||||
❌ Off-topic tangents
|
||||
❌ Preliminary discussion before decisions
|
||||
❌ Redundant information
|
||||
|
||||
## Meeting Types & Adaptations
|
||||
|
||||
### 1:1 Meetings
|
||||
Focus on:
|
||||
- Career development discussions
|
||||
- Feedback (both directions)
|
||||
- Current challenges
|
||||
- Action items for both parties
|
||||
|
||||
Template additions:
|
||||
- **Recent Wins**: What's going well
|
||||
- **Challenges**: What's not going well
|
||||
- **Career Discussion**: Development topics
|
||||
- **Feedback**: For both parties
|
||||
|
||||
### Sprint Planning
|
||||
Focus on:
|
||||
- Story acceptance criteria
|
||||
- Sizing/estimation decisions
|
||||
- Dependency identification
|
||||
- Sprint commitment
|
||||
|
||||
Template additions:
|
||||
- **Sprint Goal**: What we're committing to
|
||||
- **Story Points**: Capacity and estimates
|
||||
- **Dependencies**: External blockers
|
||||
- **Definition of Done**: Acceptance criteria
|
||||
|
||||
### Product Reviews
|
||||
Focus on:
|
||||
- Design decisions
|
||||
- User feedback discussed
|
||||
- Changes requested
|
||||
- Launch readiness assessment
|
||||
|
||||
Template additions:
|
||||
- **Design Decisions**: What was approved/rejected
|
||||
- **User Feedback**: Key insights discussed
|
||||
- **Open Design Questions**: What needs iteration
|
||||
- **Launch Criteria**: Remaining requirements
|
||||
|
||||
### Stakeholder Sync
|
||||
Focus on:
|
||||
- Status updates delivered
|
||||
- Concerns raised
|
||||
- Approvals given
|
||||
- Escalation needs
|
||||
|
||||
Template additions:
|
||||
- **Status Overview**: High-level progress
|
||||
- **Approvals Obtained**: Sign-offs received
|
||||
- **Escalations**: Issues raised to stakeholders
|
||||
- **Next Sync**: When and what to cover
|
||||
|
||||
## Example Meeting Notes
|
||||
|
||||
```
|
||||
# Product Roadmap Review - Q1 2026
|
||||
**Date**: January 20, 2026
|
||||
**Attendees**: Sarah (CPO), Mike (Eng Lead), Jennifer (Design), Tom (PM)
|
||||
**Note Taker**: Tom
|
||||
**Duration**: 45 minutes
|
||||
|
||||
## Agenda
|
||||
- [x] Review Q1 planned features
|
||||
- [x] Discuss resource constraints
|
||||
- [x] Prioritization discussion
|
||||
- [x] Timeline alignment
|
||||
|
||||
## Decisions Made
|
||||
|
||||
**Decision**: Move multi-channel dashboard to Q2, prioritize mobile app improvements for Q1
|
||||
**Context**: Customer feedback shows mobile experience is significantly impacting retention (65% of users primarily mobile). Engineering team can only tackle one major initiative this quarter.
|
||||
**Owner**: Tom (PM) to communicate to stakeholders
|
||||
**Deadline**: January 22
|
||||
|
||||
**Decision**: Allocate 20% of engineering time to technical debt
|
||||
**Context**: Accumulated tech debt is slowing feature development. Team velocity dropped 30% last quarter.
|
||||
**Owner**: Mike (Eng Lead) to create tech debt backlog
|
||||
**Deadline**: January 27
|
||||
|
||||
**Decision**: Run mobile beta with 100 users before full launch
|
||||
**Context**: Need to validate improvements on diverse devices
|
||||
**Owner**: Jennifer (Design) to coordinate with QA
|
||||
**Deadline**: February 10
|
||||
|
||||
## Action Items
|
||||
- [ ] **Update Q1 roadmap deck with new prioritization** - @Tom - Due: Jan 22
|
||||
- [ ] **Schedule alignment meeting with support team about dashboard delay** - @Tom - Due: Jan 24
|
||||
- [ ] **Create tech debt prioritization rubric** - @Mike - Due: Jan 27
|
||||
- [ ] **Run user testing on mobile designs** - @Jennifer - Due: Feb 3
|
||||
- [ ] **Document decision rationale for executives** - @Sarah - Due: Jan 23
|
||||
- [ ] **Identify 100 beta users for mobile** - @Tom - Due: Feb 1
|
||||
|
||||
## Discussion Notes
|
||||
|
||||
**Q1 Feature Prioritization**
|
||||
- Customer retention is #1 company priority this quarter
|
||||
- Mobile app NPS score is 6.2 (vs 8.1 for web)
|
||||
- Mobile accounts for 65% of daily active users
|
||||
- Multi-channel dashboard would take 8 engineering weeks
|
||||
- Mobile improvements estimated at 6 engineering weeks with higher ROI
|
||||
- Sales has 3 enterprise deals waiting on dashboard feature
|
||||
|
||||
**Resource Constraints**
|
||||
- Currently 4 engineers available (down from 6 last quarter due to attrition)
|
||||
- Design team can support both initiatives but at reduced capacity
|
||||
- QA team needs 2 weeks for thorough testing on mobile
|
||||
- One engineer on loan to security team through February
|
||||
|
||||
**Risk Discussion**
|
||||
- Delaying dashboard may impact enterprise sales (3 deals waiting)
|
||||
- Sarah noted: "We can position mobile improvements as foundation for enterprise features"
|
||||
- Mike raised concern about mobile tech stack stability - addressed through tech debt allocation
|
||||
- Need to communicate clearly with Sales about timeline change
|
||||
|
||||
**Mobile Implementation Plan**
|
||||
- Week 1-2: Design refinements based on user feedback
|
||||
- Week 3-4: Engineering implementation
|
||||
- Week 5: Internal testing
|
||||
- Week 6: Beta with 100 users
|
||||
- Week 7: Full rollout
|
||||
|
||||
## Open Questions
|
||||
- **Question**: What's the impact on enterprise pipeline if we delay dashboard?
|
||||
**Owner**: Sarah will check with Sales leadership
|
||||
**By When**: January 23
|
||||
|
||||
- **Question**: Can we do a limited beta of dashboard for enterprise customers?
|
||||
**Owner**: Tom will explore MVP scope with Mike
|
||||
**By When**: January 25
|
||||
|
||||
- **Question**: What's our plan if mobile improvements don't hit target metrics?
|
||||
**Owner**: Tom will create contingency plan
|
||||
**By When**: January 27
|
||||
|
||||
## Next Steps
|
||||
1. Tom to send updated roadmap to leadership by EOD Wednesday (Jan 22)
|
||||
2. Team to begin sprint planning for mobile improvements next Monday (Jan 27)
|
||||
3. Follow-up meeting on Feb 1 to review progress and validate prioritization
|
||||
4. Sarah to present decision rationale to executive team on Jan 24
|
||||
|
||||
---
|
||||
|
||||
**Next Meeting**: February 1, 2026 - Progress Check-in
|
||||
**Notes Sent**: January 20, 2026 5:30 PM
|
||||
```
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every action item has a single named owner (not "team")
|
||||
- [ ] Every action item has a concrete deadline
|
||||
- [ ] Decisions include context (why the decision was made)
|
||||
- [ ] Open questions have an owner and a "by when"
|
||||
- [ ] No verbatim transcripts — synthesis only
|
||||
|
||||
## Notes Distribution
|
||||
|
||||
**Subject Line Format**: "[Meeting Type] Notes - [Date] - [Key Topic]"
|
||||
|
||||
Example: "Product Roadmap Review Notes - Jan 20 - Q1 Prioritization"
|
||||
|
||||
**Recipients**:
|
||||
- All attendees
|
||||
- Anyone mentioned in action items
|
||||
- Anyone who requested notes
|
||||
|
||||
**Follow-Up**:
|
||||
- Send reminder 3 days before action item due dates
|
||||
- Weekly summary of all open action items
|
||||
- Mark action items as complete and share updates
|
||||
@@ -0,0 +1,163 @@
|
||||
---
|
||||
name: prd-template
|
||||
description: "Create a Product Requirements Document following proven PM template structure. Use when asked to write a PRD, product spec, feature specification, or requirements document for a new feature or product. Produces a complete PRD with problem statement, user stories, functional requirements, technical considerations, and success metrics."
|
||||
---
|
||||
|
||||
# PRD Template Skill
|
||||
|
||||
This skill helps create professional Product Requirements Documents following industry best practices.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Feature or product name**
|
||||
- **Problem being solved** (from the user's perspective)
|
||||
- **Target user** (role, context, what they're trying to accomplish)
|
||||
- **Success metrics** (how will you know it worked?)
|
||||
- **Scope** (MVP vs full vision — what's in and out of scope)
|
||||
- **Key stakeholders** (who needs to review and approve)
|
||||
|
||||
## Template Structure
|
||||
|
||||
Every PRD should include these sections in order:
|
||||
|
||||
### 1. Overview
|
||||
- **Problem Statement**: What problem are we solving? (2-3 sentences)
|
||||
- **Proposed Solution**: High-level description of what we're building (2-3 sentences)
|
||||
- **Success Metrics**: How we'll measure success (3-5 key metrics)
|
||||
|
||||
### 2. Context & Background
|
||||
- **Why Now**: Why is this the right time?
|
||||
- **Strategic Alignment**: How does this align with company objectives?
|
||||
- **User Research Summary**: Key insights from research (if applicable)
|
||||
|
||||
### 3. User Stories & Use Cases
|
||||
Format: "As a [user type], I want to [action] so that [benefit]"
|
||||
- Include 3-7 primary user stories
|
||||
- Add acceptance criteria for each
|
||||
|
||||
### 4. Requirements
|
||||
**Functional Requirements:**
|
||||
- Must-have features (P0)
|
||||
- Should-have features (P1)
|
||||
- Nice-to-have features (P2)
|
||||
|
||||
**Non-Functional Requirements:**
|
||||
- Performance expectations
|
||||
- Security considerations
|
||||
- Accessibility requirements
|
||||
|
||||
### 5. Design & User Experience
|
||||
- Link to design mocks or wireframes
|
||||
- Key user flows
|
||||
- Edge cases and error states
|
||||
|
||||
### 6. Technical Considerations
|
||||
- Architecture implications
|
||||
- Dependencies on other systems
|
||||
- Technical risks and mitigations
|
||||
|
||||
### 7. Implementation Plan
|
||||
- **Phase 1 (MVP)**: What goes in first version
|
||||
- **Phase 2**: What comes next
|
||||
- **Phase 3**: Future enhancements
|
||||
|
||||
### 8. Open Questions
|
||||
- Decisions that still need to be made
|
||||
- Stakeholders to consult
|
||||
- Research needed
|
||||
|
||||
### 9. Appendix
|
||||
- Research links
|
||||
- Related documents
|
||||
- Competitive analysis
|
||||
|
||||
## Writing Guidelines
|
||||
|
||||
**Tone**: Clear, concise, actionable
|
||||
**Audience**: Engineers, designers, stakeholders
|
||||
**Length**: Aim for 3-6 pages for features, 8-12 for products
|
||||
|
||||
**Best Practices:**
|
||||
- Use concrete examples over abstractions
|
||||
- Include "why" not just "what"
|
||||
- Make requirements testable
|
||||
- Link to supporting materials
|
||||
- Update as decisions are made
|
||||
|
||||
## What Makes a Good PRD
|
||||
|
||||
✅ **Do:**
|
||||
- Write from the user's perspective
|
||||
- Include specific success metrics
|
||||
- Address edge cases
|
||||
- Link to research and data
|
||||
- Make trade-offs explicit
|
||||
|
||||
❌ **Don't:**
|
||||
- Write implementation details (that's tech spec)
|
||||
- Assume everyone has context
|
||||
- Leave requirements ambiguous
|
||||
- Skip the "why"
|
||||
- Forget about accessibility
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Problem statement is written from the user's perspective (not the company's)
|
||||
- [ ] Success metrics are specific and measurable
|
||||
- [ ] User stories include acceptance criteria
|
||||
- [ ] Requirements are testable (not vague)
|
||||
- [ ] Open questions are listed explicitly
|
||||
- [ ] Implementation plan distinguishes MVP from future phases
|
||||
|
||||
## Example PRD Opening
|
||||
|
||||
```
|
||||
# PRD: Multi-Channel Customer Support Dashboard
|
||||
|
||||
## Overview
|
||||
|
||||
**Problem Statement**: Support teams are currently managing customer inquiries across email, chat, and social media using three separate tools, leading to delayed responses, duplicated work, and inconsistent customer experiences. On average, support agents waste 2.3 hours per day switching between tools and manually tracking conversation history.
|
||||
|
||||
**Proposed Solution**: Build a unified dashboard that aggregates customer inquiries from all channels into a single interface, maintains conversation history across channels, and provides intelligent routing based on agent expertise and availability.
|
||||
|
||||
**Success Metrics**:
|
||||
- Reduce average response time from 4 hours to 1 hour
|
||||
- Decrease tool-switching time by 80% (from 2.3 to <0.5 hours)
|
||||
- Improve customer satisfaction score from 3.8 to 4.5 (out of 5)
|
||||
- Increase support agent productivity by 35%
|
||||
|
||||
## Context & Background
|
||||
|
||||
**Why Now**: Customer satisfaction has declined 15% over the past 6 months, primarily due to slow response times. Our top competitor launched a unified support dashboard last quarter, and we're hearing about it in sales calls. Support team turnover is at 45% annually, with "tool complexity" cited as a top frustration.
|
||||
|
||||
**Strategic Alignment**: This aligns with our Q1 company objective to "Improve customer retention by 10%" and our support team's OKR to "Reduce average handle time by 25%."
|
||||
|
||||
**User Research Summary**: We conducted interviews with 12 support agents and observed 20 hours of support sessions. Key findings:
|
||||
- Agents spend 35% of their time finding context from previous interactions
|
||||
- 65% of escalations are due to lack of conversation history
|
||||
- Agents rated tool-switching as their #1 daily frustration (9.2/10 pain)
|
||||
- Current NPS for support experience is -12
|
||||
|
||||
## User Stories & Use Cases
|
||||
|
||||
**US1: Unified Inbox**
|
||||
As a support agent, I want to see all customer inquiries in one place so that I don't miss urgent requests and can prioritize effectively.
|
||||
|
||||
Acceptance Criteria:
|
||||
- Inbox shows inquiries from email, chat, and social media
|
||||
- Inquiries are sorted by priority (urgent, high, normal, low)
|
||||
- Agent can filter by channel, customer, or status
|
||||
- Real-time updates when new inquiries arrive
|
||||
|
||||
**US2: Cross-Channel Context**
|
||||
As a support agent, I want to see the full conversation history regardless of channel so that I can provide consistent, informed responses without asking customers to repeat themselves.
|
||||
|
||||
Acceptance Criteria:
|
||||
- Timeline view shows all interactions chronologically
|
||||
- Each interaction displays channel, timestamp, and content
|
||||
- Customer profile shows demographics and account information
|
||||
- Previous issues and resolutions are accessible
|
||||
|
||||
[Continue with 5-7 total user stories...]
|
||||
```
|
||||
@@ -0,0 +1,236 @@
|
||||
---
|
||||
name: stakeholder-update
|
||||
description: "Create concise executive stakeholder updates using the BLUF (Bottom Line Up Front) framework. Use when asked to write a status update, progress report, project communication, or executive briefing for leadership or stakeholders. Produces a BLUF-led update with status, key metrics, risks, upcoming milestones, and decisions needed — readable in under 2 minutes."
|
||||
---
|
||||
|
||||
# Stakeholder Update Skill
|
||||
|
||||
This skill creates effective status updates for executives and stakeholders following the BLUF (Bottom Line Up Front) principle.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Project or product being reported on**
|
||||
- **Audience** (CEO, board, cross-functional leads, investors — changes depth and format)
|
||||
- **Period** (this week / this sprint / this month)
|
||||
- **Current status** (on track / at risk / blocked)
|
||||
- **Key metrics** and their current values vs. targets
|
||||
|
||||
## Update Structure
|
||||
|
||||
### 1. BLUF (Bottom Line Up Front)
|
||||
Start with the most important information:
|
||||
- **Status**: 🟢 On track / 🟡 At risk / 🔴 Blocked / ✅ Complete
|
||||
- **Key Takeaway**: One sentence summary of current state
|
||||
- **Action Needed**: What you need from stakeholders (if anything)
|
||||
|
||||
### 2. Progress Summary
|
||||
Brief overview of accomplishments:
|
||||
- What shipped this period
|
||||
- Milestones achieved
|
||||
- Key metrics movement
|
||||
|
||||
Keep to 3-5 bullet points maximum.
|
||||
|
||||
### 3. Metrics Dashboard
|
||||
|
||||
**Key Metrics**
|
||||
| Metric | Current | Target | Trend | Status |
|
||||
|--------|---------|--------|-------|--------|
|
||||
| [Metric name] | [Value] | [Target] | ↑/→/↓ | 🟢/🟡/🔴 |
|
||||
|
||||
Include 3-5 most important metrics only.
|
||||
|
||||
### 4. Risks & Blockers
|
||||
|
||||
**High Priority Issues:**
|
||||
- **Issue**: Brief description
|
||||
- **Impact**: What's at stake
|
||||
- **Mitigation**: What you're doing about it
|
||||
- **Help Needed**: What stakeholders can do (if applicable)
|
||||
|
||||
Only include issues that matter at executive level.
|
||||
|
||||
### 5. Upcoming Milestones
|
||||
|
||||
**Next 30 Days:**
|
||||
- Milestone (expected date)
|
||||
- Milestone (expected date)
|
||||
|
||||
**Next 90 Days:**
|
||||
- Major milestone (month)
|
||||
- Major milestone (month)
|
||||
|
||||
### 6. Decisions Needed (if applicable)
|
||||
- **Decision**: Clear description
|
||||
- **Options**: 2-3 options with pros/cons
|
||||
- **Recommendation**: What you recommend and why
|
||||
- **Timeline**: When decision is needed
|
||||
|
||||
## Writing Guidelines
|
||||
|
||||
**Tone**: Professional, concise, action-oriented
|
||||
**Length**: Keep under 1 page (or 2 minutes reading time)
|
||||
**Frequency**: Weekly for active projects, bi-weekly for maintenance
|
||||
|
||||
**Executive Communication Principles:**
|
||||
|
||||
1. **Lead with conclusions, not process**
|
||||
- ❌ "We ran 5 experiments this week and analyzed the data..."
|
||||
- ✅ "Conversion rate increased 15% from optimization work"
|
||||
|
||||
2. **Focus on impact, not activities**
|
||||
- ❌ "Held 12 customer interviews"
|
||||
- ✅ "Identified #1 barrier to adoption (complexity of setup)"
|
||||
|
||||
3. **Make problems visible early**
|
||||
- Don't sugarcoat risks
|
||||
- Propose solutions, not just problems
|
||||
- Be specific about help needed
|
||||
|
||||
4. **Use data to tell story**
|
||||
- Quantify whenever possible
|
||||
- Show trends, not just snapshots
|
||||
- Connect metrics to business outcomes
|
||||
|
||||
5. **Make it scannable**
|
||||
- Use headers and bullet points
|
||||
- Bold key information
|
||||
- Use visual indicators (🟢🟡🔴, ↑→↓)
|
||||
|
||||
## Status Guidelines
|
||||
|
||||
**🟢 On Track**: Meeting all targets, no significant risks
|
||||
**🟡 At Risk**: Potential issues that could impact delivery
|
||||
**🔴 Blocked**: Critical issues preventing progress, needs intervention
|
||||
|
||||
## Example Update
|
||||
|
||||
```
|
||||
# Product Update: Customer Onboarding Redesign
|
||||
**Week of Jan 20, 2026**
|
||||
|
||||
## BLUF
|
||||
**Status**: 🟡 At Risk
|
||||
**Key Takeaway**: New onboarding flow is performing well in tests (+35% completion), but launch delayed one week due to integration issues with billing system.
|
||||
**Action Needed**: Decision needed on whether to launch onboarding separately or wait for billing integration fix.
|
||||
|
||||
## Progress Summary
|
||||
- Completed user testing with 24 participants (94% positive feedback)
|
||||
- Implemented first-time user experience improvements
|
||||
- Resolved 12 of 15 bugs identified in QA
|
||||
- Engineering allocated resources to billing integration fix
|
||||
|
||||
## Key Metrics
|
||||
| Metric | Current | Target | Trend | Status |
|
||||
|--------|---------|--------|-------|--------|
|
||||
| Onboarding Completion | 45% | 60% | → | 🟡 |
|
||||
| Time to First Value | 4.2 min | 3.0 min | ↓ | 🟢 |
|
||||
| Setup Support Tickets | 45/week | <30/week | ↓ | 🟢 |
|
||||
| User Activation Rate | 52% | 65% | → | 🟡 |
|
||||
|
||||
## Risks & Blockers
|
||||
|
||||
**HIGH: Billing System Integration Delay**
|
||||
- **Impact**: Prevents users from completing onboarding flow; delays launch by 1-2 weeks
|
||||
- **Root Cause**: API deprecation by payment processor, requires code rewrite
|
||||
- **Mitigation**: Engineering team reallocated resources, fix ETA Feb 3
|
||||
- **Decision Needed**: Launch onboarding without payment integration or wait for fix? (See below)
|
||||
|
||||
**MEDIUM: Mobile Testing Coverage**
|
||||
- **Impact**: Some edge cases on older Android devices not tested
|
||||
- **Mitigation**: Partnering with QA to expand test matrix; running beta with internal users on diverse devices
|
||||
|
||||
## Upcoming Milestones
|
||||
|
||||
**Next 30 Days:**
|
||||
- Resolve billing integration (Feb 3)
|
||||
- Launch onboarding redesign (Feb 5 or Feb 12 depending on decision)
|
||||
- Begin measuring impact on conversion (Feb 12)
|
||||
|
||||
**Next 90 Days:**
|
||||
- Iterate based on production data (March)
|
||||
- Extend to mobile app (April)
|
||||
- Launch advanced features (May)
|
||||
|
||||
## Decision Needed
|
||||
|
||||
**Should we launch onboarding separately from billing integration?**
|
||||
|
||||
**Option A: Launch Now (Recommended)**
|
||||
- Pros: Get 35% completion rate improvement to users immediately, gather production data, maintain momentum
|
||||
- Cons: Users need to complete payment in old flow, slightly disjointed experience
|
||||
- Timeline: Launch Feb 5
|
||||
|
||||
**Option B: Wait for Billing Fix**
|
||||
- Pros: Fully integrated experience from day one, no technical debt
|
||||
- Cons: Delays benefits by 2 weeks, Q1 metric targets at risk, team momentum lost
|
||||
- Timeline: Launch Feb 12
|
||||
|
||||
**Recommendation**: Option A. The onboarding improvements are valuable independently, and the old payment flow works fine. Waiting risks missing Q1 targets and delays validated improvements from reaching users.
|
||||
|
||||
**Timeline**: Need decision by Jan 22 for Feb 5 launch.
|
||||
|
||||
---
|
||||
|
||||
**Questions?** Reply to this email or ping me on Slack.
|
||||
```
|
||||
|
||||
## Frequency Guidance
|
||||
|
||||
**Daily standups**:
|
||||
- Ultra-brief (3 bullets)
|
||||
- What shipped yesterday
|
||||
- What's shipping today
|
||||
- Blockers
|
||||
|
||||
**Weekly updates**:
|
||||
- Use full template above
|
||||
- Focus on progress and risks
|
||||
- Keep to 1 page
|
||||
|
||||
**Monthly reviews**:
|
||||
- Deeper metrics analysis
|
||||
- Strategic reflections
|
||||
- Quarterly goal progress
|
||||
- Longer format (2-3 pages) acceptable
|
||||
|
||||
**Quarterly business reviews**:
|
||||
- Comprehensive analysis
|
||||
- Trends over time
|
||||
- Strategic recommendations
|
||||
- Presentation format
|
||||
|
||||
## Adaptation by Audience
|
||||
|
||||
### For C-Suite
|
||||
- Lead with business impact
|
||||
- Connect to company OKRs
|
||||
- Focus on strategy and outcomes
|
||||
- Minimize technical details
|
||||
|
||||
### For Product/Engineering Leadership
|
||||
- Include technical context
|
||||
- Show sprint/milestone progress
|
||||
- Discuss architecture implications
|
||||
- Reference technical debt
|
||||
|
||||
### For Cross-Functional Teams
|
||||
- Balance technical and business context
|
||||
- Highlight dependencies
|
||||
- Call out collaboration needs
|
||||
- Make asks explicit
|
||||
|
||||
### For Board/Investors
|
||||
- Focus on metrics and traction
|
||||
- Competitive positioning
|
||||
- Market opportunities
|
||||
- Financial implications
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Update leads with BLUF — status, key takeaway, and action needed before any detail
|
||||
- [ ] Every metric has a target comparison (not just a raw number)
|
||||
- [ ] Every risk has a mitigation and a "help needed" flag if stakeholder action is required
|
||||
- [ ] Decisions needed have specific options and a clear recommendation
|
||||
- [ ] Total length is under 1 page / 2 minutes reading time
|
||||
@@ -0,0 +1,237 @@
|
||||
---
|
||||
name: user-research-synthesis
|
||||
description: "Analyze and synthesize user research findings into structured, actionable insights. Use when given user research data, interview transcripts, survey results, or user feedback that needs to be analyzed and summarised. Produces a themed synthesis with prevalence data, supporting quotes, pain points analysis, feature request prioritisation, and recommended next steps."
|
||||
---
|
||||
|
||||
# User Research Synthesis Skill
|
||||
|
||||
This skill helps analyze user research data and transform it into actionable insights following a structured methodology.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Research data** (transcripts, notes, survey results, or summary bullets)
|
||||
- **Research method** (interviews, surveys, usability tests, etc.)
|
||||
- **Number of participants** and their profiles (role, context)
|
||||
- **Research questions** the study aimed to answer
|
||||
|
||||
## Synthesis Framework
|
||||
|
||||
### 1. Data Collection Overview
|
||||
- **Research Type**: Interviews, surveys, usability tests, etc.
|
||||
- **Participant Profile**: Demographics, segments, sample size
|
||||
- **Research Questions**: What we sought to learn
|
||||
- **Methodology**: How data was collected
|
||||
|
||||
### 2. Key Themes Identification
|
||||
|
||||
Organize findings into themes using this structure:
|
||||
|
||||
**Theme Name**
|
||||
- **Description**: What this theme represents
|
||||
- **Prevalence**: How many participants mentioned this (e.g., "8 out of 12 participants")
|
||||
- **Supporting Quotes**: 2-3 representative quotes
|
||||
- **Implication**: What this means for our product
|
||||
|
||||
Aim for 4-8 major themes per research effort.
|
||||
|
||||
### 3. Pain Points Analysis
|
||||
|
||||
For each identified pain point:
|
||||
- **Pain Point**: Clear description
|
||||
- **Severity**: High/Medium/Low (based on impact and frequency)
|
||||
- **Current Workaround**: How users deal with it today
|
||||
- **Evidence**: Specific examples from research
|
||||
|
||||
### 4. Feature Requests
|
||||
|
||||
Categorize requests:
|
||||
- **Must-Have**: Critical needs blocking user success
|
||||
- **High Value**: Would significantly improve experience
|
||||
- **Nice-to-Have**: Incremental improvements
|
||||
|
||||
For each request:
|
||||
- **Request**: What users asked for
|
||||
- **Frequency**: How often it came up
|
||||
- **User Quote**: Representative example
|
||||
- **Underlying Need**: Why they want this (dig deeper than surface request)
|
||||
|
||||
### 5. User Workflow Insights
|
||||
|
||||
Document actual workflows observed:
|
||||
- **Current State**: How users accomplish tasks today
|
||||
- **Pain Points**: Where they struggle
|
||||
- **Ideal State**: What they wish they could do
|
||||
- **Opportunities**: Where we can add value
|
||||
|
||||
### 6. Segmentation Insights
|
||||
|
||||
If research reveals distinct user segments:
|
||||
- **Segment Name**: Descriptive label
|
||||
- **Characteristics**: What defines this segment
|
||||
- **Unique Needs**: How their needs differ
|
||||
- **Size/Importance**: Relative weight for prioritization
|
||||
|
||||
### 7. Competitive Insights
|
||||
|
||||
If users mentioned competitors or alternatives:
|
||||
- **Competitor/Alternative**: What they use
|
||||
- **Why They Use It**: What it does well
|
||||
- **Gaps**: What it doesn't do
|
||||
- **Switching Barriers**: Why they don't switch fully
|
||||
|
||||
### 8. Recommendations
|
||||
|
||||
Prioritized recommendations based on insights:
|
||||
|
||||
**High Priority**
|
||||
- Recommendation with supporting evidence
|
||||
- Expected impact
|
||||
|
||||
**Medium Priority**
|
||||
- Recommendation with supporting evidence
|
||||
- Expected impact
|
||||
|
||||
**Low Priority / Future Consideration**
|
||||
- Recommendation with supporting evidence
|
||||
- Expected impact
|
||||
|
||||
### 9. Open Questions
|
||||
|
||||
Research gaps identified:
|
||||
- What we still need to understand
|
||||
- Suggested follow-up research
|
||||
- Uncertainties requiring validation
|
||||
|
||||
## Analysis Guidelines
|
||||
|
||||
**When synthesizing interviews:**
|
||||
- Look for patterns across multiple participants
|
||||
- Note both what users say AND what they do
|
||||
- Pay attention to emotional reactions
|
||||
- Identify jobs-to-be-done, not just feature requests
|
||||
|
||||
**When analyzing quotes:**
|
||||
- Use verbatim quotes in "quotation marks"
|
||||
- Attribute quotes: [Participant ID, Role, Context]
|
||||
- Select quotes that illustrate patterns, not outliers
|
||||
- Include both positive and negative feedback
|
||||
|
||||
**When identifying themes:**
|
||||
- Use descriptive names, not generic labels
|
||||
- Provide evidence for each theme
|
||||
- Quantify when possible ("7 out of 10 users...")
|
||||
- Connect themes to business objectives
|
||||
|
||||
## Quality Standards
|
||||
|
||||
✅ **Good Synthesis:**
|
||||
- Identifies patterns, not just individual responses
|
||||
- Connects insights to product decisions
|
||||
- Includes supporting evidence for each claim
|
||||
- Separates observations from interpretations
|
||||
- Prioritizes findings by impact
|
||||
|
||||
❌ **Poor Synthesis:**
|
||||
- Lists every individual comment
|
||||
- Lacks evidence or examples
|
||||
- Makes unsupported leaps
|
||||
- Focuses on solutions before understanding problems
|
||||
- Ignores contradictory data
|
||||
|
||||
## Example Theme
|
||||
|
||||
```
|
||||
**Theme: Information Overload During Onboarding**
|
||||
|
||||
**Description**: Users consistently expressed feeling overwhelmed by the amount of information presented during initial setup, leading to incomplete onboarding and delayed time-to-value.
|
||||
|
||||
**Prevalence**: 9 out of 12 participants mentioned this issue unprompted
|
||||
|
||||
**Supporting Quotes**:
|
||||
- "I just wanted to get started, but it felt like I needed to read a manual first" [P3, Marketing Manager]
|
||||
- "By the third screen of instructions, I started clicking 'Next' without reading" [P7, Sales Rep]
|
||||
- "I wish there was a 'quick start' option for people like me who just want to try it" [P11, Product Designer]
|
||||
|
||||
**Implication**: Our current onboarding flow prioritizes completeness over engagement. We should consider a progressive disclosure approach where users can start using the product quickly and learn advanced features contextually.
|
||||
|
||||
**Recommended Action**:
|
||||
- Design a "Quick Start" path that gets users to first value in <3 minutes
|
||||
- Move advanced configuration to contextual help within the app
|
||||
- Test with 5-10 new users before full rollout
|
||||
- Expected impact: +20-30% activation rate improvement
|
||||
```
|
||||
|
||||
## Template Output Structure
|
||||
|
||||
When synthesizing research, use this structure:
|
||||
|
||||
```markdown
|
||||
# User Research Synthesis: [Research Topic]
|
||||
|
||||
## Research Overview
|
||||
- **Date**: [Date range]
|
||||
- **Methodology**: [Interview/Survey/Testing]
|
||||
- **Participants**: [Number] [User types]
|
||||
- **Research Questions**:
|
||||
1. [Question 1]
|
||||
2. [Question 2]
|
||||
3. [Question 3]
|
||||
|
||||
## Executive Summary
|
||||
[2-3 sentence overview of key findings and implications]
|
||||
|
||||
## Key Themes
|
||||
|
||||
### Theme 1: [Theme Name]
|
||||
[Full theme documentation as shown in example above]
|
||||
|
||||
### Theme 2: [Theme Name]
|
||||
[Full theme documentation]
|
||||
|
||||
[Continue with 4-8 themes]
|
||||
|
||||
## Pain Points Summary
|
||||
|
||||
| Pain Point | Severity | Frequency | Current Workaround |
|
||||
|------------|----------|-----------|-------------------|
|
||||
| [Pain 1] | High | 10/12 users | [How they cope] |
|
||||
| [Pain 2] | Medium | 7/12 users | [How they cope] |
|
||||
|
||||
## Feature Requests
|
||||
|
||||
### Must-Have
|
||||
1. **[Request]** - Mentioned by [X] participants
|
||||
- Quote: "[Representative quote]"
|
||||
- Underlying need: [Why they want this]
|
||||
|
||||
### High Value
|
||||
[Similar structure]
|
||||
|
||||
### Nice-to-Have
|
||||
[Similar structure]
|
||||
|
||||
## Recommendations
|
||||
|
||||
### High Priority (0-3 months)
|
||||
1. **[Recommendation]**
|
||||
- Supporting evidence: [Data from research]
|
||||
- Expected impact: [What will improve]
|
||||
- Effort estimate: [Rough sizing]
|
||||
|
||||
### Medium Priority (3-6 months)
|
||||
[Similar structure]
|
||||
|
||||
### Future Consideration (6+ months)
|
||||
[Similar structure]
|
||||
|
||||
## Open Questions
|
||||
1. [Question requiring more research]
|
||||
2. [Uncertainty to validate]
|
||||
3. [Follow-up study needed]
|
||||
|
||||
## Appendix
|
||||
- Interview guide used
|
||||
- Full participant demographics
|
||||
- Raw notes/transcripts (link)
|
||||
```
|
||||
Vendored
BIN
Binary file not shown.
@@ -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"]
|
||||
}
|
||||
Vendored
BIN
Binary file not shown.
@@ -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"
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user