justin/pm-claude-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: v12.0.0 — 150-skill milestone, 15 new skills across 10 bundles

Browse Source 
Adds 15 new skills reaching the 150-skill milestone:

Data & Analytics (pm-data):
- cohort-analysis: retention curves, LTV projection, behavioural segmentation, SQL reference queries
- data-pipeline-spec: ETL/ELT design with SLAs, DQ rules, error handling, compliance

Customer Success (pm-cs):
- renewal-playbook: health snapshot, value story, commercial scenarios, objection responses, 16-week timeline
- customer-success-plan: joint success plan with milestones, mutual commitments, escalation path

People & Leadership (pm-people):
- 360-feedback-template: survey instrument + narrative report with strengths and development themes
- team-health-check: Spotify-model assessment across 7 dimensions with facilitation guide

Operations (pm-operations):
- risk-register: L×I scoring, RAG heat map, mitigation and contingency plans
- raci-matrix: role definitions, decision map, anti-pattern guide, communication template

Marketing & GTM (pm-gtm):
- social-media-strategy: audience profile, content pillars, KPIs, 4-week starter calendar
- product-positioning-doc: April Dunford-style positioning, messaging hierarchy, persona messaging

Discovery (pm-discovery):
- customer-journey-map: stage-by-stage journey with touchpoints, emotions, and prioritised opportunities

Delivery (pm-delivery):
- user-story-writer: Given/When/Then ACs, edge cases, definition of done, epic decomposition

Advanced (pm-advanced):
- ai-ethics-review: fairness, bias, transparency, privacy, safety, accountability, societal impact

Sales (pm-sales):
- partnership-proposal: mutual value, commercial model, joint GTM plan, governance

