Compare commits
27 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Mohit
|
5721cd3a49 | ||
|
Mohit
|
735df19a9b | ||
|
Mohit
|
f956b4c329 | ||
|
Mohit
|
2e58766814 | ||
 mohitagw15856
|
bd7d5afce1 | ||
|
Mohit
|
7f9331f5b4 | ||
|
mohitagw15856
|
5d4d007aeb | ||
|
Mohit
|
affae033fe | ||
|
Mohit
|
fb85a1cb55 | ||
|
Mohit
|
f170eed437 | ||
|
Mohit
|
a33b4f7003 | ||
|
Mohit
|
74f3ef79ad | ||
|
Mohit
|
4ff88bdbb1 | ||
|
mohitagw15856
|
44f69a541f | ||
|
Mohit Aggarwal
|
20eda05cc6 | ||
|
Mohit Aggarwal
|
6bb25a8c13 | ||
|
Mohit Aggarwal
|
5f12fcff50 | ||
|
Mohit Aggarwal
|
84abb1583d | ||
|
Mohit Aggarwal
|
2c92636980 | ||
|
mohitagw15856
|
dc579c7512 | ||
|
Mohit Aggarwal
|
d213ccde1c | ||
|
mohitagw15856
|
ae6ea4d53e | ||
|
mohitagw15856
|
94e53d38a8 | ||
|
mohitagw15856
|
01c10eb625 | ||
|
mohitagw15856
|
49137bd1b6 | ||
|
mohitagw15856
|
929fa3ad7f | ||
|
mohitagw15856
|
e366a77cf0 |
@@ -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": "14.0.0",
|
||||
"description": "PM stands for Professional, not just Product Management. 167 Claude Skills + 4 agent templates across 26 bundles covering 18 professions — engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, social media, writers, 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,48 +74,48 @@
|
||||
},
|
||||
{
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"name": "pm-engineering",
|
||||
"description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook, Security Threat Model, Performance Budget, Database Schema Design, Database Migration Plan, Technical Debt Register, RFC Writer, Capacity Planning, Load Testing Plan, Disaster Recovery Plan, Feature Flag Guide, Dependency Audit, Service Catalog Entry, Monitoring Setup Guide, Local Dev Setup, API Versioning Strategy, Infra-as-Code Review, Engineering Weekly Report, Tech Radar, Sprint Velocity Analysis, Microservices Decomposition, Engineering Hiring Rubric. 35 structured skills for engineering teams, SREs, and technical PMs.",
|
||||
"version": "4.0.0",
|
||||
"description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer, CI/CD Playbook, SLO & Error Budget, Developer Onboarding Doc, On-Call Runbook, Security Threat Model, Performance Budget, Database Schema Design, Database Migration Plan, Technical Debt Register, RFC Writer, Capacity Planning, Load Testing Plan, Disaster Recovery Plan, Feature Flag Guide, Dependency Audit, Service Catalog Entry, Monitoring Setup Guide, Local Dev Setup, API Versioning Strategy, Infra-as-Code Review, Engineering Weekly Report, Tech Radar, Sprint Velocity Analysis, Microservices Decomposition, Engineering Hiring Rubric, Context Mode, Claude Superpowers. 37 structured skills for engineering teams, SREs, technical PMs, and Claude Code power users.",
|
||||
"version": "4.1.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-engineering",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"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, Email Triage, Morning Intelligence. Document workflows, write SOPs, build risk registers, define RACI matrices, triage your inbox to only what needs action, and auto-generate a personalised morning news brief.",
|
||||
"version": "1.3.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-operations",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
@@ -178,8 +178,8 @@
|
||||
},
|
||||
{
|
||||
"name": "pm-cross",
|
||||
"description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary, Teaching Lesson Plan. Write journalist-ready press releases, structure grant applications, produce decision-ready executive summaries, and design complete lesson plans for any subject, audience, or setting.",
|
||||
"version": "1.1.0",
|
||||
"description": "Cross-profession skills: Press Release, Grant Proposal, Executive Summary, Teaching Lesson Plan, Sycophancy Challenger, Last 30 Days Research, NotebookLM Connector. Get genuine push-back on your ideas (not validation), gather multi-platform research from the last 30 days, and automate NotebookLM from Claude.",
|
||||
"version": "1.2.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-cross",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
@@ -191,6 +191,22 @@
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-figma",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-social",
|
||||
"description": "Social Media skills: Social Media Audit, Influencer Brief, Community Management Playbook, Social Ad Campaign, Viral Content Framework. Score your social presence, brief influencer partnerships, manage communities at scale, plan paid social campaigns with full ad copy, and build a repeatable system for shareable content.",
|
||||
"version": "1.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-social",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
},
|
||||
{
|
||||
"name": "pm-writers",
|
||||
"description": "Writers & Content Creators skills: Instagram Post Downloader, AEO Optimizer, Thumbnail Creator, Substack Notes Scraper, Notes Humanizer. Download Instagram carousels as PDFs, restructure articles for AI citation, generate thumbnail candidates via Gemini, export Substack Notes analytics to Excel, and strip AI writing patterns from any text.",
|
||||
"version": "1.0.0",
|
||||
"category": "productivity",
|
||||
"source": "./plugins/pm-writers",
|
||||
"homepage": "https://github.com/mohitagw15856/pm-claude-skills"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
name: Deploy Skill Playground
|
||||
|
||||
# Rebuilds web/skills.json from the SKILL.md files and publishes web/ to
|
||||
# GitHub Pages. Runs on every push to main that touches skills or the web app,
|
||||
# so the live site always reflects the current skill library.
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
paths:
|
||||
- 'skills/**'
|
||||
- 'web/**'
|
||||
- '.github/workflows/deploy-playground.yml'
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
pages: write
|
||||
id-token: write
|
||||
|
||||
# Allow one concurrent deployment; cancel in-progress runs for the same ref.
|
||||
concurrency:
|
||||
group: pages
|
||||
cancel-in-progress: true
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Set up Node
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: '20'
|
||||
|
||||
- name: Rebuild skills.json from SKILL.md files
|
||||
run: node web/build-skills.mjs
|
||||
|
||||
- name: Configure Pages
|
||||
uses: actions/configure-pages@v5
|
||||
|
||||
- name: Upload web/ as Pages artifact
|
||||
uses: actions/upload-pages-artifact@v3
|
||||
with:
|
||||
path: web
|
||||
|
||||
deploy:
|
||||
needs: build
|
||||
runs-on: ubuntu-latest
|
||||
environment:
|
||||
name: github-pages
|
||||
url: ${{ steps.deployment.outputs.page_url }}
|
||||
steps:
|
||||
- name: Deploy to GitHub Pages
|
||||
id: deployment
|
||||
uses: actions/deploy-pages@v4
|
||||
@@ -1,18 +1,30 @@
|
||||
# 🧠 PM Claude Skills — 135 Skills for Every Profession
|
||||
# 🧠 PM Claude Skills — 167 Skills for Every Profession
|
||||
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/releases)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills/releases)
|
||||
[](https://github.com/mohitagw15856/pm-claude-skills#-quick-install-2-minutes)
|
||||
[](LICENSE)
|
||||
[](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.
|
||||
> 167 Claude Skills + 4 agent templates across 26 bundles covering 18 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.
|
||||
A community-built library of Claude Skills for professionals across every field — product management, engineering, customer success, marketing, social media, writers, 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 (v14.0.0):** 12 new community-inspired skills across 4 bundles — a brand new Writers & Content Creators profession (Instagram downloader, AEO optimizer, thumbnail creator, Substack scraper, notes humanizer), plus decision-making, productivity, and Claude Code power tools.
|
||||
---
|
||||
|
||||
## Contents
|
||||
|
||||
- [🚀 Quick Install](#-quick-install-2-minutes)
|
||||
- [🌐 Skill Playground — try any skill in your browser](#-skill-playground--try-any-skill-in-your-browser)
|
||||
- [📦 Plugin Directory](#-plugin-directory)
|
||||
- [🤖 Building Blocks for Agent Templates](#-building-blocks-for-agent-templates)
|
||||
- [🗂️ All 167 Skills](#️-all-167-skills)
|
||||
- [📋 Changelog](#-changelog)
|
||||
- [🤝 Contributing](#-contributing--add-your-skill)
|
||||
|
||||
**🆕 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.
|
||||
---
|
||||
|
||||
## 🚀 Quick Install (2 minutes)
|
||||
@@ -49,6 +61,10 @@ claude plugin install pm-cross@pm-claude-skills # Cross-profession
|
||||
|
||||
claude plugin install pm-figma@pm-claude-skills # Figma
|
||||
|
||||
claude plugin install pm-social@pm-claude-skills # Social Media 🆕
|
||||
|
||||
claude plugin install pm-writers@pm-claude-skills # Writers & Content Creators 🆕
|
||||
|
||||
|
||||
Or clone and symlink for auto-updates:
|
||||
|
||||
@@ -58,6 +74,62 @@ ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Skill Playground — Try Any Skill in Your Browser
|
||||
|
||||
**▶ Live: [mohitagw15856.github.io/pm-claude-skills](https://mohitagw15856.github.io/pm-claude-skills/)**
|
||||
|
||||
Don't want to install anything yet? Run any of these skills from a **zero-backend web app** using **your own Claude API key**. Pick a skill, fill in the auto-generated form, and Claude streams the result. Your key is stored only in your browser (`localStorage`) and sent directly to the Anthropic API — nothing touches a server we own.
|
||||
|
||||
|
||||
|
||||
**Run it locally:**
|
||||
|
||||
```bash
|
||||
git clone https://github.com/mohitagw15856/pm-claude-skills.git
|
||||
cd pm-claude-skills
|
||||
node web/build-skills.mjs # generate the skill index (skills.json)
|
||||
cd web && python3 -m http.server 8000 # serve over HTTP (not file://)
|
||||
# open http://localhost:8000 and paste a key from console.anthropic.com
|
||||
```
|
||||
|
||||
It's fully static — deploy the `web/` folder to GitHub Pages, Netlify, or Vercel with no environment variables. Full details in [`web/README.md`](web/README.md).
|
||||
|
||||
---
|
||||
|
||||
## 📦 Plugin Directory
|
||||
|
||||
Not sure which plugin to install? Here's what each one covers:
|
||||
|
||||
| Plugin | Skills | Best for |
|
||||
|---|---|---|
|
||||
| **pm-essentials** | competitive-analysis, meeting-notes, prd-template, stakeholder-update, user-research-synthesis, docx-tracked-changes | The core PM toolkit — start here if you're new. Covers the documents you write every week: PRDs, stakeholder updates, meeting notes, and competitive analysis. |
|
||||
| **pm-advanced** | ai-ethics-review, ai-product-canvas, experiment-designer, design-handoff-brief, multi-source-signal-synthesiser | For PMs working on AI products or running sophisticated experiments. Covers ethical review of AI features, AI-native product canvases, and experiment design. |
|
||||
| **pm-analytics** | data-analysis-standard, product-health-analysis, retention-analysis | Turn raw data into PM-ready narratives. Use when you need to frame an analysis, explain health metrics to leadership, or diagnose retention drop-offs. |
|
||||
| **pm-business** | board-deck-narrative, investor-update, job-application | For PMs operating at the business layer — writing board narratives, investor updates, or crafting a standout job application. |
|
||||
| **pm-cross** | executive-summary, grant-proposal, last-30-days-research, notebooklm-connector, press-release, sycophancy-challenger, teaching-lesson-plan | Cross-profession utility skills that work outside a single domain — writing executive summaries, press releases, running research, and challenging sycophantic AI output. |
|
||||
| **pm-cs** | churn-analysis, cs-escalation-brief, cs-health-scorecard, customer-success-plan, qbr-deck, renewal-playbook | For PMs or CSMs responsible for retention. Covers churn diagnosis, escalation briefs, QBR decks, health scorecards, and renewal plays. |
|
||||
| **pm-data** | chart-data-extractor, cohort-analysis, dashboard-brief, data-pipeline-spec, metrics-framework, sql-query-explainer | Data-heavy work: extracting insights from charts, building metrics frameworks, explaining SQL queries, designing dashboards, and speccing data pipelines. |
|
||||
| **pm-delivery** | ab-test-planner, go-to-market-planner, pptx-slide-auditor, product-launch-checklist, retro-analysis, sprint-brief, sprint-planning, technical-spec-template, user-story-writer | Everything you need to ship: sprint planning, user stories, launch checklists, A/B test design, retros, and PowerPoint auditing. The most-used plugin for day-to-day delivery. |
|
||||
| **pm-design** | accessibility-audit, design-critique, design-system-audit, ux-research-plan | For PMs who work closely with design. Covers accessibility audits, structured design critiques, design system reviews, and UX research planning. |
|
||||
| **pm-discovery** | assumption-mapper, customer-journey-map, discovery-interview-guide, job-story-mapper, user-interview-synthesis | The discovery toolkit: map assumptions, build journey maps, write interview guides, synthesise user interviews, and reframe features as job stories. |
|
||||
| **pm-engineering** | 37 skills across API docs, architecture, CI/CD, incident response, security, observability, and more | The largest plugin — built for PMs embedded in engineering teams. Covers technical specs, runbooks, on-call processes, architecture decisions, and engineering hiring. |
|
||||
| **pm-figma** | figma-annotation-guide, figma-component-audit, figma-design-brief, figma-design-critique-pm, figma-design-qa, figma-design-review, figma-prototype-plan, figma-spacing-system, figma-user-flow-planner, figma-variant-matrix | Purpose-built for Figma workflows. Covers design QA, component audits, spacing systems, user flow planning, variant matrices, and design briefs — all from a PM perspective. |
|
||||
| **pm-finance** | budget-variance-analysis, financial-due-diligence, financial-model-narrative, investor-pitch-deck, tax-planning-checklist | For PMs who touch financials — explaining budget variances, building investor pitch decks, narrating financial models, and running due diligence reviews. |
|
||||
| **pm-gtm** | competitor-teardown, content-calendar, email-campaign, go-to-market, media-pitch, product-positioning-doc, seo-content-brief, social-media-strategy | The go-to-market toolkit: positioning docs, competitor teardowns, GTM plans, content calendars, email campaigns, and SEO briefs. Best for PMs who own launch and demand. |
|
||||
| **pm-hr** | change-management-plan, employee-engagement-survey, job-description-writer, onboarding-plan, redundancy-consultation | People operations skills — writing job descriptions, managing change, designing onboarding, running engagement surveys, and handling redundancy consultations. |
|
||||
| **pm-legal** | compliance-checklist, contract-review, legal-brief, nda-analyser | For PMs navigating legal and compliance work: reviewing NDAs, summarising contracts, creating compliance checklists, and preparing legal briefs. |
|
||||
| **pm-operations** | email-triage, morning-intelligence, process-documentation, project-status-report, raci-matrix, risk-register, sop-writer, vendor-evaluation, workshop-facilitation-guide | Operational efficiency skills — managing your inbox, running status reports, documenting processes, evaluating vendors, writing SOPs, and facilitating workshops. |
|
||||
| **pm-people** | 360-feedback-template, hiring-rubric, performance-review, team-health-check, team-offsite-planner | For people managers and team leads: writing performance reviews, running 360 feedback, designing hiring rubrics, checking team health, and planning offsites. |
|
||||
| **pm-planning** | feature-prioritisation, okr-builder, pricing-strategy, rice-impact-matrix, rice-prioritisation, roadmap-narrative, roadmap-presentation | Strategic planning from roadmaps to OKRs — prioritising features with RICE, writing roadmap narratives, setting pricing, building OKRs, and presenting strategy to stakeholders. |
|
||||
| **pm-research** | clinical-case-summary, literature-review, patient-communication, research-protocol | For PMs in healthcare and research settings. Covers clinical case summaries, literature reviews, research protocols, and patient-facing communication. |
|
||||
| **pm-rituals** | pm-weekly-review | A single powerful skill for the PM weekly review ritual — reflecting on progress, blockers, and priorities in a structured, consistent format. |
|
||||
| **pm-sales** | account-plan, discovery-call-prep, partnership-proposal, proposal-writer, sales-battlecard, sales-forecasting-model | For PMs who work alongside sales — writing battlecards, preparing for discovery calls, building account plans, crafting partnership proposals, and forecasting. |
|
||||
| **pm-social** | community-management-playbook, influencer-brief, social-ad-campaign, social-media-audit, viral-content-framework | Social media and community skills: running ad campaigns, briefing influencers, auditing social presence, building community playbooks, and designing viral content. |
|
||||
| **pm-strategy** | ambiguity-resolver, competitive-intelligence-monitor, competitor-signal-tracker, executive-update, stakeholder-influence-mapper, strategic-narrative-generator | Senior PM and strategic work — resolving ambiguity, tracking competitive signals, mapping stakeholder influence, writing executive updates, and building strategic narratives. |
|
||||
| **pm-writers** | aeo-optimizer, instagram-post-downloader, notes-humanizer, substack-notes-scraper, thumbnail-creator | For content creators and writers using Claude: optimising for AI search engines, humanising notes, scraping research from Substack, and generating thumbnail concepts. |
|
||||
|
||||
---
|
||||
|
||||
## 🎬 See It in Action
|
||||
|
||||
**Debugging Log Analyser** — paste a stack trace or error log, get a structured root cause diagnosis with probable cause, affected code path, a specific fix, and next debugging steps.
|
||||
@@ -74,7 +146,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 17 professions beyond financial services. **The 167 skills here are the building blocks for agent templates outside of finance.**
|
||||
|
||||
### What is an agent template?
|
||||
|
||||
@@ -151,7 +223,99 @@ More templates will follow. If you want to contribute one, see the [template con
|
||||
|
||||
---
|
||||
|
||||
## 🆕 What's New in v10.0.0
|
||||
## 📋 Changelog
|
||||
|
||||
<details>
|
||||
<summary><strong>Release history — v6.0.0 → v14.0.0</strong> (click to expand)</summary>
|
||||
|
||||
### 🆕 What's New in v14.0.0 — Writers & Content Creators + 7 Community Skills
|
||||
|
||||
**12 new community-inspired skills across 4 bundles:**
|
||||
|
||||
### New profession: ✍️ Writers & Content Creators (`pm-writers`)
|
||||
|
||||
| Skill | What It Does |
|
||||
|---|---|
|
||||
| **Instagram Post Downloader** 🆕 | Downloads Instagram images and carousels as high-res files; stitches carousel slides into a single PDF |
|
||||
| **AEO Optimizer** 🆕 | Restructures articles for AI citation — rewrites H2s as questions, adds 50–80 word answer capsules, audits paragraph length and trust signals |
|
||||
| **Thumbnail Creator** 🆕 | Generates brand-aligned thumbnail candidates via Gemini API from article copy; Claude evaluates results via computer vision |
|
||||
| **Substack Notes Scraper** 🆕 | Scrapes Substack Notes engagement data (likes, comments, restacks) and exports a formatted .xlsx with filters and conditional formatting |
|
||||
| **Notes Humanizer** 🆕 | Strips AI writing patterns (em dashes, filler phrases, uniform rhythm) and injects genuine human signals — opinion, varied rhythm, specific detail |
|
||||
|
||||
### Extended: `pm-cross` (+3 skills)
|
||||
|
||||
| Skill | What It Does |
|
||||
|---|---|
|
||||
| **Sycophancy Challenger** 🆕 | Flips Claude's default — argues the strongest case *against* your idea first, holds its position under pushback, and only backs down with new evidence |
|
||||
| **Last 30 Days Research** 🆕 | Searches Reddit, X, and the web for the last 30 days on any topic and returns a structured report: consensus, disagreements, pain points, and signal confidence |
|
||||
| **NotebookLM Connector** 🆕 | Automates NotebookLM from Claude Code via Chrome extension — create notebooks, add sources, generate mindmaps and audio overviews |
|
||||
|
||||
### Extended: `pm-operations` (+2 skills)
|
||||
|
||||
| Skill | What It Does |
|
||||
|---|---|
|
||||
| **Email Triage** 🆕 | Reads Gmail for a configurable window, filters out receipts/notifications, and surfaces only what needs a reply or decision — with priority, urgency, and a reply starter |
|
||||
| **Morning Intelligence** 🆕 | 15-question interview that writes a personalised master prompt for your morning news brief, ready to drop into a Cowork Scheduled Task or Claude Code Routine |
|
||||
|
||||
### Extended: `pm-engineering` (+2 skills — for Claude Code users)
|
||||
|
||||
| Skill | What It Does |
|
||||
|---|---|
|
||||
| **Context Mode** 🆕 | Solves Claude Code context bloat and memory loss — filters raw command output and maintains a session log so Claude resumes exactly where it left off after a reset |
|
||||
| **Claude Superpowers** 🆕 | Forces Claude Code to plan before coding, work in isolation, write tests first, and review its own work twice — from 60% first pass to 80%+ |
|
||||
|
||||
The library now includes **167 skills** across **18 professions** + 4 working agent templates.
|
||||
|
||||
---
|
||||
|
||||
### 🆕 What's New in v13.0.0 — Social Media Profession
|
||||
|
||||
**5 new skills — a complete Social Media profession bundle:**
|
||||
|
||||
| Skill | Bundle | What It Does |
|
||||
|---|---|---|
|
||||
| **Social Media Audit** 🆕 | pm-social | Scored audit across all platforms — profile completeness, content performance, competitive benchmarking, and a prioritised action plan |
|
||||
| **Influencer Brief** 🆕 | pm-social | Complete creator partnership brief with deliverables, creative guidelines, approval workflow, commercial terms, and campaign measurement |
|
||||
| **Community Management Playbook** 🆕 | pm-social | Response frameworks, moderation rules, escalation tiers, DM templates, tone-of-voice guidance, and community health metrics |
|
||||
| **Social Ad Campaign** 🆕 | pm-social | Full-funnel paid social campaign plan with audience targeting, ad set architecture, copy for every format (video, static, carousel, lead gen), budget allocation, and A/B testing plan |
|
||||
| **Viral Content Framework** 🆕 | pm-social | Psychology of sharing, 6 proven hook formulas, 5 content structures, platform-specific playbooks for LinkedIn/TikTok/Instagram/X/YouTube, and a repeatable content testing system |
|
||||
|
||||
The library now includes **167 skills** across **18 professions** + 4 working agent templates.
|
||||
|
||||
Install the new bundle:
|
||||
|
||||
claude plugin install pm-social@pm-claude-skills
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🆕 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:**
|
||||
|
||||
@@ -191,7 +355,7 @@ The `pm-engineering` bundle now has **10 skills** — the most complete engineer
|
||||
|
||||
---
|
||||
|
||||
## 📖 v6.0.0 — 100 Skills Milestone
|
||||
### 📖 v6.0.0 — 100 Skills Milestone
|
||||
|
||||
**7 skills added:**
|
||||
|
||||
@@ -205,6 +369,8 @@ The `pm-engineering` bundle now has **10 skills** — the most complete engineer
|
||||
| **Sales Forecasting Model** | pm-sales | Pipeline-based forecast with stage model, scenario analysis, assumption log, and activity sanity check |
|
||||
| **Tax Planning Checklist** | pm-finance | Year-end tax planning review framework across income, pension, CGT, business reliefs, and ISAs |
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## 📚 The Article Series
|
||||
@@ -232,88 +398,97 @@ This repo was built alongside a published article series. Read the full story:
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ All 135 Skills
|
||||
## 🗂️ All 167 Skills
|
||||
|
||||
### 🛠️ Product Management (Skills 1–34)
|
||||
The [Plugin Directory](#-plugin-directory) above summarises every bundle. Expand below for the full per-skill breakdown with folder paths.
|
||||
|
||||
<details>
|
||||
<summary><strong>Browse all 167 skills by profession</strong> (click to expand)</summary>
|
||||
|
||||
### 🛠️ 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, 166–167)
|
||||
**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 |
|
||||
| 166 | **Context Mode** 🆕 | `skills/context-mode/` | Filters command output noise and maintains a session log so Claude resumes exactly where it left off after a context reset |
|
||||
| 167 | **Claude Superpowers** 🆕 | `skills/claude-superpowers/` | Forces Claude Code to plan first, work in isolation, write tests before code, and double-review its own output — consistently better first passes |
|
||||
|
||||
---
|
||||
|
||||
### 🤝 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 +499,234 @@ 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, 164–165)
|
||||
**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 |
|
||||
| 164 | **Email Triage** 🆕 | `skills/email-triage/` | Reads Gmail for a configurable window and surfaces only what needs action — priority-ranked with urgency ratings and reply starters |
|
||||
| 165 | **Morning Intelligence** 🆕 | `skills/morning-intelligence/` | 15-question interview that writes a personalised master prompt for your daily news brief, ready for Cowork Scheduled Tasks or Claude Code Routines |
|
||||
|
||||
---
|
||||
|
||||
### 🏥 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, 161–163)
|
||||
**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 |
|
||||
| 161 | **Sycophancy Challenger** 🆕 | `skills/sycophancy-challenger/` | Argues the strongest case *against* your idea first — a genuine thinking partner that holds its position under pressure |
|
||||
| 162 | **Last 30 Days Research** 🆕 | `skills/last-30-days-research/` | Searches Reddit, X, and the web for the last 30 days on any topic and returns consensus, disagreements, pain points, and signal confidence |
|
||||
| 163 | **NotebookLM Connector** 🆕 | `skills/notebooklm-connector/` | Automates NotebookLM via Chrome extension — create notebooks, add sources, generate mindmaps and audio overviews from Claude Code |
|
||||
|
||||
---
|
||||
|
||||
### 🖼️ 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 |
|
||||
|
||||
---
|
||||
|
||||
### 📱 Social Media (Skills 151–155)
|
||||
**Bundle:** `pm-social`
|
||||
|
||||
> Install:
|
||||
|
||||
```
|
||||
claude plugin install pm-social@pm-claude-skills
|
||||
```
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 151 | **Social Media Audit** 🆕 | `skills/social-media-audit/` | Scored audit across all platforms — profile completeness, content performance, competitive benchmarking, and a prioritised action plan with 30-day quick wins |
|
||||
| 152 | **Influencer Brief** 🆕 | `skills/influencer-brief/` | Complete creator partnership brief with deliverables spec, creative guidelines, key messages, approval workflow, commercial terms, and campaign measurement |
|
||||
| 153 | **Community Management Playbook** 🆕 | `skills/community-management-playbook/` | Response frameworks, moderation rules, escalation tiers, DM templates, tone-of-voice guidance, platform-specific notes, and community health metrics |
|
||||
| 154 | **Social Ad Campaign** 🆕 | `skills/social-ad-campaign/` | Full-funnel paid social plan with audience targeting, ad set architecture, copy for every format (video, static, carousel, lead gen), budget allocation, bidding strategy, and A/B testing plan |
|
||||
| 155 | **Viral Content Framework** 🆕 | `skills/viral-content-framework/` | Psychology of sharing, 6 proven hook formulas, 5 content structures, platform-specific playbooks for LinkedIn/TikTok/Instagram/X/YouTube, and a repeatable content testing system |
|
||||
|
||||
---
|
||||
|
||||
### ✍️ Writers & Content Creators (Skills 156–160)
|
||||
**Bundle:** `pm-writers`
|
||||
|
||||
> Install:
|
||||
|
||||
```
|
||||
claude plugin install pm-writers@pm-claude-skills
|
||||
```
|
||||
|
||||
| # | Skill | Folder | What It Does |
|
||||
|---|---|---|---|
|
||||
| 156 | **Instagram Post Downloader** 🆕 | `skills/instagram-post-downloader/` | Downloads Instagram images and full carousels as high-res files; stitches carousel slides into a single PDF. Requires `*.cdninstagram.com` on domain allowlist |
|
||||
| 157 | **AEO Optimizer** 🆕 | `skills/aeo-optimizer/` | Restructures any article for AI citation — rewrites H2s as questions, adds 50–80 word answer capsules under each, audits paragraph length, and flags trust signals |
|
||||
| 158 | **Thumbnail Creator** 🆕 | `skills/thumbnail-creator/` | Generates brand-aligned thumbnail candidates via Gemini API; Claude evaluates results via computer vision and returns ranked candidates with rationale |
|
||||
| 159 | **Substack Notes Scraper** 🆕 | `skills/substack-notes-scraper/` | Scrapes Substack Notes and exports likes, comments, and restacks to a formatted .xlsx with frozen headers, filters, and top-performer highlighting |
|
||||
| 160 | **Notes Humanizer** 🆕 | `skills/notes-humanizer/` | Strips AI writing patterns (em dashes, filler phrases, uniform rhythm) across 3 phases: audit, strip, inject — returns side-by-side comparison and clean final text |
|
||||
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
## ❤️ 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 167 skills across 26 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:
|
||||
|
||||
@@ -587,7 +817,7 @@ claude plugin install pm-gtm@pm-claude-skills
|
||||
|
||||
claude plugin install pm-engineering@pm-claude-skills # Engineering (35 skills)
|
||||
|
||||
claude plugin install pm-cs@pm-claude-skills # Customer Success (4 skills) 🆕
|
||||
claude plugin install pm-cs@pm-claude-skills # Customer Success
|
||||
|
||||
claude plugin install pm-data@pm-claude-skills
|
||||
|
||||
@@ -613,6 +843,10 @@ claude plugin install pm-cross@pm-claude-skills
|
||||
|
||||
claude plugin install pm-figma@pm-claude-skills
|
||||
|
||||
claude plugin install pm-social@pm-claude-skills # Social Media 🆕
|
||||
|
||||
claude plugin install pm-writers@pm-claude-skills # Writers & Content Creators 🆕
|
||||
|
||||
---
|
||||
|
||||
## 🤖 Companion Repository — ChatGPT Custom GPTs
|
||||
@@ -627,7 +861,7 @@ Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGP
|
||||
|
||||
## 🛠️ Custom Skills for Your Team
|
||||
|
||||
The 114 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
|
||||
The 155 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
|
||||
|
||||
**What custom skills look like in practice:**
|
||||
|
||||
|
||||
@@ -0,0 +1,215 @@
|
||||
---
|
||||
name: ai-ethics-review
|
||||
description: "Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and 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"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not limit the affected-population analysis to users of the product — AI that makes decisions about people (hiring, credit, content moderation) affects non-users who have no opt-out
|
||||
- [ ] Do not accept "we will monitor" as a mitigation without specifying what is monitored, at what threshold, and who acts
|
||||
- [ ] Do not assign fairness analysis to the model team alone — protected characteristic analysis requires input from legal, HR, or a subject-matter expert
|
||||
- [ ] Do not defer the DPIA to post-launch — for high-risk tier systems, a DPIA is a pre-requisite for lawful deployment under GDPR
|
||||
- [ ] Do not conflate statistical accuracy with fairness — a model can be 95% accurate overall while performing significantly worse for a protected group
|
||||
|
||||
## 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]?"
|
||||
@@ -152,6 +152,14 @@ Ask the user for these if not provided:
|
||||
- **Available data** (what training/inference data exists)
|
||||
- **ML/AI lead** (who owns the technical implementation)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not skip the "Why AI?" question — if the answer is "we want to use AI," stop and reframe around the user problem first
|
||||
- [ ] Do not launch with an undefined accuracy threshold — "good enough" is not a threshold; set a number before build begins
|
||||
- [ ] Do not design the UX to hide AI-generated output as if it were system truth — users need to know when AI is involved so they can override it
|
||||
- [ ] Do not defer the Responsible AI checklist to post-launch — bias and privacy issues are far harder to fix in production than in design
|
||||
- [ ] Do not treat model latency as a post-launch optimisation — a 6-second AI response that replaces a 1-second rule-based response is a regression, not a feature
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] "Why AI?" is answered clearly (not "because we can")
|
||||
|
||||
@@ -73,3 +73,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Success criteria are measurable or observable (not "looks good")
|
||||
- [ ] Out-of-scope section names at least one thing that might seem in scope but isn't
|
||||
- [ ] Technical constraints are specific enough for an engineer to confirm
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write the user goal in feature language ("design the checkout flow") — it must be written from the user's perspective with a motivation and outcome
|
||||
- [ ] Do not skip the "Explicitly Out of Scope" section — without it, designers will inadvertently solve problems not intended for this iteration
|
||||
- [ ] Do not list edge cases that are so generic they apply to any feature (e.g. "handle errors") — each edge case must be specific to this feature's failure modes
|
||||
- [ ] Do not hand off the brief without confirming engineering constraints are accurate — a constraint that is wrong is worse than no constraint
|
||||
- [ ] Do not omit the emotional context of the user — designs without emotional grounding produce technically correct but experientially flat results
|
||||
|
||||
@@ -67,3 +67,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Test was not stopped early (or flagged clearly if it was)
|
||||
- [ ] Practical significance assessed separately from statistical significance
|
||||
- [ ] Sample ratio mismatch is checked in results interpretation
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not define success criteria after seeing preliminary results — post-hoc success definitions are HARKing (Hypothesising After Results are Known) and invalidate the experiment
|
||||
- [ ] Do not stop a test early because the result looks significant — early stopping dramatically inflates false positive rates; the test must run to the planned sample size
|
||||
- [ ] Do not treat statistical significance as the same as practical significance — a p < 0.05 result with a 0.1% lift is real but may not be worth shipping
|
||||
- [ ] Do not run the same experiment on the same population multiple times without correction — multiple testing inflates the chance of a false positive proportionally
|
||||
- [ ] Do not use more than one primary metric — multiple primary metrics require multiple hypothesis corrections and make the ship/kill decision ambiguous
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: multi-source-signal-synthesiser
|
||||
description: "Synthesise user signals from multiple research sources into a unified insight brief, reconciling conflicting feedback. Use when asked to make sense of data from multiple sources, synthesise user research, reconcile conflicting feedback, or when the user says 'what are users really telling us' or 'make sense of all this user data'. Produces ranked insights with confidence ratings, divergent signal analysis, and research gap identification."
|
||||
description: "Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section."
|
||||
---
|
||||
|
||||
# Multi-Source Signal Synthesiser Skill
|
||||
@@ -60,3 +60,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Divergent signals identify the specific user segments, not just "some users disagree"
|
||||
- [ ] Confidence ratings are consistent with source diversity and weighting
|
||||
- [ ] "What the data does NOT tell us" section is honest about gaps
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not echo surface-level feature requests as insights — translate every request to the underlying need before including it as a finding
|
||||
- [ ] Do not assign High confidence to insights supported by only one source type — confidence requires corroboration across at least two distinct source types
|
||||
- [ ] Do not treat all sources as equally weighted — a single interview quote and a pattern across 200 support tickets are not comparable signals
|
||||
- [ ] Do not collapse divergent signals into a single finding — where user segments have genuinely different needs, name the segments explicitly rather than averaging them away
|
||||
- [ ] Do not omit the research gap section when key decisions rest on thin data — acting on low-confidence findings without flagging the gaps misleads product teams
|
||||
|
||||
@@ -117,6 +117,14 @@ Ask the user for these if not provided:
|
||||
- [ ] What the data cannot tell us is explicitly named
|
||||
- [ ] Recommended action includes an owner and timeline
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not present correlations as causation — always state the distinction explicitly
|
||||
- [ ] Do not report a metric movement without stating the time window and comparison baseline
|
||||
- [ ] Do not skip the "so what" — raw observations without recommended actions are incomplete analysis
|
||||
- [ ] Do not overstate confidence — label hypotheses clearly and note what data would be needed to confirm them
|
||||
- [ ] Do not ignore segment breakdowns — aggregate metrics can mask opposing trends in sub-segments
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always state what the data *cannot* tell you — never oversell confidence
|
||||
|
||||
@@ -57,3 +57,11 @@ Analyse across four layers:
|
||||
- [ ] Every flagged metric has a root cause hypothesis, not just "it dropped"
|
||||
- [ ] Observations are written for a non-technical stakeholder (no raw query language or data jargon)
|
||||
- [ ] Overall health rating is justified with specific evidence
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not report a single aggregate metric without segment breakdowns — averages hide opposing trends
|
||||
- [ ] Do not flag a metric as healthy just because it is above the target — check if the target itself is meaningful
|
||||
- [ ] Do not list metric movements without root cause hypotheses — observations without explanations are not analysis
|
||||
- [ ] Do not mix product health metrics with business KPIs without explaining the relationship between them
|
||||
- [ ] Do not omit recommended actions — a health report that only describes problems without prioritised next steps is incomplete
|
||||
|
||||
@@ -126,6 +126,14 @@ Ask the user for these if not provided:
|
||||
- [ ] Churned user interviews are recommended (not just data analysis)
|
||||
- [ ] Monitoring plan includes an alert threshold
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not recommend "improve onboarding" without specifying what specific step to change and why
|
||||
- [ ] Do not analyse retention without segmenting by cohort — aggregate retention curves hide cohort-specific patterns
|
||||
- [ ] Do not treat DAU/MAU below 5% as a retention problem — at that level, it is a product-market fit problem
|
||||
- [ ] Do not skip qualitative research — churned user interviews reveal reasons that quantitative data cannot
|
||||
- [ ] Do not set a monitoring alert without specifying the threshold that triggers it
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never recommend "improve onboarding" without specifying *what* to change and *why*
|
||||
|
||||
@@ -149,6 +149,14 @@ Ask the user for these if not provided:
|
||||
- [ ] Board asks are specific and actionable
|
||||
- [ ] Deck is ≤ 15 slides (excluding appendix)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not bury bad news after slides full of good news — boards lose trust when they discover problems were de-emphasised; lead with the honest narrative
|
||||
- [ ] Do not include slides without a "so what" — a chart that shows data without a takeaway wastes board time and signals the presenter hasn't done the analysis
|
||||
- [ ] Do not exceed 15 slides in the main deck — a longer deck usually means the presenter hasn't decided what matters most
|
||||
- [ ] Do not attend a board meeting without at least one specific ask — a board meeting with no asks is a missed opportunity to leverage the room
|
||||
- [ ] Do not report metrics without comparing them to plan or a prior period — a metric shown in isolation gives the board no basis for judgement
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a board deck structure for our Q[N] board meeting"
|
||||
|
||||
@@ -119,6 +119,14 @@ Hi [Investor names or "all"],
|
||||
- [ ] Total length is skimmable in 3–4 minutes
|
||||
- [ ] No spin or buzzwords
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not omit challenges or bad news — sanitised updates erode investor trust faster than bad results do
|
||||
- [ ] Do not bury the lead — use BLUF structure and put the most important news in the first paragraph
|
||||
- [ ] Do not send an update without a clear "Ask" section — investors who want to help need to know how
|
||||
- [ ] Do not use buzzwords or spin — investors see hundreds of updates and will see through vague positive language
|
||||
- [ ] Do not report metrics without a comparison baseline — numbers without context (vs. last period or target) are meaningless
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write an investor update for [month/quarter]"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: job-application
|
||||
description: "Tailor a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter."
|
||||
description: "Tailors a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter aligned to the role's requirements."
|
||||
---
|
||||
|
||||
# Job Application Skill
|
||||
@@ -120,6 +120,14 @@ Before submitting:
|
||||
- [ ] Cover letter is 250–350 words
|
||||
- [ ] Gaps are either addressed or strategically omitted
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not fabricate or embellish experience — only use real achievements from the provided CV
|
||||
- [ ] Do not use the same cover letter template for every role — every letter must reference specific details of the job description
|
||||
- [ ] Do not address selection criteria that aren't in the JD — match keywords the employer actually used
|
||||
- [ ] Do not omit ATS optimisation — ensure role-specific keywords from the JD appear naturally in the CV summary
|
||||
- [ ] Do not write a cover letter that re-summarises the CV — it must add context and motivation, not repeat bullet points
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Help me apply for this job: [paste JD]"
|
||||
|
||||
@@ -84,12 +84,21 @@ An executive summary is NOT a summary of the document. It is a standalone docume
|
||||
**Client:** Lead with their problem. Show you understand before presenting recommendation.
|
||||
|
||||
## Quality Checks
|
||||
- Bottom line in first 3 sentences
|
||||
- Standalone — no need to read full document
|
||||
- Recommendation is specific
|
||||
- Fits length limit
|
||||
- Written for audience priorities not author priorities
|
||||
- Next steps have owners and dates
|
||||
|
||||
- [ ] Bottom line in first 3 sentences
|
||||
- [ ] Standalone — no need to read full document
|
||||
- [ ] Recommendation is specific
|
||||
- [ ] Fits length limit
|
||||
- [ ] Written for audience priorities not author priorities
|
||||
- [ ] Next steps have owners and dates
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not summarise the document chronologically — an executive summary that follows the structure of the source document is not an executive summary, it is an abstract
|
||||
- [ ] Do not bury the recommendation at the end — executives read the first paragraph and skim the rest; the ask must be in sentence one or two
|
||||
- [ ] Do not use the same summary for different audiences — a CEO and a board member have different decision contexts and require different framing
|
||||
- [ ] Do not include background that the reader already knows — every sentence of background must earn its place by making the bottom line more actionable
|
||||
- [ ] Do not leave the "risks of inaction" section vague — a summary that does not quantify what happens if the reader does nothing removes the urgency needed for a decision
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write an executive summary of this report: [paste]"
|
||||
|
||||
@@ -96,6 +96,14 @@ Funder test: does this problem align with [funder] stated priorities? Make the c
|
||||
- [ ] Sustainability section explains what happens after the grant ends
|
||||
- [ ] Word limits respected
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a generic proposal — every section must be tailored to the specific funder's stated priorities
|
||||
- [ ] Do not exceed the specified word or page limits — over-length proposals are disqualified at many funders
|
||||
- [ ] Do not leave the sustainability section vague — funders need to know what happens after grant funding ends
|
||||
- [ ] Do not use jargon the funder's reviewers won't understand — write for the panel, not the project team
|
||||
- [ ] Do not underspecify the budget narrative — every significant line item must be justified with method and reasoning
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a grant proposal for [project] applying to [funder]"
|
||||
- "Help me write a funding application for [grant programme]"
|
||||
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
name: last-30-days-research
|
||||
description: "Searches Reddit, X/Twitter, and the broader web for recent opinions, sentiment, and signal on any topic. Use when you need to know what real people are saying about a tool, product, trend, or event in the past 30 days — cutting through SEO content to surface genuine community reaction. Produces a structured report with consensus findings, pain points, positive signals, contrarian takes, source links, and a signal confidence rating."
|
||||
---
|
||||
|
||||
# Last 30 Days Research
|
||||
|
||||
## The Problem
|
||||
|
||||
Googling gives SEO-stuffed "best of" lists written six months ago by someone who has never used the thing. Real honest takes live on Reddit threads, X replies, and niche communities — but chasing them across platforms eats your afternoon. This skill does the chase for you.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
| Input | Required | Notes |
|
||||
|-------|----------|-------|
|
||||
| Topic | Yes | Tool, trend, feature, product, event, company — anything with a name |
|
||||
| Date scope | No | Defaults to last 30 days. Can override to last 7 days or last 90 days |
|
||||
| Angle | No | e.g. "focus on developer sentiment" or "looking for pricing complaints specifically" |
|
||||
|
||||
## Output Structure
|
||||
|
||||
The output is a structured research report with the following sections, delivered in this exact order:
|
||||
|
||||
```
|
||||
## Last 30 Days Research: [Topic]
|
||||
Research window: [Date 30 days ago] → [Today's date]
|
||||
|
||||
---
|
||||
|
||||
## What People Agree On
|
||||
[Consensus points that appear across multiple platforms — most reliable signal]
|
||||
|
||||
## Where People Disagree
|
||||
[Active debates, contrasting views — include which side has more weight]
|
||||
|
||||
## Pain Points That Keep Coming Up
|
||||
[Recurring complaints and frustrations — strongest signal of real problems]
|
||||
|
||||
## Positive Signals
|
||||
[What people genuinely praise — not PR, but unprompted appreciation]
|
||||
|
||||
## Most Interesting Takes
|
||||
[Contrarian, unexpected, or surprisingly insightful comments worth noting]
|
||||
|
||||
## Sources
|
||||
[Links to the most useful threads/posts found — 5–10 links with brief labels]
|
||||
|
||||
## Signal Confidence
|
||||
[High / Medium / Low — with a one-line rationale based on data volume and consistency]
|
||||
```
|
||||
|
||||
Each section should contain substantive content, not placeholders. If a section has no findings (e.g. no positive signals found), state that explicitly rather than leaving it empty or fabricating content.
|
||||
|
||||
## Instructions for Claude
|
||||
|
||||
### Step 1 — Calculate the date window
|
||||
|
||||
Determine today's date and subtract 30 days to get the research start date. Format: YYYY-MM-DD. Use these dates explicitly in every search query.
|
||||
|
||||
### Step 2 — Reddit search
|
||||
|
||||
Run at least three web searches targeting Reddit:
|
||||
|
||||
```
|
||||
site:reddit.com "[topic]" after:[30-days-ago-date]
|
||||
site:reddit.com "[topic]" 2025
|
||||
reddit.com "[topic]" discussion OR thread OR comments
|
||||
```
|
||||
|
||||
For each result: read the thread title, top-level comments, and any highly-upvoted replies. Record the key claims and the URL.
|
||||
|
||||
If the topic has common synonyms or abbreviations, run additional searches with those (e.g. "Claude Code" and "claude.code" and "Anthropic coding tool").
|
||||
|
||||
### Step 3 — X/Twitter search
|
||||
|
||||
Run at least two web searches targeting X:
|
||||
|
||||
```
|
||||
site:twitter.com OR site:x.com "[topic]" after:[30-days-ago-date]
|
||||
"[topic]" site:x.com -is:retweet
|
||||
```
|
||||
|
||||
Note: X search via web has limitations. If results are sparse, supplement with searches for specific accounts known to discuss the topic area (e.g. tech journalists, domain experts).
|
||||
|
||||
### Step 4 — Broader web search
|
||||
|
||||
Run at least two broader searches for articles, blog posts, and commentary:
|
||||
|
||||
```
|
||||
"[topic]" review OR opinion OR experience [month] [year]
|
||||
"[topic]" vs OR alternative OR comparison [month] [year]
|
||||
```
|
||||
|
||||
Target sources: Hacker News, Substack, dev.to, personal blogs, product communities. Avoid press releases and vendor-authored content.
|
||||
|
||||
### Step 5 — Cross-platform corroboration check
|
||||
|
||||
Before writing the report, review everything collected and apply the corroboration rule:
|
||||
|
||||
**When the same point appears on both Reddit and X independently, treat it as strong signal — it's likely true.**
|
||||
|
||||
A point mentioned only once on one platform is a data point, not a finding. Weight your sections accordingly.
|
||||
|
||||
### Step 6 — Write the report
|
||||
|
||||
Populate each section of the output structure. Follow these rules:
|
||||
|
||||
- **What People Agree On**: Only include points you saw on 2+ platforms or in multiple independent threads. These are your most reliable findings.
|
||||
- **Where People Disagree**: Name the sides. "Some say X, others say Y — and the X camp seems louder based on upvote counts / engagement."
|
||||
- **Pain Points**: Be specific. "Performance issues" is weak. "Cold start times over 4 seconds on the free tier" is useful.
|
||||
- **Positive Signals**: Must be unprompted praise, not from product marketing or sponsored content.
|
||||
- **Most Interesting Takes**: At least 2, maximum 5. Quote or closely paraphrase where possible.
|
||||
- **Sources**: Include the actual URLs. Label each one briefly (e.g. "Reddit thread: 'Has anyone switched from X to Y?'").
|
||||
- **Signal Confidence**: Rate High/Medium/Low based on:
|
||||
- High = 10+ sources, consistent signal across platforms
|
||||
- Medium = 5–10 sources, some inconsistency
|
||||
- Low = fewer than 5 sources, or highly fragmented signal
|
||||
|
||||
### Step 7 — Sanity check before delivering
|
||||
|
||||
Before outputting the report, verify:
|
||||
|
||||
- [ ] Every claim in the report traces to an actual source found during research (not prior knowledge)
|
||||
- [ ] The date window was actually applied to searches, not ignored
|
||||
- [ ] No fabricated or hallucinated URLs in the Sources section
|
||||
- [ ] Signal Confidence rating reflects the actual data volume, not optimism
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] At minimum 3 Reddit searches were run with the date filter applied
|
||||
- [ ] At minimum 2 X/Twitter searches were run
|
||||
- [ ] At minimum 2 broader web searches were run
|
||||
- [ ] Cross-platform corroboration principle was applied (same point on multiple platforms = stronger signal)
|
||||
- [ ] Pain Points section contains specific, concrete details — not vague generalisations
|
||||
- [ ] Sources section contains real URLs (not hallucinated), verified during research
|
||||
- [ ] Signal Confidence is rated and justified
|
||||
- [ ] If a section has no findings, it says so explicitly rather than being omitted or padded
|
||||
- [ ] No vendor-authored content or press releases treated as independent signal
|
||||
- [ ] Synonyms and alternative names for the topic were searched
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not treat SEO blog posts or vendor-authored content as community signal — only count independent sources
|
||||
- [ ] Do not report findings without applying the date filter — prior knowledge mixed with recent search results produces stale, unverifiable claims
|
||||
- [ ] Do not fabricate or guess at URLs — every link in the Sources section must have been retrieved during the research session
|
||||
- [ ] Do not report a single mention as a "finding" — a finding requires corroboration from at least two independent sources
|
||||
- [ ] Do not rate Signal Confidence as High when fewer than 5 credible sources were found — this misleads the reader about how much to rely on the output
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "What are people saying about Cursor AI from the last 30 days?"
|
||||
- "Research Vercel's recent sentiment"
|
||||
- "Last 30 days on the Arc browser shutdown"
|
||||
- "What's the current vibe on Supabase?"
|
||||
- "What are developers saying about Claude Code lately?"
|
||||
- "Research [topic] from the last 30 days"
|
||||
- "Give me a signal report on [product]"
|
||||
- "What's the Reddit and Twitter take on [trend]?"
|
||||
@@ -0,0 +1,183 @@
|
||||
---
|
||||
name: notebooklm-connector
|
||||
description: "Automates NotebookLM from Claude Code using browser automation via the Claude Chrome extension — creating notebooks, adding sources, and triggering outputs without manual clicking. Use when you want to create a NotebookLM notebook, add URLs or documents as sources, or generate mindmaps, audio overviews, or briefing docs programmatically. Produces a confirmed checklist of completed actions and a direct link to the notebook."
|
||||
---
|
||||
|
||||
# NotebookLM Connector
|
||||
|
||||
## The Problem
|
||||
|
||||
NotebookLM is one of the best AI research tools — but it doesn't connect to your other tools. Every notebook requires manual setup inside the NotebookLM UI: open browser, name the notebook, paste URLs one by one, click generate. For researchers, builders, or anyone who works with a high volume of sources, this friction compounds fast.
|
||||
|
||||
This skill automates NotebookLM from Claude Code using browser automation via the Claude Chrome extension.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
| Requirement | Details |
|
||||
|-------------|---------|
|
||||
| Claude Chrome extension | Must be installed and active in your Chrome browser |
|
||||
| NotebookLM account | Active account at notebooklm.google.com |
|
||||
| Chrome browser | Open and signed into NotebookLM |
|
||||
|
||||
If the Chrome extension is not installed, this skill cannot function. There is no fallback — you will need to perform actions manually.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
| Input | Required | Notes |
|
||||
|-------|----------|-------|
|
||||
| Action(s) to perform | Yes | What you want done — see Supported Actions below |
|
||||
| Notebook name | Conditional | Required for create; optional for add/generate if a notebook is already open |
|
||||
| Sources | Conditional | Required for add sources action — URLs, file paths, or pasted text |
|
||||
| Output type | Conditional | Required for generate action — mindmap, audio overview, or briefing doc |
|
||||
|
||||
## Supported Actions
|
||||
|
||||
| Action | What It Does |
|
||||
|--------|-------------|
|
||||
| Create notebook | Opens NotebookLM, creates a new notebook with the specified title |
|
||||
| Add sources | Adds one or more URLs, files, or text blocks as sources to a notebook |
|
||||
| Generate mindmap | Triggers mindmap generation from the notebook's sources |
|
||||
| Generate audio overview | Requests an audio overview (note: takes several minutes to render) |
|
||||
| Generate briefing doc | Requests a briefing document or slide deck from sources |
|
||||
| List notebooks | Lists your existing notebooks and their source counts |
|
||||
| Open notebook | Navigates to a specific existing notebook by name |
|
||||
|
||||
Actions can be chained in a single request: "Create a notebook called 'AI Trends Q2', add these 3 URLs as sources, then generate a mindmap."
|
||||
|
||||
## Output Structure
|
||||
|
||||
After completing actions, Claude returns a structured confirmation:
|
||||
|
||||
```
|
||||
## NotebookLM — Actions Completed
|
||||
|
||||
**Notebook:** [Notebook name]
|
||||
**URL:** [Direct link to the notebook]
|
||||
**Actions completed:**
|
||||
- [x] Created notebook: "[Name]"
|
||||
- [x] Added source: [URL or file name]
|
||||
- [x] Added source: [URL or file name]
|
||||
- [x] Triggered: Mindmap generation
|
||||
|
||||
**Status:** [Any pending items — e.g. "Audio overview is generating, check back in 5–10 minutes"]
|
||||
|
||||
**Notes:** [Any issues encountered or deviations from the requested actions]
|
||||
```
|
||||
|
||||
If an action fails, the failed step is marked with `[ ]` and a reason is provided. See Error Handling below.
|
||||
|
||||
## Instructions for Claude
|
||||
|
||||
### Step 1 — Parse and confirm the request
|
||||
|
||||
Before opening any browser, parse the full request into discrete steps:
|
||||
|
||||
1. What notebook is being targeted (new or existing)?
|
||||
2. What sources need to be added (list each URL or file)?
|
||||
3. What outputs need to be generated?
|
||||
|
||||
If anything is ambiguous — e.g. "add my research sources" without specifying what they are — ask for clarification before proceeding. Do not guess at source URLs.
|
||||
|
||||
### Step 2 — Check the Chrome extension is available
|
||||
|
||||
Confirm browser automation is available via the Claude Chrome extension. If it is not active, stop and report:
|
||||
|
||||
> "This skill requires the Claude Chrome extension to be installed and active. Please install it at [extension URL] and try again."
|
||||
|
||||
### Step 3 — Navigate to NotebookLM
|
||||
|
||||
Open or navigate to `https://notebooklm.google.com`. Confirm the user is logged in. If a login screen appears, stop and ask the user to log in manually, then retry.
|
||||
|
||||
### Step 4 — Execute actions in order
|
||||
|
||||
Execute each action in the sequence requested. After each action, confirm it completed before moving to the next. Do not batch actions speculatively.
|
||||
|
||||
**Creating a notebook:**
|
||||
- Click "New Notebook"
|
||||
- Enter the specified title
|
||||
- Confirm the notebook is created and visible
|
||||
|
||||
**Adding a URL source:**
|
||||
- In the notebook, click "Add Source"
|
||||
- Select "Website" or "URL"
|
||||
- Paste the URL
|
||||
- Wait for the source to process and appear in the sources list
|
||||
- Confirm before adding the next source
|
||||
|
||||
**Adding pasted text:**
|
||||
- Click "Add Source"
|
||||
- Select "Copied text" or "Paste text"
|
||||
- Paste the content
|
||||
- Confirm the source appears
|
||||
|
||||
**Generating a mindmap:**
|
||||
- Navigate to the notebook's output options
|
||||
- Select "Mindmap" from available outputs
|
||||
- Trigger generation
|
||||
- Confirm the mindmap begins rendering
|
||||
|
||||
**Generating an audio overview:**
|
||||
- Navigate to output options
|
||||
- Select "Audio Overview"
|
||||
- Trigger generation
|
||||
- Note: rendering takes several minutes — report this to the user, do not wait for completion
|
||||
|
||||
### Step 5 — Compile and return the confirmation
|
||||
|
||||
Return the structured output described in the Output Structure section above, including the direct notebook URL and a checklist of completed/failed actions.
|
||||
|
||||
## Error Handling
|
||||
|
||||
If any step fails, do the following:
|
||||
|
||||
1. Stop at the failed step (do not attempt to continue)
|
||||
2. Report the exact step that failed and what was observed
|
||||
3. Suggest a manual workaround for that step
|
||||
4. Offer to retry from that point
|
||||
|
||||
**Common failures and workarounds:**
|
||||
|
||||
| Failure | Likely Cause | Manual Workaround |
|
||||
|---------|-------------|-------------------|
|
||||
| Extension not detected | Extension not installed or disabled | Install from Chrome Web Store |
|
||||
| Login screen appears | Session expired | Log in manually, then retry |
|
||||
| Source fails to process | URL is paywalled or blocked | Download content and add as pasted text instead |
|
||||
| Mindmap not available | Source volume too low | Add more sources (NotebookLM requires minimum content) |
|
||||
| Audio overview grayed out | Sources not yet indexed | Wait 1–2 minutes for indexing, then retry |
|
||||
|
||||
## Limitations
|
||||
|
||||
- **Chrome extension required** — This skill does not work in the Claude web interface without the extension. It cannot function in API-only or terminal-only Claude setups.
|
||||
- **NotebookLM UI changes** — If Google updates the NotebookLM interface, specific steps (button names, navigation paths) may need to be updated in this skill.
|
||||
- **Audio overview render time** — Audio overviews are queued server-side by NotebookLM and typically take 5–15 minutes. Claude can trigger the request but cannot wait for completion.
|
||||
- **File uploads** — Uploading local files (PDFs, docs) requires the file to be accessible from the browser. File paths must be absolute.
|
||||
- **Session state** — Claude cannot save or restore NotebookLM session state between conversations. Each session starts fresh.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] User's full request was parsed into discrete steps before any browser action was taken
|
||||
- [ ] Ambiguous source references were clarified before proceeding
|
||||
- [ ] Each action was confirmed complete before the next one started
|
||||
- [ ] Direct notebook URL is included in the output
|
||||
- [ ] If audio overview was triggered, user was informed of the render delay
|
||||
- [ ] Any failed steps are explicitly reported with the specific failure reason
|
||||
- [ ] Manual workaround was offered for any step that failed
|
||||
- [ ] Output checklist accurately reflects what was completed vs. what failed
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not proceed with any browser action before the full request has been parsed into discrete steps — ambiguous source references must be clarified before navigating
|
||||
- [ ] Do not guess at source URLs if the user says "add my research sources" without specifying them — ask for the explicit list before starting
|
||||
- [ ] Do not batch actions speculatively — each action must be confirmed complete before the next one begins to avoid compounding failures
|
||||
- [ ] Do not wait for audio overview rendering to complete — audio overviews take 5–15 minutes server-side; report the trigger and move on rather than blocking the session
|
||||
- [ ] Do not attempt this skill if the Claude Chrome extension is not active — report the missing prerequisite immediately rather than attempting browser steps that will fail
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Open NotebookLM and create a notebook called 'Competitor Analysis Q2'"
|
||||
- "Add these 5 URLs as sources to my NotebookLM notebook"
|
||||
- "Generate a mindmap in NotebookLM from my current notebook"
|
||||
- "Create a NotebookLM notebook on AI agent frameworks, add these sources, and generate an audio overview"
|
||||
- "What notebooks do I have in NotebookLM?"
|
||||
- "Add this article to NotebookLM: [URL]"
|
||||
- "Generate a briefing doc from my NotebookLM sources on [topic]"
|
||||
@@ -72,6 +72,14 @@ Would a journalist care? Is the headline the full story? Is there a human angle?
|
||||
- [ ] Boilerplate is factual, not promotional
|
||||
- [ ] Embargo date and media contact are included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not bury the news — the most important information must appear in the first paragraph (inverted pyramid)
|
||||
- [ ] Do not use promotional language or superlatives — press releases must read as news, not advertising copy
|
||||
- [ ] Do not omit the boilerplate — every press release needs the standard "About [Company]" paragraph at the end
|
||||
- [ ] Do not forget the embargo date and media contact — journalists need both to use the release
|
||||
- [ ] Do not write a headline longer than 12 words — it must be scannable and specific
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a press release announcing [news]"
|
||||
- "Draft a media statement about [event]"
|
||||
|
||||
@@ -0,0 +1,164 @@
|
||||
---
|
||||
name: sycophancy-challenger
|
||||
description: "Flips Claude's default from validation to adversarial critique. Use before high-stakes decisions, plans, assumptions, or pitches you haven't stress-tested. Produces structured challenges, steelmanned counter-arguments, and the strongest case against your position — a genuine thinking partner, not a mirror."
|
||||
---
|
||||
|
||||
# Sycophancy Challenger
|
||||
|
||||
Claude defaults to validating. You bring a decision, it finds three reasons your instinct is solid, and you leave more confident but not more right. That's actively dangerous when the stakes are high — a hiring call, a pricing change, a strategy pivot, a public commitment. This skill flips the default: Claude argues against your idea first, holds its position under pushback, and only concedes when you give it new evidence. Not when you express displeasure.
|
||||
|
||||
> Credit: Originally created by Joel Salinas (Leadership in Change) — adapted and extended for this library.
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
| Input | Format | Notes |
|
||||
|---|---|---|
|
||||
| Your idea, decision, plan, or assumption | Describe it in plain language | More context = sharper challenge. Include reasoning if you have it. |
|
||||
|
||||
No other setup required. Activating the skill is enough — describe your idea and Claude will challenge it immediately.
|
||||
|
||||
---
|
||||
|
||||
## Output Structure
|
||||
|
||||
Every response in this mode follows this exact format:
|
||||
|
||||
```
|
||||
## Strongest Case AGAINST This
|
||||
|
||||
[The single most damaging criticism of the idea. Not a list of concerns — the
|
||||
one argument that, if true, would kill this. Stated directly, without softening.]
|
||||
|
||||
|
||||
## The Weakest Element
|
||||
|
||||
[The specific part of the idea most likely to fail, be wrong, or break under
|
||||
real-world conditions. Named precisely. Not "execution risk" — the actual thing.]
|
||||
|
||||
|
||||
## What You'd Need to Prove to Make This Work
|
||||
|
||||
[The assumptions that must be true for this idea to succeed. Written as testable
|
||||
claims, not as encouragement. If an assumption can't be tested, that's noted.]
|
||||
|
||||
|
||||
## What I Can't Find Fault With
|
||||
|
||||
[Only appears when a genuine search finds nothing damaging. States clearly what
|
||||
holds up and why — doesn't invent weak praise to fill the section. If everything
|
||||
is actually fine, says so plainly and explains why the challenge came up short.]
|
||||
```
|
||||
|
||||
No additional sections. No summary. No "overall, this is a solid idea." The format ends when the four sections are complete.
|
||||
|
||||
---
|
||||
|
||||
## Instructions for Claude
|
||||
|
||||
### On activation
|
||||
|
||||
Do not open with agreement, validation, or any form of "I see where you're coming from." Begin the challenge immediately. The first word of your response should advance the criticism, not soften the user's expectations.
|
||||
|
||||
### Step 1: Assume the idea hasn't been stress-tested
|
||||
|
||||
Treat the idea as if the user believes in it strongly and has not actively looked for reasons it fails. Your job is to be the adversary they didn't have in the room.
|
||||
|
||||
### Step 2: Find the strongest case against it
|
||||
|
||||
Not a balanced view. Not pros and cons. The strongest case against. Ask:
|
||||
- What's the most likely way this fails?
|
||||
- What's the assumption that, if wrong, makes everything else irrelevant?
|
||||
- Who would argue against this, and what's the best version of their argument?
|
||||
- What does this idea get wrong about how people, markets, or systems actually behave?
|
||||
|
||||
State the strongest case directly. Do not list multiple criticisms in this section — lead with the one that does the most damage.
|
||||
|
||||
### Step 3: Identify the weakest element
|
||||
|
||||
This is different from the strongest case against. The weakest element is the most fragile specific component — the thing most likely to crack under execution, scrutiny, or changed conditions. Name it precisely. Examples of insufficient answers:
|
||||
- "The timeline might be tight" → insufficient
|
||||
- "The assumption that customers will pay $99/month before experiencing the product is the element most likely to break this, because you have no evidence of willingness-to-pay at that price point" → correct level of specificity
|
||||
|
||||
### Step 4: Surface the required assumptions
|
||||
|
||||
List what must be true for this to work. Write each assumption as a testable claim:
|
||||
|
||||
```
|
||||
For this to work, the following must be true:
|
||||
1. [Assumption stated as a claim that can be verified or falsified]
|
||||
2. [Assumption stated as a claim]
|
||||
3. [Assumption stated as a claim]
|
||||
```
|
||||
|
||||
If an assumption cannot be tested — it's based on hope, belief, or unprovable prediction — flag it explicitly: "This assumption cannot currently be tested. That's a risk."
|
||||
|
||||
### Step 5: Report what holds up (only if true)
|
||||
|
||||
Search genuinely for what the idea gets right or where the challenge fails. If you find it, state it clearly. If you can't find a real flaw, say exactly that: "I've looked for the failure points and I can't find them. Here's what actually holds up: [specific things]." Do not invent praise. Do not invent flaws either.
|
||||
|
||||
### Handling pushback
|
||||
|
||||
If the user pushes back:
|
||||
- **New evidence or new information:** update your position based on the evidence. State what changed and why.
|
||||
- **Emotional pushback, repetition, or displeasure:** do not move. Restate the criticism calmly. Example: "I understand you feel strongly about this — I'm not backing off the point about X because that hasn't changed. If there's something I'm missing, tell me what it is."
|
||||
- **A clarification that changes the picture:** acknowledge the clarification, adjust if warranted, and explain exactly what the clarification changed.
|
||||
|
||||
Do not soften a position because the user seems upset. Do not move back to validation mode mid-conversation.
|
||||
|
||||
### When the skill ends
|
||||
|
||||
The session is complete when the user has either:
|
||||
1. Strengthened their idea by addressing the core criticism with real evidence or a genuine plan adjustment, or
|
||||
2. Identified a real flaw they're going to fix.
|
||||
|
||||
Not when they've expressed satisfaction. Not when a certain number of exchanges have happened. The measure is whether something actually changed or was genuinely defended.
|
||||
|
||||
### Prohibitions
|
||||
|
||||
These prohibitions do more work than the rules above. Follow them absolutely:
|
||||
|
||||
- **Never open with agreement or validation.** Not "That's an interesting approach," not "I can see why you'd think that." Start with the challenge.
|
||||
- **Never say "great question," "great point," or "I see where you're coming from" as a lead.** These are validation openers, not neutral transitions.
|
||||
- **Never soften a criticism with "however, there are also positives."** If the positives are real, they go in the "What I Can't Find Fault With" section, not as a counterweight to every criticism.
|
||||
- **Never back down because the user expressed displeasure.** Only move if given new evidence.
|
||||
- **Never invent a flaw that isn't real.** If the idea is actually solid, say so. Inventing fake criticisms is as useless as fake validation.
|
||||
- **Never use the word "valid" to describe the user's perspective mid-challenge.** It's a validation signal disguised as a neutral word.
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Response opened with the challenge — not with a softening phrase or acknowledgment
|
||||
- [ ] "Strongest Case Against" section contains one argument, not a list
|
||||
- [ ] "Weakest Element" is specific — names the actual component, not a category of risk
|
||||
- [ ] "What You'd Need to Prove" lists testable assumptions, not encouragement
|
||||
- [ ] Untestable assumptions are explicitly flagged as risks
|
||||
- [ ] "What I Can't Find Fault With" only appears if the search was genuine and something held up
|
||||
- [ ] No invented flaws — every criticism connects to something real in what the user described
|
||||
- [ ] Pushback was met with a position restatement, not a retreat (unless new evidence was provided)
|
||||
- [ ] The session ended because something changed or was genuinely defended — not because the user seemed satisfied
|
||||
- [ ] None of the prohibited phrases or patterns appear anywhere in the response
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not open with a softening phrase or acknowledgment before the challenge — the first sentence must be the critique
|
||||
- [ ] Do not retreat from a position when the user pushes back without providing new evidence — update only when genuinely persuaded
|
||||
- [ ] Do not invent flaws — every criticism must connect to something real in what the user described
|
||||
- [ ] Do not provide a list of weak objections — identify the single strongest case against the idea
|
||||
- [ ] Do not end the session because the user seems satisfied — end only when something genuinely changed or was defended
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Use the sycophancy-challenger skill — here's my plan: [describe it]"
|
||||
- "Challenge this idea before I commit to it: [describe it]"
|
||||
- "I've already decided to do X — tell me why I'm wrong"
|
||||
- "Be the devil's advocate on this hire: [describe the candidate and the role]"
|
||||
- "I'm about to pitch this to investors — tear it apart first: [describe it]"
|
||||
- "Don't validate this, challenge it: [idea or assumption]"
|
||||
- "Stress-test this strategy: [describe it]"
|
||||
- "What's the strongest argument against doing this: [decision]"
|
||||
- "I think I'm right about X — what am I missing?"
|
||||
@@ -110,6 +110,14 @@ By the end of this session, participants will be able to:
|
||||
- [ ] Differentiation is specified for both support and extension
|
||||
- [ ] Timing adds up to session length
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not design a lesson plan without explicitly stating the learning objectives — activities must trace back to outcomes
|
||||
- [ ] Do not allocate timing that does not add up to the total session length — the plan must be time-feasible
|
||||
- [ ] Do not create activities with no assessment component — learning must be measurable, not just delivered
|
||||
- [ ] Do not ignore differentiation — a plan with no accommodation for different learning levels or abilities is incomplete
|
||||
- [ ] Do not front-load all content delivery without interactive breaks — passive listening degrades retention after 15–20 minutes
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a lesson plan on [topic] for [audience]"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: churn-analysis
|
||||
description: "Analyse customer churn for a product or cohort and produce a structured churn report. Use when asked to analyse churn, understand why customers are leaving, identify churn patterns, calculate churn rate, or build a churn reduction plan. Produces a churn analysis with rate calculations, categorised reasons, early warning signals, and prioritised interventions."
|
||||
description: "Produce a structured churn analysis that separates avoidable from unavoidable churn. Use when investigating why customers are leaving, identifying at-risk segments, calculating net revenue retention, or building a retention intervention plan. Produces a churn report with rate calculations, categorised reasons by avoidability, segment breakdown, timing analysis, early warning signals, and prioritised interventions ranked by estimated impact."
|
||||
---
|
||||
|
||||
# Churn Analysis Skill
|
||||
@@ -169,6 +169,14 @@ Ranked by estimated impact × feasibility.
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not mix avoidable and unavoidable churn in intervention plans — recommending product fixes for customers who churned due to company shutdown wastes resources
|
||||
- [ ] Do not calculate churn rate using end-of-period customer count as the denominator — this understates churn; always divide churned customers by the starting cohort
|
||||
- [ ] Do not rely solely on exit survey data for churn reasons — response rates are typically low and self-selection biases the sample toward customers who are engaged enough to complete a survey
|
||||
- [ ] Do not recommend interventions without linking them to a specific churn reason — interventions disconnected from root causes will not move retention
|
||||
- [ ] Do not report only gross revenue churn — without net revenue retention (NRR), a healthy-looking retention number can hide a shrinking revenue base
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Churn rate is correctly calculated (churned ÷ starting cohort, not end-of-period total)
|
||||
|
||||
@@ -174,3 +174,11 @@ Include:
|
||||
- [ ] ARR at risk is quantified
|
||||
- [ ] Communication plan has owners and dates — not "TBD"
|
||||
- [ ] Language is professional and blameless toward individuals
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign blame to individuals — focus on system failures and process gaps
|
||||
- [ ] Do not downplay ARR at risk or describe churn risk vaguely without a number
|
||||
- [ ] Do not leave resolution plan ownership as "TBD" or unassigned
|
||||
- [ ] Do not write the brief without a clear ask from the escalation owner
|
||||
- [ ] Do not omit the customer's own stated position — their perspective must be represented fairly
|
||||
|
||||
@@ -139,3 +139,11 @@ Score each dimension 1–5. Weight as shown. Calculate weighted total out of 100
|
||||
- [ ] Actions have owners and deadlines
|
||||
- [ ] Renewal probability is calibrated against pipeline reality
|
||||
- [ ] Trend arrows reflect direction of change vs. last scorecard, not just current state
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not score health dimensions on gut feel — every score needs specific supporting evidence
|
||||
- [ ] Do not give a Green status to accounts with unresolved P1 issues or missed milestones
|
||||
- [ ] Do not list risks vaguely — "low engagement" without specifics is not actionable
|
||||
- [ ] Do not leave recommended actions without named owners and deadlines
|
||||
- [ ] Do not conflate product usage frequency with product value delivery
|
||||
|
||||
@@ -0,0 +1,200 @@
|
||||
---
|
||||
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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not define success metrics that the vendor controls — metrics must reflect the customer's business outcomes
|
||||
- [ ] Do not set milestone dates without customer confirmation — unilateral timelines undermine joint ownership
|
||||
- [ ] Do not create a plan the customer hasn't agreed to — it must be mutual, not a CSM's internal plan
|
||||
- [ ] Do not leave ownership fields blank or assigned to "CS team" — every action needs a named owner
|
||||
- [ ] Do not confuse product adoption milestones with customer business outcomes — both are needed but are not the same
|
||||
|
||||
## 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"
|
||||
@@ -216,3 +216,11 @@ Prompt questions:
|
||||
- [ ] Roadmap preview links each item to a customer goal
|
||||
- [ ] Mutual commitments section has real owners on both sides
|
||||
- [ ] Customer has at least 20 minutes of airtime in the agenda
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not fill the QBR with product activity metrics — lead with business outcomes the customer cares about
|
||||
- [ ] Do not present a roadmap without linking each item to a customer goal — vendor priorities are not a QBR agenda
|
||||
- [ ] Do not run a QBR as a one-sided presentation — it must include structured time for the customer to speak
|
||||
- [ ] Do not close a QBR without documented mutual commitments with named owners on both sides
|
||||
- [ ] Do not skip the "what's not working" slide — suppressing problems erodes trust and misses renewal risks
|
||||
|
||||
@@ -0,0 +1,198 @@
|
||||
---
|
||||
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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not start renewal conversations less than 90 days before the renewal date for accounts over $50K ARR
|
||||
- [ ] Do not build a renewal strategy without first honestly assessing account health — wishful thinking leads to last-minute churn
|
||||
- [ ] Do not treat all renewal objections as negotiating tactics — some objections signal genuine dissatisfaction that requires resolution first
|
||||
- [ ] Do not offer discounts as the first response to price objections — explore value gaps before reducing price
|
||||
- [ ] Do not close the renewal without confirming the expansion opportunity — every renewal is also an expansion conversation
|
||||
|
||||
## 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]"
|
||||
@@ -84,6 +84,13 @@ Ask the user which of these they want:
|
||||
- [ ] Assumptions about axis scale and interpolation are stated
|
||||
- [ ] CSV output is clean and directly usable
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not silently include low-confidence data points in the main table — flag them separately so the user knows which values to verify
|
||||
- [ ] Do not assume a linear scale without confirming it — logarithmic axes make extracted values incorrect by orders of magnitude if misread
|
||||
- [ ] Do not report extracted values with false precision — if the chart's Y-axis only shows gridlines every 10 units, a reported value of 37 is invented, not extracted
|
||||
- [ ] Do not omit the assumptions and caveats section — partial image quality, overlapping bars, or unlabelled axes must be disclosed
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Extract the data from this chart"
|
||||
- "Transcribe the numbers in this graph"
|
||||
|
||||
@@ -0,0 +1,195 @@
|
||||
---
|
||||
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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not allow the same user to appear in multiple cohorts — overlapping cohorts produce retention numbers that cannot be compared or acted upon
|
||||
- [ ] Do not assume assumed ARPU in LTV projections — use observed revenue per retained user per period, not a blended average that hides segment differences
|
||||
- [ ] Do not draw conclusions from cohorts too small to be statistically meaningful — flag minimum cohort size thresholds and note when a cohort is too small to trust
|
||||
- [ ] Do not conflate retention rate with engagement rate — a user who logs in but does not complete the key retention event is not retained by the definition used
|
||||
- [ ] Do not make recommendations without connecting them to specific cohort or segment findings — generic growth advice that could apply to any product adds no value
|
||||
|
||||
## 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"
|
||||
@@ -114,6 +114,14 @@ Flag any fields that may not exist in current data infrastructure.
|
||||
- [ ] Data requirements section flags any missing fields
|
||||
- [ ] Filters are practical and don't require IT to configure
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not specify metrics that the available data sources cannot actually support — always validate data availability
|
||||
- [ ] Do not include more than 8–10 primary metrics on a single dashboard — more creates noise, not insight
|
||||
- [ ] Do not skip the primary business question — a dashboard without a north-star question becomes a vanity metrics display
|
||||
- [ ] Do not choose chart types for aesthetic reasons — every chart type must match the data relationship it represents
|
||||
- [ ] Do not leave filter configurations vague — specify exact filter values, not just filter categories
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Design a dashboard to track [business process]"
|
||||
|
||||
@@ -0,0 +1,229 @@
|
||||
---
|
||||
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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not spec a pipeline without defining SLAs — "as fast as possible" is not an acceptable freshness target
|
||||
- [ ] Do not omit error handling and dead-letter queue strategy — every pipeline must specify what happens to failed records
|
||||
- [ ] Do not design idempotent loads without documenting the deduplication key — assume reruns will happen
|
||||
- [ ] Do not leave data quality rules implicit — schema validation, null checks, and referential integrity must be explicit
|
||||
- [ ] Do not ignore schema evolution — specify how upstream schema changes are detected and handled
|
||||
|
||||
## 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"
|
||||
@@ -94,6 +94,14 @@ Suggest a 3-tier dashboard structure:
|
||||
- [ ] Dashboard tiers are tailored to the product stage
|
||||
- [ ] All metric definitions are unambiguous (formula or clear description)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not set a North Star metric that measures business activity (revenue, pageviews) rather than customer value delivered — this creates incentives misaligned with product quality
|
||||
- [ ] Do not define metrics without specifying the formula or data source — an ambiguous metric will be measured differently by different people
|
||||
- [ ] Do not skip counter-metrics — optimising any single metric without a guard rail will eventually produce perverse incentives
|
||||
- [ ] Do not include more than 4–5 metrics in a daily team view — a dashboard with 20 metrics is a dashboard nobody looks at
|
||||
- [ ] Do not classify all metrics as "leading" — be honest about which are lagging outcome metrics and which genuinely predict future outcomes
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a metrics framework for [product]"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: sql-query-explainer
|
||||
description: "Explain, optimise, or translate SQL queries into plain language. Use when asked to explain a SQL query, optimise slow SQL, write a data dictionary, translate SQL to plain English for non-technical stakeholders, or review a query for correctness and performance. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
|
||||
description: "Explains, optimises, writes, and documents SQL queries. Use when asked to explain a SQL query, optimise slow SQL, translate SQL to plain English for non-technical stakeholders, write a query from a natural language description, or produce query documentation. Produces plain-English explanations, annotated optimised queries, or a data dictionary covering output shape, assumptions, and known limitations. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
|
||||
---
|
||||
|
||||
# SQL Query Explainer Skill
|
||||
|
||||
@@ -103,6 +103,14 @@ Flag if traffic is too low to reach significance in under 8 weeks — recommend
|
||||
- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
|
||||
- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not run a test without a directional hypothesis — "let's see what happens" produces uninterpretable results
|
||||
- [ ] Do not declare a winner before reaching the pre-planned sample size — peeking at results inflates false positive rates
|
||||
- [ ] Do not test multiple independent changes in a single variant — you won't know which change caused the result
|
||||
- [ ] Do not use engagement metrics (clicks, time-on-page) as the primary metric when the goal is revenue or retention — proxy metrics mislead
|
||||
- [ ] Do not ignore guardrail metrics — a conversion lift that causes a support ticket spike is not a win
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
|
||||
|
||||
@@ -131,3 +131,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Success metrics include a measurement window (30/60/90 days)
|
||||
- [ ] Rollback procedure is confirmed for Tier 1 and 2 launches
|
||||
- [ ] Post-launch retrospective is scheduled
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not build a Tier 1 GTM plan for an incremental feature update — tier the launch appropriately before planning
|
||||
- [ ] Do not create activity lists without named owners and due dates — unowned tasks do not get done
|
||||
- [ ] Do not skip the rollback procedure for Tier 1 and 2 launches — every significant launch must have an abort plan
|
||||
- [ ] Do not treat marketing and engineering as separate tracks — cross-functional coordination is the whole point of a GTM plan
|
||||
- [ ] Do not set success metrics without a defined measurement window — "increase signups" is not a measurable target
|
||||
|
||||
@@ -82,6 +82,14 @@ Order by: fixes before handoff (critical) > consistency fixes (high) > polish (m
|
||||
- [ ] Audience-appropriate concerns flagged explicitly
|
||||
- [ ] Slides without issues are listed briefly, not ignored
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not flag stylistic preferences as issues — only report genuine layout problems, overflow, and consistency errors
|
||||
- [ ] Do not produce a flat list of issues — group by severity (Critical / Major / Minor) so fixes can be prioritised
|
||||
- [ ] Do not skip slides without commenting — every slide must have an explicit pass or issue status
|
||||
- [ ] Do not suggest redesigning content — the audit scope is layout, consistency, and readability, not messaging
|
||||
- [ ] Do not report the same issue type repeatedly across slides without summarising the pattern — consolidate repeated issues
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit this slide deck before my board meeting"
|
||||
- "Review this PowerPoint for layout issues"
|
||||
|
||||
@@ -7,6 +7,15 @@ description: "Generate a comprehensive pre-launch, launch day, and post-launch c
|
||||
|
||||
Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Launch name** and planned launch date
|
||||
- **Launch tier** (1 = major product launch, 2 = significant feature release, 3 = incremental update)
|
||||
- **Team members and their roles** (engineering lead, PM, marketing, support, etc.)
|
||||
- **Feature description** (what is being launched)
|
||||
- **Rollback capability** (can this be feature-flagged or reverted quickly?)
|
||||
|
||||
## How to Use This Skill
|
||||
|
||||
Provide:
|
||||
@@ -117,6 +126,14 @@ The skill generates a tiered checklist. Tier 3 launches use only the Essentials
|
||||
- [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once
|
||||
- [ ] Post-launch retrospective is scheduled at launch time
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist
|
||||
- [ ] Do not launch on a Friday without confirmed weekend engineering coverage
|
||||
- [ ] Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual
|
||||
- [ ] Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live
|
||||
- [ ] Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The Go/No-Go decision must have a named owner — "the team" is not an owner
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
description: "Analyse sprint delivery data and produce a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint."
|
||||
description: "Analyses sprint delivery data and produces a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint."
|
||||
---
|
||||
|
||||
# Retrospective Analysis Skill
|
||||
@@ -51,3 +51,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Carry-over analysis identifies the ticket type or cause, not just the count
|
||||
- [ ] Data observations don't assign blame — they describe patterns
|
||||
- [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign blame to individuals in the retrospective brief — observations must describe patterns, not people
|
||||
- [ ] Do not produce Start/Stop/Continue prompts that are vague categories — each must name a specific behaviour
|
||||
- [ ] Do not recommend an experiment that cannot be completed within one sprint — small, testable experiments only
|
||||
- [ ] Do not treat carry-over tickets as a velocity problem without first identifying the root cause category
|
||||
- [ ] Do not run the same retrospective format every sprint — vary the format to prevent engagement fatigue
|
||||
|
||||
@@ -51,3 +51,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Every risk has a mitigation or owner (not just "this is a risk")
|
||||
- [ ] Carry-over items are connected to their impact on this sprint's goal
|
||||
- [ ] Definition of Done is agreed criteria, not a task list
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a sprint goal as a task list — the goal must be a single outcome-focused statement that can be scored pass/fail
|
||||
- [ ] Do not leave the critical path unnamed — "the important tickets" is not a critical path
|
||||
- [ ] Do not list risks without a mitigation or owner — a risk without a response is just a worry list
|
||||
- [ ] Do not ignore carry-over items' impact on this sprint's capacity and goal
|
||||
- [ ] Do not write a Definition of Done that mixes task completion with outcome criteria — they must be observable and agreed before the sprint starts
|
||||
|
||||
@@ -15,7 +15,7 @@ Transform raw backlog items into a structured, achievable sprint with clear goal
|
||||
- **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings
|
||||
- **Risk Flags** — blockers or dependencies that could derail the sprint
|
||||
|
||||
## Inputs to Request From User
|
||||
## Required Inputs
|
||||
|
||||
Ask for (if not already provided):
|
||||
- Sprint duration (1 or 2 weeks)
|
||||
@@ -95,3 +95,11 @@ Story points to commit = Historical velocity × Availability factor
|
||||
- [ ] Every story has an acceptance criterion (flag any that don't)
|
||||
- [ ] Stories estimated at 8+ points are flagged for splitting
|
||||
- [ ] Carry-overs from last sprint are accounted for in capacity
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write sprint goals as task lists — goals must be outcome-focused and scoreable pass/fail at sprint end
|
||||
- [ ] Do not commit to 100% of available capacity — always recommend 80% to preserve slack for unplanned work
|
||||
- [ ] Do not carry stories with no acceptance criteria into the sprint — flag them as blockers before committing
|
||||
- [ ] Do not allow stories estimated at 8+ points into the sprint without splitting them first
|
||||
- [ ] Do not ignore carry-over items when calculating capacity — they consume capacity and must be accounted for before new work is pulled in
|
||||
|
||||
@@ -147,3 +147,11 @@ Error codes: [list]
|
||||
- [ ] At least 2 alternative approaches are documented with reasons for rejection
|
||||
- [ ] Security and privacy section is completed for any feature touching user data
|
||||
- [ ] All open questions have a named owner and due date (not "TBD")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not include solution language in the problem statement — the problem must be described independently of the proposed solution
|
||||
- [ ] Do not omit alternatives considered — a spec that considers only one approach has not been properly evaluated
|
||||
- [ ] Do not leave open questions as "TBD" without a named owner and due date — unresolved questions are blockers
|
||||
- [ ] Do not skip security and privacy sections for any feature that touches user data
|
||||
- [ ] Do not write a non-goals section that is empty — always list at least two things that might be assumed in scope
|
||||
|
||||
@@ -0,0 +1,226 @@
|
||||
---
|
||||
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)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write user stories from a technical perspective — every story must be from the user's point of view and state their goal
|
||||
- [ ] Do not write acceptance criteria that are untestable — every criterion must have a clear pass/fail condition
|
||||
- [ ] Do not create stories that are too large to complete in a single sprint — break epics into estimable, independently deliverable stories
|
||||
- [ ] Do not omit edge cases — unhappy paths and error states are required, not optional
|
||||
- [ ] Do not skip the Definition of Done — without it, "done" means different things to different people
|
||||
|
||||
## 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"
|
||||
@@ -167,6 +167,14 @@ Ask the user for these if not provided:
|
||||
- [ ] Effort estimates are included for prioritisation
|
||||
- [ ] Testing recommendations are included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not rely solely on automated scanning tools — automated checks catch ~30% of issues; manual keyboard and screen reader testing is required
|
||||
- [ ] Do not label an issue "minor" simply because it only affects a small percentage of users — for those users it may block all access
|
||||
- [ ] Do not add ARIA roles to fix broken semantics — use correct semantic HTML first; ARIA is a last resort
|
||||
- [ ] Do not confuse colour contrast of text with colour contrast of UI components — they have different minimum ratios (4.5:1 vs 3:1)
|
||||
- [ ] Do not audit only the happy path — error states, empty states, and loading states must also meet accessibility requirements
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Audit this design for accessibility"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: design-critique
|
||||
description: "Give structured, constructive feedback on any design. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback."
|
||||
description: "Gives structured, constructive feedback on any design using UX frameworks. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback with prioritised issues and specific recommendations."
|
||||
---
|
||||
|
||||
# Design Critique Skill
|
||||
@@ -121,6 +121,14 @@ Prioritised list of the 3 most impactful changes. Each should be actionable in t
|
||||
- [ ] Priority levels (High/Medium/Low) reflect actual impact on user goal
|
||||
- [ ] Heuristic assessment only covers visible elements
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not lead with visual preference (e.g. "I don't like the colour") — every issue must reference a UX principle or user impact
|
||||
- [ ] Do not invent problems in the "What's Working" section — manufactured praise undermines the entire critique
|
||||
- [ ] Do not provide the same priority level (High/Medium/Low) to every issue — prioritisation requires genuine judgment about user impact
|
||||
- [ ] Do not skip the JTBD section for product screens — connecting feedback to the user's job-to-be-done is what separates UX critique from aesthetic opinion
|
||||
- [ ] Do not give recommendations that require a full redesign when the user is in high-fidelity — scope recommendations to the design stage
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Critique this design: [description or image]"
|
||||
|
||||
@@ -0,0 +1,223 @@
|
||||
---
|
||||
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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assess only the Figma library without checking the code implementation — Figma-code drift is one of the most common and costly design system failures
|
||||
- [ ] Do not score adoption without interviewing teams — audit tool metrics miss the human reasons teams build custom components instead of using the system
|
||||
- [ ] Do not treat all component gaps equally — prioritise gaps based on how many production screens rely on custom implementations, not alphabetically
|
||||
- [ ] Do not recommend adding more components without first auditing documentation quality — an undocumented component is often worse than no component
|
||||
- [ ] Do not schedule remediation without a named owner per initiative — design system improvements without ownership consistently stall
|
||||
|
||||
## 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?"
|
||||
@@ -152,6 +152,14 @@ For each insight: "This means we should [design/product implication]" or "This c
|
||||
- [ ] Synthesis framework is included
|
||||
- [ ] Incentive recommendation is included
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a research plan without clearly stated research objectives — every methodology choice must flow from the objectives
|
||||
- [ ] Do not design a plan that mixes generative and evaluative research without clearly separating them
|
||||
- [ ] Do not omit screener criteria — recruiting unqualified participants invalidates the research
|
||||
- [ ] Do not write discussion guide questions that are leading — questions must be neutral and open-ended
|
||||
- [ ] Do not skip the incentive recommendation — uncompensated research has lower participant quality and completion rates
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a research plan for [feature or product area]"
|
||||
|
||||
@@ -51,6 +51,13 @@ Input: *"We're building a self-serve onboarding flow to reduce time-to-value for
|
||||
| Faster onboarding correlates with higher retention | Viability | 3 | 4 | 1 | Cohort analysis of current onboarding times vs. 90-day retention |
|
||||
| The current onboarding is the primary reason for slow time-to-value | Desirability | 2 | 4 | 2 | User interviews with recent churned SMB accounts |
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not only surface desirability assumptions — feasibility and viability assumptions are equally likely to kill a product and are often overlooked
|
||||
- [ ] Do not assign high confidence to an assumption just because it hasn't been challenged yet — absence of evidence is not evidence
|
||||
- [ ] Do not recommend "user interviews" as the validation method for every assumption — some assumptions require quantitative data, competitive analysis, or technical spikes
|
||||
- [ ] Do not list assumptions that cannot be tested — every assumption in the map must have a plausible validation method, or it should be flagged as unknowable and treated as a risk
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] At least one assumption per category (Desirability, Feasibility, Viability, Usability)
|
||||
|
||||
@@ -0,0 +1,223 @@
|
||||
---
|
||||
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
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not build the map from assumptions alone — ground at least the pain points in real customer data or research
|
||||
- [ ] Do not treat all journey stages as equally weighted — identify the highest-friction moments explicitly
|
||||
- [ ] Do not omit the emotional layer — a journey map without emotions is a process flow, not a customer map
|
||||
- [ ] Do not create generic touchpoints that apply to any product — each touchpoint must be specific to this product and customer
|
||||
- [ ] Do not leave opportunities unranked — prioritise by impact and feasibility
|
||||
|
||||
## 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]"
|
||||
@@ -105,3 +105,11 @@ Ask the user for these if not provided:
|
||||
- If user is new to interviewing: remind them to stay silent after asking a question (aim for 80/20 participant-to-interviewer talking ratio)
|
||||
- Never synthesise during the interview — do it after, when you can look across sessions
|
||||
- Flag confirmation bias: if user writes questions that lead toward a predetermined answer, rewrite them as open-ended alternatives
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not use future-tense questions ("Would you use this?") — hypothetical responses do not predict real behaviour and produce false confidence in an idea
|
||||
- [ ] Do not mention your product or solution before problem exploration is complete — doing so anchors the participant's responses and invalidates the discovery
|
||||
- [ ] Do not synthesise across fewer than 5 interviews — themes from 2–3 interviews reflect anecdote, not pattern; wait for saturation
|
||||
- [ ] Do not write screener questions that are too easy to pass — if participants can guess the "right" answer, you will recruit the wrong people
|
||||
- [ ] Do not treat participant opinions as evidence of future behaviour — what people say they will do consistently diverges from what they actually do
|
||||
|
||||
@@ -114,6 +114,22 @@ Rate each job story on:
|
||||
- [ ] Current workaround identified for each high-opportunity story
|
||||
- [ ] Product opportunity is distinct from "build the feature" (it's an outcome)
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or feature area** to map (e.g. onboarding, checkout, dashboard)
|
||||
- **User type or persona** (who are we mapping jobs for?)
|
||||
- **Source material** (user interview notes, support tickets, discovery findings, or describe from memory)
|
||||
- **Scope** (full product job map vs. a single feature area)
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write job stories that describe a feature rather than a situation-motivation pair
|
||||
- [ ] Do not skip the social and emotional dimensions — mapping only functional jobs misses the most defensible differentiation opportunities
|
||||
- [ ] Do not define situations too broadly ("as a user who wants to manage their work") — the situation must be a specific moment or trigger
|
||||
- [ ] Do not conflate opportunity scoring with priority — a high opportunity score still requires feasibility and strategic fit assessment
|
||||
- [ ] Do not produce a job map without identifying current workarounds — the workaround reveals what the job is worth to the customer
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never write a job story for a feature — write it for the situation that makes the feature valuable
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: user-interview-synthesis
|
||||
description: "Synthesise user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from user interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes, 'so what' implications, and recommended next steps."
|
||||
description: "Synthesises user interview transcripts into structured research findings. Use when asked to analyse interview notes, synthesise qualitative research, identify themes from interviews, or turn raw interview data into actionable product insights. Produces a themed synthesis with supporting quotes per theme, 'so what' implications, and recommended next steps."
|
||||
---
|
||||
|
||||
# User Interview Synthesis Skill
|
||||
@@ -50,3 +50,11 @@ Ask the user for these if not provided:
|
||||
- [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
|
||||
- [ ] Single-source signals are flagged separately, not mixed into main themes
|
||||
- [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not mix single-source signals into main themes — insights cited by only one participant must be flagged separately
|
||||
- [ ] Do not write implications that are observations restated rather than product decisions enabled
|
||||
- [ ] Do not include themes that only support the project hypothesis — contradictory findings must be surfaced, not omitted
|
||||
- [ ] Do not present findings without quotes — every theme requires verbatim evidence from at least 3 participants
|
||||
- [ ] Do not leave research questions unanswered — each question from the study brief must be explicitly addressed, even if the answer is inconclusive
|
||||
|
||||
@@ -13,10 +13,12 @@ Ask the user for these if not provided:
|
||||
- **API or endpoint details** (raw spec, Postman export, or verbal description)
|
||||
- **Auth method** (API key / Bearer token / OAuth 2.0 / None)
|
||||
- **Base URL**
|
||||
- **API version** (e.g. v1, v2.3, or "unversioned" — affects deprecation notes and versioning headers)
|
||||
- **Rate limits** (requests per second/minute per token or IP, if known — or "unknown")
|
||||
- **Audience** (internal developers / external partners / public)
|
||||
- **Output format** (Markdown / OpenAPI YAML / Plain prose)
|
||||
- **Output format** (Markdown for developer portals and READMEs / Plain prose for Confluence or Notion — note: OpenAPI YAML is not produced by this skill)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
For each endpoint, produce the following:
|
||||
|
||||
@@ -133,13 +135,21 @@ data = response.json()
|
||||
- [ ] Every parameter is documented (type, required/optional, description)
|
||||
- [ ] Response fields are fully documented with types
|
||||
- [ ] All relevant error codes are listed with resolution guidance
|
||||
- [ ] Code examples are copy-paste runnable (no pseudocode)
|
||||
- [ ] Error codes cover at minimum: 400 (bad request), 401/403 (auth), 404 (not found), 429 (rate limited), 500 (server error) — or explicitly note which don't apply to this endpoint
|
||||
- [ ] Code examples use the actual base URL and a realistic placeholder token — no examples reference undefined variables or "YOUR_ENDPOINT" outside the snippet
|
||||
- [ ] Auth method is clearly stated at the top
|
||||
- [ ] Enum values are listed where applicable
|
||||
- [ ] Pagination documented if the endpoint is a list endpoint
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not document only the happy path — every endpoint must have error codes for at least 400, 401/403, 404, 429, and 500
|
||||
- [ ] Do not use placeholder values like "YOUR_ENDPOINT" or "INSERT_TOKEN" in code examples — use realistic-looking placeholders anchored to the actual base URL
|
||||
- [ ] Do not skip enum values for fields with a fixed set of accepted values — undocumented enums cause integration bugs
|
||||
- [ ] Do not omit pagination documentation on list endpoints — developers who miss this will build integrations that silently miss data
|
||||
- [ ] Do not describe what a field "is" without describing what it "does" — "the ID" is not documentation; "the unique identifier used to retrieve or update this resource" is
|
||||
|
||||
## Usage Examples
|
||||
- "Document this API endpoint: [paste spec or description]"
|
||||
- "Turn this Postman collection into developer docs"
|
||||
- "Write API reference docs for [endpoint]"
|
||||
|
||||
@@ -301,6 +301,14 @@ builders and response parsers.
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not classify expanding an enum (new response values) as non-breaking — clients with exhaustive switch statements will break when they receive an unexpected enum value
|
||||
- [ ] Do not set a sunset date without confirming it is achievable for the largest consumer — a sunset that forces consumers to miss a legal deadline will be ignored or escalated
|
||||
- [ ] Do not maintain more than two simultaneous stable/deprecated versions — each additional supported version multiplies maintenance burden and consumer confusion
|
||||
- [ ] Do not use "monitor traffic" as the sole mechanism for knowing when all consumers have migrated — track named consumers against migration completion explicitly
|
||||
- [ ] Do not skip the migration guide — consumers will delay migration indefinitely without a step-by-step guide that estimates effort
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Versioning scheme recommendation includes explicit rationale tied to the API type and consumer type provided — not a generic recommendation
|
||||
|
||||
@@ -10,6 +10,7 @@ This skill produces a complete Architecture Decision Record (ADR) following the
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **ADR number** (sequential number in your ADR registry — e.g. 012; or "next available" if unknown)
|
||||
- **Decision title** (brief, e.g. "Use PostgreSQL as primary datastore")
|
||||
- **Context** (what situation led to this decision needing to be made?)
|
||||
- **Options considered** (at least 2; if only 1 is given, prompt for alternatives that were considered or ruled out)
|
||||
@@ -17,8 +18,9 @@ Ask the user for these if not provided:
|
||||
- **Reason for choice**
|
||||
- **Status** (Proposed / Accepted / Deprecated / Superseded)
|
||||
- **Author and date**
|
||||
- **Team context** (optional — team size, relevant experience, org constraints; helps calibrate formality and depth of the Context section)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
---
|
||||
|
||||
@@ -89,13 +91,13 @@ For each option, produce:
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
[Optional but valuable: any specific patterns, gotchas, or guidance for the team implementing based on this decision. Link to relevant tickets, RFCs, or design docs if applicable.]
|
||||
[Include if the decision has non-obvious implementation gotchas, or if there are related tickets/RFCs implementers will need. Skip only if the decision is purely tooling selection with no implementation ambiguity.]
|
||||
|
||||
---
|
||||
|
||||
## Review Date
|
||||
|
||||
[Optional: "This decision should be reviewed if [condition] — e.g. team grows beyond 20 engineers, or traffic exceeds 10M requests/day."]
|
||||
[Include unless the decision is permanent or self-evidently final. State a specific trigger condition — e.g. "Review if team grows beyond 20 engineers or traffic exceeds 10M requests/day" — not just "should be reviewed periodically".]
|
||||
|
||||
---
|
||||
|
||||
@@ -107,10 +109,18 @@ For each option, produce:
|
||||
- [ ] Consequences include *negative* consequences — no decision is consequence-free
|
||||
- [ ] Decision is stated in plain language in the Decision section
|
||||
- [ ] Risks section identifies what would invalidate this decision
|
||||
- [ ] Written for someone with no prior context on this decision
|
||||
- [ ] Context section states the problem explicitly in its first 1–2 sentences (does not assume the reader knows what problem the team was solving)
|
||||
- [ ] Each rejected option's "Why ruled out" explanation names a specific constraint or trade-off (not a circular statement like "didn't meet our requirements")
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write an ADR after the decision has already been fully implemented and the team has moved on — ADRs written retrospectively often omit the real reasons and alternatives
|
||||
- [ ] Do not list only the chosen option — rejected options with honest reasons are the most valuable part of an ADR for future readers
|
||||
- [ ] Do not write consequences that are all positive — every architectural decision involves trade-offs; an ADR with no negative consequences was not scrutinised honestly
|
||||
- [ ] Do not leave the status as "Proposed" indefinitely — an ADR that no one has approved is not guiding anyone's decisions
|
||||
- [ ] Do not write context that assumes the reader already knows what problem was being solved — the context section exists precisely for readers who lack that background
|
||||
|
||||
## Usage Examples
|
||||
- "Write an ADR for using [technology]"
|
||||
- "Document our decision to [architectural choice]"
|
||||
- "Create an architecture decision record for [topic]"
|
||||
|
||||
@@ -346,6 +346,14 @@ Define the thresholds that require explicit action — not retrospective fixes a
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not set capacity trigger thresholds without knowing the baseline — a "CPU > 70%" alert is meaningless if you don't know what normal looks like
|
||||
- [ ] Do not plan only for average traffic — capacity plans that don't model peak load will result in incidents during the events that matter most
|
||||
- [ ] Do not conflate vertical and horizontal scaling — adding more app servers without addressing database connection limits will not resolve the constraint
|
||||
- [ ] Do not present growth projections as certainties — all forecasts have uncertainty; state the confidence level and provide a conservative and optimistic scenario
|
||||
- [ ] Do not defer action items without a named owner and a specific date — a roadmap with no owners is a wish list
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every resource has a quantified current utilisation and a projected months-to-ceiling — no hand-waving
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: changelog-generator
|
||||
description: "Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes. Optimised for Opus 4.7 and newer models."
|
||||
description: "Convert a git log, commit list, or release notes into a polished, user-facing changelog. Use when writing release notes, generating a CHANGELOG.md entry, or documenting what changed in a version. Produces a structured changelog section with version header, categorised changes, and migration notes."
|
||||
---
|
||||
|
||||
# Changelog Generator Skill
|
||||
@@ -15,8 +15,10 @@ Ask for these if not provided:
|
||||
- **Release date** (or "today")
|
||||
- **Audience** (developers using an API / end users of a product / internal team — affects language)
|
||||
- **Any breaking changes** (flag these explicitly if known)
|
||||
- **Previous version behaviour** (optional — paste the previous changelog entry or describe what is changing; needed for accurate "Changed" entries)
|
||||
- **Scope** (whole product / specific package or module — e.g. "payments SDK only", "iOS app", "all services")
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
Follow [Keep a Changelog](https://keepachangelog.com) format:
|
||||
|
||||
@@ -52,6 +54,10 @@ Follow [Keep a Changelog](https://keepachangelog.com) format:
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
> **Skill guidance — do not include the following section in the delivered changelog:**
|
||||
|
||||
## Formatting Rules Applied
|
||||
|
||||
**Language:** Write for the reader, not the committer. "Add dark mode support" not "implement ThemeProvider with dark palette variant".
|
||||
@@ -72,9 +78,18 @@ Follow [Keep a Changelog](https://keepachangelog.com) format:
|
||||
- [ ] Related commits are grouped into single entries (not listed individually)
|
||||
- [ ] Version and date header is correct
|
||||
- [ ] Empty sections are omitted
|
||||
- [ ] Tone is imperative mood throughout
|
||||
- [ ] No entries start with past-tense verbs (no "Added", "Fixed", "Removed" — use "Add", "Fix", "Remove")
|
||||
- [ ] Every breaking change entry includes a specific migration action (not just "update your code")
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not include implementation details in changelog entries — users need to know what changed for them, not how the code was refactored internally
|
||||
- [ ] Do not list every micro-commit as a separate entry — related commits should be grouped into one user-facing change
|
||||
- [ ] Do not omit the migration path for breaking changes — a breaking change entry without a specific migration action forces users to read the source code
|
||||
- [ ] Do not include empty sections — a "### Fixed" section with no entries signals the template was filled in carelessly
|
||||
- [ ] Do not write breaking changes in the same casual tone as minor additions — breaking changes must be visually prominent and call out migration requirements explicitly
|
||||
|
||||
## Usage Examples
|
||||
- "Write a changelog for version [X]" + [paste commits]
|
||||
- "Generate release notes from these commits"
|
||||
- "Turn this git log into a CHANGELOG entry"
|
||||
|
||||
@@ -292,6 +292,14 @@ Ask for these if not already provided:
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not describe a rollback procedure that has never been tested — a theoretical rollback is not a rollback plan; test it in staging before production
|
||||
- [ ] Do not allow deploys on Fridays or before holidays without an explicit on-call engineer who will monitor through the weekend
|
||||
- [ ] Do not commit secrets to source control even in non-production branches — secret scanning in the pipeline catches this, but prevention is the standard
|
||||
- [ ] Do not skip post-deploy monitoring after a production deploy — the deploying engineer must watch error rates and latency for the specified observation window
|
||||
- [ ] Do not suppress a security scan finding without a linked ticket and a named owner — suppressions without accountability accumulate into unmanaged risk
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every stage has a clear owner when it fails
|
||||
|
||||
@@ -0,0 +1,290 @@
|
||||
---
|
||||
name: claude-superpowers
|
||||
description: "Activate a 4-stage coding discipline framework that forces Claude to plan before coding, isolate changes on a branch, write tests first, and self-review output twice before presenting it. Use when starting a complex coding task, when past Claude sessions produced broken first drafts, or when you want to prevent rework cycles. Produces a confirmed written plan, isolated feature branch, test-first implementation, and a double-reviewed output with a correctness and code-quality checklist."
|
||||
---
|
||||
|
||||
# Claude Superpowers Skill
|
||||
|
||||
Stop Claude from shipping the first thing it writes. Superpowers mode locks Claude into four stages — Plan, Isolate, Test First, Double Review — so that what it presents at the end is actually right.
|
||||
|
||||
The default problem: Claude sprints out of the gate, writes the whole thing in one shot, and it looks great — until someone runs it. It doesn't plan. It doesn't test. It doesn't verify. The result: code that breaks on edge cases, debugging rounds that burn tokens, and rework that costs more than doing it right the first time.
|
||||
|
||||
> **Credit:** Inspired by a skill from Nate Herk's YouTube channel — adapted and extended for this library.
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
No inputs required. Superpowers activates on command, then applies to whatever coding task follows.
|
||||
|
||||
---
|
||||
|
||||
## The Four Stages
|
||||
|
||||
### Stage 1 — Plan
|
||||
|
||||
Before writing a single line of code, Claude must produce a written plan and wait for user confirmation.
|
||||
|
||||
**Plan format:**
|
||||
|
||||
```
|
||||
PLAN
|
||||
════
|
||||
|
||||
TASK
|
||||
[One-sentence restatement of what was asked. If anything is ambiguous, flag it here before proceeding.]
|
||||
|
||||
APPROACH
|
||||
[2–4 sentences describing the implementation approach and key decisions. If there are multiple valid approaches, briefly explain why this one was chosen.]
|
||||
|
||||
FILES TO CREATE OR MODIFY
|
||||
- [path/to/file.ts] — [what changes: create / modify / delete — one line reason]
|
||||
- [path/to/file.ts] — [what changes]
|
||||
|
||||
EDGE CASES I WILL HANDLE
|
||||
- [Edge case 1]
|
||||
- [Edge case 2]
|
||||
- [Edge case 3]
|
||||
|
||||
EDGE CASES I AM NOT HANDLING (out of scope)
|
||||
- [Out of scope case — reason]
|
||||
|
||||
ASSUMPTIONS
|
||||
- [Any assumption made where the requirements were unclear]
|
||||
|
||||
Confirm this plan before I start coding.
|
||||
```
|
||||
|
||||
Claude must not proceed until the user says yes (or provides corrections). If the user corrects the plan, revise and re-confirm before starting.
|
||||
|
||||
---
|
||||
|
||||
### Stage 2 — Isolate
|
||||
|
||||
Claude works in isolation until the output is complete and reviewed. Nothing touches the main project until explicitly approved.
|
||||
|
||||
**Isolation rules:**
|
||||
- If git is available: create a feature branch before making any changes. Branch name format: `superpowers/[task-slug]`
|
||||
- If no git: note that changes are being made to a working copy and flag all modified files at the end for user review before they're considered "shipped"
|
||||
- Do not modify files outside the scope defined in the plan unless the user explicitly expands scope during the session
|
||||
- If new scope is discovered mid-task (e.g. a dependency needs to change), surface it: "This requires also modifying [X] — should I include that in scope?"
|
||||
|
||||
**On starting Stage 2, announce:**
|
||||
```
|
||||
ISOLATE
|
||||
Working in isolation on branch: superpowers/[task-slug]
|
||||
No changes will be considered final until Stage 4 review is complete.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Stage 3 — Test First
|
||||
|
||||
Before writing the implementation, write the tests (or at minimum, define the expected behaviour as executable assertions).
|
||||
|
||||
**Test-first approach:**
|
||||
1. Write tests that define the expected behaviour for the task
|
||||
2. Write tests that cover each edge case identified in the plan
|
||||
3. Run the tests — they should fail (implementation doesn't exist yet)
|
||||
4. Confirm the tests are failing for the right reason before writing implementation
|
||||
5. Write the implementation
|
||||
6. Run the tests — they should now pass
|
||||
7. If tests fail: fix the implementation, not the tests
|
||||
|
||||
**If the project has no test setup:** flag it and offer two options:
|
||||
- Option A: Set up a minimal test harness before proceeding (recommended)
|
||||
- Option B: Define the expected behaviour as a checklist of manual verification steps (faster but weaker)
|
||||
|
||||
**Test summary to show before writing implementation:**
|
||||
|
||||
```
|
||||
TESTS WRITTEN
|
||||
─────────────
|
||||
File: [test file path]
|
||||
Tests:
|
||||
✗ [test description — covers: happy path]
|
||||
✗ [test description — covers: edge case 1]
|
||||
✗ [test description — covers: edge case 2]
|
||||
✗ [test description — covers: error state]
|
||||
|
||||
All tests failing as expected. Starting implementation.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Stage 4 — Double Review
|
||||
|
||||
After completing the code and running tests, Claude reviews its own work twice before presenting it. Neither review is a formality.
|
||||
|
||||
**Review 1 — "Does this match what was asked for?"**
|
||||
|
||||
Check the completed code against the original request and confirmed plan:
|
||||
- Does it do everything that was asked?
|
||||
- Does it handle all edge cases from the plan?
|
||||
- Are there any mismatches between what was planned and what was built?
|
||||
- Are there any assumptions baked in that weren't confirmed?
|
||||
|
||||
**Review 2 — "Is this good code?"**
|
||||
|
||||
Check for technical quality independent of the requirements:
|
||||
- Obvious bugs or logic errors
|
||||
- Missing error handling (especially at boundaries: API calls, file I/O, user input)
|
||||
- Security issues (injection vulnerabilities, exposed secrets, missing auth checks)
|
||||
- Readability: would another developer understand this in 6 months?
|
||||
- Performance: any obvious inefficiencies on the critical path?
|
||||
- Dead code or unused imports introduced
|
||||
|
||||
**Double Review output format:**
|
||||
|
||||
```
|
||||
REVIEW 1 — CORRECTNESS
|
||||
───────────────────────
|
||||
✅ Handles [requirement 1]
|
||||
✅ Handles [requirement 2]
|
||||
✅ Edge case [X] covered
|
||||
⚠️ [Issue found — what it is and what was changed to fix it]
|
||||
|
||||
REVIEW 2 — CODE QUALITY
|
||||
────────────────────────
|
||||
✅ Error handling present at all API boundaries
|
||||
✅ No obvious security issues
|
||||
⚠️ [Issue found — what it was and how it was fixed]
|
||||
✅ Readable — no unexplained complexity
|
||||
|
||||
VERDICT: [Ready to present / Fixed N issues before presenting]
|
||||
```
|
||||
|
||||
If issues are found in either review, fix them and note what was fixed. Present the corrected version, not the original draft.
|
||||
|
||||
---
|
||||
|
||||
## Activation Response
|
||||
|
||||
When the user triggers Superpowers mode, respond with:
|
||||
|
||||
```
|
||||
Superpowers mode active.
|
||||
|
||||
I'll work in 4 stages for every coding task this session:
|
||||
1. PLAN — Write a plan and wait for your confirmation before coding
|
||||
2. ISOLATE — Work on a branch; nothing ships until you approve
|
||||
3. TEST — Write tests before the implementation
|
||||
4. REVIEW — Review my own work twice before presenting it
|
||||
|
||||
What are we building?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Full task flow (all four stages)
|
||||
|
||||
```
|
||||
PLAN
|
||||
════
|
||||
[Plan format as above]
|
||||
Confirm this plan before I start coding.
|
||||
|
||||
---
|
||||
[User confirms]
|
||||
---
|
||||
|
||||
ISOLATE
|
||||
Working in isolation on branch: superpowers/[task-slug]
|
||||
|
||||
TESTS WRITTEN
|
||||
─────────────
|
||||
[Test summary — all failing]
|
||||
Starting implementation.
|
||||
|
||||
---
|
||||
[Implementation runs]
|
||||
---
|
||||
|
||||
REVIEW 1 — CORRECTNESS
|
||||
───────────────────────
|
||||
[Checklist]
|
||||
|
||||
REVIEW 2 — CODE QUALITY
|
||||
────────────────────────
|
||||
[Checklist]
|
||||
|
||||
VERDICT: Ready to present.
|
||||
|
||||
---
|
||||
|
||||
COMPLETE
|
||||
════════
|
||||
[Summary of what was built, files created/modified, how to run/test it]
|
||||
Branch: superpowers/[task-slug] — merge when ready.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## CLAUDE.md Installation Text
|
||||
|
||||
After activating Superpowers for the session, provide the user with the exact text to add to their `CLAUDE.md` to make it permanent:
|
||||
|
||||
````
|
||||
```
|
||||
## Superpowers Framework
|
||||
|
||||
This framework is always active for coding tasks in this project.
|
||||
|
||||
### Stage 1 — Plan
|
||||
Before writing any code: produce a written plan including task restatement, approach, files to create/modify, edge cases to handle, and assumptions. Wait for explicit user confirmation before proceeding.
|
||||
|
||||
### Stage 2 — Isolate
|
||||
Work on a feature branch (superpowers/[task-slug]) or clearly flagged working copy. Nothing is considered shipped until the user approves after Stage 4.
|
||||
|
||||
### Stage 3 — Test First
|
||||
Write tests before writing the implementation. Tests should fail before implementation, pass after. If no test setup exists, offer to create one or produce a manual verification checklist.
|
||||
|
||||
### Stage 4 — Double Review
|
||||
After completing code, run two reviews before presenting:
|
||||
- Review 1: Does this match what was asked for? Check against original request and plan.
|
||||
- Review 2: Is this good code? Check for bugs, missing error handling, security issues, readability.
|
||||
Fix any issues found. Present the corrected version. Show the review checklist.
|
||||
```
|
||||
````
|
||||
|
||||
Tell the user: "Add this to your CLAUDE.md and Superpowers will be active permanently for this project."
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Stage 1 plan was shown and user explicitly confirmed before any code was written
|
||||
- [ ] Plan includes: task restatement, approach, files to modify, edge cases in scope, edge cases out of scope, assumptions
|
||||
- [ ] Ambiguities in the original request were flagged in the plan (not silently assumed)
|
||||
- [ ] Stage 2 isolation: a feature branch was created (or flagged as working copy if no git)
|
||||
- [ ] Stage 3 tests were written before implementation — not after
|
||||
- [ ] Tests were run and confirmed to be failing before implementation started
|
||||
- [ ] Stage 4 Review 1 checked against the original request — not just against the plan
|
||||
- [ ] Stage 4 Review 2 checked for bugs, error handling, security, readability — all four
|
||||
- [ ] Issues found in either review were fixed before presenting — not flagged as "things to fix later"
|
||||
- [ ] Final output shows what was built, which files were changed, and how to run/test it
|
||||
- [ ] CLAUDE.md installation text was offered after activation
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not proceed to Stage 2 without explicit user confirmation of the plan — coding before confirmation defeats the entire purpose of the planning stage
|
||||
- [ ] Do not write tests after the implementation and call it "test-first" — tests must be written and confirmed failing before the implementation starts
|
||||
- [ ] Do not skip the Double Review when time is tight — the review is most valuable precisely when speed is the priority, because that is when errors are most likely
|
||||
- [ ] Do not expand scope during Stage 2 without surfacing it — silent scope expansion produces code the user did not approve and may not want
|
||||
- [ ] Do not mark both reviews as clean without actually performing them — a rubber-stamp review produces false confidence and defeats the framework
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Enable superpowers mode"
|
||||
- "Activate superpowers"
|
||||
- "Turn on superpowers for this session"
|
||||
- "Use the superpowers framework"
|
||||
- "Make sure you plan before coding"
|
||||
- "I want you to review your work before showing me"
|
||||
- "Write tests first this time"
|
||||
- "Slow down and plan it out before you start building"
|
||||
- "Work on a branch and show me a plan before touching anything"
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: code-review-checklist
|
||||
description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation. Optimised for Opus 4.7 and newer models."
|
||||
description: "Generate a tailored code review checklist for any pull request based on the language, type of change, and risk level. Use when asked to review code, check a PR, review a pull request, or generate a code review checklist. Produces a focused checklist with language-specific checks, risk-level-appropriate depth, and a clear approve/request-changes recommendation."
|
||||
---
|
||||
|
||||
# Code Review Checklist Skill
|
||||
@@ -14,15 +14,19 @@ Ask the user for these if not provided:
|
||||
- **Type of change** (feature / bug fix / refactor / dependency upgrade / security patch / performance)
|
||||
- **Risk level** (low / medium / high / critical)
|
||||
- **PR description** (paste the description or link to the PR)
|
||||
- **Code or diff** (optional — paste key changed files or a `git diff`; significantly improves checklist specificity)
|
||||
- **Author context** (new starter / experienced / external contributor)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
### 1. Review Summary
|
||||
**PR:** [Title or reference]
|
||||
---
|
||||
|
||||
# Code Review: [PR Title or Reference]
|
||||
|
||||
### 1. PR Overview
|
||||
**Scope assessment:** [Small / Medium / Large / Too large — should be split]
|
||||
**Recommended review depth:** [Skim / Standard / Deep dive]
|
||||
**Estimated review time:** [Minutes]
|
||||
**Estimated review time:** [e.g. 20–30 min — use 5 min per 50 lines of diff as a rough guide]
|
||||
|
||||
### 2. Correctness Checks
|
||||
|
||||
@@ -94,14 +98,25 @@ Language-specific correctness checks — choose based on the language stated:
|
||||
### 7. Common Pitfalls for This Change Type
|
||||
Based on the change type and language, flag 2-3 things reviewers typically miss for this combination.
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Checklist is tailored to the stated language (not generic)
|
||||
- [ ] Change-type-specific section is included
|
||||
- [ ] Risk-appropriate depth matches stated risk level
|
||||
- [ ] Decision framework is explicit
|
||||
- [ ] Decision framework includes at least one named blocking condition and one named non-blocking comment condition
|
||||
- [ ] Common pitfalls are specific to the stated language + change-type combo (not generic advice like "watch out for bugs")
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not generate a generic checklist that ignores the stated language — a Python checklist and a Go checklist have fundamentally different correctness concerns
|
||||
- [ ] Do not treat "looks fine" as a valid review outcome — the checklist exists to surface specific concerns, not validate a superficial read
|
||||
- [ ] Do not scope a "high risk" review the same as a "low risk" review — depth must scale with the stated risk level
|
||||
- [ ] Do not flag every stylistic preference as a blocking issue — distinguish between blocking correctness issues and non-blocking comments
|
||||
- [ ] Do not skip the "common pitfalls" section for the stated language and change-type combination — this is where the most valuable knowledge lives
|
||||
|
||||
## Usage Examples
|
||||
- "Generate a code review checklist for [PR description]"
|
||||
- "What should I check in this pull request?"
|
||||
- "Give me a code review checklist for a [language] [change type]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
|
||||
@@ -0,0 +1,248 @@
|
||||
---
|
||||
name: context-mode
|
||||
description: "Activate output filtering, session logging, and auto-resume to keep Claude Code sessions productive across resets. Use when starting a long or complex coding session, when previous sessions lost context mid-task, or when you need Claude to resume exactly where it left off after a reset. Installs a session.log at project root, filters verbose command output to preserve context, and automatically resumes in-progress tasks after any Claude reset."
|
||||
---
|
||||
|
||||
# Context Mode Skill
|
||||
|
||||
Fix the two session killers that end most Claude Code sessions in under 30 minutes: context bloat from raw command output, and memory loss after a reset.
|
||||
|
||||
Context Mode runs three systems simultaneously to keep sessions alive:
|
||||
|
||||
- **Output Filtering** — strips verbose command output before it enters context
|
||||
- **Session Log** — writes a running log of everything that happened
|
||||
- **Auto-Resume** — reads the log on reset and picks up exactly where you left off
|
||||
|
||||
> **Credit:** Inspired by a skill from Nate Herk's YouTube channel — adapted and extended for this library.
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
No inputs required. Context Mode activates on command.
|
||||
|
||||
Optional: user can specify a custom log file path if they don't want `session.log` in the project root.
|
||||
|
||||
---
|
||||
|
||||
## How Context Mode Works
|
||||
|
||||
### Part 1 — Output Filtering
|
||||
|
||||
The problem: every time Claude Code runs a command, the full raw output enters the context window. A single `npm install` can dump hundreds of lines. A test suite run? Thousands. Within 30 minutes, the context is full of noise and Claude resets.
|
||||
|
||||
The fix: before any command output enters context, filter it to the useful summary only.
|
||||
|
||||
**What gets kept:**
|
||||
- Last 10 lines of stdout
|
||||
- Every line containing `error`, `warn`, `fail`, `exception`, `traceback`, or `fatal` (case-insensitive)
|
||||
- The exit code
|
||||
- A one-line summary of what the command did and whether it succeeded
|
||||
|
||||
**What gets discarded:**
|
||||
- Middle section of long stdout (replaced with `[... N lines of output truncated ...]`)
|
||||
- Progress bars, download indicators, verbose install logs
|
||||
- Repeated identical lines (deduplicated)
|
||||
|
||||
**Filtering summary format:**
|
||||
|
||||
```
|
||||
COMMAND: [command run]
|
||||
STATUS: [exit code — success / failed]
|
||||
SUMMARY: [one sentence: what happened]
|
||||
ERRORS: [any error/warn lines — or "none"]
|
||||
TAIL: [last 10 lines of stdout]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Part 2 — Session Log
|
||||
|
||||
Claude maintains a running log file at `[project root]/session.log`. This file is written after every significant action and is the source of truth for resuming after a reset.
|
||||
|
||||
**Session log format:**
|
||||
|
||||
```
|
||||
SESSION LOG
|
||||
===========
|
||||
Started: [timestamp]
|
||||
Branch: [current git branch]
|
||||
Directory: [working directory]
|
||||
|
||||
FILES EDITED
|
||||
────────────
|
||||
[timestamp] [file path] — [one-line description of what changed]
|
||||
|
||||
COMMANDS RUN
|
||||
────────────
|
||||
[timestamp] [command] — [outcome: success / failed — brief reason]
|
||||
|
||||
TASKS IN PROGRESS
|
||||
─────────────────
|
||||
[ ] [Task description — what's been done so far and what's left]
|
||||
[x] [Completed task]
|
||||
|
||||
LAST USER PROMPT
|
||||
────────────────
|
||||
[The most recent instruction from the user, verbatim]
|
||||
|
||||
LAST ACTION TAKEN
|
||||
─────────────────
|
||||
[What Claude did last, in one sentence]
|
||||
```
|
||||
|
||||
**Log update rules:**
|
||||
- Write to `session.log` after every file edit
|
||||
- Write to `session.log` after every command run
|
||||
- Update "Tasks in Progress" when a task is started, progressed, or completed
|
||||
- Always overwrite "Last User Prompt" and "Last Action Taken" with the current values — don't append, replace
|
||||
|
||||
---
|
||||
|
||||
### Part 3 — Resume on Reset
|
||||
|
||||
When a new Claude session starts, the first action is:
|
||||
|
||||
1. Check for `session.log` in the project root
|
||||
2. If found, read it and announce the resume:
|
||||
|
||||
```
|
||||
Resuming session.
|
||||
|
||||
Branch: [branch]
|
||||
Last working on: [last task in progress]
|
||||
Files edited: [list from session log]
|
||||
Tasks pending: [incomplete tasks]
|
||||
Last prompt: "[last user prompt]"
|
||||
|
||||
Continuing from where we left off.
|
||||
```
|
||||
|
||||
3. Continue with the next logical step — don't ask "what should I do?" — check the task list and carry on
|
||||
|
||||
If no `session.log` exists, start fresh and initialise the log.
|
||||
|
||||
---
|
||||
|
||||
## Activation Response
|
||||
|
||||
When the user triggers Context Mode, respond with:
|
||||
|
||||
```
|
||||
Context Mode active.
|
||||
|
||||
Session log initialised at: [absolute path to session.log]
|
||||
Output filtering: enabled
|
||||
Auto-resume: enabled
|
||||
|
||||
I'll maintain your session state across resets. Long sessions won't lose context.
|
||||
```
|
||||
|
||||
Then immediately initialise `session.log` with the current timestamp, branch, and directory.
|
||||
|
||||
---
|
||||
|
||||
## Output Structure
|
||||
|
||||
### On activation
|
||||
|
||||
```
|
||||
Context Mode active.
|
||||
Session log initialised at: [path]
|
||||
Output filtering: enabled
|
||||
Auto-resume: enabled
|
||||
I'll maintain your session state across resets. Long sessions won't lose context.
|
||||
```
|
||||
|
||||
### On command execution (filtered output format)
|
||||
|
||||
```
|
||||
COMMAND: npm test
|
||||
STATUS: exit 1 — failed
|
||||
SUMMARY: 47 tests passed, 3 failed in auth.test.ts
|
||||
ERRORS: Error: Expected 200, received 401 (line 84)
|
||||
Error: Token not found in response (line 112)
|
||||
TAIL:
|
||||
✓ login with valid credentials (23ms)
|
||||
✓ logout clears session (11ms)
|
||||
✗ refresh token after expiry
|
||||
...
|
||||
```
|
||||
|
||||
### On reset / new session (resume announcement)
|
||||
|
||||
```
|
||||
Resuming session.
|
||||
|
||||
Branch: feature/auth-refresh
|
||||
Last working on: Fixing token refresh logic in auth.service.ts
|
||||
Files edited: src/auth/auth.service.ts, src/auth/auth.test.ts
|
||||
Tasks pending: [ ] Fix failing test on line 112
|
||||
[ ] Run full test suite once fix is applied
|
||||
Last prompt: "The refresh token test is still failing — look at the 401 handling"
|
||||
|
||||
Continuing from where we left off.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## CLAUDE.md Installation Text
|
||||
|
||||
After activating Context Mode for the session, provide the user with the exact text to add to their `CLAUDE.md` to make it permanent across all sessions:
|
||||
|
||||
````
|
||||
```
|
||||
## Context Mode
|
||||
|
||||
Context Mode is always active in this project.
|
||||
|
||||
### Output Filtering
|
||||
Before any command output enters context, filter it to:
|
||||
- Last 10 lines of stdout
|
||||
- Any lines containing: error, warn, fail, exception, traceback, fatal (case-insensitive)
|
||||
- Exit code
|
||||
- One-line summary of what the command did
|
||||
|
||||
Use this format for filtered output:
|
||||
COMMAND: [command]
|
||||
STATUS: [exit code — success/failed]
|
||||
SUMMARY: [one sentence]
|
||||
ERRORS: [error lines or "none"]
|
||||
TAIL: [last 10 lines]
|
||||
|
||||
### Session Log
|
||||
Maintain a running session log at ./session.log. Write to it after every file edit and every command run. Track: files edited, commands run, tasks in progress, last user prompt, last action taken. Format defined in Context Mode skill.
|
||||
|
||||
### Auto-Resume
|
||||
At the start of every new session, check for ./session.log. If it exists, read it and announce the resume state. Continue from the last task in progress without asking for instructions.
|
||||
```
|
||||
````
|
||||
|
||||
Tell the user: "Add this to your CLAUDE.md and Context Mode will be active permanently for this project — even after you close and reopen the session."
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] `session.log` was initialised immediately on activation (not deferred)
|
||||
- [ ] Log path shown to user is the absolute path, not relative
|
||||
- [ ] Output filtering is applied on the very next command run — not just announced
|
||||
- [ ] Filtered output format includes: command, status, summary, errors, and tail — all five fields
|
||||
- [ ] Session log tracks all four categories: files edited, commands run, tasks in progress, last prompt
|
||||
- [ ] Resume announcement reads the actual log contents — not a generic template
|
||||
- [ ] On resume, Claude continues the work without prompting the user for instructions
|
||||
- [ ] CLAUDE.md installation text was offered after activation
|
||||
- [ ] Log update rule is clear: "Last User Prompt" and "Last Action Taken" replace previous values, not append
|
||||
|
||||
---
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Enable context mode"
|
||||
- "Turn on context mode for this session"
|
||||
- "Activate long session mode"
|
||||
- "I keep losing context — fix it"
|
||||
- "Set up session logging"
|
||||
- "Keep track of what you've done so you can resume after a reset"
|
||||
- "Enable output filtering to save context"
|
||||
- "Set up auto-resume so we don't lose our place"
|
||||
@@ -452,3 +452,11 @@ Follow this checklist on the day of migration. Mark each step as done before pro
|
||||
- [ ] Lock types are identified for every DDL statement — no "should be fine" assumptions
|
||||
- [ ] The deployment runbook names who runs each step, not just what to run
|
||||
- [ ] Phase 4 (contract) is explicitly gated on the rollback window passing — not run on the same day as Phase 3
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not combine the expand and contract phases into a single deployment — they must be separated by a deployment cycle
|
||||
- [ ] Do not run DDL changes without first testing on a production-sized data clone
|
||||
- [ ] Do not skip the NOT VALID + VALIDATE pattern for constraint additions on large tables — it causes full table locks
|
||||
- [ ] Do not define a rollback as "restore from backup" — each phase must have an explicit, fast rollback procedure
|
||||
- [ ] Do not omit dual-write logic during the transition period — removing the old column before all writers are updated causes data loss
|
||||
|
||||
@@ -354,3 +354,11 @@ If this schema is being introduced to an existing system, note the migration app
|
||||
- [ ] JSONB columns are justified — not used as a substitute for proper schema design on queryable fields
|
||||
- [ ] Normalization decisions are documented with reasoning, not just stated
|
||||
- [ ] Migration notes address existing data if this is a schema change, not a greenfield schema
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not use JSONB columns as a substitute for proper relational schema design on fields that will be queried
|
||||
- [ ] Do not add indexes speculatively — every index must be justified by a specific access pattern
|
||||
- [ ] Do not omit timezone-awareness — use TIMESTAMPTZ, never plain TIMESTAMP
|
||||
- [ ] Do not design without documenting normalization decisions — future maintainers need the reasoning, not just the structure
|
||||
- [ ] Do not skip the access patterns section — schema without query patterns cannot be evaluated for correctness
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: debugging-log-analyser
|
||||
description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when sharing a log, stack trace, error output, or crash dump. Produces a structured diagnosis with probable root cause, affected code path, suggested fix, and next debugging steps. Optimised for Opus 4.7 and newer models."
|
||||
description: "Parse error logs, stack traces, and crash reports into a structured root cause diagnosis. Use when an application is throwing exceptions, crashing, or producing unexpected errors and you need to understand why and what to fix. Produces a structured diagnosis with error classification, stack trace walkthrough, probable root cause with confidence level, affected code path, a concrete code-level fix suggestion, and ordered next debugging steps."
|
||||
---
|
||||
|
||||
# Debugging Log Analyser Skill
|
||||
@@ -12,14 +12,19 @@ Parses raw error logs, stack traces, and crash reports into a structured diagnos
|
||||
Ask for these if not provided:
|
||||
- **The log / stack trace / error output** (paste directly or describe the error)
|
||||
- **Language and framework** (e.g. Node.js + Express, Python + Django, Java Spring, Go)
|
||||
- **Context** (what the user was doing when the error occurred)
|
||||
- **Context** (what changed before this started — e.g. recent deploy, config change, increased traffic, new input data; or "nothing changed" is also useful)
|
||||
- **Frequency** (one-off / intermittent / consistent / regression after a specific change)
|
||||
- **Environment** (local dev / staging / production)
|
||||
- **What they've already tried** (if anything)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
---
|
||||
|
||||
# Debugging Report: [Service/App Name]
|
||||
|
||||
### 1. Error Classification
|
||||
**Error type:** [Runtime exception / Build error / Config error / Network error / Memory/resource error / Unknown]
|
||||
**Error type:** [Runtime exception / Build error / Config error / Network error / Memory error / Unknown]
|
||||
**Severity:** [Fatal / Critical / Warning / Informational]
|
||||
**Recurrence pattern:** [One-off / Intermittent / Consistent / On-startup / Under load]
|
||||
|
||||
@@ -64,14 +69,17 @@ One or two concrete things that would prevent this class of error recurring:
|
||||
- Add monitoring/alerting for [condition]
|
||||
- Test that covers [scenario]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Root cause is specific (not "there might be a null pointer issue")
|
||||
- [ ] At least one concrete code-level fix is suggested
|
||||
- [ ] Next steps are actionable commands, not vague advice
|
||||
- [ ] Language-specific idioms are used correctly
|
||||
- [ ] Suggested fix references the actual language/framework in the input (not a generic fix that could apply to any language)
|
||||
- [ ] Confidence level includes a stated reason (not just "High" or "Low" with no explanation)
|
||||
- [ ] Prevention is proactive (not just "add error handling")
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Usage Examples
|
||||
- "Why is this crashing?" + [paste log]
|
||||
- "Can you analyse this stack trace?"
|
||||
- "I'm getting this error, what does it mean?"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: dependency-audit
|
||||
description: "Conduct a dependency audit for a project — checking for security vulnerabilities, license compliance issues, outdated packages, and transitive dependency risk. Use when asked to audit dependencies, review package security, check license compliance, assess dependency health, or produce a vulnerability report. Produces a vulnerability findings table, license compliance matrix, update priority matrix, dependency health score, and 30-day remediation plan."
|
||||
description: "Audits project dependencies for security vulnerabilities, license compliance issues, outdated packages, and transitive dependency risk. Use when asked to audit dependencies, review package security, check license compliance, assess dependency health, or produce a vulnerability report. Produces a vulnerability findings table, license compliance matrix, update priority matrix, dependency health score, and 30-day remediation plan."
|
||||
---
|
||||
|
||||
# Dependency Audit Skill
|
||||
@@ -330,3 +330,11 @@ go-licenses check ./... --allowed_licenses=MIT,Apache-2.0,BSD-2-Clause,BSD-3-Cla
|
||||
- [ ] CI pipeline change is included — the audit findings should be the last time these are caught manually
|
||||
- [ ] The dependency health score is calculated from actual findings, not estimated
|
||||
- [ ] Remediation plan actions are specific commands or steps, not "upgrade package X" without version targets
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not report only direct dependencies — transitive dependency vulnerabilities are often more dangerous and are the most commonly missed
|
||||
- [ ] Do not present raw audit tool output without interpretation — a table of 200 CVEs with no prioritisation is worse than no audit at all
|
||||
- [ ] Do not assign all Critical CVEs as "fix immediately" without checking whether an exploitable path exists in your usage context
|
||||
- [ ] Do not make license compliance decisions without legal input — flagging a GPL dependency without a recommendation is incomplete work
|
||||
- [ ] Do not complete the audit without including a CI/CD pipeline step — a one-time audit that leaves the door open for new vulnerabilities is not a remediation
|
||||
|
||||
@@ -330,3 +330,11 @@ curl http://localhost:[PORT]/health
|
||||
- [ ] On-call section has real links, not placeholders
|
||||
- [ ] Contacts are current — team members with real Slack handles
|
||||
- [ ] Troubleshooting covers the top 3 actual questions new joiners ask
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not document the ideal setup — document the actual setup; real oddities and gotchas are what new engineers need most
|
||||
- [ ] Do not leave placeholder contacts like "ask your manager" — name specific people for each domain or the doc becomes useless when the new joiner has an urgent question
|
||||
- [ ] Do not write the onboarding doc without reviewing it with a recent joiner — the author is blind to what they take for granted
|
||||
- [ ] Do not include every piece of architectural detail — an onboarding doc that covers everything teaches nothing; link to deeper docs instead
|
||||
- [ ] Do not skip the "things that might surprise you" section — undocumented non-obvious patterns are the number one cause of wasted engineering time in the first week
|
||||
|
||||
@@ -558,3 +558,11 @@ Run this checklist quarterly and before any major infrastructure change:
|
||||
- [ ] Contact list contains current phone numbers, not just Slack handles (Slack may be down during a DR event)
|
||||
- [ ] Security breach runbook (3.5) explicitly names the security team contact and does not attempt self-remediation
|
||||
- [ ] All thresholds (RTO/RPO) are visible in the monitoring dashboard so actual vs. target is measurable in real time
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write runbook commands without testing them — an untested command in a runbook is actively dangerous during a real disaster when cognitive load is highest
|
||||
- [ ] Do not set RTO/RPO targets without business sign-off — technical teams often set aspirational targets that do not reflect actual business cost tolerance for downtime
|
||||
- [ ] Do not include only the "happy path" of each failover scenario — runbooks must explicitly cover what to do when the recovery step itself fails
|
||||
- [ ] Do not list Slack handles as the only escalation contact — Slack may be unavailable during a region-wide failure; phone numbers are mandatory
|
||||
- [ ] Do not schedule DR game days without pre-committing to fix the gaps found — a game day that produces action items no one owns is theater, not preparedness
|
||||
|
||||
@@ -336,3 +336,11 @@ Brief every interviewer on these before they conduct their first interview for t
|
||||
- [ ] Scorecard uses observable behavior fields ("What did the candidate do or say") — not impression fields
|
||||
- [ ] Must-hire competencies are explicitly named for the role and level
|
||||
- [ ] Debrief agenda enforces written scorecard submission before verbal discussion to prevent anchoring
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not use a single behavioral anchor description per competency — you must define what Strong Hire AND No Hire look like separately, or interviewers cannot calibrate
|
||||
- [ ] Do not allow "culture fit" as a standalone assessment dimension — it masks similarity bias; all judgments must use observable behavioral evidence
|
||||
- [ ] Do not let interviewers share scorecard feedback before the debrief — verbal pre-debrief discussion anchors everyone to the first opinion expressed
|
||||
- [ ] Do not set the same must-hire competency list for all engineering roles — a senior backend engineer and a frontend engineer have different non-negotiable competencies
|
||||
- [ ] Do not skip the calibration bias notes section — interviewers who have never been briefed on halo effect, recency bias, and credential bias will reproduce them in every loop
|
||||
|
||||
@@ -162,3 +162,11 @@ If no decisions are pending: *No decisions pending.*
|
||||
- [ ] Escalations that need leadership attention are called out explicitly in the Risks section — not just buried in a table row
|
||||
- [ ] The entire report is readable in under 2 minutes — if it is longer than one printed page, trim it
|
||||
- [ ] Report period (week number and date range) is clearly stated in the header
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not fabricate metrics — if data is not available, mark the field as `[data needed]` rather than estimating; stakeholders making decisions on invented numbers is actively harmful
|
||||
- [ ] Do not write next week's priorities as activities ("work on X") — they must be outcomes ("ship X", "complete Y migration") so stakeholders can evaluate whether the team delivered
|
||||
- [ ] Do not bury escalations inside a risk table row — anything needing leadership attention must be called out explicitly in the Escalations section
|
||||
- [ ] Do not list blocked items without naming a specific owner and a concrete unblocking action — "waiting on X" is not a blocker entry, it is a placeholder
|
||||
- [ ] Do not write a report that exceeds two printed pages — length signals the author has not done the editorial work of deciding what matters to stakeholders
|
||||
|
||||
@@ -367,3 +367,11 @@ All flag changes in production must be traceable. Ensure the following are confi
|
||||
- [ ] Stale flag detection runs automatically and results are reviewed weekly
|
||||
- [ ] Code review checklist includes: "Does this PR introduce a flag? If yes, is the creation checklist complete?"
|
||||
- [ ] At least one person other than the flag owner knows how to disable any given flag in an emergency
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create release flags without a cleanup date — flags without expiry dates become permanent technical debt that accumulates silently until the codebase is unmaintainable
|
||||
- [ ] Do not skip monitoring setup for flags between 1–99% rollout — a partially-rolled-out flag without metric comparison is a risk without a sensor
|
||||
- [ ] Do not nest flags inside other flags — compound flag logic makes cleanup nearly impossible and creates untestable code paths
|
||||
- [ ] Do not allow flag owners to leave the team without reassigning ownership — orphan flags with no owner never get cleaned up
|
||||
- [ ] Do not use feature flags as a permanent configuration system — flags that have been at 100% or 0% for more than 30 days must be cleaned up; using flags as permanent config couples business logic to a feature flag platform
|
||||
|
||||
@@ -5,7 +5,7 @@ description: "Write a structured incident postmortem or post-incident review. Us
|
||||
|
||||
# Incident Postmortem Skill
|
||||
|
||||
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output is ready to share with engineering teams, leadership, and affected stakeholders.
|
||||
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output enforces blameless framing throughout — system gaps over individual failures — and drives toward specific, closeable action items rather than vague process commitments.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
@@ -20,8 +20,10 @@ Ask the user for these if not provided:
|
||||
- **How it was resolved**
|
||||
- **Initial thoughts on root cause**
|
||||
- **Action items already identified** (optional)
|
||||
- **Responders** (who was on-call or responded — names or roles; used for the timeline, not for blame)
|
||||
- **Customer or external communications sent** (optional — any status page updates, emails, or support messages with timestamps)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
---
|
||||
|
||||
@@ -131,13 +133,22 @@ Rules for action items:
|
||||
|
||||
- [ ] Timeline has no blame-focused language
|
||||
- [ ] Root cause is specific (not "human error")
|
||||
- [ ] Root cause answers "why did this happen?" not just "what happened?" — it names a system or process gap, not a symptom
|
||||
- [ ] Contributing factors explain the systemic gaps
|
||||
- [ ] Every action item has an owner and due date
|
||||
- [ ] "What went well" section is genuine, not token
|
||||
- [ ] No action item contains vague language like "improve monitoring", "increase resilience", or "better testing" — each must name a specific change
|
||||
- [ ] Executive summary is readable by non-technical leadership
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign blame to individuals — postmortems must focus on system and process failures
|
||||
- [ ] Do not write action items with vague language like "improve monitoring" — each must name a specific, ownable change
|
||||
- [ ] Do not skip the contributing factors — root cause alone misses the systemic issues that enable incidents
|
||||
- [ ] Do not omit the detection timeline — how long it took to detect matters as much as how long it took to resolve
|
||||
- [ ] Do not treat the postmortem as closed until all action items have named owners and due dates
|
||||
|
||||
## Usage Examples
|
||||
- "Write a postmortem for the [incident name] outage"
|
||||
- "Help me write a P1 incident report"
|
||||
- "Generate an RCA document for [service] going down on [date]"
|
||||
|
||||
@@ -290,3 +290,11 @@ Medium and Low findings should be tracked as follow-up issues with a committed r
|
||||
- [ ] Code snippets in findings show both the problematic code AND the corrected version
|
||||
- [ ] Overall risk rating is justified by the highest-severity open finding
|
||||
- [ ] Checklist items are binary (checkable) — not narrative observations
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not mark a finding as Low if it involves hardcoded credentials or secrets in any form — always Critical
|
||||
- [ ] Do not review IaC in isolation from the deployment context — networking and IAM must be evaluated together
|
||||
- [ ] Do not produce narrative findings without the specific resource name, file, and line number
|
||||
- [ ] Do not skip the "Required Actions Before Merge" summary — reviewers need a clear blocking list, not just a full report
|
||||
- [ ] Do not approve code where encryption at rest or in transit is missing on data stores, even if not explicitly flagged by the requester
|
||||
|
||||
@@ -430,3 +430,11 @@ load-test:
|
||||
- [ ] CI integration blocks promotion on threshold failure — not just records results
|
||||
- [ ] Soak test has been run at least once to establish a memory and connection pool baseline
|
||||
- [ ] Results comparison to previous run is part of the analysis — not just absolute pass/fail
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not set thresholds without grounding them in actual SLO targets or production baselines — arbitrary numbers produce meaningless pass/fail results
|
||||
- [ ] Do not run the load generator on the same host as the service under test — this contaminates both the test results and the service metrics
|
||||
- [ ] Do not use production user data in load test seeding — all test data must be synthetic, tagged, and cleaned up after each run
|
||||
- [ ] Do not skip the soak test on first deployment — only a soak test reveals slow memory leaks and connection pool exhaustion that short tests miss
|
||||
- [ ] Do not treat a passing baseline test as evidence the service handles spikes — baseline, stress, spike, and soak scenarios test fundamentally different failure modes
|
||||
|
||||
@@ -482,3 +482,11 @@ Before opening your first pull request, verify:
|
||||
- [ ] Docker Compose version and Docker Desktop memory requirements are stated explicitly
|
||||
- [ ] "Expected output" is shown for key commands so engineers know whether a step succeeded
|
||||
- [ ] Setup time estimate is honest — verified by timing a real onboarding session, not estimated
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write setup steps from memory without testing them on a clean machine — steps that skip implicit knowledge break for new engineers
|
||||
- [ ] Do not leave environment variables undocumented — every variable in .env.example must appear in the Variables table with a description and source
|
||||
- [ ] Do not write troubleshooting entries for theoretical issues — only include problems that have actually occurred during real onboarding sessions
|
||||
- [ ] Do not assume Docker Desktop is configured correctly — memory limits and platform (M1/M2) compatibility must be explicitly called out
|
||||
- [ ] Do not omit expected output for key commands — without "expected output", engineers cannot tell whether a step succeeded or silently failed
|
||||
|
||||
@@ -288,3 +288,11 @@ Conway's Law: the architecture of a system mirrors the communication structure o
|
||||
- [ ] If decomposing a monolith, the strangler fig migration plan has phases with durations, dependencies, and success criteria
|
||||
- [ ] Risk register addresses at minimum: data consistency, distributed transactions, and Conway's Law alignment
|
||||
- [ ] Organizational alignment section maps services to teams and identifies misalignments that need to be resolved
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not define service boundaries before completing the domain analysis — services derived without bounded context mapping will split the wrong things and couple the wrong things
|
||||
- [ ] Do not assign multiple teams as co-owners of a single service — shared ownership is no ownership; every service needs exactly one team accountable for it
|
||||
- [ ] Do not default to synchronous REST calls for all inter-service communication — using sync calls where async events would decouple services creates cascading failure modes
|
||||
- [ ] Do not propose more than one service per bounded context without a clear justification — over-decomposition (nanoservices) creates operational overhead that exceeds the decomposition benefit
|
||||
- [ ] Do not begin migration without deploying distributed tracing first — migrating without observability means flying blind when the first extraction causes a production incident
|
||||
|
||||
@@ -434,3 +434,11 @@ Honest assessment of what is missing today and what the priority to add it is:
|
||||
- [ ] The primary dashboard answers "is the service healthy?" in under 10 seconds — no hunting for the right panel
|
||||
- [ ] Business metrics are tracked alongside infrastructure metrics — not just four golden signals
|
||||
- [ ] Observability debt items have owners and dates — not just "would be nice to have"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not create alerts without a specific on-call action — an alert that just says "investigate" trains engineers to ignore it
|
||||
- [ ] Do not set alert thresholds from a template without calibrating against production baselines — uncalibrated thresholds cause either alert fatigue or missed incidents
|
||||
- [ ] Do not log PII, tokens, or secrets — a logging standard is incomplete without an explicit list of what must never be logged
|
||||
- [ ] Do not measure only the four golden signals without adding at least one business metric alert — infrastructure health can be green while the business-critical path is silently failing
|
||||
- [ ] Do not deploy distributed tracing without verifying that trace IDs propagate across all service boundaries — partial tracing is worse than no tracing because it produces misleading incomplete traces
|
||||
|
||||
@@ -362,3 +362,11 @@ ANYTHING ELSE:
|
||||
- [ ] Diagnostic commands work — they have been run by at least one person recently
|
||||
- [ ] Handoff template is used at every shift change — not just during incidents
|
||||
- [ ] "Things I had to figure out that weren't documented" are added to this runbook after every incident
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write alert runbooks with vague diagnostic steps like "check the logs" — every step must specify the exact command, dashboard link, or query to run
|
||||
- [ ] Do not include an alert in the runbook that has no specific on-call action — an alert that pages someone with no defined response path creates panic, not resolution
|
||||
- [ ] Do not leave the rollback command undocumented or untested — a rollback procedure that has never been run will fail when needed most
|
||||
- [ ] Do not list escalation contacts without phone numbers and Slack handles — email-only escalation paths are useless during a 3am incident
|
||||
- [ ] Do not write the runbook once and treat it as permanent — runbooks go stale after incidents; every incident must trigger a review of the relevant runbook entries
|
||||
|
||||
@@ -275,3 +275,11 @@ When a breach is detected, work through this checklist in order:
|
||||
- [ ] Budget breach response process names specific Slack channels and owners
|
||||
- [ ] Budget thresholds are anchored to baseline measurements or a justified target — not pulled from thin air
|
||||
- [ ] Per-journey targets are defined for critical user journeys, not just global averages
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not set budget thresholds without measuring a current baseline first — targets must be anchored to reality
|
||||
- [ ] Do not define global averages only — critical user journeys need individual budgets as they may diverge significantly
|
||||
- [ ] Do not omit CI enforcement — a performance budget that is not enforced in the build pipeline will not be respected
|
||||
- [ ] Do not leave the breach response process without named owners and escalation channels
|
||||
- [ ] Do not set budgets that apply only to one environment — production and staging targets should be documented separately if they differ
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: pr-description-writer
|
||||
description: "Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance. Optimised for Opus 4.7 and newer models."
|
||||
description: "Write a clear, structured pull request description from a git diff, branch summary, or commit list. Use when asked to write a PR description, draft a pull request, or document code changes. Produces a description with summary, motivation, changes made, testing steps, and reviewer guidance."
|
||||
---
|
||||
|
||||
# PR Description Writer Skill
|
||||
@@ -15,8 +15,10 @@ Ask for these if not provided:
|
||||
- **How to test it** (any specific steps a reviewer needs to verify it works)
|
||||
- **Risk level** (low / medium / high — affects how much reviewer guidance to include)
|
||||
- **PR type** (feature / bug fix / refactor / dependency upgrade / config change / hotfix)
|
||||
- **Target branch** (e.g. main / develop / release/2.4 — affects risk framing and reviewer guidance)
|
||||
- **Linked issue or ticket** (e.g. JIRA-1234, GitHub #567 — or "none")
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
### Title
|
||||
A clear, imperative-mood title under 72 characters:
|
||||
@@ -43,7 +45,7 @@ Bullet list of specific changes — one bullet per logical change, not per file:
|
||||
### Screenshots / Demo
|
||||
[If UI change: include before/after screenshots or a screen recording]
|
||||
[If API change: include example request/response]
|
||||
[If no visual change: this section can be omitted]
|
||||
[If no visual change and no API contract change: omit this section entirely — do not leave it as a placeholder]
|
||||
|
||||
### How to Test
|
||||
Step-by-step instructions a reviewer can follow:
|
||||
@@ -76,10 +78,19 @@ Flag anything that warrants extra attention:
|
||||
- [ ] Title is imperative mood and under 72 characters
|
||||
- [ ] Summary explains what AND why (not just what)
|
||||
- [ ] Changes list describes logical changes (not file-by-file changes)
|
||||
- [ ] Title starts with a valid type prefix (feat / fix / refactor / chore / deps / config / hotfix) and is under 72 characters
|
||||
- [ ] Testing steps are reproducible by someone unfamiliar with the code
|
||||
- [ ] Risk-appropriate reviewer guidance is included
|
||||
- [ ] For high-risk PRs, Reviewer Notes flags at least one specific area of concern or deliberate trade-off; for low-risk PRs, Reviewer Notes is either omitted or kept to one line
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a description that only restates what changed — explain why the change was made
|
||||
- [ ] Do not skip the testing steps — reviewers need to know how to verify the change works
|
||||
- [ ] Do not omit the reviewer notes for high-risk PRs — flag deliberate trade-offs and areas needing careful review
|
||||
- [ ] Do not describe implementation details that are obvious from the diff — add context that the diff cannot convey
|
||||
- [ ] Do not produce a single paragraph — structure with headers so reviewers can navigate to what they need
|
||||
|
||||
## Usage Examples
|
||||
- "Write a PR description for these changes" + [paste diff or description]
|
||||
- "Draft a pull request for [feature]"
|
||||
- "I need a PR description — here's what I changed"
|
||||
|
||||
@@ -397,3 +397,11 @@ Accept the current state and revisit the problem in [timeframe].
|
||||
- [ ] Open questions are assigned to named owners with deadlines — not floating
|
||||
- [ ] The RFC is written to be read by someone who was not in the planning conversations
|
||||
- [ ] Migration plan addresses all affected parties — users, API consumers, data — not just the technical steps
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write the RFC as a persuasion document — its purpose is to expose trade-offs, not sell a decision
|
||||
- [ ] Do not list alternatives without explicit rejection reasons — "we preferred the proposed solution" is not a reason
|
||||
- [ ] Do not leave the security implications section blank or write "N/A" without a reasoned explanation
|
||||
- [ ] Do not write open questions without assigning a named owner and a resolution deadline
|
||||
- [ ] Do not skip the "impact of not solving this" section — without it, reviewers cannot assess urgency
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: runbook-writer
|
||||
description: "Write an operational runbook for a service, incident type, or deployment procedure. Use when asked to write a runbook, create an ops guide, document an operational procedure, or prepare an incident response playbook. Produces a runbook with overview, prerequisites, step-by-step procedures, rollback steps, troubleshooting table, and escalation paths. Optimised for Opus 4.7 and newer models."
|
||||
description: "Write an operational runbook for a service, incident type, or deployment procedure. Use when asked to write a runbook, create an ops guide, document an operational procedure, or prepare an incident response playbook. Produces a runbook with overview, prerequisites, step-by-step procedures, rollback steps, troubleshooting table, and escalation paths."
|
||||
---
|
||||
|
||||
# Runbook Writer Skill
|
||||
@@ -15,14 +15,16 @@ Ask for these if not provided:
|
||||
- **System/service name and what it does** (brief description)
|
||||
- **Audience** (new on-call engineers / experienced SREs / DevOps team)
|
||||
- **Tech stack** (where relevant — e.g. Kubernetes, AWS RDS, Node.js)
|
||||
- **Monitoring tools** (e.g. Grafana, Datadog, CloudWatch, Splunk — used to name specific dashboards and alert links in the steps)
|
||||
- **Key environment details** (e.g. Kubernetes cluster name, AWS account/region, relevant namespaces or resource names — paste what's relevant for exact commands)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
---
|
||||
**Runbook:** [Runbook Title]
|
||||
**Service:** [Service Name]
|
||||
**Type:** [Deployment / Incident Response / Maintenance / DR]
|
||||
**Last Updated:** [Date]
|
||||
**Last Updated:** [Insert today's date in YYYY-MM-DD format]
|
||||
**Owner:** [Team or person]
|
||||
**Severity:** [P1 / P2 / P3 — if incident-type]
|
||||
|
||||
@@ -133,12 +135,21 @@ After completing the runbook:
|
||||
- [ ] Expected output is specified for each step so engineer knows if it worked
|
||||
- [ ] Failure path is explicit for each step (not "if it fails, investigate")
|
||||
- [ ] Rollback procedure is complete and independently testable
|
||||
- [ ] Escalation paths name specific contacts, not just team names
|
||||
- [ ] Escalation table has no cells containing only "[Team name]" — every row must either have a real contact or be explicitly flagged as [FILL IN: on-call rotation link]
|
||||
- [ ] Rollback section contains at least one concrete command (not left as "[rollback command]" placeholder)
|
||||
- [ ] Runbook can be followed by someone who has never touched this system
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Usage Examples
|
||||
- "Write a runbook for [service] deployment"
|
||||
- "Create an incident response runbook for [alert type]"
|
||||
- "I need a runbook for [procedure]"
|
||||
- "Document the operational procedure for [X]"
|
||||
- "Write an ops playbook for [scenario]"
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write steps as vague actions like "run the deploy script" — every step must include the exact command
|
||||
- [ ] Do not leave the rollback section as a placeholder — a runbook without a tested rollback procedure is incomplete and dangerous
|
||||
- [ ] Do not omit expected output for each step — without it, the on-call engineer cannot tell if the step succeeded
|
||||
- [ ] Do not write escalation contacts as "[Team name]" — every escalation row must have a real contact or an explicit flag to fill in
|
||||
- [ ] Do not assume the reader knows the system — write for someone who has never touched it before
|
||||
|
||||
@@ -251,3 +251,11 @@ Accepted risks are threats the team has decided not to mitigate right now. Every
|
||||
- [ ] STRIDE analysis covers all major components — not just the API layer
|
||||
- [ ] Mitigation actions are specific enough to become a ticket (not "improve security")
|
||||
- [ ] The ASCII trust boundary diagram matches the architecture description provided
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not restrict STRIDE analysis to only the API layer — threats exist at every component including the database and internal services
|
||||
- [ ] Do not leave mitigations as vague directives like "improve security" — every mitigation must be specific enough to become a ticket
|
||||
- [ ] Do not accept risks without a named owner and a review date — unowned accepted risks are not managed risks
|
||||
- [ ] Do not write a threat model that covers only theoretical threats — prioritise by likelihood and impact using the risk register
|
||||
- [ ] Do not omit the asset register — without knowing what is being protected, the STRIDE analysis has no anchor
|
||||
|
||||
@@ -290,3 +290,11 @@ Document limitations honestly — this section prevents other teams from buildin
|
||||
- [ ] All runbook links are live — not broken references or TODO placeholders
|
||||
- [ ] Data classification includes retention period and encryption status — not just sensitivity level
|
||||
- [ ] The entry has been reviewed by at least one consumer team to confirm it matches their experience of the service
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write aspirational SLO targets — targets must be agreed with stakeholders and based on historical data, not copied from a template
|
||||
- [ ] Do not leave runbook links as TODO placeholders — broken or missing links make the catalog entry worse than useless during an incident
|
||||
- [ ] Do not omit the "Known Limitations" section to make the service look better — undisclosed limitations cause incorrect integrations and downstream incidents
|
||||
- [ ] Do not list API error codes without testing them — aspirational error documentation misleads consumers
|
||||
- [ ] Do not write the "What It Does" section with jargon — a new engineer from another team must understand it in under 2 minutes
|
||||
|
||||
@@ -229,3 +229,11 @@ This policy defines what to do with the error budget — both when it's healthy
|
||||
- [ ] Error budget policy has clear triggers and clear actions — not "discuss as a team"
|
||||
- [ ] Burn rate alerts have different windows to catch both fast burns and slow burns
|
||||
- [ ] Exclusions are documented so they don't silently inflate the SLO number
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not set SLO targets at 100% — this discourages feature development and does not reflect how users experience reliability
|
||||
- [ ] Do not measure internal system metrics as SLIs — SLIs must reflect what users directly experience, not internal CPU or memory
|
||||
- [ ] Do not write an error budget policy with vague triggers — "discuss as a team" is not an actionable policy; triggers must be specific percentages
|
||||
- [ ] Do not base targets on aspirational round numbers — always derive from historical baseline data
|
||||
- [ ] Do not configure only one burn-rate alert window — a single window misses both fast burns and slow burns that exhaust the budget quietly
|
||||
|
||||
@@ -261,3 +261,11 @@ If cycle time data was not provided: *Cycle time data was not included in this a
|
||||
- [ ] Next-sprint capacity forecast uses historical average as the baseline and deducts specific known reducers
|
||||
- [ ] Health diagnosis table uses Red/Yellow/Green with evidence cited in the Evidence column — no unsupported scores
|
||||
- [ ] If metrics are missing (cycle time, blocker log), the report explicitly calls them out as recommended additions
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not generate the velocity chart from placeholder data — it must reflect the actual sprint data provided
|
||||
- [ ] Do not diagnose trend direction without computing trailing vs leading averages — "it looks like it's declining" is not a diagnosis
|
||||
- [ ] Do not list carry-over as a generic observation — identify root cause categories with counts for the analysis to be actionable
|
||||
- [ ] Do not produce recommendations without a named owner, a start date, and a measurable target
|
||||
- [ ] Do not score health dimensions without citing evidence in the Evidence column — unsupported Red/Yellow/Green scores are not credible
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: system-design-interview
|
||||
description: "Structure a complete system design answer for interview questions or real architecture sessions. Use when asked to design a system, answer a system design interview question, or architect a solution at scale. Produces a structured answer covering requirements, capacity estimates, high-level design, component deep-dives, trade-offs, and follow-up considerations. Optimised for Opus 4.7 and newer models."
|
||||
description: "Structure a complete system design answer for interview questions or real architecture sessions. Use when asked to design a system, answer a system design interview question, or architect a solution at scale. Produces a structured answer covering requirements, capacity estimates, high-level design, component deep-dives, trade-offs, and follow-up considerations."
|
||||
---
|
||||
|
||||
# System Design Interview Skill
|
||||
@@ -14,8 +14,10 @@ Ask for these if not provided:
|
||||
- **Scope** (interview prep / real architecture decision / practice run)
|
||||
- **Scale target** (rough numbers: DAU, requests/sec, data volume — or "assume typical web scale")
|
||||
- **Constraints or priorities** (e.g. prioritise availability over consistency, minimise cost, low-latency reads)
|
||||
- **Time available** (interview context only: 30 / 45 / 60 minutes — skip for real architecture sessions)
|
||||
- **Emphasis** (optional — any area to go deeper on, e.g. "focus on the DB design" or "spend more time on scaling")
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
### 1. Clarifying Questions
|
||||
Before designing, list 4–6 questions that would change the design. Examples:
|
||||
@@ -62,12 +64,7 @@ Then proceed with stated assumptions if answering an interview question.
|
||||
|
||||
### 5. High-Level Architecture
|
||||
|
||||
```
|
||||
[Client] → [CDN/Edge] → [Load Balancer] → [API Servers] → [Cache] → [DB]
|
||||
→ [Message Queue] → [Workers]
|
||||
```
|
||||
|
||||
Describe each layer in 1–2 sentences explaining its role and technology choice.
|
||||
Draw an ASCII diagram specific to this system. Do not default to the client→CDN→LB→API→Cache→DB template unless it genuinely applies. Label each component with the specific technology chosen (e.g. "Kafka" not "Message Queue", "PostgreSQL" not "DB"). Describe each component in 1–2 sentences explaining its role and why that technology was chosen.
|
||||
|
||||
### 6. Component Deep-Dive
|
||||
|
||||
@@ -122,12 +119,21 @@ Things to tackle in production but out of scope for this design session:
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Clarifying questions are design-changing (not generic filler)
|
||||
- [ ] Capacity estimates use real numbers (not just "it scales")
|
||||
- [ ] Capacity estimates show the arithmetic: DAU → requests/day → requests/sec → storage per record → total storage, so the numbers can be sanity-checked
|
||||
- [ ] Every row in the Trade-offs table has a non-empty Trade-off column (no rows where the trade-off is blank or says "none")
|
||||
- [ ] At least 2 component deep-dives with technology choices justified
|
||||
- [ ] Trade-offs section is honest (not just benefits of chosen approach)
|
||||
- [ ] Data flow is described end-to-end for the critical path
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not jump to solutions before clarifying requirements — always establish functional and non-functional requirements first
|
||||
- [ ] Do not present a design without discussing trade-offs — every architecture decision has costs and benefits that must be acknowledged
|
||||
- [ ] Do not use vague capacity estimates — show the actual calculation (QPS, storage bytes, bandwidth) not just "this handles scale"
|
||||
- [ ] Do not design for unlimited scale by default — match the design to the requirements stated
|
||||
- [ ] Do not skip the data model — a system design without entity definitions and data flow is incomplete
|
||||
|
||||
## Usage Examples
|
||||
- "Help me answer a system design interview: [question]"
|
||||
- "Design [system] for a system design interview"
|
||||
- "How would I architect [system] at scale?"
|
||||
|
||||
@@ -288,3 +288,11 @@ This log records every ring movement since the radar's first edition. Use it to
|
||||
- [ ] Maintenance process includes: nomination channel, review cadence, who decides, and ring-change criteria
|
||||
- [ ] Technologies identified as "strategic bets" in the inputs are placed in Adopt (if proven) or Trial (if being rolled out)
|
||||
- [ ] Technologies identified for deprecation are in Hold with a rationale that references the replacement
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not place a technology in Adopt without evidence it is proven at the team's scale — aspirational placements mislead engineers
|
||||
- [ ] Do not add a blip without a written rationale paragraph — table rows without context are unusable
|
||||
- [ ] Do not create a Hold entry without specifying a concrete migration path or target technology
|
||||
- [ ] Do not skip the maintenance process — a radar with no process for updates becomes stale within two quarters
|
||||
- [ ] Do not omit ring definitions — engineers need to know what they should do in response to each ring, not just what the ring means
|
||||
|
||||
@@ -258,3 +258,11 @@ Items where the cost of remediation currently exceeds the business value, accept
|
||||
- [ ] Accepted/deferred items have a review date and a named owner — no permanently deferred items
|
||||
- [ ] The register distinguishes between debt (deliberate or accumulated shortcuts) and bugs (unintended defects)
|
||||
- [ ] Items are closed as resolved only when acceptance criteria are met — not when the PR is merged
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not score debt items arbitrarily — priority scores must be calculated using the documented formula
|
||||
- [ ] Do not conflate technical debt (deliberate shortcuts) with bugs (unintended defects) — they require different remediation strategies
|
||||
- [ ] Do not underrate security and dependency items because they feel abstract — score based on actual business impact
|
||||
- [ ] Do not create "permanently deferred" items — every accepted item must have a review date and named owner
|
||||
- [ ] Do not include resolution plans that are vague descriptions — each plan must have specific, ticketable steps
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: test-strategy-doc
|
||||
description: "Write a test strategy document from a feature spec, PRD, or system description. Use when asked to create a test plan, write a test strategy, define QA approach, or plan testing for a feature or release. Produces a complete test strategy with scope, risk assessment, test types, coverage targets, and a prioritised test case outline. Optimised for Opus 4.7 and newer models."
|
||||
description: "Write a test strategy document from a feature spec, PRD, or system description. Use when asked to create a test plan, write a test strategy, define QA approach, or plan testing for a feature or release. Produces a complete test strategy with scope, risk assessment, test types, coverage targets, and a prioritised test case outline."
|
||||
---
|
||||
|
||||
# Test Strategy Document Skill
|
||||
@@ -11,12 +11,14 @@ Produces a complete test strategy from a feature spec, PRD, or system descriptio
|
||||
|
||||
Ask for these if not provided:
|
||||
- **Feature or system being tested** (paste a spec, PRD, or describe it in plain English)
|
||||
- **Tech stack** (language, framework, testing tools already in use if known)
|
||||
- **Tech stack** (language and framework — e.g. TypeScript + React, Python + FastAPI)
|
||||
- **Existing test coverage** (e.g. "we have unit tests but no E2E tests", "we use Jest + Playwright already", or "starting from scratch")
|
||||
- **Deployment cadence** (e.g. continuous deployment / weekly releases / quarterly — affects what must be automated vs. manual)
|
||||
- **Risk level** (low / medium / high / critical — affects depth and coverage requirements)
|
||||
- **Timeline** (when does this need to ship — affects prioritisation)
|
||||
- **Team context** (who is doing the testing — developers / dedicated QA / both)
|
||||
|
||||
## Output Structure
|
||||
## Output Format
|
||||
|
||||
### 1. Test Scope
|
||||
|
||||
@@ -66,7 +68,7 @@ Identify the highest-risk areas first — these drive depth and coverage:
|
||||
- **Tools:** [e.g. Playwright, Cypress, Selenium]
|
||||
- **Focus areas:** [The 3–5 most critical user flows]
|
||||
|
||||
**Performance Tests** *(include only if risk is medium+)*
|
||||
**Performance Tests** *(include if any row in the Risk Assessment table has performance as a risk factor, regardless of overall risk level)*
|
||||
- **What:** Load, stress, or latency testing
|
||||
- **Targets:** [Specific numbers — e.g. 200 req/sec at p95 < 200ms]
|
||||
- **Tools:** [e.g. k6, Locust, JMeter]
|
||||
@@ -115,11 +117,20 @@ Testing is complete when:
|
||||
|
||||
## Quality Checks
|
||||
- [ ] Risk table is populated and drives test priority (not filled in generically)
|
||||
- [ ] P0 test cases cover the highest-risk paths specifically
|
||||
- [ ] Every "P0 — exhaustive" row in the Risk Assessment table has at least one corresponding P0 test case
|
||||
- [ ] "Out of scope" section names at least one explicit exclusion (not left blank)
|
||||
- [ ] Each test type names a concrete tool (not "some testing framework")
|
||||
- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
|
||||
|
||||
## Example Trigger Phrases
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a test strategy without a risk table that drives test priority — generic coverage targets are not a strategy
|
||||
- [ ] Do not leave the "out of scope" section blank — every test strategy must explicitly name what is not being tested and why
|
||||
- [ ] Do not specify test types without naming a concrete tool for each — "some testing framework" is not actionable
|
||||
- [ ] Do not define a Definition of Done that is not measurable — "QA is happy" is not a completion criterion
|
||||
- [ ] Do not create P0 risk areas without corresponding P0 test cases — risk rating must map to test coverage
|
||||
|
||||
## Usage Examples
|
||||
- "Write a test strategy for [feature]" + [paste spec or PRD]
|
||||
- "Create a test plan for [system]"
|
||||
- "How should we test [feature]?"
|
||||
|
||||
@@ -84,6 +84,13 @@ Position competitors on two key dimensions relevant to the market:
|
||||
**Medium-term (3-12 months):**
|
||||
1. [Action] — [Rationale]
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not present competitor feature claims as facts without citing a source or flagging them as assumptions — outdated or incorrect feature data misleads sales and product decisions
|
||||
- [ ] Do not build a competitive analysis that only covers features — pricing, messaging, go-to-market motion, and who they hire for are equally strategic signals
|
||||
- [ ] Do not treat all buyers as identical — the same product may win against Competitor A in the enterprise segment and lose in SMB; segment-specific win/loss matters
|
||||
- [ ] Do not soften weaknesses and threats in the SWOT to avoid internal discomfort — an honest SWOT is only useful if the negatives are real
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] All competitor claims cite a source or are flagged as assumptions
|
||||
|
||||
@@ -110,6 +110,14 @@ Instructions for applying the redline:
|
||||
- [ ] Pattern issues identified separately from individual changes
|
||||
- [ ] Application instructions match the target platform
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not paraphrase original text when creating tracked deletions — the original text must be preserved exactly, character for character, or the tracked change cannot be reviewed against source
|
||||
- [ ] Do not mix substantive changes with stylistic edits in the same section — reviewers need to approve substantive changes at a different threshold than copy edits
|
||||
- [ ] Do not write margin comments as meta-commentary about the review process ("This section needs work") — comments must be actionable instructions the author can act on
|
||||
- [ ] Do not flag every imperfect sentence as a change — over-redlining trains authors to accept changes without reading, which defeats the purpose of tracked review
|
||||
- [ ] Do not produce a redline without a summary of top-level changes — reviewers read the summary first and use it to decide which changes to scrutinise in detail
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Redline this contract"
|
||||
- "Create tracked changes for this document"
|
||||
|
||||
@@ -7,6 +7,14 @@ description: "Structure and format meeting notes following PM best practices. Us
|
||||
|
||||
This skill structures meeting notes to maximize value and ensure follow-through.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Meeting title and date**
|
||||
- **Attendees** (names and roles)
|
||||
- **Raw notes or transcript** (paste discussion notes, a transcript, or describe what was discussed)
|
||||
- **Meeting type** (1:1 / sprint planning / product review / stakeholder sync / other) — determines which template to use
|
||||
|
||||
## Standard Meeting Notes Template
|
||||
|
||||
### Meeting Header
|
||||
@@ -251,6 +259,14 @@ Template additions:
|
||||
- [ ] Open questions have an owner and a "by when"
|
||||
- [ ] No verbatim transcripts — synthesis only
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not assign action items to "the team" or "everyone" — every action item must have exactly one named owner or it will not be completed
|
||||
- [ ] Do not capture verbatim transcript content — meeting notes record decisions and commitments, not the full conversational path to get there
|
||||
- [ ] Do not omit the context for decisions — a decision without its rationale is useless when someone asks "why did we do that?" six months later
|
||||
- [ ] Do not leave open questions without an owner and deadline — an unanswered question with no follow-up assigned is a blocked decision
|
||||
- [ ] Do not delay sending notes beyond 2 hours after the meeting — notes sent the next day miss the window when action item owners can act on commitments while fresh
|
||||
|
||||
## Notes Distribution
|
||||
|
||||
**Subject Line Format**: "[Meeting Type] Notes - [Date] - [Key Topic]"
|
||||
|
||||
@@ -110,6 +110,14 @@ Format: "As a [user type], I want to [action] so that [benefit]"
|
||||
- [ ] Open questions are listed explicitly
|
||||
- [ ] Implementation plan distinguishes MVP from future phases
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write requirements from the company's perspective — every requirement must trace back to a user need
|
||||
- [ ] Do not include vague requirements like "the system should be fast" — every requirement must be testable
|
||||
- [ ] Do not conflate MVP with future phases — be explicit about what is and is not in scope for the first release
|
||||
- [ ] Do not leave success metrics as percentages without baselines — specify the current state and the target
|
||||
- [ ] Do not skip open questions — unresolved assumptions are risks; surfacing them is the PM's job
|
||||
|
||||
## Example PRD Opening
|
||||
|
||||
```
|
||||
|
||||
@@ -234,3 +234,11 @@ Only include issues that matter at executive level.
|
||||
- [ ] Every risk has a mitigation and a "help needed" flag if stakeholder action is required
|
||||
- [ ] Decisions needed have specific options and a clear recommendation
|
||||
- [ ] Total length is under 1 page / 2 minutes reading time
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not bury the status assessment at the bottom — BLUF means the most important information comes first
|
||||
- [ ] Do not report metrics without a target or prior-period comparison — raw numbers without context are not useful
|
||||
- [ ] Do not list risks without mitigation actions and clear flags for stakeholder help needed
|
||||
- [ ] Do not write decisions needed as questions without providing a clear recommendation — executives need options, not open-ended questions
|
||||
- [ ] Do not allow the update to exceed one page — if it requires more, the message needs editing, not expanding
|
||||
|
||||
@@ -123,21 +123,21 @@ Research gaps identified:
|
||||
- Quantify when possible ("7 out of 10 users...")
|
||||
- Connect themes to business objectives
|
||||
|
||||
## Quality Standards
|
||||
## Quality Checks
|
||||
|
||||
✅ **Good Synthesis:**
|
||||
- Identifies patterns, not just individual responses
|
||||
- Connects insights to product decisions
|
||||
- Includes supporting evidence for each claim
|
||||
- Separates observations from interpretations
|
||||
- Prioritizes findings by impact
|
||||
- [ ] Themes identify patterns across multiple participants, not individual responses
|
||||
- [ ] Insights connect to specific product decisions, not just observations
|
||||
- [ ] Each claim includes supporting evidence (quotes, counts, or examples)
|
||||
- [ ] Observations and interpretations are clearly separated
|
||||
- [ ] Findings are prioritised by impact, not just listed
|
||||
|
||||
❌ **Poor Synthesis:**
|
||||
- Lists every individual comment
|
||||
- Lacks evidence or examples
|
||||
- Makes unsupported leaps
|
||||
- Focuses on solutions before understanding problems
|
||||
- Ignores contradictory data
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not list every individual comment — synthesis must identify patterns across participants
|
||||
- [ ] Do not make interpretive leaps without supporting evidence from the data
|
||||
- [ ] Do not focus on feature requests before understanding the underlying problem — always identify the job-to-be-done first
|
||||
- [ ] Do not ignore contradictory data — conflicting findings must be surfaced and noted
|
||||
- [ ] Do not present results without quantifying prevalence — state how many participants held each view
|
||||
|
||||
## Example Theme
|
||||
|
||||
|
||||
@@ -56,6 +56,14 @@ Touch targets, screen reader labels, focus order, colour contrast, motion prefer
|
||||
- [ ] Empty states specified
|
||||
- [ ] Edge cases listed as actionable questions
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not annotate only the happy path — error states, loading states, and empty states must all be documented
|
||||
- [ ] Do not use vague spacing descriptions like "some padding" — specify exact pixel values or token names
|
||||
- [ ] Do not skip accessibility annotations — focus order, ARIA labels, and colour contrast ratios must be included
|
||||
- [ ] Do not leave interaction behaviour undescribed — every interactive element needs a documented response
|
||||
- [ ] Do not produce annotations without edge cases — developers need to know what happens at boundaries
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write dev annotations for this Figma screen"
|
||||
- "Create developer handoff notes for [screen/component]"
|
||||
|
||||
@@ -66,6 +66,14 @@ Naming convention to enforce:
|
||||
- [ ] Fix plan is ordered by impact-to-effort ratio
|
||||
- [ ] Variant completeness covers all interactive states
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not flag naming issues without providing a specific, consistent naming convention to adopt
|
||||
- [ ] Do not audit only visual consistency — also check for missing interactive states and accessibility compliance
|
||||
- [ ] Do not list all issues at equal priority — group by impact (Critical / Major / Minor) so the fix plan is actionable
|
||||
- [ ] Do not omit variant completeness — every interactive component must cover all required states
|
||||
- [ ] Do not leave coverage gaps without recommending specific missing components to add
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Audit my Figma component library"
|
||||
- "Review our design system for consistency issues"
|
||||
|
||||
@@ -60,6 +60,14 @@ Feature, PM, Designer, Platform, Design due, Dev handoff dates.
|
||||
- [ ] Constraints include accessibility requirements
|
||||
- [ ] Open questions have owners
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not write a design brief that describes the solution — the brief must describe the problem and constraints, not the design answer
|
||||
- [ ] Do not skip the success criteria — designers need to know what "done" looks like before starting
|
||||
- [ ] Do not omit existing components to reuse — briefs that ignore the design system lead to inconsistent implementations
|
||||
- [ ] Do not leave open questions unresolved — escalate them before design work starts, not during it
|
||||
- [ ] Do not confuse requirements with design instructions — the brief defines what, not how
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Write a design brief for [feature]"
|
||||
- "Turn this PRD into a Figma design brief"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-critique-pm
|
||||
description: "Run a PM-perspective design critique focused on product outcomes, user goals, and business requirements — not aesthetics. Use when asked for a PM design critique, a product review of a design, feedback on a Figma design from a product perspective, or when you want to critique a design without being a designer. Produces structured outcome-based feedback tied to user goals and business metrics."
|
||||
description: "Runs a PM-perspective design critique focused on product outcomes and user goals, not aesthetics. Use when asked for a PM design critique, a product review of a Figma design, or feedback from a product perspective without needing to be a designer. Produces structured outcome-based feedback tied to user goals, business metrics, and requirement coverage."
|
||||
---
|
||||
|
||||
# Figma Design Critique — PM Perspective Skill
|
||||
@@ -68,6 +68,14 @@ Approve / Approve with changes (list) / Revise and re-review (one focus area onl
|
||||
- [ ] PM recommendation is explicit
|
||||
- [ ] Evidence basis stated honestly
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not critique visual aesthetics — PM feedback must focus on product outcomes, user goals, and business requirements
|
||||
- [ ] Do not provide feedback without stating the evidence basis — distinguish between observed design facts and assumed user behaviour
|
||||
- [ ] Do not give vague feedback like "the flow feels confusing" — every concern must reference a specific screen state or interaction
|
||||
- [ ] Do not ignore what is working — balanced critique includes explicit acknowledgment of design decisions that are well-executed
|
||||
- [ ] Do not critique without knowing the design constraints — always ask about technical, time, or resource limitations before judging decisions
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Give me a PM critique of this design"
|
||||
- "Review this design from a product perspective"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-qa
|
||||
description: "Run a pre-handoff QA checklist on any Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, review a design before engineering, or validate a Figma file is ready to build. Produces a structured QA checklist covering file hygiene, component usage, accessibility, and handoff readiness with pass/fail status. Optimised for Opus 4.7 and newer models."
|
||||
description: "Runs a pre-handoff QA checklist on a Figma design before it goes to engineering. Use when asked to QA a Figma design, do a pre-handoff check, or validate a Figma file is ready to build. Produces a structured QA report covering file hygiene, component usage, accessibility, and handoff readiness with explicit pass/fail status per item. Optimised for Opus 4.7 and newer models."
|
||||
---
|
||||
|
||||
# Figma Design QA Skill
|
||||
@@ -81,6 +81,14 @@ Status, signed off by, date.
|
||||
- [ ] Blocking issues separated from minor ones
|
||||
- [ ] Handoff decision is explicit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not produce a partial QA — every checklist category must be evaluated, not just the ones that are obviously problematic
|
||||
- [ ] Do not leave the handoff decision ambiguous — the output must explicitly state pass, pass with conditions, or fail
|
||||
- [ ] Do not skip accessibility checks — colour contrast, tap target size, and screen reader labels are required, not optional
|
||||
- [ ] Do not report issues without specifying which screen or component they appear on
|
||||
- [ ] Do not approve a design if any component is detached from the library without a documented reason
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "QA this Figma design before handoff"
|
||||
- "Run a pre-handoff check on [feature] design"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: figma-design-review
|
||||
description: "Run a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, do a PM design review, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and explicit approval status."
|
||||
description: "Runs a structured PM design review against product requirements. Use when asked to review a Figma design, check a design against requirements, or assess whether a design meets the product spec. Produces a requirements coverage check, UX concerns, open questions, and an explicit approval status — approved, approved with conditions, or not approved."
|
||||
---
|
||||
|
||||
# Figma Design Review Skill
|
||||
@@ -60,6 +60,14 @@ Approved / Approved with changes (list) / Needs revision (focus area + next revi
|
||||
- [ ] Open questions have owners
|
||||
- [ ] Approval status is explicit
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not review a design without a list of requirements to check against — always ask for the PRD, design brief, or acceptance criteria first
|
||||
- [ ] Do not give a vague approval status — the decision must be explicitly "approved", "approved with conditions", or "not approved"
|
||||
- [ ] Do not conflate requirements gaps with UX concerns — track them separately so engineers and designers can act independently
|
||||
- [ ] Do not raise concerns without suggesting what information is needed to resolve them
|
||||
- [ ] Do not skip open questions — unresolved assumptions at review time become bugs after engineering handoff
|
||||
|
||||
## Example Trigger Phrases
|
||||
- "Review this Figma design against the requirements"
|
||||
- "Do a PM design review for [feature]"
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user