Design (pm-design):
- design-system-audit: component coverage, token consistency, WCAG, adoption, remediation roadmap

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
2026-05-26 21:58:13 +01:00
parent 94e53d38a8
commit ae6ea4d53e
32 changed files with 6630 additions and 152 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude-plugin/marketplace.json
+22 -22
View File
@@ -1,8 +1,8 @@
{
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
"name": "pm-claude-skills",
"version": "11.0.0",
"description": "PM stands for Professional, not just Product Management. 135 Claude Skills + 4 agent templates across 23 bundles covering 16 professions — engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, and more. Built by a PM, used by everyone. Building blocks for the Anthropic agent template architecture.",
"version": "12.0.0",
"description": "PM stands for Professional, not just Product Management. 150 Claude Skills + 4 agent templates across 23 bundles covering 16 professions — engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, and more. Built by a PM, used by everyone. Building blocks for the Anthropic agent template architecture.",
"owner": {
"name": "Mohit Aggarwal",
"email": "mohit15856@gmail.com"
@@ -18,8 +18,8 @@
},
{
"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",
"description": "Discovery & research skills: Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper, Customer Journey Map. Structure user research from screener to synthesis — including end-to-end journey mapping with touchpoints, emotions, and prioritised opportunities.",
"version": "3.1.0",
"category": "productivity",
"source": "./plugins/pm-discovery",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -34,8 +34,8 @@
},
{
"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",
"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, User Story Writer. Write production-ready user stories with Given/When/Then acceptance criteria, edge cases, and definition of done.",
"version": "3.2.0",
"category": "productivity",
"source": "./plugins/pm-delivery",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -58,8 +58,8 @@
},
{
"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",
"description": "Advanced PM skills: AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief, AI Ethics Review. For senior PMs working on complex products — including a structured ethical review framework for AI/ML features covering fairness, transparency, privacy, safety, and accountability.",
"version": "3.1.0",
"category": "productivity",
"source": "./plugins/pm-advanced",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -74,8 +74,8 @@
},
{
"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",
"description": "Marketing & GTM skills: Go-To-Market Planner, Content Calendar, Competitor Teardown, Email Campaign, SEO Content Brief, Media Pitch, Social Media Strategy, Product Positioning Doc. Build positioning docs, messaging frameworks, content pillars, social strategies with KPIs, launch campaigns, and journalist pitches.",
"version": "1.2.0",
"category": "productivity",
"source": "./plugins/pm-gtm",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -90,32 +90,32 @@
},
{
"name": "pm-cs",
"description": "Customer Success skills: Customer Health Scorecard, QBR Deck, Escalation Brief, Churn Analysis. Score account health with a weighted RAG framework, build structured QBR decks with value narratives, write crisp escalation briefs for at-risk accounts, and analyse churn by category and segment with prioritised interventions.",
"version": "1.0.0",
"description": "Customer Success skills: Customer Health Scorecard, QBR Deck, Escalation Brief, Churn Analysis, Renewal Playbook, Customer Success Plan. Score health, build QBRs, write escalation briefs, plan renewals with commercial strategy and objection responses, and build joint success plans with milestones and mutual commitments.",
"version": "1.1.0",
"category": "productivity",
"source": "./plugins/pm-cs",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
},
{
"name": "pm-data",
"description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief, Chart Data Extractor. Build North Star metric trees, explain SQL, spec dashboards, and digitise chart images.",
"version": "1.1.0",
"description": "Data & analytics skills: Metrics Framework, SQL Query Explainer, Dashboard Brief, Chart Data Extractor, Cohort Analysis, Data Pipeline Spec. Build metric trees, explain SQL, spec dashboards, run cohort retention analysis with LTV modelling, and design ETL/ELT pipeline specifications with SLAs and data quality rules.",
"version": "1.2.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",
"description": "Leadership & people skills: Performance Review, Hiring Rubric, Team Offsite Planner, 360-Degree Feedback Template, Team Health Check. Write reviews, build scorecards, run Spotify-model team health assessments, and design 360 feedback surveys with structured narrative reports.",
"version": "1.1.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",
"description": "Design & UX skills: UX Research Plan, Design Critique, Accessibility Audit, Design System Audit. Create research plans, critique designs using JTBD and Gestalt principles, audit for WCAG 2.2 compliance, and audit design systems for component coverage, token consistency, and adoption health.",
"version": "1.1.0",
"category": "productivity",
"source": "./plugins/pm-design",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
@@ -154,16 +154,16 @@
},
{
"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",
"description": "Sales skills: Sales Battlecard, Discovery Call Prep, Proposal Writer, Account Plan, Sales Forecasting Model, Partnership Proposal. Build battlecards, prepare calls, write proposals, create account plans, build forecasts, and structure B2B partnership proposals with mutual value, commercial terms, and joint GTM plans.",
"version": "1.2.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",
"description": "Operations skills: Process Documentation, SOP Writer, Vendor Evaluation, Project Status Report, Workshop Facilitation Guide, Risk Register, RACI Matrix. Document workflows, write SOPs, build risk registers with L×I scoring, define RACI matrices for cross-functional initiatives, and design facilitated workshops.",
"version": "1.2.0",
"category": "productivity",
"source": "./plugins/pm-operations",
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
README.md
+168 -130
View File
@@ -1,18 +1,18 @@
# 🧠 PM Claude Skills — 135 Skills for Every Profession
# 🧠 PM Claude Skills — 150 Skills for Every Profession
[![Stars](https://img.shields.io/github/stars/mohitagw15856/pm-claude-skills?style=social)](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
[![Skills](https://img.shields.io/badge/skills-135-blue)](https://github.com/mohitagw15856/pm-claude-skills)
[![Version](https://img.shields.io/badge/version-11.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
[![Skills](https://img.shields.io/badge/skills-150-blue)](https://github.com/mohitagw15856/pm-claude-skills)
[![Version](https://img.shields.io/badge/version-12.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
[![Install](https://img.shields.io/badge/Install%20in%20Claude%20Code-2%20minutes-orange)](https://github.com/mohitagw15856/pm-claude-skills#-quick-install-2-minutes)
[![License](https://img.shields.io/badge/license-MIT-lightgrey)](LICENSE)
[![Sponsor](https://img.shields.io/badge/sponsor-❤️-ff69b4)](https://github.com/sponsors/mohitagw15856)
> **PM stands for Professional, not just Product Management.**
> 135 Claude Skills + 4 agent templates across 16 professions. Built by a PM, used by everyone.
> 150 Claude Skills + 4 agent templates across 16 professions. Built by a PM, used by everyone.
A community-built library of Claude Skills for professionals across every field — product management, engineering, customer success, marketing, design, legal, finance, HR, sales, operations, research, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
**🆕 Latest release (v11.0.0):** The full 500-star milestone is now complete — 21 remaining engineering skills shipped. pm-engineering is now the largest bundle in the library with 35 skills. 135 skills across 16 professions.
**🆕 Latest release (v12.0.0):** 150-skill milestone — 15 new skills across 10 bundles. From cohort analysis and data pipeline specs to renewal playbooks, team health checks, RACI matrices, social media strategy, and an AI ethics review framework.
---
## 🚀 Quick Install (2 minutes)
@@ -74,7 +74,7 @@ ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/
On May 5, 2026, Anthropic [released their first agent templates](https://www.anthropic.com/news/finance-agents) — pre-packaged Claude agents that combine **skills, connectors, and subagents** into ready-to-run workflows for financial services.
This library is the largest open-source collection of professional skills available — covering 15 professions beyond financial services. **The 106 skills here are the building blocks for agent templates outside of finance.**
This library is the largest open-source collection of professional skills available — covering 15 professions beyond financial services. **The 150 skills here are the building blocks for agent templates outside of finance.**
### What is an agent template?
@@ -151,6 +151,32 @@ More templates will follow. If you want to contribute one, see the [template con
---
## 🆕 What's New in v12.0.0 — 150 Skills Milestone
**15 new skills across 10 bundles:**
| Skill | Bundle | What It Does |
|---|---|---|
| **Cohort Analysis** 🆕 | pm-data | Retention curves, LTV projection, behavioural segmentation, and churn leading indicators — with SQL reference queries |
| **Data Pipeline Spec** 🆕 | pm-data | ETL/ELT pipeline design with sources, transforms, SLAs, DQ rules, error handling, and security/compliance notes |
| **Renewal Playbook** 🆕 | pm-cs | Renewal brief with health snapshot, stakeholder map, value story, commercial scenarios, objection responses, and a 16-week timeline |
| **Customer Success Plan** 🆕 | pm-cs | Joint success plan with business goals, success metrics, milestone roadmap, mutual commitments, and escalation path |
| **360-Degree Feedback Template** 🆕 | pm-people | Either a complete survey instrument with GWT acceptance criteria, or a structured narrative feedback report with themes and development actions |
| **Team Health Check** 🆕 | pm-people | Spotify-model health assessment across 7 dimensions — delivery, safety, morale, speed, purpose, and collaboration — with facilitation guide |
| **Risk Register** 🆕 | pm-operations | L×I risk scoring, RAG heat map, top-risk executive summary, and per-risk mitigation and contingency plans |
| **RACI Matrix** 🆕 | pm-operations | Complete RACI with role definitions, decision map, anti-pattern guide, and a communication template for all involved teams |
| **Social Media Strategy** 🆕 | pm-gtm | Audience profile, platform rationale, content pillars, posting cadence, tone of voice, KPIs, and a 4-week starter calendar |
| **Product Positioning Doc** 🆕 | pm-gtm | April Dunford-style positioning doc with category, target customer, competitive alternatives, differentiation, proof points, messaging hierarchy, and persona messaging |
| **Customer Journey Map** 🆕 | pm-discovery | Stage-by-stage journey from awareness to advocacy with touchpoints, emotions, pain points, an emotion curve, and prioritised opportunities |
| **User Story Writer** 🆕 | pm-delivery | Production-ready user stories with Given/When/Then ACs, edge cases, out-of-scope, definition of done, and epic decomposition |
| **AI Ethics Review** 🆕 | pm-advanced | Structured ethical review covering fairness, bias, transparency, privacy, safety, accountability, and societal impact — with risk tier and pre-deployment checklist |
| **Partnership Proposal** 🆕 | pm-sales | B2B partnership proposal with mutual value, commercial model, joint GTM plan, governance, and risks |
| **Design System Audit** 🆕 | pm-design | Component coverage audit, token consistency, documentation quality, WCAG 2.2 accessibility, adoption barriers, and a remediation roadmap |
The library now includes **150 skills** across **16 professions** + 4 working agent templates.
---
## 🆕 What's New in v10.0.0
**Two star milestones unlocked — 8 new skills shipped:**
@@ -232,88 +258,90 @@ This repo was built alongside a published article series. Read the full story:
---
## 🗂️ All 135 Skills
## 🗂️ All 150 Skills
### 🛠️ Product Management (Skills 1–34)
### 🛠️ Product Management (Skills 1–37)
**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 |
| 1–6 | **pm-essentials** | PRD Template, Meeting Notes, Stakeholder Update, User Research Synthesis, Competitive Analysis, **Word Doc Tracked Changes** |
| 7–11 | **pm-discovery** | Discovery Interview Guide, Job Story Mapper, User Interview Synthesis, Assumption Mapper, **Customer Journey Map** 🆕 |
| 12–17 | **pm-planning** | OKR Builder, Feature Prioritisation (RICE/MoSCoW/Kano/ICE), Roadmap Presentation, Pricing Strategy, RICE Impact Matrix, Roadmap Narrative |
| 18–26 | **pm-delivery** | Sprint Planning, Technical Spec, A/B Test Planner, Go-to-Market Planner, Launch Checklist, Sprint Brief, Retro, PPTX Slide Auditor, **User Story Writer** 🆕 |
| 27–29 | **pm-analytics** | Data Analysis Standard, Retention Analysis, Product Health Analysis |
| 30–35 | **pm-strategy** | Competitor Signal Tracker, Competitive Intelligence Monitor, Stakeholder Influence Mapper, Strategic Narrative, Executive Update, Ambiguity Resolver |
| 36–37 | **pm-advanced** | AI Product Canvas, Multi-Source Signal Synthesiser, Experiment Designer, Design Handoff Brief, **AI Ethics Review** 🆕 |
> 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)
### 📣 Marketing & GTM (Skills 38–45)
**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 |
| 38 | **Go-To-Market** | `skills/go-to-market/` | Positioning statements, messaging pillars, feature/benefit mapping, role-specific use cases |
| 39 | **Content Calendar** | `skills/content-calendar/` | Multi-channel content calendars with opening hooks, formats, and repurposing map |
| 40 | **Competitor Teardown** | `skills/competitor-teardown/` | Full competitive analysis: positioning map, feature comparison, messaging gaps, SWOT, recommendations |
| 41 | **Email Campaign** | `skills/email-campaign/` | Sequenced email campaigns with subject lines, preview text, body copy, and CTAs |
| 42 | **SEO Content Brief** | `skills/seo-content-brief/` | Complete SEO briefs with search intent, competitor gap analysis, content outline, and on-page requirements |
| 43 | **Media Pitch** | `skills/media-pitch/` | Story-first journalist pitches with angle development framework and pitch writing rules |
| 44 | **Social Media Strategy** 🆕 | `skills/social-media-strategy/` | Audience profile, platform rationale, content pillars, posting cadence, KPIs, and a 4-week starter calendar |
| 45 | **Product Positioning Doc** 🆕 | `skills/product-positioning-doc/` | April Dunford-style positioning with category, differentiation, proof points, messaging hierarchy, and persona messaging |
---
### 👩‍💻 Engineering & Tech (Skills 41–75)
### 👩‍💻 Engineering & Tech (Skills 46–80)
**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 |
| 51 | **CI/CD Playbook** | `skills/cicd-playbook/` | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
| 52 | **SLO & Error Budget** | `skills/slo-error-budget/` | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
| 53 | **Developer Onboarding Doc** | `skills/developer-onboarding-doc/` | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
| 54 | **On-Call Runbook** | `skills/oncall-runbook/` | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
| 55 | **Security Threat Model** 🆕 | `skills/security-threat-model/` | STRIDE-based threat model with asset register, trust boundaries, per-component threat enumeration, risk scores, and mitigations |
| 56 | **Performance Budget** 🆕 | `skills/performance-budget/` | Performance budgets for Core Web Vitals and backend latency SLOs with CI enforcement and breach response policy |
| 57 | **Database Schema Design** 🆕 | `skills/database-schema-design/` | Database schema documentation with ER diagram, DDL definitions, index strategy, and access pattern analysis |
| 58 | **Database Migration Plan** 🆕 | `skills/database-migration-plan/` | Safe zero-downtime migration plan using expand-contract pattern with per-step rollback and data validation queries |
| 59 | **Technical Debt Register** 🆕 | `skills/technical-debt-register/` | Debt inventory with business impact scoring, effort estimates, priority matrix, and quarterly resolution roadmap |
| 60 | **RFC Writer** 🆕 | `skills/rfc-writer/` | Engineering Request for Comments covering problem, proposed solution, alternatives-with-rejection-reasons, and rollout plan |
| 61 | **Capacity Planning** 🆕 | `skills/capacity-planning/` | Traffic forecasts, resource requirements per tier, scaling strategy, cost projections, and infrastructure action roadmap |
| 62 | **Load Testing Plan** 🆕 | `skills/load-testing-plan/` | Load test plan with scenario definitions (baseline/stress/spike/soak), k6/Locust skeleton, thresholds, and CI gates |
| 63 | **Disaster Recovery Plan** 🆕 | `skills/disaster-recovery-plan/` | DR plan with RPO/RTO targets, per-scenario runbooks, backup procedures, game day testing, and communication templates |
| 64 | **Feature Flag Guide** 🆕 | `skills/feature-flag-guide/` | Feature flag lifecycle playbook — taxonomy, rollout strategy, monitoring requirements, cleanup policy, and governance |
| 65 | **Dependency Audit** 🆕 | `skills/dependency-audit/` | Dependency audit for CVE vulnerabilities, license compliance, outdated packages, and 30-day remediation plan |
| 66 | **Service Catalog Entry** 🆕 | `skills/service-catalog-entry/` | Microservice catalog entry with ownership, SLAs, API contract, data classification, and operational runbook links |
| 67 | **Monitoring Setup Guide** 🆕 | `skills/monitoring-setup-guide/` | Four golden signals applied to a service, alert rules spec, structured log schema, tracing setup, and dashboard layout |
| 68 | **Local Dev Setup** 🆕 | `skills/local-dev-setup/` | Local development setup guide — prerequisites, env vars, dependencies, test commands, and 5 common failure fixes |
| 69 | **API Versioning Strategy** 🆕 | `skills/api-versioning-strategy/` | API versioning scheme, lifecycle policy, breaking change classification table, deprecation process, and migration guide template |
| 70 | **Infra-as-Code Review** 🆕 | `skills/infra-as-code-review/` | IaC review for Terraform/CloudFormation/Pulumi — security, naming, state, cost, and drift risk with severity-classified findings |
| 71 | **Engineering Weekly Report** 🆕 | `skills/engineering-weekly-report/` | Weekly engineering status in a consistent format — shipped/in-progress/blocked, metrics, decisions, risks, and next week |
| 72 | **Tech Radar** 🆕 | `skills/tech-radar/` | ThoughtWorks-format technology radar with Adopt/Trial/Assess/Hold quadrants, per-blip rationale, and maintenance process |
| 73 | **Sprint Velocity Analysis** 🆕 | `skills/sprint-velocity-analysis/` | Velocity trend analysis, completion rate patterns, blocker frequency, improvement recommendations, and capacity forecast |
| 74 | **Microservices Decomposition** 🆕 | `skills/microservices-decomposition/` | Domain-driven service boundary design with bounded context map, communication patterns, data ownership, and strangler fig migration plan |
| 75 | **Engineering Hiring Rubric** 🆕 | `skills/engineering-hiring-rubric/` | Technical interview rubric with level expectations, coding scorecard, system design guide, behavioural question bank, and debrief template |
| 46 | **Code Review Checklist** | `skills/code-review-checklist/` | Tailored PR review checklists by language, type, and risk level |
| 47 | **Incident Postmortem** | `skills/incident-postmortem/` | Blameless postmortems with timeline, RCA, impact, and action items |
| 48 | **API Docs Writer** | `skills/api-docs-writer/` | Developer-facing API docs: endpoints, parameters, response schemas, code examples |
| 49 | **Architecture Decision Record** | `skills/architecture-decision-record/` | ADRs with context, options considered, decision, consequences, and risks |
| 50 | **Debugging Log Analyser** | `skills/debugging-log-analyser/` | Parse stack traces and error logs into a structured root cause diagnosis with a specific fix |
| 51 | **PR Description Writer** | `skills/pr-description-writer/` | Write reviewer-friendly PR descriptions from a diff, commit list, or change summary |
| 52 | **System Design Interview** | `skills/system-design-interview/` | Structure complete system design answers with capacity estimates, component deep-dives, and trade-offs |
| 53 | **Changelog Generator** | `skills/changelog-generator/` | Convert git commits into a polished, user-facing changelog following Keep a Changelog format |
| 54 | **Test Strategy Doc** | `skills/test-strategy-doc/` | Write a complete test strategy with risk assessment, test types, coverage targets, and P0/P1 test cases |
| 55 | **Runbook Writer** | `skills/runbook-writer/` | Write operational runbooks for deployments, incidents, and maintenance with exact commands and rollback steps |
| 56 | **CI/CD Playbook** | `skills/cicd-playbook/` | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
| 57 | **SLO & Error Budget** | `skills/slo-error-budget/` | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
| 58 | **Developer Onboarding Doc** | `skills/developer-onboarding-doc/` | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
| 59 | **On-Call Runbook** | `skills/oncall-runbook/` | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
| 60 | **Security Threat Model** 🆕 | `skills/security-threat-model/` | STRIDE-based threat model with asset register, trust boundaries, per-component threat enumeration, risk scores, and mitigations |
| 61 | **Performance Budget** 🆕 | `skills/performance-budget/` | Performance budgets for Core Web Vitals and backend latency SLOs with CI enforcement and breach response policy |
| 62 | **Database Schema Design** 🆕 | `skills/database-schema-design/` | Database schema documentation with ER diagram, DDL definitions, index strategy, and access pattern analysis |
| 63 | **Database Migration Plan** 🆕 | `skills/database-migration-plan/` | Safe zero-downtime migration plan using expand-contract pattern with per-step rollback and data validation queries |
| 64 | **Technical Debt Register** 🆕 | `skills/technical-debt-register/` | Debt inventory with business impact scoring, effort estimates, priority matrix, and quarterly resolution roadmap |
| 65 | **RFC Writer** 🆕 | `skills/rfc-writer/` | Engineering Request for Comments covering problem, proposed solution, alternatives-with-rejection-reasons, and rollout plan |
| 66 | **Capacity Planning** 🆕 | `skills/capacity-planning/` | Traffic forecasts, resource requirements per tier, scaling strategy, cost projections, and infrastructure action roadmap |
| 67 | **Load Testing Plan** 🆕 | `skills/load-testing-plan/` | Load test plan with scenario definitions (baseline/stress/spike/soak), k6/Locust skeleton, thresholds, and CI gates |
| 68 | **Disaster Recovery Plan** 🆕 | `skills/disaster-recovery-plan/` | DR plan with RPO/RTO targets, per-scenario runbooks, backup procedures, game day testing, and communication templates |
| 69 | **Feature Flag Guide** 🆕 | `skills/feature-flag-guide/` | Feature flag lifecycle playbook — taxonomy, rollout strategy, monitoring requirements, cleanup policy, and governance |
| 70 | **Dependency Audit** 🆕 | `skills/dependency-audit/` | Dependency audit for CVE vulnerabilities, license compliance, outdated packages, and 30-day remediation plan |
| 71 | **Service Catalog Entry** 🆕 | `skills/service-catalog-entry/` | Microservice catalog entry with ownership, SLAs, API contract, data classification, and operational runbook links |
| 72 | **Monitoring Setup Guide** 🆕 | `skills/monitoring-setup-guide/` | Four golden signals applied to a service, alert rules spec, structured log schema, tracing setup, and dashboard layout |
| 73 | **Local Dev Setup** 🆕 | `skills/local-dev-setup/` | Local development setup guide — prerequisites, env vars, dependencies, test commands, and 5 common failure fixes |
| 74 | **API Versioning Strategy** 🆕 | `skills/api-versioning-strategy/` | API versioning scheme, lifecycle policy, breaking change classification table, deprecation process, and migration guide template |
| 75 | **Infra-as-Code Review** 🆕 | `skills/infra-as-code-review/` | IaC review for Terraform/CloudFormation/Pulumi — security, naming, state, cost, and drift risk with severity-classified findings |
| 76 | **Engineering Weekly Report** 🆕 | `skills/engineering-weekly-report/` | Weekly engineering status in a consistent format — shipped/in-progress/blocked, metrics, decisions, risks, and next week |
| 77 | **Tech Radar** 🆕 | `skills/tech-radar/` | ThoughtWorks-format technology radar with Adopt/Trial/Assess/Hold quadrants, per-blip rationale, and maintenance process |
| 78 | **Sprint Velocity Analysis** 🆕 | `skills/sprint-velocity-analysis/` | Velocity trend analysis, completion rate patterns, blocker frequency, improvement recommendations, and capacity forecast |
| 79 | **Microservices Decomposition** 🆕 | `skills/microservices-decomposition/` | Domain-driven service boundary design with bounded context map, communication patterns, data ownership, and strangler fig migration plan |
| 80 | **Engineering Hiring Rubric** 🆕 | `skills/engineering-hiring-rubric/` | Technical interview rubric with level expectations, coding scorecard, system design guide, behavioural question bank, and debrief template |
---
### 🤝 Customer Success (Skills 76–79)
### 🤝 Customer Success (Skills 76–81)
**Bundle:** `pm-cs`
> 250 ⭐ milestone unlocked. Install:
> Install:
claude plugin install pm-cs@pm-claude-skills
@@ -324,179 +352,189 @@ claude plugin install pm-cs@pm-claude-skills
| 77 | **QBR Deck** | `skills/qbr-deck/` | Slide-by-slide quarterly business review with talking points, value narrative, and mutual commitments |
| 78 | **Escalation Brief** | `skills/cs-escalation-brief/` | Structured brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
| 79 | **Churn Analysis** | `skills/churn-analysis/` | Churn breakdown by category and segment, early warning signals, and prioritised interventions |
| 80 | **Renewal Playbook** 🆕 | `skills/renewal-playbook/` | Renewal brief with health snapshot, value story, commercial scenarios, objection responses, and 16-week execution timeline |
| 81 | **Customer Success Plan** 🆕 | `skills/customer-success-plan/` | Joint success plan with business goals, success metrics, milestone roadmap, mutual commitments, and escalation path |
---
### 📊 Data & Analytics (Skills 80–83)
### 📊 Data & Analytics (Skills 82–87)
**Bundle:** `pm-data`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 80 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
| 81 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
| 82 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
| 83 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
| 82 | **Metrics Framework** | `skills/metrics-framework/` | North Star + metric tree, dashboard tiers, counter-metrics |
| 83 | **SQL Query Explainer** | `skills/sql-query-explainer/` | Explain, optimise, write, and document SQL in plain English |
| 84 | **Dashboard Brief** | `skills/dashboard-brief/` | Complete dashboard spec: KPIs, charts, filters, layout, data requirements |
| 85 | **Chart Data Extractor** | `skills/chart-data-extractor/` | Extract pixel-level data from chart images into structured data tables |
| 86 | **Cohort Analysis** 🆕 | `skills/cohort-analysis/` | Retention curves, LTV projection, behavioural segmentation, churn leading indicators, and SQL reference queries |
| 87 | **Data Pipeline Spec** 🆕 | `skills/data-pipeline-spec/` | ETL/ELT pipeline design with sources, transforms, SLAs, DQ rules, error handling, and compliance notes |
---
### 🧑‍💼 Leadership & People (Skills 84–86)
### 🧑‍💼 Leadership & People (Skills 88–92)
**Bundle:** `pm-people`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 84 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
| 85 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
| 86 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
| 88 | **Performance Review** | `skills/performance-review/` | Structured reviews from bullet-point notes — self, manager, peer, and upward |
| 89 | **Hiring Rubric** | `skills/hiring-rubric/` | Interview scorecards with competencies, behavioural questions, and panel guide |
| 90 | **Team Offsite Planner** | `skills/team-offsite-planner/` | Full offsite agenda, session facilitation notes, and logistics checklist |
| 91 | **360-Degree Feedback Template** 🆕 | `skills/360-feedback-template/` | Survey instrument with GWT-anchored questions, or a structured narrative report with strengths and development themes |
| 92 | **Team Health Check** 🆕 | `skills/team-health-check/` | Spotify-model assessment across 7 dimensions — delivery, safety, morale, speed, purpose, and collaboration |
---
### 🎨 Design & UX (Skills 87–89)
### 🎨 Design & UX (Skills 93–96)
**Bundle:** `pm-design`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 87 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
| 88 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
| 89 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
| 93 | **UX Research Plan** | `skills/ux-research-plan/` | Research plans with screener, discussion guide, and synthesis framework |
| 94 | **Design Critique** | `skills/design-critique/` | Structured feedback using JTBD, Gestalt principles, and Nielsen's heuristics |
| 95 | **Accessibility Audit** | `skills/accessibility-audit/` | WCAG 2.2 audit with prioritised remediation and quick wins |
| 96 | **Design System Audit** 🆕 | `skills/design-system-audit/` | Audit component coverage, token consistency, documentation quality, WCAG compliance, adoption barriers, and remediation roadmap |
---
### 🏢 Business & Strategy (Skills 90–92)
### 🏢 Business & Strategy (Skills 97–99)
**Bundle:** `pm-business`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 90 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
| 91 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
| 92 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
| 97 | **Investor Update** | `skills/investor-update/` | Monthly/quarterly investor updates: metrics, highlights, challenges, and asks |
| 98 | **Board Deck Narrative** | `skills/board-deck-narrative/` | Slide-by-slide board presentation structure with narrative beats and talking points |
| 99 | **Job Application** | `skills/job-application/` | Tailored CV summary, ATS keyword optimisation, and cover letter for any JD |
---
### ⚖️ Legal (Skills 93–96)
### ⚖️ Legal (Skills 100–103)
**Bundle:** `pm-legal`
> ⚠️ All legal skills include a disclaimer. Not a substitute for qualified legal advice.
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 93 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
| 94 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
| 95 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
| 96 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
| 100 | **Contract Review** | `skills/contract-review/` | Structured review with key terms, flagged clauses, risk rating, and plain English summary |
| 101 | **NDA Analyser** | `skills/nda-analyser/` | Clause-by-clause NDA analysis with risk flags and negotiation checklist |
| 102 | **Legal Brief** | `skills/legal-brief/` | Legal memos and argument outlines in IRAC format (Issue, Rule, Application, Conclusion) |
| 103 | **Compliance Checklist** | `skills/compliance-checklist/` | GDPR, SOC 2, ISO 27001, FCA, HIPAA compliance checklists with prioritised gap analysis |
---
### 💰 Finance (Skills 97–101)
### 💰 Finance (Skills 104–108)
**Bundle:** `pm-finance`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 97 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
| 98 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
| 99 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
| 100 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
| 101 | **Tax Planning Checklist** | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |
| 104 | **Financial Model Narrative** | `skills/financial-model-narrative/` | Turns P&L and model outputs into board-ready written narratives |
| 105 | **Budget Variance Analysis** | `skills/budget-variance-analysis/` | Variance table with root cause commentary and management summary |
| 106 | **Investor Pitch Deck** | `skills/investor-pitch-deck/` | Slide-by-slide pitch deck structure with what each slide must prove |
| 107 | **Financial Due Diligence** | `skills/financial-due-diligence/` | DD document request list, analytical questions, and red flags checklist |
| 108 | **Tax Planning Checklist** | `skills/tax-planning-checklist/` | Year-end tax planning framework across income, pension, CGT, business reliefs, and ISAs |
---
### 👥 HR (Skills 102–106)
### 👥 HR (Skills 109–113)
**Bundle:** `pm-hr`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 102 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
| 103 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
| 104 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
| 105 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
| 106 | **Change Management Plan** | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
| 109 | **Job Description Writer** | `skills/job-description-writer/` | Inclusive, structured JDs with built-in language review and salary range nudge |
| 110 | **Onboarding Plan** | `skills/onboarding-plan/` | 30/60/90-day plans with week-by-week structure, milestones, and manager checklist |
| 111 | **Employee Engagement Survey** | `skills/employee-engagement-survey/` | Survey design + results analysis mode with eNPS and action planning template |
| 112 | **Redundancy Consultation** | `skills/redundancy-consultation/` | Process timeline, at-risk letter, consultation script, and confirmation letter — UK law |
| 113 | **Change Management Plan** | `skills/change-management-plan/` | Full change plan covering stakeholder analysis, communication strategy, training, and adoption metrics |
---
### 🤝 Sales (Skills 107–111)
### 🤝 Sales (Skills 114–119)
**Bundle:** `pm-sales`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 107 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
| 108 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
| 109 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
| 110 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
| 111 | **Sales Forecasting Model** | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
| 114 | **Sales Battlecard** | `skills/sales-battlecard/` | One-page competitive battlecard with objection responses and landmine questions |
| 115 | **Discovery Call Prep** | `skills/discovery-call-prep/` | Call brief with research summary, hypothesis, structured questions, and success criteria |
| 116 | **Proposal Writer** | `skills/proposal-writer/` | Commercial proposals structured around the prospect's problem, not the product |
| 117 | **Account Plan** | `skills/account-plan/` | Strategic account plan with relationship map, whitespace analysis, risks, and 90-day actions |
| 118 | **Sales Forecasting Model** | `skills/sales-forecasting-model/` | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
| 119 | **Partnership Proposal** 🆕 | `skills/partnership-proposal/` | B2B partnership proposal with mutual value, commercial model, joint GTM plan, governance, and risk register |
---
### ⚙️ Operations (Skills 112–116)
### ⚙️ Operations (Skills 120–126)
**Bundle:** `pm-operations`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 112 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
| 113 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
| 114 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
| 115 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
| 116 | **Workshop Facilitation Guide** | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
| 120 | **Process Documentation** | `skills/process-documentation/` | Clear process docs with steps, roles, edge cases — followable by a new starter |
| 121 | **SOP Writer** | `skills/sop-writer/` | Formal, audit-ready SOPs with version control, quality checks, and non-conformance process |
| 122 | **Vendor Evaluation** | `skills/vendor-evaluation/` | Weighted vendor scorecard, RFP questions, reference check template, and recommendation |
| 123 | **Project Status Report** | `skills/project-status-report/` | RAG status reports with milestone progress, issues, risks, and decisions required |
| 124 | **Workshop Facilitation Guide** | `skills/workshop-facilitation-guide/` | Complete facilitation guides with activity instructions, decision protocols, and facilitator moves |
| 125 | **Risk Register** 🆕 | `skills/risk-register/` | L×I risk scoring, RAG heat map, top-risk executive summary, and per-risk mitigation and contingency plans |
| 126 | **RACI Matrix** 🆕 | `skills/raci-matrix/` | RACI with role definitions, decision map, anti-pattern guide, and a communication template for all teams |
---
### 🏥 Research & Healthcare (Skills 117–120)
### 🏥 Research & Healthcare (Skills 127–130)
**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 |
|---|---|---|---|
| 117 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
| 118 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
| 119 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
| 120 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
| 127 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
| 128 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
| 129 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
| 130 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
---
### 🌐 Cross-Profession (Skills 121–124)
### 🌐 Cross-Profession (Skills 131–134)
**Bundle:** `pm-cross`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 121 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
| 122 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
| 123 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
| 124 | **Teaching Lesson Plan** | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
| 131 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
| 132 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
| 133 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
| 134 | **Teaching Lesson Plan** | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
---
### 🖼️ Figma (Skills 125–134)
### 🖼️ Figma (Skills 135–144)
**Bundle:** `pm-figma`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 125 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
| 126 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
| 127 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
| 128 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
| 129 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
| 130 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
| 131 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
| 132 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
| 133 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
| 134 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
| 135 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
| 136 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
| 137 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
| 138 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
| 139 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
| 140 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
| 141 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
| 142 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
| 143 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
| 144 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
claude plugin install pm-figma@pm-claude-skills
---
### 📅 PM Rituals (Skill 135)
### 📅 PM Rituals (Skills 145–150)
**Bundle:** `pm-rituals`
| # | Skill | Folder | What It Does |
|---|---|---|---|
| 135 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
| 145 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
---
## ❤️ Sponsor This Work
Building and maintaining 135 skills across 23 bundles takes real time — testing skills against new model releases, building new ones from community requests, writing the article series, and keeping documentation current.
Building and maintaining 150 skills across 23 bundles takes real time — testing skills against new model releases, building new ones from community requests, writing the article series, and keeping documentation current.
If these skills save you time at work, consider sponsoring:
plugins/pm-advanced/skills/ai-ethics-review/SKILL.md
+207
View File
@@ -0,0 +1,207 @@
---
name: ai-ethics-review
description: "Conduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations."
---
# AI Ethics Review Skill
This skill produces a structured ethical review of an AI or machine learning feature, model, or product. Output covers fairness, transparency, privacy, safety, accountability, and societal impact — with risk scoring, prioritised mitigations, and a checklist suitable for governance review or responsible AI documentation.
> ⚠️ This skill provides a structured framework for identifying and documenting ethical risks. It is not a substitute for legal advice, regulated algorithmic impact assessments, or specialist ethics review required in specific jurisdictions (e.g. EU AI Act, UK AI regulation).
## Required Inputs
Ask the user for these if not provided:
- **Feature or model name** and what it does
- **Who it affects** — which users or people does the AI interact with, make decisions about, or collect data from?
- **What decisions or outputs it produces** — recommendations, predictions, classifications, generation, automation?
- **Consequentiality** — how significant are the AI's decisions? (low-stakes suggestions vs decisions that affect employment, credit, health, safety, etc.)
- **Data used** — what training data, user data, or third-party data is used?
- **Human oversight** — is there a human in the loop, and at what stage?
- **Deployment context** — who will use this and how? (internal tool / consumer-facing / automated pipeline)
## Output Structure
---
# AI Ethics Review: [Feature / Model Name]
**Product / system:** [Name and brief description]
**Review type:** [Pre-deployment review / Post-deployment audit / Change review]
**Risk tier:** [High / Medium / Low — based on consequentiality, scale, and affected population]
**Reviewer:** [Name / Team]
**Date:** [Date]
**Status:** [Draft / Approved / Requires escalation]
---
## 1. Feature Summary
| | |
|---|---|
| **What it does** | [1–2 sentences — plain English description of the AI feature and its purpose] |
| **Who uses it** | [End users / internal teams / automated system] |
| **Who is affected by its outputs** | [May be different from who uses it — e.g. an AI hiring tool is used by HR but affects candidates] |
| **Output type** | [Recommendation / Classification / Prediction / Generation / Automation / Scoring] |
| **Scale** | [How many people affected per day/month?] |
| **Consequentiality** | [High: affects access to services, employment, credit, health, safety / Medium: influences decisions / Low: suggestions with easy override] |
| **Human oversight level** | [Full automation / Human review before action / Human can override after action / Advisory only] |
---
## 2. Risk Tier Assessment
| Factor | Score (1–3) | Rationale |
|---|---|---|
| **Consequentiality** (impact on individuals) | [1=low, 3=high] | [e.g. 3 — model output influences hiring decisions] |
| **Scale** (number of people affected) | [1=few, 3=many] | [e.g. 2 — internal tool used for ~500 candidates/year] |
| **Reversibility** (can harm be undone?) | [1=reversible, 3=irreversible] | [e.g. 2 — unfair rejection can be appealed but may not be caught] |
| **Vulnerability of affected group** | [1=general population, 3=protected or vulnerable group] | [e.g. 2 — includes protected characteristics in the decision context] |
| **Transparency** (do affected people know?) | [1=informed, 3=opaque] | [e.g. 3 — candidates are not told AI is used in screening] |
**Composite risk tier:** [High (12–15) / Medium (7–11) / Low (3–6)]
**Risk tier implications:**
- **High:** Mandatory senior ethics review, DPA/DPIA required, human-in-loop for all consequential decisions, ongoing monitoring required
- **Medium:** Ethics review recommended, document mitigations, quarterly monitoring
- **Low:** Standard review, document assumptions, annual review
---
## 3. Fairness & Bias
*Does the AI treat people equitably across groups?*
**Protected characteristics relevant to this feature:**
[List applicable protected characteristics — age, gender, race/ethnicity, disability, religion, national origin, etc.]
| Risk | Analysis | Mitigation |
|---|---|---|
| **Training data bias** | [Does the training data reflect historical discrimination? e.g. hiring data that reflects past biases in who was hired] | [Audit training data for demographic representation / use debiasing techniques / document data lineage] |
| **Proxy discrimination** | [Could the model use a proxy for a protected characteristic? e.g. using postcode as a proxy for race] | [Identify proxy features / test for disparate impact using adversarial debiasing] |
| **Differential performance** | [Does the model perform differently across demographic groups? — e.g. lower accuracy for underrepresented groups] | [Disaggregate performance metrics by group / set minimum performance thresholds per group] |
| **Feedback loops** | [Does the model's output reinforce existing disparities? e.g. recommending content that keeps disadvantaged groups in lower-engagement patterns] | [Monitor outcome distributions over time / implement feedback loop detection] |
**Fairness evaluation method:** [What method will be used to measure fairness — statistical parity / equalised odds / individual fairness? Who is responsible for running it and how often?]
---
## 4. Transparency & Explainability
*Can affected people understand how the AI makes decisions?*
| Dimension | Current state | Required state | Gap |
|---|---|---|---|
| **User disclosure** | [Are users told they're interacting with AI?] | [Yes — required for trust and regulation] | [e.g. No disclosure on current UI] |
| **Decision explanation** | [Can the system explain why it reached a conclusion?] | [For high-stakes decisions: yes] | [e.g. Black-box model — no feature attribution available] |
| **Right to know** | [Can affected people ask how a decision was made?] | [Yes — required under GDPR Art. 22 for automated decisions] | [e.g. No process exists] |
| **Confidence calibration** | [Does the model express appropriate uncertainty?] | [Yes — overconfident models cause over-reliance] | [e.g. Model outputs binary label without confidence score] |
**Explainability approach:** [LIME / SHAP / rule-based surrogate / LLM-generated rationale / none — and why]
---
## 5. Privacy & Data
*Is personal data used responsibly and lawfully?*
| Risk | Analysis | Mitigation |
|---|---|---|
| **Data minimisation** | [Does the model use more personal data than necessary?] | [Audit input features — remove any that don't improve performance and involve unnecessary data collection] |
| **Data retention** | [How long is personal data retained for training and inference?] | [Define retention policy aligned to GDPR / CCPA / sector requirements] |
| **Re-identification risk** | [Could model outputs or training data be used to identify individuals?] | [Differential privacy / k-anonymity / output rate limiting] |
| **Third-party data** | [Is data from third parties used? Is it licensed for this use?] | [Audit data licensing / get legal sign-off on each third-party source] |
| **Cross-border data transfer** | [Is personal data transferred across jurisdictions?] | [Legal review — Standard Contractual Clauses or equivalent] |
**DPIA required?** [Yes / No / Uncertain — for High tier or whenever processing is likely to result in high risk to individuals under GDPR Art. 35]
---
## 6. Safety & Reliability
*What happens when the AI gets it wrong?*
| Failure mode | Likelihood | Impact | Mitigation |
|---|---|---|---|
| **False positives** | [H/M/L] | [e.g. Flagging a legitimate transaction as fraud — customer locked out] | [Set threshold conservatively; human review for edge cases] |
| **False negatives** | [H/M/L] | [e.g. Missing a real fraud case — financial loss] | [Monitor false negative rate; set minimum recall threshold] |
| **Out-of-distribution inputs** | [H/M/L] | [Model behaves unpredictably on inputs outside training distribution] | [Input validation; confidence thresholding — route uncertain inputs to human review] |
| **Model degradation** | [M] | [Performance degrades as data distributions shift post-deployment] | [Scheduled performance monitoring; drift detection alerts] |
| **Adversarial inputs** | [L/M] | [Deliberate manipulation of inputs to game the model] | [Adversarial testing; rate limiting; anomaly detection on inputs] |
| **Single point of failure** | [L/M] | [Model outage causes downstream system failure] | [Graceful degradation — define fallback behaviour when model is unavailable] |
**Fallback behaviour:** [What happens if the AI is unavailable or returns low-confidence output? — e.g. route to human review / use rule-based fallback / block the action]
---
## 7. Accountability & Governance
*Who is responsible when things go wrong?*
| Question | Answer |
|---|---|
| **Who owns this AI feature?** | [Team or individual with end-to-end accountability] |
| **Who approved deployment?** | [Name and role — must be documented] |
| **Who is responsible for ongoing monitoring?** | [Team and cadence] |
| **Who can shut it down?** | [Who has kill-switch authority and under what conditions?] |
| **How are incidents reported?** | [Internal escalation path + external disclosure process if required] |
| **Is this subject to regulation?** | [EU AI Act / UK AI regulation / sector-specific rules — FINRA, FDA, FCA, etc.] |
**Incident response plan:** [Link to or describe what happens if the model causes harm — detection, escalation, remediation, disclosure]
---
## 8. Societal Impact
*Beyond individual users — what are the broader effects?*
| Impact area | Risk | Mitigation |
|---|---|---|
| **Labour displacement** | [Does this AI automate tasks that currently employ people?] | [Transition plan / human-AI collaboration framing / skills retraining commitment] |
| **Environmental impact** | [What is the carbon cost of training and inference?] | [Measure and offset; prefer efficient architectures; use renewable-energy infrastructure where possible] |
| **Power concentration** | [Does this AI give the deploying organisation disproportionate power over individuals?] | [Ensure right to opt out; avoid lock-in; consider open alternatives] |
| **Information ecosystem** | [Could this AI contribute to misinformation, filter bubbles, or manipulation?] | [Provenance labelling / content policies / algorithmic diversity requirements] |
---
## 9. Mitigation Priorities
| # | Risk | Severity | Action | Owner | Deadline |
|---|---|---|---|---|---|
| 1 | [Highest risk — e.g. No disclosure to affected candidates] | Critical | [Add AI disclosure to UI and candidate-facing documentation] | [PM + Legal] | [Before launch] |
| 2 | [e.g. No fairness evaluation across demographic groups] | High | [Commission third-party fairness audit using [method]] | [ML team + external auditor] | [Within 30 days of launch] |
| 3 | [e.g. No model monitoring in place] | High | [Deploy performance and drift monitoring dashboard] | [ML Ops] | [Launch day] |
| 4 | [e.g. DPIA not completed] | High | [Complete DPIA with DPO before deployment] | [Legal / DPO] | [Before launch] |
---
## 10. Pre-Deployment Checklist
- [ ] Ethics review completed and approved by required reviewers
- [ ] DPIA completed (if required)
- [ ] Fairness evaluation completed and results documented
- [ ] AI disclosure is in place wherever required
- [ ] Human oversight mechanism is defined and tested
- [ ] Kill-switch and escalation path is documented and tested
- [ ] Model monitoring is deployed and alerting is configured
- [ ] Data lineage and training data audit documented
- [ ] Legal sign-off obtained on data licensing and cross-border transfers
- [ ] Incident response plan in place
---
## Quality Checks
- [ ] "Who is affected" includes people the AI makes decisions *about*, not just who uses the product
- [ ] Fairness analysis names specific protected characteristics, not just "diverse groups"
- [ ] Safety section covers both false positive and false negative failure modes
- [ ] Accountability section names real people, not teams or roles
- [ ] Mitigations are specific and time-bound — not "monitor and review"
## Example Trigger Phrases
- "Run an AI ethics review for [feature]"
- "Conduct an ethical impact assessment for our new ML model"
- "Review the AI risks for our hiring / credit / recommendation system"
- "Build a responsible AI checklist for our product"
- "What are the ethical risks of using AI for [use case]?"
plugins/pm-cs/skills/customer-success-plan/SKILL.md
+192
View File
@@ -0,0 +1,192 @@
---
name: customer-success-plan
description: "Build a joint customer success plan for a specific account. Use when asked to create a success plan, joint success plan, mutual action plan, or customer onboarding plan. Produces a structured success plan with business goals, milestones, success metrics, ownership, and a 90-180 day roadmap."
---
# Customer Success Plan Skill
This skill produces a joint customer success plan — a living document shared between the CSM and the customer that aligns on outcomes, milestones, and mutual commitments. Output is ready to co-author with the customer in a kickoff call or QBR.
## Required Inputs
Ask the user for these if not provided:
- **Account name** and industry
- **Product / plan purchased**
- **Key stakeholders** — customer champion and economic buyer
- **Customer's stated business goals** — why did they buy? What problem are they solving?
- **Contract term and renewal date**
- **Current onboarding stage** (new customer / expanding / post-QBR / pre-renewal)
- **Seats / licenses / usage purchased**
- **Any known risks** — adoption gaps, champion uncertainty, competing priorities
## Output Structure
---
# Customer Success Plan: [Account Name]
**Product:** [Product name / plan tier]
**Contract term:** [Start date → Renewal date]
**CSM:** [Name]
**Customer champion:** [Name, Title]
**Customer executive sponsor:** [Name, Title — if known]
**Last updated:** [Date]
**Status:** [Active / Under review / Completed]
---
## 1. Partnership Objectives
> *What does success look like for [Account Name] at contract end?*
[Write 2–3 sentences describing the customer's core objective in plain English — what they are trying to achieve in their business, not what features they are using.]
**Primary business goal:** [e.g. Reduce time-to-hire by 30% across engineering teams]
**Secondary goal:** [e.g. Consolidate three legacy tools into one platform, saving £X/year]
**Success statement (customer's words):** "[Direct quote from champion about what success looks like — ask for this in kickoff]"
---
## 2. Success Metrics
Define how both parties will measure success. Agreed in the kickoff call and tracked in QBRs.
| Metric | Baseline (today) | Target | By when | Data source |
|---|---|---|---|---|
| [e.g. Seat utilisation] | [X%] | [≥ 80%] | [Month 3] | [Product analytics] |
| [e.g. Time to hire] | [X days] | [< Y days] | [Month 6] | [Customer's ATS] |
| [e.g. Reports produced/month] | [X] | [≥ Y] | [Month 3] | [Product analytics] |
| [e.g. NPS] | [X] | [≥ 8] | [Month 6] | [Quarterly survey] |
**Leading indicators** (early signs the plan is on track):
- [e.g. 5+ users log in within the first 2 weeks]
- [e.g. First workflow automated within 30 days]
- [e.g. Champion presents the tool to their team by end of Month 1]
---
## 3. Milestone Roadmap
Break the success journey into phases with clear milestones and owners:
### Phase 1: Onboard (Month 1)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| Admin setup complete (SSO, permissions, data integration) | [IT contact] | [Date] | [ ] |
| All purchased seats activated and users invited | [Champion] | [Date] | [ ] |
| Core workflow [X] configured and tested | [CSM + Champion] | [Date] | [ ] |
| First training session delivered (all teams) | [CSM] | [Date] | [ ] |
| Kickoff call completed and success plan co-signed | [CSM + Champion] | [Date] | [ ] |
### Phase 2: Adopt (Months 2–3)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| [Core feature] in active daily use by ≥ X users | [Champion] | [Date] | [ ] |
| First business outcome achieved and documented | [Champion + CSM] | [Date] | [ ] |
| 30-day check-in completed | [CSM] | [Date] | [ ] |
| [Power user workflow] enabled for advanced users | [CSM] | [Date] | [ ] |
### Phase 3: Value (Months 4–6)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| QBR 1 delivered — ROI evidence presented | [CSM + AE] | [Date] | [ ] |
| Success metric [X] hit target | [Champion] | [Date] | [ ] |
| Expansion use case identified and introduced | [AE] | [Date] | [ ] |
| Reference call or case study agreed | [Champion] | [Date] | [ ] |
### Phase 4: Renew & Expand (Months 7–12)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| QBR 2 delivered — renewal conversation started | [CSM + AE] | [Date] | [ ] |
| Renewal proposal sent | [AE] | [Date] | [ ] |
| Expansion or flat renewal signed | [AE] | [Date] | [ ] |
---
## 4. Mutual Commitments
Success plans work when both parties commit. Document what each side will do:
**[Vendor] commits to:**
- Dedicated CSM available [X days/week / by email within 24 hours]
- Monthly [call / check-in / async update] with champion
- QBR every [90 days] with executive summary and ROI report
- Priority support for [Account] — response SLA of [X hours] for P1 issues
- Roadmap preview for relevant upcoming features
- [Any other specific commitment made in sales cycle]
**[Account Name] commits to:**
- Champion available for [30-min monthly] check-in
- Users complete onboarding training by [date]
- Feedback on product experience shared monthly (async or sync)
- Executive sponsor participates in QBR 1 and renewal discussion
- Provide outcome data to CSM quarterly for ROI tracking
---
## 5. Stakeholder Engagement Plan
| Stakeholder | Role | Engagement frequency | Format | Owner |
|---|---|---|---|---|
| [Champion] | Day-to-day owner | Weekly (async) + Monthly (call) | Slack / Email + Zoom | CSM |
| [Economic buyer] | Budget holder | Quarterly | QBR (in-person or video) | CSM + AE |
| [IT contact] | Integration owner | As needed | Email | CSM |
| [End users] | Active users | Training only | Group session | CSM |
---
## 6. Risk & Mitigation
| Risk | Likelihood | Impact | Mitigation plan |
|---|---|---|---|
| Low adoption in first 30 days | [M] | [H] | CSM hosts live onboarding; champion sends internal comms day 1 |
| Champion changes role | [L] | [H] | Multi-thread: introduce CSM to 2 additional stakeholders by Month 2 |
| Budget pressure at renewal | [M] | [H] | Build ROI case monthly; document value continuously |
| Competing priorities delay rollout | [H] | [M] | Agree minimum viable adoption path with champion; don't require perfection to declare value |
---
## 7. Communication Plan
| Communication | Audience | Frequency | Format | Owner |
|---|---|---|---|---|
| Health update | Champion | Monthly | Email summary (3 bullets: what's good, what needs attention, one ask) | CSM |
| QBR | Champion + Exec | Quarterly | 45-min video call with slide deck | CSM + AE |
| Product updates | Champion | As released | Release notes email | CSM |
| Support status | Champion | When open tickets exist | Email / Slack | Support + CSM |
---
## 8. Escalation Path
If the success plan falls off track:
| Trigger | Action | Owner | Timeline |
|---|---|---|---|
| Health drops to Amber | Internal review + champion call within 5 days | CSM | Immediate |
| Health drops to Red | CS leadership + AE looped in; escalation brief drafted | CS Manager | Within 24 hours |
| Champion is unresponsive for >10 days | AE attempts exec sponsor contact | AE | After CSM attempt fails |
| Adoption <40% at Month 3 | Emergency enablement session + revised milestone plan | CSM | Within 1 week of flag |
---
## Quality Checks
- [ ] Success metrics are the customer's metrics — not just product usage metrics
- [ ] Milestones have specific owners and due dates — not "TBD"
- [ ] Mutual commitments section is genuinely mutual — not just what the vendor will do
- [ ] Risk register includes champion departure and low adoption
- [ ] Plan is written to be shared with the customer — no internal-only commentary in this document
- [ ] Executive sponsor is identified and has an engagement role
## Example Trigger Phrases
- "Build a success plan for [Account Name] who just signed"
- "Create a joint success plan for our new enterprise customer"
- "Write a 6-month customer success roadmap for [Company]"
- "I need a mutual action plan for our QBR with [Account]"
- "Generate a customer success plan for an at-risk account"
plugins/pm-cs/skills/renewal-playbook/SKILL.md
+190
View File
@@ -0,0 +1,190 @@
---
name: renewal-playbook
description: "Build a structured renewal playbook for a customer account. Use when asked to plan a renewal, structure a renewal negotiation, prepare for an expansion conversation, or build a renewal strategy for at-risk or healthy accounts. Produces a renewal brief with health assessment, negotiation strategy, objection responses, expansion levers, and a timeline."
---
# Renewal Playbook Skill
This skill produces a complete renewal playbook for a specific customer account, covering health assessment, commercial strategy, negotiation preparation, expansion opportunity mapping, and a step-by-step timeline. Output is ready for the CSM or account team to execute 90–180 days before renewal.
## Required Inputs
Ask the user for these if not provided:
- **Account name**
- **Renewal date**
- **Current ARR** and proposed renewal ARR (if different)
- **Account health** — RAG status and main reasons (or describe the account situation)
- **Key stakeholders** — economic buyer, champion, and any detractors
- **Renewal risk factors** — budget pressure, low adoption, competitive threat, champion departure, etc.
- **Expansion opportunity** — any upsell or cross-sell potential?
- **Contract terms** — current plan, duration, and any terms up for renegotiation
## Output Structure
---
# Renewal Playbook: [Account Name]
**Renewal date:** [Date]
**Current ARR:** [£/$/€ X]
**Target renewal ARR:** [£/$/€ X — flat / +X% expansion / contraction risk]
**Health status:** [Green / Amber / Red]
**CSM:** [Name]
**Account executive:** [Name]
**Days to renewal:** [X days]
---
## 1. Account Health Snapshot
| Dimension | Score (1–5) | Evidence |
|---|---|---|
| **Product adoption** | [X/5] | [e.g. 3 of 5 purchased seats active; core feature used weekly] |
| **Business outcomes** | [X/5] | [e.g. Customer reports X% improvement in [metric]; no formal ROI review done] |
| **Relationship depth** | [X/5] | [e.g. Strong champion in [name/role]; limited exec sponsorship] |
| **Support & satisfaction** | [X/5] | [e.g. 2 open P2 tickets; last NPS 7; no escalations in 6 months] |
| **Commercial engagement** | [X/5] | [e.g. Invoice paid on time; no discount pressure raised yet] |
| **Overall health** | [X/5 — weighted] | [Green / Amber / Red] |
**Renewal thesis:** [One sentence: why this account will renew — or what must change for it to renew.]
---
## 2. Stakeholder Map
| Stakeholder | Role | Influence | Sentiment | Our relationship |
|---|---|---|---|---|
| [Name] | Economic buyer | High | [Positive / Neutral / Negative] | [Warm / Cold / Unknown] |
| [Name] | Champion | High | [Positive] | [Warm] |
| [Name] | End user | Low | [Neutral] | [Limited] |
| [Name] | IT / procurement | Medium | [Neutral] | [Transactional] |
**Champion risk:** [Is our champion secure in their role? Any signals of departure or reorganisation?]
**Multi-thread plan:** [Who else do we need relationships with before renewal? How do we get there?]
---
## 3. Risk Register
| Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation |
|---|---|---|---|
| [Budget pressure / cost-cutting] | [H] | [H] | [Build ROI case 90 days out; identify budget holder's priorities] |
| [Low adoption in [department]] | [M] | [H] | [Run targeted enablement session; tie to champion's OKRs] |
| [Competitor evaluation] | [M] | [M] | [Request competitive intelligence; schedule exec-level call] |
| [Champion departure] | [L] | [H] | [Map two additional stakeholders; executive intro call] |
---
## 4. Value Story
Build the ROI narrative for the renewal conversation:
**Headline result:** [e.g. "[Account] saved X hours/week or reduced [metric] by X% using [product]"]
**Evidence sources:**
- [ ] Product usage data (logins, features used, seat utilisation)
- [ ] Business metric improvement (pull from QBR deck or success plan)
- [ ] Support resolution time improvement
- [ ] Customer-provided testimonial or case study quotes
**Value gaps to close before renewal:** [Are there outcomes the customer expected but hasn't seen yet? What's the plan to close these?]
---
## 5. Expansion Opportunity
Map upside beyond flat renewal:
| Opportunity | Type | Estimated value | Likelihood | Timing |
|---|---|---|---|---|
| [Seat expansion — [dept] wants to add 10 users] | Upsell | [+£X ARR] | [High] | [Renewal or +3M] |
| [Cross-sell — [Product B] use case identified] | Cross-sell | [+£X ARR] | [Medium] | [+6M] |
| [Multi-year commitment] | Discount for term | [+£X TCV / -X% discount] | [Low] | [At renewal] |
**Expansion play:** [Which opportunity to lead with, and the sequence for raising it in the renewal conversation]
---
## 6. Commercial Strategy
**Renewal scenario planning:**
| Scenario | Probability | ARR outcome | Response strategy |
|---|---|---|---|
| **Flat renewal** | [X%] | [£X — same as current] | [Accept; plant seeds for +6M expansion] |
| **Expansion** | [X%] | [£X] | [Lead with ROI evidence; pitch seat or feature expansion] |
| **Contraction risk** | [X%] | [£X — downgrade to lower tier] | [Propose phased commitment; demonstrate path to full adoption] |
| **Churn risk** | [X%] | [£0] | [Escalate to leadership; executive sponsor engagement] |
**Discount guardrails:**
- Floor discount: [X% — do not go below without VP approval]
- Triggers for discount: [Multi-year / volume / reference customer commitment]
- What to ask for in return: [Reference case study / G2 review / executive intro / case study participation]
**Pricing flexibility:**
- [e.g. Can offer monthly billing in exchange for 24-month commit]
- [e.g. Can offer X seats free in exchange for expansion commitment]
---
## 7. Objection Responses
Prepare for the most likely objections:
**"The price is too high"**
> Anchor on value delivered: "[Customer] achieved [X outcome] — at [£X ARR], that's [£Y per outcome / hour saved / user]. What would it cost to deliver that outcome without us?"
> If budget is genuinely constrained, explore: phased payment, reduction in scope rather than full churn, multi-year pricing.
**"We're not seeing enough adoption"**
> Acknowledge, then commit: "You're right — [X seats] are actively using [core feature] out of [Y]. We want to fix this. Here's our 60-day plan: [exec sponsor on enablement call / training session / in-product nudge campaign]."
**"We're evaluating [Competitor]"**
> Don't panic. Ask: "What's driving the evaluation — is it specific features, pricing, or something else?" Then map gaps honestly. Offer a feature roadmap preview if relevant. Get clarity on their criteria and timeline before responding defensively.
**"We need to reduce spend this quarter"**
> Separate the commercial conversation from the value conversation. Offer to protect the relationship with a reduced scope today with a committed expansion trigger at a business milestone. Avoid discounting without a reason.
---
## 8. Renewal Timeline
| Week | Action | Owner | Notes |
|---|---|---|---|
| **W–16** (4 months out) | Internal renewal review — health, expansion opportunity, risk | CSM | Flag to leadership if Red |
| **W–12** | QBR / executive business review — ROI evidence delivered | CSM + AE | Book 45–60 min with economic buyer |
| **W–10** | Champion 1:1 — pulse check on satisfaction and upcoming priorities | CSM | Uncover internal dynamics before commercial discussion |
| **W–8** | Expansion conversation — plant seeds, share roadmap | AE | Do not lead with pricing |
| **W–6** | Send renewal proposal — pricing, terms, options | AE | Include multi-year option |
| **W–4** | Negotiation — address objections, finalise commercial terms | AE + CSM | Escalate to VP if >X% discount required |
| **W–2** | Legal / procurement — contract redlines, signature process | AE + Legal | |
| **W–0** | Signed. Handoff to post-renewal success plan | CSM | Thank the champion; begin next cycle |
---
## 9. Success Criteria
- [ ] Renewal signed before deadline
- [ ] ARR outcome within target range
- [ ] Champion relationship maintained or improved
- [ ] At least one expansion conversation started
- [ ] ROI evidence documented and accepted by customer
---
## Quality Checks
- [ ] Stakeholder map includes the economic buyer — not just the champion
- [ ] Risk register has a mitigation for every H/H risk
- [ ] Value story uses product data and business outcomes, not just feature lists
- [ ] Commercial strategy includes a floor discount and a reason-to-discount framework
- [ ] Timeline starts at least 90 days before renewal date
- [ ] Objection responses are specific to this account, not generic
## Example Trigger Phrases
- "Build a renewal playbook for [Account Name] renewing in [Month]"
- "Help me plan the renewal strategy for an at-risk customer"
- "Prepare a renewal brief for my QBR with [Company]"
- "What's my renewal strategy for a Red account coming up in 60 days?"
- "Create a renewal and expansion plan for [Account]"
plugins/pm-data/skills/cohort-analysis/SKILL.md
+187
View File
@@ -0,0 +1,187 @@
---
name: cohort-analysis
description: "Structure a cohort analysis for retention, LTV, or behavioural patterns. Use when asked to run a cohort analysis, analyse retention by cohort, segment users by behaviour over time, or calculate lifetime value by acquisition period. Produces a complete cohort analysis framework with methodology, cohort definitions, retention curves, and prioritised interventions."
---
# Cohort Analysis Skill
This skill produces a structured cohort analysis covering retention curves, LTV estimation, behavioural segmentation, and actionable interventions. Output is ready to present to product leadership or share with growth and data teams.
## Required Inputs
Ask the user for these if not provided:
- **Analysis goal** (retention improvement / LTV modelling / behavioural segmentation / churn prediction)
- **Product or feature being analysed**
- **Cohort definition** — what groups users? (acquisition month, signup channel, plan tier, feature adoption)
- **Observation window** — how many periods to track? (e.g. 12 months, 8 weeks)
- **Key metric** — what are you measuring per cohort? (retention rate, revenue, engagement score, feature usage)
- **Available data** — what tables/metrics are available? (paste schema or describe)
- **Baseline** — any existing retention benchmarks or goals?
## Output Structure
---
# Cohort Analysis: [Product / Feature]
**Analysis type:** [Retention / LTV / Behavioural / Churn]
**Cohort definition:** [Acquisition month / Signup channel / Plan tier / Feature adoption date]
**Observation window:** [X months / weeks]
**Primary metric:** [Metric name]
**Date prepared:** [Date]
---
## 1. Cohort Definitions
| Cohort | Period | Size | Description |
|---|---|---|---|
| [Cohort 1] | [Jan 2025] | [N users] | [e.g. Users who signed up in Jan 2025 via organic] |
| [Cohort 2] | [Feb 2025] | [N users] | [...] |
**Cohort logic:**
- Cohort entry event: [First sign-up / First purchase / Feature activation]
- Cohort exit criteria: [Churned / Downgraded / No activity for 30 days]
- Exclusions: [Trial users / Internal test accounts / Users with < X days of data]
---
## 2. Retention Curve
**How to read:** Each cell shows what % of the cohort performed the key metric in period N.
| Cohort | Period 0 | Period 1 | Period 2 | Period 3 | Period 6 | Period 12 |
|---|---|---|---|---|---|---|
| Jan 2025 | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
| Feb 2025 | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
| [Trend] | — | [↑/↓ vs prior] | [...] | [...] | [...] | [...] |
**Retention plateau:** [At what period does retention flatten? What % does it flatten at?]
**Key observations:**
- [e.g. Period 1 → Period 2 drop is the largest — average X% churn in first 30 days]
- [e.g. Cohorts acquired via [channel] retain X% better at Period 6]
- [e.g. Retention has improved from X% → Y% at Period 3 comparing oldest to newest cohort]
---
## 3. LTV Projection (if applicable)
**ARPU per period:** [£/$/€ X per active user per month]
**Retention curve used:** [Which cohort or blended average]
| Period | Retained % | Revenue per user | Cumulative LTV |
|---|---|---|---|
| Month 1 | [X%] | [£X] | [£X] |
| Month 3 | [X%] | [£X] | [£X] |
| Month 6 | [X%] | [£X] | [£X] |
| Month 12 | [X%] | [£X] | [£X] |
**Blended LTV:** [£X at 12 months — based on blended retention across cohorts]
**LTV by segment:**
| Segment | LTV (12M) | vs Baseline |
|---|---|---|
| [Organic] | [£X] | [+X%] |
| [Paid] | [£X] | [-X%] |
| [Enterprise] | [£X] | [+X%] |
---
## 4. Behavioural Segmentation
Group cohorts by behaviour patterns, not just acquisition date:
| Segment | Definition | Size | Retention (P6) | LTV (12M) |
|---|---|---|---|---|
| **Power users** | [Used core feature ≥ 3x/week in first 30 days] | [X%] | [X%] | [£X] |
| **Casual users** | [Used 1–2x/week in first 30 days] | [X%] | [X%] | [£X] |
| **Dormant** | [Logged in but did not use core feature] | [X%] | [X%] | [£X] |
| **Never activated** | [Signed up but never completed onboarding] | [X%] | [X%] | [£X] |
**Activation threshold insight:** [What action — taken within the first X days — most strongly predicts retention? This is the "aha moment" to optimise for.]
---
## 5. Leading Indicators of Churn
List the signals that appear **before** users churn, so teams can intervene:
| Signal | How early does it appear? | Churn correlation | Intervention |
|---|---|---|---|
| [No login for 7 days] | [7 days before churn] | [Strong] | [Re-engagement email sequence] |
| [Support ticket with escalation] | [14 days before churn] | [Moderate] | [CSM outreach within 48 hours] |
| [Feature usage dropped >50% WoW] | [10 days before churn] | [Strong] | [In-app nudge with use-case tutorial] |
---
## 6. Cohort Comparison: What's Changed Over Time
Compare oldest and newest cohorts to assess whether product improvements are showing up in retention:
| Metric | [Oldest cohort — e.g. Jan 2024] | [Newest cohort — e.g. Jan 2025] | Change |
|---|---|---|---|
| Period 1 retention | [X%] | [X%] | [↑/↓ X pp] |
| Period 3 retention | [X%] | [X%] | [↑/↓ X pp] |
| Activation rate | [X%] | [X%] | [↑/↓ X pp] |
| Avg. sessions in first 30 days | [X] | [X] | [↑/↓] |
**Verdict:** [Are more recent cohorts performing better or worse? What shipped in that period that might explain the change?]
---
## 7. Recommendations
Prioritise by impact on retention curve:
| # | Recommendation | Target segment | Expected impact | Effort | Priority |
|---|---|---|---|---|---|
| 1 | [e.g. Redesign onboarding to hit activation milestone in day 1, not day 7] | [Never-activated segment] | [+X pp P1 retention] | [Medium] | P1 |
| 2 | [e.g. Launch re-engagement sequence at day 7 inactivity trigger] | [Dormant segment] | [+X pp P2 retention] | [Low] | P1 |
| 3 | [e.g. Introduce power-user features earlier to accelerate habit formation] | [Casual users] | [+X pp P6 LTV] | [High] | P2 |
---
## 8. SQL Reference (if applicable)
Provide the core cohort query so data teams can replicate or extend the analysis:
```sql
-- Retention cohort query
SELECT
DATE_TRUNC('month', u.created_at) AS cohort_month,
DATE_TRUNC('month', e.event_date) AS activity_month,
DATEDIFF('month', u.created_at, e.event_date) AS period,
COUNT(DISTINCT e.user_id) AS retained_users,
COUNT(DISTINCT c.user_id) AS cohort_size,
ROUND(COUNT(DISTINCT e.user_id) * 100.0 / COUNT(DISTINCT c.user_id), 1) AS retention_rate
FROM users u
JOIN events e ON u.user_id = e.user_id
JOIN (
SELECT user_id, DATE_TRUNC('month', created_at) AS cohort_month
FROM users
WHERE created_at >= '[start_date]'
) c ON u.user_id = c.user_id AND DATE_TRUNC('month', u.created_at) = c.cohort_month
WHERE e.event_type = '[key_retention_event]'
GROUP BY 1, 2, 3
ORDER BY 1, 3;
```
---
## Quality Checks
- [ ] Cohort definition is unambiguous — the same user cannot appear in two cohorts
- [ ] Retention curve shows a clear plateau, or the analysis notes that the window is too short to see one
- [ ] LTV projection uses observed retention, not assumed
- [ ] Behavioural segments are mutually exclusive and exhaustive
- [ ] Recommendations are tied to specific cohort or segment findings — not generic growth advice
- [ ] Leading indicators are observable in production data, not just in theory
## Example Trigger Phrases
- "Run a cohort analysis for our SaaS product"
- "Analyse retention by acquisition month for the last 12 cohorts"
- "What's the LTV of users who came via paid vs organic?"
- "Build a cohort retention model showing period 0 through period 12"
- "Segment users by behaviour and show me which group retains best"
plugins/pm-data/skills/data-pipeline-spec/SKILL.md
+221
View File
@@ -0,0 +1,221 @@
---
name: data-pipeline-spec
description: "Design an ETL/ELT data pipeline specification. Use when asked to design a data pipeline, spec an ETL or ELT process, document a data ingestion workflow, or plan a data integration. Produces a complete pipeline spec with sources, transforms, destinations, SLAs, error handling, and data quality rules."
---
# Data Pipeline Spec Skill
This skill produces a complete data pipeline specification covering sources, transformations, destinations, scheduling, SLAs, error handling, data quality checks, and monitoring requirements. Output is ready for engineering handoff or architecture review.
## Required Inputs
Ask the user for these if not provided:
- **Pipeline purpose** — what business question or workflow does this pipeline serve?
- **Source systems** — where does data come from? (databases, APIs, files, event streams)
- **Destination** — where does data land? (data warehouse, data lake, downstream DB, reporting tool)
- **Transformation type** — ETL (transform before loading) or ELT (load raw, transform in warehouse)?
- **Frequency / SLA** — how often must data be fresh? (real-time / hourly / daily / weekly)
- **Volume estimate** — approximate rows/events per run
- **Data quality requirements** — completeness, deduplication, freshness, schema enforcement
- **Team or stack** — any specific tools in use? (Airflow, dbt, Fivetran, Spark, Kafka, etc.)
## Output Structure
---
# Data Pipeline Spec: [Pipeline Name]
**Purpose:** [One sentence — what decision or workflow does this pipeline enable?]
**Type:** [ETL / ELT / Streaming / Batch]
**Owner:** [Team or individual]
**Version:** [1.0]
**Date:** [Date]
**Status:** [Draft / Under Review / Approved]
---
## 1. Overview
[2–3 sentences describing the pipeline end-to-end: what data moves, from where to where, at what cadence, and why.]
**Architecture diagram (text):**
```
[Source A] ──┐
[Source B] ──┤──► [Ingestion Layer] ──► [Transform Layer] ──► [Destination] ──► [Consumers]
[Source C] ──┘
```
---
## 2. Sources
| Source | System | Connection type | Data format | Update pattern | Volume |
|---|---|---|---|---|---|
| [Source 1] | [PostgreSQL / Salesforce / S3 / Kafka] | [JDBC / REST API / SDK / Webhook] | [JSON / CSV / Parquet / CDC] | [Append / Full refresh / Incremental] | [X rows/day] |
| [Source 2] | [...] | [...] | [...] | [...] | [...] |
**Incremental key (if applicable):** [The column used to identify new or changed records — e.g. `updated_at`, `event_id`]
**Authentication:** [API key / OAuth / IAM role / connection string — note where credentials are stored]
---
## 3. Ingestion Layer
**Tool:** [Fivetran / Airbyte / Kafka Connect / custom script / dbt source]
**Ingestion method:**
- [ ] Full extract (full table refresh each run)
- [ ] Incremental extract (only new/changed rows since last run)
- [ ] CDC (change data capture from database transaction log)
- [ ] Event streaming (continuous ingestion from Kafka/Kinesis)
**Raw landing zone:** [Where raw data lands before transformation — e.g. `raw.salesforce_opportunities` in Snowflake, S3 bucket `s3://data-raw/crm/`]
**Schema handling:** [Strict schema enforcement / Schema evolution allowed / Union schema]
---
## 4. Transformation Logic
List each transformation in execution order. For ELT pipelines, this is the dbt model or SQL layer.
| Step | Name | Description | Input | Output | Tool |
|---|---|---|---|---|---|
| 1 | [Deduplicate events] | [Remove duplicate event rows based on event_id] | `raw.events` | `staging.events_deduped` | [dbt / SQL / Spark] |
| 2 | [Join user profile] | [Enrich events with user attributes from CRM] | `staging.events_deduped`, `raw.users` | `staging.events_enriched` | [...] |
| 3 | [Aggregate to daily] | [Roll up to user×day grain] | `staging.events_enriched` | `mart.user_daily_activity` | [...] |
**Business logic rules:**
- [e.g. Revenue is recognised on `payment_confirmed_at`, not `payment_initiated_at`]
- [e.g. Users in the `internal@company.com` domain are excluded from all metrics]
- [e.g. Currency conversion uses the ECB rate from the first business day of each month]
**Slowly Changing Dimensions (SCD) — if applicable:**
- [e.g. `users.plan_tier` is SCD Type 2 — keep history of plan changes with `valid_from` / `valid_to`]
---
## 5. Destination
| Destination | System | Schema / Table | Write mode | Consumers |
|---|---|---|---|---|
| [Primary] | [Snowflake / BigQuery / Redshift / PostgreSQL] | [`analytics.mart_user_activity`] | [Append / Upsert / Full replace] | [Looker / Metabase / downstream pipeline] |
| [Secondary] | [...] | [...] | [...] | [...] |
**Partitioning / Clustering:** [e.g. Partitioned by `event_date`, clustered by `user_id` — reduces query cost for time-range scans]
**Retention policy:** [e.g. Raw data retained for 90 days; mart tables retained indefinitely]
---
## 6. Scheduling & SLAs
| SLA | Target | Breach action |
|---|---|---|
| **Data freshness** | [Data must be ≤ X hours old by HH:MM UTC] | [Page on-call / alert Slack channel] |
| **Pipeline completion** | [Must complete within X minutes of trigger] | [Alert and auto-retry] |
| **Availability** | [Pipeline must run successfully X% of days per month] | [Incident review] |
**Schedule:** [Cron expression and human description — e.g. `0 6 * * *` — daily at 06:00 UTC]
**Trigger type:**
- [ ] Time-based (cron)
- [ ] Event-based (triggered by upstream pipeline success / file arrival / Kafka lag)
- [ ] Manual (ad hoc runs only)
**Backfill strategy:** [How to reprocess historical data if the pipeline fails or logic changes — e.g. parameterised date range, full drop-and-reload]
---
## 7. Data Quality Rules
| Check | Table | Rule | Failure action |
|---|---|---|---|
| Completeness | `staging.events` | `event_id IS NOT NULL` — 100% of rows | Block load / Alert |
| Uniqueness | `mart.user_daily_activity` | `(user_id, date)` must be unique | Block load |
| Freshness | `mart.user_daily_activity` | `max(event_date) >= CURRENT_DATE - 1` | Alert |
| Volume | `staging.events` | Row count within ±20% of 7-day average | Alert |
| Referential integrity | `staging.events` | All `user_id` values exist in `users` table | Alert |
**DQ tool:** [dbt tests / Great Expectations / Monte Carlo / custom SQL assertions]
---
## 8. Error Handling & Recovery
**Retry policy:** [e.g. 3 retries with exponential back-off: 5 min, 20 min, 60 min]
**Failure modes and responses:**
| Failure | Detection | Response | Owner |
|---|---|---|---|
| Source unavailable | HTTP 5xx / connection timeout | Retry 3×, then alert and skip run | Data engineering |
| Schema change in source | Column missing or type mismatch | Block load, alert schema owner | Data owner + engineering |
| DQ check fails | dbt test failure / assertion error | Block load for P1 checks; alert for P2 | Data engineering |
| Partial load | Row count < expected threshold | Alert; do not publish to consumers until resolved | Data engineering |
**Dead-letter queue:** [Where failed records are routed for manual inspection — e.g. `raw.dlq_events`]
---
## 9. Monitoring & Observability
**Metrics to track:**
- Pipeline run duration (p50, p95)
- Rows processed per run
- DQ check pass rate
- Source freshness lag
- Error rate per source
**Alerting:**
- [Slack channel: #data-alerts]
- [PagerDuty: data-on-call escalation for P1 SLA breaches]
- [Dashboard: [link to monitoring dashboard]]
**Logging:** [What gets logged and where — e.g. Airflow task logs to CloudWatch, structured JSON to data lake]
---
## 10. Dependencies & Sequencing
**Upstream dependencies:** [Which pipelines or data sources must succeed before this pipeline runs?]
**Downstream dependents:** [Which dashboards, pipelines, or models depend on this pipeline's output?]
```
[upstream pipeline A] ──► THIS PIPELINE ──► [downstream dashboard B]
└──► [downstream pipeline C]
```
**Coordination mechanism:** [Airflow DAG dependency / dbt ref() / event trigger / manual gate]
---
## 11. Security & Compliance
- **PII fields:** [List columns containing PII — e.g. `email`, `ip_address`, `name`]
- **Masking / Pseudonymisation:** [e.g. email hashed with SHA-256 before landing in mart layer]
- **Access control:** [Who can query the destination tables? — e.g. Role-based access in Snowflake]
- **Data residency:** [Which regions is data permitted to transit and rest in?]
- **Audit trail:** [Is pipeline execution auditable for compliance purposes? Where are logs retained?]
---
## Quality Checks
- [ ] Every source has an incremental key or full-refresh justification
- [ ] Business logic rules are documented, not just the SQL
- [ ] SLAs are agreed with consumers, not set unilaterally by engineering
- [ ] DQ checks cover completeness, uniqueness, freshness, and volume
- [ ] Failure modes include a documented recovery owner
- [ ] PII fields are identified and a treatment plan is specified
## Example Trigger Phrases
- "Design a data pipeline for our Salesforce to Snowflake sync"
- "Write a pipeline spec for ingesting Stripe events into our data warehouse"
- "Build an ETL spec for our user activity data"
- "Document our dbt pipeline from raw events to the analytics mart"
- "Spec out the pipeline that feeds the executive dashboard"
plugins/pm-delivery/skills/user-story-writer/SKILL.md
+218
View File
@@ -0,0 +1,218 @@
---
name: user-story-writer
description: "Write well-structured user stories with acceptance criteria and edge cases. Use when asked to write user stories, create tickets from a feature brief, convert a PRD into stories, or write acceptance criteria. Produces ready-to-estimate stories in the standard format with clear acceptance criteria, edge cases, and definition of done."
---
# User Story Writer Skill
This skill produces production-ready user stories from a feature brief, PRD section, or verbal description. Each story follows the standard format with a clear who/what/why, behavioural acceptance criteria in Given/When/Then format, edge cases, and definition of done. Output is ready to paste into Jira, Linear, or your planning tool.
## Required Inputs
Ask the user for these if not provided:
- **Feature or change** to break into stories — paste the brief, PRD section, or describe the feature
- **User types / personas** involved (e.g. admin, end user, guest, API consumer)
- **Scope** — are we writing one story or decomposing an epic into a full set of stories?
- **Acceptance criteria format preference** — Given/When/Then, bullet checklist, or both?
- **Technical constraints or notes** — anything the engineering team has flagged that should shape the stories
## Output Structure
For each story:
---
## Story: [Short title — verb + noun, e.g. "Filter search results by date range"]
**Epic:** [Parent epic name — e.g. "Advanced Search"]
**Story ID:** [Jira/Linear ID — leave blank if not yet created]
**Priority:** [P1 / P2 / P3]
**Story points:** [Leave blank — for engineering to estimate]
---
### User Story
> **As a** [specific user type — not "user"],
> **I want to** [concrete action they want to take],
> **So that** [the outcome they achieve — business value, not feature description].
**Example:**
> As an **account manager**,
> I want to **filter my client list by last contact date**,
> so that I **can quickly identify clients I haven't spoken to in over 30 days and prioritise outreach**.
---
### Context
[1–3 sentences of context that aren't in the user story itself: when does this story matter, what triggers the need, how does it fit into a larger flow. This helps engineers understand why before they ask.]
---
### Acceptance Criteria
**Format: Given / When / Then**
Each criterion tests one specific behaviour. Write one GWT per observable outcome — not one GWT for the whole feature.
**AC1: [Short name for this criterion]**
```
Given [starting state or context]
When [user action]
Then [observable system behaviour]
```
**AC2: [Short name]**
```
Given [...]
When [...]
Then [...]
```
**AC3: [Short name]**
```
Given [...]
When [...]
Then [...]
```
---
### Edge Cases
[List scenarios that are non-obvious but must be handled. These become additional ACs or notes to engineering.]
- [ ] **[Edge case 1]:** [e.g. User applies a date filter that returns 0 results — show empty state with clear messaging and a "clear filters" action]
- [ ] **[Edge case 2]:** [e.g. User has >10,000 clients — filter must not degrade load time >200ms]
- [ ] **[Edge case 3]:** [e.g. Date filter persists across page refresh — or explicitly should not if that's the decision]
- [ ] **[Permission edge case]:** [e.g. Read-only users can see the filter but cannot save filter presets]
---
### Out of Scope
[Explicitly state what this story does NOT cover — prevents scope creep and clarifies where the next story begins.]
- Saving and sharing filter presets (separate story — see [Story X])
- Bulk actions on filtered results
- Exporting filtered client list to CSV
---
### Definition of Done
- [ ] Acceptance criteria all pass
- [ ] Edge cases handled (or explicitly deferred with a new ticket raised)
- [ ] Unit tests written for each AC
- [ ] Works on mobile viewport (if applicable)
- [ ] Accessibility: keyboard navigable and screen-reader compatible
- [ ] Error states are handled and copy approved
- [ ] Product and design have reviewed in staging
- [ ] No console errors in production build
---
## Epic Decomposition Template
If the user provides an epic or feature brief, decompose it into a full set of stories before writing them:
**Epic:** [Name]
**Goal:** [What outcome does completing this epic achieve?]
**Stories:**
| # | Story | Notes | Dependencies |
|---|---|---|---|
| 1 | [Core happy path story — the simplest version of the feature that delivers value] | | |
| 2 | [Validation / error handling story] | | Depends on #1 |
| 3 | [Edge case or power user story] | | Depends on #1 |
| 4 | [Admin or configuration story] | | |
| 5 | [Performance or scale story — if applicable] | | Depends on #1 |
**Suggested sprint order:** [Which stories are P1 for MVP? Which can follow in a later sprint?]
---
## Common Story Anti-Patterns — and Fixes
Use these to review stories before handing to engineering:
| Anti-pattern | Example | Fix |
|---|---|---|
| **Solution in the story** | "As a user I want a dropdown filter" | Remove the UI decision — "As a user I want to filter by date range" |
| **Vague "so that"** | "so that it's easier to use" | Make it specific — "so that I can prioritise outreach without opening each record manually" |
| **Too big** | Story covers 5 distinct user flows | Split into separate stories per flow |
| **No acceptance criteria** | Story has description only | Add at least 3 GWT criteria before engineering starts |
| **ACs that test the solution, not the behaviour** | "Given the dropdown is open, When I select an option" | Test the outcome — "Given I have applied a date filter, When I view my results, Then only clients last contacted in that date range appear" |
| **Missing empty state** | No AC for what happens with 0 results | Add it — empty states are part of the feature |
| **Missing error state** | No AC for network failure or invalid input | Add error handling ACs explicitly |
---
## Example: Full Story Set for a Feature
**Feature brief:** "Allow users to export their invoice history as a PDF or CSV"
---
### Story 1: Export invoice list as CSV
> As a **finance admin**,
> I want to **export my invoice history as a CSV file**,
> so that I can **import it into our accounting software without manual data entry**.
**AC1: Successful export**
```
Given I am on the Invoices page with at least one invoice
When I click "Export" and select "CSV"
Then a CSV file is downloaded containing all visible invoices with columns: Invoice ID, Date, Amount, Status, Customer Name
```
**AC2: Empty state**
```
Given I am on the Invoices page with no invoices
When I click "Export"
Then the export button is disabled and a tooltip reads "No invoices to export"
```
**AC3: Filtered export**
```
Given I have applied a date filter showing invoices from Jan 2026 only
When I click "Export" and select "CSV"
Then the export contains only invoices from Jan 2026 — not all invoices
```
**Edge cases:**
- [ ] Export with >10,000 invoices — must complete in <30s or show a progress indicator
- [ ] Export triggered on mobile — downloads to device's default download location
**Out of scope:** PDF export (Story 2), scheduled exports (future epic)
---
### Story 2: Export invoice list as PDF
> As a **finance admin**,
> I want to **export my invoice history as a formatted PDF**,
> so that I can **share a professional summary with our accountant**.
[... ACs follow same pattern ...]
---
## Quality Checks
- [ ] Every story has a specific user type — not "a user" or "the system"
- [ ] The "so that" explains business value — not just feature description
- [ ] Each AC tests one observable outcome — not a bundle of behaviours
- [ ] Empty states, error states, and edge cases are explicitly handled
- [ ] Out of scope is documented — not assumed
- [ ] Stories are independent — they can be shipped individually without depending on unreleased work (except where explicitly noted)
## Example Trigger Phrases
- "Write user stories for [feature] from this brief"
- "Break this PRD section into user stories with acceptance criteria"
- "Convert these feature requirements into Jira tickets"
- "Write the user stories and ACs for [feature name]"
- "Decompose this epic into individual stories ready for sprint planning"
plugins/pm-design/skills/design-system-audit/SKILL.md
+215
View File
@@ -0,0 +1,215 @@
---
name: design-system-audit
description: "Audit a design system for consistency, coverage, and quality. Use when asked to audit a design system, review a component library, assess design token coverage, or evaluate the health of a shared design system. Produces a structured audit with a health score, component coverage gaps, token inconsistencies, accessibility issues, and a prioritised remediation roadmap."
---
# Design System Audit Skill
This skill produces a structured audit of a design system — covering component coverage, token consistency, documentation quality, accessibility compliance, contribution processes, and adoption health. Output is ready for a design system team, design leadership, or an engineering team evaluating their shared component library.
## Required Inputs
Ask the user for these if not provided:
- **Design system name** and what product(s) it serves
- **Audit scope** — component library / design tokens / documentation / contribution process / all of the above
- **Current tooling** — Figma / Storybook / Zeroheight / custom / combination?
- **Team using it** — how many designers and engineers, how many products?
- **Known pain points** — what do teams complain about most?
- **Governance model** — centralised team / federated contributors / no dedicated team?
- **Goal of the audit** — improve adoption / prepare for a rebrand / onboard new teams / justify investment?
## Output Structure
---
# Design System Audit: [System Name]
**Products served:** [List of products / apps]
**Audit scope:** [Full / Components only / Tokens only / Documentation]
**Auditor:** [Name / Team]
**Date:** [Date]
**Stakeholders:** [Design lead, Eng lead, CPO, etc.]
---
## Overall Health Score
| Dimension | Score (1–5) | Status |
|---|---|---|
| Component coverage | [X/5] | 🟢/🟡/🔴 |
| Token consistency | [X/5] | 🟢/🟡/🔴 |
| Documentation quality | [X/5] | 🟢/🟡/🔴 |
| Accessibility compliance | [X/5] | 🟢/🟡/🔴 |
| Adoption rate | [X/5] | 🟢/🟡/🔴 |
| Contribution process | [X/5] | 🟢/🟡/🔴 |
| **Overall** | **[X/5]** | 🟢/🟡/🔴 |
**Summary:** [2–3 sentences. What is the overall state of the design system? What are the top 2 issues and what is the biggest strength?]
---
## 1. Component Coverage Audit
**How to assess:** Compare components in the design system against the actual UI patterns in the product. Every pattern that exists in production but not in the system is a coverage gap.
### Component Inventory
| Category | Components present | Coverage | Gap |
|---|---|---|---|
| **Navigation** | [Navbar, Sidebar, Breadcrumb, Tabs] | [80%] | [Missing: Mega menu, mobile drawer] |
| **Forms & Inputs** | [Text input, Dropdown, Checkbox, Radio, Toggle, Date picker] | [90%] | [Missing: Multi-select, Rich text editor] |
| **Feedback & Alerts** | [Toast, Banner, Modal, Tooltip] | [60%] | [Missing: Inline validation, Progress indicator, Skeleton loader] |
| **Data Display** | [Table, Card, Badge, Avatar] | [50%] | [Missing: Data grid, Stat card, Timeline, Gantt] |
| **Layout** | [Grid, Container, Divider, Spacer] | [70%] | [Missing: Responsive breakpoint utilities] |
| **Buttons & Actions** | [Button, Icon button, FAB, Link] | [100%] | [None] |
**Coverage score:** [X% of production UI patterns are covered by the design system]
**Most impactful gaps:**
1. [Most used pattern not in the system — causing most duplication]
2. [...]
3. [...]
---
## 2. Component Quality Audit
For each component, assess against these quality criteria:
| Component | States complete | Responsive | Accessibility | Dark mode | Props documented | Code matches Figma |
|---|---|---|---|---|---|---|
| Button | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Modal | ⚠️ Loading state missing | ✅ | ✅ | ❌ | ⚠️ Partial | ✅ |
| Table | ❌ Sorting state missing | ❌ No mobile layout | ⚠️ No aria-sort | ❌ | ❌ | ⚠️ Drift |
| [Component] | [...] | [...] | [...] | [...] | [...] | [...] |
**Legend:** ✅ Complete — ⚠️ Partial / inconsistent — ❌ Missing
**Components with critical quality issues (fix before anything else):**
- [Component name]: [Specific issue and why it's blocking]
- [...]
---
## 3. Design Token Audit
**Token coverage:**
| Token type | Defined | Used consistently | Issues |
|---|---|---|---|
| **Colour** | [X tokens defined] | [⚠️ — 12 hardcoded hex values found in Figma] | [Inconsistent use of primary-500 vs primary-600 for CTAs across products] |
| **Typography** | [X tokens defined] | [✅] | [None — all type styles use token scale] |
| **Spacing** | [X tokens defined] | [⚠️ — custom spacing used in X components] | [Engineers using arbitrary px values instead of spacing tokens in X components] |
| **Border radius** | [X tokens defined] | [❌ — not defined; each component has hardcoded values] | [Button, card, modal all use different radius values with no token] |
| **Shadow / elevation** | [X tokens defined] | [⚠️] | [3 different drop-shadow values in use; no elevation scale] |
| **Animation / motion** | [X tokens defined] | [❌ — not defined] | [Transition durations inconsistent across components] |
**Semantic token layer:** [Does the system have semantic tokens (e.g. `color.action.primary` on top of `color.blue.500`) or only primitive tokens?]
**Token drift:** [Are code tokens and Figma tokens in sync? Use a tool like Token Studio, Style Dictionary, or manual comparison.]
---
## 4. Documentation Quality Audit
**Assessment per component / pattern:**
| Document type | Quality | Issues |
|---|---|---|
| **Usage guidelines** | [⚠️ — X% of components have guidelines] | [Button and Form components documented; Navigation and Data Display mostly undocumented] |
| **Do / Don't examples** | [❌ — mostly absent] | [Engineers frequently misuse components because intent is unclear] |
| **Accessibility notes** | [⚠️ — present for some components] | [No consistent format; accessibility notes missing for interactive components] |
| **Code examples** | [✅ — all Storybook components have code examples] | [...] |
| **Changelog** | [❌ — no component-level changelog exists] | [Breaking changes are not communicated; causes unexpected UI regressions] |
| **Migration guides** | [❌ — absent] | [Teams don't know how to upgrade to new component versions] |
**Documentation score:** [X% of components have complete, usable documentation]
**Most common designer / engineer complaint about docs:** [e.g. "I can't find whether to use Modal or Drawer for this use case — no guidance exists"]
---
## 5. Accessibility Audit
**WCAG 2.2 compliance status:**
| Criterion | Level | Status | Components affected |
|---|---|---|---|
| Colour contrast (text) | AA | [✅ / ⚠️ / ❌] | [e.g. ❌ — Disabled state text fails 4.5:1 ratio in 3 components] |
| Colour contrast (UI components) | AA | [✅ / ⚠️ / ❌] | [...] |
| Keyboard navigation | AA | [✅ / ⚠️ / ❌] | [⚠️ — Modal focus trap not implemented; Dropdown not keyboard accessible] |
| Focus visible | AA | [✅ / ⚠️ / ❌] | [...] |
| Screen reader support (ARIA) | AA | [✅ / ⚠️ / ❌] | [❌ — Table component lacks aria-sort; Icon buttons have no aria-label] |
| Touch target size | AA | [✅ / ⚠️ / ❌] | [⚠️ — Mobile tap targets below 44×44px in X components] |
| Motion / animation | AA | [✅ / ⚠️ / ❌] | [...] |
**Critical accessibility blockers (must fix before next release):**
1. [Most critical issue — e.g. Keyboard users cannot close Modal — focus trap missing]
2. [...]
---
## 6. Adoption Audit
**Adoption by team / product:**
| Product / Team | Components used from system | Custom components built outside system | Adoption score |
|---|---|---|---|
| [Product A] | [X% of UI uses system components] | [Y custom components] | [High / Medium / Low] |
| [Product B] | [...] | [...] | [...] |
**Why teams are not adopting:**
| Barrier | Severity | Evidence |
|---|---|---|
| [Component doesn't exist] | High | [Top reason in team survey] |
| [Component exists but doesn't meet use case] | Medium | [Modal component lacks X state needed by Product B] |
| [Documentation too sparse to know how to use it] | Medium | [...] |
| [No one enforces system use — easier to build custom] | High | [...] |
| [System is out of date with product's current visual language] | Medium | [...] |
---
## 7. Contribution Process Audit
| Dimension | Current state | Assessment |
|---|---|---|
| **How to contribute** | [Documented / Not documented] | [✅ / ❌] |
| **Contribution criteria** | [Clear entry bar for what goes in the system] | [⚠️ — unclear who decides what becomes a system component vs stays local] |
| **Review process** | [Who reviews contributions and how long it takes] | [❌ — no formal review; contributions sit unreviewed for weeks] |
| **Release cadence** | [How often system releases happen] | [⚠️ — sporadic; no set cadence] |
| **Breaking change policy** | [How breaking changes are handled and communicated] | [❌ — no policy; breaking changes are a surprise] |
| **Versioning** | [Semantic versioning in place?] | [✅ — all packages use semver] |
---
## 8. Prioritised Remediation Roadmap
| Priority | Initiative | Impact | Effort | Timeline |
|---|---|---|---|---|
| P1 | Fix [X] critical accessibility issues (keyboard nav, ARIA) | Critical — legal + user impact | Medium | Sprint 1–2 |
| P1 | Define and implement border radius and shadow token scale | High — ends inconsistency | Low | Sprint 1 |
| P1 | Document top 10 most-used components (usage + do/don't) | High — unblocks adoption | Medium | Sprint 2–4 |
| P2 | Build Skeleton loader + Inline validation components (top 2 gaps) | High — eliminates custom duplication | High | Quarter 2 |
| P2 | Establish contribution process with SLA for reviews | Medium — enables growth | Low | Sprint 3 |
| P3 | Dark mode token support | Medium — product parity | High | Quarter 3 |
| P3 | Design-code token sync tooling (Token Studio / Style Dictionary) | Medium — reduces drift | Medium | Quarter 2–3 |
---
## Quality Checks
- [ ] Coverage gaps are identified by comparing the design system to actual production UI, not assumed
- [ ] Accessibility issues cite specific WCAG criterion and affected components
- [ ] Adoption barriers are backed by evidence (interviews, survey, usage data) — not assumed
- [ ] Remediation roadmap has effort estimates and is sequenced by impact
- [ ] Both Figma and code (Storybook/implementation) are assessed — not just Figma
- [ ] Stakeholders from design, engineering, and product have reviewed the audit
## Example Trigger Phrases
- "Audit our design system for consistency and coverage"
- "Review our component library and identify gaps"
- "Assess the health of our shared design system"
- "Run a design system audit before we do a rebrand"
- "What's wrong with our design system and what should we fix first?"
plugins/pm-discovery/skills/customer-journey-map/SKILL.md
+215
View File
@@ -0,0 +1,215 @@
---
name: customer-journey-map
description: "Build a customer journey map for a product, service, or experience. Use when asked to map a customer journey, create a user journey, document touchpoints and pain points, or design an experience map. Produces a complete journey map with stages, touchpoints, emotions, pain points, and prioritised opportunities."
---
# Customer Journey Map Skill
This skill produces a complete customer journey map covering every stage from awareness through advocacy. Each stage includes touchpoints, customer actions, emotions, pain points, and specific improvement opportunities. Output is ready for use in product discovery, UX design, or cross-functional alignment workshops.
## Required Inputs
Ask the user for these if not provided:
- **Product or service** being mapped
- **Customer persona** — which customer segment is this map for? (be specific — one persona per map)
- **Journey scope** — full end-to-end (awareness → advocacy), or a specific phase (e.g. onboarding only)?
- **Current state or future state?** — mapping how it works today, or designing how it should work?
- **Data sources** — any research, user interviews, support tickets, NPS comments, analytics available?
- **Goal of the map** — what decision will this inform? (redesign, prioritisation, stakeholder alignment, new feature)
## Output Structure
---
# Customer Journey Map: [Product / Service]
**Persona:** [Name — e.g. "Sarah, the overwhelmed HR manager"]
**Journey scope:** [Full end-to-end / Onboarding / Purchase / Renewal]
**Current or future state:** [Current state / Desired future state]
**Prepared by:** [Name / Team]
**Date:** [Date]
**Based on:** [Research sources — interviews, analytics, support data, assumed/hypothetical]
---
## Persona Summary
| | |
|---|---|
| **Name** | [Sarah] |
| **Role** | [HR Manager at a 200-person professional services firm] |
| **Goal** | [Reduce time spent on manual employee data management] |
| **Frustrations** | [Too many tools that don't talk to each other; always chasing approvals] |
| **Tech comfort** | [Moderate — comfortable with SaaS tools but not a power user] |
| **Decision power** | [Recommends tools; budget approved by CHRO] |
---
## Journey Overview
```
AWARENESS → CONSIDERATION → DECISION → ONBOARDING → ADOPTION → ADVOCACY
[Stage 1] [Stage 2] [Stage 3] [Stage 4] [Stage 5] [Stage 6]
```
**Overall experience rating (current state):** [😤 Frustrating / 😐 Neutral / 😊 Positive]
---
## Stage 1: Awareness
*How does the customer first discover the product exists?*
**Customer goal at this stage:** [e.g. Realise they have a problem worth solving — or find a solution to a specific pain]
| Element | Detail |
|---|---|
| **Trigger** | [What event makes them start looking? — e.g. Manual process breaks down / peer recommendation / saw ad] |
| **Where they are** | [Google search / LinkedIn / conference / colleague conversation / email newsletter] |
| **What they do** | [e.g. Searches "automate employee onboarding" / asks peers in HR community / clicks LinkedIn ad] |
| **Emotion** | [😤 Frustrated — overwhelmed by manual processes and hoping for a better way] |
| **Pain points** | [Overwhelming number of options / hard to know which tools are credible / can't tell what's B2B vs B2C from homepage] |
| **Opportunities** | [SEO content targeting the trigger keyword / LinkedIn thought leadership / peer community presence] |
---
## Stage 2: Consideration
*The customer is actively evaluating options. What do they do to decide?*
| Element | Detail |
|---|---|
| **Customer goal** | [Narrow down from many options to a shortlist of 2–3] |
| **What they do** | [Reads G2/Capterra reviews / watches demo video / downloads comparison guide / asks peers who use something similar] |
| **Touchpoints** | [Website / review sites / social proof / demo request flow / sales email] |
| **Emotion** | [😕 Anxious — worried about making the wrong choice; past tool purchases haven't delivered] |
| **Pain points** | [Pricing not visible on website / demo requires a call before seeing the product / unclear if it works with their existing stack] |
| **Opportunities** | [Self-serve demo or interactive product tour / transparent pricing page / ROI calculator / case studies from similar company size] |
---
## Stage 3: Decision
*The customer is ready to buy — or not. What makes them commit?*
| Element | Detail |
|---|---|
| **Customer goal** | [Get sign-off from CHRO and justify the decision with a business case] |
| **What they do** | [Books sales call / requests security questionnaire / builds internal business case / negotiates contract] |
| **Touchpoints** | [AE / sales call / security review / contract / procurement process] |
| **Emotion** | [😬 Cautious — doesn't want to be wrong; presenting to leadership adds pressure] |
| **Pain points** | [Sales process is slow / security questionnaire takes weeks / contract terms are non-standard and require legal] |
| **Opportunities** | [Security FAQ self-serve / standard contract with predictable terms / champion toolkit (slides, business case template) to help them sell internally] |
---
## Stage 4: Onboarding
*The customer has bought. Now they need to get value fast.*
| Element | Detail |
|---|---|
| **Customer goal** | [Get the product working and show their CHRO it was a good decision] |
| **What they do** | [Receives welcome email / attends kickoff call / configures integrations / invites team] |
| **Touchpoints** | [Onboarding email sequence / in-product onboarding checklist / CSM / help centre / integrations marketplace] |
| **Emotion** | [😬 Anxious but hopeful — excited about potential but stressed about the setup work] |
| **Pain points** | [Setup is more complex than expected / IT required for SSO but IT is slow to respond / generic onboarding doesn't match their use case] |
| **Opportunities** | [Role-specific onboarding paths / IT connector with pre-filled request template / quick win email at day 3 (show them one thing that already works)] |
**Key moment of truth:** [What single moment in this stage determines whether they'll become an active user or ghost? — e.g. "First time the product saves them 30 minutes on a task they used to do manually"]
---
## Stage 5: Adoption
*The customer is using the product. Are they getting consistent value?*
| Element | Detail |
|---|---|
| **Customer goal** | [Make the product a regular part of their workflow; demonstrate ROI to leadership] |
| **What they do** | [Uses core features daily / discovers new features / hits a limitation / contacts support / attends webinar] |
| **Touchpoints** | [Product UI / in-app notifications / email / support / community / customer success manager] |
| **Emotion** | [Variable — some days 😊 when the product works well; some days 😤 when hitting a gap or bug] |
| **Pain points** | [Feature they expected isn't there / reporting doesn't show the metric leadership wants / power features are too complex / feels like they're underutilising what they're paying for] |
| **Opportunities** | [Proactive CSM check-in at day 30 / in-product feature discovery / usage dashboard for the customer to see their own ROI / community for peer learning] |
**Adoption health indicators:**
- [DAU/MAU ratio — what does healthy look like?]
- [Feature X used by Y% of seats within Z weeks]
- [First NPS survey at 60 days — target score]
---
## Stage 6: Advocacy
*The customer loves the product. How do you turn them into a referral engine?*
| Element | Detail |
|---|---|
| **Customer goal** | [Solve problems faster; feel like an expert; feel valued as a customer] |
| **What they do** | [Refers a peer / writes a G2 review / participates in case study / speaks at event / becomes a power user / joins community] |
| **Touchpoints** | [CSM / community / review request email / referral programme / case study outreach / conference sponsorship] |
| **Emotion** | [😊 Proud — the tool is part of their professional identity; they feel smart for choosing it] |
| **Pain points** | [Referral programme is clunky / no structured way to connect with peers / case study process is slow and effortful for them] |
| **Opportunities** | [One-click G2 review request at high-satisfaction moment / peer community / referral programme with meaningful reward / case study process that does most of the work for them] |
---
## Emotion Curve
Plot the customer's emotional experience across the journey:
```
High 😊 │ * * *
│ *
Neutral 😐│ * *
│ *
Low 😤 │ * *
└────────────────────────────────────────────────────
Aware Consider Decide Onboard Adopt Advocate
```
**Lowest point:** [Which stage has the worst experience — and why?]
**Highest point:** [When is the customer most delighted — what drove it?]
**Biggest drop:** [Where does sentiment fall most sharply — this is usually the biggest opportunity]
---
## Prioritised Opportunities
| Opportunity | Stage | Impact on customer | Effort to fix | Priority |
|---|---|---|---|---|
| [Self-serve product tour before sales call] | Consideration | [High — removes top buying barrier] | [Medium] | P1 |
| [Quick win email at day 3] | Onboarding | [High — builds early habit] | [Low] | P1 |
| [IT SSO setup template] | Onboarding | [Medium — removes specific blocker] | [Low] | P2 |
| [30-day proactive CSM check-in] | Adoption | [Medium — catches churn signals early] | [Medium] | P2 |
| [Peer referral programme] | Advocacy | [High for growth — reduces CAC] | [High] | P3 |
---
## What We Don't Know (Research Gaps)
| Gap | How to close it | Priority |
|---|---|---|
| [What actually triggers the decision to start looking?] | [5 JTBD interviews with recent buyers] | [High] |
| [What causes customers to stall in onboarding?] | [Drop-off analysis in onboarding funnel + 3 interviews with churned customers] | [High] |
| [What % of customers have reached the advocacy stage?] | [Product analytics — identify power users; NPS by cohort] | [Medium] |
---
## Quality Checks
- [ ] Map covers one specific persona — not "all customers"
- [ ] Each stage includes the customer's emotional state — not just actions
- [ ] Pain points are the customer's pain — not the company's pain
- [ ] Opportunities are specific enough to become backlog items or design prompts
- [ ] Emotion curve shows the real experience — not an aspirationally positive version
- [ ] Research gaps are documented — the map reflects what is known, not assumed
## Example Trigger Phrases
- "Map the customer journey for [product]"
- "Build a user journey from awareness to advocacy"
- "Create a journey map for our onboarding experience"
- "Map out the touchpoints and pain points for [customer type]"
- "Design an experience map for [process or product]"
plugins/pm-gtm/skills/product-positioning-doc/SKILL.md
+221
View File
@@ -0,0 +1,221 @@
---
name: product-positioning-doc
description: "Write a product positioning document and messaging framework. Use when asked to define product positioning, write a positioning statement, build a messaging framework, or create a messaging hierarchy. Produces a complete positioning doc with category definition, target customer, differentiation, proof points, messaging pillars, and persona-specific messaging."
---
# Product Positioning Doc Skill
This skill produces a complete product positioning document following the April Dunford positioning methodology. Output covers category definition, target customer, unique attributes, proof points, and a messaging hierarchy — ready to align GTM, marketing, sales, and product teams.
## Required Inputs
Ask the user for these if not provided:
- **Product name** and what it does
- **Target customer** — who is it for? (role, company type, size)
- **Problem it solves** — what pain or goal does it address?
- **Key alternatives** — what do customers use today instead? (not just direct competitors — include status quo, spreadsheets, DIY)
- **Differentiation** — what does this product do that alternatives cannot? (not features — capabilities that produce different outcomes)
- **Proof points** — any customer data, case studies, metrics, or validation?
- **Business goal** — is positioning for a new category, expansion into new segment, or repositioning away from a declining category?
## Output Structure
---
# Positioning Document: [Product Name]
**Version:** [1.0]
**Owner:** [PMM / Founder / Marketing lead]
**Date:** [Date]
**Status:** [Draft / Reviewed / Approved]
**Approved by:** [Names — this document must be signed off by product, marketing, and sales leadership before use]
---
## 1. Background & Context
[2–3 sentences describing why positioning is being done now. Is this a new product, a pivot, a segment expansion, or a rebrand? What triggered this work?]
**Positioning objective:** [e.g. Move from being perceived as a reporting tool to being the category leader in revenue intelligence for mid-market SaaS]
---
## 2. Market Category
**What category does this product compete in?**
This is the frame of reference your customer uses to understand what the product is. Choose the wrong category and everything downstream — competitors, value, messaging — is wrong.
**Category:** [e.g. Customer data platform / Revenue intelligence / No-code automation / Modern data stack]
**Why this category, not [alternative category]?**
[1–2 sentences on why this framing serves the customer's understanding better than adjacent categories]
**Category maturity:**
- [ ] New category (we are creating it — high education burden, high upside if it works)
- [ ] Growing category (fast-growing segment — compete on differentiation)
- [ ] Mature category (well-understood — must disrupt with clear superiority or narrower niche)
---
## 3. Target Customer
**Be precise. Vague targeting produces vague positioning.**
| Dimension | Description |
|---|---|
| **Primary buyer / decision-maker** | [e.g. VP of Revenue Operations at B2B SaaS companies with 100–500 employees] |
| **Primary user** | [e.g. Revenue operations analysts and sales ops managers] |
| **Company profile** | [Industry, size, growth stage, technology stack] |
| **Business context** | [What is happening in their world that makes them a buyer right now?] |
| **Trigger event** | [What just happened that makes them start looking for a solution? — e.g. Sales team grew past 20 reps, forecast accuracy became a board question] |
**Who this is NOT for:**
[Be explicit about who to exclude — this sharpens the positioning for those who are a fit]
---
## 4. Competitive Alternatives
What do buyers use today when they don't have your product? List all real alternatives — not just direct competitors.
| Alternative | Who uses it | Why buyers choose it | What they sacrifice |
|---|---|---|---|
| **[Direct competitor — e.g. Gong]** | [Enterprise sales teams] | [Market leader, strong brand, sales coaching features] | [Price, complexity, implementation time] |
| **[Adjacent tool — e.g. Salesforce reports]** | [CRM-native users] | [Already have it, no additional cost] | [No AI analysis, manual reporting, siloed data] |
| **[Status quo — e.g. spreadsheets + manual tracking]** | [SMB, early-stage] | [Free, flexible, no change management] | [Time-consuming, error-prone, not scalable] |
| **[Build in-house]** | [Tech companies with data teams] | [Custom to their exact needs] | [Engineering cost, maintenance burden, 12+ month timeline] |
**Key insight:** [What does this competitive landscape tell you about what your positioning must emphasise? e.g. "Every alternative either costs too much or requires too much manual work — positioning must nail 'fast time to value' and 'right-sized for mid-market'"]
---
## 5. Unique Differentiated Attributes
These are the features or capabilities your product has that alternatives genuinely cannot match — or cannot match at the same level. Do not list features that competitors also have.
| Attribute | What it is | What it enables (outcome) | Why competitors can't match it |
|---|---|---|---|
| [e.g. Real-time CRM sync] | [Bidirectional sync with any CRM in <5 min] | [Reps see clean data in the tools they already use — no toggle between systems] | [Legacy competitors require 3-month integration projects; Salesforce-native tools only work in SFDC] |
| [e.g. Natural language querying] | [Ask questions in plain English, get data visualisations] | [Anyone on the revenue team can answer their own questions without SQL or waiting for an analyst] | [BI tools require analyst training; direct competitors have rigid dashboards] |
| [...] | [...] | [...] | [...] |
**The core differentiation thesis:**
[1–2 sentences that unite the above attributes into a single "why we win" statement — this is internal language, not customer-facing yet]
---
## 6. Value Proof Points
Back up the differentiation claims with evidence:
| Claim | Proof point | Source |
|---|---|---|
| [Fastest time to value] | [Average customer is live in 4 hours vs 3 months for legacy alternatives] | [Customer data — average across [X] accounts] |
| [Better forecast accuracy] | [Customers achieve X% improvement in forecast accuracy within 90 days] | [Case study: [Company Name] — link] |
| [Loved by operators, not just managers] | [NPS of X among end users; 4.8/5 on G2 for ease of use] | [G2 reviews, internal NPS survey] |
**Proof gaps:** [Are there claims you're making that you don't yet have evidence for? List them — they are either research projects or risks to the positioning]
---
## 7. Positioning Statement
The classic positioning template — internal only, never used verbatim in marketing:
> **For** [target customer]
> **who** [trigger event or problem statement],
> **[Product name]** is a **[category]**
> **that** [primary differentiated value — the outcome, not the feature].
> **Unlike** [primary alternative],
> **[Product name]** [the key thing that makes you different and better].
**Draft positioning statement:**
> For [VP Revenue Ops at B2B SaaS companies with 50–500 reps] who [struggle to forecast accurately as the sales team scales], [Product Name] is a [revenue intelligence platform] that [gives every rep and manager accurate, real-time pipeline visibility without any analyst overhead]. Unlike [Salesforce dashboards and manual reporting], [Product Name] [syncs automatically, surfaces risks before they become missed quarters, and needs no configuration by IT or data teams].
---
## 8. Messaging Hierarchy
Translate the positioning into customer-facing language at three levels:
### Tagline (5–8 words)
[The simplest possible statement of what you do and for whom. Used in ads, hero sections, email signatures.]
Options to test:
1. [e.g. "Revenue intelligence for scaling sales teams"]
2. [e.g. "Forecast with confidence. Close with clarity."]
3. [e.g. "The revenue platform your whole team will actually use"]
### Value Proposition (1–2 sentences)
[Used in the hero section of the website, email subject lines, and sales decks. Must be instantly clear.]
> [e.g. "[Product Name] gives revenue teams real-time pipeline visibility and accurate forecasting — without spreadsheets, custom reports, or waiting for an analyst. Get live in 4 hours, not 4 months."]
### Full Description (3–5 sentences)
[Used in PR, partnership briefs, longer sales emails, and About Us pages.]
> [e.g. "[Product Name] is the revenue intelligence platform built for mid-market SaaS teams. Unlike legacy BI tools that require analyst configuration or CRM dashboards that only show what's already happened, [Product Name] automatically syncs your entire revenue stack, surfaces AI-driven risk signals, and lets any rep or manager ask questions in plain English. [X] customers use [Product Name] to call their quarters with confidence. Average time to live: 4 hours."]
---
## 9. Persona-Specific Messaging
The core positioning is the same, but different buyers care about different aspects:
| Persona | Their primary concern | Lead message | Proof point to use |
|---|---|---|---|
| **VP Revenue Operations** | Forecast accuracy, board credibility | "Call your quarter with confidence" | [X% improvement in forecast accuracy across N customers] |
| **Head of Sales** | Rep productivity, pipeline visibility | "Your reps close more, not admin more" | [X hours/week saved per rep] |
| **CEO / CFO** | Revenue predictability, cost | "Stop being surprised by quarters" | [ROI: £X saved vs X headcount required to replicate manually] |
| **Sales Rep** | Ease of use, not adding to workload | "It works in the tools you already use" | [Ease of use NPS, G2 reviews] |
---
## 10. Messaging Do's and Don'ts
**Do say:**
- [Specific, outcome-focused language — what the customer achieves]
- [Comparative language grounded in evidence]
- [Language your target buyer uses to describe their problem — not language you invented]
**Don't say:**
- ["Best-in-class", "innovative", "cutting-edge", "game-changing" — unless followed by evidence]
- [Feature lists without outcome context]
- [Jargon your buyer doesn't use themselves]
- [Claims your competitors could also make]
---
## 11. Distribution Plan
Positioning only works if it's implemented consistently:
| Team | What they need | Format | Owner | When |
|---|---|---|---|---|
| Marketing | Tagline, value prop, messaging hierarchy | This doc + messaging playbook | PMM | [Date] |
| Sales | Competitive positioning, objection responses | One-pager + deck | Sales enablement | [Date] |
| Product | Category definition, target customer | Shared doc + roadmap input | PMM + PM | [Date] |
| Leadership | Full positioning narrative | This doc | PMM | [Date] |
---
## Quality Checks
- [ ] Positioning statement has exactly one A — the product is accountable to exactly one primary differentiated claim
- [ ] Competitive alternatives include the status quo — not just named competitors
- [ ] Differentiated attributes describe outcomes, not features
- [ ] Every proof point cites a source — not "customers say…"
- [ ] Persona messaging uses the buyer's language, not the company's
- [ ] At least two people from product, marketing, and sales have reviewed and approved
## Example Trigger Phrases
- "Write a positioning document for [product]"
- "Build a messaging framework for our B2B SaaS tool"
- "Define our product positioning — who is this for and why should they care?"
- "Create a positioning statement and messaging hierarchy for [launch]"
- "Help me articulate our differentiation vs [Competitor]"
plugins/pm-gtm/skills/social-media-strategy/SKILL.md
+237
View File
@@ -0,0 +1,237 @@
---
name: social-media-strategy
description: "Build a social media strategy for a brand, product, or creator. Use when asked to create a social media strategy, define a social content strategy, plan content pillars, set social KPIs, or build a posting framework. Produces a complete strategy with audience definition, platform selection, content pillars, posting cadence, KPIs, and a 4-week starter calendar."
---
# Social Media Strategy Skill
This skill produces a complete social media strategy covering audience definition, platform rationale, content pillars, posting cadence, tone of voice guidelines, measurement framework, and a 4-week starter content calendar. Output is ready for a marketing team, founder, or agency to execute immediately.
## Required Inputs
Ask the user for these if not provided:
- **Brand / product / creator name**
- **What you're promoting** — product, service, personal brand, community, or event
- **Target audience** — who are you trying to reach? (job title, age, interests, platforms they use)
- **Business goal** — what does social need to achieve? (brand awareness / lead generation / community building / sales / recruitment)
- **Current social presence** — which platforms are you on? What's working, what isn't?
- **Competitors or aspirational accounts** — who does social well in your space?
- **Resources** — how many people and how much time per week can you dedicate to social?
## Output Structure
---
# Social Media Strategy: [Brand / Product / Creator]
**Goal:** [Primary business goal]
**Audience:** [1-sentence description of primary audience]
**Timeframe:** [e.g. Q3 2026 — 3-month strategy]
**Owner:** [Marketing lead / founder / social team]
**Date:** [Date]
---
## 1. Audience Profile
**Primary audience:**
| Dimension | Detail |
|---|---|
| **Who they are** | [Job title, age range, life stage, geography] |
| **What they care about** | [Professional or personal priorities, pain points] |
| **Where they spend time online** | [Platforms, communities, influencers they follow] |
| **What they consume** | [Content formats they engage with — video, threads, newsletters, podcasts] |
| **What would make them follow you** | [The specific value proposition of your social presence] |
**Secondary audience:** [Any secondary segment — e.g. job seekers if you're a brand, investors if you're a startup]
---
## 2. Platform Strategy
Not every platform is right for every brand. Justify each platform choice:
| Platform | Audience fit | Content format | Priority | Why (or why not) |
|---|---|---|---|---|
| **LinkedIn** | [B2B / professional] | [Text posts, carousels, articles] | [Primary / Secondary / Skip] | [e.g. Primary platform for B2B SaaS — where buyers and influencers are] |
| **X / Twitter** | [Tech, media, founders] | [Short text, threads, replies] | [...] | [...] |
| **Instagram** | [Consumer, visual brands, creators] | [Reels, Stories, carousels] | [...] | [...] |
| **TikTok** | [B2C, Gen Z, consumer] | [Short-form video] | [...] | [...] |
| **YouTube** | [All audiences — discovery + long-form] | [Long-form video, Shorts] | [...] | [...] |
| **Threads** | [Text-first, creator, early adopter] | [Short text, conversations] | [...] | [...] |
**Lead platform:** [One platform to invest most heavily in — where your audience is most active and where you have the best chance to stand out]
**Supporting platforms:** [1–2 secondary platforms where you'll repurpose or adapt content]
---
## 3. Content Pillars
Define 3–5 content themes that anchor your social presence. Each pillar must serve the audience, not just the brand.
### Pillar 1: [Name — e.g. "Behind the build"]
**What it is:** [1-sentence description]
**Why the audience cares:** [What value does this deliver to them?]
**Content examples:**
- [e.g. Engineering decisions we made and why]
- [e.g. Week-in-the-life of the founding team]
- [e.g. What we shipped this week and what we learned]
**Format mix:** [Carousel / video / thread / short-form text]
**Posting cadence:** [X times per week]
---
### Pillar 2: [Name — e.g. "Practical education"]
**What it is:** [...]
**Why the audience cares:** [...]
**Content examples:**
- [...]
- [...]
**Format mix:** [...]
**Posting cadence:** [...]
---
### Pillar 3: [Name — e.g. "Social proof and community"]
**What it is:** [Customer stories, testimonials, user-generated content, community spotlights]
**Why the audience cares:** [Validation from peers carries more weight than brand claims]
**Content examples:**
- [Customer outcome stories — 1 metric + 1 quote format]
- [Repost community member wins]
- [Case study carousels]
**Format mix:** [...]
**Posting cadence:** [...]
---
### Pillar 4: [Name — e.g. "Point of view"]
**What it is:** [Opinions on industry trends, hot takes, commentary on news in your space]
**Why the audience cares:** [People follow accounts that say something, not just share information]
**Content examples:**
- [Contrarian takes on common advice]
- [Reaction to industry news — what it means for your audience]
- [Founder's personal perspective on a topic]
**Format mix:** [...]
**Posting cadence:** [...]
---
## 4. Tone of Voice
Define how your brand sounds on social — before you write a single post:
| Dimension | [Your brand] sounds like... | [Your brand] does NOT sound like... |
|---|---|---|
| **Formality** | [e.g. Conversational, plain English] | [Corporate speak, jargon] |
| **Energy** | [e.g. Curious, enthusiastic] | [Aggressive, hypey] |
| **Personality** | [e.g. Smart friend who happens to be an expert] | [Faceless institution] |
| **Humour** | [e.g. Dry wit, occasional] | [Try-hard memes, sarcasm] |
| **Self-promotion** | [e.g. Earns the right to mention the product] | [Every post is an ad] |
**Reference accounts that nail the tone you're aiming for:** [Name 2–3 accounts — and why]
---
## 5. Posting Cadence & Workflow
| Platform | Posts per week | Best days | Best times | Format split |
|---|---|---|---|---|
| [LinkedIn] | [3–5] | [Tue–Thu] | [07:30–09:00 or 12:00–13:00] | [60% educational, 30% POV, 10% product] |
| [X / Twitter] | [5–7] | [Any] | [Morning and lunchtime] | [50% replies/engagement, 30% original, 20% reposts] |
| [Instagram] | [3–4] | [Mon, Wed, Fri] | [18:00–20:00] | [50% Reels, 30% carousels, 20% Stories] |
**Content production workflow:**
| Day | Activity | Owner | Time required |
|---|---|---|---|
| Monday | Plan the week's content — review pillars, select topics | [Social manager] | 30 min |
| Tuesday | Write long-form posts for LinkedIn and threads | [Writer / founder] | 60 min |
| Wednesday | Design carousels or graphics | [Designer / Canva] | 45 min |
| Thursday | Schedule the week's content in [Buffer / Hootsuite / Later] | [Social manager] | 20 min |
| Daily | Engage with comments, reply to mentions, interact with community | [Social manager] | 15 min |
---
## 6. Growth Tactics
Beyond posting, how will you grow your following and reach?
| Tactic | Description | Platform | Frequency |
|---|---|---|---|
| **Engage before you post** | Spend 15 min commenting on posts from target accounts before posting your own | All | Daily |
| **Collaboration posts** | Co-create content with a complementary brand or creator | LinkedIn / IG | Monthly |
| **Community participation** | Answer questions in relevant groups, subreddits, or Discord servers | LinkedIn / Reddit / Discord | Weekly |
| **Tag relevant accounts** | When mentioning companies, tools, or people — tag them (earns reshares) | All | As relevant |
| **Cross-promote** | Mention your social in newsletters, emails, events, and podcast appearances | All | Ongoing |
| **Use trending formats early** | When a new format (e.g. LinkedIn carousels, IG Reels) emerges, adopt early | Platform-specific | When relevant |
---
## 7. Measurement Framework
**Primary KPIs (tied to business goal):**
| KPI | Platform | Current baseline | Target (90 days) | Why it matters |
|---|---|---|---|---|
| [Follower growth rate] | [LinkedIn] | [X%/month] | [≥ Y%/month] | [Audience reach] |
| [Engagement rate] | [LinkedIn] | [X%] | [≥ Y%] | [Content resonance] |
| [Link clicks / traffic from social] | [All] | [X visits/month] | [≥ Y visits/month] | [Direct business impact] |
| [Inbound leads attributed to social] | [LinkedIn] | [X/month] | [≥ Y/month] | [Revenue impact] |
**Secondary metrics (health indicators):**
- Reach per post
- Saves and shares (not just likes)
- Comment sentiment and quality
- DMs initiated from content
**Reporting cadence:** [Weekly check on engagement / Monthly review of follower and traffic / Quarterly strategy review]
---
## 8. 4-Week Starter Content Calendar
A concrete first month of content — ready to adapt and post:
| Week | Day | Platform | Pillar | Format | Topic idea |
|---|---|---|---|---|---|
| 1 | Mon | LinkedIn | Education | Carousel | [e.g. "5 things we wished we knew before building [X]"] |
| 1 | Wed | LinkedIn | Behind the build | Text post | [e.g. "We almost gave up in month 3. Here's what changed."] |
| 1 | Fri | Instagram | Social proof | Reel | [e.g. Customer story — problem → solution → result] |
| 2 | Tue | LinkedIn | POV | Thread | [e.g. "Hot take: [common advice in your space] is wrong. Here's why."] |
| 2 | Thu | X/Twitter | Education | Thread | [e.g. "The [X] framework we use every week — and how you can steal it"] |
| 2 | Sat | Instagram | Behind the build | Story | [e.g. "Week 2 update — what we shipped and one thing that didn't go to plan"] |
| 3 | Mon | LinkedIn | Education | Carousel | [e.g. "How to [achieve outcome] in [timeframe] — step by step"] |
| 3 | Wed | LinkedIn | Community | Text post | [e.g. Reshare a customer win with commentary] |
| 3 | Fri | Instagram | POV | Reel | [e.g. "[Industry myth] — why we disagree and what we do instead"] |
| 4 | Tue | LinkedIn | Behind the build | Video | [e.g. Founder talking to camera — "One thing I learned building [X] this month"] |
| 4 | Thu | X/Twitter | POV | Thread | [e.g. "[Trend in your space] — here's what's actually happening"] |
| 4 | Sat | All | Milestone | Text + image | [e.g. "[X followers / X users / X months] — thank you + what's next"] |
---
## Quality Checks
- [ ] Every content pillar delivers value to the audience — not just the brand
- [ ] Platform selection is justified by where the target audience actually spends time
- [ ] Tone of voice examples are specific enough to use as a writing guide
- [ ] KPIs are tied to the business goal, not just vanity metrics (likes, followers in isolation)
- [ ] Posting cadence is realistic for the available resources — sustainable beats ambitious
- [ ] The 4-week calendar has specific topic ideas, not just "write an educational post"
## Example Trigger Phrases
- "Build a social media strategy for [brand/product]"
- "Create a LinkedIn content strategy for our B2B SaaS"
- "Help me define content pillars and posting cadence for our startup"
- "Design a 90-day social media plan for [company]"
- "What should our social media strategy be for a product launch?"
plugins/pm-operations/skills/raci-matrix/SKILL.md
+160
View File
@@ -0,0 +1,160 @@
---
name: raci-matrix
description: "Define a RACI matrix for a cross-functional project or process. Use when asked to build a RACI, create a responsibility matrix, clarify ownership across teams, or document decision rights. Produces a complete RACI matrix with role definitions, decision mapping, and a process for resolving conflicts."
---
# RACI Matrix Skill
This skill produces a complete RACI (Responsible, Accountable, Consulted, Informed) matrix for a project, product launch, or ongoing process. Output is ready to share with teams to clarify ownership, reduce decision bottlenecks, and eliminate duplication of effort.
## Required Inputs
Ask the user for these if not provided:
- **Project or process name**
- **Key activities or decisions** to map (or the user can describe the project and the skill will derive them)
- **Teams or roles involved** (list team names and key individuals if helpful)
- **Primary purpose** — clarifying launch ownership / onboarding a new team / reducing bottlenecks / governance documentation
- **RACI variant** — standard RACI, or RASCI (adds Supportive), or DACI (Driver, Approver, Contributors, Informed)?
## Output Structure
---
# RACI Matrix: [Project / Process Name]
**Version:** [1.0]
**Owner:** [Programme lead / PM]
**Date:** [Date]
**Teams involved:** [List teams]
---
## 1. Role Definitions
Before reading the matrix, agree on what each letter means for this project:
| Letter | Role | Definition | Rules |
|---|---|---|---|
| **R** | Responsible | Does the work. One or more people actually execute the task. | Multiple Rs are allowed — but if there are many, consider splitting the task |
| **A** | Accountable | Owns the outcome. Signs off on decisions. Answers if something goes wrong. | **There must be exactly one A per row.** Never two. Never zero. |
| **C** | Consulted | Provides expertise or input before work is done. Two-way communication. | Consulted parties must be engaged — not just available. Cap at 3 per row or it becomes noise |
| **I** | Informed | Notified of progress or outcomes. One-way communication. | Informed only — they don't review or approve |
**Golden rules:**
- Every row has exactly one **A**
- The same person or team should not be **A** for more than [X] rows — spreads accountability too thin
- **C** is expensive — consulting someone means they must respond. Use it intentionally
- If someone is **R** they cannot also be **A** for the same task unless they are the decision-maker (common in small teams)
---
## 2. RACI Matrix
Columns = teams or roles. Rows = activities or decisions.
| Activity / Decision | [Role 1] | [Role 2] | [Role 3] | [Role 4] | [Role 5] | Notes |
|---|---|---|---|---|---|---|
| **[Phase 1: Discovery]** | | | | | | |
| Define project scope and objectives | A/R | C | I | I | — | PM leads; engineering consulted on technical feasibility |
| Conduct user research | R | A | C | I | — | UX researcher executes; PM accountable |
| Approve discovery findings | C | A | I | R | — | |
| **[Phase 2: Design]** | | | | | | |
| Define solution approach | A | R | C | I | I | |
| Design system / UI designs | C | A/R | I | I | — | |
| Design review and sign-off | C | R | A | I | — | |
| Accessibility review | I | R | A | C | — | |
| **[Phase 3: Build]** | | | | | | |
| Technical architecture decision | C | C | A/R | I | — | |
| Sprint planning | A | C | R | I | I | |
| Code review and merge | I | C | R | A | — | |
| Security review | I | C | C | A/R | — | |
| **[Phase 4: Launch]** | | | | | | |
| Launch go / no-go decision | A | C | C | R | I | PM holds final authority |
| Release to production | C | I | A/R | I | — | |
| Customer communications | A/R | I | I | I | C | |
| Post-launch monitoring | C | I | R | A | — | |
| **[Ongoing / BAU]** | | | | | | |
| Incident response | I | C | R | A | — | |
| Feature prioritisation | A/R | C | C | I | I | |
| Stakeholder reporting | A/R | I | I | I | C | |
---
## 3. Decision Map
For high-stakes decisions, document the decision type, who holds authority, and how disagreements are resolved:
| Decision | Authority (A) | Must consult (C) | Escalation path if disagreed |
|---|---|---|---|
| Scope change >20% effort | [Exec sponsor / Programme lead] | [PM, Engineering lead] | [Steering committee] |
| Budget overrun >10% | [Finance / Exec] | [PM, Programme lead] | [CFO / Board] |
| Architecture pattern change | [Engineering lead] | [Tech lead, Security] | [CTO] |
| Go-live date change | [PM] | [Engineering, Comms, CS] | [Programme sponsor] |
| Feature cut from scope | [PM] | [Product, UX, Engineering] | [CPO] |
---
## 4. Common RACI Anti-Patterns — and Fixes
Review the completed matrix against these failure modes:
| Anti-pattern | Symptom | Fix |
|---|---|---|
| **Multiple As** | Two teams both think they own an outcome | Agree one A; the other becomes C or I |
| **No A** | Decisions stall; no one feels responsible | Assign the most senior stakeholder as A |
| **Everyone is C** | Every decision goes to a committee | Audit each C — does this person actually provide input that changes outcomes? If not, move to I |
| **R without A** | Work gets done but no one owns quality | Add an A; usually the manager of the R |
| **A without R** | Accountability without execution — manager is disconnected | Add an R from the team; or combine A/R if appropriate |
| **Too many Rs** | Diffusion of responsibility | Split the task into sub-tasks, each with one clear R |
| **Key team missing from matrix** | They're affected but not in the RACI | Add them; assign at minimum I for relevant rows |
---
## 5. Communication Template
Once the RACI is agreed, use this template to communicate it to all involved teams:
---
**Subject:** [Project Name] — Roles and Responsibilities Agreed
We've finalised the RACI matrix for [Project Name]. Here's what it means for you:
**[Role 1 team]:** You are **Accountable** for [X, Y, Z activities]. This means you make the final call on those decisions and answer if outcomes are not met.
**[Role 2 team]:** You are **Responsible** for [A, B, C]. You execute the work. For [D], you are **Consulted** — we need your input before decisions are finalised.
**[Role 3 team]:** You are **Informed** on [E, F] — we'll send you updates at [weekly / milestone / launch]. No action required unless you see something that needs escalation.
Please review the full matrix here: [Link]. Raise any concerns by [Date] — after that, we'll treat it as agreed.
---
## 6. RACI Review Cadence
| Trigger | Action |
|---|---|
| New team member joins | Review rows relevant to their role — update R as needed |
| Phase change (e.g. discovery → delivery) | Review full matrix — some Rs and As will shift |
| Escalation or confusion about ownership | Use the matrix to diagnose — find the missing A |
| 3 months into a long programme | Full RACI review — roles drift over time |
| Team restructure or reorganisation | Full rebuild — ownership assumptions change |
---
## Quality Checks
- [ ] Every row has exactly one **A**
- [ ] No individual or team is **A** for more than their realistic sphere of authority
- [ ] **C** columns are sparse — consulting everyone dilutes the process
- [ ] Matrix was reviewed and agreed by at least one representative from each role column
- [ ] A communication plan exists to share the RACI with all involved parties
- [ ] Decision map covers the top 5–10 highest-stakes decisions in the project
## Example Trigger Phrases
- "Build a RACI matrix for our product launch"
- "Create a responsibility matrix for our new cross-functional project"
- "Who owns what on this initiative? Help me build a RACI"
- "Map out decision rights for our engineering and product teams"
- "Generate a RACI for a [migration / launch / process] involving [teams]"
plugins/pm-operations/skills/risk-register/SKILL.md
+211
View File
@@ -0,0 +1,211 @@
---
name: risk-register
description: "Build and maintain a project or product risk register. Use when asked to create a risk register, identify project risks, build a risk matrix, or document risks and mitigations for a programme. Produces a complete risk register with likelihood/impact scoring, RAG status, ownership, and prioritised mitigations."
---
# Risk Register Skill
This skill produces a complete risk register for a project, programme, or product. Output follows standard risk management practice with likelihood × impact scoring, RAG status, a risk heat map, and specific mitigation and contingency plans. Ready to share with a project board, steering committee, or programme office.
## Required Inputs
Ask the user for these if not provided:
- **Project or product name**
- **Project stage** (discovery / delivery / launch / live / programme-level)
- **Key objectives** — what is the project trying to achieve?
- **Known risks** — anything already on the team's radar (even informal concerns count)
- **Key dependencies** — external vendors, teams, systems, or regulatory approvals
- **Deadline or milestone sensitivity** — are there hard dates that cannot move?
- **Audience** — who will read this? (internal team / executive steering / external board / regulator)
## Output Structure
---
# Risk Register: [Project / Product Name]
**Project stage:** [Discovery / Delivery / Launch / Live / Programme]
**Version:** [1.0]
**Owner:** [PM / Programme Manager / Risk Lead]
**Last reviewed:** [Date]
**Next review:** [Date — recommend weekly during delivery, monthly during discovery]
**Status:** [Active / Archived]
---
## 1. Risk Scoring Framework
**Likelihood (L)**
| Score | Label | Definition |
|---|---|---|
| 5 | Almost certain | >80% probability of occurring |
| 4 | Likely | 60–80% probability |
| 3 | Possible | 40–60% probability |
| 2 | Unlikely | 20–40% probability |
| 1 | Rare | <20% probability |
**Impact (I)**
| Score | Label | Definition |
|---|---|---|
| 5 | Critical | Programme failure, regulatory breach, major financial loss, safety event |
| 4 | High | Significant schedule delay (>4 weeks), scope reduction, reputational damage |
| 3 | Medium | Moderate delay (1–4 weeks), cost overrun, reduced quality |
| 2 | Low | Minor delay (<1 week), manageable cost increase |
| 1 | Negligible | Minimal impact, easily absorbed |
**Risk Score = L × I**
| Score | RAG | Action |
|---|---|---|
| 20–25 | 🔴 Critical | Immediate escalation; active management required |
| 12–19 | 🔴 High | Owner-assigned mitigation; weekly review |
| 8–11 | 🟡 Medium | Mitigation planned; fortnightly review |
| 4–7 | 🟡 Low | Monitor; monthly review |
| 1–3 | 🟢 Negligible | Accept; review if context changes |
---
## 2. Risk Register
| ID | Risk | Category | L | I | Score | RAG | Owner | Status | Mitigation | Contingency | Review date |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R01 | [Risk description — be specific: "Third-party API may not support required volume, causing X to fail"] | [Schedule / Technical / Resource / Commercial / Compliance / External] | [1–5] | [1–5] | [L×I] | 🔴/🟡/🟢 | [Name] | [Open / Mitigating / Closed] | [What are we doing to reduce likelihood or impact?] | [What do we do if it happens?] | [Date] |
| R02 | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] |
---
## 3. Risk Categories — Common Risks by Type
Use these to prompt risk identification. Add, remove, or customise for your project.
### Schedule & Delivery
- Key milestone depends on a dependency that has not confirmed availability
- Team capacity reduced by planned or unplanned absence during critical period
- Technical complexity is underestimated — story points consistently overrun
- External approval (regulator, legal, procurement) takes longer than planned
### Technical
- Integration with a third-party system not yet prototyped or agreed
- Existing technical debt makes the change harder or riskier than estimated
- Security or compliance review required before launch has not been scoped
- Performance under production load untested
- Key technical knowledge held by one person (single point of failure)
### Resource & People
- Key SME or engineer leaving or unavailable during critical phase
- Budget not confirmed for Phase 2 of the project
- Stakeholder sponsor changes role or leaves the organisation
- Team not yet at full capacity (hiring lag, access issues, onboarding time)
### Commercial & Financial
- Vendor or partner contract not yet signed
- Cost estimate based on assumptions that have not been validated
- Revenue or savings case depends on assumptions outside the team's control
- Currency exposure or exchange rate risk for international projects
### Compliance & Regulatory
- Data privacy impact assessment (DPIA) not yet complete
- Regulatory approval required and timeline is uncertain
- GDPR, HIPAA, SOC 2, or sector-specific compliance requirement not yet mapped
- Legal review of terms of service or contracts pending
### Stakeholder & Adoption
- Key user group has low awareness or motivation to adopt the change
- Internal resistance from a team that will be affected by the change
- Executive sponsor not consistently engaged — decisions are slow
- Communications plan not yet agreed with change management team
### External
- Market or competitive change could undermine the business case
- Macroeconomic conditions affect budget or priority
- Supplier or infrastructure provider risk (e.g. cloud provider, hardware)
- Geopolitical or regulatory environment change
---
## 4. Risk Heat Map
Plot risks by likelihood (Y axis) and impact (X axis):
```
│ Low Medium High Critical
│ (1) (2-3) (4) (5)
─────────┼────────────────────────────────────
Almost │ 🟡 🟡 🔴 🔴
certain │
(5) │
─────────┼────────────────────────────────────
Likely │ 🟡 🟡 🔴 🔴
(4) │
─────────┼────────────────────────────────────
Possible │ 🟢 🟡 🟡 🔴
(3) │
─────────┼────────────────────────────────────
Unlikely │ 🟢 🟢 🟡 🟡
(2) │
─────────┼────────────────────────────────────
Rare │ 🟢 🟢 🟢 🟡
(1) │
```
[Plot each risk ID on this grid — e.g. R01 lands at L4/I5 = 🔴 Critical]
---
## 5. Top Risks — Executive Summary
For steering committee or board-level reporting:
| Rank | Risk | Score | RAG | Owner | Mitigation status |
|---|---|---|---|---|---|
| 1 | [Most critical risk — plain English description] | [X] | 🔴 | [Owner] | [Active / Planned / Not started] |
| 2 | [...] | [...] | 🔴 | [...] | [...] |
| 3 | [...] | [...] | 🟡 | [...] | [...] |
| 4 | [...] | [...] | 🟡 | [...] | [...] |
| 5 | [...] | [...] | 🟡 | [...] | [...] |
**Decisions required from steering:**
- [Any risk that requires budget, scope, or timeline decision to mitigate]
---
## 6. Risk Changes Since Last Review
| Risk ID | Change | Detail |
|---|---|---|
| [R03] | Score increased | [L moved from 2 → 4 — vendor confirmed delay in API availability] |
| [R07] | Risk closed | [Legal sign-off received on 12 May] |
| [NEW] | New risk identified | [R09 — budget freeze announcement affects Phase 2 funding] |
---
## 7. Risk Closure Criteria
A risk is closed when:
- The risk event can no longer occur (e.g. milestone passed, contract signed), OR
- The residual risk score drops to Negligible (1–3) AND the team formally accepts it, OR
- The risk has materialised and transitioned to an **issue** (tracked separately)
**Issues log:** [Link to issues log — risks that have materialised and are now active problems being managed]
---
## Quality Checks
- [ ] Every risk has a specific owner — not "the team" or "TBD"
- [ ] Mitigations describe what is actively being done — not "monitor and review"
- [ ] Contingency plans exist for all Critical and High risks
- [ ] Risk descriptions are specific — "vendor may be late" is not specific enough; name the vendor and the dependency
- [ ] Register has been reviewed in the last [X] days
- [ ] Closed risks are archived, not deleted — they provide audit trail
- [ ] Risks are distinguished from issues — a risk is something that might happen; an issue is something that has happened
## Example Trigger Phrases
- "Build a risk register for our product launch"
- "Create a risk matrix for [project name]"
- "What risks should I document for a data migration project?"
- "Generate a risk register for our steering committee"
- "Help me identify and score risks for our Q3 delivery plan"
plugins/pm-people/skills/360-feedback-template/SKILL.md
+256
View File
@@ -0,0 +1,256 @@
---
name: 360-feedback-template
description: "Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas."
---
# 360-Degree Feedback Template Skill
This skill produces two outputs depending on what the user needs: (1) a complete 360 survey instrument for gathering feedback, or (2) a structured 360 feedback report written from gathered notes. Both outputs follow best practice: behaviourally anchored ratings, specific examples, and development-oriented framing.
## Required Inputs
Ask the user which output they need, then gather inputs:
**For a survey instrument:**
- **Role being reviewed** (job title and level)
- **Competencies to assess** (or use defaults below)
- **Reviewer relationships** (peer / direct report / manager / cross-functional)
- **Rating scale preference** (1–5 / 1–4 / frequency-based)
- **Anonymity level** (fully anonymous / attributed / confidential aggregated)
**For a feedback report:**
- **Person being reviewed** (role and level)
- **Feedback notes or raw themes** from reviewers (paste what you have)
- **Reviewer relationships** (how many peers, direct reports, managers responded)
- **Any context** — performance cycle, specific behaviours to address, promotion consideration
---
## Output A: 360 Survey Instrument
---
# 360 Feedback Survey: [Role / Level]
**Purpose:** This survey helps [Name / "the reviewee"] understand how their behaviours and impact are perceived by the people they work with most closely. Responses [are / are not] anonymous. Results will be shared as [individual responses / aggregated themes].
**Instructions:** For each statement, rate how frequently you observe this behaviour. Add specific examples in the open-ended sections — these are the most valuable part of the survey.
**Rating scale:**
- **5 — Consistently:** Almost always demonstrates this behaviour, even in difficult situations
- **4 — Usually:** Demonstrates this behaviour more often than not
- **3 — Sometimes:** Demonstrates this behaviour inconsistently
- **2 — Rarely:** Seldom demonstrates this behaviour
- **1 — Not observed:** Have not had the opportunity to observe this behaviour
---
### Section 1: Delivery & Execution
| Statement | Rating (1–5) |
|---|---|
| Delivers work on time and to the expected quality | |
| Proactively flags risks and blockers before they become problems | |
| Follows through on commitments without needing to be chased | |
| Manages their workload effectively without compromising quality | |
| Adapts quickly when priorities or requirements change | |
**Open question:** Describe a specific time when [Name] handled a delivery challenge particularly well or poorly.
---
### Section 2: Communication & Collaboration
| Statement | Rating (1–5) |
|---|---|
| Communicates clearly and concisely in both written and verbal formats | |
| Listens actively and considers others' input before responding | |
| Keeps the right people informed without over-communicating | |
| Resolves disagreements constructively and without defensiveness | |
| Makes it easy for others to collaborate with them | |
**Open question:** Give an example of how [Name] handled a difficult or high-stakes communication.
---
### Section 3: Leadership & Influence
| Statement | Rating (1–5) |
|---|---|
| Sets a clear direction that others can follow | |
| Builds confidence and capability in people around them | |
| Influences decisions without relying on authority | |
| Gives clear, constructive feedback that helps others improve | |
| Creates an environment where people feel safe to raise concerns | |
**Open question:** Describe a situation where [Name]'s leadership had a notable positive or negative impact on the team.
---
### Section 4: Strategic Thinking
| Statement | Rating (1–5) |
|---|---|
| Understands the broader business context, not just their immediate work | |
| Makes connections between their work and organisational goals | |
| Thinks ahead and anticipates second-order consequences | |
| Brings original ideas or new approaches to problems | |
| Balances short-term needs with longer-term thinking | |
**Open question:** Give an example of [Name] demonstrating (or missing) strategic thinking.
---
### Section 5: Culture & Values
| Statement | Rating (1–5) |
|---|---|
| Treats everyone with respect, regardless of level or background | |
| Is someone people trust and can rely on | |
| Gives credit to others and shares the spotlight | |
| Takes responsibility for mistakes without placing blame | |
| Contributes positively to team morale, especially under pressure | |
**Open question:** How does [Name] embody (or not embody) the team's values in practice?
---
### Section 6: Overall & Development
**Open questions (all reviewers):**
1. What is [Name]'s single most important strength? Give a specific example.
2. What is the one behaviour or habit that, if changed, would most increase [Name]'s effectiveness?
3. Is there anything else you want [Name] to know? (This response will be shared directly.)
---
## Output B: 360 Feedback Report
---
# 360 Feedback Report: [Name] — [Role]
**Review cycle:** [Quarter / Year / Promotion cycle]
**Responses received:** [X total — X peers, X direct reports, X managers, X cross-functional]
**Report prepared by:** [HR / People team / Manager / Coach]
**Date:** [Date]
> This report synthesises feedback from [X] reviewers. Open-ended responses have been lightly edited for clarity; no individual response is attributed to protect reviewer confidentiality. Direct quotes marked in *italics* appear verbatim.
---
### Executive Summary
[3–4 sentences. State the overall picture: what is this person known for, what is working well, and what one or two areas are the consistent development themes. Balanced, honest, and grounded in the data — not a sanitised summary.]
**Overall rating:** [X.X / 5.0 — above average / at level / below expectations for level]
---
### Strengths: What to Build On
**Theme 1: [Strength — e.g. Reliability and follow-through]**
[2–3 sentences synthesising the feedback evidence for this strength. Reference how many reviewers noted it and in what contexts.]
*"[Direct quote from reviewer that best illustrates this theme]"*
---
**Theme 2: [Strength — e.g. Collaborative problem-solving]**
[2–3 sentences synthesising evidence.]
*"[Direct quote]"*
---
**Theme 3: [Strength — e.g. Clear communication under pressure]**
[2–3 sentences synthesising evidence.]
*"[Direct quote]"*
---
### Development Areas: What to Work On
**Theme 1: [Development area — e.g. Giving timely upward feedback]**
[2–3 sentences describing the behaviour pattern observed, what impact it has, and what different looks like. Non-blaming and specific.]
*"[Direct quote that captures the theme]"*
**Suggested actions:**
- [Specific, observable behaviour change — e.g. In the next team meeting where you disagree with a decision, name your concern in the meeting rather than after it]
- [Development resource or practice — e.g. Try the "I notice / I wonder / I suggest" framework for giving difficult feedback]
---
**Theme 2: [Development area — e.g. Strategic communication to leadership]**
[2–3 sentences.]
*"[Direct quote]"*
**Suggested actions:**
- [...]
- [...]
---
### Ratings Summary
| Competency | Average score | Range | Notable pattern |
|---|---|---|---|
| Delivery & Execution | [X.X] | [X–X] | [e.g. Consistently high; one outlier] |
| Communication & Collaboration | [X.X] | [X–X] | [e.g. Peers score higher than direct reports] |
| Leadership & Influence | [X.X] | [X–X] | [...] |
| Strategic Thinking | [X.X] | [X–X] | [...] |
| Culture & Values | [X.X] | [X–X] | [...] |
| **Overall** | **[X.X]** | [X–X] | |
**Score variance:** [Is there high agreement or wide spread across reviewers? High variance suggests the behaviour is context-dependent — explore when and with whom.]
---
### Direct Message from Reviewers
[Include up to 3 unedited quotes from the "Is there anything else you want [Name] to know?" question. These are shared verbatim as agreed in the survey instructions.]
*"[Quote 1]"*
*"[Quote 2]"*
*"[Quote 3]"*
---
### Recommended Focus for the Next 90 Days
[1–2 specific, measurable development commitments. Written to be agreed in the feedback conversation — not prescriptive.]
1. **[Behaviour to change]:** [What does success look like at 90 days? How will we measure it?]
2. **[Skill to build]:** [What specific resource, practice, or support will help? Who will observe progress?]
---
## Quality Checks
- [ ] Survey questions are behaviourally anchored — they describe observable actions, not attitudes
- [ ] Open-ended questions ask for specific examples — not general impressions
- [ ] Report strengths are backed by specific evidence, not generic praise
- [ ] Development areas name the behaviour and its impact — not the person's character
- [ ] Suggested actions are specific enough that the reviewee knows exactly what to do differently on Monday
- [ ] Direct quotes are genuinely direct — not paraphrased into blandness
## Example Trigger Phrases
- "Build a 360 feedback survey for a [role] at senior level"
- "Write a 360 feedback report from these notes: [paste notes]"
- "Design a 360 review template for engineering managers"
- "Help me write constructive 360 feedback for my colleague [Name]"
- "Create a peer feedback survey for our upcoming performance cycle"
plugins/pm-people/skills/team-health-check/SKILL.md
+262
View File
@@ -0,0 +1,262 @@
---
name: team-health-check
description: "Run a structured team health assessment. Use when asked to run a team health check, assess team morale, facilitate a team retrospective on ways of working, or evaluate team dynamics. Produces a health assessment across key dimensions with RAG status, underlying signals, and prioritised improvement actions."
---
# Team Health Check Skill
This skill produces a structured team health assessment inspired by Spotify's health check model and extended with engineering, product, and cross-functional team dimensions. Output can be used as a facilitation guide for a live session or as an async survey-and-report format.
## Required Inputs
Ask the user for these if not provided:
- **Team name and function** (engineering squad, product team, sales pod, etc.)
- **Team size and composition** (how many people, what roles)
- **Format** — facilitated live session or async survey + report?
- **Context** — why are you running this now? (new team / ongoing ritual / post-incident / low morale signal)
- **Any known issues** — anything the facilitator knows going in that will colour the results?
## Output Structure
---
# Team Health Check: [Team Name]
**Date:** [Date]
**Facilitated by:** [Name or role]
**Team size:** [X people]
**Format:** [Live session (60 min) / Async survey + report]
**Cycle:** [One-off / Quarterly / Monthly]
---
## Part 1: Facilitation Guide (Live Session)
Use this guide to run the session in 60 minutes.
### Session structure
| Time | Activity | Owner |
|---|---|---|
| 0–5 min | Framing and ground rules | Facilitator |
| 5–40 min | Card voting — 7 dimensions, 5 min each | Full team |
| 40–50 min | Top 3 themes discussion | Full team |
| 50–58 min | Actions and owners | Team lead |
| 58–60 min | Close and next date | Facilitator |
### Ground rules (read at start)
- This is not a performance review — there are no wrong answers
- We're assessing the team, not individuals — speak about "we" not "they"
- What's said here stays here — results shared as aggregated themes, not attributed to individuals
- The goal is one or two actionable improvements, not a long list
### Voting mechanic
For each dimension, each team member votes with one of three cards:
- 🟢 **Green** — working well, we're proud of this
- 🟡 **Amber** — some things work, but there are issues worth discussing
- 🔴 **Red** — we have a real problem here that's slowing us down
After voting, the team discusses: what drove the votes? What would make this Green?
---
## Part 2: Health Dimensions
---
### Dimension 1: Delivering Value
*Are we shipping things that matter, at the pace we should?*
| Indicator | Probes for discussion |
|---|---|
| We ship work that creates real value for our users | How do we know our output is valuable? When did we last talk to a user? |
| Our pace of delivery feels healthy and sustainable | Are we consistently shipping? Or do we have long dry spells? |
| We have clarity on what "done" looks like | Do we have a shared definition of ready and done? |
| We celebrate shipping, not just building | Do we acknowledge completed work, or does it just disappear into the backlog? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 2: Easy to Release
*Is releasing software (or our work) smooth and low-risk?*
| Indicator | Probes for discussion |
|---|---|
| We can release whenever we choose, without anxiety | What does a release feel like? Smooth or stressful? |
| Our deployment process is automated and reliable | How much manual work does a release involve? |
| We have confidence in our test coverage | Do we catch bugs before users do? |
| Rollback is fast and rehearsed | Have we ever rolled back? How long did it take? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 3: Fun & Morale
*Do people enjoy working here and with each other?*
| Indicator | Probes for discussion |
|---|---|
| People generally enjoy coming to work | If you had to describe the team energy in one word, what would it be? |
| We celebrate successes as a team | When did we last properly celebrate something? |
| Interpersonal dynamics are healthy — no drama or cliques | Are there any relationships that are strained or avoided? |
| We laugh and have non-work conversations | Do we know each other as people, not just colleagues? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 4: Psychological Safety
*Can people speak up, take risks, and make mistakes without fear?*
| Indicator | Probes for discussion |
|---|---|
| People raise concerns without worrying about the consequences | When did someone last raise a concern publicly? What happened? |
| Mistakes are treated as learning opportunities, not blame events | Think of the last mistake on the team. How was it handled? |
| People challenge each other's ideas in a constructive way | Do we have real debates, or do we agree in the room and disagree in the corridor? |
| Everyone's voice feels equally heard regardless of seniority | Do the same people always speak first and longest? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 5: Speed & Feedback Loops
*Do we learn fast and adjust quickly?*
| Indicator | Probes for discussion |
|---|---|
| We get feedback on our work quickly (from users, data, tests) | How long after shipping do we know if something worked? |
| Our planning and retrospective cycles help us improve | Do retros lead to real change, or do the same issues come back? |
| We cut work that isn't working, even when it's hard | Can you name something we've stopped doing because it wasn't working? |
| Our meetings and processes don't slow us down | Which meetings do people dread? Which do they find valuable? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 6: Mission & Purpose
*Do we understand why our work matters?*
| Indicator | Probes for discussion |
|---|---|
| Everyone on the team can articulate why their work matters | Could each person on this team explain to a stranger why their work is important? |
| The team's goals are clear and shared | Can everyone name the team's top 3 priorities right now? |
| Our work connects to the wider company direction | Do we understand how we fit into the bigger picture? |
| We're proud of what this team builds | If you described your team's work to someone you respect, would you feel good about it? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 7: Collaboration & Support
*Do we work well together and support each other?*
| Indicator | Probes for discussion |
|---|---|
| People actively help each other when someone is stuck | Think of the last time someone was blocked — what happened? |
| Knowledge is shared openly — no information silos | Is there any knowledge that only one person holds? What's the risk? |
| Cross-team collaboration is smooth and low-friction | Which team is hardest to collaborate with and why? |
| People feel supported when they're struggling | Is there psychological safety to say "I'm struggling with this"? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
## Part 3: Health Summary & Report
Use this template to document results after the session or survey.
---
### RAG Summary Dashboard
| Dimension | Score | Status | Trend vs last quarter |
|---|---|---|---|
| Delivering Value | [X/5] | 🟢 / 🟡 / 🔴 | [↑ / → / ↓] |
| Easy to Release | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Fun & Morale | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Psychological Safety | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Speed & Feedback Loops | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Mission & Purpose | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Collaboration & Support | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| **Overall** | **[X/5]** | 🟢 / 🟡 / 🔴 | [↑ / → / ↓] |
---
### Top Themes
**What's working well (keep doing):**
1. [...]
2. [...]
**What needs attention (most important to fix):**
1. [Most pressing issue — specific, with evidence from the session]
2. [Second issue]
3. [Third issue — if applicable]
---
### Action Plan
| Action | Owner | Due date | Success indicator |
|---|---|---|---|
| [Specific action — e.g. Introduce pairing Fridays for knowledge sharing] | [Team lead / individual] | [Date] | [How will we know it worked?] |
| [...] | [...] | [...] | [...] |
**Next health check:** [Date — recommended 6–8 weeks for teams with active improvement actions, 13 weeks for steady-state teams]
---
## Quality Checks
- [ ] Session ground rules established psychological safety before voting started
- [ ] Each dimension had open discussion, not just a vote
- [ ] Actions are specific enough to be verifiably done — no vague commitments like "improve communication"
- [ ] Each action has a single owner — not "the team"
- [ ] Results are shared with the team, not kept by management
- [ ] Trend data is tracked across cycles to show improvement or regression
## Example Trigger Phrases
- "Run a team health check for my engineering squad"
- "Facilitate a team health assessment — we've had some morale issues"
- "Build a team health check survey for my product team"
- "Generate a Spotify-style health check for our cross-functional pod"
- "Create a quarterly team health check template"
plugins/pm-sales/skills/partnership-proposal/SKILL.md
+228
View File
@@ -0,0 +1,228 @@
---
name: partnership-proposal
description: "Write a B2B partnership proposal or business case. Use when asked to write a partnership proposal, draft a partnership brief, structure a co-marketing proposal, or create a business case for a strategic partnership. Produces a structured proposal with value proposition, partnership model, commercial terms, and mutual commitments."
---
# Partnership Proposal Skill
This skill produces a complete B2B partnership proposal covering the partnership rationale, mutual value, partnership model, commercial terms, governance, and a joint go-to-market plan. Output is ready to share with a prospective partner or use as the basis for a business case to internal stakeholders.
## Required Inputs
Ask the user for these if not provided:
- **Your company** — name, what you do, and the audience you serve
- **Prospective partner** — name, what they do, and their audience
- **Partnership type** — technology integration / co-marketing / reseller / referral / strategic alliance / OEM
- **Partnership goal** — what does each party get? (new customers / revenue / product capability / market reach)
- **Proposed commercial model** — revenue share, referral fee, licensing, co-investment?
- **Urgency or context** — is there a specific event, product launch, or competitive reason for this partnership?
## Output Structure
---
# Partnership Proposal: [Your Company] × [Partner Company]
**Prepared by:** [Name, Role at Your Company]
**Date:** [Date]
**Partnership type:** [Technology / Co-marketing / Reseller / Referral / Strategic Alliance]
**Proposal status:** [Initial proposal / For negotiation / Final]
---
## Executive Summary
[3–5 sentences. Answer: what are we proposing, why now, and what does each party stand to gain? Write this so a busy executive can understand the proposal in 60 seconds without reading further.]
**Headline value for [Partner]:**
> [One sentence — the most compelling thing this partnership does for them]
**Headline value for [Your Company]:**
> [One sentence — the most compelling thing this partnership does for you]
---
## 1. The Opportunity
**Market context:** [Why does this partnership make sense now? What's happening in the market that creates a window for this to work?]
**Shared customer:** [Describe the customer both organisations serve — the overlap that makes this logical. Include size of the shared addressable market if you have it.]
**Problem neither of us solves alone:** [What can't either party do for the shared customer independently that the partnership would enable?]
---
## 2. What We're Proposing
**Partnership model:**
| Element | Description |
|---|---|
| **Type** | [Technology integration / Co-marketing / Reseller / Referral / OEM] |
| **Scope** | [What specifically are we partnering on? — product features, joint campaigns, distribution, etc.] |
| **Exclusivity** | [Exclusive in [region/segment] / Non-exclusive / Right of first refusal] |
| **Duration** | [Initial term — e.g. 12 months, renewable] |
| **Geographic scope** | [UK / EMEA / Global / Specific markets] |
**What this looks like in practice:**
[3–5 bullet points describing what the partnership actually means day-to-day. Make it concrete and operational — not abstract. e.g.:]
- [Our product will natively integrate with [Partner's product] — the integration will be live in [timeframe]]
- [We will co-market to each other's customer bases — joint webinar, co-authored content, shared newsletter placement]
- [Each company will train a dedicated partnership contact who manages the relationship]
- [[Partner] will list [Your product] in their marketplace / app directory / referral programme]
---
## 3. Value Proposition — What Each Party Gets
### For [Partner]
| Value | Evidence / Basis |
|---|---|
| **[New customer reach]** | [e.g. Access to [Your Company]'s [X,000] [role] customers — [X%] of whom have expressed interest in [Partner's category]] |
| **[Product capability]** | [e.g. [Partner]'s product gains [capability] that [X%] of their customers have requested — based on [source]] |
| **[Revenue opportunity]** | [e.g. Estimated [£/$/€ X] in referral revenue in Year 1 based on [X%] conversion from shared pipeline] |
| **[Market differentiation]** | [e.g. The integration creates a meaningful competitive moat vs [Competitor] who lacks this capability] |
### For [Your Company]
| Value | Evidence / Basis |
|---|---|
| **[Distribution]** | [e.g. Access to [Partner]'s [X,000] customers in [segment] — a segment where we currently have [X] customers] |
| **[Credibility]** | [e.g. Association with [Partner]'s brand accelerates enterprise sales cycles — [Partner] is trusted by [X] of the Fortune 500] |
| **[Revenue]** | [e.g. Target [X] referral customers in Year 1 at average ACV of [£X] = [£X ARR]] |
| **[Product]** | [e.g. [Partner]'s data / capability enhances [specific part of our product] — improving [user outcome]] |
---
## 4. Commercial Model
**Proposed commercial terms:**
| Term | Proposal | Notes |
|---|---|---|
| **Revenue share** | [e.g. [X%] of ARR from customers referred by [Partner]] | [Standard in this category: [X–Y%] range] |
| **Referral fee** | [e.g. £[X] per qualified lead that converts] | [Or: flat fee per introduction vs % of closed deal] |
| **Licensing / access** | [e.g. [Partner] provides API access at no cost in exchange for integration and co-marketing] | [...] |
| **Co-marketing investment** | [e.g. Each party commits [£X] to joint marketing activities per quarter] | [...] |
| **Minimum commitment** | [e.g. [X] qualified referrals per quarter / [£X] GMV per year] | [Optional — only if there's a meaningful minimum that makes sense] |
**Payment terms:** [Monthly / Quarterly in arrears / Annual true-up]
**What we're not proposing:** [Be explicit about what's off the table — e.g. equity / exclusivity in all markets / upfront payment]
---
## 5. Joint Go-to-Market Plan
**Phase 1: Foundation (Months 1–2)**
| Activity | Owner | Timeline |
|---|---|---|
| Technical integration scoped and resourced | [Engineering at both companies] | [Month 1] |
| Partnership launch announcement drafted | [Marketing at both companies] | [Month 1] |
| Joint customer case study identified | [CSM at both companies] | [Month 2] |
| Partner enablement — each team trained on the other's product | [Partnership lead, both sides] | [Month 2] |
**Phase 2: Launch (Month 3)**
| Activity | Owner | Timeline |
|---|---|---|
| Integration live in both products / marketplace | [Engineering] | [Month 3] |
| Joint press release / blog post / email announcement | [Marketing] | [Month 3] |
| First joint webinar | [Both companies] | [Month 3] |
| First joint pipeline reviewed | [Partnership leads] | [Month 3] |
**Phase 3: Scale (Months 4–12)**
| Activity | Owner | Cadence |
|---|---|---|
| Co-sell on named accounts | [AE at both companies] | [Monthly] |
| Joint content (blog, webinar, case study) | [Marketing] | [Quarterly] |
| Pipeline and revenue review | [Partnership leads] | [Monthly] |
| Partnership QBR | [VP level, both companies] | [Quarterly] |
---
## 6. Success Metrics
How we'll know the partnership is working:
| Metric | Year 1 target | Measurement |
|---|---|---|
| Customers referred (each direction) | [X] | [CRM tracking — tagged as partner-sourced] |
| Revenue from partnership | [£/$/€ X ARR] | [CRM + finance reporting] |
| Integration adoption | [X% of mutual customers using integration] | [Product analytics] |
| Customer satisfaction with integration | [NPS ≥ X] | [Post-integration survey] |
| Joint pipeline generated | [£X] | [Quarterly pipeline review] |
**Review cadence:** Monthly partnership lead check-in + Quarterly business review at VP level
---
## 7. Governance & Operations
**Partnership contacts:**
| Role | [Your Company] | [Partner] |
|---|---|---|
| Partnership lead (day-to-day) | [Name, email] | [TBC] |
| Executive sponsor | [Name, title] | [TBC] |
| Technical lead | [Name] | [TBC] |
| Marketing lead | [Name] | [TBC] |
**Decision-making:**
- Day-to-day partnership operations: partnership leads
- Commercial term changes: VP-level approval from both parties
- Partnership termination: CEO/MD sign-off + [X days] written notice
**Legal framework:**
- [ ] Partnership agreement / MOU to be drafted by [Company]'s legal team
- [ ] Data processing agreement (if personal data is shared)
- [ ] NDAs: [already in place / to be signed before detailed discussions]
- [ ] IP ownership: [Clarify who owns jointly developed materials, integrations, content]
---
## 8. Risks & Mitigations
| Risk | Likelihood | Mitigation |
|---|---|---|
| Partnership champion leaves [Partner] | M | Ensure VP-level sponsorship; build multiple relationships |
| Integration takes longer than planned | M | Scope technical work in Phase 1; set realistic launch commitment |
| Low adoption of the integration | M | Include in onboarding for both products; co-market to existing customers not just new |
| Partner signs with our competitor | L | Discuss exclusivity options; prioritise quick launch to create switching costs |
| Commercial model becomes imbalanced | L | Quarterly review with clear exit terms if targets are consistently missed |
---
## 9. Proposed Next Steps
| # | Action | Owner | By when |
|---|---|---|---|
| 1 | [Partner] reviews this proposal and provides feedback | [[Partner name]] | [Date] |
| 2 | Both parties sign NDA (if not already in place) | [Legal, both sides] | [Before next meeting] |
| 3 | Technical discovery call — assess integration feasibility | [Engineering leads] | [Date] |
| 4 | Commercial terms negotiation | [Partnership leads / VP] | [Date] |
| 5 | MOU / partnership agreement drafted and signed | [Legal] | [Date] |
| 6 | Integration and launch planning begins | [Both teams] | [Date] |
---
## Quality Checks
- [ ] Value proposition for the partner is written from their perspective — not yours
- [ ] Commercial model includes specific numbers, not just structure
- [ ] "What we're not proposing" section prevents misaligned expectations
- [ ] Go-to-market plan has named owners and dates, not "TBD"
- [ ] Success metrics are agreed bilaterally — not set unilaterally
- [ ] Risks section includes the most uncomfortable risk (partner signs with a competitor)
## Example Trigger Phrases
- "Write a partnership proposal for [Company] to partner with [Partner]"
- "Draft a co-marketing partnership brief between us and [Partner]"
- "Create a reseller partnership proposal for [Company]"
- "Build the business case for a strategic partnership with [Partner]"
- "Structure a technology integration partnership proposal"
skills/360-feedback-template/SKILL.md
+256
View File
@@ -0,0 +1,256 @@
---
name: 360-feedback-template
description: "Design a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas."
---
# 360-Degree Feedback Template Skill
This skill produces two outputs depending on what the user needs: (1) a complete 360 survey instrument for gathering feedback, or (2) a structured 360 feedback report written from gathered notes. Both outputs follow best practice: behaviourally anchored ratings, specific examples, and development-oriented framing.
## Required Inputs
Ask the user which output they need, then gather inputs:
**For a survey instrument:**
- **Role being reviewed** (job title and level)
- **Competencies to assess** (or use defaults below)
- **Reviewer relationships** (peer / direct report / manager / cross-functional)
- **Rating scale preference** (1–5 / 1–4 / frequency-based)
- **Anonymity level** (fully anonymous / attributed / confidential aggregated)
**For a feedback report:**
- **Person being reviewed** (role and level)
- **Feedback notes or raw themes** from reviewers (paste what you have)
- **Reviewer relationships** (how many peers, direct reports, managers responded)
- **Any context** — performance cycle, specific behaviours to address, promotion consideration
---
## Output A: 360 Survey Instrument
---
# 360 Feedback Survey: [Role / Level]
**Purpose:** This survey helps [Name / "the reviewee"] understand how their behaviours and impact are perceived by the people they work with most closely. Responses [are / are not] anonymous. Results will be shared as [individual responses / aggregated themes].
**Instructions:** For each statement, rate how frequently you observe this behaviour. Add specific examples in the open-ended sections — these are the most valuable part of the survey.
**Rating scale:**
- **5 — Consistently:** Almost always demonstrates this behaviour, even in difficult situations
- **4 — Usually:** Demonstrates this behaviour more often than not
- **3 — Sometimes:** Demonstrates this behaviour inconsistently
- **2 — Rarely:** Seldom demonstrates this behaviour
- **1 — Not observed:** Have not had the opportunity to observe this behaviour
---
### Section 1: Delivery & Execution
| Statement | Rating (1–5) |
|---|---|
| Delivers work on time and to the expected quality | |
| Proactively flags risks and blockers before they become problems | |
| Follows through on commitments without needing to be chased | |
| Manages their workload effectively without compromising quality | |
| Adapts quickly when priorities or requirements change | |
**Open question:** Describe a specific time when [Name] handled a delivery challenge particularly well or poorly.
---
### Section 2: Communication & Collaboration
| Statement | Rating (1–5) |
|---|---|
| Communicates clearly and concisely in both written and verbal formats | |
| Listens actively and considers others' input before responding | |
| Keeps the right people informed without over-communicating | |
| Resolves disagreements constructively and without defensiveness | |
| Makes it easy for others to collaborate with them | |
**Open question:** Give an example of how [Name] handled a difficult or high-stakes communication.
---
### Section 3: Leadership & Influence
| Statement | Rating (1–5) |
|---|---|
| Sets a clear direction that others can follow | |
| Builds confidence and capability in people around them | |
| Influences decisions without relying on authority | |
| Gives clear, constructive feedback that helps others improve | |
| Creates an environment where people feel safe to raise concerns | |
**Open question:** Describe a situation where [Name]'s leadership had a notable positive or negative impact on the team.
---
### Section 4: Strategic Thinking
| Statement | Rating (1–5) |
|---|---|
| Understands the broader business context, not just their immediate work | |
| Makes connections between their work and organisational goals | |
| Thinks ahead and anticipates second-order consequences | |
| Brings original ideas or new approaches to problems | |
| Balances short-term needs with longer-term thinking | |
**Open question:** Give an example of [Name] demonstrating (or missing) strategic thinking.
---
### Section 5: Culture & Values
| Statement | Rating (1–5) |
|---|---|
| Treats everyone with respect, regardless of level or background | |
| Is someone people trust and can rely on | |
| Gives credit to others and shares the spotlight | |
| Takes responsibility for mistakes without placing blame | |
| Contributes positively to team morale, especially under pressure | |
**Open question:** How does [Name] embody (or not embody) the team's values in practice?
---
### Section 6: Overall & Development
**Open questions (all reviewers):**
1. What is [Name]'s single most important strength? Give a specific example.
2. What is the one behaviour or habit that, if changed, would most increase [Name]'s effectiveness?
3. Is there anything else you want [Name] to know? (This response will be shared directly.)
---
## Output B: 360 Feedback Report
---
# 360 Feedback Report: [Name] — [Role]
**Review cycle:** [Quarter / Year / Promotion cycle]
**Responses received:** [X total — X peers, X direct reports, X managers, X cross-functional]
**Report prepared by:** [HR / People team / Manager / Coach]
**Date:** [Date]
> This report synthesises feedback from [X] reviewers. Open-ended responses have been lightly edited for clarity; no individual response is attributed to protect reviewer confidentiality. Direct quotes marked in *italics* appear verbatim.
---
### Executive Summary
[3–4 sentences. State the overall picture: what is this person known for, what is working well, and what one or two areas are the consistent development themes. Balanced, honest, and grounded in the data — not a sanitised summary.]
**Overall rating:** [X.X / 5.0 — above average / at level / below expectations for level]
---
### Strengths: What to Build On
**Theme 1: [Strength — e.g. Reliability and follow-through]**
[2–3 sentences synthesising the feedback evidence for this strength. Reference how many reviewers noted it and in what contexts.]
*"[Direct quote from reviewer that best illustrates this theme]"*
---
**Theme 2: [Strength — e.g. Collaborative problem-solving]**
[2–3 sentences synthesising evidence.]
*"[Direct quote]"*
---
**Theme 3: [Strength — e.g. Clear communication under pressure]**
[2–3 sentences synthesising evidence.]
*"[Direct quote]"*
---
### Development Areas: What to Work On
**Theme 1: [Development area — e.g. Giving timely upward feedback]**
[2–3 sentences describing the behaviour pattern observed, what impact it has, and what different looks like. Non-blaming and specific.]
*"[Direct quote that captures the theme]"*
**Suggested actions:**
- [Specific, observable behaviour change — e.g. In the next team meeting where you disagree with a decision, name your concern in the meeting rather than after it]
- [Development resource or practice — e.g. Try the "I notice / I wonder / I suggest" framework for giving difficult feedback]
---
**Theme 2: [Development area — e.g. Strategic communication to leadership]**
[2–3 sentences.]
*"[Direct quote]"*
**Suggested actions:**
- [...]
- [...]
---
### Ratings Summary
| Competency | Average score | Range | Notable pattern |
|---|---|---|---|
| Delivery & Execution | [X.X] | [X–X] | [e.g. Consistently high; one outlier] |
| Communication & Collaboration | [X.X] | [X–X] | [e.g. Peers score higher than direct reports] |
| Leadership & Influence | [X.X] | [X–X] | [...] |
| Strategic Thinking | [X.X] | [X–X] | [...] |
| Culture & Values | [X.X] | [X–X] | [...] |
| **Overall** | **[X.X]** | [X–X] | |
**Score variance:** [Is there high agreement or wide spread across reviewers? High variance suggests the behaviour is context-dependent — explore when and with whom.]
---
### Direct Message from Reviewers
[Include up to 3 unedited quotes from the "Is there anything else you want [Name] to know?" question. These are shared verbatim as agreed in the survey instructions.]
*"[Quote 1]"*
*"[Quote 2]"*
*"[Quote 3]"*
---
### Recommended Focus for the Next 90 Days
[1–2 specific, measurable development commitments. Written to be agreed in the feedback conversation — not prescriptive.]
1. **[Behaviour to change]:** [What does success look like at 90 days? How will we measure it?]
2. **[Skill to build]:** [What specific resource, practice, or support will help? Who will observe progress?]
---
## Quality Checks
- [ ] Survey questions are behaviourally anchored — they describe observable actions, not attitudes
- [ ] Open-ended questions ask for specific examples — not general impressions
- [ ] Report strengths are backed by specific evidence, not generic praise
- [ ] Development areas name the behaviour and its impact — not the person's character
- [ ] Suggested actions are specific enough that the reviewee knows exactly what to do differently on Monday
- [ ] Direct quotes are genuinely direct — not paraphrased into blandness
## Example Trigger Phrases
- "Build a 360 feedback survey for a [role] at senior level"
- "Write a 360 feedback report from these notes: [paste notes]"
- "Design a 360 review template for engineering managers"
- "Help me write constructive 360 feedback for my colleague [Name]"
- "Create a peer feedback survey for our upcoming performance cycle"
skills/ai-ethics-review/SKILL.md
+207
View File
@@ -0,0 +1,207 @@
---
name: ai-ethics-review
description: "Conduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations."
---
# AI Ethics Review Skill
This skill produces a structured ethical review of an AI or machine learning feature, model, or product. Output covers fairness, transparency, privacy, safety, accountability, and societal impact — with risk scoring, prioritised mitigations, and a checklist suitable for governance review or responsible AI documentation.
> ⚠️ This skill provides a structured framework for identifying and documenting ethical risks. It is not a substitute for legal advice, regulated algorithmic impact assessments, or specialist ethics review required in specific jurisdictions (e.g. EU AI Act, UK AI regulation).
## Required Inputs
Ask the user for these if not provided:
- **Feature or model name** and what it does
- **Who it affects** — which users or people does the AI interact with, make decisions about, or collect data from?
- **What decisions or outputs it produces** — recommendations, predictions, classifications, generation, automation?
- **Consequentiality** — how significant are the AI's decisions? (low-stakes suggestions vs decisions that affect employment, credit, health, safety, etc.)
- **Data used** — what training data, user data, or third-party data is used?
- **Human oversight** — is there a human in the loop, and at what stage?
- **Deployment context** — who will use this and how? (internal tool / consumer-facing / automated pipeline)
## Output Structure
---
# AI Ethics Review: [Feature / Model Name]
**Product / system:** [Name and brief description]
**Review type:** [Pre-deployment review / Post-deployment audit / Change review]
**Risk tier:** [High / Medium / Low — based on consequentiality, scale, and affected population]
**Reviewer:** [Name / Team]
**Date:** [Date]
**Status:** [Draft / Approved / Requires escalation]
---
## 1. Feature Summary
| | |
|---|---|
| **What it does** | [1–2 sentences — plain English description of the AI feature and its purpose] |
| **Who uses it** | [End users / internal teams / automated system] |
| **Who is affected by its outputs** | [May be different from who uses it — e.g. an AI hiring tool is used by HR but affects candidates] |
| **Output type** | [Recommendation / Classification / Prediction / Generation / Automation / Scoring] |
| **Scale** | [How many people affected per day/month?] |
| **Consequentiality** | [High: affects access to services, employment, credit, health, safety / Medium: influences decisions / Low: suggestions with easy override] |
| **Human oversight level** | [Full automation / Human review before action / Human can override after action / Advisory only] |
---
## 2. Risk Tier Assessment
| Factor | Score (1–3) | Rationale |
|---|---|---|
| **Consequentiality** (impact on individuals) | [1=low, 3=high] | [e.g. 3 — model output influences hiring decisions] |
| **Scale** (number of people affected) | [1=few, 3=many] | [e.g. 2 — internal tool used for ~500 candidates/year] |
| **Reversibility** (can harm be undone?) | [1=reversible, 3=irreversible] | [e.g. 2 — unfair rejection can be appealed but may not be caught] |
| **Vulnerability of affected group** | [1=general population, 3=protected or vulnerable group] | [e.g. 2 — includes protected characteristics in the decision context] |
| **Transparency** (do affected people know?) | [1=informed, 3=opaque] | [e.g. 3 — candidates are not told AI is used in screening] |
**Composite risk tier:** [High (12–15) / Medium (7–11) / Low (3–6)]
**Risk tier implications:**
- **High:** Mandatory senior ethics review, DPA/DPIA required, human-in-loop for all consequential decisions, ongoing monitoring required
- **Medium:** Ethics review recommended, document mitigations, quarterly monitoring
- **Low:** Standard review, document assumptions, annual review
---
## 3. Fairness & Bias
*Does the AI treat people equitably across groups?*
**Protected characteristics relevant to this feature:**
[List applicable protected characteristics — age, gender, race/ethnicity, disability, religion, national origin, etc.]
| Risk | Analysis | Mitigation |
|---|---|---|
| **Training data bias** | [Does the training data reflect historical discrimination? e.g. hiring data that reflects past biases in who was hired] | [Audit training data for demographic representation / use debiasing techniques / document data lineage] |
| **Proxy discrimination** | [Could the model use a proxy for a protected characteristic? e.g. using postcode as a proxy for race] | [Identify proxy features / test for disparate impact using adversarial debiasing] |
| **Differential performance** | [Does the model perform differently across demographic groups? — e.g. lower accuracy for underrepresented groups] | [Disaggregate performance metrics by group / set minimum performance thresholds per group] |
| **Feedback loops** | [Does the model's output reinforce existing disparities? e.g. recommending content that keeps disadvantaged groups in lower-engagement patterns] | [Monitor outcome distributions over time / implement feedback loop detection] |
**Fairness evaluation method:** [What method will be used to measure fairness — statistical parity / equalised odds / individual fairness? Who is responsible for running it and how often?]
---
## 4. Transparency & Explainability
*Can affected people understand how the AI makes decisions?*
| Dimension | Current state | Required state | Gap |
|---|---|---|---|
| **User disclosure** | [Are users told they're interacting with AI?] | [Yes — required for trust and regulation] | [e.g. No disclosure on current UI] |
| **Decision explanation** | [Can the system explain why it reached a conclusion?] | [For high-stakes decisions: yes] | [e.g. Black-box model — no feature attribution available] |
| **Right to know** | [Can affected people ask how a decision was made?] | [Yes — required under GDPR Art. 22 for automated decisions] | [e.g. No process exists] |
| **Confidence calibration** | [Does the model express appropriate uncertainty?] | [Yes — overconfident models cause over-reliance] | [e.g. Model outputs binary label without confidence score] |
**Explainability approach:** [LIME / SHAP / rule-based surrogate / LLM-generated rationale / none — and why]
---
## 5. Privacy & Data
*Is personal data used responsibly and lawfully?*
| Risk | Analysis | Mitigation |
|---|---|---|
| **Data minimisation** | [Does the model use more personal data than necessary?] | [Audit input features — remove any that don't improve performance and involve unnecessary data collection] |
| **Data retention** | [How long is personal data retained for training and inference?] | [Define retention policy aligned to GDPR / CCPA / sector requirements] |
| **Re-identification risk** | [Could model outputs or training data be used to identify individuals?] | [Differential privacy / k-anonymity / output rate limiting] |
| **Third-party data** | [Is data from third parties used? Is it licensed for this use?] | [Audit data licensing / get legal sign-off on each third-party source] |
| **Cross-border data transfer** | [Is personal data transferred across jurisdictions?] | [Legal review — Standard Contractual Clauses or equivalent] |
**DPIA required?** [Yes / No / Uncertain — for High tier or whenever processing is likely to result in high risk to individuals under GDPR Art. 35]
---
## 6. Safety & Reliability
*What happens when the AI gets it wrong?*
| Failure mode | Likelihood | Impact | Mitigation |
|---|---|---|---|
| **False positives** | [H/M/L] | [e.g. Flagging a legitimate transaction as fraud — customer locked out] | [Set threshold conservatively; human review for edge cases] |
| **False negatives** | [H/M/L] | [e.g. Missing a real fraud case — financial loss] | [Monitor false negative rate; set minimum recall threshold] |
| **Out-of-distribution inputs** | [H/M/L] | [Model behaves unpredictably on inputs outside training distribution] | [Input validation; confidence thresholding — route uncertain inputs to human review] |
| **Model degradation** | [M] | [Performance degrades as data distributions shift post-deployment] | [Scheduled performance monitoring; drift detection alerts] |
| **Adversarial inputs** | [L/M] | [Deliberate manipulation of inputs to game the model] | [Adversarial testing; rate limiting; anomaly detection on inputs] |
| **Single point of failure** | [L/M] | [Model outage causes downstream system failure] | [Graceful degradation — define fallback behaviour when model is unavailable] |
**Fallback behaviour:** [What happens if the AI is unavailable or returns low-confidence output? — e.g. route to human review / use rule-based fallback / block the action]
---
## 7. Accountability & Governance
*Who is responsible when things go wrong?*
| Question | Answer |
|---|---|
| **Who owns this AI feature?** | [Team or individual with end-to-end accountability] |
| **Who approved deployment?** | [Name and role — must be documented] |
| **Who is responsible for ongoing monitoring?** | [Team and cadence] |
| **Who can shut it down?** | [Who has kill-switch authority and under what conditions?] |
| **How are incidents reported?** | [Internal escalation path + external disclosure process if required] |
| **Is this subject to regulation?** | [EU AI Act / UK AI regulation / sector-specific rules — FINRA, FDA, FCA, etc.] |
**Incident response plan:** [Link to or describe what happens if the model causes harm — detection, escalation, remediation, disclosure]
---
## 8. Societal Impact
*Beyond individual users — what are the broader effects?*
| Impact area | Risk | Mitigation |
|---|---|---|
| **Labour displacement** | [Does this AI automate tasks that currently employ people?] | [Transition plan / human-AI collaboration framing / skills retraining commitment] |
| **Environmental impact** | [What is the carbon cost of training and inference?] | [Measure and offset; prefer efficient architectures; use renewable-energy infrastructure where possible] |
| **Power concentration** | [Does this AI give the deploying organisation disproportionate power over individuals?] | [Ensure right to opt out; avoid lock-in; consider open alternatives] |
| **Information ecosystem** | [Could this AI contribute to misinformation, filter bubbles, or manipulation?] | [Provenance labelling / content policies / algorithmic diversity requirements] |
---
## 9. Mitigation Priorities
| # | Risk | Severity | Action | Owner | Deadline |
|---|---|---|---|---|---|
| 1 | [Highest risk — e.g. No disclosure to affected candidates] | Critical | [Add AI disclosure to UI and candidate-facing documentation] | [PM + Legal] | [Before launch] |
| 2 | [e.g. No fairness evaluation across demographic groups] | High | [Commission third-party fairness audit using [method]] | [ML team + external auditor] | [Within 30 days of launch] |
| 3 | [e.g. No model monitoring in place] | High | [Deploy performance and drift monitoring dashboard] | [ML Ops] | [Launch day] |
| 4 | [e.g. DPIA not completed] | High | [Complete DPIA with DPO before deployment] | [Legal / DPO] | [Before launch] |
---
## 10. Pre-Deployment Checklist
- [ ] Ethics review completed and approved by required reviewers
- [ ] DPIA completed (if required)
- [ ] Fairness evaluation completed and results documented
- [ ] AI disclosure is in place wherever required
- [ ] Human oversight mechanism is defined and tested
- [ ] Kill-switch and escalation path is documented and tested
- [ ] Model monitoring is deployed and alerting is configured
- [ ] Data lineage and training data audit documented
- [ ] Legal sign-off obtained on data licensing and cross-border transfers
- [ ] Incident response plan in place
---
## Quality Checks
- [ ] "Who is affected" includes people the AI makes decisions *about*, not just who uses the product
- [ ] Fairness analysis names specific protected characteristics, not just "diverse groups"
- [ ] Safety section covers both false positive and false negative failure modes
- [ ] Accountability section names real people, not teams or roles
- [ ] Mitigations are specific and time-bound — not "monitor and review"
## Example Trigger Phrases
- "Run an AI ethics review for [feature]"
- "Conduct an ethical impact assessment for our new ML model"
- "Review the AI risks for our hiring / credit / recommendation system"
- "Build a responsible AI checklist for our product"
- "What are the ethical risks of using AI for [use case]?"
skills/cohort-analysis/SKILL.md
+187
View File
@@ -0,0 +1,187 @@
---
name: cohort-analysis
description: "Structure a cohort analysis for retention, LTV, or behavioural patterns. Use when asked to run a cohort analysis, analyse retention by cohort, segment users by behaviour over time, or calculate lifetime value by acquisition period. Produces a complete cohort analysis framework with methodology, cohort definitions, retention curves, and prioritised interventions."
---
# Cohort Analysis Skill
This skill produces a structured cohort analysis covering retention curves, LTV estimation, behavioural segmentation, and actionable interventions. Output is ready to present to product leadership or share with growth and data teams.
## Required Inputs
Ask the user for these if not provided:
- **Analysis goal** (retention improvement / LTV modelling / behavioural segmentation / churn prediction)
- **Product or feature being analysed**
- **Cohort definition** — what groups users? (acquisition month, signup channel, plan tier, feature adoption)
- **Observation window** — how many periods to track? (e.g. 12 months, 8 weeks)
- **Key metric** — what are you measuring per cohort? (retention rate, revenue, engagement score, feature usage)
- **Available data** — what tables/metrics are available? (paste schema or describe)
- **Baseline** — any existing retention benchmarks or goals?
## Output Structure
---
# Cohort Analysis: [Product / Feature]
**Analysis type:** [Retention / LTV / Behavioural / Churn]
**Cohort definition:** [Acquisition month / Signup channel / Plan tier / Feature adoption date]
**Observation window:** [X months / weeks]
**Primary metric:** [Metric name]
**Date prepared:** [Date]
---
## 1. Cohort Definitions
| Cohort | Period | Size | Description |
|---|---|---|---|
| [Cohort 1] | [Jan 2025] | [N users] | [e.g. Users who signed up in Jan 2025 via organic] |
| [Cohort 2] | [Feb 2025] | [N users] | [...] |
**Cohort logic:**
- Cohort entry event: [First sign-up / First purchase / Feature activation]
- Cohort exit criteria: [Churned / Downgraded / No activity for 30 days]
- Exclusions: [Trial users / Internal test accounts / Users with < X days of data]
---
## 2. Retention Curve
**How to read:** Each cell shows what % of the cohort performed the key metric in period N.
| Cohort | Period 0 | Period 1 | Period 2 | Period 3 | Period 6 | Period 12 |
|---|---|---|---|---|---|---|
| Jan 2025 | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
| Feb 2025 | 100% | [X%] | [X%] | [X%] | [X%] | [X%] |
| [Trend] | — | [↑/↓ vs prior] | [...] | [...] | [...] | [...] |
**Retention plateau:** [At what period does retention flatten? What % does it flatten at?]
**Key observations:**
- [e.g. Period 1 → Period 2 drop is the largest — average X% churn in first 30 days]
- [e.g. Cohorts acquired via [channel] retain X% better at Period 6]
- [e.g. Retention has improved from X% → Y% at Period 3 comparing oldest to newest cohort]
---
## 3. LTV Projection (if applicable)
**ARPU per period:** [£/$/€ X per active user per month]
**Retention curve used:** [Which cohort or blended average]
| Period | Retained % | Revenue per user | Cumulative LTV |
|---|---|---|---|
| Month 1 | [X%] | [£X] | [£X] |
| Month 3 | [X%] | [£X] | [£X] |
| Month 6 | [X%] | [£X] | [£X] |
| Month 12 | [X%] | [£X] | [£X] |
**Blended LTV:** [£X at 12 months — based on blended retention across cohorts]
**LTV by segment:**
| Segment | LTV (12M) | vs Baseline |
|---|---|---|
| [Organic] | [£X] | [+X%] |
| [Paid] | [£X] | [-X%] |
| [Enterprise] | [£X] | [+X%] |
---
## 4. Behavioural Segmentation
Group cohorts by behaviour patterns, not just acquisition date:
| Segment | Definition | Size | Retention (P6) | LTV (12M) |
|---|---|---|---|---|
| **Power users** | [Used core feature ≥ 3x/week in first 30 days] | [X%] | [X%] | [£X] |
| **Casual users** | [Used 1–2x/week in first 30 days] | [X%] | [X%] | [£X] |
| **Dormant** | [Logged in but did not use core feature] | [X%] | [X%] | [£X] |
| **Never activated** | [Signed up but never completed onboarding] | [X%] | [X%] | [£X] |
**Activation threshold insight:** [What action — taken within the first X days — most strongly predicts retention? This is the "aha moment" to optimise for.]
---
## 5. Leading Indicators of Churn
List the signals that appear **before** users churn, so teams can intervene:
| Signal | How early does it appear? | Churn correlation | Intervention |
|---|---|---|---|
| [No login for 7 days] | [7 days before churn] | [Strong] | [Re-engagement email sequence] |
| [Support ticket with escalation] | [14 days before churn] | [Moderate] | [CSM outreach within 48 hours] |
| [Feature usage dropped >50% WoW] | [10 days before churn] | [Strong] | [In-app nudge with use-case tutorial] |
---
## 6. Cohort Comparison: What's Changed Over Time
Compare oldest and newest cohorts to assess whether product improvements are showing up in retention:
| Metric | [Oldest cohort — e.g. Jan 2024] | [Newest cohort — e.g. Jan 2025] | Change |
|---|---|---|---|
| Period 1 retention | [X%] | [X%] | [↑/↓ X pp] |
| Period 3 retention | [X%] | [X%] | [↑/↓ X pp] |
| Activation rate | [X%] | [X%] | [↑/↓ X pp] |
| Avg. sessions in first 30 days | [X] | [X] | [↑/↓] |
**Verdict:** [Are more recent cohorts performing better or worse? What shipped in that period that might explain the change?]
---
## 7. Recommendations
Prioritise by impact on retention curve:
| # | Recommendation | Target segment | Expected impact | Effort | Priority |
|---|---|---|---|---|---|
| 1 | [e.g. Redesign onboarding to hit activation milestone in day 1, not day 7] | [Never-activated segment] | [+X pp P1 retention] | [Medium] | P1 |
| 2 | [e.g. Launch re-engagement sequence at day 7 inactivity trigger] | [Dormant segment] | [+X pp P2 retention] | [Low] | P1 |
| 3 | [e.g. Introduce power-user features earlier to accelerate habit formation] | [Casual users] | [+X pp P6 LTV] | [High] | P2 |
---
## 8. SQL Reference (if applicable)
Provide the core cohort query so data teams can replicate or extend the analysis:
```sql
-- Retention cohort query
SELECT
DATE_TRUNC('month', u.created_at) AS cohort_month,
DATE_TRUNC('month', e.event_date) AS activity_month,
DATEDIFF('month', u.created_at, e.event_date) AS period,
COUNT(DISTINCT e.user_id) AS retained_users,
COUNT(DISTINCT c.user_id) AS cohort_size,
ROUND(COUNT(DISTINCT e.user_id) * 100.0 / COUNT(DISTINCT c.user_id), 1) AS retention_rate
FROM users u
JOIN events e ON u.user_id = e.user_id
JOIN (
SELECT user_id, DATE_TRUNC('month', created_at) AS cohort_month
FROM users
WHERE created_at >= '[start_date]'
) c ON u.user_id = c.user_id AND DATE_TRUNC('month', u.created_at) = c.cohort_month
WHERE e.event_type = '[key_retention_event]'
GROUP BY 1, 2, 3
ORDER BY 1, 3;
```
---
## Quality Checks
- [ ] Cohort definition is unambiguous — the same user cannot appear in two cohorts
- [ ] Retention curve shows a clear plateau, or the analysis notes that the window is too short to see one
- [ ] LTV projection uses observed retention, not assumed
- [ ] Behavioural segments are mutually exclusive and exhaustive
- [ ] Recommendations are tied to specific cohort or segment findings — not generic growth advice
- [ ] Leading indicators are observable in production data, not just in theory
## Example Trigger Phrases
- "Run a cohort analysis for our SaaS product"
- "Analyse retention by acquisition month for the last 12 cohorts"
- "What's the LTV of users who came via paid vs organic?"
- "Build a cohort retention model showing period 0 through period 12"
- "Segment users by behaviour and show me which group retains best"
skills/customer-journey-map/SKILL.md
+215
View File
@@ -0,0 +1,215 @@
---
name: customer-journey-map
description: "Build a customer journey map for a product, service, or experience. Use when asked to map a customer journey, create a user journey, document touchpoints and pain points, or design an experience map. Produces a complete journey map with stages, touchpoints, emotions, pain points, and prioritised opportunities."
---
# Customer Journey Map Skill
This skill produces a complete customer journey map covering every stage from awareness through advocacy. Each stage includes touchpoints, customer actions, emotions, pain points, and specific improvement opportunities. Output is ready for use in product discovery, UX design, or cross-functional alignment workshops.
## Required Inputs
Ask the user for these if not provided:
- **Product or service** being mapped
- **Customer persona** — which customer segment is this map for? (be specific — one persona per map)
- **Journey scope** — full end-to-end (awareness → advocacy), or a specific phase (e.g. onboarding only)?
- **Current state or future state?** — mapping how it works today, or designing how it should work?
- **Data sources** — any research, user interviews, support tickets, NPS comments, analytics available?
- **Goal of the map** — what decision will this inform? (redesign, prioritisation, stakeholder alignment, new feature)
## Output Structure
---
# Customer Journey Map: [Product / Service]
**Persona:** [Name — e.g. "Sarah, the overwhelmed HR manager"]
**Journey scope:** [Full end-to-end / Onboarding / Purchase / Renewal]
**Current or future state:** [Current state / Desired future state]
**Prepared by:** [Name / Team]
**Date:** [Date]
**Based on:** [Research sources — interviews, analytics, support data, assumed/hypothetical]
---
## Persona Summary
| | |
|---|---|
| **Name** | [Sarah] |
| **Role** | [HR Manager at a 200-person professional services firm] |
| **Goal** | [Reduce time spent on manual employee data management] |
| **Frustrations** | [Too many tools that don't talk to each other; always chasing approvals] |
| **Tech comfort** | [Moderate — comfortable with SaaS tools but not a power user] |
| **Decision power** | [Recommends tools; budget approved by CHRO] |
---
## Journey Overview
```
AWARENESS → CONSIDERATION → DECISION → ONBOARDING → ADOPTION → ADVOCACY
[Stage 1] [Stage 2] [Stage 3] [Stage 4] [Stage 5] [Stage 6]
```
**Overall experience rating (current state):** [😤 Frustrating / 😐 Neutral / 😊 Positive]
---
## Stage 1: Awareness
*How does the customer first discover the product exists?*
**Customer goal at this stage:** [e.g. Realise they have a problem worth solving — or find a solution to a specific pain]
| Element | Detail |
|---|---|
| **Trigger** | [What event makes them start looking? — e.g. Manual process breaks down / peer recommendation / saw ad] |
| **Where they are** | [Google search / LinkedIn / conference / colleague conversation / email newsletter] |
| **What they do** | [e.g. Searches "automate employee onboarding" / asks peers in HR community / clicks LinkedIn ad] |
| **Emotion** | [😤 Frustrated — overwhelmed by manual processes and hoping for a better way] |
| **Pain points** | [Overwhelming number of options / hard to know which tools are credible / can't tell what's B2B vs B2C from homepage] |
| **Opportunities** | [SEO content targeting the trigger keyword / LinkedIn thought leadership / peer community presence] |
---
## Stage 2: Consideration
*The customer is actively evaluating options. What do they do to decide?*
| Element | Detail |
|---|---|
| **Customer goal** | [Narrow down from many options to a shortlist of 2–3] |
| **What they do** | [Reads G2/Capterra reviews / watches demo video / downloads comparison guide / asks peers who use something similar] |
| **Touchpoints** | [Website / review sites / social proof / demo request flow / sales email] |
| **Emotion** | [😕 Anxious — worried about making the wrong choice; past tool purchases haven't delivered] |
| **Pain points** | [Pricing not visible on website / demo requires a call before seeing the product / unclear if it works with their existing stack] |
| **Opportunities** | [Self-serve demo or interactive product tour / transparent pricing page / ROI calculator / case studies from similar company size] |
---
## Stage 3: Decision
*The customer is ready to buy — or not. What makes them commit?*
| Element | Detail |
|---|---|
| **Customer goal** | [Get sign-off from CHRO and justify the decision with a business case] |
| **What they do** | [Books sales call / requests security questionnaire / builds internal business case / negotiates contract] |
| **Touchpoints** | [AE / sales call / security review / contract / procurement process] |
| **Emotion** | [😬 Cautious — doesn't want to be wrong; presenting to leadership adds pressure] |
| **Pain points** | [Sales process is slow / security questionnaire takes weeks / contract terms are non-standard and require legal] |
| **Opportunities** | [Security FAQ self-serve / standard contract with predictable terms / champion toolkit (slides, business case template) to help them sell internally] |
---
## Stage 4: Onboarding
*The customer has bought. Now they need to get value fast.*
| Element | Detail |
|---|---|
| **Customer goal** | [Get the product working and show their CHRO it was a good decision] |
| **What they do** | [Receives welcome email / attends kickoff call / configures integrations / invites team] |
| **Touchpoints** | [Onboarding email sequence / in-product onboarding checklist / CSM / help centre / integrations marketplace] |
| **Emotion** | [😬 Anxious but hopeful — excited about potential but stressed about the setup work] |
| **Pain points** | [Setup is more complex than expected / IT required for SSO but IT is slow to respond / generic onboarding doesn't match their use case] |
| **Opportunities** | [Role-specific onboarding paths / IT connector with pre-filled request template / quick win email at day 3 (show them one thing that already works)] |
**Key moment of truth:** [What single moment in this stage determines whether they'll become an active user or ghost? — e.g. "First time the product saves them 30 minutes on a task they used to do manually"]
---
## Stage 5: Adoption
*The customer is using the product. Are they getting consistent value?*
| Element | Detail |
|---|---|
| **Customer goal** | [Make the product a regular part of their workflow; demonstrate ROI to leadership] |
| **What they do** | [Uses core features daily / discovers new features / hits a limitation / contacts support / attends webinar] |
| **Touchpoints** | [Product UI / in-app notifications / email / support / community / customer success manager] |
| **Emotion** | [Variable — some days 😊 when the product works well; some days 😤 when hitting a gap or bug] |
| **Pain points** | [Feature they expected isn't there / reporting doesn't show the metric leadership wants / power features are too complex / feels like they're underutilising what they're paying for] |
| **Opportunities** | [Proactive CSM check-in at day 30 / in-product feature discovery / usage dashboard for the customer to see their own ROI / community for peer learning] |
**Adoption health indicators:**
- [DAU/MAU ratio — what does healthy look like?]
- [Feature X used by Y% of seats within Z weeks]
- [First NPS survey at 60 days — target score]
---
## Stage 6: Advocacy
*The customer loves the product. How do you turn them into a referral engine?*
| Element | Detail |
|---|---|
| **Customer goal** | [Solve problems faster; feel like an expert; feel valued as a customer] |
| **What they do** | [Refers a peer / writes a G2 review / participates in case study / speaks at event / becomes a power user / joins community] |
| **Touchpoints** | [CSM / community / review request email / referral programme / case study outreach / conference sponsorship] |
| **Emotion** | [😊 Proud — the tool is part of their professional identity; they feel smart for choosing it] |
| **Pain points** | [Referral programme is clunky / no structured way to connect with peers / case study process is slow and effortful for them] |
| **Opportunities** | [One-click G2 review request at high-satisfaction moment / peer community / referral programme with meaningful reward / case study process that does most of the work for them] |
---
## Emotion Curve
Plot the customer's emotional experience across the journey:
```
High 😊 │ * * *
│ *
Neutral 😐│ * *
│ *
Low 😤 │ * *
└────────────────────────────────────────────────────
Aware Consider Decide Onboard Adopt Advocate
```
**Lowest point:** [Which stage has the worst experience — and why?]
**Highest point:** [When is the customer most delighted — what drove it?]
**Biggest drop:** [Where does sentiment fall most sharply — this is usually the biggest opportunity]
---
## Prioritised Opportunities
| Opportunity | Stage | Impact on customer | Effort to fix | Priority |
|---|---|---|---|---|
| [Self-serve product tour before sales call] | Consideration | [High — removes top buying barrier] | [Medium] | P1 |
| [Quick win email at day 3] | Onboarding | [High — builds early habit] | [Low] | P1 |
| [IT SSO setup template] | Onboarding | [Medium — removes specific blocker] | [Low] | P2 |
| [30-day proactive CSM check-in] | Adoption | [Medium — catches churn signals early] | [Medium] | P2 |
| [Peer referral programme] | Advocacy | [High for growth — reduces CAC] | [High] | P3 |
---
## What We Don't Know (Research Gaps)
| Gap | How to close it | Priority |
|---|---|---|
| [What actually triggers the decision to start looking?] | [5 JTBD interviews with recent buyers] | [High] |
| [What causes customers to stall in onboarding?] | [Drop-off analysis in onboarding funnel + 3 interviews with churned customers] | [High] |
| [What % of customers have reached the advocacy stage?] | [Product analytics — identify power users; NPS by cohort] | [Medium] |
---
## Quality Checks
- [ ] Map covers one specific persona — not "all customers"
- [ ] Each stage includes the customer's emotional state — not just actions
- [ ] Pain points are the customer's pain — not the company's pain
- [ ] Opportunities are specific enough to become backlog items or design prompts
- [ ] Emotion curve shows the real experience — not an aspirationally positive version
- [ ] Research gaps are documented — the map reflects what is known, not assumed
## Example Trigger Phrases
- "Map the customer journey for [product]"
- "Build a user journey from awareness to advocacy"
- "Create a journey map for our onboarding experience"
- "Map out the touchpoints and pain points for [customer type]"
- "Design an experience map for [process or product]"
skills/customer-success-plan/SKILL.md
+192
View File
@@ -0,0 +1,192 @@
---
name: customer-success-plan
description: "Build a joint customer success plan for a specific account. Use when asked to create a success plan, joint success plan, mutual action plan, or customer onboarding plan. Produces a structured success plan with business goals, milestones, success metrics, ownership, and a 90-180 day roadmap."
---
# Customer Success Plan Skill
This skill produces a joint customer success plan — a living document shared between the CSM and the customer that aligns on outcomes, milestones, and mutual commitments. Output is ready to co-author with the customer in a kickoff call or QBR.
## Required Inputs
Ask the user for these if not provided:
- **Account name** and industry
- **Product / plan purchased**
- **Key stakeholders** — customer champion and economic buyer
- **Customer's stated business goals** — why did they buy? What problem are they solving?
- **Contract term and renewal date**
- **Current onboarding stage** (new customer / expanding / post-QBR / pre-renewal)
- **Seats / licenses / usage purchased**
- **Any known risks** — adoption gaps, champion uncertainty, competing priorities
## Output Structure
---
# Customer Success Plan: [Account Name]
**Product:** [Product name / plan tier]
**Contract term:** [Start date → Renewal date]
**CSM:** [Name]
**Customer champion:** [Name, Title]
**Customer executive sponsor:** [Name, Title — if known]
**Last updated:** [Date]
**Status:** [Active / Under review / Completed]
---
## 1. Partnership Objectives
> *What does success look like for [Account Name] at contract end?*
[Write 2–3 sentences describing the customer's core objective in plain English — what they are trying to achieve in their business, not what features they are using.]
**Primary business goal:** [e.g. Reduce time-to-hire by 30% across engineering teams]
**Secondary goal:** [e.g. Consolidate three legacy tools into one platform, saving £X/year]
**Success statement (customer's words):** "[Direct quote from champion about what success looks like — ask for this in kickoff]"
---
## 2. Success Metrics
Define how both parties will measure success. Agreed in the kickoff call and tracked in QBRs.
| Metric | Baseline (today) | Target | By when | Data source |
|---|---|---|---|---|
| [e.g. Seat utilisation] | [X%] | [≥ 80%] | [Month 3] | [Product analytics] |
| [e.g. Time to hire] | [X days] | [< Y days] | [Month 6] | [Customer's ATS] |
| [e.g. Reports produced/month] | [X] | [≥ Y] | [Month 3] | [Product analytics] |
| [e.g. NPS] | [X] | [≥ 8] | [Month 6] | [Quarterly survey] |
**Leading indicators** (early signs the plan is on track):
- [e.g. 5+ users log in within the first 2 weeks]
- [e.g. First workflow automated within 30 days]
- [e.g. Champion presents the tool to their team by end of Month 1]
---
## 3. Milestone Roadmap
Break the success journey into phases with clear milestones and owners:
### Phase 1: Onboard (Month 1)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| Admin setup complete (SSO, permissions, data integration) | [IT contact] | [Date] | [ ] |
| All purchased seats activated and users invited | [Champion] | [Date] | [ ] |
| Core workflow [X] configured and tested | [CSM + Champion] | [Date] | [ ] |
| First training session delivered (all teams) | [CSM] | [Date] | [ ] |
| Kickoff call completed and success plan co-signed | [CSM + Champion] | [Date] | [ ] |
### Phase 2: Adopt (Months 2–3)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| [Core feature] in active daily use by ≥ X users | [Champion] | [Date] | [ ] |
| First business outcome achieved and documented | [Champion + CSM] | [Date] | [ ] |
| 30-day check-in completed | [CSM] | [Date] | [ ] |
| [Power user workflow] enabled for advanced users | [CSM] | [Date] | [ ] |
### Phase 3: Value (Months 4–6)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| QBR 1 delivered — ROI evidence presented | [CSM + AE] | [Date] | [ ] |
| Success metric [X] hit target | [Champion] | [Date] | [ ] |
| Expansion use case identified and introduced | [AE] | [Date] | [ ] |
| Reference call or case study agreed | [Champion] | [Date] | [ ] |
### Phase 4: Renew & Expand (Months 7–12)
| Milestone | Owner | Due date | Status |
|---|---|---|---|
| QBR 2 delivered — renewal conversation started | [CSM + AE] | [Date] | [ ] |
| Renewal proposal sent | [AE] | [Date] | [ ] |
| Expansion or flat renewal signed | [AE] | [Date] | [ ] |
---
## 4. Mutual Commitments
Success plans work when both parties commit. Document what each side will do:
**[Vendor] commits to:**
- Dedicated CSM available [X days/week / by email within 24 hours]
- Monthly [call / check-in / async update] with champion
- QBR every [90 days] with executive summary and ROI report
- Priority support for [Account] — response SLA of [X hours] for P1 issues
- Roadmap preview for relevant upcoming features
- [Any other specific commitment made in sales cycle]
**[Account Name] commits to:**
- Champion available for [30-min monthly] check-in
- Users complete onboarding training by [date]
- Feedback on product experience shared monthly (async or sync)
- Executive sponsor participates in QBR 1 and renewal discussion
- Provide outcome data to CSM quarterly for ROI tracking
---
## 5. Stakeholder Engagement Plan
| Stakeholder | Role | Engagement frequency | Format | Owner |
|---|---|---|---|---|
| [Champion] | Day-to-day owner | Weekly (async) + Monthly (call) | Slack / Email + Zoom | CSM |
| [Economic buyer] | Budget holder | Quarterly | QBR (in-person or video) | CSM + AE |
| [IT contact] | Integration owner | As needed | Email | CSM |
| [End users] | Active users | Training only | Group session | CSM |
---
## 6. Risk & Mitigation
| Risk | Likelihood | Impact | Mitigation plan |
|---|---|---|---|
| Low adoption in first 30 days | [M] | [H] | CSM hosts live onboarding; champion sends internal comms day 1 |
| Champion changes role | [L] | [H] | Multi-thread: introduce CSM to 2 additional stakeholders by Month 2 |
| Budget pressure at renewal | [M] | [H] | Build ROI case monthly; document value continuously |
| Competing priorities delay rollout | [H] | [M] | Agree minimum viable adoption path with champion; don't require perfection to declare value |
---
## 7. Communication Plan
| Communication | Audience | Frequency | Format | Owner |
|---|---|---|---|---|
| Health update | Champion | Monthly | Email summary (3 bullets: what's good, what needs attention, one ask) | CSM |
| QBR | Champion + Exec | Quarterly | 45-min video call with slide deck | CSM + AE |
| Product updates | Champion | As released | Release notes email | CSM |
| Support status | Champion | When open tickets exist | Email / Slack | Support + CSM |
---
## 8. Escalation Path
If the success plan falls off track:
| Trigger | Action | Owner | Timeline |
|---|---|---|---|
| Health drops to Amber | Internal review + champion call within 5 days | CSM | Immediate |
| Health drops to Red | CS leadership + AE looped in; escalation brief drafted | CS Manager | Within 24 hours |
| Champion is unresponsive for >10 days | AE attempts exec sponsor contact | AE | After CSM attempt fails |
| Adoption <40% at Month 3 | Emergency enablement session + revised milestone plan | CSM | Within 1 week of flag |
---
## Quality Checks
- [ ] Success metrics are the customer's metrics — not just product usage metrics
- [ ] Milestones have specific owners and due dates — not "TBD"
- [ ] Mutual commitments section is genuinely mutual — not just what the vendor will do
- [ ] Risk register includes champion departure and low adoption
- [ ] Plan is written to be shared with the customer — no internal-only commentary in this document
- [ ] Executive sponsor is identified and has an engagement role
## Example Trigger Phrases
- "Build a success plan for [Account Name] who just signed"
- "Create a joint success plan for our new enterprise customer"
- "Write a 6-month customer success roadmap for [Company]"
- "I need a mutual action plan for our QBR with [Account]"
- "Generate a customer success plan for an at-risk account"
skills/data-pipeline-spec/SKILL.md
+221
View File
@@ -0,0 +1,221 @@
---
name: data-pipeline-spec
description: "Design an ETL/ELT data pipeline specification. Use when asked to design a data pipeline, spec an ETL or ELT process, document a data ingestion workflow, or plan a data integration. Produces a complete pipeline spec with sources, transforms, destinations, SLAs, error handling, and data quality rules."
---
# Data Pipeline Spec Skill
This skill produces a complete data pipeline specification covering sources, transformations, destinations, scheduling, SLAs, error handling, data quality checks, and monitoring requirements. Output is ready for engineering handoff or architecture review.
## Required Inputs
Ask the user for these if not provided:
- **Pipeline purpose** — what business question or workflow does this pipeline serve?
- **Source systems** — where does data come from? (databases, APIs, files, event streams)
- **Destination** — where does data land? (data warehouse, data lake, downstream DB, reporting tool)
- **Transformation type** — ETL (transform before loading) or ELT (load raw, transform in warehouse)?
- **Frequency / SLA** — how often must data be fresh? (real-time / hourly / daily / weekly)
- **Volume estimate** — approximate rows/events per run
- **Data quality requirements** — completeness, deduplication, freshness, schema enforcement
- **Team or stack** — any specific tools in use? (Airflow, dbt, Fivetran, Spark, Kafka, etc.)
## Output Structure
---
# Data Pipeline Spec: [Pipeline Name]
**Purpose:** [One sentence — what decision or workflow does this pipeline enable?]
**Type:** [ETL / ELT / Streaming / Batch]
**Owner:** [Team or individual]
**Version:** [1.0]
**Date:** [Date]
**Status:** [Draft / Under Review / Approved]
---
## 1. Overview
[2–3 sentences describing the pipeline end-to-end: what data moves, from where to where, at what cadence, and why.]
**Architecture diagram (text):**
```
[Source A] ──┐
[Source B] ──┤──► [Ingestion Layer] ──► [Transform Layer] ──► [Destination] ──► [Consumers]
[Source C] ──┘
```
---
## 2. Sources
| Source | System | Connection type | Data format | Update pattern | Volume |
|---|---|---|---|---|---|
| [Source 1] | [PostgreSQL / Salesforce / S3 / Kafka] | [JDBC / REST API / SDK / Webhook] | [JSON / CSV / Parquet / CDC] | [Append / Full refresh / Incremental] | [X rows/day] |
| [Source 2] | [...] | [...] | [...] | [...] | [...] |
**Incremental key (if applicable):** [The column used to identify new or changed records — e.g. `updated_at`, `event_id`]
**Authentication:** [API key / OAuth / IAM role / connection string — note where credentials are stored]
---
## 3. Ingestion Layer
**Tool:** [Fivetran / Airbyte / Kafka Connect / custom script / dbt source]
**Ingestion method:**
- [ ] Full extract (full table refresh each run)
- [ ] Incremental extract (only new/changed rows since last run)
- [ ] CDC (change data capture from database transaction log)
- [ ] Event streaming (continuous ingestion from Kafka/Kinesis)
**Raw landing zone:** [Where raw data lands before transformation — e.g. `raw.salesforce_opportunities` in Snowflake, S3 bucket `s3://data-raw/crm/`]
**Schema handling:** [Strict schema enforcement / Schema evolution allowed / Union schema]
---
## 4. Transformation Logic
List each transformation in execution order. For ELT pipelines, this is the dbt model or SQL layer.
| Step | Name | Description | Input | Output | Tool |
|---|---|---|---|---|---|
| 1 | [Deduplicate events] | [Remove duplicate event rows based on event_id] | `raw.events` | `staging.events_deduped` | [dbt / SQL / Spark] |
| 2 | [Join user profile] | [Enrich events with user attributes from CRM] | `staging.events_deduped`, `raw.users` | `staging.events_enriched` | [...] |
| 3 | [Aggregate to daily] | [Roll up to user×day grain] | `staging.events_enriched` | `mart.user_daily_activity` | [...] |
**Business logic rules:**
- [e.g. Revenue is recognised on `payment_confirmed_at`, not `payment_initiated_at`]
- [e.g. Users in the `internal@company.com` domain are excluded from all metrics]
- [e.g. Currency conversion uses the ECB rate from the first business day of each month]
**Slowly Changing Dimensions (SCD) — if applicable:**
- [e.g. `users.plan_tier` is SCD Type 2 — keep history of plan changes with `valid_from` / `valid_to`]
---
## 5. Destination
| Destination | System | Schema / Table | Write mode | Consumers |
|---|---|---|---|---|
| [Primary] | [Snowflake / BigQuery / Redshift / PostgreSQL] | [`analytics.mart_user_activity`] | [Append / Upsert / Full replace] | [Looker / Metabase / downstream pipeline] |
| [Secondary] | [...] | [...] | [...] | [...] |
**Partitioning / Clustering:** [e.g. Partitioned by `event_date`, clustered by `user_id` — reduces query cost for time-range scans]
**Retention policy:** [e.g. Raw data retained for 90 days; mart tables retained indefinitely]
---
## 6. Scheduling & SLAs
| SLA | Target | Breach action |
|---|---|---|
| **Data freshness** | [Data must be ≤ X hours old by HH:MM UTC] | [Page on-call / alert Slack channel] |
| **Pipeline completion** | [Must complete within X minutes of trigger] | [Alert and auto-retry] |
| **Availability** | [Pipeline must run successfully X% of days per month] | [Incident review] |
**Schedule:** [Cron expression and human description — e.g. `0 6 * * *` — daily at 06:00 UTC]
**Trigger type:**
- [ ] Time-based (cron)
- [ ] Event-based (triggered by upstream pipeline success / file arrival / Kafka lag)
- [ ] Manual (ad hoc runs only)
**Backfill strategy:** [How to reprocess historical data if the pipeline fails or logic changes — e.g. parameterised date range, full drop-and-reload]
---
## 7. Data Quality Rules
| Check | Table | Rule | Failure action |
|---|---|---|---|
| Completeness | `staging.events` | `event_id IS NOT NULL` — 100% of rows | Block load / Alert |
| Uniqueness | `mart.user_daily_activity` | `(user_id, date)` must be unique | Block load |
| Freshness | `mart.user_daily_activity` | `max(event_date) >= CURRENT_DATE - 1` | Alert |
| Volume | `staging.events` | Row count within ±20% of 7-day average | Alert |
| Referential integrity | `staging.events` | All `user_id` values exist in `users` table | Alert |
**DQ tool:** [dbt tests / Great Expectations / Monte Carlo / custom SQL assertions]
---
## 8. Error Handling & Recovery
**Retry policy:** [e.g. 3 retries with exponential back-off: 5 min, 20 min, 60 min]
**Failure modes and responses:**
| Failure | Detection | Response | Owner |
|---|---|---|---|
| Source unavailable | HTTP 5xx / connection timeout | Retry 3×, then alert and skip run | Data engineering |
| Schema change in source | Column missing or type mismatch | Block load, alert schema owner | Data owner + engineering |
| DQ check fails | dbt test failure / assertion error | Block load for P1 checks; alert for P2 | Data engineering |
| Partial load | Row count < expected threshold | Alert; do not publish to consumers until resolved | Data engineering |
**Dead-letter queue:** [Where failed records are routed for manual inspection — e.g. `raw.dlq_events`]
---
## 9. Monitoring & Observability
**Metrics to track:**
- Pipeline run duration (p50, p95)
- Rows processed per run
- DQ check pass rate
- Source freshness lag
- Error rate per source
**Alerting:**
- [Slack channel: #data-alerts]
- [PagerDuty: data-on-call escalation for P1 SLA breaches]
- [Dashboard: [link to monitoring dashboard]]
**Logging:** [What gets logged and where — e.g. Airflow task logs to CloudWatch, structured JSON to data lake]
---
## 10. Dependencies & Sequencing
**Upstream dependencies:** [Which pipelines or data sources must succeed before this pipeline runs?]
**Downstream dependents:** [Which dashboards, pipelines, or models depend on this pipeline's output?]
```
[upstream pipeline A] ──► THIS PIPELINE ──► [downstream dashboard B]
└──► [downstream pipeline C]
```
**Coordination mechanism:** [Airflow DAG dependency / dbt ref() / event trigger / manual gate]
---
## 11. Security & Compliance
- **PII fields:** [List columns containing PII — e.g. `email`, `ip_address`, `name`]
- **Masking / Pseudonymisation:** [e.g. email hashed with SHA-256 before landing in mart layer]
- **Access control:** [Who can query the destination tables? — e.g. Role-based access in Snowflake]
- **Data residency:** [Which regions is data permitted to transit and rest in?]
- **Audit trail:** [Is pipeline execution auditable for compliance purposes? Where are logs retained?]
---
## Quality Checks
- [ ] Every source has an incremental key or full-refresh justification
- [ ] Business logic rules are documented, not just the SQL
- [ ] SLAs are agreed with consumers, not set unilaterally by engineering
- [ ] DQ checks cover completeness, uniqueness, freshness, and volume
- [ ] Failure modes include a documented recovery owner
- [ ] PII fields are identified and a treatment plan is specified
## Example Trigger Phrases
- "Design a data pipeline for our Salesforce to Snowflake sync"
- "Write a pipeline spec for ingesting Stripe events into our data warehouse"
- "Build an ETL spec for our user activity data"
- "Document our dbt pipeline from raw events to the analytics mart"
- "Spec out the pipeline that feeds the executive dashboard"
skills/design-system-audit/SKILL.md
+215
View File
@@ -0,0 +1,215 @@
---
name: design-system-audit
description: "Audit a design system for consistency, coverage, and quality. Use when asked to audit a design system, review a component library, assess design token coverage, or evaluate the health of a shared design system. Produces a structured audit with a health score, component coverage gaps, token inconsistencies, accessibility issues, and a prioritised remediation roadmap."
---
# Design System Audit Skill
This skill produces a structured audit of a design system — covering component coverage, token consistency, documentation quality, accessibility compliance, contribution processes, and adoption health. Output is ready for a design system team, design leadership, or an engineering team evaluating their shared component library.
## Required Inputs
Ask the user for these if not provided:
- **Design system name** and what product(s) it serves
- **Audit scope** — component library / design tokens / documentation / contribution process / all of the above
- **Current tooling** — Figma / Storybook / Zeroheight / custom / combination?
- **Team using it** — how many designers and engineers, how many products?
- **Known pain points** — what do teams complain about most?
- **Governance model** — centralised team / federated contributors / no dedicated team?
- **Goal of the audit** — improve adoption / prepare for a rebrand / onboard new teams / justify investment?
## Output Structure
---
# Design System Audit: [System Name]
**Products served:** [List of products / apps]
**Audit scope:** [Full / Components only / Tokens only / Documentation]
**Auditor:** [Name / Team]
**Date:** [Date]
**Stakeholders:** [Design lead, Eng lead, CPO, etc.]
---
## Overall Health Score
| Dimension | Score (1–5) | Status |
|---|---|---|
| Component coverage | [X/5] | 🟢/🟡/🔴 |
| Token consistency | [X/5] | 🟢/🟡/🔴 |
| Documentation quality | [X/5] | 🟢/🟡/🔴 |
| Accessibility compliance | [X/5] | 🟢/🟡/🔴 |
| Adoption rate | [X/5] | 🟢/🟡/🔴 |
| Contribution process | [X/5] | 🟢/🟡/🔴 |
| **Overall** | **[X/5]** | 🟢/🟡/🔴 |
**Summary:** [2–3 sentences. What is the overall state of the design system? What are the top 2 issues and what is the biggest strength?]
---
## 1. Component Coverage Audit
**How to assess:** Compare components in the design system against the actual UI patterns in the product. Every pattern that exists in production but not in the system is a coverage gap.
### Component Inventory
| Category | Components present | Coverage | Gap |
|---|---|---|---|
| **Navigation** | [Navbar, Sidebar, Breadcrumb, Tabs] | [80%] | [Missing: Mega menu, mobile drawer] |
| **Forms & Inputs** | [Text input, Dropdown, Checkbox, Radio, Toggle, Date picker] | [90%] | [Missing: Multi-select, Rich text editor] |
| **Feedback & Alerts** | [Toast, Banner, Modal, Tooltip] | [60%] | [Missing: Inline validation, Progress indicator, Skeleton loader] |
| **Data Display** | [Table, Card, Badge, Avatar] | [50%] | [Missing: Data grid, Stat card, Timeline, Gantt] |
| **Layout** | [Grid, Container, Divider, Spacer] | [70%] | [Missing: Responsive breakpoint utilities] |
| **Buttons & Actions** | [Button, Icon button, FAB, Link] | [100%] | [None] |
**Coverage score:** [X% of production UI patterns are covered by the design system]
**Most impactful gaps:**
1. [Most used pattern not in the system — causing most duplication]
2. [...]
3. [...]
---
## 2. Component Quality Audit
For each component, assess against these quality criteria:
| Component | States complete | Responsive | Accessibility | Dark mode | Props documented | Code matches Figma |
|---|---|---|---|---|---|---|
| Button | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| Modal | ⚠️ Loading state missing | ✅ | ✅ | ❌ | ⚠️ Partial | ✅ |
| Table | ❌ Sorting state missing | ❌ No mobile layout | ⚠️ No aria-sort | ❌ | ❌ | ⚠️ Drift |
| [Component] | [...] | [...] | [...] | [...] | [...] | [...] |
**Legend:** ✅ Complete — ⚠️ Partial / inconsistent — ❌ Missing
**Components with critical quality issues (fix before anything else):**
- [Component name]: [Specific issue and why it's blocking]
- [...]
---
## 3. Design Token Audit
**Token coverage:**
| Token type | Defined | Used consistently | Issues |
|---|---|---|---|
| **Colour** | [X tokens defined] | [⚠️ — 12 hardcoded hex values found in Figma] | [Inconsistent use of primary-500 vs primary-600 for CTAs across products] |
| **Typography** | [X tokens defined] | [✅] | [None — all type styles use token scale] |
| **Spacing** | [X tokens defined] | [⚠️ — custom spacing used in X components] | [Engineers using arbitrary px values instead of spacing tokens in X components] |
| **Border radius** | [X tokens defined] | [❌ — not defined; each component has hardcoded values] | [Button, card, modal all use different radius values with no token] |
| **Shadow / elevation** | [X tokens defined] | [⚠️] | [3 different drop-shadow values in use; no elevation scale] |
| **Animation / motion** | [X tokens defined] | [❌ — not defined] | [Transition durations inconsistent across components] |
**Semantic token layer:** [Does the system have semantic tokens (e.g. `color.action.primary` on top of `color.blue.500`) or only primitive tokens?]
**Token drift:** [Are code tokens and Figma tokens in sync? Use a tool like Token Studio, Style Dictionary, or manual comparison.]
---
## 4. Documentation Quality Audit
**Assessment per component / pattern:**
| Document type | Quality | Issues |
|---|---|---|
| **Usage guidelines** | [⚠️ — X% of components have guidelines] | [Button and Form components documented; Navigation and Data Display mostly undocumented] |
| **Do / Don't examples** | [❌ — mostly absent] | [Engineers frequently misuse components because intent is unclear] |
| **Accessibility notes** | [⚠️ — present for some components] | [No consistent format; accessibility notes missing for interactive components] |
| **Code examples** | [✅ — all Storybook components have code examples] | [...] |
| **Changelog** | [❌ — no component-level changelog exists] | [Breaking changes are not communicated; causes unexpected UI regressions] |
| **Migration guides** | [❌ — absent] | [Teams don't know how to upgrade to new component versions] |
**Documentation score:** [X% of components have complete, usable documentation]
**Most common designer / engineer complaint about docs:** [e.g. "I can't find whether to use Modal or Drawer for this use case — no guidance exists"]
---
## 5. Accessibility Audit
**WCAG 2.2 compliance status:**
| Criterion | Level | Status | Components affected |
|---|---|---|---|
| Colour contrast (text) | AA | [✅ / ⚠️ / ❌] | [e.g. ❌ — Disabled state text fails 4.5:1 ratio in 3 components] |
| Colour contrast (UI components) | AA | [✅ / ⚠️ / ❌] | [...] |
| Keyboard navigation | AA | [✅ / ⚠️ / ❌] | [⚠️ — Modal focus trap not implemented; Dropdown not keyboard accessible] |
| Focus visible | AA | [✅ / ⚠️ / ❌] | [...] |
| Screen reader support (ARIA) | AA | [✅ / ⚠️ / ❌] | [❌ — Table component lacks aria-sort; Icon buttons have no aria-label] |
| Touch target size | AA | [✅ / ⚠️ / ❌] | [⚠️ — Mobile tap targets below 44×44px in X components] |
| Motion / animation | AA | [✅ / ⚠️ / ❌] | [...] |
**Critical accessibility blockers (must fix before next release):**
1. [Most critical issue — e.g. Keyboard users cannot close Modal — focus trap missing]
2. [...]
---
## 6. Adoption Audit
**Adoption by team / product:**
| Product / Team | Components used from system | Custom components built outside system | Adoption score |
|---|---|---|---|
| [Product A] | [X% of UI uses system components] | [Y custom components] | [High / Medium / Low] |
| [Product B] | [...] | [...] | [...] |
**Why teams are not adopting:**
| Barrier | Severity | Evidence |
|---|---|---|
| [Component doesn't exist] | High | [Top reason in team survey] |
| [Component exists but doesn't meet use case] | Medium | [Modal component lacks X state needed by Product B] |
| [Documentation too sparse to know how to use it] | Medium | [...] |
| [No one enforces system use — easier to build custom] | High | [...] |
| [System is out of date with product's current visual language] | Medium | [...] |
---
## 7. Contribution Process Audit
| Dimension | Current state | Assessment |
|---|---|---|
| **How to contribute** | [Documented / Not documented] | [✅ / ❌] |
| **Contribution criteria** | [Clear entry bar for what goes in the system] | [⚠️ — unclear who decides what becomes a system component vs stays local] |
| **Review process** | [Who reviews contributions and how long it takes] | [❌ — no formal review; contributions sit unreviewed for weeks] |
| **Release cadence** | [How often system releases happen] | [⚠️ — sporadic; no set cadence] |
| **Breaking change policy** | [How breaking changes are handled and communicated] | [❌ — no policy; breaking changes are a surprise] |
| **Versioning** | [Semantic versioning in place?] | [✅ — all packages use semver] |
---
## 8. Prioritised Remediation Roadmap
| Priority | Initiative | Impact | Effort | Timeline |
|---|---|---|---|---|
| P1 | Fix [X] critical accessibility issues (keyboard nav, ARIA) | Critical — legal + user impact | Medium | Sprint 1–2 |
| P1 | Define and implement border radius and shadow token scale | High — ends inconsistency | Low | Sprint 1 |
| P1 | Document top 10 most-used components (usage + do/don't) | High — unblocks adoption | Medium | Sprint 2–4 |
| P2 | Build Skeleton loader + Inline validation components (top 2 gaps) | High — eliminates custom duplication | High | Quarter 2 |
| P2 | Establish contribution process with SLA for reviews | Medium — enables growth | Low | Sprint 3 |
| P3 | Dark mode token support | Medium — product parity | High | Quarter 3 |
| P3 | Design-code token sync tooling (Token Studio / Style Dictionary) | Medium — reduces drift | Medium | Quarter 2–3 |
---
## Quality Checks
- [ ] Coverage gaps are identified by comparing the design system to actual production UI, not assumed
- [ ] Accessibility issues cite specific WCAG criterion and affected components
- [ ] Adoption barriers are backed by evidence (interviews, survey, usage data) — not assumed
- [ ] Remediation roadmap has effort estimates and is sequenced by impact
- [ ] Both Figma and code (Storybook/implementation) are assessed — not just Figma
- [ ] Stakeholders from design, engineering, and product have reviewed the audit
## Example Trigger Phrases
- "Audit our design system for consistency and coverage"
- "Review our component library and identify gaps"
- "Assess the health of our shared design system"
- "Run a design system audit before we do a rebrand"
- "What's wrong with our design system and what should we fix first?"
skills/partnership-proposal/SKILL.md
+228
View File
@@ -0,0 +1,228 @@
---
name: partnership-proposal
description: "Write a B2B partnership proposal or business case. Use when asked to write a partnership proposal, draft a partnership brief, structure a co-marketing proposal, or create a business case for a strategic partnership. Produces a structured proposal with value proposition, partnership model, commercial terms, and mutual commitments."
---
# Partnership Proposal Skill
This skill produces a complete B2B partnership proposal covering the partnership rationale, mutual value, partnership model, commercial terms, governance, and a joint go-to-market plan. Output is ready to share with a prospective partner or use as the basis for a business case to internal stakeholders.
## Required Inputs
Ask the user for these if not provided:
- **Your company** — name, what you do, and the audience you serve
- **Prospective partner** — name, what they do, and their audience
- **Partnership type** — technology integration / co-marketing / reseller / referral / strategic alliance / OEM
- **Partnership goal** — what does each party get? (new customers / revenue / product capability / market reach)
- **Proposed commercial model** — revenue share, referral fee, licensing, co-investment?
- **Urgency or context** — is there a specific event, product launch, or competitive reason for this partnership?
## Output Structure
---
# Partnership Proposal: [Your Company] × [Partner Company]
**Prepared by:** [Name, Role at Your Company]
**Date:** [Date]
**Partnership type:** [Technology / Co-marketing / Reseller / Referral / Strategic Alliance]
**Proposal status:** [Initial proposal / For negotiation / Final]
---
## Executive Summary
[3–5 sentences. Answer: what are we proposing, why now, and what does each party stand to gain? Write this so a busy executive can understand the proposal in 60 seconds without reading further.]
**Headline value for [Partner]:**
> [One sentence — the most compelling thing this partnership does for them]
**Headline value for [Your Company]:**
> [One sentence — the most compelling thing this partnership does for you]
---
## 1. The Opportunity
**Market context:** [Why does this partnership make sense now? What's happening in the market that creates a window for this to work?]
**Shared customer:** [Describe the customer both organisations serve — the overlap that makes this logical. Include size of the shared addressable market if you have it.]
**Problem neither of us solves alone:** [What can't either party do for the shared customer independently that the partnership would enable?]
---
## 2. What We're Proposing
**Partnership model:**
| Element | Description |
|---|---|
| **Type** | [Technology integration / Co-marketing / Reseller / Referral / OEM] |
| **Scope** | [What specifically are we partnering on? — product features, joint campaigns, distribution, etc.] |
| **Exclusivity** | [Exclusive in [region/segment] / Non-exclusive / Right of first refusal] |
| **Duration** | [Initial term — e.g. 12 months, renewable] |
| **Geographic scope** | [UK / EMEA / Global / Specific markets] |
**What this looks like in practice:**
[3–5 bullet points describing what the partnership actually means day-to-day. Make it concrete and operational — not abstract. e.g.:]
- [Our product will natively integrate with [Partner's product] — the integration will be live in [timeframe]]
- [We will co-market to each other's customer bases — joint webinar, co-authored content, shared newsletter placement]
- [Each company will train a dedicated partnership contact who manages the relationship]
- [[Partner] will list [Your product] in their marketplace / app directory / referral programme]
---
## 3. Value Proposition — What Each Party Gets
### For [Partner]
| Value | Evidence / Basis |
|---|---|
| **[New customer reach]** | [e.g. Access to [Your Company]'s [X,000] [role] customers — [X%] of whom have expressed interest in [Partner's category]] |
| **[Product capability]** | [e.g. [Partner]'s product gains [capability] that [X%] of their customers have requested — based on [source]] |
| **[Revenue opportunity]** | [e.g. Estimated [£/$/€ X] in referral revenue in Year 1 based on [X%] conversion from shared pipeline] |
| **[Market differentiation]** | [e.g. The integration creates a meaningful competitive moat vs [Competitor] who lacks this capability] |
### For [Your Company]
| Value | Evidence / Basis |
|---|---|
| **[Distribution]** | [e.g. Access to [Partner]'s [X,000] customers in [segment] — a segment where we currently have [X] customers] |
| **[Credibility]** | [e.g. Association with [Partner]'s brand accelerates enterprise sales cycles — [Partner] is trusted by [X] of the Fortune 500] |
| **[Revenue]** | [e.g. Target [X] referral customers in Year 1 at average ACV of [£X] = [£X ARR]] |
| **[Product]** | [e.g. [Partner]'s data / capability enhances [specific part of our product] — improving [user outcome]] |
---
## 4. Commercial Model
**Proposed commercial terms:**
| Term | Proposal | Notes |
|---|---|---|
| **Revenue share** | [e.g. [X%] of ARR from customers referred by [Partner]] | [Standard in this category: [X–Y%] range] |
| **Referral fee** | [e.g. £[X] per qualified lead that converts] | [Or: flat fee per introduction vs % of closed deal] |
| **Licensing / access** | [e.g. [Partner] provides API access at no cost in exchange for integration and co-marketing] | [...] |
| **Co-marketing investment** | [e.g. Each party commits [£X] to joint marketing activities per quarter] | [...] |
| **Minimum commitment** | [e.g. [X] qualified referrals per quarter / [£X] GMV per year] | [Optional — only if there's a meaningful minimum that makes sense] |
**Payment terms:** [Monthly / Quarterly in arrears / Annual true-up]
**What we're not proposing:** [Be explicit about what's off the table — e.g. equity / exclusivity in all markets / upfront payment]
---
## 5. Joint Go-to-Market Plan
**Phase 1: Foundation (Months 1–2)**
| Activity | Owner | Timeline |
|---|---|---|
| Technical integration scoped and resourced | [Engineering at both companies] | [Month 1] |
| Partnership launch announcement drafted | [Marketing at both companies] | [Month 1] |
| Joint customer case study identified | [CSM at both companies] | [Month 2] |
| Partner enablement — each team trained on the other's product | [Partnership lead, both sides] | [Month 2] |
**Phase 2: Launch (Month 3)**
| Activity | Owner | Timeline |
|---|---|---|
| Integration live in both products / marketplace | [Engineering] | [Month 3] |
| Joint press release / blog post / email announcement | [Marketing] | [Month 3] |
| First joint webinar | [Both companies] | [Month 3] |
| First joint pipeline reviewed | [Partnership leads] | [Month 3] |
**Phase 3: Scale (Months 4–12)**
| Activity | Owner | Cadence |
|---|---|---|
| Co-sell on named accounts | [AE at both companies] | [Monthly] |
| Joint content (blog, webinar, case study) | [Marketing] | [Quarterly] |
| Pipeline and revenue review | [Partnership leads] | [Monthly] |
| Partnership QBR | [VP level, both companies] | [Quarterly] |
---
## 6. Success Metrics
How we'll know the partnership is working:
| Metric | Year 1 target | Measurement |
|---|---|---|
| Customers referred (each direction) | [X] | [CRM tracking — tagged as partner-sourced] |
| Revenue from partnership | [£/$/€ X ARR] | [CRM + finance reporting] |
| Integration adoption | [X% of mutual customers using integration] | [Product analytics] |
| Customer satisfaction with integration | [NPS ≥ X] | [Post-integration survey] |
| Joint pipeline generated | [£X] | [Quarterly pipeline review] |
**Review cadence:** Monthly partnership lead check-in + Quarterly business review at VP level
---
## 7. Governance & Operations
**Partnership contacts:**
| Role | [Your Company] | [Partner] |
|---|---|---|
| Partnership lead (day-to-day) | [Name, email] | [TBC] |
| Executive sponsor | [Name, title] | [TBC] |
| Technical lead | [Name] | [TBC] |
| Marketing lead | [Name] | [TBC] |
**Decision-making:**
- Day-to-day partnership operations: partnership leads
- Commercial term changes: VP-level approval from both parties
- Partnership termination: CEO/MD sign-off + [X days] written notice
**Legal framework:**
- [ ] Partnership agreement / MOU to be drafted by [Company]'s legal team
- [ ] Data processing agreement (if personal data is shared)
- [ ] NDAs: [already in place / to be signed before detailed discussions]
- [ ] IP ownership: [Clarify who owns jointly developed materials, integrations, content]
---
## 8. Risks & Mitigations
| Risk | Likelihood | Mitigation |
|---|---|---|
| Partnership champion leaves [Partner] | M | Ensure VP-level sponsorship; build multiple relationships |
| Integration takes longer than planned | M | Scope technical work in Phase 1; set realistic launch commitment |
| Low adoption of the integration | M | Include in onboarding for both products; co-market to existing customers not just new |
| Partner signs with our competitor | L | Discuss exclusivity options; prioritise quick launch to create switching costs |
| Commercial model becomes imbalanced | L | Quarterly review with clear exit terms if targets are consistently missed |
---
## 9. Proposed Next Steps
| # | Action | Owner | By when |
|---|---|---|---|
| 1 | [Partner] reviews this proposal and provides feedback | [[Partner name]] | [Date] |
| 2 | Both parties sign NDA (if not already in place) | [Legal, both sides] | [Before next meeting] |
| 3 | Technical discovery call — assess integration feasibility | [Engineering leads] | [Date] |
| 4 | Commercial terms negotiation | [Partnership leads / VP] | [Date] |
| 5 | MOU / partnership agreement drafted and signed | [Legal] | [Date] |
| 6 | Integration and launch planning begins | [Both teams] | [Date] |
---
## Quality Checks
- [ ] Value proposition for the partner is written from their perspective — not yours
- [ ] Commercial model includes specific numbers, not just structure
- [ ] "What we're not proposing" section prevents misaligned expectations
- [ ] Go-to-market plan has named owners and dates, not "TBD"
- [ ] Success metrics are agreed bilaterally — not set unilaterally
- [ ] Risks section includes the most uncomfortable risk (partner signs with a competitor)
## Example Trigger Phrases
- "Write a partnership proposal for [Company] to partner with [Partner]"
- "Draft a co-marketing partnership brief between us and [Partner]"
- "Create a reseller partnership proposal for [Company]"
- "Build the business case for a strategic partnership with [Partner]"
- "Structure a technology integration partnership proposal"
skills/product-positioning-doc/SKILL.md
+221
View File
@@ -0,0 +1,221 @@
---
name: product-positioning-doc
description: "Write a product positioning document and messaging framework. Use when asked to define product positioning, write a positioning statement, build a messaging framework, or create a messaging hierarchy. Produces a complete positioning doc with category definition, target customer, differentiation, proof points, messaging pillars, and persona-specific messaging."
---
# Product Positioning Doc Skill
This skill produces a complete product positioning document following the April Dunford positioning methodology. Output covers category definition, target customer, unique attributes, proof points, and a messaging hierarchy — ready to align GTM, marketing, sales, and product teams.
## Required Inputs
Ask the user for these if not provided:
- **Product name** and what it does
- **Target customer** — who is it for? (role, company type, size)
- **Problem it solves** — what pain or goal does it address?
- **Key alternatives** — what do customers use today instead? (not just direct competitors — include status quo, spreadsheets, DIY)
- **Differentiation** — what does this product do that alternatives cannot? (not features — capabilities that produce different outcomes)
- **Proof points** — any customer data, case studies, metrics, or validation?
- **Business goal** — is positioning for a new category, expansion into new segment, or repositioning away from a declining category?
## Output Structure
---
# Positioning Document: [Product Name]
**Version:** [1.0]
**Owner:** [PMM / Founder / Marketing lead]
**Date:** [Date]
**Status:** [Draft / Reviewed / Approved]
**Approved by:** [Names — this document must be signed off by product, marketing, and sales leadership before use]
---
## 1. Background & Context
[2–3 sentences describing why positioning is being done now. Is this a new product, a pivot, a segment expansion, or a rebrand? What triggered this work?]
**Positioning objective:** [e.g. Move from being perceived as a reporting tool to being the category leader in revenue intelligence for mid-market SaaS]
---
## 2. Market Category
**What category does this product compete in?**
This is the frame of reference your customer uses to understand what the product is. Choose the wrong category and everything downstream — competitors, value, messaging — is wrong.
**Category:** [e.g. Customer data platform / Revenue intelligence / No-code automation / Modern data stack]
**Why this category, not [alternative category]?**
[1–2 sentences on why this framing serves the customer's understanding better than adjacent categories]
**Category maturity:**
- [ ] New category (we are creating it — high education burden, high upside if it works)
- [ ] Growing category (fast-growing segment — compete on differentiation)
- [ ] Mature category (well-understood — must disrupt with clear superiority or narrower niche)
---
## 3. Target Customer
**Be precise. Vague targeting produces vague positioning.**
| Dimension | Description |
|---|---|
| **Primary buyer / decision-maker** | [e.g. VP of Revenue Operations at B2B SaaS companies with 100–500 employees] |
| **Primary user** | [e.g. Revenue operations analysts and sales ops managers] |
| **Company profile** | [Industry, size, growth stage, technology stack] |
| **Business context** | [What is happening in their world that makes them a buyer right now?] |
| **Trigger event** | [What just happened that makes them start looking for a solution? — e.g. Sales team grew past 20 reps, forecast accuracy became a board question] |
**Who this is NOT for:**
[Be explicit about who to exclude — this sharpens the positioning for those who are a fit]
---
## 4. Competitive Alternatives
What do buyers use today when they don't have your product? List all real alternatives — not just direct competitors.
| Alternative | Who uses it | Why buyers choose it | What they sacrifice |
|---|---|---|---|
| **[Direct competitor — e.g. Gong]** | [Enterprise sales teams] | [Market leader, strong brand, sales coaching features] | [Price, complexity, implementation time] |
| **[Adjacent tool — e.g. Salesforce reports]** | [CRM-native users] | [Already have it, no additional cost] | [No AI analysis, manual reporting, siloed data] |
| **[Status quo — e.g. spreadsheets + manual tracking]** | [SMB, early-stage] | [Free, flexible, no change management] | [Time-consuming, error-prone, not scalable] |
| **[Build in-house]** | [Tech companies with data teams] | [Custom to their exact needs] | [Engineering cost, maintenance burden, 12+ month timeline] |
**Key insight:** [What does this competitive landscape tell you about what your positioning must emphasise? e.g. "Every alternative either costs too much or requires too much manual work — positioning must nail 'fast time to value' and 'right-sized for mid-market'"]
---
## 5. Unique Differentiated Attributes
These are the features or capabilities your product has that alternatives genuinely cannot match — or cannot match at the same level. Do not list features that competitors also have.
| Attribute | What it is | What it enables (outcome) | Why competitors can't match it |
|---|---|---|---|
| [e.g. Real-time CRM sync] | [Bidirectional sync with any CRM in <5 min] | [Reps see clean data in the tools they already use — no toggle between systems] | [Legacy competitors require 3-month integration projects; Salesforce-native tools only work in SFDC] |
| [e.g. Natural language querying] | [Ask questions in plain English, get data visualisations] | [Anyone on the revenue team can answer their own questions without SQL or waiting for an analyst] | [BI tools require analyst training; direct competitors have rigid dashboards] |
| [...] | [...] | [...] | [...] |
**The core differentiation thesis:**
[1–2 sentences that unite the above attributes into a single "why we win" statement — this is internal language, not customer-facing yet]
---
## 6. Value Proof Points
Back up the differentiation claims with evidence:
| Claim | Proof point | Source |
|---|---|---|
| [Fastest time to value] | [Average customer is live in 4 hours vs 3 months for legacy alternatives] | [Customer data — average across [X] accounts] |
| [Better forecast accuracy] | [Customers achieve X% improvement in forecast accuracy within 90 days] | [Case study: [Company Name] — link] |
| [Loved by operators, not just managers] | [NPS of X among end users; 4.8/5 on G2 for ease of use] | [G2 reviews, internal NPS survey] |
**Proof gaps:** [Are there claims you're making that you don't yet have evidence for? List them — they are either research projects or risks to the positioning]
---
## 7. Positioning Statement
The classic positioning template — internal only, never used verbatim in marketing:
> **For** [target customer]
> **who** [trigger event or problem statement],
> **[Product name]** is a **[category]**
> **that** [primary differentiated value — the outcome, not the feature].
> **Unlike** [primary alternative],
> **[Product name]** [the key thing that makes you different and better].
**Draft positioning statement:**
> For [VP Revenue Ops at B2B SaaS companies with 50–500 reps] who [struggle to forecast accurately as the sales team scales], [Product Name] is a [revenue intelligence platform] that [gives every rep and manager accurate, real-time pipeline visibility without any analyst overhead]. Unlike [Salesforce dashboards and manual reporting], [Product Name] [syncs automatically, surfaces risks before they become missed quarters, and needs no configuration by IT or data teams].
---
## 8. Messaging Hierarchy
Translate the positioning into customer-facing language at three levels:
### Tagline (5–8 words)
[The simplest possible statement of what you do and for whom. Used in ads, hero sections, email signatures.]
Options to test:
1. [e.g. "Revenue intelligence for scaling sales teams"]
2. [e.g. "Forecast with confidence. Close with clarity."]
3. [e.g. "The revenue platform your whole team will actually use"]
### Value Proposition (1–2 sentences)
[Used in the hero section of the website, email subject lines, and sales decks. Must be instantly clear.]
> [e.g. "[Product Name] gives revenue teams real-time pipeline visibility and accurate forecasting — without spreadsheets, custom reports, or waiting for an analyst. Get live in 4 hours, not 4 months."]
### Full Description (3–5 sentences)
[Used in PR, partnership briefs, longer sales emails, and About Us pages.]
> [e.g. "[Product Name] is the revenue intelligence platform built for mid-market SaaS teams. Unlike legacy BI tools that require analyst configuration or CRM dashboards that only show what's already happened, [Product Name] automatically syncs your entire revenue stack, surfaces AI-driven risk signals, and lets any rep or manager ask questions in plain English. [X] customers use [Product Name] to call their quarters with confidence. Average time to live: 4 hours."]
---
## 9. Persona-Specific Messaging
The core positioning is the same, but different buyers care about different aspects:
| Persona | Their primary concern | Lead message | Proof point to use |
|---|---|---|---|
| **VP Revenue Operations** | Forecast accuracy, board credibility | "Call your quarter with confidence" | [X% improvement in forecast accuracy across N customers] |
| **Head of Sales** | Rep productivity, pipeline visibility | "Your reps close more, not admin more" | [X hours/week saved per rep] |
| **CEO / CFO** | Revenue predictability, cost | "Stop being surprised by quarters" | [ROI: £X saved vs X headcount required to replicate manually] |
| **Sales Rep** | Ease of use, not adding to workload | "It works in the tools you already use" | [Ease of use NPS, G2 reviews] |
---
## 10. Messaging Do's and Don'ts
**Do say:**
- [Specific, outcome-focused language — what the customer achieves]
- [Comparative language grounded in evidence]
- [Language your target buyer uses to describe their problem — not language you invented]
**Don't say:**
- ["Best-in-class", "innovative", "cutting-edge", "game-changing" — unless followed by evidence]
- [Feature lists without outcome context]
- [Jargon your buyer doesn't use themselves]
- [Claims your competitors could also make]
---
## 11. Distribution Plan
Positioning only works if it's implemented consistently:
| Team | What they need | Format | Owner | When |
|---|---|---|---|---|
| Marketing | Tagline, value prop, messaging hierarchy | This doc + messaging playbook | PMM | [Date] |
| Sales | Competitive positioning, objection responses | One-pager + deck | Sales enablement | [Date] |
| Product | Category definition, target customer | Shared doc + roadmap input | PMM + PM | [Date] |
| Leadership | Full positioning narrative | This doc | PMM | [Date] |
---
## Quality Checks
- [ ] Positioning statement has exactly one A — the product is accountable to exactly one primary differentiated claim
- [ ] Competitive alternatives include the status quo — not just named competitors
- [ ] Differentiated attributes describe outcomes, not features
- [ ] Every proof point cites a source — not "customers say…"
- [ ] Persona messaging uses the buyer's language, not the company's
- [ ] At least two people from product, marketing, and sales have reviewed and approved
## Example Trigger Phrases
- "Write a positioning document for [product]"
- "Build a messaging framework for our B2B SaaS tool"
- "Define our product positioning — who is this for and why should they care?"
- "Create a positioning statement and messaging hierarchy for [launch]"
- "Help me articulate our differentiation vs [Competitor]"
skills/raci-matrix/SKILL.md
+160
View File
@@ -0,0 +1,160 @@
---
name: raci-matrix
description: "Define a RACI matrix for a cross-functional project or process. Use when asked to build a RACI, create a responsibility matrix, clarify ownership across teams, or document decision rights. Produces a complete RACI matrix with role definitions, decision mapping, and a process for resolving conflicts."
---
# RACI Matrix Skill
This skill produces a complete RACI (Responsible, Accountable, Consulted, Informed) matrix for a project, product launch, or ongoing process. Output is ready to share with teams to clarify ownership, reduce decision bottlenecks, and eliminate duplication of effort.
## Required Inputs
Ask the user for these if not provided:
- **Project or process name**
- **Key activities or decisions** to map (or the user can describe the project and the skill will derive them)
- **Teams or roles involved** (list team names and key individuals if helpful)
- **Primary purpose** — clarifying launch ownership / onboarding a new team / reducing bottlenecks / governance documentation
- **RACI variant** — standard RACI, or RASCI (adds Supportive), or DACI (Driver, Approver, Contributors, Informed)?
## Output Structure
---
# RACI Matrix: [Project / Process Name]
**Version:** [1.0]
**Owner:** [Programme lead / PM]
**Date:** [Date]
**Teams involved:** [List teams]
---
## 1. Role Definitions
Before reading the matrix, agree on what each letter means for this project:
| Letter | Role | Definition | Rules |
|---|---|---|---|
| **R** | Responsible | Does the work. One or more people actually execute the task. | Multiple Rs are allowed — but if there are many, consider splitting the task |
| **A** | Accountable | Owns the outcome. Signs off on decisions. Answers if something goes wrong. | **There must be exactly one A per row.** Never two. Never zero. |
| **C** | Consulted | Provides expertise or input before work is done. Two-way communication. | Consulted parties must be engaged — not just available. Cap at 3 per row or it becomes noise |
| **I** | Informed | Notified of progress or outcomes. One-way communication. | Informed only — they don't review or approve |
**Golden rules:**
- Every row has exactly one **A**
- The same person or team should not be **A** for more than [X] rows — spreads accountability too thin
- **C** is expensive — consulting someone means they must respond. Use it intentionally
- If someone is **R** they cannot also be **A** for the same task unless they are the decision-maker (common in small teams)
---
## 2. RACI Matrix
Columns = teams or roles. Rows = activities or decisions.
| Activity / Decision | [Role 1] | [Role 2] | [Role 3] | [Role 4] | [Role 5] | Notes |
|---|---|---|---|---|---|---|
| **[Phase 1: Discovery]** | | | | | | |
| Define project scope and objectives | A/R | C | I | I | — | PM leads; engineering consulted on technical feasibility |
| Conduct user research | R | A | C | I | — | UX researcher executes; PM accountable |
| Approve discovery findings | C | A | I | R | — | |
| **[Phase 2: Design]** | | | | | | |
| Define solution approach | A | R | C | I | I | |
| Design system / UI designs | C | A/R | I | I | — | |
| Design review and sign-off | C | R | A | I | — | |
| Accessibility review | I | R | A | C | — | |
| **[Phase 3: Build]** | | | | | | |
| Technical architecture decision | C | C | A/R | I | — | |
| Sprint planning | A | C | R | I | I | |
| Code review and merge | I | C | R | A | — | |
| Security review | I | C | C | A/R | — | |
| **[Phase 4: Launch]** | | | | | | |
| Launch go / no-go decision | A | C | C | R | I | PM holds final authority |
| Release to production | C | I | A/R | I | — | |
| Customer communications | A/R | I | I | I | C | |
| Post-launch monitoring | C | I | R | A | — | |
| **[Ongoing / BAU]** | | | | | | |
| Incident response | I | C | R | A | — | |
| Feature prioritisation | A/R | C | C | I | I | |
| Stakeholder reporting | A/R | I | I | I | C | |
---
## 3. Decision Map
For high-stakes decisions, document the decision type, who holds authority, and how disagreements are resolved:
| Decision | Authority (A) | Must consult (C) | Escalation path if disagreed |
|---|---|---|---|
| Scope change >20% effort | [Exec sponsor / Programme lead] | [PM, Engineering lead] | [Steering committee] |
| Budget overrun >10% | [Finance / Exec] | [PM, Programme lead] | [CFO / Board] |
| Architecture pattern change | [Engineering lead] | [Tech lead, Security] | [CTO] |
| Go-live date change | [PM] | [Engineering, Comms, CS] | [Programme sponsor] |
| Feature cut from scope | [PM] | [Product, UX, Engineering] | [CPO] |
---
## 4. Common RACI Anti-Patterns — and Fixes
Review the completed matrix against these failure modes:
| Anti-pattern | Symptom | Fix |
|---|---|---|
| **Multiple As** | Two teams both think they own an outcome | Agree one A; the other becomes C or I |
| **No A** | Decisions stall; no one feels responsible | Assign the most senior stakeholder as A |
| **Everyone is C** | Every decision goes to a committee | Audit each C — does this person actually provide input that changes outcomes? If not, move to I |
| **R without A** | Work gets done but no one owns quality | Add an A; usually the manager of the R |
| **A without R** | Accountability without execution — manager is disconnected | Add an R from the team; or combine A/R if appropriate |
| **Too many Rs** | Diffusion of responsibility | Split the task into sub-tasks, each with one clear R |
| **Key team missing from matrix** | They're affected but not in the RACI | Add them; assign at minimum I for relevant rows |
---
## 5. Communication Template
Once the RACI is agreed, use this template to communicate it to all involved teams:
---
**Subject:** [Project Name] — Roles and Responsibilities Agreed
We've finalised the RACI matrix for [Project Name]. Here's what it means for you:
**[Role 1 team]:** You are **Accountable** for [X, Y, Z activities]. This means you make the final call on those decisions and answer if outcomes are not met.
**[Role 2 team]:** You are **Responsible** for [A, B, C]. You execute the work. For [D], you are **Consulted** — we need your input before decisions are finalised.
**[Role 3 team]:** You are **Informed** on [E, F] — we'll send you updates at [weekly / milestone / launch]. No action required unless you see something that needs escalation.
Please review the full matrix here: [Link]. Raise any concerns by [Date] — after that, we'll treat it as agreed.
---
## 6. RACI Review Cadence
| Trigger | Action |
|---|---|
| New team member joins | Review rows relevant to their role — update R as needed |
| Phase change (e.g. discovery → delivery) | Review full matrix — some Rs and As will shift |
| Escalation or confusion about ownership | Use the matrix to diagnose — find the missing A |
| 3 months into a long programme | Full RACI review — roles drift over time |
| Team restructure or reorganisation | Full rebuild — ownership assumptions change |
---
## Quality Checks
- [ ] Every row has exactly one **A**
- [ ] No individual or team is **A** for more than their realistic sphere of authority
- [ ] **C** columns are sparse — consulting everyone dilutes the process
- [ ] Matrix was reviewed and agreed by at least one representative from each role column
- [ ] A communication plan exists to share the RACI with all involved parties
- [ ] Decision map covers the top 5–10 highest-stakes decisions in the project
## Example Trigger Phrases
- "Build a RACI matrix for our product launch"
- "Create a responsibility matrix for our new cross-functional project"
- "Who owns what on this initiative? Help me build a RACI"
- "Map out decision rights for our engineering and product teams"
- "Generate a RACI for a [migration / launch / process] involving [teams]"
skills/renewal-playbook/SKILL.md
+190
View File
@@ -0,0 +1,190 @@
---
name: renewal-playbook
description: "Build a structured renewal playbook for a customer account. Use when asked to plan a renewal, structure a renewal negotiation, prepare for an expansion conversation, or build a renewal strategy for at-risk or healthy accounts. Produces a renewal brief with health assessment, negotiation strategy, objection responses, expansion levers, and a timeline."
---
# Renewal Playbook Skill
This skill produces a complete renewal playbook for a specific customer account, covering health assessment, commercial strategy, negotiation preparation, expansion opportunity mapping, and a step-by-step timeline. Output is ready for the CSM or account team to execute 90–180 days before renewal.
## Required Inputs
Ask the user for these if not provided:
- **Account name**
- **Renewal date**
- **Current ARR** and proposed renewal ARR (if different)
- **Account health** — RAG status and main reasons (or describe the account situation)
- **Key stakeholders** — economic buyer, champion, and any detractors
- **Renewal risk factors** — budget pressure, low adoption, competitive threat, champion departure, etc.
- **Expansion opportunity** — any upsell or cross-sell potential?
- **Contract terms** — current plan, duration, and any terms up for renegotiation
## Output Structure
---
# Renewal Playbook: [Account Name]
**Renewal date:** [Date]
**Current ARR:** [£/$/€ X]
**Target renewal ARR:** [£/$/€ X — flat / +X% expansion / contraction risk]
**Health status:** [Green / Amber / Red]
**CSM:** [Name]
**Account executive:** [Name]
**Days to renewal:** [X days]
---
## 1. Account Health Snapshot
| Dimension | Score (1–5) | Evidence |
|---|---|---|
| **Product adoption** | [X/5] | [e.g. 3 of 5 purchased seats active; core feature used weekly] |
| **Business outcomes** | [X/5] | [e.g. Customer reports X% improvement in [metric]; no formal ROI review done] |
| **Relationship depth** | [X/5] | [e.g. Strong champion in [name/role]; limited exec sponsorship] |
| **Support & satisfaction** | [X/5] | [e.g. 2 open P2 tickets; last NPS 7; no escalations in 6 months] |
| **Commercial engagement** | [X/5] | [e.g. Invoice paid on time; no discount pressure raised yet] |
| **Overall health** | [X/5 — weighted] | [Green / Amber / Red] |
**Renewal thesis:** [One sentence: why this account will renew — or what must change for it to renew.]
---
## 2. Stakeholder Map
| Stakeholder | Role | Influence | Sentiment | Our relationship |
|---|---|---|---|---|
| [Name] | Economic buyer | High | [Positive / Neutral / Negative] | [Warm / Cold / Unknown] |
| [Name] | Champion | High | [Positive] | [Warm] |
| [Name] | End user | Low | [Neutral] | [Limited] |
| [Name] | IT / procurement | Medium | [Neutral] | [Transactional] |
**Champion risk:** [Is our champion secure in their role? Any signals of departure or reorganisation?]
**Multi-thread plan:** [Who else do we need relationships with before renewal? How do we get there?]
---
## 3. Risk Register
| Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation |
|---|---|---|---|
| [Budget pressure / cost-cutting] | [H] | [H] | [Build ROI case 90 days out; identify budget holder's priorities] |
| [Low adoption in [department]] | [M] | [H] | [Run targeted enablement session; tie to champion's OKRs] |
| [Competitor evaluation] | [M] | [M] | [Request competitive intelligence; schedule exec-level call] |
| [Champion departure] | [L] | [H] | [Map two additional stakeholders; executive intro call] |
---
## 4. Value Story
Build the ROI narrative for the renewal conversation:
**Headline result:** [e.g. "[Account] saved X hours/week or reduced [metric] by X% using [product]"]
**Evidence sources:**
- [ ] Product usage data (logins, features used, seat utilisation)
- [ ] Business metric improvement (pull from QBR deck or success plan)
- [ ] Support resolution time improvement
- [ ] Customer-provided testimonial or case study quotes
**Value gaps to close before renewal:** [Are there outcomes the customer expected but hasn't seen yet? What's the plan to close these?]
---
## 5. Expansion Opportunity
Map upside beyond flat renewal:
| Opportunity | Type | Estimated value | Likelihood | Timing |
|---|---|---|---|---|
| [Seat expansion — [dept] wants to add 10 users] | Upsell | [+£X ARR] | [High] | [Renewal or +3M] |
| [Cross-sell — [Product B] use case identified] | Cross-sell | [+£X ARR] | [Medium] | [+6M] |
| [Multi-year commitment] | Discount for term | [+£X TCV / -X% discount] | [Low] | [At renewal] |
**Expansion play:** [Which opportunity to lead with, and the sequence for raising it in the renewal conversation]
---
## 6. Commercial Strategy
**Renewal scenario planning:**
| Scenario | Probability | ARR outcome | Response strategy |
|---|---|---|---|
| **Flat renewal** | [X%] | [£X — same as current] | [Accept; plant seeds for +6M expansion] |
| **Expansion** | [X%] | [£X] | [Lead with ROI evidence; pitch seat or feature expansion] |
| **Contraction risk** | [X%] | [£X — downgrade to lower tier] | [Propose phased commitment; demonstrate path to full adoption] |
| **Churn risk** | [X%] | [£0] | [Escalate to leadership; executive sponsor engagement] |
**Discount guardrails:**
- Floor discount: [X% — do not go below without VP approval]
- Triggers for discount: [Multi-year / volume / reference customer commitment]
- What to ask for in return: [Reference case study / G2 review / executive intro / case study participation]
**Pricing flexibility:**
- [e.g. Can offer monthly billing in exchange for 24-month commit]
- [e.g. Can offer X seats free in exchange for expansion commitment]
---
## 7. Objection Responses
Prepare for the most likely objections:
**"The price is too high"**
> Anchor on value delivered: "[Customer] achieved [X outcome] — at [£X ARR], that's [£Y per outcome / hour saved / user]. What would it cost to deliver that outcome without us?"
> If budget is genuinely constrained, explore: phased payment, reduction in scope rather than full churn, multi-year pricing.
**"We're not seeing enough adoption"**
> Acknowledge, then commit: "You're right — [X seats] are actively using [core feature] out of [Y]. We want to fix this. Here's our 60-day plan: [exec sponsor on enablement call / training session / in-product nudge campaign]."
**"We're evaluating [Competitor]"**
> Don't panic. Ask: "What's driving the evaluation — is it specific features, pricing, or something else?" Then map gaps honestly. Offer a feature roadmap preview if relevant. Get clarity on their criteria and timeline before responding defensively.
**"We need to reduce spend this quarter"**
> Separate the commercial conversation from the value conversation. Offer to protect the relationship with a reduced scope today with a committed expansion trigger at a business milestone. Avoid discounting without a reason.
---
## 8. Renewal Timeline
| Week | Action | Owner | Notes |
|---|---|---|---|
| **W–16** (4 months out) | Internal renewal review — health, expansion opportunity, risk | CSM | Flag to leadership if Red |
| **W–12** | QBR / executive business review — ROI evidence delivered | CSM + AE | Book 45–60 min with economic buyer |
| **W–10** | Champion 1:1 — pulse check on satisfaction and upcoming priorities | CSM | Uncover internal dynamics before commercial discussion |
| **W–8** | Expansion conversation — plant seeds, share roadmap | AE | Do not lead with pricing |
| **W–6** | Send renewal proposal — pricing, terms, options | AE | Include multi-year option |
| **W–4** | Negotiation — address objections, finalise commercial terms | AE + CSM | Escalate to VP if >X% discount required |
| **W–2** | Legal / procurement — contract redlines, signature process | AE + Legal | |
| **W–0** | Signed. Handoff to post-renewal success plan | CSM | Thank the champion; begin next cycle |
---
## 9. Success Criteria
- [ ] Renewal signed before deadline
- [ ] ARR outcome within target range
- [ ] Champion relationship maintained or improved
- [ ] At least one expansion conversation started
- [ ] ROI evidence documented and accepted by customer
---
## Quality Checks
- [ ] Stakeholder map includes the economic buyer — not just the champion
- [ ] Risk register has a mitigation for every H/H risk
- [ ] Value story uses product data and business outcomes, not just feature lists
- [ ] Commercial strategy includes a floor discount and a reason-to-discount framework
- [ ] Timeline starts at least 90 days before renewal date
- [ ] Objection responses are specific to this account, not generic
## Example Trigger Phrases
- "Build a renewal playbook for [Account Name] renewing in [Month]"
- "Help me plan the renewal strategy for an at-risk customer"
- "Prepare a renewal brief for my QBR with [Company]"
- "What's my renewal strategy for a Red account coming up in 60 days?"
- "Create a renewal and expansion plan for [Account]"
skills/risk-register/SKILL.md
+211
View File
@@ -0,0 +1,211 @@
---
name: risk-register
description: "Build and maintain a project or product risk register. Use when asked to create a risk register, identify project risks, build a risk matrix, or document risks and mitigations for a programme. Produces a complete risk register with likelihood/impact scoring, RAG status, ownership, and prioritised mitigations."
---
# Risk Register Skill
This skill produces a complete risk register for a project, programme, or product. Output follows standard risk management practice with likelihood × impact scoring, RAG status, a risk heat map, and specific mitigation and contingency plans. Ready to share with a project board, steering committee, or programme office.
## Required Inputs
Ask the user for these if not provided:
- **Project or product name**
- **Project stage** (discovery / delivery / launch / live / programme-level)
- **Key objectives** — what is the project trying to achieve?
- **Known risks** — anything already on the team's radar (even informal concerns count)
- **Key dependencies** — external vendors, teams, systems, or regulatory approvals
- **Deadline or milestone sensitivity** — are there hard dates that cannot move?
- **Audience** — who will read this? (internal team / executive steering / external board / regulator)
## Output Structure
---
# Risk Register: [Project / Product Name]
**Project stage:** [Discovery / Delivery / Launch / Live / Programme]
**Version:** [1.0]
**Owner:** [PM / Programme Manager / Risk Lead]
**Last reviewed:** [Date]
**Next review:** [Date — recommend weekly during delivery, monthly during discovery]
**Status:** [Active / Archived]
---
## 1. Risk Scoring Framework
**Likelihood (L)**
| Score | Label | Definition |
|---|---|---|
| 5 | Almost certain | >80% probability of occurring |
| 4 | Likely | 60–80% probability |
| 3 | Possible | 40–60% probability |
| 2 | Unlikely | 20–40% probability |
| 1 | Rare | <20% probability |
**Impact (I)**
| Score | Label | Definition |
|---|---|---|
| 5 | Critical | Programme failure, regulatory breach, major financial loss, safety event |
| 4 | High | Significant schedule delay (>4 weeks), scope reduction, reputational damage |
| 3 | Medium | Moderate delay (1–4 weeks), cost overrun, reduced quality |
| 2 | Low | Minor delay (<1 week), manageable cost increase |
| 1 | Negligible | Minimal impact, easily absorbed |
**Risk Score = L × I**
| Score | RAG | Action |
|---|---|---|
| 20–25 | 🔴 Critical | Immediate escalation; active management required |
| 12–19 | 🔴 High | Owner-assigned mitigation; weekly review |
| 8–11 | 🟡 Medium | Mitigation planned; fortnightly review |
| 4–7 | 🟡 Low | Monitor; monthly review |
| 1–3 | 🟢 Negligible | Accept; review if context changes |
---
## 2. Risk Register
| ID | Risk | Category | L | I | Score | RAG | Owner | Status | Mitigation | Contingency | Review date |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R01 | [Risk description — be specific: "Third-party API may not support required volume, causing X to fail"] | [Schedule / Technical / Resource / Commercial / Compliance / External] | [1–5] | [1–5] | [L×I] | 🔴/🟡/🟢 | [Name] | [Open / Mitigating / Closed] | [What are we doing to reduce likelihood or impact?] | [What do we do if it happens?] | [Date] |
| R02 | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] |
---
## 3. Risk Categories — Common Risks by Type
Use these to prompt risk identification. Add, remove, or customise for your project.
### Schedule & Delivery
- Key milestone depends on a dependency that has not confirmed availability
- Team capacity reduced by planned or unplanned absence during critical period
- Technical complexity is underestimated — story points consistently overrun
- External approval (regulator, legal, procurement) takes longer than planned
### Technical
- Integration with a third-party system not yet prototyped or agreed
- Existing technical debt makes the change harder or riskier than estimated
- Security or compliance review required before launch has not been scoped
- Performance under production load untested
- Key technical knowledge held by one person (single point of failure)
### Resource & People
- Key SME or engineer leaving or unavailable during critical phase
- Budget not confirmed for Phase 2 of the project
- Stakeholder sponsor changes role or leaves the organisation
- Team not yet at full capacity (hiring lag, access issues, onboarding time)
### Commercial & Financial
- Vendor or partner contract not yet signed
- Cost estimate based on assumptions that have not been validated
- Revenue or savings case depends on assumptions outside the team's control
- Currency exposure or exchange rate risk for international projects
### Compliance & Regulatory
- Data privacy impact assessment (DPIA) not yet complete
- Regulatory approval required and timeline is uncertain
- GDPR, HIPAA, SOC 2, or sector-specific compliance requirement not yet mapped
- Legal review of terms of service or contracts pending
### Stakeholder & Adoption
- Key user group has low awareness or motivation to adopt the change
- Internal resistance from a team that will be affected by the change
- Executive sponsor not consistently engaged — decisions are slow
- Communications plan not yet agreed with change management team
### External
- Market or competitive change could undermine the business case
- Macroeconomic conditions affect budget or priority
- Supplier or infrastructure provider risk (e.g. cloud provider, hardware)
- Geopolitical or regulatory environment change
---
## 4. Risk Heat Map
Plot risks by likelihood (Y axis) and impact (X axis):
```
│ Low Medium High Critical
│ (1) (2-3) (4) (5)
─────────┼────────────────────────────────────
Almost │ 🟡 🟡 🔴 🔴
certain │
(5) │
─────────┼────────────────────────────────────
Likely │ 🟡 🟡 🔴 🔴
(4) │
─────────┼────────────────────────────────────
Possible │ 🟢 🟡 🟡 🔴
(3) │
─────────┼────────────────────────────────────
Unlikely │ 🟢 🟢 🟡 🟡
(2) │
─────────┼────────────────────────────────────
Rare │ 🟢 🟢 🟢 🟡
(1) │
```
[Plot each risk ID on this grid — e.g. R01 lands at L4/I5 = 🔴 Critical]
---
## 5. Top Risks — Executive Summary
For steering committee or board-level reporting:
| Rank | Risk | Score | RAG | Owner | Mitigation status |
|---|---|---|---|---|---|
| 1 | [Most critical risk — plain English description] | [X] | 🔴 | [Owner] | [Active / Planned / Not started] |
| 2 | [...] | [...] | 🔴 | [...] | [...] |
| 3 | [...] | [...] | 🟡 | [...] | [...] |
| 4 | [...] | [...] | 🟡 | [...] | [...] |
| 5 | [...] | [...] | 🟡 | [...] | [...] |
**Decisions required from steering:**
- [Any risk that requires budget, scope, or timeline decision to mitigate]
---
## 6. Risk Changes Since Last Review
| Risk ID | Change | Detail |
|---|---|---|
| [R03] | Score increased | [L moved from 2 → 4 — vendor confirmed delay in API availability] |
| [R07] | Risk closed | [Legal sign-off received on 12 May] |
| [NEW] | New risk identified | [R09 — budget freeze announcement affects Phase 2 funding] |
---
## 7. Risk Closure Criteria
A risk is closed when:
- The risk event can no longer occur (e.g. milestone passed, contract signed), OR
- The residual risk score drops to Negligible (1–3) AND the team formally accepts it, OR
- The risk has materialised and transitioned to an **issue** (tracked separately)
**Issues log:** [Link to issues log — risks that have materialised and are now active problems being managed]
---
## Quality Checks
- [ ] Every risk has a specific owner — not "the team" or "TBD"
- [ ] Mitigations describe what is actively being done — not "monitor and review"
- [ ] Contingency plans exist for all Critical and High risks
- [ ] Risk descriptions are specific — "vendor may be late" is not specific enough; name the vendor and the dependency
- [ ] Register has been reviewed in the last [X] days
- [ ] Closed risks are archived, not deleted — they provide audit trail
- [ ] Risks are distinguished from issues — a risk is something that might happen; an issue is something that has happened
## Example Trigger Phrases
- "Build a risk register for our product launch"
- "Create a risk matrix for [project name]"
- "What risks should I document for a data migration project?"
- "Generate a risk register for our steering committee"
- "Help me identify and score risks for our Q3 delivery plan"
skills/social-media-strategy/SKILL.md
+237
View File
@@ -0,0 +1,237 @@
---
name: social-media-strategy
description: "Build a social media strategy for a brand, product, or creator. Use when asked to create a social media strategy, define a social content strategy, plan content pillars, set social KPIs, or build a posting framework. Produces a complete strategy with audience definition, platform selection, content pillars, posting cadence, KPIs, and a 4-week starter calendar."
---
# Social Media Strategy Skill
This skill produces a complete social media strategy covering audience definition, platform rationale, content pillars, posting cadence, tone of voice guidelines, measurement framework, and a 4-week starter content calendar. Output is ready for a marketing team, founder, or agency to execute immediately.
## Required Inputs
Ask the user for these if not provided:
- **Brand / product / creator name**
- **What you're promoting** — product, service, personal brand, community, or event
- **Target audience** — who are you trying to reach? (job title, age, interests, platforms they use)
- **Business goal** — what does social need to achieve? (brand awareness / lead generation / community building / sales / recruitment)
- **Current social presence** — which platforms are you on? What's working, what isn't?
- **Competitors or aspirational accounts** — who does social well in your space?
- **Resources** — how many people and how much time per week can you dedicate to social?
## Output Structure
---
# Social Media Strategy: [Brand / Product / Creator]
**Goal:** [Primary business goal]
**Audience:** [1-sentence description of primary audience]
**Timeframe:** [e.g. Q3 2026 — 3-month strategy]
**Owner:** [Marketing lead / founder / social team]
**Date:** [Date]
---
## 1. Audience Profile
**Primary audience:**
| Dimension | Detail |
|---|---|
| **Who they are** | [Job title, age range, life stage, geography] |
| **What they care about** | [Professional or personal priorities, pain points] |
| **Where they spend time online** | [Platforms, communities, influencers they follow] |
| **What they consume** | [Content formats they engage with — video, threads, newsletters, podcasts] |
| **What would make them follow you** | [The specific value proposition of your social presence] |
**Secondary audience:** [Any secondary segment — e.g. job seekers if you're a brand, investors if you're a startup]
---
## 2. Platform Strategy
Not every platform is right for every brand. Justify each platform choice:
| Platform | Audience fit | Content format | Priority | Why (or why not) |
|---|---|---|---|---|
| **LinkedIn** | [B2B / professional] | [Text posts, carousels, articles] | [Primary / Secondary / Skip] | [e.g. Primary platform for B2B SaaS — where buyers and influencers are] |
| **X / Twitter** | [Tech, media, founders] | [Short text, threads, replies] | [...] | [...] |
| **Instagram** | [Consumer, visual brands, creators] | [Reels, Stories, carousels] | [...] | [...] |
| **TikTok** | [B2C, Gen Z, consumer] | [Short-form video] | [...] | [...] |
| **YouTube** | [All audiences — discovery + long-form] | [Long-form video, Shorts] | [...] | [...] |
| **Threads** | [Text-first, creator, early adopter] | [Short text, conversations] | [...] | [...] |
**Lead platform:** [One platform to invest most heavily in — where your audience is most active and where you have the best chance to stand out]
**Supporting platforms:** [1–2 secondary platforms where you'll repurpose or adapt content]
---
## 3. Content Pillars
Define 3–5 content themes that anchor your social presence. Each pillar must serve the audience, not just the brand.
### Pillar 1: [Name — e.g. "Behind the build"]
**What it is:** [1-sentence description]
**Why the audience cares:** [What value does this deliver to them?]
**Content examples:**
- [e.g. Engineering decisions we made and why]
- [e.g. Week-in-the-life of the founding team]
- [e.g. What we shipped this week and what we learned]
**Format mix:** [Carousel / video / thread / short-form text]
**Posting cadence:** [X times per week]
---
### Pillar 2: [Name — e.g. "Practical education"]
**What it is:** [...]
**Why the audience cares:** [...]
**Content examples:**
- [...]
- [...]
**Format mix:** [...]
**Posting cadence:** [...]
---
### Pillar 3: [Name — e.g. "Social proof and community"]
**What it is:** [Customer stories, testimonials, user-generated content, community spotlights]
**Why the audience cares:** [Validation from peers carries more weight than brand claims]
**Content examples:**
- [Customer outcome stories — 1 metric + 1 quote format]
- [Repost community member wins]
- [Case study carousels]
**Format mix:** [...]
**Posting cadence:** [...]
---
### Pillar 4: [Name — e.g. "Point of view"]
**What it is:** [Opinions on industry trends, hot takes, commentary on news in your space]
**Why the audience cares:** [People follow accounts that say something, not just share information]
**Content examples:**
- [Contrarian takes on common advice]
- [Reaction to industry news — what it means for your audience]
- [Founder's personal perspective on a topic]
**Format mix:** [...]
**Posting cadence:** [...]
---
## 4. Tone of Voice
Define how your brand sounds on social — before you write a single post:
| Dimension | [Your brand] sounds like... | [Your brand] does NOT sound like... |
|---|---|---|
| **Formality** | [e.g. Conversational, plain English] | [Corporate speak, jargon] |
| **Energy** | [e.g. Curious, enthusiastic] | [Aggressive, hypey] |
| **Personality** | [e.g. Smart friend who happens to be an expert] | [Faceless institution] |
| **Humour** | [e.g. Dry wit, occasional] | [Try-hard memes, sarcasm] |
| **Self-promotion** | [e.g. Earns the right to mention the product] | [Every post is an ad] |
**Reference accounts that nail the tone you're aiming for:** [Name 2–3 accounts — and why]
---
## 5. Posting Cadence & Workflow
| Platform | Posts per week | Best days | Best times | Format split |
|---|---|---|---|---|
| [LinkedIn] | [3–5] | [Tue–Thu] | [07:30–09:00 or 12:00–13:00] | [60% educational, 30% POV, 10% product] |
| [X / Twitter] | [5–7] | [Any] | [Morning and lunchtime] | [50% replies/engagement, 30% original, 20% reposts] |
| [Instagram] | [3–4] | [Mon, Wed, Fri] | [18:00–20:00] | [50% Reels, 30% carousels, 20% Stories] |
**Content production workflow:**
| Day | Activity | Owner | Time required |
|---|---|---|---|
| Monday | Plan the week's content — review pillars, select topics | [Social manager] | 30 min |
| Tuesday | Write long-form posts for LinkedIn and threads | [Writer / founder] | 60 min |
| Wednesday | Design carousels or graphics | [Designer / Canva] | 45 min |
| Thursday | Schedule the week's content in [Buffer / Hootsuite / Later] | [Social manager] | 20 min |
| Daily | Engage with comments, reply to mentions, interact with community | [Social manager] | 15 min |
---
## 6. Growth Tactics
Beyond posting, how will you grow your following and reach?
| Tactic | Description | Platform | Frequency |
|---|---|---|---|
| **Engage before you post** | Spend 15 min commenting on posts from target accounts before posting your own | All | Daily |
| **Collaboration posts** | Co-create content with a complementary brand or creator | LinkedIn / IG | Monthly |
| **Community participation** | Answer questions in relevant groups, subreddits, or Discord servers | LinkedIn / Reddit / Discord | Weekly |
| **Tag relevant accounts** | When mentioning companies, tools, or people — tag them (earns reshares) | All | As relevant |
| **Cross-promote** | Mention your social in newsletters, emails, events, and podcast appearances | All | Ongoing |
| **Use trending formats early** | When a new format (e.g. LinkedIn carousels, IG Reels) emerges, adopt early | Platform-specific | When relevant |
---
## 7. Measurement Framework
**Primary KPIs (tied to business goal):**
| KPI | Platform | Current baseline | Target (90 days) | Why it matters |
|---|---|---|---|---|
| [Follower growth rate] | [LinkedIn] | [X%/month] | [≥ Y%/month] | [Audience reach] |
| [Engagement rate] | [LinkedIn] | [X%] | [≥ Y%] | [Content resonance] |
| [Link clicks / traffic from social] | [All] | [X visits/month] | [≥ Y visits/month] | [Direct business impact] |
| [Inbound leads attributed to social] | [LinkedIn] | [X/month] | [≥ Y/month] | [Revenue impact] |
**Secondary metrics (health indicators):**
- Reach per post
- Saves and shares (not just likes)
- Comment sentiment and quality
- DMs initiated from content
**Reporting cadence:** [Weekly check on engagement / Monthly review of follower and traffic / Quarterly strategy review]
---
## 8. 4-Week Starter Content Calendar
A concrete first month of content — ready to adapt and post:
| Week | Day | Platform | Pillar | Format | Topic idea |
|---|---|---|---|---|---|
| 1 | Mon | LinkedIn | Education | Carousel | [e.g. "5 things we wished we knew before building [X]"] |
| 1 | Wed | LinkedIn | Behind the build | Text post | [e.g. "We almost gave up in month 3. Here's what changed."] |
| 1 | Fri | Instagram | Social proof | Reel | [e.g. Customer story — problem → solution → result] |
| 2 | Tue | LinkedIn | POV | Thread | [e.g. "Hot take: [common advice in your space] is wrong. Here's why."] |
| 2 | Thu | X/Twitter | Education | Thread | [e.g. "The [X] framework we use every week — and how you can steal it"] |
| 2 | Sat | Instagram | Behind the build | Story | [e.g. "Week 2 update — what we shipped and one thing that didn't go to plan"] |
| 3 | Mon | LinkedIn | Education | Carousel | [e.g. "How to [achieve outcome] in [timeframe] — step by step"] |
| 3 | Wed | LinkedIn | Community | Text post | [e.g. Reshare a customer win with commentary] |
| 3 | Fri | Instagram | POV | Reel | [e.g. "[Industry myth] — why we disagree and what we do instead"] |
| 4 | Tue | LinkedIn | Behind the build | Video | [e.g. Founder talking to camera — "One thing I learned building [X] this month"] |
| 4 | Thu | X/Twitter | POV | Thread | [e.g. "[Trend in your space] — here's what's actually happening"] |
| 4 | Sat | All | Milestone | Text + image | [e.g. "[X followers / X users / X months] — thank you + what's next"] |
---
## Quality Checks
- [ ] Every content pillar delivers value to the audience — not just the brand
- [ ] Platform selection is justified by where the target audience actually spends time
- [ ] Tone of voice examples are specific enough to use as a writing guide
- [ ] KPIs are tied to the business goal, not just vanity metrics (likes, followers in isolation)
- [ ] Posting cadence is realistic for the available resources — sustainable beats ambitious
- [ ] The 4-week calendar has specific topic ideas, not just "write an educational post"
## Example Trigger Phrases
- "Build a social media strategy for [brand/product]"
- "Create a LinkedIn content strategy for our B2B SaaS"
- "Help me define content pillars and posting cadence for our startup"
- "Design a 90-day social media plan for [company]"
- "What should our social media strategy be for a product launch?"
skills/team-health-check/SKILL.md
+262
View File
@@ -0,0 +1,262 @@
---
name: team-health-check
description: "Run a structured team health assessment. Use when asked to run a team health check, assess team morale, facilitate a team retrospective on ways of working, or evaluate team dynamics. Produces a health assessment across key dimensions with RAG status, underlying signals, and prioritised improvement actions."
---
# Team Health Check Skill
This skill produces a structured team health assessment inspired by Spotify's health check model and extended with engineering, product, and cross-functional team dimensions. Output can be used as a facilitation guide for a live session or as an async survey-and-report format.
## Required Inputs
Ask the user for these if not provided:
- **Team name and function** (engineering squad, product team, sales pod, etc.)
- **Team size and composition** (how many people, what roles)
- **Format** — facilitated live session or async survey + report?
- **Context** — why are you running this now? (new team / ongoing ritual / post-incident / low morale signal)
- **Any known issues** — anything the facilitator knows going in that will colour the results?
## Output Structure
---
# Team Health Check: [Team Name]
**Date:** [Date]
**Facilitated by:** [Name or role]
**Team size:** [X people]
**Format:** [Live session (60 min) / Async survey + report]
**Cycle:** [One-off / Quarterly / Monthly]
---
## Part 1: Facilitation Guide (Live Session)
Use this guide to run the session in 60 minutes.
### Session structure
| Time | Activity | Owner |
|---|---|---|
| 0–5 min | Framing and ground rules | Facilitator |
| 5–40 min | Card voting — 7 dimensions, 5 min each | Full team |
| 40–50 min | Top 3 themes discussion | Full team |
| 50–58 min | Actions and owners | Team lead |
| 58–60 min | Close and next date | Facilitator |
### Ground rules (read at start)
- This is not a performance review — there are no wrong answers
- We're assessing the team, not individuals — speak about "we" not "they"
- What's said here stays here — results shared as aggregated themes, not attributed to individuals
- The goal is one or two actionable improvements, not a long list
### Voting mechanic
For each dimension, each team member votes with one of three cards:
- 🟢 **Green** — working well, we're proud of this
- 🟡 **Amber** — some things work, but there are issues worth discussing
- 🔴 **Red** — we have a real problem here that's slowing us down
After voting, the team discusses: what drove the votes? What would make this Green?
---
## Part 2: Health Dimensions
---
### Dimension 1: Delivering Value
*Are we shipping things that matter, at the pace we should?*
| Indicator | Probes for discussion |
|---|---|
| We ship work that creates real value for our users | How do we know our output is valuable? When did we last talk to a user? |
| Our pace of delivery feels healthy and sustainable | Are we consistently shipping? Or do we have long dry spells? |
| We have clarity on what "done" looks like | Do we have a shared definition of ready and done? |
| We celebrate shipping, not just building | Do we acknowledge completed work, or does it just disappear into the backlog? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 2: Easy to Release
*Is releasing software (or our work) smooth and low-risk?*
| Indicator | Probes for discussion |
|---|---|
| We can release whenever we choose, without anxiety | What does a release feel like? Smooth or stressful? |
| Our deployment process is automated and reliable | How much manual work does a release involve? |
| We have confidence in our test coverage | Do we catch bugs before users do? |
| Rollback is fast and rehearsed | Have we ever rolled back? How long did it take? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 3: Fun & Morale
*Do people enjoy working here and with each other?*
| Indicator | Probes for discussion |
|---|---|
| People generally enjoy coming to work | If you had to describe the team energy in one word, what would it be? |
| We celebrate successes as a team | When did we last properly celebrate something? |
| Interpersonal dynamics are healthy — no drama or cliques | Are there any relationships that are strained or avoided? |
| We laugh and have non-work conversations | Do we know each other as people, not just colleagues? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 4: Psychological Safety
*Can people speak up, take risks, and make mistakes without fear?*
| Indicator | Probes for discussion |
|---|---|
| People raise concerns without worrying about the consequences | When did someone last raise a concern publicly? What happened? |
| Mistakes are treated as learning opportunities, not blame events | Think of the last mistake on the team. How was it handled? |
| People challenge each other's ideas in a constructive way | Do we have real debates, or do we agree in the room and disagree in the corridor? |
| Everyone's voice feels equally heard regardless of seniority | Do the same people always speak first and longest? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 5: Speed & Feedback Loops
*Do we learn fast and adjust quickly?*
| Indicator | Probes for discussion |
|---|---|
| We get feedback on our work quickly (from users, data, tests) | How long after shipping do we know if something worked? |
| Our planning and retrospective cycles help us improve | Do retros lead to real change, or do the same issues come back? |
| We cut work that isn't working, even when it's hard | Can you name something we've stopped doing because it wasn't working? |
| Our meetings and processes don't slow us down | Which meetings do people dread? Which do they find valuable? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 6: Mission & Purpose
*Do we understand why our work matters?*
| Indicator | Probes for discussion |
|---|---|
| Everyone on the team can articulate why their work matters | Could each person on this team explain to a stranger why their work is important? |
| The team's goals are clear and shared | Can everyone name the team's top 3 priorities right now? |
| Our work connects to the wider company direction | Do we understand how we fit into the bigger picture? |
| We're proud of what this team builds | If you described your team's work to someone you respect, would you feel good about it? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
### Dimension 7: Collaboration & Support
*Do we work well together and support each other?*
| Indicator | Probes for discussion |
|---|---|
| People actively help each other when someone is stuck | Think of the last time someone was blocked — what happened? |
| Knowledge is shared openly — no information silos | Is there any knowledge that only one person holds? What's the risk? |
| Cross-team collaboration is smooth and low-friction | Which team is hardest to collaborate with and why? |
| People feel supported when they're struggling | Is there psychological safety to say "I'm struggling with this"? |
**Current vote:** 🟢 / 🟡 / 🔴
**Key themes from discussion:**
**What would make this Green?**
---
## Part 3: Health Summary & Report
Use this template to document results after the session or survey.
---
### RAG Summary Dashboard
| Dimension | Score | Status | Trend vs last quarter |
|---|---|---|---|
| Delivering Value | [X/5] | 🟢 / 🟡 / 🔴 | [↑ / → / ↓] |
| Easy to Release | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Fun & Morale | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Psychological Safety | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Speed & Feedback Loops | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Mission & Purpose | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| Collaboration & Support | [X/5] | 🟢 / 🟡 / 🔴 | [...] |
| **Overall** | **[X/5]** | 🟢 / 🟡 / 🔴 | [↑ / → / ↓] |
---
### Top Themes
**What's working well (keep doing):**
1. [...]
2. [...]
**What needs attention (most important to fix):**
1. [Most pressing issue — specific, with evidence from the session]
2. [Second issue]
3. [Third issue — if applicable]
---
### Action Plan
| Action | Owner | Due date | Success indicator |
|---|---|---|---|
| [Specific action — e.g. Introduce pairing Fridays for knowledge sharing] | [Team lead / individual] | [Date] | [How will we know it worked?] |
| [...] | [...] | [...] | [...] |
**Next health check:** [Date — recommended 6–8 weeks for teams with active improvement actions, 13 weeks for steady-state teams]
---
## Quality Checks
- [ ] Session ground rules established psychological safety before voting started
- [ ] Each dimension had open discussion, not just a vote
- [ ] Actions are specific enough to be verifiably done — no vague commitments like "improve communication"
- [ ] Each action has a single owner — not "the team"
- [ ] Results are shared with the team, not kept by management
- [ ] Trend data is tracked across cycles to show improvement or regression
## Example Trigger Phrases
- "Run a team health check for my engineering squad"
- "Facilitate a team health assessment — we've had some morale issues"
- "Build a team health check survey for my product team"
- "Generate a Spotify-style health check for our cross-functional pod"
- "Create a quarterly team health check template"
skills/user-story-writer/SKILL.md
+218
View File
@@ -0,0 +1,218 @@
---
name: user-story-writer
description: "Write well-structured user stories with acceptance criteria and edge cases. Use when asked to write user stories, create tickets from a feature brief, convert a PRD into stories, or write acceptance criteria. Produces ready-to-estimate stories in the standard format with clear acceptance criteria, edge cases, and definition of done."
---
# User Story Writer Skill
This skill produces production-ready user stories from a feature brief, PRD section, or verbal description. Each story follows the standard format with a clear who/what/why, behavioural acceptance criteria in Given/When/Then format, edge cases, and definition of done. Output is ready to paste into Jira, Linear, or your planning tool.
## Required Inputs
Ask the user for these if not provided:
- **Feature or change** to break into stories — paste the brief, PRD section, or describe the feature
- **User types / personas** involved (e.g. admin, end user, guest, API consumer)
- **Scope** — are we writing one story or decomposing an epic into a full set of stories?
- **Acceptance criteria format preference** — Given/When/Then, bullet checklist, or both?
- **Technical constraints or notes** — anything the engineering team has flagged that should shape the stories
## Output Structure
For each story:
---
## Story: [Short title — verb + noun, e.g. "Filter search results by date range"]
**Epic:** [Parent epic name — e.g. "Advanced Search"]
**Story ID:** [Jira/Linear ID — leave blank if not yet created]
**Priority:** [P1 / P2 / P3]
**Story points:** [Leave blank — for engineering to estimate]
---
### User Story
> **As a** [specific user type — not "user"],
> **I want to** [concrete action they want to take],
> **So that** [the outcome they achieve — business value, not feature description].
**Example:**
> As an **account manager**,
> I want to **filter my client list by last contact date**,
> so that I **can quickly identify clients I haven't spoken to in over 30 days and prioritise outreach**.
---
### Context
[1–3 sentences of context that aren't in the user story itself: when does this story matter, what triggers the need, how does it fit into a larger flow. This helps engineers understand why before they ask.]
---
### Acceptance Criteria
**Format: Given / When / Then**
Each criterion tests one specific behaviour. Write one GWT per observable outcome — not one GWT for the whole feature.
**AC1: [Short name for this criterion]**
```
Given [starting state or context]
When [user action]
Then [observable system behaviour]
```
**AC2: [Short name]**
```
Given [...]
When [...]
Then [...]
```
**AC3: [Short name]**
```
Given [...]
When [...]
Then [...]
```
---
### Edge Cases
[List scenarios that are non-obvious but must be handled. These become additional ACs or notes to engineering.]
- [ ] **[Edge case 1]:** [e.g. User applies a date filter that returns 0 results — show empty state with clear messaging and a "clear filters" action]
- [ ] **[Edge case 2]:** [e.g. User has >10,000 clients — filter must not degrade load time >200ms]
- [ ] **[Edge case 3]:** [e.g. Date filter persists across page refresh — or explicitly should not if that's the decision]
- [ ] **[Permission edge case]:** [e.g. Read-only users can see the filter but cannot save filter presets]
---
### Out of Scope
[Explicitly state what this story does NOT cover — prevents scope creep and clarifies where the next story begins.]
- Saving and sharing filter presets (separate story — see [Story X])
- Bulk actions on filtered results
- Exporting filtered client list to CSV
---
### Definition of Done
- [ ] Acceptance criteria all pass
- [ ] Edge cases handled (or explicitly deferred with a new ticket raised)
- [ ] Unit tests written for each AC
- [ ] Works on mobile viewport (if applicable)
- [ ] Accessibility: keyboard navigable and screen-reader compatible
- [ ] Error states are handled and copy approved
- [ ] Product and design have reviewed in staging
- [ ] No console errors in production build
---
## Epic Decomposition Template
If the user provides an epic or feature brief, decompose it into a full set of stories before writing them:
**Epic:** [Name]
**Goal:** [What outcome does completing this epic achieve?]
**Stories:**
| # | Story | Notes | Dependencies |
|---|---|---|---|
| 1 | [Core happy path story — the simplest version of the feature that delivers value] | | |
| 2 | [Validation / error handling story] | | Depends on #1 |
| 3 | [Edge case or power user story] | | Depends on #1 |
| 4 | [Admin or configuration story] | | |
| 5 | [Performance or scale story — if applicable] | | Depends on #1 |
**Suggested sprint order:** [Which stories are P1 for MVP? Which can follow in a later sprint?]
---
## Common Story Anti-Patterns — and Fixes
Use these to review stories before handing to engineering:
| Anti-pattern | Example | Fix |
|---|---|---|
| **Solution in the story** | "As a user I want a dropdown filter" | Remove the UI decision — "As a user I want to filter by date range" |
| **Vague "so that"** | "so that it's easier to use" | Make it specific — "so that I can prioritise outreach without opening each record manually" |
| **Too big** | Story covers 5 distinct user flows | Split into separate stories per flow |
| **No acceptance criteria** | Story has description only | Add at least 3 GWT criteria before engineering starts |
| **ACs that test the solution, not the behaviour** | "Given the dropdown is open, When I select an option" | Test the outcome — "Given I have applied a date filter, When I view my results, Then only clients last contacted in that date range appear" |
| **Missing empty state** | No AC for what happens with 0 results | Add it — empty states are part of the feature |
| **Missing error state** | No AC for network failure or invalid input | Add error handling ACs explicitly |
---
## Example: Full Story Set for a Feature
**Feature brief:** "Allow users to export their invoice history as a PDF or CSV"
---
### Story 1: Export invoice list as CSV
> As a **finance admin**,
> I want to **export my invoice history as a CSV file**,
> so that I can **import it into our accounting software without manual data entry**.
**AC1: Successful export**
```
Given I am on the Invoices page with at least one invoice
When I click "Export" and select "CSV"
Then a CSV file is downloaded containing all visible invoices with columns: Invoice ID, Date, Amount, Status, Customer Name
```
**AC2: Empty state**
```
Given I am on the Invoices page with no invoices
When I click "Export"
Then the export button is disabled and a tooltip reads "No invoices to export"
```
**AC3: Filtered export**
```
Given I have applied a date filter showing invoices from Jan 2026 only
When I click "Export" and select "CSV"
Then the export contains only invoices from Jan 2026 — not all invoices
```
**Edge cases:**
- [ ] Export with >10,000 invoices — must complete in <30s or show a progress indicator
- [ ] Export triggered on mobile — downloads to device's default download location
**Out of scope:** PDF export (Story 2), scheduled exports (future epic)
---
### Story 2: Export invoice list as PDF
> As a **finance admin**,
> I want to **export my invoice history as a formatted PDF**,
> so that I can **share a professional summary with our accountant**.
[... ACs follow same pattern ...]
---
## Quality Checks
- [ ] Every story has a specific user type — not "a user" or "the system"
- [ ] The "so that" explains business value — not just feature description
- [ ] Each AC tests one observable outcome — not a bundle of behaviours
- [ ] Empty states, error states, and edge cases are explicitly handled
- [ ] Out of scope is documented — not assumed
- [ ] Stories are independent — they can be shipped individually without depending on unreleased work (except where explicitly noted)
## Example Trigger Phrases
- "Write user stories for [feature] from this brief"
- "Break this PRD section into user stories with acceptance criteria"
- "Convert these feature requirements into Jira tickets"
- "Write the user stories and ACs for [feature name]"
- "Decompose this epic into individual stories ready for sprint planning"