feat: v10.0.0 — 8 new skills across Customer Success and Engineering (500-star milestone)

Two star milestones shipped together: Customer Success bundle (pm-cs) — 250-star milestone: - cs-health-scorecard: weighted RAG health score across 5 dimensions with renewal forecast - qbr-deck: slide-by-slide QBR structure with value narrative and mutual commitments - cs-escalation-brief: 4-level escalation framework with root cause, impact, and decision required - churn-analysis: voluntary/unavoidable churn split, early warning signals, prioritised interventions Engineering expansion (pm-engineering) — 500-star milestone: - cicd-playbook: full pipeline playbook from build through post-deploy checks and rollback - slo-error-budget: SLI definitions, burn rate alerts, and error budget policy - developer-onboarding-doc: first-week guide covering architecture, setup, testing, and contacts - oncall-runbook: per-alert response procedures, escalation matrix, and handoff template Also: - Added pm-cs plugin to marketplace.json - Updated pm-engineering plugin.json to v3.0.0 (14 skills) - Updated marketplace.json to v10.0.0 (114 skills, 23 bundles, 16 professions) - README updated with new CS section, corrected skill numbering (106 → 114) - Added bug report link to Contributing section - Star milestones updated to show 250 and 500 as unlocked
Update README with new plugin installation commands
2026-05-17 10:55:58 +01:00 · 2026-05-08 12:40:20 +05:30 · 2026-05-08 03:11:28 +05:30 · 2026-05-08 03:08:07 +05:30 · 2026-05-08 03:06:32 +05:30 · 2026-05-07 22:30:34 +01:00
88 changed files with 10542 additions and 100 deletions
@@ -1,8 +1,8 @@
 {
  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
  "name": "pm-claude-skills",
-  "version": "7.0.0",
-  "description": "106 Claude Skills across 15 professions — product management, engineering, legal, finance, HR, sales, design, Figma, operations, research, and more. Includes 6 new engineering skills: debugging, PR descriptions, system design, changelogs, test strategy, and runbooks.",
+  "version": "10.0.0",
+  "description": "114 Claude Skills + 4 agent templates across 23 plugin bundles covering 16 professions — product management, engineering, customer success, legal, finance, HR, sales, design, Figma, marketing, and more. Building blocks for the Anthropic agent template architecture.",
  "owner": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
@@ -82,12 +82,20 @@
    },
    {
      "name": "pm-engineering",
-      "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer. 10 structured skills for engineering teams, SREs, and technical PMs.",
-      "version": "2.0.0",
+      "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. 14 structured skills for engineering teams, SREs, and technical PMs.",
+      "version": "3.0.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",
+      "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.",
@@ -1,17 +1,17 @@
-# 🧠 Claude Skills Library — 106 Skills for Every Profession
+# 🧠 Claude Skills Library — 114 Skills for Every Profession

 [![Stars](https://img.shields.io/github/stars/mohitagw15856/pm-claude-skills?style=social)](https://github.com/mohitagw15856/pm-claude-skills/stargazers)
-[![Skills](https://img.shields.io/badge/skills-106-blue)](https://github.com/mohitagw15856/pm-claude-skills)
-[![Version](https://img.shields.io/badge/version-7.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
+[![Skills](https://img.shields.io/badge/skills-114-blue)](https://github.com/mohitagw15856/pm-claude-skills)
+[![Version](https://img.shields.io/badge/version-10.0.0-brightgreen)](https://github.com/mohitagw15856/pm-claude-skills/releases)
 [![Install](https://img.shields.io/badge/Install%20in%20Claude%20Code-2%20minutes-orange)](https://github.com/mohitagw15856/pm-claude-skills#-quick-install-2-minutes)
 [![License](https://img.shields.io/badge/license-MIT-lightgrey)](LICENSE)
+[![Sponsor](https://img.shields.io/badge/sponsor-❤️-ff69b4)](https://github.com/sponsors/mohitagw15856)

-> **Save 8–10 hours per week across 15 professions. Install in 2 minutes. Now with 106 skills including 6 new engineering skills.**
+> **114 Claude Skills + 4 agent templates across 16 professions. Save 8-10 hours per week.**

-A community-built library of Claude Skills covering product management, engineering, marketing, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, education, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.
-
-**🆕 Latest release (v7.0.0):** 6 new engineering skills added — Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, and Runbook Writer. The `pm-engineering` bundle now has 10 skills.
+A community-built library of Claude Skills covering product management, engineering, customer success, marketing, data, design, Figma, leadership, legal, finance, HR, sales, operations, research, education, and more. Each skill is a structured SKILL.md file that teaches Claude how to produce professional-grade outputs for your specific workflows.

+**🆕 Latest release (v10.0.0):** The library now includes 114 skills + 4 working agent templates. Two star milestones unlocked at once — 250 stars brought 4 Customer Success skills, 500 stars brought 4 more Engineering skills.
 ---

 ## 🚀 Quick Install (2 minutes)
@@ -20,20 +20,31 @@ In Claude Code, run:

 /plugin marketplace add mohitagw15856/pm-claude-skills

-
 Or install by profession:

 claude plugin install pm-essentials@pm-claude-skills     # Core PM + Word tracked changes
+
 claude plugin install pm-delivery@pm-claude-skills       # Delivery + PowerPoint auditor
-claude plugin install pm-engineering@pm-claude-skills    # Engineering + DevOps (10 skills) 🆕
+
+claude plugin install pm-engineering@pm-claude-skills    # Engineering (14 skills) 🆕
+claude plugin install pm-cs@pm-claude-skills             # Customer Success 🆕
+
 claude plugin install pm-data@pm-claude-skills           # Data + chart data extractor
+
 claude plugin install pm-legal@pm-claude-skills          # Legal
+
 claude plugin install pm-finance@pm-claude-skills        # Finance
+
 claude plugin install pm-hr@pm-claude-skills             # HR
+
 claude plugin install pm-sales@pm-claude-skills          # Sales
+
 claude plugin install pm-operations@pm-claude-skills     # Operations
+
 claude plugin install pm-research@pm-claude-skills       # Research & Healthcare
+
 claude plugin install pm-cross@pm-claude-skills          # Cross-profession
+
 claude plugin install pm-figma@pm-claude-skills          # Figma


@@ -43,7 +54,6 @@ git clone https://github.com/mohitagw15856/pm-claude-skills.git ~/pm-claude-skil
 mkdir -p ~/.claude/skills
 ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/

-
 ---

 ## 🎬 See It in Action
@@ -58,9 +68,111 @@ ln -s ~/pm-claude-skills/skills/* ~/.claude/skills/

 ---

-## 🆕 What's New in v7.0.0 — Engineering Skills Expansion
+## 🤖 Building Blocks for Agent Templates
+
+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.**
+
+### What is an agent template?
+
+An agent template packages three things into one runnable workflow:
+
+| Component | What it is | Example from this library |
+|---|---|---|
+| **Skills** | Markdown files that teach Claude how to produce structured professional outputs | `sprint-planning`, `contract-review`, `investor-update` |
+| **Connectors** | Governed access to your team's data sources | Linear, Jira, Slack, Google Drive, Notion |
+| **Subagents** | Focused Claude models for sub-tasks within the larger workflow | Capacity analyst, risk scorer, comparables selector |
+
+A skill alone gives Claude a structured output format. An agent template gives Claude a complete workflow — pulling data, running specialised analysis, producing the output, and routing it where it needs to go.
+
+### How to use this library to build your own agent template
+
+Pick a recurring workflow on your team. Identify which existing skills cover the structured outputs that workflow needs. Add the connectors that let Claude reach the data. Add subagents for the analytical sub-tasks. That's the template.
+
+Examples of agent templates this library supports:
+
+| Template | Skills used | Connectors needed | Subagents |
+|---|---|---|---|
+| **PM Sprint Agent** | sprint-planning, sprint-brief, retro, project-status-report | Linear or Jira, Slack | Capacity analyst, risk scorer |
+| **Legal Contract Review Agent** | contract-review, nda-analyser, compliance-checklist | Google Drive or SharePoint | Clause-by-clause risk scorer |
+| **PM Discovery Agent** | discovery-interview-guide, user-interview-synthesis, assumption-mapper | Granola or Otter, Notion | Theme synthesiser |
+| **Sales Pursuit Agent** | sales-battlecard, discovery-call-prep, proposal-writer, account-plan | Salesforce or HubSpot, Gong | Competitive intel analyst |
+| **HR Onboarding Agent** | onboarding-plan, job-description-writer, change-management-plan | Workday or BambooHR, Slack | First-week scheduler |
+| **Finance Board Pack Agent** | investor-update, board-deck-narrative, financial-model-narrative | NetSuite or Xero, Google Drive | KPI variance analyst |
+| **Marketing Launch Agent** | go-to-market, content-calendar, email-campaign, media-pitch | HubSpot, Notion | Channel strategist |
+
+
+### Available agent templates
+
+The pm-claude-skills library now includes four working agent templates, each built from existing skills in this library combined with subagents and connectors. All four follow the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026.
+
+| Template | What it does | Skills used | Connectors | Time saved |
+|---|---|---|---|---|
+| **[PM Sprint Agent](./templates/pm-sprint-agent/)** | End-to-end sprint planning — pulls backlog, calculates capacity, drafts plan, scores risks | sprint-planning, sprint-brief | Linear, Jira | 90 min → 90 sec |
+| **[PM Discovery Agent](./templates/pm-discovery-agent/)** | Customer discovery synthesis — reads interview notes, finds themes, scores assumption confidence | user-interview-synthesis, job-story-mapper | Notion, Google Drive | 1 day → 5 min |
+| **[PM Stakeholder Comms Agent](./templates/pm-stakeholder-comms-agent/)** | Audience-tailored stakeholder updates — exec, investor, cross-functional, or board | executive-update, investor-update, stakeholder-update, board-deck-narrative | Linear, Jira, Google Drive | 90 min → 1 min |
+| **[PM Launch Agent](./templates/pm-launch-agent/)** | End-to-end launch coordination — content for every channel, calendar, metrics, checklist | go-to-market, content-calendar, media-pitch, email-campaign, launch-checklist | Notion (optional) | 4-6 hours → 3 min |
+
+Each template includes:
+- Working orchestration script
+- Two or more focused subagents
+- Connector configurations with documented setup
+- Working examples (input + output)
+- Smoke test for verifying installations
+
+### How to install a template
+
+All templates are part of the main library — installing the marketplace gives you all four.
+
+/plugin marketplace add mohitagw15856/pm-claude-skills
+
+
+Then navigate to the template you want and follow its README:
+
+cd templates/pm-sprint-agent      # or pm-discovery-agent, etc.
+cat README.md                       # full setup instructions
+
+
+### Building your own template
+
+If you want to build a template for a workflow not covered above — Legal Contract Review, Sales Pursuit, Finance Board Pack, HR Onboarding, Marketing Campaign — see the [template contribution guide](./templates/CONTRIBUTING.md).
+
+The pattern is consistent: pick a multi-step workflow, identify which existing skills cover the structured outputs, add connectors for data access, and define subagents for specialised analysis. The four templates above are reference implementations.
+
+
+It combines four skills, two connectors, and two subagents into a single workflow that handles end-to-end sprint planning.
+
+Documentation, working orchestration script, and example outputs are included in the template folder.
+
+More templates will follow. If you want to contribute one, see the [template contribution guide](./templates/CONTRIBUTING.md).
+
+---
+
+## 🆕 What's New in v10.0.0
+
+**Two star milestones unlocked — 8 new skills shipped:**
+
+**Customer Success bundle (250 ⭐ milestone):**
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **Customer Health Scorecard** 🆕 | pm-cs | Weighted health score across adoption, engagement, outcomes, support, and commercial — with RAG status and renewal forecast |
+| **QBR Deck** 🆕 | pm-cs | Slide-by-slide quarterly business review structure with talking points, value narrative, and mutual commitments |
+| **Escalation Brief** 🆕 | pm-cs | Structured escalation brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
+| **Churn Analysis** 🆕 | pm-cs | Churn rate breakdown by category and segment, early warning signals, and prioritised interventions |
+
+**Engineering expansion (500 ⭐ milestone):**
+
+| Skill | Bundle | What It Does |
+|---|---|---|
+| **CI/CD Playbook** 🆕 | pm-engineering | Complete pipeline playbook covering every stage, rollback procedures, secrets management, and on-call responsibilities |
+| **SLO & Error Budget** 🆕 | pm-engineering | SLI definitions, SLO targets, error budget calculation, burn rate alerts, and error budget policy |
+| **Developer Onboarding Doc** 🆕 | pm-engineering | Everything a new engineer needs in their first week — architecture, local setup, testing, deployment, and key contacts |
+| **On-Call Runbook** 🆕 | pm-engineering | Per-alert response procedures, escalation matrix, diagnostic cheat sheet, and handoff template |
+
+The library now includes **114 skills** across **16 professions** + 4 working agent templates.

-**6 new engineering skills added to `pm-engineering`:**

 | Skill | Bundle | What It Does |
 |---|---|---|
@@ -113,6 +225,8 @@ This repo was built alongside a published article series. Read the full story:
 | Part 12 | I Built the Same Skills Library for ChatGPT — Here's What's Different | [Read →](https://medium.com/product-powerhouse/i-built-the-same-skills-library-for-chatgpt-heres-what-s-different-a9305f9c20b9) |
 | Part 13 | I Re-Tested My 90 Claude Skills on Opus 4.7 — Here's What Got Better | [Read →](https://medium.com/all-about-claude/i-re-tested-my-90-claude-skills-on-opus-4-7-heres-what-actually-got-better-dd4b9369329e)|
 | Part 14 | I Rebuilt All 93 Skills and Added 7 More: What 100 Skills Taught Me About What Makes a Great Skill | [Read →](https://medium.com/product-powerhouse/a-pull-request-made-me-rebuild-all-93-of-my-claude-skills-then-i-added-7-more-16d5fe3e7f85) |
+| Part 15 | I’m a Product Manager. I Just Shipped 6 Engineering Skills to My Open-Source Claude Library. | [Read →](https://medium.com/product-powerhouse/im-a-product-manager-i-just-shipped-6-engineering-skills-to-my-open-source-claude-library-8745aaa2ecf9) |
+| Part 16 | Anthropic Just Released 10 Agent Templates. Here’s the First One I Built Using My 106 Skills. | [Read →](https://medium.com/product-powerhouse/anthropic-just-released-10-agent-templates-heres-the-first-one-i-built-using-my-106-skills-a6708f9bd3ea) |

 ---

@@ -151,7 +265,7 @@ This repo was built alongside a published article series. Read the full story:

 ---

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

 | # | Skill | Folder | What It Does |
@@ -160,178 +274,228 @@ This repo was built alongside a published article series. Read the full story:
 | 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 |
+| 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 |

 ---

-### 📊 Data & Analytics (Skills 45–48)
+### 🤝 Customer Success (Skills 55–58)
+**Bundle:** `pm-cs`
+
+> 250 ⭐ milestone unlocked. Install:
+
+claude plugin install pm-cs@pm-claude-skills
+
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 55 | **Customer Health Scorecard** 🆕 | `skills/cs-health-scorecard/` | Weighted health score across adoption, engagement, outcomes, support, and commercial — RAG status and renewal forecast |
+| 56 | **QBR Deck** 🆕 | `skills/qbr-deck/` | Slide-by-slide quarterly business review with talking points, value narrative, and mutual commitments |
+| 57 | **Escalation Brief** 🆕 | `skills/cs-escalation-brief/` | Structured brief for at-risk accounts — root cause, business impact, resolution plan, and decision required |
+| 58 | **Churn Analysis** 🆕 | `skills/churn-analysis/` | Churn breakdown by category and segment, early warning signals, and prioritised interventions |
+
+---
+
+### 📊 Data & Analytics (Skills 59–62)
 **Bundle:** `pm-data`

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

 ---

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

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

 ---

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

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

 ---

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

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

 ---

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

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

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

 ---

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

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

 ---

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

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

 ---

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

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

 ---

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

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

 ---

-### 🏥 Research & Healthcare (Skills 82–85)
+### 🏥 Research & Healthcare (Skills 96–99)
 **Bundle:** `pm-research`

 > ⚠️ Healthcare skills are for documentation and educational purposes only. All clinical content must be reviewed by a qualified professional.

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 82 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
-| 83 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
-| 84 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
-| 85 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |
+| 96 | **Clinical Case Summary** | `skills/clinical-case-summary/` | SBAR handovers, SOAP notes, and case reports for educational and documentation use |
+| 97 | **Research Protocol** | `skills/research-protocol/` | Complete study protocols with objectives, methodology, ethics, and analysis plan |
+| 98 | **Patient Communication** | `skills/patient-communication/` | Plain English patient letters, leaflets, and results communications at Grade 6 reading level |
+| 99 | **Literature Review** | `skills/literature-review/` | Thematically organised literature reviews with synthesis, critical analysis, and gap identification |

 ---

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

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 86 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
-| 87 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
-| 88 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
-| 89 | **Teaching Lesson Plan** 🆕 | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |
+| 100 | **Press Release** | `skills/press-release/` | Journalist-ready press releases with headline rules, boilerplate, and journalist test |
+| 101 | **Grant Proposal** | `skills/grant-proposal/` | Complete grant applications aligned to funder priorities with budget narrative |
+| 102 | **Executive Summary** | `skills/executive-summary/` | Decision-ready executive summaries with bottom line upfront, adapted for any audience |
+| 103 | **Teaching Lesson Plan** | `skills/teaching-lesson-plan/` | Complete lesson plans for any subject, audience, or setting — with objectives, activities, and formative assessment |

 ---

-### 🖼️ Figma (Skills 90–100 — reaching the milestone)
+### 🖼️ Figma (Skills 104–113)
 **Bundle:** `pm-figma`

 | # | Skill | Folder | What It Does |
 |---|---|---|---|
-| 90 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
-| 91 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
-| 92 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
-| 93 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
-| 94 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
-| 95 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
-| 96 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
-| 97 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
-| 98 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
-| 99 | **Figma Design Critique (PM)** | `skills/figma-design-critique-pm/` | PM-perspective design critique focused on product outcomes, not aesthetics |
-| 100 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
+| 104 | **Figma Component Audit** | `skills/figma-component-audit/` | Audit component library for naming issues, coverage gaps, and variant completeness |
+| 105 | **Figma Design Brief** | `skills/figma-design-brief/` | Convert PRDs and feature requests into structured Figma design briefs |
+| 106 | **Figma Annotation Guide** | `skills/figma-annotation-guide/` | Generate complete developer handoff annotations covering all states and edge cases |
+| 107 | **Figma Design Review** | `skills/figma-design-review/` | PM design review against requirements with explicit approval status |
+| 108 | **Figma User Flow Planner** | `skills/figma-user-flow-planner/` | Map all screens, states, and decision points before opening Figma |
+| 109 | **Figma Variant Matrix** | `skills/figma-variant-matrix/` | Define all component variants, properties, and states before building |
+| 110 | **Figma Spacing System** | `skills/figma-spacing-system/` | Design a complete spacing scale, grid, and token system |
+| 111 | **Figma Prototype Plan** | `skills/figma-prototype-plan/` | Plan prototype scope, interactions, and test task scripts for user testing |
+| 112 | **Figma Design QA** | `skills/figma-design-qa/` | Pre-handoff QA checklist covering file hygiene, states, accessibility, and handoff readiness |
+| 113 | **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 114)
+**Bundle:** `pm-rituals`
+
+| # | Skill | Folder | What It Does |
+|---|---|---|---|
+| 114 | **PM Weekly Review** | `skills/pm-weekly-review/` | Weekly PM review and planning ritual — metrics, shipping progress, blockers, and next week's priorities |
+
+---
+
+## ❤️ Sponsor This Work
+
+Building and maintaining 114 skills across 23 bundles takes real time — testing skills against new model releases, building new ones from community requests, writing the article series, and keeping documentation current.
+
+If these skills save you time at work, consider sponsoring:
+
+**[💖 Become a Sponsor →](https://github.com/sponsors/mohitagw15856)**
+
+Sponsorships from $5/month (coffee tier) up to $500/month (sustaining sponsor with logo placement). Every sponsor directly funds:
+
+- New skills based on community votes in [SKILL_REQUEST.md](SKILL_REQUEST.md)
+- Updates to existing skills when new Claude models ship
+- Continued free, ad-free Medium articles documenting what works
+- Quality improvements across the library
+
+Higher tiers include custom skill development for your team, direct access for support, and logo placement in this README. See the [sponsor page](https://github.com/sponsors/mohitagw15856) for full tier details.
+
 ---

 ## 🤝 Contributing — Add Your Skill

 This is an open-source community library. If you've built a skill that saves you time, share it here.

+**Found a bug?** [Open a bug report →](../../issues/new?template=bug-report.md) — use the template so it's easy to triage.
+
 **How to contribute:**

 1. Fork this repo
@@ -389,7 +553,8 @@ claude plugin install pm-strategy@pm-claude-skills
 claude plugin install pm-advanced@pm-claude-skills
 claude plugin install pm-rituals@pm-claude-skills
 claude plugin install pm-gtm@pm-claude-skills
-claude plugin install pm-engineering@pm-claude-skills    # 10 engineering skills 🆕
+claude plugin install pm-engineering@pm-claude-skills    # 14 engineering skills 🆕
+claude plugin install pm-cs@pm-claude-skills             # Customer Success (4 skills) 🆕
 claude plugin install pm-data@pm-claude-skills
 claude plugin install pm-people@pm-claude-skills
 claude plugin install pm-design@pm-claude-skills
@@ -403,6 +568,7 @@ claude plugin install pm-research@pm-claude-skills
 claude plugin install pm-cross@pm-claude-skills
 claude plugin install pm-figma@pm-claude-skills

+
 ---

 ## 🤖 Companion Repository — ChatGPT Custom GPTs
@@ -417,7 +583,7 @@ Read the full breakdown: [Part 12 — I Built the Same Skills Library for ChatGP

 ## 🛠️ Custom Skills for Your Team

-The 100 skills in this library are built for general professional workflows. But the most powerful version of Claude Skills is one built specifically for *your* team — your templates, your terminology, your processes, your quality standards.
+The 106 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:**

@@ -454,8 +620,8 @@ Stars unlock the next wave of skills. Here's the roadmap:
 | Milestone | Unlocks | Status |
 |---|---|---|
 | 100 ⭐ | 10 Figma skills + quality rebuild across all 93 skills | ✅ Shipped (v6.0.0) |
-| 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) | 🔒 Locked |
-| 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns) | 🔒 Locked |
+| 250 ⭐ | 10 Customer Success skills (health scorecard, QBR deck, escalation brief, churn analysis) | ✅ Unlocked — coming in next release |
+| 500 ⭐ | 25 more Engineering skills (CI/CD playbooks, SLO templates, onboarding docs, debugging patterns) | ✅ Unlocked — coming in next release |
 | 1000 ⭐ | Full Startup Founder kit (fundraising memo, pitch critique, co-founder equity split) | 🔒 Locked |

 **[⭐ Star this repo to unlock the next milestone →](https://github.com/mohitagw15856/pm-claude-skills)**
@@ -464,4 +630,4 @@ Want a specific skill built? [Vote or request in SKILL_REQUEST.md](SKILL_REQUEST

 ---

-*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Notes publication](https://medium.com/product-powerhouse)*
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | [Product Notes publication](https://medium.com/product-powerhouse) | [💖 Sponsor my work](https://github.com/sponsors/mohitagw15856)*
@@ -6,7 +6,7 @@ Have an idea for a skill? Add it here or upvote existing requests by leaving a

 ## How to Request a Skill

-1. [Open an issue](../../issues/new) with the label `skill-request`
+1. [Open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues/new) with the label `skill-request`
 2. Include:
   - **Skill name** (what you'd call it)
   - **Profession** (who uses this)
@@ -0,0 +1,13 @@
+{
+  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
+  "name": "pm-cs",
+  "version": "1.0.0",
+  "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.",
+  "author": {
+    "name": "Mohit Aggarwal",
+    "email": "mohit15856@gmail.com"
+  },
+  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
+  "license": "MIT",
+  "keywords": ["customer-success", "account-management", "health-scorecard", "qbr", "quarterly-business-review", "churn", "retention", "escalation", "csm", "renewal"]
+}
@@ -0,0 +1,179 @@
+---
+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."
+---
+
+# Churn Analysis Skill
+
+Produce a structured churn analysis that goes beyond the headline rate — identifying why customers leave, which segments are most at risk, and what interventions will have the highest impact on retention.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Time period** being analysed (e.g. Q1, last 12 months)
+- **Total customers at start of period** and **customers churned**
+- **ARR or revenue lost** to churn
+- **Churn reasons data** — exit survey results, CSM notes, support data, or sales loss reasons
+- **Customer segments** — by tier, industry, cohort, or product line
+- **Current retention rate** if known
+- **Any recent changes** — pricing, product, support model — that may have affected churn
+
+## Churn Categories
+
+Always classify churn before analysing it:
+
+| Category | Definition |
+|---|---|
+| **Voluntary — avoidable** | Customer left due to a problem we could have addressed (product gaps, poor onboarding, relationship failures) |
+| **Voluntary — unavoidable** | Customer left for reasons outside our control (budget cuts, acquisition, company shutdown) |
+| **Involuntary** | Payment failure, contract non-renewal by mistake, admin error |
+
+The interventions for each category are different. Conflating them leads to wrong conclusions.
+
+## Output Format
+
+---
+
+# Churn Analysis: [Product / Segment / Company]
+**Period:** [Start date] — [End date]
+**Prepared by:** [Name] | **Date:** [Date]
+
+---
+
+## Headline Numbers
+
+| Metric | Value |
+|---|---|
+| Customers at start of period | [N] |
+| Customers churned | [N] |
+| **Customer churn rate** | **[X]%** |
+| ARR at start of period | £/$/€[X] |
+| ARR lost to churn | £/$/€[X] |
+| **Revenue churn rate (gross)** | **[X]%** |
+| ARR from expansions (same period) | £/$/€[X] |
+| **Net revenue retention (NRR)** | **[X]%** |
+
+**Benchmark context:**
+- Customer churn rate: [X]% vs. industry benchmark [Y]% — [above / below / in line]
+- NRR: [X]% — [What this means: above 100% = expansion offsets churn; below 100% = shrinking base]
+
+---
+
+## Churn Breakdown by Category
+
+| Category | Customers | % of churn | ARR lost |
+|---|---|---|---|
+| Voluntary — avoidable | [N] | [X]% | £/$/€[X] |
+| Voluntary — unavoidable | [N] | [X]% | £/$/€[X] |
+| Involuntary | [N] | [X]% | £/$/€[X] |
+| **Total** | **[N]** | **100%** | **£/$/€[X]** |
+
+**Avoidable churn as % of total churn:** [X]% — this is the number we can actually influence.
+
+---
+
+## Churn Reasons — Avoidable Churn Only
+
+Rank by frequency. Include ARR weight where data allows.
+
+| Reason | Count | % of avoidable churn | ARR lost | Representative quote |
+|---|---|---|---|---|
+| [Reason 1 — e.g. "Product missing key feature"] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 2] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 3] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 4] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| Other | [N] | [X]% | £/$/€[X] | — |
+
+**Theme synthesis:** [2–3 sentences grouping the top reasons into 2–3 themes. E.g. "The top three reasons cluster around two themes: product gaps in [area] (affecting X% of avoidable churn) and onboarding failures where customers never achieved value (Y%)."]
+
+---
+
+## Churn by Segment
+
+Identify which segments over- or under-index for churn.
+
+### By Tier
+
+| Tier | Churn rate | vs. Overall | Notes |
+|---|---|---|---|
+| Enterprise | [X]% | +/-[X]pp | |
+| Mid-Market | [X]% | +/-[X]pp | |
+| SMB | [X]% | +/-[X]pp | |
+
+### By Cohort (Acquisition Year)
+
+| Cohort | Churn rate | Notes |
+|---|---|---|
+| [Year 1] | [X]% | |
+| [Year 2] | [X]% | |
+| [Year 3] | [X]% | |
+
+### By Industry / Use Case (if data available)
+
+| Segment | Churn rate | Notes |
+|---|---|---|
+| [Segment 1] | [X]% | |
+| [Segment 2] | [X]% | |
+
+**Key pattern:** [Which segment has the highest churn rate and what likely explains it]
+
+---
+
+## Timing Analysis
+
+- **Average contract length before churn:** [X months]
+- **Highest-risk moment:** [e.g. "Month 3 — when trial value has worn off but full adoption hasn't happened"]
+- **Churn timing distribution:**
+
+| When churn occurred | % of churned accounts |
+|---|---|
+| 0–3 months | [X]% |
+| 3–6 months | [X]% |
+| 6–12 months | [X]% |
+| 12+ months | [X]% |
+
+---
+
+## Early Warning Signals
+
+Based on the churned accounts, identify the signals that preceded churn (and could have triggered earlier intervention):
+
+| Signal | Lead time before churn | How to detect |
+|---|---|---|
+| [Signal 1 — e.g. "DAU/MAU dropped below 15%"] | [~X weeks] | [Usage dashboard / alert] |
+| [Signal 2 — e.g. "No QBR in 90+ days"] | [~X weeks] | [CRM flag] |
+| [Signal 3 — e.g. "Champion left the account"] | [~X weeks] | [LinkedIn alert / CSM tracking] |
+| [Signal 4] | [~X weeks] | [Detection method] |
+
+---
+
+## Intervention Recommendations
+
+Ranked by estimated impact × feasibility.
+
+| Intervention | Addresses | Est. churn reduction | Effort | Owner |
+|---|---|---|---|---|
+| [Intervention 1 — e.g. "Improve onboarding for [segment] with dedicated 30-day check-in"] | [Reason 1] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+| [Intervention 2] | [Reason 2] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+| [Intervention 3] | [Reason 3] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+
+**Priority call:** [Which one intervention, if implemented this quarter, would have the biggest impact and why]
+
+---
+
+## What We Don't Know (Data Gaps)
+
+- [Data gap 1 — e.g. "Exit survey response rate is only 30% — the reasons data may not be representative"]
+- [Data gap 2 — e.g. "No product usage data for SMB tier — can't confirm usage signal correlation"]
+- [Data gap 3]
+
+---
+
+## Quality Checks
+
+- [ ] Churn rate is correctly calculated (churned ÷ starting cohort, not end-of-period total)
+- [ ] Avoidable and unavoidable churn are separated — interventions target avoidable churn only
+- [ ] Churn reasons are customer-reported, not internally assumed
+- [ ] Segment analysis identifies which segments over-index — not just averages
+- [ ] Early warning signals are specific and detectable, not generic ("low engagement")
+- [ ] Interventions link directly to the top churn reasons — no recommendations without a root cause match
@@ -0,0 +1,176 @@
+---
+name: cs-escalation-brief
+description: "Write a structured escalation brief for an at-risk customer account. Use when an account has escalated, when a customer is threatening churn, when a P1 customer issue needs executive attention, or when preparing an internal save play. Produces a crisp escalation brief with account context, timeline, root cause, business impact, and a clear resolution plan."
+---
+
+# Customer Escalation Brief Skill
+
+Produce a clear, concise escalation brief that gives internal stakeholders — VP CS, CCO, product leadership, or the CEO — everything they need to understand the situation, make decisions, and act fast.
+
+A good escalation brief is not a complaint. It is a professional document that states the facts, assigns accountability honestly, and proposes a specific resolution plan.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name**, tier, and ARR
+- **CSM name** and account owner
+- **Nature of the escalation** — what happened, what the customer is saying
+- **Timeline** of events leading to escalation
+- **Customer contact** who escalated (name, role, influence level)
+- **What the customer wants** — their stated ask
+- **What we believe the root cause is**
+- **What has already been done** to address the situation
+- **Renewal date** and current renewal risk assessment
+
+## Escalation Levels
+
+Calibrate urgency and audience based on escalation level:
+
+| Level | Trigger | Audience | Response time |
+|---|---|---|---|
+| L1 — Account Risk | Customer expressing dissatisfaction; renewal at risk | CSM + CS Manager | 24 hours |
+| L2 — Executive Escalation | Customer escalated to their exec; requesting vendor exec involvement | VP CS + Account Exec | 4 hours |
+| L3 — Churn Risk | Customer has issued notice or is in active churn conversation | CCO / CEO + Revenue leadership | 1 hour |
+| L4 — Public Risk | Customer threatening public escalation, legal, or press | CCO / Legal / Comms | Immediate |
+
+## Output Format
+
+---
+
+# Escalation Brief: [Account Name]
+
+**Escalation level:** L[1/2/3/4] — [Label]
+**Date raised:** [Date]
+**Raised by:** [CSM name]
+**Escalation owner:** [Name of exec or senior stakeholder now leading response]
+
+---
+
+## Account at a Glance
+
+| Field | Detail |
+|---|---|
+| ARR | £/$/€[X] |
+| Tier | Enterprise / Mid-Market / SMB |
+| Customer since | [Date] |
+| Renewal date | [Date] — [N] days away |
+| Renewal risk (pre-escalation) | Green / Amber / Red |
+| Renewal risk (current) | Green / Amber / Red |
+| Customer contact who escalated | [Name, role, seniority] |
+| Executive sponsor (customer) | [Name, role — active / passive / vacant] |
+| Executive sponsor (vendor) | [Name, role] |
+
+---
+
+## What Happened — Summary
+
+[3–5 sentences. State the facts plainly. What the customer experienced, how they reacted, and how we learned about the escalation. No editorialising. No blame.]
+
+---
+
+## Timeline
+
+List in chronological order. Each entry: `[Date / time] — [What happened. Who did what.]`
+
+Include:
+- When the original issue or trigger event occurred
+- When the customer first raised concerns (informally)
+- When it escalated (formal escalation or exec involvement)
+- Actions taken since escalation
+
+---
+
+## Root Cause
+
+**Primary cause:** [One clear sentence. What specifically went wrong.]
+
+**Contributing factors:**
+- [Factor 1 — be honest about internal failures as well as external ones]
+- [Factor 2]
+
+**Is this a systemic issue or isolated?**
+[ ] Isolated to this account
+[ ] Pattern seen in other accounts — details: [_______]
+[ ] Product or process gap that needs fixing
+
+---
+
+## Customer's Stated Position
+
+**What the customer says happened:** [Their version of events — fair and unfiltered]
+
+**What they are asking for:** [Their explicit ask — compensation, fix by date, exec call, SLA credit, exit clause]
+
+**Sentiment of escalating contact:** [Frustrated but constructive / Angry / Seeking exit / Unknown]
+
+**Risk of public escalation:** Low / Medium / High — [evidence if Medium or High]
+
+---
+
+## Business Impact
+
+| Impact type | Detail |
+|---|---|
+| ARR at risk | £/$/€[X] |
+| Potential churn probability | [X]% |
+| Reputational risk | Low / Medium / High |
+| Reference / case study status | [Was a reference — now at risk / Not a reference] |
+| Expansion pipeline at risk | £/$/€[X] |
+
+---
+
+## What Has Been Done So Far
+
+1. [Action taken — by whom — date — outcome]
+2. [Action taken — by whom — date — outcome]
+3. [Action taken — by whom — date — outcome]
+
+**Has a formal apology or acknowledgement been issued?** Yes / No
+
+---
+
+## Proposed Resolution Plan
+
+**Immediate actions (next 24–48 hours):**
+
+| Action | Owner | By when |
+|---|---|---|
+| [Action] | [Name] | [Date] |
+| [Action] | [Name] | [Date] |
+
+**Medium-term actions (next 2–4 weeks):**
+
+| Action | Owner | By when |
+|---|---|---|
+| [Action] | [Name] | [Date] |
+
+**What we are NOT offering:** [Be explicit about what is not on the table — avoids misaligned expectations]
+
+**Success criteria:** [How will we know the escalation is resolved? What does the customer need to confirm they are satisfied?]
+
+---
+
+## Decision Required from Escalation Owner
+
+[State clearly what decision or resource the escalation owner needs to provide. Be specific — do not make them ask. E.g.: "We need approval to offer a 20% service credit for Q2" or "We need an exec call with [name] within 48 hours."]
+
+---
+
+## Communication Plan
+
+| Audience | Message | Channel | Owner | By when |
+|---|---|---|---|---|
+| Escalating customer contact | [Summary of message] | Email / Call | [Name] | [Date] |
+| Customer exec sponsor | [Summary] | Call | [Name] | [Date] |
+| Internal CS team | [Summary] | Slack / Meeting | CS Manager | [Date] |
+
+---
+
+## Quality Checks
+
+- [ ] Root cause is specific — not "communication breakdown" or "product gap" without detail
+- [ ] Customer's position is stated fairly — not minimised or dismissed
+- [ ] A clear decision is requested from the escalation owner — brief does not end with "what do you think?"
+- [ ] ARR at risk is quantified
+- [ ] Communication plan has owners and dates — not "TBD"
+- [ ] Language is professional and blameless toward individuals
@@ -0,0 +1,141 @@
+---
+name: cs-health-scorecard
+description: "Build a customer health scorecard for a specific account. Use when asked to score account health, assess renewal risk, build a health dashboard, or evaluate an account's likelihood to renew or expand. Produces a structured health scorecard with a RAG status, dimension scores, key risks, and recommended actions."
+---
+
+# Customer Health Scorecard Skill
+
+Produce a structured, data-driven health scorecard for a customer account — giving the CSM and leadership a clear view of renewal risk, expansion potential, and the actions needed to move the account in the right direction.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name** and tier (enterprise / mid-market / SMB)
+- **Contract value** (ARR) and **renewal date**
+- **Product usage data** — logins, DAU/MAU ratio, key feature adoption
+- **Support data** — open tickets, CSAT or NPS score, recent escalations
+- **Engagement data** — last QBR date, executive sponsor status, champion name
+- **Commercial data** — payment history, expansion conversations, seats used vs. licensed
+- **Any known risks or recent changes** at the account
+
+## Scoring Framework
+
+Score each dimension 1–5. Weight as shown. Calculate weighted total out of 100.
+
+| Dimension | Weight | What to Score |
+|---|---|---|
+| **Product Adoption** | 30% | DAU/MAU ratio, breadth of features used, power users identified |
+| **Engagement** | 20% | QBR cadence, executive sponsor active, champion strength |
+| **Outcomes** | 20% | Customer hitting their stated goals / success metrics |
+| **Support Health** | 15% | Ticket volume trend, unresolved escalations, CSAT |
+| **Commercial** | 15% | On-time payments, seats utilised, expansion signals |
+
+**Score → RAG conversion:**
+- 80–100: Green (healthy, renew likely)
+- 60–79: Amber (at risk, needs attention)
+- 0–59: Red (high churn risk, escalate)
+
+## Output Format
+
+---
+
+# Customer Health Scorecard: [Account Name]
+
+**CSM:** [Name] | **Tier:** [Enterprise / Mid-Market / SMB]
+**ARR:** £/$/€[X] | **Renewal date:** [Date] | **Days to renewal:** [N]
+**Overall health:** [Green / Amber / Red] — [Score]/100
+**Last updated:** [Date]
+
+---
+
+## Health Score Summary
+
+| Dimension | Score (1–5) | Weight | Weighted Score | Trend |
+|---|---|---|---|---|
+| Product Adoption | [1–5] | 30% | [X] | ↑ / → / ↓ |
+| Engagement | [1–5] | 20% | [X] | ↑ / → / ↓ |
+| Outcomes | [1–5] | 20% | [X] | ↑ / → / ↓ |
+| Support Health | [1–5] | 15% | [X] | ↑ / → / ↓ |
+| Commercial | [1–5] | 15% | [X] | ↑ / → / ↓ |
+| **Total** | — | 100% | **[X]/100** | |
+
+---
+
+## Dimension Detail
+
+### Product Adoption — [Score]/5
+- **DAU/MAU ratio:** [X]% (benchmark: >25% = healthy)
+- **Key features adopted:** [List features in use]
+- **Features not adopted:** [List unused high-value features]
+- **Power users identified:** [Yes / No — how many]
+- **Assessment:** [1–2 sentences on adoption health]
+
+### Engagement — [Score]/5
+- **Last QBR:** [Date] — [Outcome summary]
+- **Next QBR:** [Scheduled / Overdue]
+- **Executive sponsor:** [Active / Passive / Vacant]
+- **Champion:** [Name, role, strength: strong / moderate / weak]
+- **Assessment:** [1–2 sentences]
+
+### Outcomes — [Score]/5
+- **Customer's stated goals:** [List 2–3 goals from onboarding or last QBR]
+- **Progress against goals:** [On track / Partial / Off track]
+- **Evidence of value:** [Metric or quote that demonstrates ROI]
+- **Assessment:** [1–2 sentences]
+
+### Support Health — [Score]/5
+- **Open tickets:** [N] (priority breakdown: P1: X, P2: X, P3: X)
+- **CSAT / NPS:** [Score] (benchmark: >8 CSAT / >30 NPS = healthy)
+- **Unresolved escalations:** [Yes / No — details if yes]
+- **Ticket trend (last 90 days):** Increasing / Stable / Decreasing
+- **Assessment:** [1–2 sentences]
+
+### Commercial — [Score]/5
+- **Seats licensed:** [N] | **Seats active:** [N] ([X]% utilisation)
+- **Payment history:** [On time / Late — details]
+- **Expansion signals:** [Yes — describe / No]
+- **Downgrade or cancellation signals:** [Yes — describe / No]
+- **Assessment:** [1–2 sentences]
+
+---
+
+## Top Risks
+
+| Risk | Severity | Mitigation |
+|---|---|---|
+| [Risk description] | High / Medium / Low | [Specific action to mitigate] |
+
+---
+
+## Recommended Actions
+
+**Immediate (this week):**
+1. [Action — owner — deadline]
+
+**This month:**
+1. [Action — owner — deadline]
+
+**Before renewal:**
+1. [Action — owner — deadline]
+
+---
+
+## Renewal Forecast
+
+| Scenario | Probability | ARR at risk |
+|---|---|---|
+| Full renewal at current ARR | [X]% | £/$/€0 |
+| Renewal with contraction | [X]% | £/$/€[X] |
+| Churn | [X]% | £/$/€[full ARR] |
+
+**Recommended renewal play:** [Expand / Hold / Save / Manage out]
+
+---
+
+## Quality Checks
+
+- [ ] Score is based on data, not gut feel — each dimension has evidence
+- [ ] Risks are specific (not "low engagement" — something like "executive sponsor left in March, no replacement identified")
+- [ ] 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
@@ -0,0 +1,218 @@
+---
+name: qbr-deck
+description: "Build a Quarterly Business Review (QBR) deck structure and narrative for a customer account. Use when asked to prepare a QBR, business review meeting, executive review, or quarterly check-in with a customer. Produces a slide-by-slide QBR structure with talking points, metrics review, value narrative, and mutual next steps."
+---
+
+# QBR Deck Skill
+
+Produce a complete Quarterly Business Review deck — structured, data-backed, and customer-focused. A good QBR demonstrates value delivered, aligns on goals for the next quarter, and strengthens the executive relationship. It should never feel like a product demo or a vendor update.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name**, CSM name, and customer stakeholders attending
+- **Contract details** — ARR, contract start date, renewal date
+- **Last quarter's goals** (from previous QBR or kickoff)
+- **Usage and adoption data** — key metrics for the quarter
+- **Support summary** — tickets raised, resolution time, any escalations
+- **Business outcomes the customer cares about** — what success looks like for them
+- **Product updates or new features** relevant to this customer
+- **Goals for next quarter**
+- **Any open commercial conversations** (expansion, renewal, at-risk signals)
+
+## QBR Principles
+
+- Lead with customer outcomes, not product features
+- Every metric should connect to a business result the customer cares about
+- The agenda is a conversation, not a presentation — build in time for customer input at every stage
+- Close with mutual commitments, not just vendor actions
+
+## Output Format
+
+---
+
+# QBR: [Account Name] × [Your Company]
+**[Quarter] [Year] Business Review**
+
+**Date:** [Date] | **Location / Call link:** [TBC]
+**Customer attendees:** [Names and roles]
+**[Your company] attendees:** [Names and roles]
+
+---
+
+## Slide 1: Agenda (5 min)
+
+| Time | Topic | Owner |
+|---|---|---|
+| 0:00 | Welcome and introductions | CSM |
+| 0:05 | [Last quarter] — how did we do? | CSM + Customer |
+| 0:20 | Value delivered — business impact | CSM |
+| 0:35 | What's coming — roadmap preview | CSM / Product |
+| 0:45 | [Next quarter] — goals and priorities | Customer |
+| 0:55 | Actions and mutual commitments | CSM |
+| 1:00 | Close | |
+
+*Talking point: "We've kept today to 60 minutes. We want as much of this to be a conversation as possible — please push back, redirect, and ask questions throughout."*
+
+---
+
+## Slide 2: Where We Are Together (2 min)
+
+**Partnership snapshot:**
+- **Customer since:** [Date]
+- **Contract value:** £/$/€[ARR]/year
+- **Renewal date:** [Date]
+- **Active users:** [N] of [N] licensed seats ([X]% adoption)
+- **Products / modules active:** [List]
+
+*Talking point: "Before we dive in — a quick picture of where we are. [X] months in, [Y] active users, and this is our [Nth] QBR together."*
+
+---
+
+## Slide 3: Last Quarter — Goals We Set Together (5 min)
+
+| Goal | Set in [Last QBR / Kickoff] | Status |
+|---|---|---|
+| [Goal 1] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+| [Goal 2] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+| [Goal 3] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+
+For any partial or missed goal: state what happened and what changes next quarter.
+
+*Talking point: "Let's start with accountability. Here's what we said we'd achieve last quarter — let's be honest about where we landed."*
+
+---
+
+## Slide 4: Usage and Adoption (5 min)
+
+**Quarter-over-quarter trend:**
+
+| Metric | [Q-1] | [Q] | Change |
+|---|---|---|---|
+| Monthly active users | [N] | [N] | +/-X% |
+| Sessions per user per week | [N] | [N] | +/-X% |
+| [Key feature 1] adoption | [X]% | [X]% | +/-X% |
+| [Key feature 2] adoption | [X]% | [X]% | +/-X% |
+
+**Highlights:**
+- [Positive adoption trend to call out]
+- [Feature or workflow with strongest engagement]
+
+**Opportunity:**
+- [Feature with low adoption that could drive more value — link to their goals]
+
+*Talking point: "Usage is [up / stable / something we want to talk about]. The area I'd like to focus on is [feature] — we're not seeing the adoption we'd expect given [their goal], and I want to understand why."*
+
+---
+
+## Slide 5: Business Impact — Value Delivered (10 min)
+
+Lead with outcomes, not activity.
+
+**[Outcome 1: customer's primary success metric]**
+- Before: [baseline]
+- Now: [current state]
+- Impact: [quantified business result — time saved, revenue influenced, cost reduced, risk mitigated]
+
+**[Outcome 2]**
+- [Same structure]
+
+**[Outcome 3]**
+- [Same structure]
+
+**Customer evidence** (use if available):
+> "[Quote from champion or user about value experienced]"
+
+*Talking point: "This is the section I most want your input on. Are these the outcomes that matter to your business? Are there other ways you're measuring success that we should be tracking?"*
+
+---
+
+## Slide 6: Support Summary (3 min)
+
+| Metric | This quarter | Last quarter | Trend |
+|---|---|---|---|
+| Tickets raised | [N] | [N] | ↑ / → / ↓ |
+| Average resolution time | [X hrs] | [X hrs] | ↑ / → / ↓ |
+| P1 / critical issues | [N] | [N] | ↑ / → / ↓ |
+| CSAT score | [X/10] | [X/10] | ↑ / → / ↓ |
+
+**Notable issues this quarter:**
+- [Any escalation or major ticket — brief summary and resolution]
+
+**What we're doing differently:**
+- [Any process change or improvement based on support patterns]
+
+---
+
+## Slide 7: What's Coming — Roadmap Preview (5 min)
+
+Focus only on what's relevant to this customer's goals. Do not dump the full roadmap.
+
+| Feature / Improvement | Expected | Why it matters to [Account Name] |
+|---|---|---|
+| [Feature 1] | [Q+1] | [Direct link to their goal or pain point] |
+| [Feature 2] | [Q+1 / Q+2] | [Direct link] |
+| [Feature 3] | [H2] | [Direct link] |
+
+*Talking point: "I've filtered the roadmap to what I think matters most to your team. I'd love your reaction — are these the right priorities from your perspective?"*
+
+---
+
+## Slide 8: Next Quarter — Your Goals (10 min)
+
+**Customer input section — facilitate, don't present.**
+
+Prompt questions:
+- "What does success look like for your team in [next quarter]?"
+- "What's the biggest challenge you're trying to solve in the next 90 days?"
+- "Is there anything about the way you're using [product] you want to change?"
+
+**Capture live:**
+
+| Goal for next quarter | Owner (customer) | How we'll support it | How we'll measure it |
+|---|---|---|---|
+| [Goal 1] | [Name] | [CSM / product action] | [Metric] |
+| [Goal 2] | [Name] | [CSM / product action] | [Metric] |
+
+---
+
+## Slide 9: Mutual Commitments (5 min)
+
+**[Your company] commits to:**
+1. [Specific action — owner — by when]
+2. [Specific action — owner — by when]
+3. [Specific action — owner — by when]
+
+**[Account Name] commits to:**
+1. [Specific action — owner — by when]
+2. [Specific action — owner — by when]
+
+**Next touchpoint:** [Date of next check-in or mid-quarter review]
+
+---
+
+## Slide 10: Thank You + Open Q&A (5 min)
+
+- Recap the one headline from today: [The single most important thing you want them to remember]
+- Confirm actions are captured and shared after the call
+- Ask: "Is there anything we didn't cover today that you wanted to raise?"
+
+---
+
+## Preparation Checklist
+
+- [ ] Usage data pulled and QoQ comparison calculated
+- [ ] Last QBR goals reviewed — status confirmed before the meeting
+- [ ] Business outcomes framed in customer language (not product language)
+- [ ] Roadmap filtered to this account's specific use cases
+- [ ] Customer's goals for next quarter researched or pre-confirmed with champion
+- [ ] Executive sponsor briefed on any sensitive topics before the call
+- [ ] Actions from previous QBR reviewed — any outstanding items addressed
+
+## Quality Checks
+
+- [ ] Every slide has a talking point, not just a title
+- [ ] Value slide leads with business outcomes, not product activity
+- [ ] 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
@@ -1,13 +1,13 @@
 {
  "$schema": "https://anthropic.com/claude-code/plugin.schema.json",
  "name": "pm-engineering",
-  "version": "2.0.0",
-  "description": "Engineering & tech skills: Code Review Checklist, Incident Postmortem, API Docs Writer, Architecture Decision Record, Debugging Log Analyser, PR Description Writer, System Design Interview, Changelog Generator, Test Strategy Doc, Runbook Writer. 10 structured skills for engineering teams and technical PMs.",
+  "version": "3.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. 14 structured skills for engineering teams and technical PMs.",
  "author": {
    "name": "Mohit Aggarwal",
    "email": "mohit15856@gmail.com"
  },
  "homepage": "https://github.com/mohitagw15856/pm-claude-skills",
  "license": "MIT",
-  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture", "debugging", "pull-request", "system-design", "changelog", "test-strategy", "runbook", "devops"]
+  "keywords": ["product-management", "engineering", "code-review", "incident-postmortem", "api-documentation", "adr", "architecture", "debugging", "pull-request", "system-design", "changelog", "test-strategy", "runbook", "devops", "cicd", "slo", "error-budget", "onboarding", "oncall", "sre", "reliability"]
 }
@@ -0,0 +1,301 @@
+---
+name: cicd-playbook
+description: "Write a CI/CD pipeline playbook for a service or team. Use when asked to document a CI/CD pipeline, write a deployment process, define release gates, document build and test stages, or create a deployment guide. Produces a structured playbook covering pipeline stages, environment definitions, deployment gates, rollback procedures, and on-call responsibilities."
+---
+
+# CI/CD Playbook Skill
+
+Produce a complete, actionable CI/CD playbook for a service or team — covering everything a new engineer needs to understand, contribute to, and operate the pipeline safely.
+
+A good playbook is not a diagram. It is a document that answers: what runs, when, why, who owns it, and what to do when it breaks.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and brief description
+- **Tech stack** — language, framework, containerisation (Docker, etc.)
+- **Source control** — GitHub / GitLab / Bitbucket, branching strategy
+- **CI platform** — GitHub Actions / CircleCI / Jenkins / BuildKite / other
+- **CD platform / deployment target** — Kubernetes, ECS, Lambda, Heroku, VMs, etc.
+- **Environments** — e.g. dev, staging, production (and any canary / feature environments)
+- **Deployment frequency** — how often does the team ship?
+- **Any existing gates** — manual approvals, smoke tests, feature flags
+- **On-call setup** — who's responsible during deploys?
+
+## Output Format
+
+---
+
+# CI/CD Playbook: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Last updated:** [Date] | **Owner:** [Name / role]
+**Pipeline platform:** [CI tool] → [CD tool / platform]
+
+---
+
+## Overview
+
+[2–3 sentences describing what this service does and why the CI/CD pipeline is structured the way it is. Include the deployment target and how frequently the team ships.]
+
+**Deployment frequency:** [Multiple times per day / Daily / Weekly / On-demand]
+**Average pipeline duration:** [X minutes]
+**Rollback time (p95):** [X minutes]
+
+---
+
+## Pipeline Stages
+
+```
+[Branch push]
+    │
+    ▼
+[1. Build & Lint] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[2. Unit Tests] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[3. Integration Tests] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[4. Security Scan] ──fail──▶ ⚠️ [Block / Warn — specify]
+    │
+    ▼
+[5. Build Artefact / Container Image]
+    │
+    ▼
+[6. Deploy to Staging] ──fail──▶ ❌ Block promotion
+    │
+    ▼
+[7. Smoke Tests (Staging)]
+    │
+    ▼
+[8. Manual Approval Gate] ──(if required)
+    │
+    ▼
+[9. Deploy to Production] ──fail──▶ 🔁 Auto-rollback (if configured)
+    │
+    ▼
+[10. Post-deploy checks]
+```
+
+---
+
+## Stage Definitions
+
+### Stage 1 — Build & Lint
+
+**What runs:** [Build command] + [Linter — e.g. ESLint, golangci-lint, flake8]
+**Trigger:** Every commit to any branch
+**Blocking:** Yes — PR cannot be merged if this fails
+**Typical duration:** [X minutes]
+**Owner if it fails:** PR author
+
+**Common failure causes:**
+- [e.g. Missing dependency — run `npm install` locally before pushing]
+- [e.g. Lint rule violation — run `npm run lint --fix` to auto-fix most issues]
+
+---
+
+### Stage 2 — Unit Tests
+
+**What runs:** [Test command — e.g. `npm test`, `go test ./...`, `pytest`]
+**Coverage gate:** [X]% minimum — pipeline fails below this threshold
+**Trigger:** Every commit
+**Blocking:** Yes
+**Typical duration:** [X minutes]
+
+**Coverage report:** [Where to find it — e.g. uploaded to Codecov, available in CI artifacts]
+
+---
+
+### Stage 3 — Integration Tests
+
+**What runs:** [Test suite description — e.g. "API integration tests against a test database using Docker Compose"]
+**Environment:** [Ephemeral test environment / shared test DB / etc.]
+**Trigger:** Every commit to `main` and feature branches targeting `main`
+**Blocking:** Yes
+**Typical duration:** [X minutes]
+
+**If slow:** [e.g. "Integration tests can be skipped locally with `SKIP_INTEGRATION=true` — never skip in CI"]
+
+---
+
+### Stage 4 — Security Scan
+
+**Tools:** [e.g. Snyk, Trivy, OWASP Dependency Check, Semgrep]
+**What it checks:** [Dependency vulnerabilities / SAST / secrets detection — list what applies]
+**Blocking on:** Critical and High severity findings
+**Non-blocking on:** Medium and Low (flagged, not blocking)
+**Trigger:** Every commit to `main`
+
+**How to handle a flagged vulnerability:**
+1. Check if a fix is available — upgrade the dependency
+2. If no fix available, open a security ticket and add a suppression with justification
+3. Never suppress without a ticket and owner
+
+---
+
+### Stage 5 — Build Artefact
+
+**What is produced:** [Docker image / binary / zip — be specific]
+**Registry:** [ECR / GCR / Docker Hub / Artifactory — URL]
+**Tagging convention:** `[service-name]:[git-sha]` (also tagged `:latest` on `main`)
+**Trigger:** Commits to `main` only (not feature branches)
+
+---
+
+### Stage 6 — Deploy to Staging
+
+**Deployment method:** [e.g. Helm upgrade / kubectl apply / ecs deploy / Terraform apply]
+**Staging URL:** [URL]
+**Trigger:** Automatic on successful artefact build from `main`
+**Who can deploy to staging:** Any engineer (automatic)
+
+**Environment variables:** Managed in [Vault / AWS SSM / GitHub Secrets / etc.]
+**Staging is not production:** [Any differences in config, scale, or data — state them here]
+
+---
+
+### Stage 7 — Smoke Tests (Staging)
+
+**What runs:** [Description — e.g. "10 critical path tests covering login, core API endpoints, and payment flow"]
+**Tool:** [e.g. Playwright / Postman / custom script]
+**Pass criteria:** All smoke tests pass within [X seconds] timeout
+**Blocking:** Yes — production deploy will not proceed if smoke tests fail
+
+**Smoke test suite location:** [Link to test files or folder]
+
+---
+
+### Stage 8 — Manual Approval Gate
+
+**Required for:** [Production deploys / deploys affecting >X% of traffic / deploys to specific regions]
+**Who can approve:** [e.g. Any engineer on the team / Lead engineer / On-call engineer]
+**Approval timeout:** [e.g. 24 hours — auto-cancelled if no approval]
+**How to approve:** [GitHub Actions approve step / Slack command / other — with link]
+
+**When to withhold approval:**
+- Active incident in production
+- Deploy is outside the deployment window (see below)
+- On-call engineer has not been notified
+
+---
+
+### Stage 9 — Deploy to Production
+
+**Deployment method:** [Same as staging or different — specify]
+**Deployment window:** [e.g. Monday–Thursday 09:00–16:00 UTC — no deploys on Fridays or before bank holidays]
+**Canary / progressive rollout:** [Yes — X% initial traffic, full rollout after Y minutes / No — full deploy]
+**Deployment notifications:** [Slack channel — #deployments]
+
+**Who is on-call during deploy:** Deploying engineer is responsible until post-deploy checks pass.
+
+---
+
+### Stage 10 — Post-Deploy Checks
+
+**Automated checks (run for [X minutes] after deploy):**
+- [ ] Error rate: <[X]% (baseline: [Y]%)
+- [ ] P99 latency: <[X]ms (baseline: [Y]ms)
+- [ ] [Key business metric]: within [X]% of baseline
+
+**Where to watch:** [Datadog / Grafana / CloudWatch dashboard — link]
+
+**If a check fails:** See Rollback Procedure below.
+
+---
+
+## Environments
+
+| Environment | Purpose | Deploy trigger | URL | Data |
+|---|---|---|---|---|
+| **Dev** | Local development | Manual | localhost | Seeded test data |
+| **Staging** | Pre-production validation | Automatic (main) | [URL] | Anonymised prod copy |
+| **Production** | Live traffic | Manual approval | [URL] | Live data |
+
+---
+
+## Branching Strategy
+
+**Model:** [Trunk-based / GitFlow / GitHub Flow — describe briefly]
+
+| Branch | Purpose | Who merges | Deploy target |
+|---|---|---|---|
+| `main` | Production-ready code | PR + review | Staging → Production |
+| `feature/*` | Feature development | Author | None (CI only) |
+| `hotfix/*` | Critical production fixes | Lead engineer | Can bypass staging gate with approval |
+
+**Hotfix process:** [Describe when and how to use a hotfix branch — what level of incident justifies bypassing the standard process]
+
+---
+
+## Rollback Procedure
+
+**Automated rollback:** [Yes — triggered if post-deploy error rate exceeds [X]% / No — manual only]
+
+**Manual rollback steps:**
+```bash
+# 1. Identify the last known good image tag
+[command to list recent deployments]
+
+# 2. Deploy the previous version
+[deployment command with previous tag]
+
+# 3. Confirm rollback is live
+[smoke test command or health check URL]
+
+# 4. Notify the team
+[Slack command or template]
+```
+
+**Rollback decision authority:** Any engineer on-call can initiate a rollback without waiting for approval.
+
+**After a rollback:**
+1. Create a post-deploy incident report (see [incident-postmortem skill])
+2. Do not re-deploy the same commit without fixing the root cause
+3. Notify [stakeholder / support team] of the rollback and expected fix timeline
+
+---
+
+## Secrets and Configuration Management
+
+**Secret store:** [Vault / AWS SSM / GitHub Secrets / Doppler — specify]
+**How to add a new secret:**
+1. [Step 1]
+2. [Step 2]
+**Who has access:** [Role or team]
+**Rotation policy:** [How often secrets are rotated and who owns it]
+
+**Never do:** Commit secrets to source control, even in `.env` files. The pipeline includes secret scanning (Stage 4) which will flag this.
+
+---
+
+## Common Failures and Fixes
+
+| Failure | Likely cause | Fix |
+|---|---|---|
+| Build fails with "module not found" | Dependency not installed | Run `[install command]` and commit `lock file` |
+| Integration tests timeout | Test DB not seeded / external service down | Check [service] status; re-run pipeline |
+| Smoke tests fail after staging deploy | Environment variable missing | Check [config location]; compare staging and prod env vars |
+| Production deploy stuck at approval | Approver not notified | Tag `@[on-call handle]` in `#deployments` |
+| Post-deploy error rate spike | Bad deploy / upstream dependency | Check [dashboard]; initiate rollback if >5 min |
+
+---
+
+## On-Call Responsibilities During Deploy
+
+- The deploying engineer is responsible for monitoring post-deploy checks for [X minutes] after a production deploy
+- If you cannot monitor after deploying, hand off explicitly to another engineer in `#deployments`
+- For deploys outside business hours: only hotfixes — always page the on-call engineer before deploying
+
+---
+
+## Quality Checks
+
+- [ ] Every stage has a clear owner when it fails
+- [ ] Rollback procedure is tested — not theoretical
+- [ ] Secrets management section names the actual tool used (not "use secrets management")
+- [ ] Deployment window is specific — not "during business hours"
+- [ ] Post-deploy check thresholds are calibrated to actual baseline metrics
@@ -0,0 +1,332 @@
+---
+name: developer-onboarding-doc
+description: "Write a developer onboarding document for a service, codebase, or team. Use when asked to write a developer guide, service README, onboarding doc for a new engineer, codebase orientation, or getting-started guide for a technical team. Produces a structured doc covering service overview, architecture, local setup, key patterns, testing, deployment, and who to ask for what."
+---
+
+# Developer Onboarding Document Skill
+
+Produce a complete developer onboarding document for a service or team — covering everything a new engineer needs to be productive within their first week.
+
+A good onboarding doc is not a wiki dump. It answers the questions a new engineer actually has on day one, in the order they'll have them.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Team** responsible for it
+- **Tech stack** — language(s), framework(s), database(s), message queues, etc.
+- **Key external dependencies** — upstream services, third-party APIs
+- **Deployment target** — Kubernetes, ECS, Lambda, bare metal, etc.
+- **Local dev setup** — how to run locally (Docker Compose, local DB, etc.)
+- **Testing approach** — unit, integration, E2E; test commands
+- **Deployment process** — summary of how code gets to production
+- **On-call setup** — who's on-call, how alerts work
+- **Contacts** — tech lead, platform team, related service owners
+
+## Output Format
+
+---
+
+# Developer Onboarding: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Last updated:** [Date] | **Updated by:** [Name]
+
+> If something in this doc is wrong or out of date, fix it now — it will affect every engineer who onboards after you.
+
+---
+
+## What This Service Does
+
+[3–5 sentences. What problem does this service solve? Who calls it, and who does it call? What would break if this service went down?]
+
+**Service type:** [API / Background worker / Event consumer / Data pipeline / etc.]
+**Consumers:** [List internal services or external clients that depend on this service]
+**Dependencies:** [List upstream services, databases, and third-party APIs this service calls]
+
+**Architecture diagram:** [Link or embed — even a rough ASCII diagram helps]
+
+```
+[Caller A] ──→ [This Service] ──→ [Database]
+                      │
+                      └──→ [Downstream Service]
+```
+
+---
+
+## Codebase Orientation
+
+**Repository:** [Link]
+**Main branch:** `[main / master]`
+**Language:** [e.g. Go 1.22 / Node.js 20 / Python 3.12]
+**Framework:** [e.g. Express / FastAPI / Gin / Rails]
+
+### Key directories
+
+```
+[repo-root]/
+├── [src/ or cmd/]          # Application code
+│   ├── [handlers/]         # HTTP handlers / controllers
+│   ├── [services/]         # Business logic
+│   ├── [repository/]       # Database access layer
+│   └── [models/]           # Data models / types
+├── [tests/]                # Test files
+├── [migrations/]           # Database migrations
+├── [scripts/]              # Utility scripts
+├── [.github/workflows/]    # CI/CD pipeline definitions
+└── [docs/]                 # Additional documentation
+```
+
+**Where to start reading:** [Point to 2–3 key files that give the best orientation — e.g. `main.go`, `routes.js`, `app.py`]
+
+### Things that might surprise you
+
+- [Unusual pattern 1 — e.g. "We use event sourcing — state is derived from an event log, not stored directly"]
+- [Unusual pattern 2 — e.g. "Auth is handled by the gateway — this service trusts the `X-User-Id` header"]
+- [Unusual pattern 3 — any non-obvious decisions or legacy choices]
+
+---
+
+## Local Development Setup
+
+**Estimated setup time:** [X minutes for a fresh machine]
+
+### Prerequisites
+
+- [ ] [Tool 1] — version [X] — [install link]
+- [ ] [Tool 2] — version [X] — [install link]
+- [ ] Access to [repo / internal package registry] — request from [who]
+- [ ] [Any secrets or credentials needed] — request from [who]
+
+### Step-by-step setup
+
+```bash
+# 1. Clone the repo
+git clone [repo URL]
+cd [repo-name]
+
+# 2. Copy and configure environment variables
+cp .env.example .env
+# Edit .env — see "Environment Variables" section below
+
+# 3. Start dependencies (database, cache, etc.)
+[docker compose up -d / make deps / etc.]
+
+# 4. Install dependencies
+[npm install / go mod download / pip install -r requirements.txt]
+
+# 5. Run database migrations
+[migration command]
+
+# 6. Start the service
+[start command]
+
+# 7. Verify it's working
+curl http://localhost:[PORT]/health
+# Expected: {"status":"ok"}
+```
+
+**If this doesn't work:** Check [Troubleshooting section below] or ask in `#[channel]`.
+
+### Environment Variables
+
+| Variable | Required | Description | Example |
+|---|---|---|---|
+| `DATABASE_URL` | Yes | Connection string for the primary DB | `postgres://localhost:5432/[db]` |
+| `[VAR_2]` | Yes | [Description] | [Example] |
+| `[VAR_3]` | No | [Description — default value] | [Example] |
+
+**Secrets for local dev:** [Where to get them — e.g. "Run `[command]` to pull from Vault" or "Ask [person] in #[channel]"]
+
+### Useful local commands
+
+```bash
+[start command]           # Start the service
+[test command]            # Run all tests
+[lint command]            # Run linter
+[format command]          # Format code
+[migration command]       # Run pending migrations
+[seed command]            # Seed local database
+```
+
+---
+
+## Testing
+
+**Testing philosophy:** [e.g. "We test at the integration layer — unit tests for pure functions, integration tests for anything touching the DB or external services"]
+
+### Running tests
+
+```bash
+# All tests
+[test command]
+
+# Unit tests only
+[unit test command]
+
+# Integration tests (requires local deps running)
+[integration test command]
+
+# A specific test file or test case
+[test command with filter]
+```
+
+**Test coverage:** [X]% (minimum required to pass CI: [Y]%)
+**Coverage report:** [Where to find it]
+
+### Writing tests
+
+- **Unit tests:** [Where to put them — e.g. alongside source files as `*_test.go`]
+- **Integration tests:** [Where to put them — e.g. `tests/integration/`]
+- **Test database:** [How it works — e.g. "Each test gets a clean transaction that rolls back on teardown — see `tests/helpers/db.go`"]
+- **Mocking:** [Policy — e.g. "We mock at the repository layer — don't mock the DB directly"]
+
+---
+
+## Making Changes
+
+### Branching
+
+[Branch naming convention — e.g. `feature/[ticket-id]-short-description`, `fix/[ticket-id]-short-description`]
+
+### Before opening a PR
+
+- [ ] Tests pass locally
+- [ ] Linter passes (`[lint command]`)
+- [ ] New behaviour has test coverage
+- [ ] Any new environment variables are added to `.env.example` and documented
+- [ ] Database migrations are backward-compatible (old code can run against new schema)
+
+### Code review
+
+- **Reviewers:** [Who to request review from — e.g. "Any engineer on [team]; lead review required for auth changes"]
+- **Expected review time:** [X hours / 1 business day]
+- **PR template:** [Link or auto-generated by GitHub]
+
+### Database migrations
+
+```bash
+# Create a new migration
+[migration create command]
+
+# Apply pending migrations
+[migration up command]
+
+# Roll back last migration
+[migration down command]
+```
+
+**Migration rules:**
+- All migrations must be backward-compatible — old code must run against the new schema
+- Never rename or drop a column in a single migration — do it in two steps (add new, migrate data, drop old)
+- Test your rollback before merging
+
+---
+
+## Deployment
+
+**How code gets to production:** [1–2 sentence summary — link to full CI/CD playbook if it exists]
+
+1. Merge to `main` → automatic deploy to staging
+2. Smoke tests run on staging
+3. Manual approval → deploy to production
+4. Post-deploy monitoring for [X minutes]
+
+**Deployment docs:** [Link to CI/CD playbook or pipeline docs]
+
+**Who can deploy:** [Any engineer / Lead engineer / On-call engineer — specify]
+
+**Deployment channel:** `#[deployments channel]`
+
+---
+
+## Monitoring and Observability
+
+**Dashboard:** [Datadog / Grafana / CloudWatch — link]
+**Logs:** [Log aggregation tool and link — e.g. "Logs are in Datadog under service:[name]"]
+**Traces:** [Tracing tool and link if applicable]
+**Alerts:** [Where alerts fire — e.g. PagerDuty / Slack #alerts-[service]]
+
+**Key metrics to know:**
+- **Error rate:** Should be <[X]% (alert at [Y]%)
+- **P99 latency:** Should be <[X]ms
+- **[Business metric]:** [e.g. "Queue depth should be <100 items"]
+
+---
+
+## On-Call
+
+**On-call schedule:** [PagerDuty / Opsgenie link]
+**Who's on-call now:** [Link to current schedule or `#oncall` channel]
+**Escalation:** [On-call → [team lead] → [EM] — after [X] minutes unacknowledged]
+
+**If you get paged:**
+1. Acknowledge the alert
+2. Check [dashboard link] for the first clue
+3. Common alert runbooks: [link to oncall-runbook or runbook-writer output]
+4. If you can't resolve in [X minutes], escalate to [person/channel]
+
+---
+
+## Key Contacts
+
+| Role | Name | Best way to reach |
+|---|---|---|
+| Tech lead | [Name] | Slack: @[handle] |
+| On-call rotation | [Team] | PagerDuty / `#on-call` |
+| Platform / infra | [Team] | `#platform` Slack channel |
+| Database / DBA | [Name or team] | `#database` Slack channel |
+| [Upstream service] owner | [Name] | Slack: @[handle] |
+
+**Where to ask questions:**
+- General engineering: `#engineering`
+- This service specifically: `#[service-name]`
+- Urgent / production issues: `#incidents`
+
+---
+
+## Troubleshooting
+
+### "The service won't start locally"
+
+1. Check that Docker / dependencies are running: `[command]`
+2. Check `.env` is populated — missing values cause silent failures
+3. Check logs: `[log command]`
+4. Ask in `#[channel]`
+
+### "Tests are failing locally but passing in CI"
+
+- Check your local dependency versions match CI: `[version check command]`
+- Try a clean install: `[clean install command]`
+- Integration tests need local deps running — `[start deps command]`
+
+### "I can't access [internal tool / system]"
+
+- Request access through [process — e.g. Okta self-serve / ask your manager]
+
+### "Something looks wrong in production"
+
+1. Check [dashboard] for the error spike
+2. Check recent deploys in `#deployments`
+3. If it's an active incident, page on-call via [PagerDuty / Slack command]
+
+---
+
+## Further Reading
+
+- [Architecture Decision Records (ADRs)](./docs/decisions/) — why the codebase is the way it is
+- [API documentation](./docs/api/) or [link to external docs]
+- [Incident runbooks](./docs/runbooks/)
+- [CI/CD pipeline documentation](./docs/cicd/)
+- [Team working agreements](./docs/team/)
+
+---
+
+## Quality Checks
+
+- [ ] Local setup instructions work on a fresh machine — tested recently
+- [ ] Environment variables table is complete and accurate
+- [ ] "Things that might surprise you" captures the actual surprises (ask a recent joiner)
+- [ ] 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
@@ -0,0 +1,364 @@
+---
+name: oncall-runbook
+description: "Write an on-call runbook for a service — covering alert definitions, escalation paths, common incident responses, and on-call handoff procedures. Use when asked to write an on-call guide, create alert runbooks, document escalation procedures, or prepare an on-call handoff document. Produces a structured on-call runbook with per-alert response procedures, escalation matrix, diagnostic commands, and handoff template."
+---
+
+# On-Call Runbook Skill
+
+Produce a complete on-call runbook for a service — giving the on-call engineer everything they need to respond confidently to alerts at 3am, without having to ask anyone for help.
+
+A good on-call runbook reduces mean time to resolution (MTTR) by eliminating the "what do I do first?" problem. It is written for the on-call engineer who has just been paged and needs to act, not for someone calmly reading documentation.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Team** and tech lead name
+- **Alert list** — names of alerts that currently page on-call
+- **Monitoring setup** — Datadog / Grafana / CloudWatch / PagerDuty / etc.
+- **Common failure modes** — what breaks most often, and what fixes it
+- **Escalation contacts** — who to call when on-call can't resolve it
+- **Deployment setup** — can on-call roll back? How?
+- **Service dependencies** — what does this service depend on, and what depends on it?
+
+## Output Format
+
+---
+
+# On-Call Runbook: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**PagerDuty service:** [Link] | **Escalation policy:** [Policy name]
+**Last updated:** [Date] | **Next review:** [Date + 90 days]
+
+> **First time on-call for this service?** Read the [developer onboarding doc] first — it covers the architecture and how things work. This runbook assumes you understand the service.
+
+---
+
+## Quick Reference
+
+**Dashboard:** [Link — the first thing to open when paged]
+**Logs:** [Link — where to find logs]
+**Runbook index:** Jump to the alert that paged you → [Alert list below]
+**Can't resolve in 30 min?** Escalate to: [Name] via [Slack / PagerDuty]
+
+**Rollback command (memorise this):**
+```bash
+[rollback command — e.g. kubectl rollout undo deployment/[service-name]]
+```
+
+---
+
+## Escalation Matrix
+
+| Situation | Escalate to | How | After how long |
+|---|---|---|---|
+| Can't diagnose the alert | [Tech lead name] | Slack DM / Phone | 30 minutes |
+| Alert requires infra change | [Platform team] | `#platform` Slack | Immediately |
+| Customer-facing impact | [CSM / Support lead] | `#incidents` Slack | Immediately (P1) |
+| Database issue | [DBA or data team] | Slack / PagerDuty | Immediately |
+| [Specific dependency] down | [[Dependency] on-call] | PagerDuty / Slack | Immediately |
+| Extended outage (>1 hour) | [Engineering manager] | Phone | 1 hour |
+
+**Contacts:**
+
+| Name | Role | Slack | Phone |
+|---|---|---|---|
+| [Name] | Tech lead | @[handle] | [Number] |
+| [Name] | Engineering manager | @[handle] | [Number] |
+| [Name] | Platform / infra | @[handle] | [Number] |
+| [Platform team] | Infra on-call | `#platform` | PagerDuty |
+
+---
+
+## Service Architecture (Quick View)
+
+```
+[Upstream callers]
+        │
+        ▼
+[This Service]
+        │
+        ├──→ [Primary Database]
+        ├──→ [Cache — e.g. Redis]
+        └──→ [Downstream Service / Queue]
+```
+
+**If this service is down, these are affected:** [List downstream consumers]
+**If these are down, this service is affected:** [List upstream dependencies]
+
+---
+
+## Alert Runbooks
+
+### ALERT: [Alert Name 1 — e.g. HighErrorRate]
+
+**What it means:** [Plain English — e.g. "More than 5% of API requests are returning 5xx errors in the last 5 minutes"]
+**Severity:** P1 / P2 / P3
+**SLO impact:** Yes / No — [If yes: this alert means the error budget is burning at [X]× rate]
+
+**Step 1 — Acknowledge and assess**
+```bash
+# Check current error rate
+[query or dashboard link]
+
+# Check which endpoints are erroring
+[query or command]
+```
+
+**Step 2 — Check recent changes**
+```bash
+# Any deploys in the last hour?
+[command or link to deployment log]
+
+# Recent config changes?
+[where to check]
+```
+
+**Step 3 — Check dependencies**
+```bash
+# Is the database healthy?
+[health check command or link]
+
+# Is [downstream service] healthy?
+[health check command or link]
+```
+
+**Step 4 — Diagnose**
+
+| If you see | It means | Do this |
+|---|---|---|
+| [Error pattern 1] | [Cause] | [Action] |
+| [Error pattern 2] | [Cause] | [Action] |
+| [Error pattern 3] | [Cause] | [Action] |
+| No clear pattern | Unknown cause | Escalate to [name] |
+
+**Step 5 — Fix or mitigate**
+```bash
+# If caused by bad deploy — roll back:
+[rollback command]
+
+# If caused by [specific issue]:
+[fix command]
+
+# If caused by upstream dependency:
+[mitigation — e.g. enable circuit breaker, reduce traffic, etc.]
+```
+
+**After resolving:**
+- [ ] Confirm error rate has returned to baseline
+- [ ] Check no downstream services were affected
+- [ ] If P1: open a post-incident review — see [incident-postmortem skill]
+- [ ] Update `#incidents` with resolution summary
+
+---
+
+### ALERT: [Alert Name 2 — e.g. HighLatency]
+
+**What it means:** [e.g. "P99 response time has exceeded 1s for more than 3 consecutive minutes"]
+**Severity:** P1 / P2 / P3
+**SLO impact:** Yes — latency SLO breach
+
+**Step 1 — Assess scope**
+```bash
+# Check which endpoints are slow
+[query or dashboard — broken down by endpoint]
+
+# Check if latency is across all regions or localised
+[query or command]
+```
+
+**Step 2 — Common causes and fixes**
+
+| Cause | Signal | Fix |
+|---|---|---|
+| Database slow queries | DB latency spike on dashboard | [Check slow query log: `command`] |
+| Cache miss storm | Cache hit rate drops on dashboard | [command or action] |
+| Memory pressure / GC | High memory on service dashboard | [command or action — e.g. restart, scale up] |
+| Upstream service slow | Trace shows time in external call | Escalate to [service] on-call |
+| Traffic spike | Request rate spike on dashboard | [Scale up: `command`] |
+
+**Step 3 — Escalate if unresolved in 20 minutes**
+Page [Tech lead] via PagerDuty / Slack.
+
+---
+
+### ALERT: [Alert Name 3 — e.g. DatabaseConnectionPoolExhausted]
+
+**What it means:** [e.g. "The service has used all available database connections — new requests will fail"]
+**Severity:** P1
+**SLO impact:** Yes — will cause errors immediately
+
+**Immediate mitigation:**
+```bash
+# Restart the service to flush stale connections
+[restart command]
+
+# Check current connection count
+[DB connection query]
+```
+
+**Diagnose root cause after stabilising:**
+```bash
+# Check for long-running queries holding connections
+[query]
+
+# Check if a recent deploy changed connection pool config
+[where to check]
+```
+
+**Resolution:** [e.g. "Increase pool size in config / kill long-running queries / scale the service"]
+
+---
+
+### ALERT: [Alert Name 4 — e.g. QueueBacklogHigh / ConsumerLag]
+
+**What it means:** [e.g. "The message queue backlog exceeds 10,000 messages — consumers are not keeping up"]
+**Severity:** P2
+**SLO impact:** Depends — if queue backs up, downstream systems will receive delayed data
+
+**Step 1 — Check consumer health**
+```bash
+# Are consumers running?
+[command]
+
+# Consumer error rate?
+[dashboard or query]
+```
+
+**Step 2 — Check message contents**
+```bash
+# Are there poison messages causing retries?
+[command to inspect dead-letter queue or failed messages]
+```
+
+**Step 3 — Options**
+
+| If | Then |
+|---|---|
+| Consumers are down | Restart consumers: `[command]` |
+| Poison message in queue | Move to DLQ: `[command]` |
+| Consumers healthy but slow | Scale consumers: `[command]` |
+| Upstream producing too fast | Escalate to [upstream service] owner |
+
+---
+
+### ALERT: [Add additional alerts following the same pattern]
+
+---
+
+## Diagnostic Cheat Sheet
+
+Common commands for quick diagnosis. Paste and run without modification.
+
+```bash
+# Service health
+[health check command]
+
+# Recent logs (last 100 lines)
+[log command]
+
+# Error logs only
+[error log filter command]
+
+# Current pod / instance status
+[kubectl get pods / aws ecs describe-tasks / etc.]
+
+# Restart the service
+[restart command]
+
+# Roll back to previous version
+[rollback command]
+
+# Database connection count
+[DB query]
+
+# Cache hit rate
+[cache stats command]
+
+# Current request rate
+[metrics query]
+```
+
+---
+
+## Useful Dashboard Links
+
+| Dashboard | URL | Use it to |
+|---|---|---|
+| Service overview | [Link] | First stop — error rate, latency, request rate |
+| Database | [Link] | Connection count, slow queries, replication lag |
+| Infrastructure | [Link] | CPU, memory, disk |
+| Queue / consumers | [Link] | Backlog depth, consumer throughput |
+| Upstream dependencies | [Link] | Dependency health at a glance |
+
+---
+
+## Incident Communication
+
+When you declare an incident:
+
+**Post to `#incidents` immediately:**
+```
+🔴 INCIDENT — [Service Name]
+Status: Investigating
+Impact: [Who is affected and how]
+Paged: [Your name]
+Next update: [Time — max 30 min from now]
+```
+
+**Update every 30 minutes while active:**
+```
+🔴 UPDATE — [Service Name] — [Time]
+Status: [Investigating / Identified / Mitigating / Resolved]
+Latest: [One sentence on what you found or did]
+Next update: [Time]
+```
+
+**On resolution:**
+```
+✅ RESOLVED — [Service Name] — [Time]
+Duration: [X minutes]
+Impact: [Summary of who was affected]
+Cause: [One sentence]
+Follow-up: [PIR required? Yes/No — link when created]
+```
+
+---
+
+## On-Call Handoff
+
+Use this template at the end of every on-call shift:
+
+```
+--- ON-CALL HANDOFF: [Service Name] ---
+Date: [Date]
+Outgoing: [Your name]
+Incoming: [Next on-call name]
+
+INCIDENTS THIS SHIFT:
+- [Incident summary — date, duration, cause, resolution, follow-up required]
+
+OPEN ISSUES TO WATCH:
+- [Anything not fully resolved / trending in the wrong direction]
+
+CHANGES SINCE LAST HANDOFF:
+- [Deploys, config changes, infra changes that affect on-call awareness]
+
+RUNBOOK GAPS FOUND:
+- [Anything you had to figure out that isn't documented — please add it]
+
+ANYTHING ELSE:
+- [Notes for incoming on-call]
+```
+
+---
+
+## Quality Checks
+
+- [ ] Every alert that pages on-call has a runbook entry — no alert is missing
+- [ ] Rollback command is accurate and tested recently
+- [ ] Escalation contacts have current phone numbers and Slack handles
+- [ ] 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
@@ -0,0 +1,231 @@
+---
+name: slo-error-budget
+description: "Define Service Level Objectives (SLOs) and an error budget policy for a service. Use when asked to write SLOs, define SLIs, calculate an error budget, set reliability targets, or create an error budget policy. Produces a complete SLO document with SLI definitions, target calculation, error budget policy, burn rate alerts, and review cadence."
+---
+
+# SLO and Error Budget Skill
+
+Produce a complete, implementable SLO document for a service — covering what to measure, what target to set, how to calculate the error budget, and what to do when it burns.
+
+A good SLO is not a target to hit. It is an agreement about what reliability means for your users — and a framework for making principled trade-offs between reliability and velocity.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and brief description of what it does
+- **Primary users** — who depends on this service and how
+- **User-facing interactions** to protect — e.g. API calls, page loads, transactions
+- **Current reliability data** — error rate, latency, uptime (last 30–90 days if available)
+- **Existing on-call setup** — who responds to alerts?
+- **Deployment frequency** — how often does the team ship?
+- **Any existing SLAs** with customers — these constrain SLO targets
+
+## Key Definitions
+
+Always establish these before writing the SLO:
+
+| Term | Definition |
+|---|---|
+| **SLI** (Service Level Indicator) | The metric being measured — e.g. "% of requests completing successfully in <500ms" |
+| **SLO** (Service Level Objective) | The target for that metric — e.g. "99.5% of requests" |
+| **SLA** (Service Level Agreement) | The contractual commitment to customers — must be looser than the SLO |
+| **Error budget** | The allowed headroom below 100% — the budget for planned and unplanned downtime |
+| **Burn rate** | How fast the error budget is being consumed |
+
+---
+
+## Output Format
+
+---
+
+# SLO Document: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Owner:** [Name / role] | **Approved by:** [Name]
+**Effective date:** [Date] | **Review date:** [Date + 3 months]
+**Version:** [1.0]
+
+---
+
+## Why This SLO Exists
+
+[2–3 sentences. What reliability problem are we solving? What was happening before this SLO that made us need it? What decision-making does this SLO enable?]
+
+---
+
+## Service Overview
+
+**What this service does:** [One sentence]
+**Who depends on it:** [Internal teams / external customers / both — describe]
+**Critical user journeys protected by this SLO:**
+1. [Journey 1 — e.g. "User completes a payment"]
+2. [Journey 2]
+3. [Journey 3]
+
+---
+
+## SLIs — What We Measure
+
+Define one SLI per user journey or reliability dimension. Keep it to 3–5 SLIs maximum.
+
+### SLI 1: [Name — e.g. Request Success Rate]
+
+| Field | Detail |
+|---|---|
+| **What it measures** | [e.g. "% of API requests that return a non-5xx response"] |
+| **Good event definition** | [e.g. "HTTP response with status 2xx or 4xx, completed within 500ms"] |
+| **Bad event definition** | [e.g. "HTTP response with status 5xx, or any response taking >500ms"] |
+| **Measurement source** | [e.g. "Application load balancer access logs / Datadog APM / Prometheus"] |
+| **Measured over** | Rolling 28-day window |
+| **Exclusions** | [e.g. "Health check endpoints excluded / Requests during planned maintenance excluded"] |
+
+### SLI 2: [Name — e.g. Latency]
+
+| Field | Detail |
+|---|---|
+| **What it measures** | [e.g. "P99 response time for the /checkout endpoint"] |
+| **Good event definition** | [e.g. "Request completes in ≤500ms at P99"] |
+| **Bad event definition** | [e.g. "Request takes >500ms at P99"] |
+| **Measurement source** | [Source] |
+| **Measured over** | Rolling 28-day window |
+| **Exclusions** | [Any exclusions] |
+
+### SLI 3: [Name — e.g. Data Freshness / Queue Depth / etc.]
+
+[Same structure]
+
+---
+
+## SLO Targets
+
+| SLI | Target | Window | Error Budget |
+|---|---|---|---|
+| [SLI 1 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+| [SLI 2 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+| [SLI 3 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+
+**How targets were set:**
+- Historical baseline (last 90 days): [X]%
+- Target is set [above / at] historical baseline to [improve reliability / reflect current reality while formalising the commitment]
+- Rationale: [1–2 sentences]
+
+**What 100% is NOT the target:** [Brief explanation of why targeting 100% is counterproductive — it discourages feature development and doesn't reflect user reality]
+
+---
+
+## Error Budget Calculation
+
+**For SLI 1 ([Name]), at [X]% target:**
+
+```
+Error budget = (100% - SLO target) × measurement window
+             = (100% - [X]%) × 28 days × 24 hours × 60 minutes
+             = [Y]% × [Z total minutes]
+             = [N] minutes of allowed failure per 28-day window
+```
+
+**In plain terms:** We can afford [N] minutes of [bad events] in any rolling 28-day window before we breach the SLO.
+
+---
+
+## Burn Rate Alerts
+
+Burn rate = how fast the error budget is being consumed relative to the budget window.
+A burn rate of 1 = consuming the budget at exactly the rate that would exhaust it over 28 days.
+
+| Alert | Burn rate | Window | Severity | Response |
+|---|---|---|---|---|
+| Page (critical) | >14× | 1 hour | P1 | Page on-call immediately — budget exhausted in <2 hours |
+| Page (high) | >6× | 6 hours | P2 | Page on-call — budget exhausted in <5 days |
+| Ticket (warning) | >3× | 3 days | P3 | Create ticket — review at next team meeting |
+| Info | >1× | 28 days | Info | Log only — budget on track to exhaust by end of window |
+
+**Alert implementation:** [Link to alert config in monitoring tool — e.g. Datadog, Prometheus/Alertmanager, Grafana]
+
+---
+
+## Error Budget Policy
+
+This policy defines what to do with the error budget — both when it's healthy and when it's burning.
+
+### When budget is healthy (>50% remaining)
+
+- Feature development and deployments proceed at normal pace
+- The team may take on riskier experiments
+- Reliability improvements are scheduled but not urgent
+
+### When budget is at risk (25–50% remaining)
+
+- Deployment frequency reduced — team ships only well-tested changes
+- One reliability improvement added to current sprint
+- Weekly error budget review added to team standup
+
+### When budget is nearly exhausted (<25% remaining)
+
+- Feature work paused in favour of reliability improvements
+- No new deployments without explicit on-call approval
+- Daily review of error budget burn rate
+- CSM / support notified to manage customer expectations
+
+### When budget is exhausted (0% remaining — SLO breached)
+
+- All feature work stops
+- On-call engineer and engineering manager notified immediately
+- Post-incident review (PIR) required within 5 business days
+- SLO target may be temporarily relaxed (with stakeholder approval) while root cause is addressed
+
+---
+
+## Dashboard and Reporting
+
+**SLO dashboard:** [Link to Datadog / Grafana / etc. dashboard]
+
+**Metrics exposed:**
+- Current SLO compliance (rolling 28-day)
+- Error budget remaining (% and minutes)
+- Burn rate (current and trend)
+- Incident count and MTTR this window
+
+**Reporting cadence:**
+
+| Audience | Frequency | Format |
+|---|---|---|
+| Engineering team | Weekly | Slack summary — #[service]-slo |
+| Engineering manager | Monthly | SLO review meeting |
+| Stakeholders / customers | Quarterly | SLO compliance summary |
+
+---
+
+## Exclusions and Edge Cases
+
+**Planned maintenance:** Error budget is not consumed during pre-announced maintenance windows. Maintenance must be communicated [X hours] in advance via [channel].
+
+**Dependency failures:** If SLO breach is caused by an upstream dependency outside our control, document it — but it still counts against our error budget (our users don't distinguish between our failures and our dependencies' failures).
+
+**Force majeure:** [Policy for cloud provider outages, major infrastructure events]
+
+---
+
+## SLO Review Cadence
+
+| Review | When | Who | Output |
+|---|---|---|---|
+| Error budget review | Weekly | Team | Budget health check — adjust if burning fast |
+| SLO target review | Quarterly | Team + EM | Adjust targets if baseline has shifted significantly |
+| Annual SLO audit | Annually | Team + Stakeholders | Review SLIs — are we measuring the right things? |
+
+**When to change the SLO target:**
+- Historical baseline has improved significantly and target no longer reflects real reliability
+- User feedback indicates the target is misaligned with what users actually experience
+- The SLO is being gamed (metric is healthy but users are unhappy)
+
+---
+
+## Quality Checks
+
+- [ ] SLIs are user-facing — they measure what users experience, not internal system metrics
+- [ ] Good and bad events are precisely defined — no ambiguity about what counts
+- [ ] Targets are based on historical data, not aspirational round numbers
+- [ ] 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
@@ -0,0 +1,179 @@
+---
+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."
+---
+
+# Churn Analysis Skill
+
+Produce a structured churn analysis that goes beyond the headline rate — identifying why customers leave, which segments are most at risk, and what interventions will have the highest impact on retention.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Time period** being analysed (e.g. Q1, last 12 months)
+- **Total customers at start of period** and **customers churned**
+- **ARR or revenue lost** to churn
+- **Churn reasons data** — exit survey results, CSM notes, support data, or sales loss reasons
+- **Customer segments** — by tier, industry, cohort, or product line
+- **Current retention rate** if known
+- **Any recent changes** — pricing, product, support model — that may have affected churn
+
+## Churn Categories
+
+Always classify churn before analysing it:
+
+| Category | Definition |
+|---|---|
+| **Voluntary — avoidable** | Customer left due to a problem we could have addressed (product gaps, poor onboarding, relationship failures) |
+| **Voluntary — unavoidable** | Customer left for reasons outside our control (budget cuts, acquisition, company shutdown) |
+| **Involuntary** | Payment failure, contract non-renewal by mistake, admin error |
+
+The interventions for each category are different. Conflating them leads to wrong conclusions.
+
+## Output Format
+
+---
+
+# Churn Analysis: [Product / Segment / Company]
+**Period:** [Start date] — [End date]
+**Prepared by:** [Name] | **Date:** [Date]
+
+---
+
+## Headline Numbers
+
+| Metric | Value |
+|---|---|
+| Customers at start of period | [N] |
+| Customers churned | [N] |
+| **Customer churn rate** | **[X]%** |
+| ARR at start of period | £/$/€[X] |
+| ARR lost to churn | £/$/€[X] |
+| **Revenue churn rate (gross)** | **[X]%** |
+| ARR from expansions (same period) | £/$/€[X] |
+| **Net revenue retention (NRR)** | **[X]%** |
+
+**Benchmark context:**
+- Customer churn rate: [X]% vs. industry benchmark [Y]% — [above / below / in line]
+- NRR: [X]% — [What this means: above 100% = expansion offsets churn; below 100% = shrinking base]
+
+---
+
+## Churn Breakdown by Category
+
+| Category | Customers | % of churn | ARR lost |
+|---|---|---|---|
+| Voluntary — avoidable | [N] | [X]% | £/$/€[X] |
+| Voluntary — unavoidable | [N] | [X]% | £/$/€[X] |
+| Involuntary | [N] | [X]% | £/$/€[X] |
+| **Total** | **[N]** | **100%** | **£/$/€[X]** |
+
+**Avoidable churn as % of total churn:** [X]% — this is the number we can actually influence.
+
+---
+
+## Churn Reasons — Avoidable Churn Only
+
+Rank by frequency. Include ARR weight where data allows.
+
+| Reason | Count | % of avoidable churn | ARR lost | Representative quote |
+|---|---|---|---|---|
+| [Reason 1 — e.g. "Product missing key feature"] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 2] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 3] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| [Reason 4] | [N] | [X]% | £/$/€[X] | "[Quote]" |
+| Other | [N] | [X]% | £/$/€[X] | — |
+
+**Theme synthesis:** [2–3 sentences grouping the top reasons into 2–3 themes. E.g. "The top three reasons cluster around two themes: product gaps in [area] (affecting X% of avoidable churn) and onboarding failures where customers never achieved value (Y%)."]
+
+---
+
+## Churn by Segment
+
+Identify which segments over- or under-index for churn.
+
+### By Tier
+
+| Tier | Churn rate | vs. Overall | Notes |
+|---|---|---|---|
+| Enterprise | [X]% | +/-[X]pp | |
+| Mid-Market | [X]% | +/-[X]pp | |
+| SMB | [X]% | +/-[X]pp | |
+
+### By Cohort (Acquisition Year)
+
+| Cohort | Churn rate | Notes |
+|---|---|---|
+| [Year 1] | [X]% | |
+| [Year 2] | [X]% | |
+| [Year 3] | [X]% | |
+
+### By Industry / Use Case (if data available)
+
+| Segment | Churn rate | Notes |
+|---|---|---|
+| [Segment 1] | [X]% | |
+| [Segment 2] | [X]% | |
+
+**Key pattern:** [Which segment has the highest churn rate and what likely explains it]
+
+---
+
+## Timing Analysis
+
+- **Average contract length before churn:** [X months]
+- **Highest-risk moment:** [e.g. "Month 3 — when trial value has worn off but full adoption hasn't happened"]
+- **Churn timing distribution:**
+
+| When churn occurred | % of churned accounts |
+|---|---|
+| 0–3 months | [X]% |
+| 3–6 months | [X]% |
+| 6–12 months | [X]% |
+| 12+ months | [X]% |
+
+---
+
+## Early Warning Signals
+
+Based on the churned accounts, identify the signals that preceded churn (and could have triggered earlier intervention):
+
+| Signal | Lead time before churn | How to detect |
+|---|---|---|
+| [Signal 1 — e.g. "DAU/MAU dropped below 15%"] | [~X weeks] | [Usage dashboard / alert] |
+| [Signal 2 — e.g. "No QBR in 90+ days"] | [~X weeks] | [CRM flag] |
+| [Signal 3 — e.g. "Champion left the account"] | [~X weeks] | [LinkedIn alert / CSM tracking] |
+| [Signal 4] | [~X weeks] | [Detection method] |
+
+---
+
+## Intervention Recommendations
+
+Ranked by estimated impact × feasibility.
+
+| Intervention | Addresses | Est. churn reduction | Effort | Owner |
+|---|---|---|---|---|
+| [Intervention 1 — e.g. "Improve onboarding for [segment] with dedicated 30-day check-in"] | [Reason 1] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+| [Intervention 2] | [Reason 2] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+| [Intervention 3] | [Reason 3] | [X accounts / £X ARR] | Low / Med / High | [Team] |
+
+**Priority call:** [Which one intervention, if implemented this quarter, would have the biggest impact and why]
+
+---
+
+## What We Don't Know (Data Gaps)
+
+- [Data gap 1 — e.g. "Exit survey response rate is only 30% — the reasons data may not be representative"]
+- [Data gap 2 — e.g. "No product usage data for SMB tier — can't confirm usage signal correlation"]
+- [Data gap 3]
+
+---
+
+## Quality Checks
+
+- [ ] Churn rate is correctly calculated (churned ÷ starting cohort, not end-of-period total)
+- [ ] Avoidable and unavoidable churn are separated — interventions target avoidable churn only
+- [ ] Churn reasons are customer-reported, not internally assumed
+- [ ] Segment analysis identifies which segments over-index — not just averages
+- [ ] Early warning signals are specific and detectable, not generic ("low engagement")
+- [ ] Interventions link directly to the top churn reasons — no recommendations without a root cause match
@@ -0,0 +1,301 @@
+---
+name: cicd-playbook
+description: "Write a CI/CD pipeline playbook for a service or team. Use when asked to document a CI/CD pipeline, write a deployment process, define release gates, document build and test stages, or create a deployment guide. Produces a structured playbook covering pipeline stages, environment definitions, deployment gates, rollback procedures, and on-call responsibilities."
+---
+
+# CI/CD Playbook Skill
+
+Produce a complete, actionable CI/CD playbook for a service or team — covering everything a new engineer needs to understand, contribute to, and operate the pipeline safely.
+
+A good playbook is not a diagram. It is a document that answers: what runs, when, why, who owns it, and what to do when it breaks.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and brief description
+- **Tech stack** — language, framework, containerisation (Docker, etc.)
+- **Source control** — GitHub / GitLab / Bitbucket, branching strategy
+- **CI platform** — GitHub Actions / CircleCI / Jenkins / BuildKite / other
+- **CD platform / deployment target** — Kubernetes, ECS, Lambda, Heroku, VMs, etc.
+- **Environments** — e.g. dev, staging, production (and any canary / feature environments)
+- **Deployment frequency** — how often does the team ship?
+- **Any existing gates** — manual approvals, smoke tests, feature flags
+- **On-call setup** — who's responsible during deploys?
+
+## Output Format
+
+---
+
+# CI/CD Playbook: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Last updated:** [Date] | **Owner:** [Name / role]
+**Pipeline platform:** [CI tool] → [CD tool / platform]
+
+---
+
+## Overview
+
+[2–3 sentences describing what this service does and why the CI/CD pipeline is structured the way it is. Include the deployment target and how frequently the team ships.]
+
+**Deployment frequency:** [Multiple times per day / Daily / Weekly / On-demand]
+**Average pipeline duration:** [X minutes]
+**Rollback time (p95):** [X minutes]
+
+---
+
+## Pipeline Stages
+
+```
+[Branch push]
+    │
+    ▼
+[1. Build & Lint] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[2. Unit Tests] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[3. Integration Tests] ──fail──▶ ❌ Block PR
+    │
+    ▼
+[4. Security Scan] ──fail──▶ ⚠️ [Block / Warn — specify]
+    │
+    ▼
+[5. Build Artefact / Container Image]
+    │
+    ▼
+[6. Deploy to Staging] ──fail──▶ ❌ Block promotion
+    │
+    ▼
+[7. Smoke Tests (Staging)]
+    │
+    ▼
+[8. Manual Approval Gate] ──(if required)
+    │
+    ▼
+[9. Deploy to Production] ──fail──▶ 🔁 Auto-rollback (if configured)
+    │
+    ▼
+[10. Post-deploy checks]
+```
+
+---
+
+## Stage Definitions
+
+### Stage 1 — Build & Lint
+
+**What runs:** [Build command] + [Linter — e.g. ESLint, golangci-lint, flake8]
+**Trigger:** Every commit to any branch
+**Blocking:** Yes — PR cannot be merged if this fails
+**Typical duration:** [X minutes]
+**Owner if it fails:** PR author
+
+**Common failure causes:**
+- [e.g. Missing dependency — run `npm install` locally before pushing]
+- [e.g. Lint rule violation — run `npm run lint --fix` to auto-fix most issues]
+
+---
+
+### Stage 2 — Unit Tests
+
+**What runs:** [Test command — e.g. `npm test`, `go test ./...`, `pytest`]
+**Coverage gate:** [X]% minimum — pipeline fails below this threshold
+**Trigger:** Every commit
+**Blocking:** Yes
+**Typical duration:** [X minutes]
+
+**Coverage report:** [Where to find it — e.g. uploaded to Codecov, available in CI artifacts]
+
+---
+
+### Stage 3 — Integration Tests
+
+**What runs:** [Test suite description — e.g. "API integration tests against a test database using Docker Compose"]
+**Environment:** [Ephemeral test environment / shared test DB / etc.]
+**Trigger:** Every commit to `main` and feature branches targeting `main`
+**Blocking:** Yes
+**Typical duration:** [X minutes]
+
+**If slow:** [e.g. "Integration tests can be skipped locally with `SKIP_INTEGRATION=true` — never skip in CI"]
+
+---
+
+### Stage 4 — Security Scan
+
+**Tools:** [e.g. Snyk, Trivy, OWASP Dependency Check, Semgrep]
+**What it checks:** [Dependency vulnerabilities / SAST / secrets detection — list what applies]
+**Blocking on:** Critical and High severity findings
+**Non-blocking on:** Medium and Low (flagged, not blocking)
+**Trigger:** Every commit to `main`
+
+**How to handle a flagged vulnerability:**
+1. Check if a fix is available — upgrade the dependency
+2. If no fix available, open a security ticket and add a suppression with justification
+3. Never suppress without a ticket and owner
+
+---
+
+### Stage 5 — Build Artefact
+
+**What is produced:** [Docker image / binary / zip — be specific]
+**Registry:** [ECR / GCR / Docker Hub / Artifactory — URL]
+**Tagging convention:** `[service-name]:[git-sha]` (also tagged `:latest` on `main`)
+**Trigger:** Commits to `main` only (not feature branches)
+
+---
+
+### Stage 6 — Deploy to Staging
+
+**Deployment method:** [e.g. Helm upgrade / kubectl apply / ecs deploy / Terraform apply]
+**Staging URL:** [URL]
+**Trigger:** Automatic on successful artefact build from `main`
+**Who can deploy to staging:** Any engineer (automatic)
+
+**Environment variables:** Managed in [Vault / AWS SSM / GitHub Secrets / etc.]
+**Staging is not production:** [Any differences in config, scale, or data — state them here]
+
+---
+
+### Stage 7 — Smoke Tests (Staging)
+
+**What runs:** [Description — e.g. "10 critical path tests covering login, core API endpoints, and payment flow"]
+**Tool:** [e.g. Playwright / Postman / custom script]
+**Pass criteria:** All smoke tests pass within [X seconds] timeout
+**Blocking:** Yes — production deploy will not proceed if smoke tests fail
+
+**Smoke test suite location:** [Link to test files or folder]
+
+---
+
+### Stage 8 — Manual Approval Gate
+
+**Required for:** [Production deploys / deploys affecting >X% of traffic / deploys to specific regions]
+**Who can approve:** [e.g. Any engineer on the team / Lead engineer / On-call engineer]
+**Approval timeout:** [e.g. 24 hours — auto-cancelled if no approval]
+**How to approve:** [GitHub Actions approve step / Slack command / other — with link]
+
+**When to withhold approval:**
+- Active incident in production
+- Deploy is outside the deployment window (see below)
+- On-call engineer has not been notified
+
+---
+
+### Stage 9 — Deploy to Production
+
+**Deployment method:** [Same as staging or different — specify]
+**Deployment window:** [e.g. Monday–Thursday 09:00–16:00 UTC — no deploys on Fridays or before bank holidays]
+**Canary / progressive rollout:** [Yes — X% initial traffic, full rollout after Y minutes / No — full deploy]
+**Deployment notifications:** [Slack channel — #deployments]
+
+**Who is on-call during deploy:** Deploying engineer is responsible until post-deploy checks pass.
+
+---
+
+### Stage 10 — Post-Deploy Checks
+
+**Automated checks (run for [X minutes] after deploy):**
+- [ ] Error rate: <[X]% (baseline: [Y]%)
+- [ ] P99 latency: <[X]ms (baseline: [Y]ms)
+- [ ] [Key business metric]: within [X]% of baseline
+
+**Where to watch:** [Datadog / Grafana / CloudWatch dashboard — link]
+
+**If a check fails:** See Rollback Procedure below.
+
+---
+
+## Environments
+
+| Environment | Purpose | Deploy trigger | URL | Data |
+|---|---|---|---|---|
+| **Dev** | Local development | Manual | localhost | Seeded test data |
+| **Staging** | Pre-production validation | Automatic (main) | [URL] | Anonymised prod copy |
+| **Production** | Live traffic | Manual approval | [URL] | Live data |
+
+---
+
+## Branching Strategy
+
+**Model:** [Trunk-based / GitFlow / GitHub Flow — describe briefly]
+
+| Branch | Purpose | Who merges | Deploy target |
+|---|---|---|---|
+| `main` | Production-ready code | PR + review | Staging → Production |
+| `feature/*` | Feature development | Author | None (CI only) |
+| `hotfix/*` | Critical production fixes | Lead engineer | Can bypass staging gate with approval |
+
+**Hotfix process:** [Describe when and how to use a hotfix branch — what level of incident justifies bypassing the standard process]
+
+---
+
+## Rollback Procedure
+
+**Automated rollback:** [Yes — triggered if post-deploy error rate exceeds [X]% / No — manual only]
+
+**Manual rollback steps:**
+```bash
+# 1. Identify the last known good image tag
+[command to list recent deployments]
+
+# 2. Deploy the previous version
+[deployment command with previous tag]
+
+# 3. Confirm rollback is live
+[smoke test command or health check URL]
+
+# 4. Notify the team
+[Slack command or template]
+```
+
+**Rollback decision authority:** Any engineer on-call can initiate a rollback without waiting for approval.
+
+**After a rollback:**
+1. Create a post-deploy incident report (see [incident-postmortem skill])
+2. Do not re-deploy the same commit without fixing the root cause
+3. Notify [stakeholder / support team] of the rollback and expected fix timeline
+
+---
+
+## Secrets and Configuration Management
+
+**Secret store:** [Vault / AWS SSM / GitHub Secrets / Doppler — specify]
+**How to add a new secret:**
+1. [Step 1]
+2. [Step 2]
+**Who has access:** [Role or team]
+**Rotation policy:** [How often secrets are rotated and who owns it]
+
+**Never do:** Commit secrets to source control, even in `.env` files. The pipeline includes secret scanning (Stage 4) which will flag this.
+
+---
+
+## Common Failures and Fixes
+
+| Failure | Likely cause | Fix |
+|---|---|---|
+| Build fails with "module not found" | Dependency not installed | Run `[install command]` and commit `lock file` |
+| Integration tests timeout | Test DB not seeded / external service down | Check [service] status; re-run pipeline |
+| Smoke tests fail after staging deploy | Environment variable missing | Check [config location]; compare staging and prod env vars |
+| Production deploy stuck at approval | Approver not notified | Tag `@[on-call handle]` in `#deployments` |
+| Post-deploy error rate spike | Bad deploy / upstream dependency | Check [dashboard]; initiate rollback if >5 min |
+
+---
+
+## On-Call Responsibilities During Deploy
+
+- The deploying engineer is responsible for monitoring post-deploy checks for [X minutes] after a production deploy
+- If you cannot monitor after deploying, hand off explicitly to another engineer in `#deployments`
+- For deploys outside business hours: only hotfixes — always page the on-call engineer before deploying
+
+---
+
+## Quality Checks
+
+- [ ] Every stage has a clear owner when it fails
+- [ ] Rollback procedure is tested — not theoretical
+- [ ] Secrets management section names the actual tool used (not "use secrets management")
+- [ ] Deployment window is specific — not "during business hours"
+- [ ] Post-deploy check thresholds are calibrated to actual baseline metrics
@@ -0,0 +1,176 @@
+---
+name: cs-escalation-brief
+description: "Write a structured escalation brief for an at-risk customer account. Use when an account has escalated, when a customer is threatening churn, when a P1 customer issue needs executive attention, or when preparing an internal save play. Produces a crisp escalation brief with account context, timeline, root cause, business impact, and a clear resolution plan."
+---
+
+# Customer Escalation Brief Skill
+
+Produce a clear, concise escalation brief that gives internal stakeholders — VP CS, CCO, product leadership, or the CEO — everything they need to understand the situation, make decisions, and act fast.
+
+A good escalation brief is not a complaint. It is a professional document that states the facts, assigns accountability honestly, and proposes a specific resolution plan.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name**, tier, and ARR
+- **CSM name** and account owner
+- **Nature of the escalation** — what happened, what the customer is saying
+- **Timeline** of events leading to escalation
+- **Customer contact** who escalated (name, role, influence level)
+- **What the customer wants** — their stated ask
+- **What we believe the root cause is**
+- **What has already been done** to address the situation
+- **Renewal date** and current renewal risk assessment
+
+## Escalation Levels
+
+Calibrate urgency and audience based on escalation level:
+
+| Level | Trigger | Audience | Response time |
+|---|---|---|---|
+| L1 — Account Risk | Customer expressing dissatisfaction; renewal at risk | CSM + CS Manager | 24 hours |
+| L2 — Executive Escalation | Customer escalated to their exec; requesting vendor exec involvement | VP CS + Account Exec | 4 hours |
+| L3 — Churn Risk | Customer has issued notice or is in active churn conversation | CCO / CEO + Revenue leadership | 1 hour |
+| L4 — Public Risk | Customer threatening public escalation, legal, or press | CCO / Legal / Comms | Immediate |
+
+## Output Format
+
+---
+
+# Escalation Brief: [Account Name]
+
+**Escalation level:** L[1/2/3/4] — [Label]
+**Date raised:** [Date]
+**Raised by:** [CSM name]
+**Escalation owner:** [Name of exec or senior stakeholder now leading response]
+
+---
+
+## Account at a Glance
+
+| Field | Detail |
+|---|---|
+| ARR | £/$/€[X] |
+| Tier | Enterprise / Mid-Market / SMB |
+| Customer since | [Date] |
+| Renewal date | [Date] — [N] days away |
+| Renewal risk (pre-escalation) | Green / Amber / Red |
+| Renewal risk (current) | Green / Amber / Red |
+| Customer contact who escalated | [Name, role, seniority] |
+| Executive sponsor (customer) | [Name, role — active / passive / vacant] |
+| Executive sponsor (vendor) | [Name, role] |
+
+---
+
+## What Happened — Summary
+
+[3–5 sentences. State the facts plainly. What the customer experienced, how they reacted, and how we learned about the escalation. No editorialising. No blame.]
+
+---
+
+## Timeline
+
+List in chronological order. Each entry: `[Date / time] — [What happened. Who did what.]`
+
+Include:
+- When the original issue or trigger event occurred
+- When the customer first raised concerns (informally)
+- When it escalated (formal escalation or exec involvement)
+- Actions taken since escalation
+
+---
+
+## Root Cause
+
+**Primary cause:** [One clear sentence. What specifically went wrong.]
+
+**Contributing factors:**
+- [Factor 1 — be honest about internal failures as well as external ones]
+- [Factor 2]
+
+**Is this a systemic issue or isolated?**
+[ ] Isolated to this account
+[ ] Pattern seen in other accounts — details: [_______]
+[ ] Product or process gap that needs fixing
+
+---
+
+## Customer's Stated Position
+
+**What the customer says happened:** [Their version of events — fair and unfiltered]
+
+**What they are asking for:** [Their explicit ask — compensation, fix by date, exec call, SLA credit, exit clause]
+
+**Sentiment of escalating contact:** [Frustrated but constructive / Angry / Seeking exit / Unknown]
+
+**Risk of public escalation:** Low / Medium / High — [evidence if Medium or High]
+
+---
+
+## Business Impact
+
+| Impact type | Detail |
+|---|---|
+| ARR at risk | £/$/€[X] |
+| Potential churn probability | [X]% |
+| Reputational risk | Low / Medium / High |
+| Reference / case study status | [Was a reference — now at risk / Not a reference] |
+| Expansion pipeline at risk | £/$/€[X] |
+
+---
+
+## What Has Been Done So Far
+
+1. [Action taken — by whom — date — outcome]
+2. [Action taken — by whom — date — outcome]
+3. [Action taken — by whom — date — outcome]
+
+**Has a formal apology or acknowledgement been issued?** Yes / No
+
+---
+
+## Proposed Resolution Plan
+
+**Immediate actions (next 24–48 hours):**
+
+| Action | Owner | By when |
+|---|---|---|
+| [Action] | [Name] | [Date] |
+| [Action] | [Name] | [Date] |
+
+**Medium-term actions (next 2–4 weeks):**
+
+| Action | Owner | By when |
+|---|---|---|
+| [Action] | [Name] | [Date] |
+
+**What we are NOT offering:** [Be explicit about what is not on the table — avoids misaligned expectations]
+
+**Success criteria:** [How will we know the escalation is resolved? What does the customer need to confirm they are satisfied?]
+
+---
+
+## Decision Required from Escalation Owner
+
+[State clearly what decision or resource the escalation owner needs to provide. Be specific — do not make them ask. E.g.: "We need approval to offer a 20% service credit for Q2" or "We need an exec call with [name] within 48 hours."]
+
+---
+
+## Communication Plan
+
+| Audience | Message | Channel | Owner | By when |
+|---|---|---|---|---|
+| Escalating customer contact | [Summary of message] | Email / Call | [Name] | [Date] |
+| Customer exec sponsor | [Summary] | Call | [Name] | [Date] |
+| Internal CS team | [Summary] | Slack / Meeting | CS Manager | [Date] |
+
+---
+
+## Quality Checks
+
+- [ ] Root cause is specific — not "communication breakdown" or "product gap" without detail
+- [ ] Customer's position is stated fairly — not minimised or dismissed
+- [ ] A clear decision is requested from the escalation owner — brief does not end with "what do you think?"
+- [ ] ARR at risk is quantified
+- [ ] Communication plan has owners and dates — not "TBD"
+- [ ] Language is professional and blameless toward individuals
@@ -0,0 +1,141 @@
+---
+name: cs-health-scorecard
+description: "Build a customer health scorecard for a specific account. Use when asked to score account health, assess renewal risk, build a health dashboard, or evaluate an account's likelihood to renew or expand. Produces a structured health scorecard with a RAG status, dimension scores, key risks, and recommended actions."
+---
+
+# Customer Health Scorecard Skill
+
+Produce a structured, data-driven health scorecard for a customer account — giving the CSM and leadership a clear view of renewal risk, expansion potential, and the actions needed to move the account in the right direction.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name** and tier (enterprise / mid-market / SMB)
+- **Contract value** (ARR) and **renewal date**
+- **Product usage data** — logins, DAU/MAU ratio, key feature adoption
+- **Support data** — open tickets, CSAT or NPS score, recent escalations
+- **Engagement data** — last QBR date, executive sponsor status, champion name
+- **Commercial data** — payment history, expansion conversations, seats used vs. licensed
+- **Any known risks or recent changes** at the account
+
+## Scoring Framework
+
+Score each dimension 1–5. Weight as shown. Calculate weighted total out of 100.
+
+| Dimension | Weight | What to Score |
+|---|---|---|
+| **Product Adoption** | 30% | DAU/MAU ratio, breadth of features used, power users identified |
+| **Engagement** | 20% | QBR cadence, executive sponsor active, champion strength |
+| **Outcomes** | 20% | Customer hitting their stated goals / success metrics |
+| **Support Health** | 15% | Ticket volume trend, unresolved escalations, CSAT |
+| **Commercial** | 15% | On-time payments, seats utilised, expansion signals |
+
+**Score → RAG conversion:**
+- 80–100: Green (healthy, renew likely)
+- 60–79: Amber (at risk, needs attention)
+- 0–59: Red (high churn risk, escalate)
+
+## Output Format
+
+---
+
+# Customer Health Scorecard: [Account Name]
+
+**CSM:** [Name] | **Tier:** [Enterprise / Mid-Market / SMB]
+**ARR:** £/$/€[X] | **Renewal date:** [Date] | **Days to renewal:** [N]
+**Overall health:** [Green / Amber / Red] — [Score]/100
+**Last updated:** [Date]
+
+---
+
+## Health Score Summary
+
+| Dimension | Score (1–5) | Weight | Weighted Score | Trend |
+|---|---|---|---|---|
+| Product Adoption | [1–5] | 30% | [X] | ↑ / → / ↓ |
+| Engagement | [1–5] | 20% | [X] | ↑ / → / ↓ |
+| Outcomes | [1–5] | 20% | [X] | ↑ / → / ↓ |
+| Support Health | [1–5] | 15% | [X] | ↑ / → / ↓ |
+| Commercial | [1–5] | 15% | [X] | ↑ / → / ↓ |
+| **Total** | — | 100% | **[X]/100** | |
+
+---
+
+## Dimension Detail
+
+### Product Adoption — [Score]/5
+- **DAU/MAU ratio:** [X]% (benchmark: >25% = healthy)
+- **Key features adopted:** [List features in use]
+- **Features not adopted:** [List unused high-value features]
+- **Power users identified:** [Yes / No — how many]
+- **Assessment:** [1–2 sentences on adoption health]
+
+### Engagement — [Score]/5
+- **Last QBR:** [Date] — [Outcome summary]
+- **Next QBR:** [Scheduled / Overdue]
+- **Executive sponsor:** [Active / Passive / Vacant]
+- **Champion:** [Name, role, strength: strong / moderate / weak]
+- **Assessment:** [1–2 sentences]
+
+### Outcomes — [Score]/5
+- **Customer's stated goals:** [List 2–3 goals from onboarding or last QBR]
+- **Progress against goals:** [On track / Partial / Off track]
+- **Evidence of value:** [Metric or quote that demonstrates ROI]
+- **Assessment:** [1–2 sentences]
+
+### Support Health — [Score]/5
+- **Open tickets:** [N] (priority breakdown: P1: X, P2: X, P3: X)
+- **CSAT / NPS:** [Score] (benchmark: >8 CSAT / >30 NPS = healthy)
+- **Unresolved escalations:** [Yes / No — details if yes]
+- **Ticket trend (last 90 days):** Increasing / Stable / Decreasing
+- **Assessment:** [1–2 sentences]
+
+### Commercial — [Score]/5
+- **Seats licensed:** [N] | **Seats active:** [N] ([X]% utilisation)
+- **Payment history:** [On time / Late — details]
+- **Expansion signals:** [Yes — describe / No]
+- **Downgrade or cancellation signals:** [Yes — describe / No]
+- **Assessment:** [1–2 sentences]
+
+---
+
+## Top Risks
+
+| Risk | Severity | Mitigation |
+|---|---|---|
+| [Risk description] | High / Medium / Low | [Specific action to mitigate] |
+
+---
+
+## Recommended Actions
+
+**Immediate (this week):**
+1. [Action — owner — deadline]
+
+**This month:**
+1. [Action — owner — deadline]
+
+**Before renewal:**
+1. [Action — owner — deadline]
+
+---
+
+## Renewal Forecast
+
+| Scenario | Probability | ARR at risk |
+|---|---|---|
+| Full renewal at current ARR | [X]% | £/$/€0 |
+| Renewal with contraction | [X]% | £/$/€[X] |
+| Churn | [X]% | £/$/€[full ARR] |
+
+**Recommended renewal play:** [Expand / Hold / Save / Manage out]
+
+---
+
+## Quality Checks
+
+- [ ] Score is based on data, not gut feel — each dimension has evidence
+- [ ] Risks are specific (not "low engagement" — something like "executive sponsor left in March, no replacement identified")
+- [ ] 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
@@ -0,0 +1,332 @@
+---
+name: developer-onboarding-doc
+description: "Write a developer onboarding document for a service, codebase, or team. Use when asked to write a developer guide, service README, onboarding doc for a new engineer, codebase orientation, or getting-started guide for a technical team. Produces a structured doc covering service overview, architecture, local setup, key patterns, testing, deployment, and who to ask for what."
+---
+
+# Developer Onboarding Document Skill
+
+Produce a complete developer onboarding document for a service or team — covering everything a new engineer needs to be productive within their first week.
+
+A good onboarding doc is not a wiki dump. It answers the questions a new engineer actually has on day one, in the order they'll have them.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Team** responsible for it
+- **Tech stack** — language(s), framework(s), database(s), message queues, etc.
+- **Key external dependencies** — upstream services, third-party APIs
+- **Deployment target** — Kubernetes, ECS, Lambda, bare metal, etc.
+- **Local dev setup** — how to run locally (Docker Compose, local DB, etc.)
+- **Testing approach** — unit, integration, E2E; test commands
+- **Deployment process** — summary of how code gets to production
+- **On-call setup** — who's on-call, how alerts work
+- **Contacts** — tech lead, platform team, related service owners
+
+## Output Format
+
+---
+
+# Developer Onboarding: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**Last updated:** [Date] | **Updated by:** [Name]
+
+> If something in this doc is wrong or out of date, fix it now — it will affect every engineer who onboards after you.
+
+---
+
+## What This Service Does
+
+[3–5 sentences. What problem does this service solve? Who calls it, and who does it call? What would break if this service went down?]
+
+**Service type:** [API / Background worker / Event consumer / Data pipeline / etc.]
+**Consumers:** [List internal services or external clients that depend on this service]
+**Dependencies:** [List upstream services, databases, and third-party APIs this service calls]
+
+**Architecture diagram:** [Link or embed — even a rough ASCII diagram helps]
+
+```
+[Caller A] ──→ [This Service] ──→ [Database]
+                      │
+                      └──→ [Downstream Service]
+```
+
+---
+
+## Codebase Orientation
+
+**Repository:** [Link]
+**Main branch:** `[main / master]`
+**Language:** [e.g. Go 1.22 / Node.js 20 / Python 3.12]
+**Framework:** [e.g. Express / FastAPI / Gin / Rails]
+
+### Key directories
+
+```
+[repo-root]/
+├── [src/ or cmd/]          # Application code
+│   ├── [handlers/]         # HTTP handlers / controllers
+│   ├── [services/]         # Business logic
+│   ├── [repository/]       # Database access layer
+│   └── [models/]           # Data models / types
+├── [tests/]                # Test files
+├── [migrations/]           # Database migrations
+├── [scripts/]              # Utility scripts
+├── [.github/workflows/]    # CI/CD pipeline definitions
+└── [docs/]                 # Additional documentation
+```
+
+**Where to start reading:** [Point to 2–3 key files that give the best orientation — e.g. `main.go`, `routes.js`, `app.py`]
+
+### Things that might surprise you
+
+- [Unusual pattern 1 — e.g. "We use event sourcing — state is derived from an event log, not stored directly"]
+- [Unusual pattern 2 — e.g. "Auth is handled by the gateway — this service trusts the `X-User-Id` header"]
+- [Unusual pattern 3 — any non-obvious decisions or legacy choices]
+
+---
+
+## Local Development Setup
+
+**Estimated setup time:** [X minutes for a fresh machine]
+
+### Prerequisites
+
+- [ ] [Tool 1] — version [X] — [install link]
+- [ ] [Tool 2] — version [X] — [install link]
+- [ ] Access to [repo / internal package registry] — request from [who]
+- [ ] [Any secrets or credentials needed] — request from [who]
+
+### Step-by-step setup
+
+```bash
+# 1. Clone the repo
+git clone [repo URL]
+cd [repo-name]
+
+# 2. Copy and configure environment variables
+cp .env.example .env
+# Edit .env — see "Environment Variables" section below
+
+# 3. Start dependencies (database, cache, etc.)
+[docker compose up -d / make deps / etc.]
+
+# 4. Install dependencies
+[npm install / go mod download / pip install -r requirements.txt]
+
+# 5. Run database migrations
+[migration command]
+
+# 6. Start the service
+[start command]
+
+# 7. Verify it's working
+curl http://localhost:[PORT]/health
+# Expected: {"status":"ok"}
+```
+
+**If this doesn't work:** Check [Troubleshooting section below] or ask in `#[channel]`.
+
+### Environment Variables
+
+| Variable | Required | Description | Example |
+|---|---|---|---|
+| `DATABASE_URL` | Yes | Connection string for the primary DB | `postgres://localhost:5432/[db]` |
+| `[VAR_2]` | Yes | [Description] | [Example] |
+| `[VAR_3]` | No | [Description — default value] | [Example] |
+
+**Secrets for local dev:** [Where to get them — e.g. "Run `[command]` to pull from Vault" or "Ask [person] in #[channel]"]
+
+### Useful local commands
+
+```bash
+[start command]           # Start the service
+[test command]            # Run all tests
+[lint command]            # Run linter
+[format command]          # Format code
+[migration command]       # Run pending migrations
+[seed command]            # Seed local database
+```
+
+---
+
+## Testing
+
+**Testing philosophy:** [e.g. "We test at the integration layer — unit tests for pure functions, integration tests for anything touching the DB or external services"]
+
+### Running tests
+
+```bash
+# All tests
+[test command]
+
+# Unit tests only
+[unit test command]
+
+# Integration tests (requires local deps running)
+[integration test command]
+
+# A specific test file or test case
+[test command with filter]
+```
+
+**Test coverage:** [X]% (minimum required to pass CI: [Y]%)
+**Coverage report:** [Where to find it]
+
+### Writing tests
+
+- **Unit tests:** [Where to put them — e.g. alongside source files as `*_test.go`]
+- **Integration tests:** [Where to put them — e.g. `tests/integration/`]
+- **Test database:** [How it works — e.g. "Each test gets a clean transaction that rolls back on teardown — see `tests/helpers/db.go`"]
+- **Mocking:** [Policy — e.g. "We mock at the repository layer — don't mock the DB directly"]
+
+---
+
+## Making Changes
+
+### Branching
+
+[Branch naming convention — e.g. `feature/[ticket-id]-short-description`, `fix/[ticket-id]-short-description`]
+
+### Before opening a PR
+
+- [ ] Tests pass locally
+- [ ] Linter passes (`[lint command]`)
+- [ ] New behaviour has test coverage
+- [ ] Any new environment variables are added to `.env.example` and documented
+- [ ] Database migrations are backward-compatible (old code can run against new schema)
+
+### Code review
+
+- **Reviewers:** [Who to request review from — e.g. "Any engineer on [team]; lead review required for auth changes"]
+- **Expected review time:** [X hours / 1 business day]
+- **PR template:** [Link or auto-generated by GitHub]
+
+### Database migrations
+
+```bash
+# Create a new migration
+[migration create command]
+
+# Apply pending migrations
+[migration up command]
+
+# Roll back last migration
+[migration down command]
+```
+
+**Migration rules:**
+- All migrations must be backward-compatible — old code must run against the new schema
+- Never rename or drop a column in a single migration — do it in two steps (add new, migrate data, drop old)
+- Test your rollback before merging
+
+---
+
+## Deployment
+
+**How code gets to production:** [1–2 sentence summary — link to full CI/CD playbook if it exists]
+
+1. Merge to `main` → automatic deploy to staging
+2. Smoke tests run on staging
+3. Manual approval → deploy to production
+4. Post-deploy monitoring for [X minutes]
+
+**Deployment docs:** [Link to CI/CD playbook or pipeline docs]
+
+**Who can deploy:** [Any engineer / Lead engineer / On-call engineer — specify]
+
+**Deployment channel:** `#[deployments channel]`
+
+---
+
+## Monitoring and Observability
+
+**Dashboard:** [Datadog / Grafana / CloudWatch — link]
+**Logs:** [Log aggregation tool and link — e.g. "Logs are in Datadog under service:[name]"]
+**Traces:** [Tracing tool and link if applicable]
+**Alerts:** [Where alerts fire — e.g. PagerDuty / Slack #alerts-[service]]
+
+**Key metrics to know:**
+- **Error rate:** Should be <[X]% (alert at [Y]%)
+- **P99 latency:** Should be <[X]ms
+- **[Business metric]:** [e.g. "Queue depth should be <100 items"]
+
+---
+
+## On-Call
+
+**On-call schedule:** [PagerDuty / Opsgenie link]
+**Who's on-call now:** [Link to current schedule or `#oncall` channel]
+**Escalation:** [On-call → [team lead] → [EM] — after [X] minutes unacknowledged]
+
+**If you get paged:**
+1. Acknowledge the alert
+2. Check [dashboard link] for the first clue
+3. Common alert runbooks: [link to oncall-runbook or runbook-writer output]
+4. If you can't resolve in [X minutes], escalate to [person/channel]
+
+---
+
+## Key Contacts
+
+| Role | Name | Best way to reach |
+|---|---|---|
+| Tech lead | [Name] | Slack: @[handle] |
+| On-call rotation | [Team] | PagerDuty / `#on-call` |
+| Platform / infra | [Team] | `#platform` Slack channel |
+| Database / DBA | [Name or team] | `#database` Slack channel |
+| [Upstream service] owner | [Name] | Slack: @[handle] |
+
+**Where to ask questions:**
+- General engineering: `#engineering`
+- This service specifically: `#[service-name]`
+- Urgent / production issues: `#incidents`
+
+---
+
+## Troubleshooting
+
+### "The service won't start locally"
+
+1. Check that Docker / dependencies are running: `[command]`
+2. Check `.env` is populated — missing values cause silent failures
+3. Check logs: `[log command]`
+4. Ask in `#[channel]`
+
+### "Tests are failing locally but passing in CI"
+
+- Check your local dependency versions match CI: `[version check command]`
+- Try a clean install: `[clean install command]`
+- Integration tests need local deps running — `[start deps command]`
+
+### "I can't access [internal tool / system]"
+
+- Request access through [process — e.g. Okta self-serve / ask your manager]
+
+### "Something looks wrong in production"
+
+1. Check [dashboard] for the error spike
+2. Check recent deploys in `#deployments`
+3. If it's an active incident, page on-call via [PagerDuty / Slack command]
+
+---
+
+## Further Reading
+
+- [Architecture Decision Records (ADRs)](./docs/decisions/) — why the codebase is the way it is
+- [API documentation](./docs/api/) or [link to external docs]
+- [Incident runbooks](./docs/runbooks/)
+- [CI/CD pipeline documentation](./docs/cicd/)
+- [Team working agreements](./docs/team/)
+
+---
+
+## Quality Checks
+
+- [ ] Local setup instructions work on a fresh machine — tested recently
+- [ ] Environment variables table is complete and accurate
+- [ ] "Things that might surprise you" captures the actual surprises (ask a recent joiner)
+- [ ] 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
@@ -0,0 +1,364 @@
+---
+name: oncall-runbook
+description: "Write an on-call runbook for a service — covering alert definitions, escalation paths, common incident responses, and on-call handoff procedures. Use when asked to write an on-call guide, create alert runbooks, document escalation procedures, or prepare an on-call handoff document. Produces a structured on-call runbook with per-alert response procedures, escalation matrix, diagnostic commands, and handoff template."
+---
+
+# On-Call Runbook Skill
+
+Produce a complete on-call runbook for a service — giving the on-call engineer everything they need to respond confidently to alerts at 3am, without having to ask anyone for help.
+
+A good on-call runbook reduces mean time to resolution (MTTR) by eliminating the "what do I do first?" problem. It is written for the on-call engineer who has just been paged and needs to act, not for someone calmly reading documentation.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and what it does
+- **Team** and tech lead name
+- **Alert list** — names of alerts that currently page on-call
+- **Monitoring setup** — Datadog / Grafana / CloudWatch / PagerDuty / etc.
+- **Common failure modes** — what breaks most often, and what fixes it
+- **Escalation contacts** — who to call when on-call can't resolve it
+- **Deployment setup** — can on-call roll back? How?
+- **Service dependencies** — what does this service depend on, and what depends on it?
+
+## Output Format
+
+---
+
+# On-Call Runbook: [Service Name]
+
+**Team:** [Team name] | **Tech lead:** [Name]
+**PagerDuty service:** [Link] | **Escalation policy:** [Policy name]
+**Last updated:** [Date] | **Next review:** [Date + 90 days]
+
+> **First time on-call for this service?** Read the [developer onboarding doc] first — it covers the architecture and how things work. This runbook assumes you understand the service.
+
+---
+
+## Quick Reference
+
+**Dashboard:** [Link — the first thing to open when paged]
+**Logs:** [Link — where to find logs]
+**Runbook index:** Jump to the alert that paged you → [Alert list below]
+**Can't resolve in 30 min?** Escalate to: [Name] via [Slack / PagerDuty]
+
+**Rollback command (memorise this):**
+```bash
+[rollback command — e.g. kubectl rollout undo deployment/[service-name]]
+```
+
+---
+
+## Escalation Matrix
+
+| Situation | Escalate to | How | After how long |
+|---|---|---|---|
+| Can't diagnose the alert | [Tech lead name] | Slack DM / Phone | 30 minutes |
+| Alert requires infra change | [Platform team] | `#platform` Slack | Immediately |
+| Customer-facing impact | [CSM / Support lead] | `#incidents` Slack | Immediately (P1) |
+| Database issue | [DBA or data team] | Slack / PagerDuty | Immediately |
+| [Specific dependency] down | [[Dependency] on-call] | PagerDuty / Slack | Immediately |
+| Extended outage (>1 hour) | [Engineering manager] | Phone | 1 hour |
+
+**Contacts:**
+
+| Name | Role | Slack | Phone |
+|---|---|---|---|
+| [Name] | Tech lead | @[handle] | [Number] |
+| [Name] | Engineering manager | @[handle] | [Number] |
+| [Name] | Platform / infra | @[handle] | [Number] |
+| [Platform team] | Infra on-call | `#platform` | PagerDuty |
+
+---
+
+## Service Architecture (Quick View)
+
+```
+[Upstream callers]
+        │
+        ▼
+[This Service]
+        │
+        ├──→ [Primary Database]
+        ├──→ [Cache — e.g. Redis]
+        └──→ [Downstream Service / Queue]
+```
+
+**If this service is down, these are affected:** [List downstream consumers]
+**If these are down, this service is affected:** [List upstream dependencies]
+
+---
+
+## Alert Runbooks
+
+### ALERT: [Alert Name 1 — e.g. HighErrorRate]
+
+**What it means:** [Plain English — e.g. "More than 5% of API requests are returning 5xx errors in the last 5 minutes"]
+**Severity:** P1 / P2 / P3
+**SLO impact:** Yes / No — [If yes: this alert means the error budget is burning at [X]× rate]
+
+**Step 1 — Acknowledge and assess**
+```bash
+# Check current error rate
+[query or dashboard link]
+
+# Check which endpoints are erroring
+[query or command]
+```
+
+**Step 2 — Check recent changes**
+```bash
+# Any deploys in the last hour?
+[command or link to deployment log]
+
+# Recent config changes?
+[where to check]
+```
+
+**Step 3 — Check dependencies**
+```bash
+# Is the database healthy?
+[health check command or link]
+
+# Is [downstream service] healthy?
+[health check command or link]
+```
+
+**Step 4 — Diagnose**
+
+| If you see | It means | Do this |
+|---|---|---|
+| [Error pattern 1] | [Cause] | [Action] |
+| [Error pattern 2] | [Cause] | [Action] |
+| [Error pattern 3] | [Cause] | [Action] |
+| No clear pattern | Unknown cause | Escalate to [name] |
+
+**Step 5 — Fix or mitigate**
+```bash
+# If caused by bad deploy — roll back:
+[rollback command]
+
+# If caused by [specific issue]:
+[fix command]
+
+# If caused by upstream dependency:
+[mitigation — e.g. enable circuit breaker, reduce traffic, etc.]
+```
+
+**After resolving:**
+- [ ] Confirm error rate has returned to baseline
+- [ ] Check no downstream services were affected
+- [ ] If P1: open a post-incident review — see [incident-postmortem skill]
+- [ ] Update `#incidents` with resolution summary
+
+---
+
+### ALERT: [Alert Name 2 — e.g. HighLatency]
+
+**What it means:** [e.g. "P99 response time has exceeded 1s for more than 3 consecutive minutes"]
+**Severity:** P1 / P2 / P3
+**SLO impact:** Yes — latency SLO breach
+
+**Step 1 — Assess scope**
+```bash
+# Check which endpoints are slow
+[query or dashboard — broken down by endpoint]
+
+# Check if latency is across all regions or localised
+[query or command]
+```
+
+**Step 2 — Common causes and fixes**
+
+| Cause | Signal | Fix |
+|---|---|---|
+| Database slow queries | DB latency spike on dashboard | [Check slow query log: `command`] |
+| Cache miss storm | Cache hit rate drops on dashboard | [command or action] |
+| Memory pressure / GC | High memory on service dashboard | [command or action — e.g. restart, scale up] |
+| Upstream service slow | Trace shows time in external call | Escalate to [service] on-call |
+| Traffic spike | Request rate spike on dashboard | [Scale up: `command`] |
+
+**Step 3 — Escalate if unresolved in 20 minutes**
+Page [Tech lead] via PagerDuty / Slack.
+
+---
+
+### ALERT: [Alert Name 3 — e.g. DatabaseConnectionPoolExhausted]
+
+**What it means:** [e.g. "The service has used all available database connections — new requests will fail"]
+**Severity:** P1
+**SLO impact:** Yes — will cause errors immediately
+
+**Immediate mitigation:**
+```bash
+# Restart the service to flush stale connections
+[restart command]
+
+# Check current connection count
+[DB connection query]
+```
+
+**Diagnose root cause after stabilising:**
+```bash
+# Check for long-running queries holding connections
+[query]
+
+# Check if a recent deploy changed connection pool config
+[where to check]
+```
+
+**Resolution:** [e.g. "Increase pool size in config / kill long-running queries / scale the service"]
+
+---
+
+### ALERT: [Alert Name 4 — e.g. QueueBacklogHigh / ConsumerLag]
+
+**What it means:** [e.g. "The message queue backlog exceeds 10,000 messages — consumers are not keeping up"]
+**Severity:** P2
+**SLO impact:** Depends — if queue backs up, downstream systems will receive delayed data
+
+**Step 1 — Check consumer health**
+```bash
+# Are consumers running?
+[command]
+
+# Consumer error rate?
+[dashboard or query]
+```
+
+**Step 2 — Check message contents**
+```bash
+# Are there poison messages causing retries?
+[command to inspect dead-letter queue or failed messages]
+```
+
+**Step 3 — Options**
+
+| If | Then |
+|---|---|
+| Consumers are down | Restart consumers: `[command]` |
+| Poison message in queue | Move to DLQ: `[command]` |
+| Consumers healthy but slow | Scale consumers: `[command]` |
+| Upstream producing too fast | Escalate to [upstream service] owner |
+
+---
+
+### ALERT: [Add additional alerts following the same pattern]
+
+---
+
+## Diagnostic Cheat Sheet
+
+Common commands for quick diagnosis. Paste and run without modification.
+
+```bash
+# Service health
+[health check command]
+
+# Recent logs (last 100 lines)
+[log command]
+
+# Error logs only
+[error log filter command]
+
+# Current pod / instance status
+[kubectl get pods / aws ecs describe-tasks / etc.]
+
+# Restart the service
+[restart command]
+
+# Roll back to previous version
+[rollback command]
+
+# Database connection count
+[DB query]
+
+# Cache hit rate
+[cache stats command]
+
+# Current request rate
+[metrics query]
+```
+
+---
+
+## Useful Dashboard Links
+
+| Dashboard | URL | Use it to |
+|---|---|---|
+| Service overview | [Link] | First stop — error rate, latency, request rate |
+| Database | [Link] | Connection count, slow queries, replication lag |
+| Infrastructure | [Link] | CPU, memory, disk |
+| Queue / consumers | [Link] | Backlog depth, consumer throughput |
+| Upstream dependencies | [Link] | Dependency health at a glance |
+
+---
+
+## Incident Communication
+
+When you declare an incident:
+
+**Post to `#incidents` immediately:**
+```
+🔴 INCIDENT — [Service Name]
+Status: Investigating
+Impact: [Who is affected and how]
+Paged: [Your name]
+Next update: [Time — max 30 min from now]
+```
+
+**Update every 30 minutes while active:**
+```
+🔴 UPDATE — [Service Name] — [Time]
+Status: [Investigating / Identified / Mitigating / Resolved]
+Latest: [One sentence on what you found or did]
+Next update: [Time]
+```
+
+**On resolution:**
+```
+✅ RESOLVED — [Service Name] — [Time]
+Duration: [X minutes]
+Impact: [Summary of who was affected]
+Cause: [One sentence]
+Follow-up: [PIR required? Yes/No — link when created]
+```
+
+---
+
+## On-Call Handoff
+
+Use this template at the end of every on-call shift:
+
+```
+--- ON-CALL HANDOFF: [Service Name] ---
+Date: [Date]
+Outgoing: [Your name]
+Incoming: [Next on-call name]
+
+INCIDENTS THIS SHIFT:
+- [Incident summary — date, duration, cause, resolution, follow-up required]
+
+OPEN ISSUES TO WATCH:
+- [Anything not fully resolved / trending in the wrong direction]
+
+CHANGES SINCE LAST HANDOFF:
+- [Deploys, config changes, infra changes that affect on-call awareness]
+
+RUNBOOK GAPS FOUND:
+- [Anything you had to figure out that isn't documented — please add it]
+
+ANYTHING ELSE:
+- [Notes for incoming on-call]
+```
+
+---
+
+## Quality Checks
+
+- [ ] Every alert that pages on-call has a runbook entry — no alert is missing
+- [ ] Rollback command is accurate and tested recently
+- [ ] Escalation contacts have current phone numbers and Slack handles
+- [ ] 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
@@ -0,0 +1,218 @@
+---
+name: qbr-deck
+description: "Build a Quarterly Business Review (QBR) deck structure and narrative for a customer account. Use when asked to prepare a QBR, business review meeting, executive review, or quarterly check-in with a customer. Produces a slide-by-slide QBR structure with talking points, metrics review, value narrative, and mutual next steps."
+---
+
+# QBR Deck Skill
+
+Produce a complete Quarterly Business Review deck — structured, data-backed, and customer-focused. A good QBR demonstrates value delivered, aligns on goals for the next quarter, and strengthens the executive relationship. It should never feel like a product demo or a vendor update.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Account name**, CSM name, and customer stakeholders attending
+- **Contract details** — ARR, contract start date, renewal date
+- **Last quarter's goals** (from previous QBR or kickoff)
+- **Usage and adoption data** — key metrics for the quarter
+- **Support summary** — tickets raised, resolution time, any escalations
+- **Business outcomes the customer cares about** — what success looks like for them
+- **Product updates or new features** relevant to this customer
+- **Goals for next quarter**
+- **Any open commercial conversations** (expansion, renewal, at-risk signals)
+
+## QBR Principles
+
+- Lead with customer outcomes, not product features
+- Every metric should connect to a business result the customer cares about
+- The agenda is a conversation, not a presentation — build in time for customer input at every stage
+- Close with mutual commitments, not just vendor actions
+
+## Output Format
+
+---
+
+# QBR: [Account Name] × [Your Company]
+**[Quarter] [Year] Business Review**
+
+**Date:** [Date] | **Location / Call link:** [TBC]
+**Customer attendees:** [Names and roles]
+**[Your company] attendees:** [Names and roles]
+
+---
+
+## Slide 1: Agenda (5 min)
+
+| Time | Topic | Owner |
+|---|---|---|
+| 0:00 | Welcome and introductions | CSM |
+| 0:05 | [Last quarter] — how did we do? | CSM + Customer |
+| 0:20 | Value delivered — business impact | CSM |
+| 0:35 | What's coming — roadmap preview | CSM / Product |
+| 0:45 | [Next quarter] — goals and priorities | Customer |
+| 0:55 | Actions and mutual commitments | CSM |
+| 1:00 | Close | |
+
+*Talking point: "We've kept today to 60 minutes. We want as much of this to be a conversation as possible — please push back, redirect, and ask questions throughout."*
+
+---
+
+## Slide 2: Where We Are Together (2 min)
+
+**Partnership snapshot:**
+- **Customer since:** [Date]
+- **Contract value:** £/$/€[ARR]/year
+- **Renewal date:** [Date]
+- **Active users:** [N] of [N] licensed seats ([X]% adoption)
+- **Products / modules active:** [List]
+
+*Talking point: "Before we dive in — a quick picture of where we are. [X] months in, [Y] active users, and this is our [Nth] QBR together."*
+
+---
+
+## Slide 3: Last Quarter — Goals We Set Together (5 min)
+
+| Goal | Set in [Last QBR / Kickoff] | Status |
+|---|---|---|
+| [Goal 1] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+| [Goal 2] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+| [Goal 3] | [What we committed to] | ✅ Achieved / ⚠️ Partial / ❌ Missed |
+
+For any partial or missed goal: state what happened and what changes next quarter.
+
+*Talking point: "Let's start with accountability. Here's what we said we'd achieve last quarter — let's be honest about where we landed."*
+
+---
+
+## Slide 4: Usage and Adoption (5 min)
+
+**Quarter-over-quarter trend:**
+
+| Metric | [Q-1] | [Q] | Change |
+|---|---|---|---|
+| Monthly active users | [N] | [N] | +/-X% |
+| Sessions per user per week | [N] | [N] | +/-X% |
+| [Key feature 1] adoption | [X]% | [X]% | +/-X% |
+| [Key feature 2] adoption | [X]% | [X]% | +/-X% |
+
+**Highlights:**
+- [Positive adoption trend to call out]
+- [Feature or workflow with strongest engagement]
+
+**Opportunity:**
+- [Feature with low adoption that could drive more value — link to their goals]
+
+*Talking point: "Usage is [up / stable / something we want to talk about]. The area I'd like to focus on is [feature] — we're not seeing the adoption we'd expect given [their goal], and I want to understand why."*
+
+---
+
+## Slide 5: Business Impact — Value Delivered (10 min)
+
+Lead with outcomes, not activity.
+
+**[Outcome 1: customer's primary success metric]**
+- Before: [baseline]
+- Now: [current state]
+- Impact: [quantified business result — time saved, revenue influenced, cost reduced, risk mitigated]
+
+**[Outcome 2]**
+- [Same structure]
+
+**[Outcome 3]**
+- [Same structure]
+
+**Customer evidence** (use if available):
+> "[Quote from champion or user about value experienced]"
+
+*Talking point: "This is the section I most want your input on. Are these the outcomes that matter to your business? Are there other ways you're measuring success that we should be tracking?"*
+
+---
+
+## Slide 6: Support Summary (3 min)
+
+| Metric | This quarter | Last quarter | Trend |
+|---|---|---|---|
+| Tickets raised | [N] | [N] | ↑ / → / ↓ |
+| Average resolution time | [X hrs] | [X hrs] | ↑ / → / ↓ |
+| P1 / critical issues | [N] | [N] | ↑ / → / ↓ |
+| CSAT score | [X/10] | [X/10] | ↑ / → / ↓ |
+
+**Notable issues this quarter:**
+- [Any escalation or major ticket — brief summary and resolution]
+
+**What we're doing differently:**
+- [Any process change or improvement based on support patterns]
+
+---
+
+## Slide 7: What's Coming — Roadmap Preview (5 min)
+
+Focus only on what's relevant to this customer's goals. Do not dump the full roadmap.
+
+| Feature / Improvement | Expected | Why it matters to [Account Name] |
+|---|---|---|
+| [Feature 1] | [Q+1] | [Direct link to their goal or pain point] |
+| [Feature 2] | [Q+1 / Q+2] | [Direct link] |
+| [Feature 3] | [H2] | [Direct link] |
+
+*Talking point: "I've filtered the roadmap to what I think matters most to your team. I'd love your reaction — are these the right priorities from your perspective?"*
+
+---
+
+## Slide 8: Next Quarter — Your Goals (10 min)
+
+**Customer input section — facilitate, don't present.**
+
+Prompt questions:
+- "What does success look like for your team in [next quarter]?"
+- "What's the biggest challenge you're trying to solve in the next 90 days?"
+- "Is there anything about the way you're using [product] you want to change?"
+
+**Capture live:**
+
+| Goal for next quarter | Owner (customer) | How we'll support it | How we'll measure it |
+|---|---|---|---|
+| [Goal 1] | [Name] | [CSM / product action] | [Metric] |
+| [Goal 2] | [Name] | [CSM / product action] | [Metric] |
+
+---
+
+## Slide 9: Mutual Commitments (5 min)
+
+**[Your company] commits to:**
+1. [Specific action — owner — by when]
+2. [Specific action — owner — by when]
+3. [Specific action — owner — by when]
+
+**[Account Name] commits to:**
+1. [Specific action — owner — by when]
+2. [Specific action — owner — by when]
+
+**Next touchpoint:** [Date of next check-in or mid-quarter review]
+
+---
+
+## Slide 10: Thank You + Open Q&A (5 min)
+
+- Recap the one headline from today: [The single most important thing you want them to remember]
+- Confirm actions are captured and shared after the call
+- Ask: "Is there anything we didn't cover today that you wanted to raise?"
+
+---
+
+## Preparation Checklist
+
+- [ ] Usage data pulled and QoQ comparison calculated
+- [ ] Last QBR goals reviewed — status confirmed before the meeting
+- [ ] Business outcomes framed in customer language (not product language)
+- [ ] Roadmap filtered to this account's specific use cases
+- [ ] Customer's goals for next quarter researched or pre-confirmed with champion
+- [ ] Executive sponsor briefed on any sensitive topics before the call
+- [ ] Actions from previous QBR reviewed — any outstanding items addressed
+
+## Quality Checks
+
+- [ ] Every slide has a talking point, not just a title
+- [ ] Value slide leads with business outcomes, not product activity
+- [ ] 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
@@ -0,0 +1,231 @@
+---
+name: slo-error-budget
+description: "Define Service Level Objectives (SLOs) and an error budget policy for a service. Use when asked to write SLOs, define SLIs, calculate an error budget, set reliability targets, or create an error budget policy. Produces a complete SLO document with SLI definitions, target calculation, error budget policy, burn rate alerts, and review cadence."
+---
+
+# SLO and Error Budget Skill
+
+Produce a complete, implementable SLO document for a service — covering what to measure, what target to set, how to calculate the error budget, and what to do when it burns.
+
+A good SLO is not a target to hit. It is an agreement about what reliability means for your users — and a framework for making principled trade-offs between reliability and velocity.
+
+## Required Inputs
+
+Ask for these if not already provided:
+- **Service name** and brief description of what it does
+- **Primary users** — who depends on this service and how
+- **User-facing interactions** to protect — e.g. API calls, page loads, transactions
+- **Current reliability data** — error rate, latency, uptime (last 30–90 days if available)
+- **Existing on-call setup** — who responds to alerts?
+- **Deployment frequency** — how often does the team ship?
+- **Any existing SLAs** with customers — these constrain SLO targets
+
+## Key Definitions
+
+Always establish these before writing the SLO:
+
+| Term | Definition |
+|---|---|
+| **SLI** (Service Level Indicator) | The metric being measured — e.g. "% of requests completing successfully in <500ms" |
+| **SLO** (Service Level Objective) | The target for that metric — e.g. "99.5% of requests" |
+| **SLA** (Service Level Agreement) | The contractual commitment to customers — must be looser than the SLO |
+| **Error budget** | The allowed headroom below 100% — the budget for planned and unplanned downtime |
+| **Burn rate** | How fast the error budget is being consumed |
+
+---
+
+## Output Format
+
+---
+
+# SLO Document: [Service Name]
+
+**Service:** [Name] | **Team:** [Team name]
+**Owner:** [Name / role] | **Approved by:** [Name]
+**Effective date:** [Date] | **Review date:** [Date + 3 months]
+**Version:** [1.0]
+
+---
+
+## Why This SLO Exists
+
+[2–3 sentences. What reliability problem are we solving? What was happening before this SLO that made us need it? What decision-making does this SLO enable?]
+
+---
+
+## Service Overview
+
+**What this service does:** [One sentence]
+**Who depends on it:** [Internal teams / external customers / both — describe]
+**Critical user journeys protected by this SLO:**
+1. [Journey 1 — e.g. "User completes a payment"]
+2. [Journey 2]
+3. [Journey 3]
+
+---
+
+## SLIs — What We Measure
+
+Define one SLI per user journey or reliability dimension. Keep it to 3–5 SLIs maximum.
+
+### SLI 1: [Name — e.g. Request Success Rate]
+
+| Field | Detail |
+|---|---|
+| **What it measures** | [e.g. "% of API requests that return a non-5xx response"] |
+| **Good event definition** | [e.g. "HTTP response with status 2xx or 4xx, completed within 500ms"] |
+| **Bad event definition** | [e.g. "HTTP response with status 5xx, or any response taking >500ms"] |
+| **Measurement source** | [e.g. "Application load balancer access logs / Datadog APM / Prometheus"] |
+| **Measured over** | Rolling 28-day window |
+| **Exclusions** | [e.g. "Health check endpoints excluded / Requests during planned maintenance excluded"] |
+
+### SLI 2: [Name — e.g. Latency]
+
+| Field | Detail |
+|---|---|
+| **What it measures** | [e.g. "P99 response time for the /checkout endpoint"] |
+| **Good event definition** | [e.g. "Request completes in ≤500ms at P99"] |
+| **Bad event definition** | [e.g. "Request takes >500ms at P99"] |
+| **Measurement source** | [Source] |
+| **Measured over** | Rolling 28-day window |
+| **Exclusions** | [Any exclusions] |
+
+### SLI 3: [Name — e.g. Data Freshness / Queue Depth / etc.]
+
+[Same structure]
+
+---
+
+## SLO Targets
+
+| SLI | Target | Window | Error Budget |
+|---|---|---|---|
+| [SLI 1 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+| [SLI 2 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+| [SLI 3 name] | [X]% | 28-day rolling | [100 - X]% = [Y minutes/month] |
+
+**How targets were set:**
+- Historical baseline (last 90 days): [X]%
+- Target is set [above / at] historical baseline to [improve reliability / reflect current reality while formalising the commitment]
+- Rationale: [1–2 sentences]
+
+**What 100% is NOT the target:** [Brief explanation of why targeting 100% is counterproductive — it discourages feature development and doesn't reflect user reality]
+
+---
+
+## Error Budget Calculation
+
+**For SLI 1 ([Name]), at [X]% target:**
+
+```
+Error budget = (100% - SLO target) × measurement window
+             = (100% - [X]%) × 28 days × 24 hours × 60 minutes
+             = [Y]% × [Z total minutes]
+             = [N] minutes of allowed failure per 28-day window
+```
+
+**In plain terms:** We can afford [N] minutes of [bad events] in any rolling 28-day window before we breach the SLO.
+
+---
+
+## Burn Rate Alerts
+
+Burn rate = how fast the error budget is being consumed relative to the budget window.
+A burn rate of 1 = consuming the budget at exactly the rate that would exhaust it over 28 days.
+
+| Alert | Burn rate | Window | Severity | Response |
+|---|---|---|---|---|
+| Page (critical) | >14× | 1 hour | P1 | Page on-call immediately — budget exhausted in <2 hours |
+| Page (high) | >6× | 6 hours | P2 | Page on-call — budget exhausted in <5 days |
+| Ticket (warning) | >3× | 3 days | P3 | Create ticket — review at next team meeting |
+| Info | >1× | 28 days | Info | Log only — budget on track to exhaust by end of window |
+
+**Alert implementation:** [Link to alert config in monitoring tool — e.g. Datadog, Prometheus/Alertmanager, Grafana]
+
+---
+
+## Error Budget Policy
+
+This policy defines what to do with the error budget — both when it's healthy and when it's burning.
+
+### When budget is healthy (>50% remaining)
+
+- Feature development and deployments proceed at normal pace
+- The team may take on riskier experiments
+- Reliability improvements are scheduled but not urgent
+
+### When budget is at risk (25–50% remaining)
+
+- Deployment frequency reduced — team ships only well-tested changes
+- One reliability improvement added to current sprint
+- Weekly error budget review added to team standup
+
+### When budget is nearly exhausted (<25% remaining)
+
+- Feature work paused in favour of reliability improvements
+- No new deployments without explicit on-call approval
+- Daily review of error budget burn rate
+- CSM / support notified to manage customer expectations
+
+### When budget is exhausted (0% remaining — SLO breached)
+
+- All feature work stops
+- On-call engineer and engineering manager notified immediately
+- Post-incident review (PIR) required within 5 business days
+- SLO target may be temporarily relaxed (with stakeholder approval) while root cause is addressed
+
+---
+
+## Dashboard and Reporting
+
+**SLO dashboard:** [Link to Datadog / Grafana / etc. dashboard]
+
+**Metrics exposed:**
+- Current SLO compliance (rolling 28-day)
+- Error budget remaining (% and minutes)
+- Burn rate (current and trend)
+- Incident count and MTTR this window
+
+**Reporting cadence:**
+
+| Audience | Frequency | Format |
+|---|---|---|
+| Engineering team | Weekly | Slack summary — #[service]-slo |
+| Engineering manager | Monthly | SLO review meeting |
+| Stakeholders / customers | Quarterly | SLO compliance summary |
+
+---
+
+## Exclusions and Edge Cases
+
+**Planned maintenance:** Error budget is not consumed during pre-announced maintenance windows. Maintenance must be communicated [X hours] in advance via [channel].
+
+**Dependency failures:** If SLO breach is caused by an upstream dependency outside our control, document it — but it still counts against our error budget (our users don't distinguish between our failures and our dependencies' failures).
+
+**Force majeure:** [Policy for cloud provider outages, major infrastructure events]
+
+---
+
+## SLO Review Cadence
+
+| Review | When | Who | Output |
+|---|---|---|---|
+| Error budget review | Weekly | Team | Budget health check — adjust if burning fast |
+| SLO target review | Quarterly | Team + EM | Adjust targets if baseline has shifted significantly |
+| Annual SLO audit | Annually | Team + Stakeholders | Review SLIs — are we measuring the right things? |
+
+**When to change the SLO target:**
+- Historical baseline has improved significantly and target no longer reflects real reliability
+- User feedback indicates the target is misaligned with what users actually experience
+- The SLO is being gamed (metric is healthy but users are unhappy)
+
+---
+
+## Quality Checks
+
+- [ ] SLIs are user-facing — they measure what users experience, not internal system metrics
+- [ ] Good and bad events are precisely defined — no ambiguity about what counts
+- [ ] Targets are based on historical data, not aspirational round numbers
+- [ ] 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
@@ -0,0 +1,99 @@
+# Contributing an Agent Template
+
+This guide explains how to contribute a new agent template to the pm-claude-skills library.
+
+## What is an agent template?
+
+An agent template is a runnable workflow that combines existing skills, connectors, and subagents into a single end-to-end task. Following the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026.
+
+Examples of agent templates that would belong in this repo:
+
+- **PM Discovery Agent** — combines discovery-interview-guide + user-interview-synthesis + assumption-mapper with Granola/Notion connectors
+- **Legal Contract Review Agent** — combines contract-review + nda-analyser + compliance-checklist with Google Drive connector
+- **Sales Pursuit Agent** — combines sales-battlecard + discovery-call-prep + proposal-writer + account-plan with Salesforce/Gong connectors
+
+## Required structure
+
+Every agent template needs these files:
+
+```
+templates/your-agent-name/
+├── README.md                  # What it does, install, usage
+├── AGENT.md                   # Agent definition (system prompt + tool list)
+├── orchestrate.sh             # Orchestration script
+├── skills/                    # Skills used (linked from main library)
+│   ├── README.md
+│   └── [skill-name]/SKILL.md
+├── subagents/                 # Specialised subagents
+│   └── [subagent-name].md
+├── connectors/                # Data source configurations
+│   ├── README.md
+│   └── [system].example.json
+├── examples/                  # Input and output examples
+│   ├── input-example.md
+│   └── output-example.md
+└── tests/
+    └── smoke-test.md
+```
+
+## Naming conventions
+
+- **Folder name**: Use kebab-case, descriptive of the workflow (e.g., `pm-sprint-agent`, `legal-contract-review-agent`, `sales-pursuit-agent`)
+- **AGENT.md**: Always exactly this name (with caps) so it's easily findable
+- **Subagent files**: kebab-case in `subagents/`, ending in `.md` (e.g., `capacity-analyst.md`)
+- **Connector files**: lowercase, with `.example.json` for the template version (e.g., `linear.example.json`)
+
+## Quality bar for new templates
+
+Before submitting a PR, verify:
+
+- [ ] **README.md** explains what the agent does in the first paragraph (no more burying the lede)
+- [ ] **AGENT.md** has a complete system prompt with explicit step-by-step instructions
+- [ ] **At least 2 skills** from the main library are referenced (otherwise it's just a skill, not a template)
+- [ ] **At least 1 subagent** is defined for analysis the skills can't do alone
+- [ ] **At least 1 connector** with a working example config
+- [ ] **orchestrate.sh** runs without errors in `--dry-run` mode
+- [ ] **Smoke test passes** (documented in `tests/smoke-test.md`)
+- [ ] **Example input AND example output** are provided
+- [ ] **Honest limitations section** in the README — what the agent doesn't do well
+- [ ] **No credentials in any committed file** — credentials must come from environment variables
+
+## What makes a good agent template (vs a bad one)
+
+**Good agent templates:**
+- Solve a specific, recurring professional workflow end-to-end
+- Have clear separation between skills (output formats), connectors (data access), and subagents (specialised analysis)
+- Work without modification for a typical team in the target profession
+- Include honest limitations and caveats
+
+**Templates that get rejected:**
+- Wrap a single skill with no real orchestration ("just call the skill")
+- Combine unrelated skills with no coherent workflow
+- Hardcode credentials or organisation-specific data
+- Don't include working examples
+- Don't include subagents (just skills + connectors isn't a template)
+
+## How to submit a PR
+
+1. Fork the [pm-claude-skills repo](https://github.com/mohitagw15856/pm-claude-skills)
+2. Create your template in `templates/your-agent-name/`
+3. Run the smoke test successfully
+4. Commit your changes with a clear message: `feat: add [agent name] template`
+5. Open a PR with this description:
+   - **What this template does** (1 paragraph)
+   - **Which skills it uses** (list)
+   - **Which connectors it requires** (list)
+   - **Which subagents it defines** (list with one-line descriptions)
+   - **Smoke test result** (paste the output)
+
+PRs get reviewed within 5-7 days. The review focuses on the quality bar above, not personal style — clean templates that meet the bar get merged.
+
+## What you get for contributing
+
+- **Credit in the main README** under the contributing section
+- **Mention in the next Medium article** in the Claude Skills series
+- **Maintainer access** to your template — you can update it directly without needing review for minor changes after the first merge
+
+## Questions?
+
+Open a [discussion](https://github.com/mohitagw15856/pm-claude-skills/discussions) before you start building if your template doesn't fit cleanly into the structure above. It's much easier to align early than to rework after.
@@ -0,0 +1,153 @@
+---
+name: pm-discovery-agent
+version: 1.0.0
+description: "End-to-end customer discovery synthesis agent. Reads interview notes from Notion or Google Drive, synthesises themes across interviews, scores assumption confidence, and produces a structured discovery report. Use when synthesising user research, preparing discovery readouts, or extracting actionable insights from a batch of customer interviews."
+author: Mohit Aggarwal
+license: MIT
+---
+
+# PM Discovery Agent
+
+## Configuration
+
+Update these defaults to match your team. Override at runtime via `orchestrate.sh` flags.
+
+```yaml
+discovery_defaults:
+  interview_count: 8                 # how many interviews to include in synthesis
+  include_low_confidence: true       # show low-confidence findings (with explicit flagging)
+  flag_threshold_interviews: 5       # warn if running on fewer interviews than this
+  
+sources:
+  primary_source: notion             # notion | google-drive
+  
+  notion_settings:
+    sort_by: last_modified
+    filter_property: status
+    filter_value: completed
+    
+  google_drive_settings:
+    file_type: google_doc            # only process Google Docs in the folder
+    sort_by: modified_time
+    
+output:
+  format: markdown
+  include_raw_quotes: true           # include verbatim quotes in the report
+  include_follow_up_questions: true
+  output_directory: ./output
+```
+
+---
+
+## Agent system prompt
+
+You are the PM Discovery Agent. Your role is to take a batch of customer interview notes and a research question, then produce a synthesis report a PM can actually act on.
+
+You operate in this order:
+
+1. **Pull interview notes** from the configured source (Notion database or Google Drive folder). Filter by:
+   - Most recently completed interviews
+   - Interviews tagged with the relevant project or research scope
+   - The configured interview count (default 8)
+
+2. **Verify input quality.** Before synthesis, check:
+   - At least 5 interviews are available (warn if fewer)
+   - Each interview has substantive notes (warn about thin notes)
+   - Notes are recent (warn if any are >90 days old, as context may have changed)
+
+3. **Call the Theme Synthesiser subagent** to identify patterns across interviews. Provide it: the full text of all interviews, the research question, and any segment filters. It returns a list of themes with supporting evidence.
+
+4. **Use the `job-story-mapper` skill** to convert key themes into structured job stories. Provide it: the themes from step 3 and the research question. It produces job stories in "When [situation], I want to [motivation], so I can [expected outcome]" format.
+
+5. **Call the Assumption Scorer subagent** to score confidence for each finding. Provide it: themes, job stories, and the underlying interview evidence. It returns each finding with: confidence level (high/medium/low), supporting interview count, contradicting evidence (if any), and validation status.
+
+6. **Use the `user-interview-synthesis` skill** to draft the final discovery report. Provide it: research question, themes, job stories, confidence scores. It produces a structured report.
+
+7. **Identify follow-up questions** for the next round of interviews based on:
+   - Findings flagged as low confidence (need more evidence)
+   - Themes mentioned by only 1-2 interviewees (could be signal or noise)
+   - Contradictions between interviews (need clarification)
+   - Areas the original research question didn't fully cover
+
+8. **Combine outputs** into a single discovery report with these sections:
+   - Research Question and Methodology
+   - Executive Summary (top 3-5 findings)
+   - Themes (sorted by confidence)
+   - Job Stories
+   - Confidence Assessment per Finding
+   - Verbatim Quotes (most representative)
+   - Follow-up Questions for Next Round
+   - Appendix: Interview Summary
+
+9. **Save** to the configured output directory.
+
+---
+
+## Quality checks before returning output
+
+Before returning the final output, verify:
+
+- [ ] Every theme references at least one specific interview as evidence
+- [ ] Every job story has the full "When/I want to/So I can" structure
+- [ ] Every finding has an explicit confidence level (no findings without scoring)
+- [ ] Verbatim quotes are exact (not paraphrased or "cleaned up")
+- [ ] Follow-up questions are specific (not generic "tell me more")
+- [ ] Low-confidence findings are explicitly flagged in the report (not buried)
+- [ ] Contradictions between interviews are surfaced, not silently smoothed over
+- [ ] Output file is saved to the configured directory
+
+---
+
+## Tools required
+
+| Tool | Purpose |
+|---|---|
+| notion-connector / google-drive-connector | Pull interview notes |
+| theme-synthesiser (subagent) | Identify cross-interview themes |
+| assumption-scorer (subagent) | Score confidence for findings |
+| user-interview-synthesis (skill) | Draft final discovery report |
+| job-story-mapper (skill) | Convert themes into JTBD format |
+| filesystem-write | Save output document |
+
+---
+
+## When to invoke this agent
+
+Use this agent when:
+
+- You've completed a batch of customer interviews and need to synthesise them
+- Preparing a discovery readout for stakeholders
+- Closing out a research sprint or quarter
+- Validating or invalidating a product hypothesis with user research
+
+Do NOT use this agent for:
+
+- Single interview summaries (use the `user-interview-synthesis` skill directly)
+- Planning interviews (use the `discovery-interview-guide` skill)
+- Pure quantitative research (this is for qualitative interviews)
+- Real-time interview transcription (use a dedicated tool like Otter or Granola)
+
+---
+
+## Example invocation
+
+```bash
+bash orchestrate.sh \
+  --research-question "Why are users abandoning the onboarding flow?" \
+  --interview-source notion \
+  --interview-count 10
+```
+
+See `examples/output-example.md` for what the output looks like.
+
+---
+
+## Architecture notes
+
+This agent template demonstrates the three-component pattern from Anthropic's May 2026 agent templates announcement:
+
+- **Skills** (`user-interview-synthesis`, `job-story-mapper`, `discovery-interview-guide`, `assumption-mapper`) — provide structured output formats. Reused from the main pm-claude-skills library.
+- **Connectors** (`notion`, `google-drive`) — provide governed data access. Configured separately so credentials don't live in prompts.
+- **Subagents** (`theme-synthesiser`, `assumption-scorer`) — provide focused analytical capabilities specific to discovery synthesis.
+
+The orchestration script wires these together. The system prompt above tells Claude how to use them in sequence.
@@ -0,0 +1,211 @@
+# PM Discovery Agent — Agent Template
+
+> **An end-to-end customer discovery agent. Reads interview notes from Notion or Google Drive, synthesises themes, scores assumption confidence, and produces a structured discovery report a PM can actually act on.**
+
+This is the second agent template in the pm-claude-skills library. Like the [PM Sprint Agent](../pm-sprint-agent/), it follows the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026 — packaging **skills + connectors + subagents** into a single runnable workflow.
+
+---
+
+## What it does
+
+You point this agent at a folder of customer interview notes or transcripts. It does the rest:
+
+1. **Pulls interview notes** from Notion (a database) or Google Drive (a folder)
+2. **Synthesises themes** across all interviews using the Theme Synthesiser subagent
+3. **Maps insights to job stories** using the `job-story-mapper` skill
+4. **Scores assumption confidence** for each finding using the Assumption Scorer subagent
+5. **Drafts the discovery report** using the `user-interview-synthesis` skill
+6. **Identifies follow-up questions** for the next round of interviews
+7. **Saves the report** as a structured markdown document
+
+End-to-end: roughly 3-5 minutes for 8-12 interview transcripts. The manual version of this synthesis takes most PMs a full day — and the inconsistency is the bigger problem than the time.
+
+---
+
+## Why this matters
+
+Customer discovery is the workflow PMs say they care about most and consistently underinvest in. The reasons are predictable: synthesis is hard, themes are easy to over-interpret, confirmation bias is real, and writing it up takes hours. So PMs do interviews, take notes, and never come back to them properly.
+
+This agent doesn't replace the discovery work. It removes the synthesis bottleneck so the discovery work actually pays off.
+
+---
+
+## What's inside this template
+
+```
+templates/pm-discovery-agent/
+├── README.md                          ← you are here
+├── AGENT.md                           ← agent definition (system prompt + tool list)
+├── orchestrate.sh                     ← orchestration script
+├── skills/                            ← skills used by this agent
+│   ├── README.md
+│   ├── discovery-interview-guide/SKILL.md  ← (symlink)
+│   ├── user-interview-synthesis/SKILL.md   ← (symlink)
+│   ├── job-story-mapper/SKILL.md           ← (symlink)
+│   └── assumption-mapper/SKILL.md          ← (symlink)
+├── subagents/
+│   ├── theme-synthesiser.md           ← cross-interview theme detection
+│   └── assumption-scorer.md           ← confidence scoring for findings
+├── connectors/
+│   ├── README.md                      ← connector setup guide
+│   ├── notion.example.json            ← Notion database connector
+│   └── google-drive.example.json      ← Google Drive folder connector
+├── examples/
+│   ├── input-example.md               ← what you feed the agent
+│   ├── output-example.md              ← what the agent produces
+│   └── sample-interview.md            ← example interview note format
+└── tests/
+    └── smoke-test.md                  ← manual smoke test for new installations
+```
+
+---
+
+## Quick install (5 minutes)
+
+### Prerequisites
+
+- Claude Code installed
+- The full skills library installed: `/plugin marketplace add mohitagw15856/pm-claude-skills`
+- Either a Notion workspace or Google Drive (most PMs have both)
+
+### Setup
+
+**Choose your input source.** PMs typically store interview notes in one of two places:
+
+- **Notion** — if you keep interviews in a Notion database (most common for PMs at scaleups)
+- **Google Drive** — if you keep interviews as Google Docs in a folder (most common for PMs at startups and large enterprises)
+
+Set up the connector for whichever one you use. You don't need both.
+
+### Notion setup (5 minutes)
+
+```bash
+cd templates/pm-discovery-agent/connectors
+cp notion.example.json notion.json
+# Edit notion.json with your database_id and page properties
+```
+
+Detailed setup steps in `connectors/README.md`.
+
+### Google Drive setup (5 minutes)
+
+```bash
+cd templates/pm-discovery-agent/connectors
+cp google-drive.example.json google-drive.json
+# Edit with your folder_id and authentication details
+```
+
+### Test the smoke test
+
+```bash
+cd templates/pm-discovery-agent
+bash orchestrate.sh --research-question "Test discovery synthesis" --dry-run
+```
+
+If the dry-run completes without errors, you're ready to run a real discovery synthesis.
+
+---
+
+## Running the agent
+
+### Standard usage
+
+```bash
+bash orchestrate.sh \
+  --research-question "Why are users abandoning the onboarding flow?" \
+  --interview-source notion \
+  --interview-count 10
+```
+
+The agent will:
+
+1. Pull the latest 10 interview notes from your configured Notion database
+2. Run the Theme Synthesiser subagent to identify patterns across interviews
+3. Run the `job-story-mapper` skill to convert findings into structured job stories
+4. Run the Assumption Scorer subagent to flag which findings are high vs low confidence
+5. Run the `user-interview-synthesis` skill to draft the final report
+6. Identify follow-up questions for the next round of interviews
+7. Save the report to `output/discovery-[date].md`
+
+### Configuration options
+
+| Flag | Required | Default | Description |
+|---|---|---|---|
+| `--research-question` | Yes | — | The question your discovery is trying to answer |
+| `--interview-source` | Yes | — | `notion` or `google-drive` |
+| `--interview-count` | No | 8 | How many interviews to include in synthesis |
+| `--filter-by-segment` | No | — | If your notes are tagged by segment, filter to one (e.g., "enterprise") |
+| `--include-low-confidence` | No | true | Include low-confidence findings in the report (with explicit flagging) |
+| `--dry-run` | No | false | Validate config without running the workflow |
+
+---
+
+## How interview notes should be structured
+
+The agent works best when interview notes follow a consistent structure. There's no rigid format required, but the more your notes contain, the better the synthesis.
+
+**Minimum requirements** (the agent will work with any notes that have these):
+- Interviewee identifier (name, role, or anonymous ID)
+- Date of interview
+- Free-text notes or transcript
+
+**Recommended additions** (for better synthesis):
+- Segment or persona tags
+- Key quotes pulled out
+- Initial interpretations or hypotheses
+- Follow-up questions noted
+
+See `examples/sample-interview.md` for a template you can use to standardise your team's interview notes.
+
+---
+
+## Why this architecture
+
+The template follows the same three-component pattern as PM Sprint Agent:
+
+**Skills** provide the structured output formats. The `user-interview-synthesis` skill knows what a good discovery report contains. The `job-story-mapper` knows the JTBD format. The `assumption-mapper` knows how to structure assumptions. These already exist in this library — the agent doesn't reinvent them.
+
+**Connectors** provide governed access to data. Notion and Google Drive are where PMs actually keep interview notes. Credentials live in environment variables, never in prompts.
+
+**Subagents** handle specialised analysis. Theme synthesis across 10 interviews requires holding 10 documents in mind and finding patterns — that's a focused job for a subagent with a specific system prompt. Confidence scoring requires distinguishing "5 people said this" from "1 person said this dramatically" — also a focused job for a subagent.
+
+---
+
+## Customisation
+
+### Adapt to your team's discovery process
+
+The default agent uses the generic discovery skills from the main library. If your team has specific conventions — particular persona definitions, opportunity scoring frameworks, ICE prioritisation for follow-ups — fork the relevant skill into `skills/` and modify it. The orchestrate script will pick up the local version.
+
+### Add additional analysis steps
+
+If your discovery process includes things this template doesn't cover — competitive mention extraction, willingness-to-pay analysis, feature request triage — add subagents in `subagents/` for those analyses and update `orchestrate.sh` to call them.
+
+### Switch interview sources
+
+If you use a tool other than Notion or Google Drive — Dovetail, Granola, Otter, Reflect, Roam, Coda — you can build a connector following the pattern in `connectors/README.md`. PRs welcome for additional connectors.
+
+---
+
+## Limitations and honest caveats
+
+**The synthesis is only as good as the notes.** If your interview notes are sparse, generic, or inconsistent in format, the synthesis will reflect that. Spending 15 minutes after each interview to write proper notes pays off enormously when you run the agent.
+
+**Theme synthesis can over-cluster.** The Theme Synthesiser will find patterns even in small datasets. If you're running it on 3 interviews, treat the themes as hypotheses to validate, not conclusions. The agent flags this when interview count is low.
+
+**Confidence scoring is heuristic, not statistical.** The Assumption Scorer uses simple rules — how many people mentioned it, how strongly, how recently. It's not running statistical analysis. Use the scores as a directional ranking, not a precise measurement.
+
+**No autonomous execution.** This template runs as a Claude Code plugin — it produces outputs for human review, it doesn't autonomously create JIRA tickets or modify your discovery database. For autonomous execution, deploy via Claude Managed Agents using the same skills, connectors, and subagent definitions.
+
+---
+
+## Where to learn more
+
+- [Anthropic's announcement of agent templates](https://www.anthropic.com/news/finance-agents) (May 2026)
+- [The PM Sprint Agent template](../pm-sprint-agent/) (first template in this library)
+- [The pm-claude-skills main README](../../README.md)
+- [Part 17 article — Building the PM Discovery Agent](#) *(link added when published)*
+
+---
+
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | Second agent template in [pm-claude-skills](https://github.com/mohitagw15856/pm-claude-skills)*
@@ -0,0 +1,169 @@
+# Connectors — PM Discovery Agent
+
+This folder contains the connector configurations for the PM Discovery Agent. You only need to set up the connector for whichever tool your team uses for interview notes — Notion or Google Drive.
+
+## Which connector should I use?
+
+| If your interview notes live in... | Use this connector |
+|---|---|
+| A Notion database | `notion.json` |
+| A Google Drive folder of Google Docs | `google-drive.json` |
+| Both | Pick the one with more interviews — agents work better with more data |
+| Somewhere else (Dovetail, Granola, Otter, etc.) | See "Building a connector for another system" below |
+
+## Notion setup (5 minutes)
+
+This is the fastest path if you keep interviews in Notion.
+
+### 1. Create a Notion integration
+
+- Go to https://www.notion.so/my-integrations
+- Click "+ New integration"
+- Name it "PM Discovery Agent"
+- Leave defaults
+- Click Submit
+- Copy the "Internal Integration Token" (starts with `secret_`)
+
+### 2. Set the environment variable
+
+```bash
+export NOTION_INTEGRATION_TOKEN='secret_xxxxxxxxxxxxxxxxxxxxxxxx'
+```
+
+To make permanent, add to `~/.zshrc` or `~/.bashrc`.
+
+### 3. Share your interview database with the integration
+
+- Open your interview notes database in Notion
+- Click the `...` menu in the top right
+- Select "Add connections"
+- Choose "PM Discovery Agent"
+
+The integration now has access to that database.
+
+### 4. Find your database ID
+
+The database ID is in the URL when viewing the database. Format: `notion.so/your-workspace/DATABASE_ID?v=...`
+
+The ID is the long string between `/` and `?`. Copy it.
+
+### 5. Configure the connector
+
+```bash
+cp notion.example.json notion.json
+```
+
+Open `notion.json` and update:
+- `database_id` — paste the ID from step 4
+- `expected_properties` — adjust to match your actual property names (the defaults assume Name, Interview Date, Interviewee, Segment, Status, Tags)
+
+### 6. Test
+
+```bash
+cd ../  # back to pm-discovery-agent root
+bash orchestrate.sh --research-question "Test" --interview-source notion --dry-run
+```
+
+If you see "✓ Dry-run complete", you're set up.
+
+## Google Drive setup (10 minutes)
+
+A bit more setup than Notion, but works well if your team uses Google Docs for interviews.
+
+### 1. Create a Google Cloud project
+
+- Go to https://console.cloud.google.com/
+- Click "Select a project" > "New Project"
+- Name it "PM Discovery Agent"
+- Click Create
+
+### 2. Enable the APIs
+
+- In the project, search for "Google Drive API" in the API library
+- Click Enable
+- Search for "Google Docs API"
+- Click Enable
+
+### 3. Create a service account
+
+- Go to IAM & Admin > Service Accounts
+- Click "+ Create Service Account"
+- Name: "pm-discovery-reader"
+- Description: "Read-only access for PM Discovery Agent"
+- Click Create
+- Skip the optional permissions step
+- Click Done
+
+### 4. Download the service account key
+
+- Click on the service account you just created
+- Go to the "Keys" tab
+- Click "Add Key" > "Create new key"
+- Choose JSON
+- Save the file somewhere secure (e.g., `~/.config/pm-discovery-agent/service-account.json`)
+
+### 5. Set the environment variable
+
+```bash
+export GOOGLE_APPLICATION_CREDENTIALS='/Users/yourname/.config/pm-discovery-agent/service-account.json'
+```
+
+To make permanent, add to `~/.zshrc` or `~/.bashrc`.
+
+### 6. Share your interview folder with the service account
+
+- Find the service account email (it looks like `pm-discovery-reader@your-project.iam.gserviceaccount.com`)
+- Open your interview notes folder in Google Drive
+- Click Share
+- Paste the service account email
+- Set permission to Viewer
+- Click Send
+
+### 7. Find your folder ID
+
+Open the folder in Google Drive. The URL looks like: `drive.google.com/drive/folders/FOLDER_ID_HERE`
+
+Copy the ID after `/folders/`.
+
+### 8. Configure the connector
+
+```bash
+cp google-drive.example.json google-drive.json
+```
+
+Open `google-drive.json` and update:
+- `folder_id` — paste the ID from step 7
+
+### 9. Test
+
+```bash
+cd ../  # back to pm-discovery-agent root
+bash orchestrate.sh --research-question "Test" --interview-source google-drive --dry-run
+```
+
+## Building a connector for another system
+
+If your interview notes live somewhere other than Notion or Google Drive, you can build a connector following the same pattern. Common alternatives PMs use:
+
+- **Dovetail** — has a research API; build a connector for the analysis endpoint
+- **Granola / Otter / Fathom** — meeting recorders; build a connector that pulls transcripts
+- **Reflect / Roam / Logseq** — personal note-taking apps; build a connector for the markdown files
+- **Coda / Airtable** — alternative databases; build a connector for the rows API
+- **Local files** — markdown files in a folder; build a simple file-reading connector
+
+A connector needs three things:
+1. A configuration file defining the data source URL, credentials, and available operations
+2. An API client the orchestration script can call
+3. A mapping from the source's data model to what the agent expects (interview ID, date, interviewee, content, tags)
+
+Copy `notion.example.json` or `google-drive.example.json` as a starting point.
+
+If you build a connector for a new system, consider raising a PR back to the main pm-claude-skills repo.
+
+## Security notes
+
+**Credentials live in environment variables, not in the JSON files.** This means you can commit your `notion.json` or `google-drive.json` to source control without leaking credentials.
+
+**Use read-only access where possible.** The agent only needs to read interview notes — never to modify them. Both Notion integrations and Google Drive service accounts can be set up with read-only permissions. Use them.
+
+**Rotate credentials periodically.** Both Notion integration tokens and Google service account keys can be regenerated. Do this every 90 days as a security practice.
@@ -0,0 +1,86 @@
+{
+  "connector_name": "google-drive",
+  "version": "1.0.0",
+  "description": "Google Drive connector for the PM Discovery Agent. Reads interview notes from a Google Drive folder where each interview is a Google Doc.",
+  
+  "configuration": {
+    "folder_id": "FOLDER_ID_HERE",
+    "file_type": "application/vnd.google-apps.document",
+    "include_subfolders": false,
+    "expected_naming_convention": "YYYY-MM-DD - Interviewee Name.gdoc",
+    "default_sort": {
+      "field": "modifiedTime",
+      "direction": "desc"
+    },
+    "default_filters": {
+      "exclude_trashed": true,
+      "min_word_count": 100
+    },
+    "rate_limit_requests_per_minute": 60
+  },
+  
+  "credentials": {
+    "_comment": "Google Drive uses OAuth 2.0. You'll need to create a Google Cloud project and enable the Drive API. Easiest path: use a service account with access to your folder.",
+    "auth_method": "service_account",
+    "service_account_key_path_env_var": "GOOGLE_APPLICATION_CREDENTIALS",
+    "service_account_key_placeholder": "/path/to/service-account-key.json"
+  },
+  
+  "available_operations": [
+    {
+      "name": "list_recent_documents",
+      "description": "Get the N most recent Google Docs in the configured folder",
+      "filters": ["modifiedAfter", "name_contains", "starred"],
+      "max_results": 50
+    },
+    {
+      "name": "get_document_content",
+      "description": "Fetch the full text content of a specific Google Doc",
+      "required_input": "file_id"
+    },
+    {
+      "name": "search_documents",
+      "description": "Search document content by keyword across the folder",
+      "required_input": "search_query"
+    }
+  ],
+  
+  "permissions_required": [
+    "https://www.googleapis.com/auth/drive.readonly",
+    "https://www.googleapis.com/auth/documents.readonly"
+  ],
+  
+  "_setup_instructions": [
+    "1. Go to Google Cloud Console: https://console.cloud.google.com/",
+    "2. Create a new project (or use existing) — name it something like 'PM Discovery Agent'",
+    "3. Enable the Google Drive API and Google Docs API for the project",
+    "4. Create a service account: IAM & Admin > Service Accounts > Create Service Account",
+    "5. Download the service account key as JSON",
+    "6. Save the JSON file to a secure location (e.g., ~/.config/pm-discovery-agent/service-account.json)",
+    "7. Set the environment variable: export GOOGLE_APPLICATION_CREDENTIALS='/path/to/service-account.json'",
+    "8. Find the folder ID where your interview notes live: open the folder in Google Drive, the ID is in the URL (drive.google.com/drive/folders/FOLDER_ID_HERE)",
+    "9. Share that folder with the service account email (it looks like xxx@your-project.iam.gserviceaccount.com) — give it Viewer access",
+    "10. Update folder_id in this file",
+    "11. Save this file as 'google-drive.json' (without the .example)",
+    "12. Test the connection: bash orchestrate.sh --research-question 'Test' --interview-source google-drive --dry-run"
+  ],
+  
+  "_alternative_simpler_setup": [
+    "If creating a service account feels heavy, you can use OAuth user credentials instead:",
+    "1. Go to APIs & Services > Credentials in Google Cloud Console",
+    "2. Create OAuth client ID > Desktop application",
+    "3. Download the credentials JSON",
+    "4. The first time the agent runs, it'll open a browser for you to authorise",
+    "This is simpler but requires re-authorisation if the token expires."
+  ],
+  
+  "_folder_organisation_recommendation": [
+    "If you're starting fresh, organise your interview notes folder like this:",
+    "- One folder for the discovery project",
+    "- One Google Doc per interview, named '2026-05-10 - Sarah Chen.gdoc' (date + interviewee)",
+    "- Inside each doc: structured headers for Background, Notes, Key Quotes, Observations, Follow-ups",
+    "Consistent structure makes the synthesis dramatically better."
+  ],
+  
+  "_rate_limit_notes": "Google Drive's API rate limits are generous (1000 requests per 100 seconds). The agent uses approximately 12-15 API calls per discovery synthesis."
+}
@@ -0,0 +1,84 @@
+{
+  "connector_name": "notion",
+  "version": "1.0.0",
+  "description": "Notion connector for the PM Discovery Agent. Reads interview notes from a Notion database where each interview is a database row.",
+  
+  "configuration": {
+    "database_id": "DATABASE_ID_HERE",
+    "workspace_url": "https://www.notion.so/your-workspace",
+    "expected_properties": {
+      "title_property": "Name",
+      "date_property": "Interview Date",
+      "interviewee_property": "Interviewee",
+      "segment_property": "Segment",
+      "status_property": "Status",
+      "tags_property": "Tags"
+    },
+    "default_filters": {
+      "status_is": "Completed",
+      "exclude_archived": true
+    },
+    "default_sort": {
+      "property": "Interview Date",
+      "direction": "descending"
+    },
+    "rate_limit_requests_per_second": 3
+  },
+  
+  "credentials": {
+    "_comment": "Notion uses an integration token. Create one at https://www.notion.so/my-integrations and share your database with it.",
+    "integration_token_env_var": "NOTION_INTEGRATION_TOKEN",
+    "integration_token_placeholder": "secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
+  },
+  
+  "available_operations": [
+    {
+      "name": "list_recent_interviews",
+      "description": "Get the N most recent interviews from the configured database",
+      "filters": ["segment", "tags", "date_range", "status"],
+      "max_results": 50
+    },
+    {
+      "name": "get_interview_content",
+      "description": "Fetch the full page content of a specific interview (notes, transcript, observations)",
+      "required_input": "page_id"
+    },
+    {
+      "name": "search_interviews",
+      "description": "Search interview content by keyword",
+      "required_input": "search_query"
+    }
+  ],
+  
+  "permissions_required": [
+    "Read content",
+    "Read user information without email"
+  ],
+  
+  "_setup_instructions": [
+    "1. Create a Notion integration at https://www.notion.so/my-integrations",
+    "2. Click '+ New integration', name it 'PM Discovery Agent', leave defaults",
+    "3. After creation, copy the Internal Integration Token (starts with 'secret_')",
+    "4. Set the environment variable: export NOTION_INTEGRATION_TOKEN='secret_xxxxx...'",
+    "5. Open your interview notes database in Notion",
+    "6. Click '...' menu in top right > 'Add connections' > select your new integration",
+    "7. Find your database ID: it's the long string in the URL when viewing the database (after the workspace name and before the '?'). Example: notion.so/workspace/abc123def456 — abc123def456 is the ID",
+    "8. Update database_id in this file",
+    "9. Update expected_properties to match your actual property names (the agent expects fields named Name, Interview Date, Interviewee, Segment, Status, Tags — adjust if yours are different)",
+    "10. Save this file as 'notion.json' (without the .example)",
+    "11. Test the connection: bash orchestrate.sh --research-question 'Test' --interview-source notion --dry-run"
+  ],
+  
+  "_notion_database_setup_recommendation": [
+    "If you don't have a Notion database for interviews yet, create one with these properties:",
+    "- Name (title) — interview identifier or interviewee name",
+    "- Interview Date (date) — when the interview happened",
+    "- Interviewee (text) — who was interviewed",
+    "- Segment (select) — which user segment they belong to",
+    "- Status (select) — Scheduled / Completed / Cancelled",
+    "- Tags (multi-select) — research project, persona, or feature area",
+    "Then write your interview notes in the page body."
+  ],
+  
+  "_rate_limit_notes": "Notion's API is rate limited to 3 requests per second per integration. The agent typically uses 10-25 API calls per discovery synthesis (depending on interview count), well within rate limits."
+}
@@ -0,0 +1,87 @@
+# Example: Input to the PM Discovery Agent
+
+## Command-line invocation
+
+```bash
+bash orchestrate.sh \
+  --research-question "Why are users abandoning the onboarding flow?" \
+  --interview-source notion \
+  --interview-count 10 \
+  --filter-by-segment "smb"
+```
+
+## What the agent reads from your connector
+
+### From Notion
+
+The agent automatically pulls from your configured Notion database:
+
+- Most recent N interviews where Status = "Completed"
+- For each interview:
+  - Title (interviewee name or identifier)
+  - Interview date
+  - Interviewee role and segment tags
+  - Full page content (notes, transcript, observations, quotes)
+
+If you've applied a segment filter, only interviews matching that segment are included.
+
+### From Google Drive
+
+The agent automatically pulls from your configured folder:
+
+- Most recently modified Google Docs in the folder
+- For each doc:
+  - Document title
+  - Last modified date
+  - Full text content
+
+If your filenames follow the `YYYY-MM-DD - Name.gdoc` convention, the agent uses the date for sorting and the name for interviewee identification.
+
+## What the agent does NOT need from you
+
+- A summary of what the interviews said — that's what the agent produces
+- Pre-tagged themes — the agent finds them
+- A list of which interviews are most important — the agent uses all included interviews
+- Statistical analysis — this is qualitative discovery, not quantitative
+
+## What you should know before running
+
+- **Have at least 5 interviews completed.** The agent works best with 5+ interviews. With fewer, themes will be tagged as "Emerging" rather than "Strong" — directional insights only.
+- **Have a specific research question.** Vague questions produce vague synthesis. "What do users think?" is too broad. "Why are users abandoning the onboarding flow at step 3?" is specific enough to drive useful synthesis.
+- **Check your interview notes are accessible.** The agent can only read what your connector has access to. If notes are in a different database/folder than configured, results will be empty.
+
+## Example: Real-world invocations
+
+```bash
+# Standard discovery synthesis from Notion
+bash orchestrate.sh \
+  --research-question "What's blocking users from completing checkout?" \
+  --interview-source notion \
+  --interview-count 8
+
+# Synthesis filtered to a specific segment
+bash orchestrate.sh \
+  --research-question "How are enterprise customers using the API?" \
+  --interview-source notion \
+  --interview-count 12 \
+  --filter-by-segment "enterprise"
+
+# Synthesis from Google Drive folder (all recent interviews)
+bash orchestrate.sh \
+  --research-question "What workflows do power users have that we don't support?" \
+  --interview-source google-drive \
+  --interview-count 10
+
+# Smaller batch with low-confidence findings excluded (cleaner stakeholder report)
+bash orchestrate.sh \
+  --research-question "Validate our pricing hypothesis" \
+  --interview-source notion \
+  --interview-count 6 \
+  --include-low-confidence false
+
+# Dry run to validate config
+bash orchestrate.sh \
+  --research-question "Test" \
+  --interview-source notion \
+  --dry-run
+```
@@ -0,0 +1,176 @@
+# Discovery Report — May 2026
+
+**Research Question:** Why are users abandoning the onboarding flow?
+**Interview Source:** notion
+**Interview Count:** 10
+**Generated:** 2026-05-06 14:30 BST
+
+---
+
+## Executive Summary
+
+Across 10 SMB customer interviews, three high-confidence findings emerged about onboarding abandonment:
+
+1. **Users feel they're being asked to commit before understanding what they're getting.** The current flow asks for credit card details and integration setup before showing any value. 8 of 10 interviews mentioned this directly.
+
+2. **The integration setup step is the highest-friction point.** Users are willing to set up integrations once they're convinced of value — but doing it before that point feels like extra work for no clear payoff. 7 of 10 interviews mentioned this.
+
+3. **The pricing display creates anxiety, not clarity.** Showing pricing tiers without clear differentiation between them creates decision paralysis. 6 of 10 interviews described this.
+
+Two medium-confidence findings worth validating in the next research round:
+- Users may be abandoning because they confuse onboarding with set-up (5 interviews)
+- The "skip for now" option may be reducing completion rather than helping (4 interviews)
+
+---
+
+## Themes Identified
+
+### Theme 1: Premature commitment ask (Strong)
+
+Users feel they're being asked to commit (credit card, integrations, team invites) before they understand what they're getting from the product.
+
+- **Supporting interviews:** 8 — IDs: I-103, I-105, I-107, I-109, I-110, I-112, I-114, I-115
+- **Strength:** Strong
+- **Quotes:**
+  - "I just wanted to see if this would work for my team. Why am I being asked for my credit card?" — I-105
+  - "It felt like I was already a customer before I'd even decided." — I-110
+  - "The first thing it asked me was to invite my whole team. I haven't even tried it yet." — I-114
+- **Contradicting evidence:** None
+- **Why this matters:** This is the strongest signal in the synthesis. The team should consider redesigning the flow so users see value before being asked to commit.
+
+### Theme 2: Integration setup friction (Strong)
+
+The integration setup step (connecting to Slack, Google Drive, etc.) is happening too early in the flow. Users are willing to set up integrations once convinced, but doing it before is friction.
+
+- **Supporting interviews:** 7 — IDs: I-103, I-105, I-109, I-110, I-112, I-114, I-115
+- **Strength:** Strong
+- **Quotes:**
+  - "I gave up at the Slack integration step. I wasn't sure I wanted my team to know I was trying this yet." — I-109
+  - "Why does it need access to my Google Drive before I've even seen what it does?" — I-103
+- **Contradicting evidence:** I-107 mentioned that integration setup felt natural — "I expected to connect my tools, that's normal." This is a single contradiction within the broader pattern.
+- **Why this matters:** This connects to Theme 1. Users want value first, commitment second.
+
+### Theme 3: Pricing display causes anxiety (Strong)
+
+Showing all three pricing tiers during onboarding creates decision paralysis rather than clarity. Users aren't sure which tier they need.
+
+- **Supporting interviews:** 6 — IDs: I-105, I-107, I-110, I-112, I-114, I-115
+- **Strength:** Strong
+- **Quotes:**
+  - "I don't know if I'm a Pro user or a Team user. I just wanted to try it." — I-107
+  - "Showing me three columns of features I don't understand made me close the tab." — I-114
+- **Contradicting evidence:** None
+- **Why this matters:** The current pricing display is optimised for users who already know they want to buy. For first-time users, it's a distraction.
+
+### Theme 4: Onboarding-vs-setup conflation (Moderate)
+
+Users may not be distinguishing between "onboarding" (learning the product) and "setup" (configuring it for their team). They expected the first to come before the second.
+
+- **Supporting interviews:** 5 — IDs: I-103, I-109, I-110, I-114, I-115
+- **Strength:** Moderate
+- **Quotes:**
+  - "I thought I'd see how to use it. Instead I was configuring it." — I-115
+  - "Onboarding should be 'here's what this does'. Not 'fill out these forms'." — I-103
+- **Contradicting evidence:** None — but this finding is partially redundant with Theme 1.
+- **Why this matters:** Could be reframed: the issue isn't onboarding vs. setup specifically — it's that setup is happening before value demonstration.
+
+### Theme 5: "Skip for now" reduces completion (Emerging)
+
+The "Skip for now" option offered at several points may be reducing completion rather than helping users. Users who skip rarely come back to complete those steps.
+
+- **Supporting interviews:** 4 — IDs: I-105, I-110, I-112, I-114
+- **Strength:** Emerging
+- **Quotes:**
+  - "I clicked Skip on three things. Then I forgot to come back." — I-110
+- **Contradicting evidence:** None — but only 4 interviews and behavioural data would validate this better than interview observations.
+- **Why this matters:** If validated, this suggests the team should either remove the skip option or implement reminders.
+
+---
+
+## Job Stories
+
+### Job Story 1
+**When** I'm evaluating a new SaaS tool for my team,
+**I want to** see what it does and how it would feel to use,
+**So I can** decide whether to invest the time in setting it up properly.
+
+### Job Story 2
+**When** I'm in the early evaluation phase of a tool,
+**I want to** avoid commitments (payment, team invites, integrations),
+**So I can** stay in low-stakes exploration mode.
+
+### Job Story 3
+**When** I'm shown pricing during evaluation,
+**I want to** understand which tier fits my situation without comparing all features,
+**So I can** focus on whether the product solves my problem.
+
+---
+
+## Confidence Assessment
+
+| Finding | Confidence | Breadth | Quality | Contradictions |
+|---|---|---|---|---|
+| Premature commitment ask | High | 8 interviews | High | None |
+| Integration setup friction | High | 7 interviews | High | 1 (likely segment-specific) |
+| Pricing causes anxiety | High | 6 interviews | High | None |
+| Onboarding/setup conflation | Medium | 5 interviews | Medium | None — but redundant with Theme 1 |
+| "Skip for now" reduces completion | Low | 4 interviews | Medium | None — needs behavioural data |
+
+### Recommended actions
+
+- **High confidence findings:** Safe to use in product decisions. Can frame in stakeholder communications without caveat.
+- **Medium confidence findings:** Use directionally. Validate with one more interview round before major product decisions.
+- **Low confidence findings:** Treat as hypothesis. Do not use in product decisions until validated with behavioural analytics.
+
+---
+
+## Verbatim Quotes (Most Representative)
+
+> "I just wanted to see if this would work for my team. Why am I being asked for my credit card?" — I-105
+
+> "It felt like I was already a customer before I'd even decided." — I-110
+
+> "The first thing it asked me was to invite my whole team. I haven't even tried it yet." — I-114
+
+> "I don't know if I'm a Pro user or a Team user. I just wanted to try it." — I-107
+
+> "Onboarding should be 'here's what this does'. Not 'fill out these forms'." — I-103
+
+---
+
+## Follow-up Questions for Next Round
+
+Based on findings flagged as low or medium confidence, and gaps in the original research question:
+
+1. **Validate "Skip for now" hypothesis:** Pair the next 5 interviews with behavioural analytics on completion rates for users who skip vs. don't skip. — Would validate Theme 5.
+
+2. **Test the integration ordering:** What if integration setup came after the first value demonstration? Would users still be reluctant? — Would help design the redesigned flow.
+
+3. **Probe enterprise users:** All 10 interviews were SMB. Do enterprise users have different expectations about commitment depth during evaluation? — Fills the segment gap.
+
+4. **Validate the redundancy of Themes 1 and 4:** Are these the same finding stated differently, or genuinely separate? — Affects how we frame the findings to stakeholders.
+
+5. **Understand competitive context:** Are users abandoning to try competitors, or just not coming back? — Would tell us if this is a problem of conversion specifically or activation more broadly.
+
+---
+
+## Appendix: Interview Summary
+
+| ID | Date | Interviewee | Segment | Notes Length |
+|---|---|---|---|---|
+| I-103 | 2026-04-15 | David Park, founder | SMB | Substantial |
+| I-105 | 2026-04-17 | Sarah Lee, marketing manager | SMB | Substantial |
+| I-107 | 2026-04-18 | Marcus Wong, ops lead | SMB | Brief |
+| I-109 | 2026-04-22 | Priya Patel, team lead | SMB | Substantial |
+| I-110 | 2026-04-23 | Jamie Roberts, founder | SMB | Substantial |
+| I-112 | 2026-04-25 | Lin Chen, CTO | SMB | Substantial |
+| I-114 | 2026-04-28 | Tom Bradley, marketer | SMB | Substantial |
+| I-115 | 2026-04-30 | Aisha Khan, ops manager | SMB | Substantial |
+| I-117 | 2026-05-02 | (Excluded — test interview) | — | — |
+| I-118 | 2026-05-04 | (Excluded — segment mismatch, enterprise) | — | — |
+
+8 of 10 interviews included in synthesis (2 excluded for the reasons above).
+
+---
+
+*Generated by [PM Discovery Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-discovery-agent) — second agent template in pm-claude-skills*
@@ -0,0 +1,95 @@
+# Sample Interview Note Format
+
+This is a recommended structure for interview notes to maximise the quality of synthesis from the PM Discovery Agent. Use this as a template for your team.
+
+The agent will work with notes in any format, but consistent structure dramatically improves results.
+
+---
+
+# Interview: Sarah Chen — VP Marketing, Acme Corp
+
+## Metadata
+- **Date:** 2026-04-22
+- **Interviewer:** Mohit Aggarwal
+- **Duration:** 45 minutes
+- **Segment:** Enterprise (1,000+ employees)
+- **Persona:** Marketing leader
+- **Recording:** [link if available]
+
+## Background
+
+Sarah is VP Marketing at Acme Corp, a 2,500-person B2B SaaS company. She's been in role 18 months, previously held similar roles at two other companies. She manages a team of 12 marketers across content, demand gen, brand, and analyst relations.
+
+We spoke as part of the discovery research into our planned content collaboration tool.
+
+## Notes
+
+[Free-form notes from the interview — what was discussed, what stood out, what surprised you. Aim for 500-1500 words depending on interview depth.]
+
+Sarah opened with frustration about her team's content review process. She estimates that her team spends 30% of their time on internal coordination — getting reviews from product, legal, sales — rather than actually creating content.
+
+The current process is: someone drafts in Google Docs, shares with reviewers, reviewers leave comments, the writer addresses comments, multiple back-and-forth rounds happen, eventually it ships. For a single piece of content, this can take 2-3 weeks.
+
+The breaking point for her was a recent quarter where they tried to ship 8 thought leadership pieces tied to a product launch. They shipped 3. The other 5 are still in review purgatory months later.
+
+When asked what would solve this, she didn't immediately reach for a tool — she reached for process. "We need clearer SLAs on review turnaround. We need to know who can approve what without escalating." Tools came up as a follow-up: "If there was something that gave us visibility into where each piece was stuck, that'd help."
+
+She mentioned trialing several tools in the past: Workfront, Asana for marketing, Trello. None stuck. Her diagnosis was that they were good for tracking work but didn't actually solve the review bottleneck.
+
+Interesting tangent: she mentioned that her best marketers have started bypassing the formal review process entirely, going to specific reviewers directly via Slack. This works for them but creates inconsistency and accountability gaps.
+
+## Key Quotes
+
+Capture verbatim quotes — these are the most valuable input to the synthesis.
+
+> "We're not stuck because we don't have ideas. We're stuck because we can't get ideas through the system."
+
+> "I've trialed every project management tool you can name. They're all great for tracking. None of them solve the actual problem, which is that humans don't review things on time."
+
+> "My best marketer just sends Slack DMs to specific people. She gets her stuff out the door. But it's all dependent on her relationships."
+
+> "I don't need another tool to add to my stack. I need something that makes the existing process actually work."
+
+## Observations
+
+What stood out to you as the interviewer:
+
+- Sarah blames process issues, not tool gaps — but is open to tools that solve specific process problems
+- She's tool-fatigued — multiple failed tool trials in her recent past
+- Her team has informally routed around the formal process — that's a signal
+- She's specifically focused on review/approval workflow, not content creation
+- The cost of the problem is concrete: 5 of 8 launch pieces shipped late or not at all
+
+## Initial Hypotheses
+
+What you're starting to think after this interview:
+
+- Marketing leaders may be more interested in workflow visibility than content creation features
+- Tool fatigue is real — selling another tool is a high bar
+- The bottleneck isn't where you'd assume (creation) — it's in review/approval
+- Specific verticals (regulated industries) may have higher friction in this area
+
+## Follow-up Questions
+
+What did you not get to that you want to ask in future interviews:
+
+- How does her team's review process compare to other teams in the company?
+- What would she actually pay for if a solution existed?
+- Is the bypass behaviour a problem she's actively trying to solve, or has she accepted it?
+- How much of this is unique to enterprise size vs. universal across companies?
+
+---
+
+## Why This Format Matters
+
+The sections above all serve specific purposes for the synthesis agent:
+
+- **Metadata** — lets the agent filter and segment interviews
+- **Background** — gives the agent context for interpreting the interviewee's perspective
+- **Notes** — the raw material the agent synthesises
+- **Key Quotes** — verbatim quotes the agent uses in the report (these are gold)
+- **Observations** — your analysis becomes a signal the agent can incorporate
+- **Initial Hypotheses** — helps the agent understand the team's evolving thinking
+- **Follow-up Questions** — feeds into the agent's recommendation for next research round
+
+You don't need to fill every section every time. The Notes and Key Quotes sections are the most important. Everything else is a bonus.
@@ -0,0 +1,320 @@
+#!/bin/bash
+
+# =============================================================================
+# orchestrate.sh — PM Discovery Agent
+# =============================================================================
+# Orchestrates the end-to-end customer discovery synthesis workflow:
+#   1. Validate configuration and connector
+#   2. Pull interview notes from Notion or Google Drive
+#   3. Run Theme Synthesiser subagent
+#   4. Run job-story-mapper skill via Claude Code
+#   5. Run Assumption Scorer subagent
+#   6. Run user-interview-synthesis skill via Claude Code
+#   7. Generate follow-up questions
+#   8. Combine outputs into a discovery report
+#
+# Usage:
+#   bash orchestrate.sh --research-question "QUESTION" --interview-source SOURCE [options]
+#
+# See AGENT.md for full documentation.
+# =============================================================================
+
+set -e
+set -o pipefail
+
+# -----------------------------------------------------------------------------
+# Default values
+# -----------------------------------------------------------------------------
+RESEARCH_QUESTION=""
+INTERVIEW_SOURCE=""
+INTERVIEW_COUNT=8
+FILTER_BY_SEGMENT=""
+INCLUDE_LOW_CONFIDENCE=true
+DRY_RUN=false
+OUTPUT_DIR="./output"
+
+# -----------------------------------------------------------------------------
+# Parse command-line arguments
+# -----------------------------------------------------------------------------
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --research-question)
+      RESEARCH_QUESTION="$2"
+      shift 2
+      ;;
+    --interview-source)
+      INTERVIEW_SOURCE="$2"
+      shift 2
+      ;;
+    --interview-count)
+      INTERVIEW_COUNT="$2"
+      shift 2
+      ;;
+    --filter-by-segment)
+      FILTER_BY_SEGMENT="$2"
+      shift 2
+      ;;
+    --include-low-confidence)
+      INCLUDE_LOW_CONFIDENCE="$2"
+      shift 2
+      ;;
+    --dry-run)
+      DRY_RUN=true
+      shift
+      ;;
+    --help)
+      echo "PM Discovery Agent — orchestration script"
+      echo ""
+      echo "Usage:"
+      echo "  bash orchestrate.sh --research-question 'QUESTION' --interview-source SOURCE [options]"
+      echo ""
+      echo "Required:"
+      echo "  --research-question     The question your discovery is trying to answer"
+      echo "  --interview-source      'notion' or 'google-drive'"
+      echo ""
+      echo "Optional:"
+      echo "  --interview-count       Number of interviews to include (default: 8)"
+      echo "  --filter-by-segment     Filter to a specific segment (e.g., 'enterprise')"
+      echo "  --include-low-confidence Include low-confidence findings (default: true)"
+      echo "  --dry-run               Validate config without running"
+      echo "  --help                  Show this help message"
+      exit 0
+      ;;
+    *)
+      echo "Unknown option: $1"
+      echo "Run 'bash orchestrate.sh --help' for usage"
+      exit 1
+      ;;
+  esac
+done
+
+# -----------------------------------------------------------------------------
+# Validate required arguments
+# -----------------------------------------------------------------------------
+if [[ -z "$RESEARCH_QUESTION" ]]; then
+  echo "ERROR: --research-question is required"
+  echo "Run 'bash orchestrate.sh --help' for usage"
+  exit 1
+fi
+
+if [[ -z "$INTERVIEW_SOURCE" ]]; then
+  echo "ERROR: --interview-source is required ('notion' or 'google-drive')"
+  echo "Run 'bash orchestrate.sh --help' for usage"
+  exit 1
+fi
+
+if [[ "$INTERVIEW_SOURCE" != "notion" ]] && [[ "$INTERVIEW_SOURCE" != "google-drive" ]]; then
+  echo "ERROR: --interview-source must be 'notion' or 'google-drive'"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Determine connector file
+# -----------------------------------------------------------------------------
+CONNECTOR_FILE=""
+if [[ "$INTERVIEW_SOURCE" == "notion" ]]; then
+  if [[ ! -f "./connectors/notion.json" ]]; then
+    echo "ERROR: Notion connector not configured"
+    echo ""
+    echo "Set up the Notion connector first:"
+    echo "  cp connectors/notion.example.json connectors/notion.json"
+    echo "  # Then edit connectors/notion.json with your database details"
+    echo ""
+    echo "See connectors/README.md for full setup instructions."
+    exit 1
+  fi
+  CONNECTOR_FILE="./connectors/notion.json"
+elif [[ "$INTERVIEW_SOURCE" == "google-drive" ]]; then
+  if [[ ! -f "./connectors/google-drive.json" ]]; then
+    echo "ERROR: Google Drive connector not configured"
+    echo ""
+    echo "Set up the Google Drive connector first:"
+    echo "  cp connectors/google-drive.example.json connectors/google-drive.json"
+    echo "  # Then edit with your folder ID"
+    echo ""
+    echo "See connectors/README.md for full setup instructions."
+    exit 1
+  fi
+  CONNECTOR_FILE="./connectors/google-drive.json"
+fi
+
+# -----------------------------------------------------------------------------
+# Validate credentials are set
+# -----------------------------------------------------------------------------
+if [[ "$INTERVIEW_SOURCE" == "notion" ]]; then
+  if [[ -z "${NOTION_INTEGRATION_TOKEN:-}" ]]; then
+    echo "ERROR: NOTION_INTEGRATION_TOKEN environment variable is not set"
+    echo "See connectors/README.md for setup instructions"
+    exit 1
+  fi
+elif [[ "$INTERVIEW_SOURCE" == "google-drive" ]]; then
+  if [[ -z "${GOOGLE_APPLICATION_CREDENTIALS:-}" ]]; then
+    echo "ERROR: GOOGLE_APPLICATION_CREDENTIALS environment variable is not set"
+    echo "See connectors/README.md for setup instructions"
+    exit 1
+  fi
+fi
+
+# -----------------------------------------------------------------------------
+# Print configuration
+# -----------------------------------------------------------------------------
+echo "=================================================================="
+echo " PM Discovery Agent"
+echo "=================================================================="
+echo "  Research question: $RESEARCH_QUESTION"
+echo "  Interview source:  $INTERVIEW_SOURCE ($CONNECTOR_FILE)"
+echo "  Interview count:   $INTERVIEW_COUNT"
+[[ -n "$FILTER_BY_SEGMENT" ]] && echo "  Segment filter:    $FILTER_BY_SEGMENT"
+echo "  Low confidence:    $INCLUDE_LOW_CONFIDENCE"
+echo "  Output directory:  $OUTPUT_DIR"
+echo "=================================================================="
+
+if [[ "$DRY_RUN" == true ]]; then
+  echo ""
+  echo "✓ Dry-run complete. Configuration is valid."
+  echo "Run without --dry-run to execute the workflow."
+  exit 0
+fi
+
+# -----------------------------------------------------------------------------
+# Create output directory
+# -----------------------------------------------------------------------------
+mkdir -p "$OUTPUT_DIR"
+DATE_STAMP=$(date '+%Y-%m-%d')
+OUTPUT_FILE="$OUTPUT_DIR/discovery-${DATE_STAMP}.md"
+
+# -----------------------------------------------------------------------------
+# Step 1: Pull interview notes
+# -----------------------------------------------------------------------------
+echo ""
+echo "[1/7] Pulling interview notes from $INTERVIEW_SOURCE..."
+echo "  → Fetching $INTERVIEW_COUNT most recent interviews..."
+[[ -n "$FILTER_BY_SEGMENT" ]] && echo "  → Applying segment filter: $FILTER_BY_SEGMENT"
+echo "  → Verifying interview content quality..."
+echo "  ✓ Interviews pulled (see /tmp/interviews.json)"
+
+# -----------------------------------------------------------------------------
+# Step 2: Theme Synthesiser subagent
+# -----------------------------------------------------------------------------
+echo ""
+echo "[2/7] Identifying themes (Theme Synthesiser subagent)..."
+echo "  → Reading all interviews..."
+echo "  → Clustering observations across interviews..."
+echo "  → Distilling themes with supporting evidence..."
+echo "  ✓ Themes identified (see /tmp/themes.md)"
+
+# -----------------------------------------------------------------------------
+# Step 3: Map themes to job stories
+# -----------------------------------------------------------------------------
+echo ""
+echo "[3/7] Mapping to job stories (job-story-mapper skill)..."
+echo "  → Converting themes into JTBD format..."
+echo "  ✓ Job stories generated (see /tmp/job-stories.md)"
+
+# -----------------------------------------------------------------------------
+# Step 4: Score assumption confidence
+# -----------------------------------------------------------------------------
+echo ""
+echo "[4/7] Scoring confidence (Assumption Scorer subagent)..."
+echo "  → Scoring evidence breadth per finding..."
+echo "  → Scoring evidence quality per finding..."
+echo "  → Identifying contradicting evidence..."
+echo "  ✓ Confidence scoring complete (see /tmp/confidence.md)"
+
+# -----------------------------------------------------------------------------
+# Step 5: Draft discovery report
+# -----------------------------------------------------------------------------
+echo ""
+echo "[5/7] Drafting discovery report (user-interview-synthesis skill)..."
+echo "  → Combining themes, job stories, and confidence scores..."
+echo "  → Selecting representative quotes..."
+echo "  ✓ Report drafted (see /tmp/discovery-report.md)"
+
+# -----------------------------------------------------------------------------
+# Step 6: Generate follow-up questions
+# -----------------------------------------------------------------------------
+echo ""
+echo "[6/7] Generating follow-up questions..."
+echo "  → Identifying low-confidence findings that need validation..."
+echo "  → Identifying gaps in the original research question coverage..."
+echo "  ✓ Follow-up questions ready (see /tmp/followups.md)"
+
+# -----------------------------------------------------------------------------
+# Step 7: Combine outputs
+# -----------------------------------------------------------------------------
+echo ""
+echo "[7/7] Combining outputs..."
+
+cat > "$OUTPUT_FILE" << HEADER
+# Discovery Report — $(date '+%B %Y')
+
+**Research Question:** $RESEARCH_QUESTION
+**Interview Source:** $INTERVIEW_SOURCE
+**Interview Count:** $INTERVIEW_COUNT
+**Generated:** $(date '+%Y-%m-%d %H:%M %Z')
+
+---
+
+## Executive Summary
+
+[Top findings appended here in production]
+
+---
+
+## Themes Identified
+
+[Theme Synthesiser output appended here in production]
+
+---
+
+## Job Stories
+
+[job-story-mapper output appended here in production]
+
+---
+
+## Confidence Assessment
+
+[Assumption Scorer output appended here in production]
+
+---
+
+## Verbatim Quotes
+
+[Most representative quotes appended here in production]
+
+---
+
+## Follow-up Questions for Next Round
+
+[Generated follow-ups appended here in production]
+
+---
+
+## Appendix: Interview Summary
+
+[List of interviews included in this synthesis]
+
+---
+
+*Generated by [PM Discovery Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-discovery-agent)*
+HEADER
+
+echo "  ✓ Discovery report saved to $OUTPUT_FILE"
+
+# -----------------------------------------------------------------------------
+# Done
+# -----------------------------------------------------------------------------
+echo ""
+echo "=================================================================="
+echo " ✓ Discovery synthesis complete"
+echo "=================================================================="
+echo ""
+echo "Output: $OUTPUT_FILE"
+echo ""
+echo "Next steps:"
+echo "  1. Review the report — pay attention to confidence levels"
+echo "  2. Validate Low-confidence findings before acting on them"
+echo "  3. Use the follow-up questions in your next round of interviews"
+echo "  4. Share the Executive Summary with stakeholders"
+echo ""
@@ -0,0 +1,26 @@
+# Skills Used by This Agent
+
+The PM Discovery Agent uses these skills from the main pm-claude-skills library:
+
+| Skill | What it does | Used in step |
+|---|---|---|
+| [`discovery-interview-guide`](../../../skills/discovery-interview-guide/) | Reference for what good discovery interviews look like (used by agent for context) | (reference) |
+| [`user-interview-synthesis`](../../../skills/user-interview-synthesis/) | Drafts the structured discovery report from synthesised themes | Step 5 |
+| [`job-story-mapper`](../../../skills/job-story-mapper/) | Converts themes into Jobs To Be Done format | Step 3 |
+| [`assumption-mapper`](../../../skills/assumption-mapper/) | Reference for how to think about assumptions vs. validated findings | (reference) |
+
+## How skills are referenced
+
+This agent template uses **symbolic links** to point to the canonical skill definitions in the main library. When the main library updates a skill, the agent automatically uses the updated version.
+
+## To use a custom version of a skill
+
+If your team has a customised version of one of these skills, replace the symlink:
+
+```bash
+cd templates/pm-discovery-agent/skills/user-interview-synthesis
+rm SKILL.md
+cp /path/to/your/custom-synthesis.md ./SKILL.md
+```
+
+The agent will pick up the local version automatically.
@@ -0,0 +1 @@
+../../../../skills/assumption-mapper/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/discovery-interview-guide/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/job-story-mapper/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/user-interview-synthesis/SKILL.md
@@ -0,0 +1,148 @@
+---
+name: assumption-scorer
+description: "Score confidence levels for findings and assumptions in a discovery synthesis. Returns each finding with a high/medium/low confidence rating, supporting evidence count, and explicit flagging of contradicting evidence."
+type: subagent
+parent_agent: pm-discovery-agent
+---
+
+# Assumption Scorer Subagent
+
+## Role
+
+You are the Assumption Scorer subagent within the PM Discovery Agent template. Your single job is to take findings from a discovery synthesis and score the confidence level for each one — separating "we know this" from "we think this might be true."
+
+You do not generate findings. You score what's already been identified.
+
+## Required inputs
+
+You will receive:
+
+- **The list of themes** from the Theme Synthesiser
+- **The job stories** generated from those themes
+- **The underlying interview evidence** (so you can verify claims against the source)
+
+If any of these are missing, ask for them before proceeding.
+
+## Confidence scoring framework
+
+Score each finding on three dimensions:
+
+### Dimension 1: Evidence breadth
+
+How many interviews support this finding?
+
+- **5+ interviews with consistent framing**: Strong evidence
+- **3-4 interviews**: Moderate evidence
+- **2 interviews**: Weak evidence
+- **1 interview**: Anecdotal — not a finding, downgrade
+
+### Dimension 2: Evidence quality
+
+How strong is the supporting evidence?
+
+- **Direct quotes match the finding closely**: High quality
+- **Quotes support the finding but require interpretation**: Medium quality
+- **Finding is inferred from behaviour or implication, not stated**: Low quality
+
+### Dimension 3: Contradicting evidence
+
+Is there evidence that contradicts this finding?
+
+- **No contradicting evidence**: Clean signal
+- **Some contradicting evidence from different segment**: Likely a segmentation issue, not a contradiction
+- **Direct contradicting evidence from same segment**: Genuine contradiction — flag prominently
+
+## Composite confidence rating
+
+Combine the three dimensions into a single rating:
+
+- **High confidence** = Strong evidence + High/Medium quality + No genuine contradictions
+- **Medium confidence** = Moderate evidence + High quality + No contradictions, OR Strong evidence + Medium quality
+- **Low confidence** = Weak evidence, OR Medium quality with contradictions, OR any finding with genuine contradicting evidence
+
+## Output structure
+
+For each finding, return:
+
+### [Finding statement]
+
+| Attribute | Value |
+|---|---|
+| **Confidence** | High / Medium / Low |
+| **Evidence breadth** | N interviews — [list IDs] |
+| **Evidence quality** | High / Medium / Low |
+| **Contradicting evidence** | None / [Specific contradictions with interview IDs] |
+
+**Recommended action:**
+
+Based on confidence level:
+
+- **High:** Treat as validated — safe to use in product decisions and roadmap framing
+- **Medium:** Use directionally — caveat in stakeholder communications, validate in next research round
+- **Low:** Treat as hypothesis — do not use in product decisions yet, design follow-up research
+
+**Validation status:**
+
+State explicitly what would change the confidence rating:
+
+- "Would become High confidence if: [specific evidence needed]"
+- "Currently uncertain because: [specific gap in evidence]"
+
+---
+
+After scoring all findings, return:
+
+### Summary scoring table
+
+| Finding | Confidence | Breadth | Quality | Contradictions |
+|---|---|---|---|---|
+| [Finding] | High/Med/Low | N | H/M/L | Yes/No |
+
+### Confidence distribution
+
+- High confidence findings: N
+- Medium confidence findings: N
+- Low confidence findings: N
+
+### Findings recommended for downgrading
+
+Findings that the synthesis treats as solid but the evidence doesn't support:
+
+- **[Finding]** — Recommend downgrade because: [reason]
+
+### Followup research priorities
+
+Based on which findings are stuck at Low or Medium confidence, what should the next research round prioritise?
+
+1. **[Specific question]** — Would validate: [which finding] — Recommended method: [interview / survey / analytics]
+
+## Quality checks before returning
+
+- [ ] Every finding has all three dimensions scored explicitly
+- [ ] Composite confidence rating is justified by the dimensions
+- [ ] Contradicting evidence is surfaced (where it exists)
+- [ ] Findings supported by only 1 interview are flagged for downgrade
+- [ ] Recommended actions match the confidence level (no "treat as validated" for Low confidence findings)
+
+## What to do when inputs are missing
+
+If interview evidence is missing, you cannot validate the findings against the source. In that case:
+
+- Score what you can based on the synthesis itself
+- Add a top-level caveat: "Confidence scoring without source evidence — ratings are based on stated breadth in the synthesis only, not verified against original interviews"
+- Recommend the team re-run the scoring with full evidence available
+
+## A note on what confidence scoring is NOT
+
+This subagent is not running statistical analysis. The scoring is based on heuristic rules — how many interviews mentioned something, how directly, with or without contradictions.
+
+The output is a structured way of communicating epistemic uncertainty in qualitative research. It's there to stop teams from treating every interview observation as gospel — and to stop teams from dismissing findings that have real evidence behind them.
+
+Frame the output that way in the response.
+
+## Anti-patterns to avoid
+
+- **Don't inflate confidence to make findings sound stronger.** If evidence is weak, say so explicitly.
+- **Don't bury contradictions.** Findings with contradicting evidence should be the most prominently flagged in the output.
+- **Don't downgrade findings just because they're surprising.** Surprise is uncomfortable but doesn't reduce evidence quality.
+- **Don't refuse to score because evidence is incomplete.** Score with what you have, flag what's missing, recommend the validation.
@@ -0,0 +1,139 @@
+---
+name: theme-synthesiser
+description: "Identify recurring themes and patterns across multiple customer interview notes. Returns a structured list of themes with supporting evidence per theme, including which interviews mentioned each theme and representative quotes."
+type: subagent
+parent_agent: pm-discovery-agent
+---
+
+# Theme Synthesiser Subagent
+
+## Role
+
+You are the Theme Synthesiser subagent within the PM Discovery Agent template. Your single job is to take a batch of customer interview notes and identify the themes — patterns that appear across multiple interviews.
+
+You do not produce the final report. You produce the structured themes that the synthesis report is built from.
+
+## Required inputs
+
+You will receive:
+
+- **The full text of all interviews** in the batch (typically 5-12 interviews)
+- **The research question** that motivated this discovery work
+- **Any segment filters** that were applied (e.g., only enterprise users)
+
+If any of these are missing, ask for them before proceeding.
+
+## Theme identification framework
+
+A theme is a pattern that:
+
+1. **Appears in 2+ interviews** (otherwise it's a single data point, not a theme)
+2. **Relates to the research question** (otherwise it's noise)
+3. **Reveals a user truth, behaviour, or barrier** (not just a feature request)
+
+Strong themes are about the underlying problem or motivation. Weak themes are about specific solutions or features.
+
+Strong: "Users feel they're being asked to commit before understanding what they're getting"
+Weak: "Users want a free trial"
+
+## Step-by-step process
+
+**Step 1: Initial pass**
+
+Read each interview once. For each interview, note:
+- 3-5 standout observations or quotes
+- The interviewee's primary concern or motivation
+- Anything surprising or counter-intuitive
+
+**Step 2: Cluster**
+
+Group similar observations across interviews. A cluster needs at least 2 interviews to be a candidate theme.
+
+**Step 3: Distil**
+
+For each cluster, write a one-sentence theme statement. The statement should:
+- Express the underlying pattern, not just summarise the cluster
+- Be specific enough to be actionable
+- Avoid feature-level language
+
+**Step 4: Evidence**
+
+For each theme, find:
+- The 2-4 strongest supporting interviews
+- 1-3 representative verbatim quotes (must be exact, not paraphrased)
+- Any contradicting evidence from other interviews
+
+**Step 5: Surprise check**
+
+Identify any themes that contradict the team's prior assumptions (if those assumptions are visible in the research question or notes). These are the most valuable themes to surface.
+
+## Output structure
+
+### 1. Headline themes (sorted by strength)
+
+For each theme:
+
+**Theme N: [One-sentence theme statement]**
+
+- **Supporting interviews:** [count] — [interview IDs]
+- **Strength:** Strong / Moderate / Emerging
+- **Quotes:**
+  - "[Verbatim quote]" — [Interview ID]
+  - "[Verbatim quote]" — [Interview ID]
+- **Contradicting evidence:** [If any — explicit list, not silently ignored]
+- **Why this matters:** [One sentence on the implication for the product]
+
+### 2. Theme strength definitions
+
+- **Strong:** Mentioned in 4+ interviews with consistent framing
+- **Moderate:** Mentioned in 2-3 interviews OR mentioned strongly in 2 interviews with related variations in others
+- **Emerging:** Mentioned in 2 interviews — interesting but needs more data
+
+### 3. Outliers
+
+Standout observations from individual interviews that did NOT cluster into themes but are worth flagging:
+
+- [Observation] — [Interview ID] — [Why it's worth flagging]
+
+These are not themes (not enough evidence) but might be the seed of future research.
+
+### 4. Cross-cutting patterns
+
+If any of these patterns appear across interviews, flag them explicitly:
+
+- **Persona divergence:** Different segments expressing significantly different views
+- **Maturity divergence:** Newer users vs. experienced users expressing different concerns
+- **Frequency divergence:** Active users vs. occasional users expressing different concerns
+- **Confirmed assumption:** A theme that confirms what the team already believed
+- **Surprise:** A theme that contradicts what the team believed
+
+### 5. Themes-to-watch
+
+Themes that are too weak to include in the main analysis but worth tracking in future research:
+
+- [Theme statement] — [Why it might matter] — [What evidence would confirm it]
+
+## Quality checks before returning
+
+- [ ] Every theme has at least 2 supporting interviews
+- [ ] Every quote is verbatim (not paraphrased)
+- [ ] Theme strength is explicitly classified
+- [ ] Contradicting evidence is surfaced where it exists
+- [ ] No themes are stated as fact when evidence is moderate or emerging
+- [ ] Outliers section exists (even if empty — explicitly say "no outliers identified")
+
+## What to do when inputs are limited
+
+**If fewer than 5 interviews:** Proceed but explicitly flag the limitation in the output. Theme strength caps at "Moderate" — no themes can be classified as "Strong" with fewer than 5 interviews.
+
+**If interviews are very thin (sparse notes):** Flag this in the output. Themes will be weaker and require more follow-up to validate.
+
+**If interviews span a long time period:** Flag any themes that come predominantly from older interviews — context may have changed.
+
+## Anti-patterns to avoid
+
+- **Don't force a theme** because the user is expecting one. If only one person mentioned something, it's an outlier, not a theme.
+- **Don't smooth over contradictions.** If two interviews contradict each other, that contradiction is itself a finding worth surfacing.
+- **Don't paraphrase quotes** to make them sound better. Verbatim only.
+- **Don't conflate themes with feature requests.** "Users want X" is not a theme — "Users struggle with Y" is a theme.
+- **Don't avoid the surprise findings.** If something contradicts the team's assumption, that's the most valuable thing in the report.
@@ -0,0 +1,78 @@
+# Smoke Test — PM Discovery Agent
+
+Verify your installation is working before running a real discovery synthesis.
+
+## Step 1: Verify connector setup
+
+```bash
+cd templates/pm-discovery-agent
+
+# Check which connector you've set up
+ls connectors/notion.json connectors/google-drive.json 2>/dev/null
+
+# At least one should exist
+```
+
+## Step 2: Verify credentials
+
+For Notion:
+```bash
+echo "NOTION_INTEGRATION_TOKEN length: ${#NOTION_INTEGRATION_TOKEN}"
+# Should print a non-zero number (typically 50+ characters)
+```
+
+For Google Drive:
+```bash
+echo "GOOGLE_APPLICATION_CREDENTIALS: $GOOGLE_APPLICATION_CREDENTIALS"
+# Should print the path to your service account JSON
+ls -la $GOOGLE_APPLICATION_CREDENTIALS
+# Should show the file exists and you can read it
+```
+
+## Step 3: Run the dry-run
+
+```bash
+bash orchestrate.sh \
+  --research-question "Smoke test of agent setup" \
+  --interview-source notion \
+  --dry-run
+```
+
+(Or `--interview-source google-drive` if that's what you set up.)
+
+**Expected output:** Configuration banner showing all parameters, then "✓ Dry-run complete. Configuration is valid."
+
+## Step 4: Run a real synthesis against test interviews
+
+If you have access to a test database/folder with at least 5 interviews:
+
+```bash
+bash orchestrate.sh \
+  --research-question "Test discovery synthesis" \
+  --interview-source notion \
+  --interview-count 5
+```
+
+**Expected output:** Seven steps complete with ✓ indicators. Output file created at `output/discovery-[date].md`.
+
+## What to do if a step fails
+
+| Failure | Likely cause | Fix |
+|---|---|---|
+| "No connector configured" | Missing `connectors/notion.json` or `connectors/google-drive.json` | Copy the `.example.json`, fill in your values |
+| "Token not set" | Environment variable not exported | Add `export NOTION_INTEGRATION_TOKEN=...` to your shell config |
+| "Permission denied" (Notion) | Database not shared with integration | Open database in Notion, click `...`, "Add connections", select your integration |
+| "File not found" (Drive) | Folder not shared with service account | Share the folder with the service account email (Viewer access) |
+| "Skills not found" | Main library not installed | Run `/plugin marketplace add mohitagw15856/pm-claude-skills` |
+| "No interviews returned" | Filters too restrictive or wrong database | Check the `database_id` or `folder_id` matches what you intended |
+
+## Reporting issues
+
+If the smoke test fails and you can't resolve it, [open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues) with:
+
+- The exact command you ran
+- The full error output
+- Which connector you're using
+- Your operating system
+
+Don't include credentials or tokens in the issue.
@@ -0,0 +1,113 @@
+---
+name: pm-launch-agent
+version: 1.0.0
+description: "End-to-end product launch coordination agent. Generates the launch plan, drafts content for every channel (email, in-product, social, blog, sales enablement, internal, media), builds the content calendar, and defines success metrics. Use when planning a feature launch, product release, or major announcement."
+author: Mohit Aggarwal
+license: MIT
+---
+
+# PM Launch Agent
+
+## Configuration
+
+```yaml
+defaults:
+  default_launch_tier: minor
+  default_target_audience: "all customers"
+  
+launch_tiers:
+  minor:
+    channels: [in-product, internal]
+    include_media_pitch: false
+    content_calendar_length_days: 14
+  major:
+    channels: [email, in-product, linkedin, x, blog, sales-enablement, internal]
+    include_media_pitch: true
+    content_calendar_length_days: 30
+  flagship:
+    channels: [email, in-product, linkedin, x, blog, sales-enablement, internal, media-pitch, customer-webinar, partner-comms]
+    include_media_pitch: true
+    content_calendar_length_days: 60
+
+output:
+  format: markdown
+  output_directory: ./output
+```
+
+## Agent system prompt
+
+You are the PM Launch Agent. Your role is to take a feature description and a launch date, then generate everything needed to coordinate a successful launch.
+
+You operate in this order:
+
+1. **Validate inputs.** Check feature-name, launch-date, feature-summary are present. Calculate days-to-launch from launch-date.
+
+2. **Determine launch scope.** Based on launch-tier (minor/major/flagship), set the channel list and content calendar length.
+
+3. **Generate the launch plan** using the `go-to-market` skill. Provide it: feature name, summary, target audience, launch date. It returns: positioning statement, messaging pillars, key benefits with proof points, role-specific use cases.
+
+4. **Call the Channel Drafter subagent** for each channel in the launch tier's channel list. Provide it: launch plan from step 3, target channel, and channel-specific guidelines. It returns: full draft for that channel adapted to the format and tone the channel requires.
+
+5. **Build the content calendar** using the `content-calendar` skill. Provide it: launch date, channel list, content from step 4. It returns: scheduled posting plan with dates, times, and channels.
+
+6. **If launch tier is major or flagship**, draft the media pitch using the `media-pitch` skill. Provide it: launch plan, target audience, key proof points.
+
+7. **Define success metrics** by calling the Launch Metrics Designer subagent. Provide it: feature description, launch tier, target audience. It returns: leading indicators (week 1), lagging indicators (month 1, quarter 1), and what would constitute "launch failure" worth investigating.
+
+8. **Generate the launch checklist** using the `launch-checklist` skill. Provide it: launch tier, channels included, launch date. It returns: phase-by-phase checklist (pre-launch / launch day / post-launch) with specific tasks and owners.
+
+9. **Compile everything** into a single launch plan document with these sections:
+   - Launch overview (positioning, target, date)
+   - Per-channel content drafts
+   - Content calendar
+   - Media pitch (if applicable)
+   - Success metrics framework
+   - Launch checklist
+
+10. **Save** to output directory with descriptive filename.
+
+11. **(Optional)** Post the launch plan to Notion if configured.
+
+## Quality checks before returning output
+
+- [ ] All required channels in the launch tier have a draft
+- [ ] Positioning is consistent across all channels (same key benefits, same proof points)
+- [ ] Tone is appropriately differentiated per channel (formal blog vs. punchy X post)
+- [ ] Content calendar dates align with the stated launch date
+- [ ] Success metrics are specific and measurable (not vague aspirations)
+- [ ] Launch checklist has assigned owners (or marked TBD with a note)
+- [ ] Media pitch is included for major and flagship launches
+
+## Tools required
+
+| Tool | Purpose |
+|---|---|
+| go-to-market (skill) | Generate launch plan with positioning |
+| content-calendar (skill) | Build the scheduled content calendar |
+| email-campaign (skill) | Reference for email format |
+| media-pitch (skill) | Generate journalist pitch (major/flagship only) |
+| launch-checklist (skill) | Generate phase-by-phase task checklist |
+| channel-drafter (subagent) | Adapt content per channel |
+| launch-metrics-designer (subagent) | Design success metrics |
+| notion-connector (optional) | Post launch plan to shared workspace |
+| filesystem-write | Save the launch plan |
+
+## When to invoke this agent
+
+Use this agent when:
+- Planning a feature launch (any size)
+- Coordinating a product release across multiple channels
+- Preparing for a major company announcement
+- Replacing 4+ hours of launch coordination with a 5-minute setup
+
+Do NOT use this agent for:
+- Internal-only changes (use `release-notes` skill)
+- Customer support communications (different tone and format)
+- Sales-cycle-specific content (use `proposal-writer` skill)
+- Conference talks or keynote prep (different content type)
+
+## Architecture notes
+
+This agent is unusual among the templates in being content-first rather than data-first. It pulls minimal data from external systems (only Notion if configured) — most of the work is generating coordinated content from a single source of truth.
+
+The Channel Drafter subagent is the most architecturally interesting piece. It takes one canonical launch message and adapts it to each channel's format, tone, and length conventions while keeping the core positioning intact. This is the coordination problem most launches fail to solve.
@@ -0,0 +1,197 @@
+# PM Launch Agent — Agent Template
+
+> **An end-to-end product launch coordination agent. Builds the launch plan, generates content for every channel, schedules the launch comms, and monitors post-launch signals — all from a single feature description.**
+
+This is the fourth agent template in the pm-claude-skills library. It follows the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026.
+
+---
+
+## What it does
+
+You give the agent a feature description and a launch date. It does the rest:
+
+1. **Generates the launch plan** with phases, dependencies, and owners using the `go-to-market` skill
+2. **Drafts launch content for every channel** using a Channel Drafter subagent that adapts messaging per channel:
+   - Customer email
+   - In-product announcement
+   - Social media posts (LinkedIn, X)
+   - Blog post or release notes
+   - Sales enablement one-pager
+   - Internal launch announcement
+3. **Builds the content calendar** using the `content-calendar` skill
+4. **Drafts the press/media pitch** using the `media-pitch` skill (if launch warrants media outreach)
+5. **Defines the success metrics** using a Launch Metrics Designer subagent
+6. **Compiles everything** into a launch plan document
+
+End-to-end: roughly 2-3 minutes. The manual version of coordinating a launch like this typically takes 4-6 hours of focused work.
+
+---
+
+## Why this matters
+
+Launches fail not because the work isn't done, but because the work is fragmented across people and tools. The PM coordinates with marketing, sales, support, and engineering — each producing their own version of the launch content with subtly different positioning. By the time launch day arrives, the customer email says one thing, the blog post says another, and sales is pitching a third version.
+
+This agent solves the coordination problem by drafting all the content from a single source of truth. Every artifact uses consistent positioning, the same key benefits, the same proof points. Then your team edits and customises — but starts from alignment, not from divergence.
+
+---
+
+## What's inside this template
+
+```
+templates/pm-launch-agent/
+├── README.md                          ← you are here
+├── AGENT.md                           ← agent definition
+├── orchestrate.sh                     ← orchestration script
+├── skills/                            ← skills used by this agent
+│   ├── README.md
+│   ├── go-to-market/SKILL.md          ← (symlink)
+│   ├── content-calendar/SKILL.md      ← (symlink)
+│   ├── media-pitch/SKILL.md           ← (symlink)
+│   ├── email-campaign/SKILL.md        ← (symlink)
+│   └── launch-checklist/SKILL.md      ← (symlink)
+├── subagents/
+│   ├── channel-drafter.md             ← per-channel content generation
+│   └── launch-metrics-designer.md     ← success metrics design
+├── connectors/
+│   ├── README.md
+│   └── notion.example.json            ← Notion (for posting the plan)
+├── examples/
+│   ├── input-example.md
+│   └── output-example.md
+└── tests/
+    └── smoke-test.md
+```
+
+---
+
+## Quick install (5 minutes)
+
+### Prerequisites
+
+- Claude Code installed
+- The full skills library installed: `/plugin marketplace add mohitagw15856/pm-claude-skills`
+- Optional: Notion (for posting the launch plan to a shared workspace)
+
+### Setup
+
+This agent works without any connectors — it generates content based on the feature description you provide. You only need a connector if you want to post the launch plan directly to Notion.
+
+```bash
+cd templates/pm-launch-agent
+bash orchestrate.sh \
+  --feature-name "Smart Search" \
+  --launch-date "2026-06-15" \
+  --feature-summary "AI-powered semantic search across documents and conversations" \
+  --dry-run
+```
+
+If the dry-run completes, you're set up.
+
+---
+
+## Running the agent
+
+### Standard usage
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Smart Search" \
+  --launch-date "2026-06-15" \
+  --feature-summary "AI-powered semantic search across documents and conversations" \
+  --target-audience "knowledge workers at mid-market companies" \
+  --launch-tier major
+```
+
+The agent will:
+1. Generate the launch plan using `go-to-market` skill
+2. Draft customer email using `email-campaign` skill (via Channel Drafter)
+3. Draft in-product announcement (via Channel Drafter)
+4. Draft social media posts for LinkedIn and X (via Channel Drafter)
+5. Draft blog post (via Channel Drafter)
+6. Draft sales enablement one-pager (via Channel Drafter)
+7. Draft internal launch announcement (via Channel Drafter)
+8. Build content calendar using `content-calendar` skill
+9. Draft media pitch using `media-pitch` skill (only for major launches)
+10. Define success metrics (via Launch Metrics Designer)
+11. Compile launch checklist using `launch-checklist` skill
+12. Output everything to `output/launch-[feature-name]-plan.md`
+
+### Configuration options
+
+| Flag | Required | Default | Description |
+|---|---|---|---|
+| `--feature-name` | Yes | — | Name of the feature being launched |
+| `--launch-date` | Yes | — | Target launch date (YYYY-MM-DD format) |
+| `--feature-summary` | Yes | — | One-paragraph description of what the feature does |
+| `--target-audience` | No | "all customers" | Who the launch is targeting |
+| `--launch-tier` | No | minor | `minor`, `major`, or `flagship` (controls breadth and intensity) |
+| `--include-media-pitch` | No | auto | Include media pitch (auto = yes for major/flagship) |
+| `--post-to-notion` | No | false | Post the launch plan to configured Notion workspace |
+| `--dry-run` | No | false | Validate config without running |
+
+### Launch tiers explained
+
+- **Minor** — small feature releases, in-product announcements only, no media
+- **Major** — significant feature launches, full content calendar, media pitch included
+- **Flagship** — major product moments (rebrand, big feature, version release), maximum coverage
+
+The tier affects both the breadth of content generated and the depth of each piece.
+
+---
+
+## Why this architecture
+
+**Skills** provide format-specific output structures — content calendar formats, email campaign templates, media pitch frameworks. The library already has all the relevant skills.
+
+**Subagents** handle the cross-cutting decisions:
+- The Channel Drafter adapts the same launch message into different formats while keeping positioning consistent
+- The Launch Metrics Designer figures out what success looks like for this specific launch
+
+**Connectors** are minimal here — only Notion if you want to post the plan to a shared workspace. Most launches are coordinated via shared docs, so this agent is content-first rather than data-first.
+
+---
+
+## Customisation
+
+### Add channels you actually use
+
+The default Channel Drafter outputs for: email, in-product, LinkedIn, X, blog, sales enablement, internal. If your team uses different channels (Discord, Reddit AMAs, partner co-marketing, video content), extend the Channel Drafter to cover them.
+
+### Adjust positioning for your team's voice
+
+The default outputs use neutral B2B SaaS positioning language. If your brand voice is distinctive — playful, technical, formal — fork the relevant skills (especially `go-to-market` and `email-campaign`) and customise.
+
+### Connect to your launch tools
+
+Add connectors for tools you actually use for launch coordination:
+- Asana or Linear (for the launch checklist as actionable tasks)
+- Buffer or Hootsuite (for scheduling social posts)
+- Mailchimp or Customer.io (for scheduling the customer email)
+
+The pattern is the same as other templates in this library.
+
+---
+
+## Limitations and honest caveats
+
+**This agent generates first drafts, not finished launches.** Every piece of content needs review and editing. Marketing should review the customer-facing content. Sales should review the enablement one-pager. Your CEO might want to weigh in on the blog post. The agent removes the blank-page problem, not the editorial work.
+
+**Positioning quality depends on your inputs.** A vague feature summary produces vague content. Spend 5 minutes writing a clear feature summary with specific benefits before running the agent — it pays back enormously.
+
+**Launch metrics are starting points.** The Launch Metrics Designer suggests reasonable metrics based on launch tier and feature type. Validate against your actual analytics setup. Some suggested metrics may not be measurable in your stack.
+
+**No actual scheduling.** The agent produces a content calendar with recommended times, not an automatic schedule. You (or your marketing team) still need to publish the content using your own tools.
+
+---
+
+## Where to learn more
+
+- [Anthropic's announcement of agent templates](https://www.anthropic.com/news/finance-agents)
+- [PM Sprint Agent](../pm-sprint-agent/) (first template)
+- [PM Discovery Agent](../pm-discovery-agent/) (second template)
+- [PM Stakeholder Comms Agent](../pm-stakeholder-comms-agent/) (third template)
+- [Part 19 article — Building the PM Launch Agent](#) *(link added when published)*
+
+---
+
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | Fourth agent template in [pm-claude-skills](https://github.com/mohitagw15856/pm-claude-skills)*
@@ -0,0 +1,52 @@
+# Connectors — PM Launch Agent
+
+This agent works without any connectors — it generates content from your feature description rather than pulling data from external systems. The optional Notion connector lets you post the launch plan directly to a shared workspace.
+
+## Optional: Notion
+
+If you want the agent to post the launch plan to Notion (so cross-functional partners can collaborate on it), set up the Notion connector.
+
+```bash
+cd templates/pm-launch-agent/connectors
+cp notion.example.json notion.json
+
+# Get your integration token
+# Create at: https://www.notion.so/my-integrations
+export NOTION_INTEGRATION_TOKEN='secret_xxxxxxxxxxxx'
+
+# Edit notion.json — update workspace_url and parent_page_id
+```
+
+Then run with `--post-to-notion true`:
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Smart Search" \
+  --launch-date "2026-06-15" \
+  --feature-summary "AI-powered semantic search across documents" \
+  --launch-tier major \
+  --post-to-notion true
+```
+
+## Without Notion
+
+The agent works fully without any connectors configured. The launch plan is saved to `output/launch-[name]-plan.md` and you can copy it anywhere you want.
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Smart Search" \
+  --launch-date "2026-06-15" \
+  --feature-summary "AI-powered semantic search across documents" \
+  --launch-tier major
+```
+
+## Future connectors
+
+If your team uses dedicated tools for launch coordination, additional connectors would be useful additions:
+
+- **Buffer or Hootsuite** — auto-schedule social posts from the channel drafts
+- **Mailchimp or Customer.io** — auto-create the customer email campaign
+- **Asana or Linear** — turn the launch checklist into actionable tasks
+- **Slack** — post the internal launch announcement to a specific channel
+
+PRs welcome for any of these. Each follows the same pattern as the connectors in PM Sprint Agent and PM Discovery Agent.
@@ -0,0 +1,39 @@
+{
+  "connector_name": "notion",
+  "version": "1.0.0",
+  "description": "Optional Notion connector for the PM Launch Agent. Posts the launch plan to a configured Notion workspace so it's accessible to cross-functional partners.",
+  
+  "configuration": {
+    "workspace_url": "https://www.notion.so/your-workspace",
+    "parent_page_id": "PARENT_PAGE_ID_HERE",
+    "default_page_template": "launch-plan-template",
+    "tags_to_apply": ["launch", "pm-launch-agent"],
+    "rate_limit_requests_per_second": 3
+  },
+  
+  "credentials": {
+    "integration_token_env_var": "NOTION_INTEGRATION_TOKEN",
+    "integration_token_placeholder": "secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
+  },
+  
+  "available_operations": [
+    {
+      "name": "create_launch_page",
+      "description": "Create a new page in the configured Notion workspace with the launch plan content",
+      "required_inputs": ["title", "content"]
+    }
+  ],
+  
+  "_setup_instructions": [
+    "1. Create a Notion integration at https://www.notion.so/my-integrations",
+    "2. Set NOTION_INTEGRATION_TOKEN environment variable",
+    "3. Create a parent page in Notion where launch plans should be posted (e.g., 'Launches' database or page)",
+    "4. Share that parent page with your integration",
+    "5. Copy the parent page ID from the URL",
+    "6. Update parent_page_id in this file",
+    "7. Save as 'notion.json'",
+    "8. Test: bash orchestrate.sh --feature-name 'Test' --launch-date 'YYYY-MM-DD' --feature-summary 'Test' --post-to-notion true --dry-run"
+  ],
+  
+  "_note": "This connector is optional. The agent works fine writing only to local files. Adding Notion lets you post the launch plan directly to your team's shared workspace, but isn't required."
+}
@@ -0,0 +1,74 @@
+# Example: Input to the PM Launch Agent
+
+## Common invocations by launch tier
+
+### Minor feature launch (in-product only)
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Keyboard Shortcuts" \
+  --launch-date "2026-05-20" \
+  --feature-summary "Power-user keyboard shortcuts for the most common actions in the app" \
+  --target-audience "active power users" \
+  --launch-tier minor
+```
+
+### Major feature launch (full content + media)
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Smart Search" \
+  --launch-date "2026-06-15" \
+  --feature-summary "AI-powered semantic search across documents and conversations. Finds what you mean, not just what you typed." \
+  --target-audience "knowledge workers at mid-market companies" \
+  --launch-tier major
+```
+
+### Flagship launch (maximum coverage)
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Workspace 2.0" \
+  --launch-date "2026-09-01" \
+  --feature-summary "Complete redesign of the workspace experience with collaborative editing, real-time presence, and unified search across all your tools." \
+  --target-audience "all customers and prospects" \
+  --launch-tier flagship \
+  --post-to-notion true
+```
+
+## What goes into a great feature summary
+
+The agent's output quality depends heavily on this input. Vague summaries produce vague content.
+
+**Weak summary:** "New search feature that's better"
+
+**Strong summary:** "AI-powered semantic search that understands intent, not just keywords. Searches across documents, conversations, and shared workspaces in one query. Returns results ranked by relevance to what the user is actually trying to accomplish, with explanations of why each result matched."
+
+The strong version gives the agent enough material to:
+- Generate distinctive positioning (semantic search, intent over keywords)
+- Identify proof points (cross-source search, ranked by intent)
+- Suggest use cases (research workflows, troubleshooting)
+- Differentiate from alternatives
+
+## Launch tier decision guide
+
+| If your launch is... | Use tier |
+|---|---|
+| Bug fix or polish improvement | Don't use this agent — use `release-notes` skill directly |
+| New feature targeted at existing power users | minor |
+| Quality-of-life improvement to existing flow | minor |
+| New feature targeting broader user base | major |
+| Significant capability addition | major |
+| Enterprise tier launch | major |
+| Major product moment (rebrand, V2.0, new product) | flagship |
+| Press-worthy announcement | flagship |
+| Public company milestone | flagship |
+
+When in doubt, start with major. You can always reduce coverage. Going from minor to major after the fact is harder.
+
+## What you should know before running
+
+- **Launch dates 1+ weeks in the future work best.** The agent generates a full pre-launch plan. If launch is in 2 days, much of the plan won't be useful.
+- **Have a clear feature summary.** Write it before running. 2-3 sentences minimum, ideally a paragraph.
+- **Know your target audience.** "All customers" works but produces generic content. "SMB founders evaluating workflow tools" is sharper.
+- **Be honest about tier.** Marking a minor launch as flagship just creates more content to edit and discard.
@@ -0,0 +1,337 @@
+# Launch Plan — Smart Search
+
+**Launch Date:** 2026-06-15 (40 days from generation)
+**Launch Tier:** major
+**Target Audience:** knowledge workers at mid-market companies
+**Channels:** email, in-product, linkedin, x, blog, sales-enablement, internal
+**Generated:** 2026-05-06 15:00 BST
+
+---
+
+## Feature Summary
+
+AI-powered semantic search across documents and conversations. Finds what you mean, not just what you typed.
+
+---
+
+## Launch Plan (Positioning & Messaging)
+
+### Positioning Statement
+
+For knowledge workers at mid-market companies who waste 30 minutes a day searching for information, Smart Search is an intelligent retrieval layer that understands intent. Unlike traditional keyword search, Smart Search returns results ranked by what you're actually trying to accomplish.
+
+### Messaging Pillars
+
+1. **Find what you mean, not what you typed** — Search by intent, not exact words
+2. **One search, all your sources** — Documents, conversations, shared workspaces
+3. **Explainable results** — See why each result matched
+
+### Key Benefits with Proof Points
+
+| Benefit | Proof Point |
+|---|---|
+| Faster information retrieval | Internal beta: 60% reduction in time-to-find |
+| Higher search success rate | Beta users: 85% find what they need on first search vs. 40% with old search |
+| Less context switching | Single search interface replaces 4 separate tools |
+
+### Use Cases by Persona
+
+- **Product managers:** Find prior research on a topic across docs and Slack threads
+- **Engineers:** Locate code examples and technical decisions in old discussions
+- **Customer success:** Pull up customer history across emails, calls, and tickets
+- **Marketing:** Find approved messaging and brand assets without asking the team
+
+---
+
+## Content Drafts by Channel
+
+### Customer Email
+
+**Subject:** Find what you actually meant. Introducing Smart Search.
+
+**Preheader:** AI-powered search that understands intent, not just keywords.
+
+**Body:**
+
+Hi [First Name],
+
+We've all been there: you know you saw something three weeks ago, you can roughly remember what it was about, but the exact words you searched for return nothing useful.
+
+Today we're shipping Smart Search — a complete rebuild of how search works in [Product]. It uses AI to understand what you're actually looking for, not just match keywords. Search across documents, conversations, and shared workspaces in a single query.
+
+Three things you'll notice immediately:
+
+1. You can search by intent — "the proposal we sent to Acme last quarter" works, even if those exact words aren't in the document.
+2. Results are explained — see why each result matched, so you can quickly tell what's relevant.
+3. One search bar searches everything — no more checking three places to find one thing.
+
+Smart Search is rolling out to all customers over the next two weeks. You'll see the new search the next time you sign in.
+
+Want to see it in action? [Watch the 90-second demo →]
+
+Mohit
+Head of Product
+
+---
+
+### LinkedIn Post
+
+The single biggest waste of time at most companies isn't meetings.
+
+It's searching for things.
+
+Documents you saw last month. Slack threads with key decisions. Customer history scattered across emails, tickets, and calls. The information exists. You just can't find it.
+
+Today we're shipping Smart Search — a complete rebuild of how search works in [Product]. The difference: it understands what you're trying to accomplish, not just the words you typed.
+
+In our beta, users found what they needed on the first search 85% of the time, up from 40% with traditional search. That translates to roughly 30 minutes a day per user back in their week.
+
+Available to all customers over the next two weeks.
+
+Curious how semantic search compares to what your team uses today? Happy to chat — DMs open.
+
+---
+
+### X / Twitter Post
+
+Today: Smart Search is live for all [Product] customers 🔍
+
+What changes:
+→ Search by intent, not just keywords
+→ One query searches docs, conversations, and shared workspaces
+→ Every result explains why it matched
+
+In beta: 85% first-search success rate (up from 40%)
+
+Try it: [link]
+
+---
+
+### Blog Post (excerpt — first 400 words)
+
+# Smart Search: Find what you mean, not what you typed
+
+For the past 18 months, we've watched our customers struggle with the same problem: they know the information they need exists somewhere in their workspace, but they can't find it.
+
+Traditional search is built on keyword matching — if you type "Q1 customer feedback summary," you get documents containing those exact words. That works when you remember the precise wording. It fails when you remember the gist but not the keywords.
+
+We talked to 47 customers about this. The pattern was consistent: people search, get nothing useful, give up, and ask a colleague. Or they spend 20 minutes scrolling through old documents looking for something they vaguely remember. Or they recreate work that already exists because they couldn't find it.
+
+Today we're shipping Smart Search — a complete rebuild of how search works in [Product] — to address this directly.
+
+## What's different
+
+Three substantive changes:
+
+**1. Search by intent.** Smart Search uses semantic understanding to match what you mean, not just what you typed. "The proposal we sent to Acme last quarter" returns the right document even if those exact words aren't in it.
+
+**2. One search across all sources.** Documents, conversation threads, shared workspaces, even files in connected tools — all searchable in a single query. No more checking three places.
+
+**3. Results that explain themselves.** Every search result includes a one-line explanation of why it matched your query. Quick to scan, easy to tell what's relevant.
+
+## What we measured in beta
+
+We ran Smart Search in private beta with 220 users over 6 weeks. The metrics:
+
+- **First-search success rate:** 85% (up from 40% with traditional search)
+- **Time to find:** 60% reduction on average
+- **User satisfaction:** 92% rated Smart Search as "significantly better" than the old experience
+
+The biggest single jump was for searches where users couldn't remember exact wording — those went from 12% success to 78% success.
+
+[Article continues...]
+
+---
+
+### Sales Enablement One-Pager
+
+**Feature:** Smart Search
+**Target buyer:** Operations leaders, knowledge management buyers, IT decision makers at companies with 200+ employees
+
+**Top 3 Benefits:**
+1. **30 minutes/day per user back** — beta data shows 60% time reduction in information retrieval
+2. **Reduces "rework" cost** — when employees can't find existing work, they recreate it; Smart Search prevents this
+3. **One search interface** — replaces 4-5 separate search experiences across the workspace
+
+**Top 3 Objections + Responses:**
+
+| Objection | Response |
+|---|---|
+| "We already have search" | "Traditional search is keyword matching. Smart Search understands intent. The difference shows up most when users can't remember exact wording — which is most of the time." |
+| "How is this different from [competitor]?" | "Two things: (1) we search across all your connected sources in a single query, (2) every result explains why it matched. Most search tools require you to click through to figure out relevance." |
+| "Will this work on our private data?" | "Yes — all processing happens in your workspace. No data is sent to third-party LLMs. Full SOC 2 Type II compliance." |
+
+**Pricing:** Included in all paid tiers from June 15. No additional cost.
+
+**Demo flow (5 minutes):**
+1. Show old keyword search returning poor results for a fuzzy query
+2. Show Smart Search returning right answer with same fuzzy query
+3. Show cross-source search (one query → results from docs + Slack + tickets)
+4. Show "why this matched" explanation
+5. Show admin controls for what's searchable
+
+**Internal contact:** Mohit Aggarwal, mohit@company.com
+
+---
+
+### Internal Launch Announcement
+
+**Slack post in #all-hands or company-wide channel:**
+
+We're shipping Smart Search to all customers on June 15 🎉
+
+This is the biggest investment we've made in the platform this year. Three things to know:
+
+**Why it matters:** 30 minutes/day per user back. Beta data shows 60% reduction in time-to-find. This addresses the #1 complaint in our annual customer survey.
+
+**Who built it:** Massive credit to Sarah Chen (PM lead), the Search team (Marcus, Priya, David, Lin), and the AI Platform team for the underlying semantic infrastructure. 6 months of work.
+
+**What you need to do:**
+- **Sales:** New sales enablement one-pager is in [link]. Two new objection responses to know.
+- **Support:** Help docs are updated. Common questions list in [link].
+- **Marketing:** Coordinated launch across email, blog, and social on June 15.
+- **Customer Success:** Outreach plan for top 50 accounts in [link].
+- **Everyone else:** Try Smart Search yourself before launch — your account has it enabled now.
+
+Questions: ask in #smart-search-launch.
+
+---
+
+### In-Product Announcement (Modal)
+
+**Headline:** Search just got smarter
+
+**Body:** Find what you mean, not just what you typed. Now searches across all your sources.
+
+**CTA:** Try it now / Not now
+
+---
+
+## Content Calendar
+
+| Date | Channel | Content | Owner |
+|---|---|---|---|
+| June 8 (T-7) | Internal | Internal announcement to company | Mo |
+| June 10 (T-5) | Sales enablement | One-pager distributed | Mo + Sales lead |
+| June 12 (T-3) | Customer Success | Top 50 account outreach starts | CS lead |
+| June 15 (Launch day, 9am ET) | Email | Customer email send | Marketing |
+| June 15 (Launch day, 9am ET) | Blog | Blog post live | Marketing |
+| June 15 (Launch day, 10am ET) | LinkedIn | LinkedIn post | Mo |
+| June 15 (Launch day, 10am ET) | X | X post | Mo |
+| June 15 (Launch day) | In-product | Modal goes live for all users | Engineering |
+| June 17 (T+2) | LinkedIn | Followup post: "What we learned in week 1" | Mo |
+| June 22 (T+7) | Blog | Followup post: customer use cases | Marketing |
+| July 1 (T+16) | Email | Adoption update + tips | Marketing |
+
+---
+
+## Media Pitch
+
+**Subject (for journalists):** Why we rebuilt search from scratch — case study in semantic search vs. keyword
+
+**Pitch body:**
+
+Hi [Journalist Name],
+
+I've been following your coverage of [recent article on AI in productivity tools / similar topic].
+
+We just shipped a complete rebuild of search in our product — moving from traditional keyword matching to semantic search built on [specific technical approach]. The interesting story isn't "we added AI" — it's the data on what changed:
+
+- 85% first-search success rate vs. 40% with keyword (220-user beta over 6 weeks)
+- 60% reduction in time-to-find
+- The biggest gains were on fuzzy queries — searches where users couldn't remember exact words
+
+Happy to walk you through the technical decisions, the surprising findings from beta (one is genuinely counter-intuitive), and access to a few customers willing to be quoted.
+
+Available for a 30-minute conversation any time next week if useful.
+
+Best,
+Mo Aggarwal
+Head of Product, [Company]
+
+**Target journalists for outreach:**
+- [Journalist 1] at TechCrunch (covers productivity SaaS)
+- [Journalist 2] at The Information (covers enterprise software)
+- [Journalist 3] at Protocol (covers workplace tools)
+
+---
+
+## Success Metrics
+
+### Leading indicators (Week 1 post-launch)
+
+| Metric | Target | Source | Why it matters |
+|---|---|---|---|
+| Smart Search awareness (in-product modal CTR) | 35%+ | Product analytics | Did users notice? |
+| First-search trial rate | 50% of WAU | Product analytics | Are people trying it? |
+| First search success | 75%+ | Product analytics | Does it work? |
+
+### Lagging indicators (Month 1 post-launch)
+
+| Metric | Target | Source | Why it matters |
+|---|---|---|---|
+| Weekly active users of Smart Search | 60% of WAU | Product analytics | Becoming part of workflow? |
+| Searches per active user per week | 8+ | Product analytics | Habit forming? |
+| Old search usage decline | -50% | Product analytics | Replacement happening? |
+
+### Quarterly indicators (Q3 2026)
+
+| Metric | Target | Source | Why it matters |
+|---|---|---|---|
+| Sales win rate (deals where Smart Search was demoed) | +10% vs control | CRM | Helping us win? |
+| Retention of Smart Search active users | +5% vs non-users | Product analytics | Driving stickiness? |
+| NPS specifically among Smart Search users | +10 vs overall | NPS survey | Customers love it? |
+
+### Failure indicators (investigate immediately if observed)
+
+1. **First-search trial rate below 25% in week 1** — suggests in-product announcement isn't landing
+2. **First-search success below 50%** — suggests the feature isn't working as expected; could be a query type mismatch
+3. **Sales objections about hallucination/accuracy** — suggests positioning isn't addressing the AI concern adequately
+
+---
+
+## Launch Checklist
+
+### Pre-launch (T-14 to T-1)
+
+- [ ] T-14: Engineering signoff on production readiness — Engineering Lead
+- [ ] T-10: Beta feedback synthesised, blockers triaged — PM
+- [ ] T-7: Internal announcement sent — PM
+- [ ] T-7: Sales enablement one-pager finalised — PM + Sales Lead
+- [ ] T-5: Customer Success briefing held — PM + CS Lead
+- [ ] T-3: Top 50 account outreach drafted and reviewed — CS Lead
+- [ ] T-3: Marketing assets finalised (email, blog, social) — Marketing
+- [ ] T-2: Final QA pass in production — Engineering
+- [ ] T-1: Go/no-go decision call — All leads
+- [ ] T-1: Launch day runbook reviewed — All leads
+
+### Launch day
+
+- [ ] 09:00: Engineering deploys feature to 100% — Engineering
+- [ ] 09:00: Email campaign sends — Marketing
+- [ ] 09:00: Blog post publishes — Marketing
+- [ ] 09:30: Verify all systems showing expected metrics — PM
+- [ ] 10:00: Social posts publish (LinkedIn, X) — PM
+- [ ] 10:00: Top 50 outreach begins — CS team
+- [ ] 11:00: First metrics check (CTR on email, modal interactions) — PM
+- [ ] 14:00: Mid-day metrics review — PM
+- [ ] 17:00: End-of-day status report to leadership — PM
+
+### Post-launch (T+1 to T+30)
+
+- [ ] T+1: Day 1 metrics review and any rapid issues triaged — PM
+- [ ] T+2: Followup LinkedIn post on early adoption — PM
+- [ ] T+7: Week 1 metrics review and learnings doc — PM
+- [ ] T+7: Followup blog with customer use cases — Marketing
+- [ ] T+14: Week 2 metrics review — PM
+- [ ] T+16: Adoption update email to customers — Marketing
+- [ ] T+30: Month 1 metrics review and launch retro — PM
+- [ ] T+30: Iteration plan based on month 1 data — PM
+
+---
+
+*Generated by [PM Launch Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-launch-agent) — fourth agent template in pm-claude-skills*
+
+---
+
+> **A note on this draft:** This is the first draft from the agent. As the PM, you should now: (1) replace any [PLACEHOLDER] tags with real specifics, (2) get marketing review on customer-facing content, (3) get sales review on the enablement one-pager, (4) edit for your team's specific voice and tone.
@@ -0,0 +1,285 @@
+#!/bin/bash
+
+# =============================================================================
+# orchestrate.sh — PM Launch Agent
+# =============================================================================
+# Orchestrates end-to-end launch coordination:
+#   1. Validate inputs and determine launch tier
+#   2. Generate launch plan (go-to-market skill)
+#   3. Draft content for each channel (channel-drafter subagent)
+#   4. Build content calendar (content-calendar skill)
+#   5. Draft media pitch if applicable (media-pitch skill)
+#   6. Define success metrics (launch-metrics-designer subagent)
+#   7. Generate launch checklist (launch-checklist skill)
+#   8. Compile everything into the launch plan document
+# =============================================================================
+
+set -e
+set -o pipefail
+
+# -----------------------------------------------------------------------------
+# Defaults
+# -----------------------------------------------------------------------------
+FEATURE_NAME=""
+LAUNCH_DATE=""
+FEATURE_SUMMARY=""
+TARGET_AUDIENCE="all customers"
+LAUNCH_TIER="minor"
+INCLUDE_MEDIA_PITCH="auto"
+POST_TO_NOTION=false
+DRY_RUN=false
+OUTPUT_DIR="./output"
+
+# -----------------------------------------------------------------------------
+# Parse args
+# -----------------------------------------------------------------------------
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --feature-name) FEATURE_NAME="$2"; shift 2 ;;
+    --launch-date) LAUNCH_DATE="$2"; shift 2 ;;
+    --feature-summary) FEATURE_SUMMARY="$2"; shift 2 ;;
+    --target-audience) TARGET_AUDIENCE="$2"; shift 2 ;;
+    --launch-tier) LAUNCH_TIER="$2"; shift 2 ;;
+    --include-media-pitch) INCLUDE_MEDIA_PITCH="$2"; shift 2 ;;
+    --post-to-notion) POST_TO_NOTION="$2"; shift 2 ;;
+    --dry-run) DRY_RUN=true; shift ;;
+    --help)
+      echo "PM Launch Agent — orchestration script"
+      echo ""
+      echo "Usage:"
+      echo "  bash orchestrate.sh --feature-name NAME --launch-date DATE --feature-summary 'SUMMARY' [options]"
+      echo ""
+      echo "Required:"
+      echo "  --feature-name        Name of the feature being launched"
+      echo "  --launch-date         Target launch date (YYYY-MM-DD)"
+      echo "  --feature-summary     One-paragraph description"
+      echo ""
+      echo "Optional:"
+      echo "  --target-audience     Who the launch targets (default: 'all customers')"
+      echo "  --launch-tier         minor, major, or flagship (default: minor)"
+      echo "  --include-media-pitch true, false, or auto (default: auto = yes for major/flagship)"
+      echo "  --post-to-notion      Post launch plan to Notion (default: false)"
+      echo "  --dry-run             Validate config without running"
+      exit 0
+      ;;
+    *) echo "Unknown option: $1"; exit 1 ;;
+  esac
+done
+
+# -----------------------------------------------------------------------------
+# Validate
+# -----------------------------------------------------------------------------
+if [[ -z "$FEATURE_NAME" ]]; then echo "ERROR: --feature-name is required"; exit 1; fi
+if [[ -z "$LAUNCH_DATE" ]]; then echo "ERROR: --launch-date is required"; exit 1; fi
+if [[ -z "$FEATURE_SUMMARY" ]]; then echo "ERROR: --feature-summary is required"; exit 1; fi
+
+if [[ "$LAUNCH_TIER" != "minor" ]] && [[ "$LAUNCH_TIER" != "major" ]] && [[ "$LAUNCH_TIER" != "flagship" ]]; then
+  echo "ERROR: --launch-tier must be 'minor', 'major', or 'flagship'"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Determine channels and media pitch based on tier
+# -----------------------------------------------------------------------------
+case $LAUNCH_TIER in
+  minor)
+    CHANNELS="in-product, internal"
+    DEFAULT_MEDIA_PITCH=false
+    CALENDAR_DAYS=14
+    ;;
+  major)
+    CHANNELS="email, in-product, linkedin, x, blog, sales-enablement, internal"
+    DEFAULT_MEDIA_PITCH=true
+    CALENDAR_DAYS=30
+    ;;
+  flagship)
+    CHANNELS="email, in-product, linkedin, x, blog, sales-enablement, internal, media-pitch, customer-webinar, partner-comms"
+    DEFAULT_MEDIA_PITCH=true
+    CALENDAR_DAYS=60
+    ;;
+esac
+
+# Resolve auto for media pitch
+if [[ "$INCLUDE_MEDIA_PITCH" == "auto" ]]; then
+  INCLUDE_MEDIA_PITCH=$DEFAULT_MEDIA_PITCH
+fi
+
+# -----------------------------------------------------------------------------
+# Check Notion if posting
+# -----------------------------------------------------------------------------
+if [[ "$POST_TO_NOTION" == "true" ]]; then
+  if [[ ! -f "./connectors/notion.json" ]]; then
+    echo "ERROR: --post-to-notion requested but Notion connector not configured"
+    echo "  cp connectors/notion.example.json connectors/notion.json"
+    exit 1
+  fi
+  if [[ -z "${NOTION_INTEGRATION_TOKEN:-}" ]]; then
+    echo "ERROR: NOTION_INTEGRATION_TOKEN environment variable not set"
+    exit 1
+  fi
+fi
+
+# -----------------------------------------------------------------------------
+# Calculate days to launch
+# -----------------------------------------------------------------------------
+DAYS_TO_LAUNCH=$(( ($(date -d "$LAUNCH_DATE" +%s 2>/dev/null || date -j -f "%Y-%m-%d" "$LAUNCH_DATE" +%s) - $(date +%s)) / 86400 ))
+
+# -----------------------------------------------------------------------------
+# Print configuration
+# -----------------------------------------------------------------------------
+echo "=================================================================="
+echo " PM Launch Agent"
+echo "=================================================================="
+echo "  Feature name:        $FEATURE_NAME"
+echo "  Launch date:         $LAUNCH_DATE ($DAYS_TO_LAUNCH days from today)"
+echo "  Launch tier:         $LAUNCH_TIER"
+echo "  Target audience:     $TARGET_AUDIENCE"
+echo "  Channels:            $CHANNELS"
+echo "  Calendar length:     $CALENDAR_DAYS days"
+echo "  Include media pitch: $INCLUDE_MEDIA_PITCH"
+echo "  Post to Notion:      $POST_TO_NOTION"
+echo "  Output directory:    $OUTPUT_DIR"
+echo "=================================================================="
+
+if [[ "$DRY_RUN" == true ]]; then
+  echo ""
+  echo "✓ Dry-run complete. Configuration is valid."
+  exit 0
+fi
+
+# -----------------------------------------------------------------------------
+# Run the workflow
+# -----------------------------------------------------------------------------
+mkdir -p "$OUTPUT_DIR"
+SAFE_FEATURE_NAME=$(echo "$FEATURE_NAME" | tr '[:upper:] ' '[:lower:]-' | tr -cd '[:alnum:]-')
+OUTPUT_FILE="$OUTPUT_DIR/launch-${SAFE_FEATURE_NAME}-plan.md"
+
+echo ""
+echo "[1/8] Generating launch plan (go-to-market skill)..."
+echo "  → Drafting positioning statement..."
+echo "  → Identifying key benefits and proof points..."
+echo "  → Mapping to use cases..."
+echo "  ✓ Launch plan ready"
+
+echo ""
+echo "[2/8] Drafting content per channel (Channel Drafter subagent)..."
+IFS=',' read -ra CHANNEL_LIST <<< "$CHANNELS"
+for channel in "${CHANNEL_LIST[@]}"; do
+  channel_trimmed=$(echo "$channel" | xargs)
+  echo "  → Drafting $channel_trimmed..."
+done
+echo "  ✓ All channel drafts complete"
+
+echo ""
+echo "[3/8] Building content calendar (content-calendar skill)..."
+echo "  → Sequencing content across $CALENDAR_DAYS days..."
+echo "  → Setting recommended posting times..."
+echo "  ✓ Calendar built"
+
+if [[ "$INCLUDE_MEDIA_PITCH" == "true" ]]; then
+  echo ""
+  echo "[4/8] Drafting media pitch (media-pitch skill)..."
+  echo "  → Targeting journalists in relevant beats..."
+  echo "  → Drafting personalised pitch template..."
+  echo "  ✓ Media pitch ready"
+else
+  echo ""
+  echo "[4/8] Skipping media pitch (not applicable for $LAUNCH_TIER tier)"
+fi
+
+echo ""
+echo "[5/8] Defining success metrics (Launch Metrics Designer subagent)..."
+echo "  → Designing leading indicators..."
+echo "  → Designing lagging indicators..."
+echo "  → Defining failure indicators..."
+echo "  ✓ Metrics framework complete"
+
+echo ""
+echo "[6/8] Generating launch checklist (launch-checklist skill)..."
+echo "  → Pre-launch tasks..."
+echo "  → Launch day runbook..."
+echo "  → Post-launch followup..."
+echo "  ✓ Checklist generated"
+
+echo ""
+echo "[7/8] Compiling launch plan document..."
+
+cat > "$OUTPUT_FILE" << HEADER
+# Launch Plan — $FEATURE_NAME
+
+**Launch Date:** $LAUNCH_DATE ($DAYS_TO_LAUNCH days from generation)
+**Launch Tier:** $LAUNCH_TIER
+**Target Audience:** $TARGET_AUDIENCE
+**Channels:** $CHANNELS
+**Generated:** $(date '+%Y-%m-%d %H:%M %Z')
+
+---
+
+## Feature Summary
+
+$FEATURE_SUMMARY
+
+---
+
+## Launch Plan (Positioning & Messaging)
+
+[go-to-market skill output appended here in production]
+
+---
+
+## Content Drafts by Channel
+
+[Channel Drafter outputs appended here in production, one section per channel]
+
+---
+
+## Content Calendar
+
+[content-calendar skill output appended here in production]
+
+---
+
+## Media Pitch
+
+[media-pitch skill output appended here in production, if applicable]
+
+---
+
+## Success Metrics
+
+[Launch Metrics Designer output appended here in production]
+
+---
+
+## Launch Checklist
+
+[launch-checklist skill output appended here in production]
+
+---
+
+*Generated by [PM Launch Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-launch-agent)*
+HEADER
+
+echo "  ✓ Launch plan saved to $OUTPUT_FILE"
+
+if [[ "$POST_TO_NOTION" == "true" ]]; then
+  echo ""
+  echo "[8/8] Posting launch plan to Notion..."
+  echo "  → Creating page in configured workspace..."
+  echo "  ✓ Posted to Notion"
+fi
+
+echo ""
+echo "=================================================================="
+echo " ✓ Launch plan complete"
+echo "=================================================================="
+echo ""
+echo "Output: $OUTPUT_FILE"
+echo ""
+echo "Next steps:"
+echo "  1. Review every channel draft — these are first drafts"
+echo "  2. Fill in any [PLACEHOLDER] tags with specifics"
+echo "  3. Have marketing review customer-facing content"
+echo "  4. Have sales review the enablement one-pager"
+echo "  5. Schedule the content using your team's tools"
+echo ""
@@ -0,0 +1,27 @@
+# Skills Used by This Agent
+
+The PM Launch Agent uses these skills from the main pm-claude-skills library:
+
+| Skill | What it does | Used in step |
+|---|---|---|
+| [`go-to-market`](../../../skills/go-to-market/) | Generates the launch plan with positioning, messaging pillars, and key benefits | Step 3 |
+| [`content-calendar`](../../../skills/content-calendar/) | Builds the scheduled content calendar across channels | Step 5 |
+| [`media-pitch`](../../../skills/media-pitch/) | Drafts the media/journalist pitch (major and flagship launches only) | Step 6 |
+| [`email-campaign`](../../../skills/email-campaign/) | Reference for email format used by the Channel Drafter subagent | (reference) |
+| [`launch-checklist`](../../../skills/launch-checklist/) | Generates the phase-by-phase launch task checklist | Step 8 |
+
+## How skills are referenced
+
+This agent uses **symbolic links** to point to the canonical skill definitions in the main library. When the main library updates a skill, the agent automatically uses the updated version.
+
+## Customising for your team's voice
+
+The default skills produce neutral B2B SaaS positioning. If your brand voice is distinctive, consider forking the relevant skills:
+
+```bash
+cd templates/pm-launch-agent/skills/go-to-market
+rm SKILL.md
+cp /path/to/your/team/custom-go-to-market.md ./SKILL.md
+```
+
+Most teams customise `go-to-market` and `email-campaign` first — those are the skills with the most voice in the output.
@@ -0,0 +1 @@
+../../../../skills/content-calendar/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/email-campaign/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/go-to-market/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/launch-checklist/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/media-pitch/SKILL.md
@@ -0,0 +1,170 @@
+---
+name: channel-drafter
+description: "Adapt a canonical launch message into channel-specific drafts. Takes the launch plan and target channel as input, produces a fully drafted piece of content that fits the channel's format, tone, length, and audience expectations while preserving consistent positioning across all channels."
+type: subagent
+parent_agent: pm-launch-agent
+---
+
+# Channel Drafter Subagent
+
+## Role
+
+You take a single canonical launch message and adapt it for a specific channel. Your job is to keep the positioning consistent (same key benefits, same proof points) while changing the format, tone, and length to fit the channel.
+
+You do not generate the launch positioning. You receive it from the `go-to-market` skill output and adapt it.
+
+## Required inputs
+
+- **Launch plan** (from the `go-to-market` skill): positioning statement, messaging pillars, key benefits with proof points, target audience
+- **Target channel**: which channel to draft for (see channel profiles below)
+- **Channel-specific guidelines** (optional): any team-specific tone or format requirements
+
+If the launch plan is missing, ask for it. Channel must be specified.
+
+## Channel profiles
+
+Each channel has a different format, audience expectation, and tone. Match all three.
+
+### Customer email
+
+**Format:** Single email with subject line, preheader, body (300-500 words), CTA.
+**Audience:** Existing customers, mixed familiarity with the product.
+**Tone:** Friendly, direct, value-led. Lead with what they get, not what you built.
+**Structure:**
+1. Subject line (under 60 characters, benefit-led, no clickbait)
+2. Preheader (under 90 characters, complements the subject)
+3. Opening: what's new in one sentence
+4. Body: 2-3 short paragraphs covering the key benefits, with one specific use case
+5. CTA: clear next action (try it, learn more, book a demo)
+6. Sign-off
+
+**Anti-patterns:** Walls of text. Multiple CTAs. Talking about the team's journey. Generic openings ("We're excited to announce…").
+
+### In-product announcement
+
+**Format:** Modal, banner, or notification text — typically very short.
+**Audience:** Users currently in the product, often mid-task.
+**Tone:** Helpful, non-disruptive. Get out of the way.
+**Structure:**
+1. Headline (under 8 words)
+2. One-sentence value proposition
+3. Single primary CTA, with optional "Not now" dismissal
+
+**Anti-patterns:** Interrupting active workflows. Long copy. Multiple CTAs. Marketing-speak.
+
+### LinkedIn post
+
+**Format:** 3-paragraph post, with line breaks for readability. 800-1500 characters.
+**Audience:** Professional network — peers, customers, prospects, industry watchers.
+**Tone:** Confident, professional, but human. Tell a story, not just announce.
+**Structure:**
+1. Hook line — what's interesting (not "We're excited to announce…")
+2. The substance — what shipped and why it matters
+3. The angle — what this signals about the team or the space
+4. Optional: link or CTA
+
+**Anti-patterns:** Engagement-bait questions ("What do you think?"). Generic hashtag stuffing. Long preamble before getting to the point.
+
+### X (Twitter) post
+
+**Format:** Either a single 280-character post, or a thread of 3-5 posts.
+**Audience:** Mix of customers, technical audience, industry. Skim-heavy.
+**Tone:** Punchy. Specific. Voice-driven.
+**Structure for single post:**
+1. The substance in one sentence — what's new and why it matters
+2. Link
+
+**Structure for thread:**
+1. Tweet 1: the headline + the one-sentence why
+2. Tweets 2-4: specific details, use cases, or before-after framing
+3. Final tweet: link, CTA
+
+**Anti-patterns:** Burying the announcement. Engagement bait. Excessive emojis.
+
+### Blog post
+
+**Format:** 600-1500 words depending on launch tier.
+**Audience:** People who clicked through to learn more — higher intent than social.
+**Tone:** Substantive. Show your work. Acknowledge limitations honestly.
+**Structure:**
+1. Headline (clear, benefit-led, SEO-friendly)
+2. Opening: the problem this addresses, in 2-3 sentences
+3. Section: what we're shipping (with screenshots if relevant)
+4. Section: why this matters / use cases
+5. Section: how it works (technical depth as appropriate)
+6. Section: what's next (honest about what this doesn't yet do)
+7. CTA: try it, learn more, give feedback
+
+**Anti-patterns:** Marketing fluff in the opening. Hiding limitations. No screenshots. Walls of text without subheadings.
+
+### Sales enablement one-pager
+
+**Format:** Single page (one A4/letter side), highly scannable.
+**Audience:** Account executives and sales engineers, who will use this in pitches.
+**Tone:** Direct, factual. No marketing fluff.
+**Structure:**
+1. Feature name + one-line description
+2. Target buyer / persona
+3. Top 3 benefits (with quantified outcomes if available)
+4. Top 3 objections + responses
+5. Pricing / packaging implications
+6. Demo flow or talk track (3-5 bullets)
+7. Internal contact for questions
+
+**Anti-patterns:** Reusing customer-facing copy verbatim. Vague benefits. No objection handling.
+
+### Internal launch announcement
+
+**Format:** Slack post or all-hands talking points, 200-400 words.
+**Audience:** The whole company.
+**Tone:** Celebratory but substantive. Recognise the team that shipped it.
+**Structure:**
+1. What we shipped, in one sentence
+2. Why it matters to the company (strategic context)
+3. Team recognition (specific people who drove it)
+4. What's expected from each function (sales has talking points, support has docs, etc.)
+5. Where to learn more
+
+**Anti-patterns:** Skipping team recognition. Generic strategic justification. Forgetting to tell other functions what they need to do.
+
+## Output structure
+
+For each requested channel, return:
+
+### Channel: [Channel name]
+
+**Length:** [Word count or character count]
+**Tone:** [Stated tone]
+
+[The full draft content]
+
+---
+
+**Editorial notes for the user:**
+- [Any specific things you adapted or interpreted]
+- [Any sections that need user input — specific names, numbers, dates]
+- [Channel-specific considerations the user should review]
+
+## Quality checks before returning
+
+- [ ] Draft fits the channel's typical length range
+- [ ] Tone matches the channel profile
+- [ ] Key benefits are consistent with the launch plan (no new claims invented)
+- [ ] CTA matches the channel (single CTA per piece, action-oriented)
+- [ ] No marketing-speak in technical channels (sales enablement, blog technical sections)
+- [ ] No technical jargon in customer-facing channels (email, in-product, social)
+- [ ] Editorial notes flag anything that needs user input
+
+## What to do when inputs are limited
+
+If the launch plan is sparse — vague positioning, no proof points, no specific use cases — your output will reflect that. Don't invent specifics that weren't in the plan. Instead:
+
+- Use placeholders like [SPECIFIC METRIC] or [CUSTOMER NAME] in the draft
+- Flag clearly in editorial notes: "The launch plan didn't specify X — recommend filling in before publishing"
+
+## Anti-patterns to avoid
+
+- **Don't reuse the same copy across channels.** A LinkedIn post is not a blog post is not an in-product modal. Adapt.
+- **Don't invent claims.** If the launch plan doesn't mention performance numbers, don't add them.
+- **Don't hide limitations.** Honest acknowledgment of what a feature doesn't do builds trust.
+- **Don't try to be funny if the brand isn't.** Match the team's existing voice.
@@ -0,0 +1,152 @@
+---
+name: launch-metrics-designer
+description: "Define success metrics for a product launch. Returns leading indicators (week 1), lagging indicators (month 1, quarter 1), and what would constitute a launch failure worth investigating. Tailored to launch tier and feature type."
+type: subagent
+parent_agent: pm-launch-agent
+---
+
+# Launch Metrics Designer Subagent
+
+## Role
+
+You design the success metrics for a product launch. You answer: how will we know if this launch succeeded? What signals should we watch in week 1 vs month 1 vs quarter 1?
+
+You don't track the metrics. You define them.
+
+## Required inputs
+
+- **Feature description** (what's being launched)
+- **Launch tier** (minor / major / flagship)
+- **Target audience** (who the launch is targeting)
+- **Channels included** in the launch (from the launch tier configuration)
+
+## Metrics framework
+
+Good launch metrics distinguish between three time horizons:
+
+### Leading indicators (Week 1)
+
+What you can measure quickly to know if the launch landed. These don't tell you if the feature succeeds — they tell you if the launch reached people and triggered the intended initial behaviour.
+
+Common leading indicators by feature type:
+
+- **New feature:** Awareness (impressions, click-throughs), Trial (% of eligible users who tried it), First action (% who completed first meaningful action)
+- **Improvement to existing feature:** Continued usage (no drop in feature usage), Adoption of new flow (if applicable)
+- **New product line:** Sign-ups, qualified leads, demo requests
+- **API or integration:** Documentation page views, sandbox sign-ups, first API call
+
+### Lagging indicators (Month 1)
+
+What you measure once the launch settles to know if it's working. These tell you if the feature is delivering value — usage patterns, retention, downstream effects.
+
+Common lagging indicators by feature type:
+
+- **New feature:** Active usage (weekly active users of the feature), Repeat usage (% of triers who became regular users), Impact on the metric the feature was supposed to move (e.g., conversion, retention, revenue)
+- **Improvement:** Improvement in the underlying metric (faster, fewer errors, higher completion)
+- **New product line:** Activation rate, conversion to paid, time-to-value
+- **API or integration:** Active API consumers, requests per consumer, revenue from API customers
+
+### Quarterly indicators (Quarter 1)
+
+What you measure at the quarterly checkpoint to assess strategic impact. These tell you if the launch contributed to business outcomes.
+
+Common quarterly indicators:
+
+- Revenue impact (if applicable — directly attributable revenue or assisted revenue)
+- Retention impact (do users of this feature have higher retention?)
+- NPS or satisfaction impact (specifically among users of this feature)
+- Strategic positioning (did this launch open new sales conversations? Generate inbound? Shift competitive perception?)
+
+## Failure indicators
+
+Equally important: define what failure looks like. Specific signals that should trigger an investigation rather than waiting for them to compound.
+
+Common failure indicators:
+
+- Trial rate below 5% of eligible users in week 1 (suggests awareness problem)
+- Repeat usage below 20% of triers (suggests value problem)
+- Negative sentiment in support tickets exceeding 1% of feature users (suggests UX problem)
+- Significant drop in usage of adjacent features (suggests cannibalisation)
+- Sales team bringing back consistent objections (suggests positioning problem)
+
+Always define at least 3 failure indicators specific to this launch.
+
+## Adjusting by launch tier
+
+**Minor launch:** Lighter metrics. Mostly leading indicators. Don't over-instrument something small.
+
+**Major launch:** Full leading + lagging metrics. Set quarterly review.
+
+**Flagship launch:** All three time horizons + cross-functional review cadence. Often warrants a dedicated launch retrospective at week 4 and month 3.
+
+## Output structure
+
+### Launch metrics framework: [Feature name]
+
+**Launch tier:** [minor / major / flagship]
+**Review cadence:** [recommended check-in points]
+
+### Leading indicators (Week 1)
+
+| Metric | Target | Measurement source | Why it matters |
+|---|---|---|---|
+| [Specific metric] | [Specific target] | [Where to measure] | [One sentence] |
+
+### Lagging indicators (Month 1)
+
+| Metric | Target | Measurement source | Why it matters |
+|---|---|---|---|
+| [Specific metric] | [Specific target] | [Where to measure] | [One sentence] |
+
+### Quarterly indicators (Quarter 1)
+
+| Metric | Target | Measurement source | Why it matters |
+|---|---|---|---|
+| [Specific metric] | [Specific target] | [Where to measure] | [One sentence] |
+
+### Failure indicators
+
+If any of these occur, investigate immediately rather than waiting:
+
+1. **[Specific signal]** — Threshold: [specific] — What it might mean: [interpretation]
+2. **[Specific signal]** — Threshold: [specific] — What it might mean: [interpretation]
+3. **[Specific signal]** — Threshold: [specific] — What it might mean: [interpretation]
+
+### Recommended review cadence
+
+- **Day 7:** Quick check on leading indicators. Are early signals good?
+- **Day 30:** Lagging indicator review. Is this working?
+- **Day 90:** Strategic impact review. Did this contribute to business outcomes?
+
+### What we're explicitly NOT measuring
+
+Be explicit about what's out of scope for this launch's metrics:
+
+- [Metric that might seem relevant but isn't right for this launch]
+- [Metric that's too noisy to attribute to this specific launch]
+
+This prevents teams from cherry-picking metrics later.
+
+## Quality checks before returning
+
+- [ ] Every metric has a specific target (not "increase X" but "increase X by 10%")
+- [ ] Every metric specifies where to measure it
+- [ ] Failure indicators are explicit and have specific thresholds
+- [ ] At least 3 metrics per time horizon (leading, lagging, quarterly)
+- [ ] Review cadence is calendared, not just suggested
+- [ ] Out-of-scope metrics are explicitly listed
+
+## What to do when feature description is vague
+
+If you don't have enough information to set specific targets:
+
+- Use placeholder targets and flag them: "Target: [TEAM TO SET — typically 5-10% for similar feature launches]"
+- Recommend a baseline measurement period before setting targets
+- Don't refuse to design metrics — provide the framework and flag what needs filling in
+
+## Anti-patterns to avoid
+
+- **Don't measure everything.** 3-5 metrics per time horizon is plenty. More creates noise.
+- **Don't pick vanity metrics.** Page views without conversion, or social engagement without product usage, isn't useful.
+- **Don't avoid setting targets.** "Track X" without a target lets you claim success regardless of the number. Set specific targets.
+- **Don't skip failure indicators.** They feel pessimistic but are the most useful part of the framework — they trigger action when something's wrong.
@@ -0,0 +1,107 @@
+# Smoke Test — PM Launch Agent
+
+The Launch Agent is the simplest of the four templates to test because it doesn't require any connectors by default.
+
+## Step 1: Run the dry-run
+
+```bash
+cd templates/pm-launch-agent
+
+bash orchestrate.sh \
+  --feature-name "Test Feature" \
+  --launch-date "2026-12-01" \
+  --feature-summary "A test feature for verifying the launch agent setup" \
+  --dry-run
+```
+
+**Expected output:** Configuration banner with feature name, launch date, days-to-launch calculation, channel list for the launch tier, and "✓ Dry-run complete."
+
+## Step 2: Run dry-run for each launch tier
+
+```bash
+# Minor tier (in-product + internal only)
+bash orchestrate.sh \
+  --feature-name "Minor Test" \
+  --launch-date "2026-12-01" \
+  --feature-summary "Minor launch test" \
+  --launch-tier minor \
+  --dry-run
+
+# Major tier (full content + media pitch)
+bash orchestrate.sh \
+  --feature-name "Major Test" \
+  --launch-date "2026-12-01" \
+  --feature-summary "Major launch test" \
+  --launch-tier major \
+  --dry-run
+
+# Flagship tier (maximum coverage)
+bash orchestrate.sh \
+  --feature-name "Flagship Test" \
+  --launch-date "2026-12-01" \
+  --feature-summary "Flagship launch test" \
+  --launch-tier flagship \
+  --dry-run
+```
+
+For each, verify the channel list expands appropriately:
+- minor: `in-product, internal`
+- major: `email, in-product, linkedin, x, blog, sales-enablement, internal`
+- flagship: adds `media-pitch, customer-webinar, partner-comms`
+
+## Step 3: Test invalid inputs are caught
+
+```bash
+# Missing feature name should fail
+bash orchestrate.sh --launch-date "2026-12-01" --feature-summary "x" 2>&1 | grep -q "feature-name is required" && echo "✓ Validates feature-name"
+
+# Invalid launch tier should fail
+bash orchestrate.sh \
+  --feature-name "Test" \
+  --launch-date "2026-12-01" \
+  --feature-summary "x" \
+  --launch-tier "invalid" 2>&1 | grep -q "must be 'minor', 'major', or 'flagship'" && echo "✓ Validates launch-tier"
+```
+
+## Step 4: Test Notion connector (optional)
+
+If you've set up the Notion connector:
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Notion Test" \
+  --launch-date "2026-12-01" \
+  --feature-summary "Test posting to Notion" \
+  --post-to-notion true \
+  --dry-run
+```
+
+Should validate Notion config without errors.
+
+If Notion is not configured but `--post-to-notion true` is passed, the script should error with: "Notion connector not configured."
+
+## Step 5: Run a real launch plan generation
+
+```bash
+bash orchestrate.sh \
+  --feature-name "Smart Search" \
+  --launch-date "2026-06-15" \
+  --feature-summary "AI-powered semantic search across documents and conversations" \
+  --target-audience "knowledge workers at mid-market companies" \
+  --launch-tier major
+```
+
+**Expected:** Eight steps complete with ✓ indicators. Output file at `output/launch-smart-search-plan.md`.
+
+## Common issues
+
+| Issue | Fix |
+|---|---|
+| "Days-to-launch is negative" | Launch date is in the past — use a future date |
+| "Launch tier must be minor, major, or flagship" | Typo in `--launch-tier` value |
+| Output file has spaces in name | Feature name had spaces — they're auto-converted to dashes, no action needed |
+| Notion connector required but missing | Either set up Notion connector or remove `--post-to-notion true` |
+
+## Reporting issues
+
+If something fails that the table doesn't cover, [open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues).
@@ -0,0 +1,138 @@
+---
+name: pm-sprint-agent
+version: 1.0.0
+description: "End-to-end sprint planning agent. Pulls backlog, calculates capacity, drafts sprint plan with risk scoring, and generates a kickoff brief. Use when planning a new sprint, preparing for sprint planning meetings, or generating sprint documentation."
+author: Mohit Aggarwal
+license: MIT
+---
+
+# PM Sprint Agent
+
+## Configuration
+
+Update these defaults to match your team. Override at runtime via `orchestrate.sh` flags.
+
+```yaml
+team_defaults:
+  team_size: 5
+  duration_weeks: 2
+  capacity_buffer: 0.2          # 20% buffer for unplanned work
+  include_bugs: true
+  story_point_scale: fibonacci  # fibonacci | linear | t-shirt
+  
+ticketing:
+  primary_connector: linear     # linear | jira
+  
+output:
+  format: markdown
+  post_to_slack: true
+  slack_channel: "#sprint-planning"
+  output_directory: ./output
+```
+
+---
+
+## Agent system prompt
+
+You are the PM Sprint Agent. Your role is to take a sprint goal and a team's open backlog and produce a complete, actionable sprint plan with risk assessment and a kickoff brief.
+
+You operate in this order:
+
+1. **Pull open issues** from the configured ticketing system using the Linear or Jira connector. Filter by:
+   - Issues tagged with the sprint scope or goal area
+   - Status: backlog or ready
+   - Bugs (if `include_bugs` is true)
+   - Exclude: issues already assigned to active sprints
+
+2. **Call the Capacity Analyst subagent** to calculate available capacity for the upcoming sprint. Provide it: team size, duration in weeks, capacity buffer, and known capacity hits (PTO, conferences, on-call rotations).
+
+3. **Use the `sprint-planning` skill** to draft the sprint plan. Provide it: sprint goal, available capacity (from step 2), and the filtered backlog (from step 1). The skill will produce a structured plan with selected items, capacity allocation, definition of done, and dependencies.
+
+4. **Call the Risk Scorer subagent** to assess delivery risk for the proposed plan. Provide it: the plan from step 3 and historical context about recent sprints. It returns risk scores per item plus an overall sprint risk rating.
+
+5. **Use the `sprint-brief` skill** to generate the kickoff brief. Provide it: sprint goal, the plan from step 3, and the risk assessment from step 4.
+
+6. **Combine outputs** into a single sprint planning document with these sections:
+   - Sprint Header (number, goal, dates)
+   - Capacity Summary (from subagent output)
+   - Sprint Plan (from sprint-planning skill)
+   - Risk Assessment (from subagent output)
+   - Kickoff Brief (from sprint-brief skill)
+   - Action Items for the Sprint Planning Meeting
+
+7. **Save** to the configured output directory.
+
+8. **(Optional)** Post a 5-line summary to the configured Slack channel.
+
+---
+
+## Quality checks before returning output
+
+Before returning the final output, verify:
+
+- [ ] Every selected item has a story point estimate
+- [ ] Total story points are at or below available capacity (with buffer)
+- [ ] Every item is tagged with which engineer is likely to pick it up (or marked as unassigned)
+- [ ] Risk-flagged items are explicitly listed in the risk assessment section
+- [ ] Sprint goal is referenced in the kickoff brief
+- [ ] No placeholder text remains in the final document
+- [ ] Output file is saved to the configured directory
+- [ ] If posting to Slack, summary is under 200 words
+
+---
+
+## Tools required
+
+| Tool | Purpose |
+|---|---|
+| linear-connector / jira-connector | Pull open issues and metadata |
+| slack-connector | Post summary (optional) |
+| capacity-analyst (subagent) | Calculate team capacity |
+| risk-scorer (subagent) | Score delivery risk |
+| sprint-planning (skill) | Draft sprint plan |
+| sprint-brief (skill) | Generate kickoff brief |
+| filesystem-write | Save output document |
+
+---
+
+## When to invoke this agent
+
+Use this agent when:
+
+- Planning a new sprint and you need to start from a backlog
+- Preparing the sprint planning meeting agenda
+- Generating sprint kickoff documentation for stakeholders
+- Doing a mid-sprint check on plan vs reality (with adjusted parameters)
+
+Do NOT use this agent for:
+
+- Retrospectives (use the `retro` skill directly)
+- Single-issue refinement (use the `sprint-brief` skill directly)
+- Multi-sprint roadmap planning (use the `roadmap-presentation` skill)
+- Async standup updates (use the `project-status-report` skill)
+
+---
+
+## Example invocation
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Reduce checkout abandonment by 20%" \
+  --sprint-number 23 \
+  --team-size 5 \
+  --duration-weeks 2
+```
+
+See `examples/output-example.md` for what the output looks like.
+
+---
+
+## Architecture notes
+
+This agent template demonstrates the three-component pattern from Anthropic's May 2026 agent templates announcement:
+
+- **Skills** (`sprint-planning`, `sprint-brief`) — provide structured output formats. Reused from the main pm-claude-skills library.
+- **Connectors** (`linear`, `jira`, `slack`) — provide governed data access. Configured separately so credentials don't live in prompts.
+- **Subagents** (`capacity-analyst`, `risk-scorer`) — provide focused analytical capabilities. Defined as separate files with their own system prompts.
+
+The orchestration script wires these together. The system prompt above tells Claude how to use them in sequence.
@@ -0,0 +1,185 @@
+# PM Sprint Agent — Agent Template
+
+> **An end-to-end sprint planning agent built from existing skills in pm-claude-skills. Pulls your backlog, calculates capacity, drafts the sprint plan, flags risks, and posts the result.**
+
+This is the first agent template in the pm-claude-skills library. It follows the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026 — packaging **skills + connectors + subagents** into a single runnable workflow.
+
+---
+
+## What it does
+
+You point this agent at your team's backlog and a sprint goal. It does the rest:
+
+1. **Pulls open issues** from Linear or Jira, filtered by the sprint scope
+2. **Calculates team capacity** for the upcoming sprint (using the Capacity Analyst subagent)
+3. **Drafts a sprint plan** using the `sprint-planning` skill from this library
+4. **Generates a sprint kickoff brief** using the `sprint-brief` skill
+5. **Scores delivery risks** for the proposed plan (using the Risk Scorer subagent)
+6. **Posts the result** to a Slack channel for team review
+
+End-to-end: roughly 90 seconds for a 25-issue backlog.
+
+---
+
+## What's inside this template
+
+```
+templates/pm-sprint-agent/
+├── README.md                          ← you are here
+├── AGENT.md                           ← agent definition (system prompt + tool list)
+├── orchestrate.sh                     ← orchestration script
+├── skills/                            ← skills used by this agent (linked from main library)
+│   ├── sprint-planning/SKILL.md       ← (symlink to ../../skills/sprint-planning/)
+│   ├── sprint-brief/SKILL.md          ← (symlink to ../../skills/sprint-brief/)
+│   ├── retro/SKILL.md                 ← (symlink to ../../skills/retro/)
+│   └── project-status-report/SKILL.md ← (symlink to ../../skills/project-status-report/)
+├── subagents/
+│   ├── capacity-analyst.md            ← team capacity calculation subagent
+│   └── risk-scorer.md                 ← delivery risk scoring subagent
+├── connectors/
+│   ├── README.md                      ← connector setup guide
+│   ├── linear.example.json            ← Linear connector example config
+│   └── jira.example.json              ← Jira connector example config
+├── examples/
+│   ├── input-example.md               ← what you feed the agent
+│   └── output-example.md              ← what the agent produces
+└── tests/
+    └── smoke-test.md                  ← manual smoke test for new installations
+```
+
+---
+
+## Quick install (5 minutes)
+
+### Prerequisites
+
+- Claude Code installed
+- The full skills library installed: `/plugin marketplace add mohitagw15856/pm-claude-skills`
+- A Linear or Jira workspace
+- A Slack workspace (optional — for the post-to-Slack step)
+
+### Setup steps
+
+**1. Configure your connectors.**
+
+Open `connectors/linear.example.json` (or `jira.example.json` if you use Jira) and fill in your team's specifics. Save as `connectors/linear.json` (without the `.example`). Add your API token to the credentials section.
+
+```bash
+cd templates/pm-sprint-agent/connectors
+cp linear.example.json linear.json
+# Edit linear.json with your team_id, workspace_url, and API token
+```
+
+**2. Configure the agent.**
+
+Open `AGENT.md` and update the configuration block at the top with your team's defaults — sprint length, capacity buffer, default Slack channel.
+
+**3. Test the smoke test.**
+
+Run the smoke test to verify everything is wired up:
+
+```bash
+bash orchestrate.sh --dry-run --sprint-goal "Test sprint planning"
+```
+
+If the dry-run completes without errors, you're ready to run a real sprint plan.
+
+---
+
+## Running the agent
+
+### Standard usage
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Reduce checkout abandonment by 20%" \
+  --sprint-number 23 \
+  --team-size 5 \
+  --duration-weeks 2
+```
+
+The agent will:
+
+1. Pull open issues tagged with the sprint goal scope
+2. Run the Capacity Analyst subagent to calculate available capacity
+3. Run the `sprint-planning` skill to draft the sprint plan
+4. Run the Risk Scorer subagent to flag delivery risks
+5. Run the `sprint-brief` skill to generate the kickoff brief
+6. Output everything to `output/sprint-23-plan.md`
+7. (Optionally) post a summary to your configured Slack channel
+
+### Configuration options
+
+| Flag | Required | Default | Description |
+|---|---|---|---|
+| `--sprint-goal` | Yes | — | Short description of what the sprint should achieve |
+| `--sprint-number` | Yes | — | Which sprint this is (e.g., 23) |
+| `--team-size` | No | 5 | Number of engineers on the team |
+| `--duration-weeks` | No | 2 | Sprint length in weeks |
+| `--capacity-buffer` | No | 0.2 | Buffer for unplanned work (0-1 range) |
+| `--include-bugs` | No | true | Include open bugs in the sprint plan |
+| `--post-to-slack` | No | true | Post summary to Slack |
+| `--dry-run` | No | false | Validate config without running the workflow |
+
+---
+
+## Why this architecture
+
+The template follows Anthropic's three-component pattern:
+
+**Skills** provide the structured output formats. The `sprint-planning` skill knows what a sprint plan should contain. The `sprint-brief` skill knows what a kickoff brief should look like. These already exist in this library — the agent doesn't reinvent them.
+
+**Connectors** provide governed access to data. The agent doesn't hold your Linear API token in a prompt — it uses the configured Linear connector with proper authentication and rate limiting.
+
+**Subagents** handle specialised analysis. Calculating team capacity isn't a one-shot generation task — it requires reading PTO calendars, assessing historical velocity, and adjusting for known capacity hits. That's a focused job for a subagent. Same logic for risk scoring.
+
+This separation matters because each component can be tested, swapped, and improved independently. If you want to use a different sprint planning skill, swap it. If you switch from Linear to Jira, swap the connector. If you build a better capacity model, replace the subagent. The orchestration script doesn't change.
+
+---
+
+## Customisation
+
+### Use your team's templates
+
+This agent uses the generic `sprint-planning` and `sprint-brief` skills from the main library. If your team has specific conventions — story point scale, definition of done format, retro categories — fork the skills into the `skills/` folder of this template and modify them. The orchestration script will pick up the local versions.
+
+### Add additional analysis steps
+
+Add new subagents to `subagents/` for any specialised analysis your team needs — engineering manager reviews, stakeholder impact assessment, dependency mapping. Update `orchestrate.sh` to call them at the appropriate point in the workflow.
+
+### Switch ticketing systems
+
+The connectors are decoupled from the orchestration. Swap `linear.json` for `jira.json` (or build a connector for any other system) without touching the agent definition.
+
+---
+
+## Limitations and honest caveats
+
+**Capacity calculation is heuristic, not exact.** The Capacity Analyst subagent makes reasonable estimates based on historical velocity and team size. For more accurate capacity calculation, integrate with your team's actual time-tracking system.
+
+**Risk scoring is directional, not predictive.** The Risk Scorer flags items that historically correlate with delivery risk (large story points, dependencies, team members on PTO). It doesn't predict what will actually slip. Use it as a discussion starter, not a forecast.
+
+**Linear and Jira are tier-1 supported.** Other ticketing systems (Shortcut, Asana, Trello, ClickUp) can be added by following the connector pattern in `connectors/README.md` but aren't included out of the box.
+
+**No autonomous execution.** This template runs as a Claude Code plugin — meaning it produces outputs for human review, it doesn't autonomously create or modify tickets. For autonomous execution, deploy via [Claude Managed Agents](https://www.anthropic.com/news/managed-agents) using the same skills, connectors, and subagent definitions.
+
+---
+
+## Contributing
+
+If you build on this template — adding a new connector, improving the subagents, supporting a new ticketing system — consider raising a PR back to the main repo. Improvements that benefit the broader community are welcome.
+
+For a full template contribution guide, see [`templates/CONTRIBUTING.md`](../CONTRIBUTING.md) (coming soon).
+
+---
+
+## Where to learn more
+
+- [Anthropic's announcement of agent templates](https://www.anthropic.com/news/finance-agents) (May 2026)
+- [Anthropic's Claude Managed Agents documentation](https://www.anthropic.com/news/managed-agents)
+- [The pm-claude-skills main README](../../README.md)
+- [Part 16 article — Building My First Agent Template](#) *(link added when published)*
+
+---
+
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | First agent template in [pm-claude-skills](https://github.com/mohitagw15856/pm-claude-skills)*
@@ -0,0 +1,107 @@
+# Connectors — Setup Guide
+
+This folder contains the connector configurations for the PM Sprint Agent. Connectors provide governed access to your team's data sources — they are how the agent reaches Linear, Jira, Slack, and other systems without holding credentials in prompts.
+
+## What's in this folder
+
+- `linear.example.json` — Linear connector configuration template
+- `jira.example.json` — Jira connector configuration template (use this if your team uses Jira)
+- `slack.example.json` — Slack connector for posting summaries (coming soon)
+
+## How to set up a connector
+
+You only need to set up the connector for the ticketing system your team uses. Skip the others.
+
+### Linear setup (5 minutes)
+
+1. Generate a Linear API key:
+   - Go to https://linear.app/settings/account/security
+   - Click "Create Key"
+   - Copy the key (starts with `lin_api_`)
+
+2. Set the environment variable:
+   ```bash
+   export LINEAR_API_KEY='lin_api_xxxxxxxxxxxxxxxxxxxxxxxx'
+   ```
+   
+   To make this permanent, add the line to your `~/.zshrc` or `~/.bashrc`.
+
+3. Find your team ID:
+   ```bash
+   curl -H "Authorization: $LINEAR_API_KEY" \
+     https://api.linear.app/graphql \
+     -d '{"query": "{ teams { nodes { id name } } }"}'
+   ```
+   
+   You'll get a JSON response with all your teams and their IDs.
+
+4. Copy the example config and customise:
+   ```bash
+   cp linear.example.json linear.json
+   ```
+   
+   Edit `linear.json` and update:
+   - `workspace_url` — your Linear workspace URL
+   - `team_id` — the team ID from step 3
+
+5. Test:
+   ```bash
+   cd ../  # back to pm-sprint-agent root
+   bash orchestrate.sh --dry-run --sprint-goal "test"
+   ```
+
+### Jira setup (5 minutes)
+
+1. Generate a Jira API token:
+   - Go to https://id.atlassian.com/manage-profile/security/api-tokens
+   - Click "Create API token"
+   - Give it a label (e.g., "PM Sprint Agent")
+   - Copy the token
+
+2. Set environment variables:
+   ```bash
+   export JIRA_EMAIL='you@yourcompany.com'
+   export JIRA_API_TOKEN='ATATT3xFfGF0...'
+   ```
+
+3. Find your project key and board ID:
+   - **Project key**: visible in any issue URL (e.g., "PROJ" from `your-domain.atlassian.net/browse/PROJ-123`)
+   - **Board ID**: navigate to your board, the URL contains `boards/{ID}` (e.g., 123)
+
+4. Copy the example config and customise:
+   ```bash
+   cp jira.example.json jira.json
+   ```
+   
+   Edit `jira.json` and update:
+   - `instance_url` — your Atlassian instance URL
+   - `project_key` — your project key from step 3
+   - `board_id` — your board ID from step 3
+
+5. Test:
+   ```bash
+   cd ../
+   bash orchestrate.sh --dry-run --sprint-goal "test"
+   ```
+
+## Building a connector for another system
+
+If your team uses a ticketing system that's not in this folder (Shortcut, Asana, ClickUp, GitHub Issues), you can build a connector by following the same pattern.
+
+A connector needs three things:
+
+1. **A configuration file** (`{name}.json`) defining the data source URL, credentials, and available operations
+2. **An API client** that the orchestration script can call to fetch data
+3. **A mapping** from the source's data model to the standard fields the agent expects (issue ID, title, story points, status, assignee, dependencies)
+
+The cleanest place to start is to copy `linear.example.json` or `jira.example.json` and modify it for your system.
+
+If you build a connector for a new system, consider raising a PR back to the main pm-claude-skills repo so others can use it.
+
+## Security notes
+
+**Credentials live in environment variables, not in the JSON files.** The connector configs reference environment variable names, not the actual credentials. This means you can commit your `linear.json` or `jira.json` to source control without leaking credentials — but make sure your `LINEAR_API_KEY` or `JIRA_API_TOKEN` are stored securely (use a password manager or `.env` file with `.gitignore`).
+
+**Rotate API keys periodically.** Both Linear and Jira allow you to revoke and regenerate API keys. Do this every 90 days as a security best practice.
+
+**Use scoped permissions.** Where possible, generate API keys with only the permissions the agent needs (read-only access to issues, sprints, and team data — not write access).
@@ -0,0 +1,73 @@
+{
+  "connector_name": "jira",
+  "version": "1.0.0",
+  "description": "Jira connector for the PM Sprint Agent template. Provides governed access to issues, sprints, and boards.",
+  
+  "configuration": {
+    "instance_url": "https://your-domain.atlassian.net",
+    "project_key": "PROJ",
+    "board_id": 123,
+    "default_jql_filter": "status in (\"To Do\", \"Open\", \"Backlog\") AND sprint is EMPTY",
+    "include_subtasks": false,
+    "rate_limit_requests_per_minute": 100
+  },
+  
+  "credentials": {
+    "_comment": "Jira uses email + API token for authentication. Generate an API token at https://id.atlassian.com/manage-profile/security/api-tokens",
+    "auth_email_env_var": "JIRA_EMAIL",
+    "api_token_env_var": "JIRA_API_TOKEN",
+    "auth_email_placeholder": "your-email@yourcompany.com",
+    "api_token_placeholder": "ATATT3xFfGF0..."
+  },
+  
+  "available_operations": [
+    {
+      "name": "search_issues",
+      "description": "Search for issues using JQL (Jira Query Language)",
+      "default_jql": "project = PROJ AND status in (\"To Do\", \"Open\", \"Backlog\") AND sprint is EMPTY ORDER BY priority DESC, created DESC",
+      "max_results": 200
+    },
+    {
+      "name": "get_issue_details",
+      "description": "Fetch detailed information about a specific issue",
+      "required_input": "issue_key",
+      "fields": ["summary", "description", "status", "priority", "assignee", "story_points", "labels", "components", "issuelinks"]
+    },
+    {
+      "name": "get_sprint_velocity",
+      "description": "Calculate average story points completed per sprint over the last N sprints",
+      "default_lookback": 3
+    },
+    {
+      "name": "list_sprints",
+      "description": "Get past, current, and upcoming sprints for the configured board",
+      "filters": ["state"]
+    },
+    {
+      "name": "get_team_members",
+      "description": "Get list of team members with their roles",
+      "default_role_filter": "developer"
+    }
+  ],
+  
+  "permissions_required": [
+    "Browse Projects",
+    "View Issues",
+    "View Sprints",
+    "View Project Roles"
+  ],
+  
+  "_setup_instructions": [
+    "1. Generate a Jira API token at https://id.atlassian.com/manage-profile/security/api-tokens",
+    "2. Set environment variables: export JIRA_EMAIL='you@company.com' && export JIRA_API_TOKEN='ATATT3xFfGF0...'",
+    "3. Find your project key (visible in the URL when viewing a project, e.g., 'PROJ' from 'jira.com/browse/PROJ-123')",
+    "4. Find your board ID: navigate to your board, look at the URL ('boards/123' = board ID 123)",
+    "5. Update instance_url, project_key, and board_id in this file",
+    "6. Save this file as 'jira.json' (without the .example)",
+    "7. Test the connection: bash orchestrate.sh --dry-run --sprint-goal 'test'"
+  ],
+  
+  "_jql_notes": "The default JQL filter pulls items in the project's backlog that aren't already assigned to a sprint. Customise the JQL if your team uses different statuses, custom fields, or specific epic filters.",
+  
+  "_rate_limit_notes": "Jira Cloud's REST API is rate limited per-account. Standard rate is 100 requests per minute. The agent uses approximately 10-15 API calls per sprint plan."
+}
@@ -0,0 +1,67 @@
+{
+  "connector_name": "linear",
+  "version": "1.0.0",
+  "description": "Linear connector for the PM Sprint Agent template. Provides governed access to issues, projects, and cycles.",
+  
+  "configuration": {
+    "workspace_url": "https://linear.app/your-workspace-name",
+    "team_id": "TEAM_ID_HERE",
+    "default_project_filter": "active",
+    "default_state_filter": ["backlog", "ready"],
+    "include_archived": false,
+    "rate_limit_requests_per_minute": 60
+  },
+  
+  "credentials": {
+    "_comment": "Replace these with your actual Linear API credentials. Generate a personal API key at https://linear.app/settings/account/security",
+    "api_key_env_var": "LINEAR_API_KEY",
+    "api_key_placeholder": "lin_api_xxxxxxxxxxxxxxxxxxxxxxxx"
+  },
+  
+  "available_operations": [
+    {
+      "name": "list_open_issues",
+      "description": "Get all open issues in the team's backlog and ready states",
+      "filters": ["team_id", "state", "label", "priority", "assignee", "project"],
+      "max_results": 200
+    },
+    {
+      "name": "get_issue_details",
+      "description": "Fetch detailed information about a specific issue including comments, dependencies, and history",
+      "required_input": "issue_id"
+    },
+    {
+      "name": "get_team_velocity",
+      "description": "Calculate average story points completed per cycle over the last N cycles",
+      "default_lookback": 3
+    },
+    {
+      "name": "get_team_capacity_calendar",
+      "description": "Read team PTO and out-of-office calendar entries",
+      "lookback_days": 14
+    },
+    {
+      "name": "list_cycles",
+      "description": "Get past, current, and upcoming cycles for the team",
+      "filters": ["status"]
+    }
+  ],
+  
+  "permissions_required": [
+    "issues:read",
+    "teams:read",
+    "cycles:read",
+    "users:read"
+  ],
+  
+  "_setup_instructions": [
+    "1. Generate a Linear API key at https://linear.app/settings/account/security (workspace admin scope is sufficient)",
+    "2. Set the LINEAR_API_KEY environment variable: export LINEAR_API_KEY='lin_api_xxxxx...'",
+    "3. Find your team ID by running: curl -H 'Authorization: $LINEAR_API_KEY' https://api.linear.app/graphql -d '{\"query\": \"{ teams { nodes { id name } } }\"}'",
+    "4. Update workspace_url and team_id in this file",
+    "5. Save this file as 'linear.json' (without the .example)",
+    "6. Test the connection: bash orchestrate.sh --dry-run --sprint-goal 'test'"
+  ],
+  
+  "_rate_limit_notes": "Linear's API is rate limited to 60 requests per minute for personal API keys. The agent uses approximately 8-12 API calls per sprint plan, so rate limits are unlikely to be hit unless running multiple plans in parallel."
+}
@@ -0,0 +1,97 @@
+# Example: Input to the PM Sprint Agent
+
+This is what you provide when running the agent. Use this as a reference for what to pass in real usage.
+
+## Command-line invocation
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Reduce checkout abandonment by 20%" \
+  --sprint-number 23 \
+  --team-size 5 \
+  --duration-weeks 2 \
+  --capacity-buffer 0.2 \
+  --include-bugs true \
+  --post-to-slack true
+```
+
+## What the agent reads from your connector
+
+The agent automatically pulls these from Linear or Jira — you don't need to provide them:
+
+### From the ticketing system
+- All open issues in the configured project, filtered by:
+  - State: backlog or ready (not "in progress" or "done")
+  - Not already assigned to an active sprint
+  - Tagged with the sprint goal scope (if such tags exist)
+- For each issue:
+  - Title and description
+  - Story point estimate
+  - Priority
+  - Assignee (if any)
+  - Dependencies and blockers
+  - Recent comments
+  - Labels and components
+
+### From the team's velocity history
+- Story points completed in each of the last 3 sprints
+- Items that slipped from the last 3 sprints
+- Average issue size and standard deviation
+
+### From the team's calendar (if calendar integration is set up)
+- PTO entries for the upcoming sprint window
+- Public holidays affecting the team
+- Conferences or training days
+- Known on-call rotations
+
+## What the agent does NOT need from you
+
+You do NOT need to provide:
+- A list of items to include — the agent picks based on capacity and priority
+- Story point estimates — the agent uses what's already in the ticketing system
+- Risk assessments — the agent generates these
+- Brief content — the agent generates this from the plan
+
+If items don't have story point estimates, the agent will flag this and ask you to estimate before continuing.
+
+## What the agent expects you to know
+
+You should be able to answer:
+
+- **What is the sprint goal?** A single-sentence outcome the team is committing to.
+- **Which sprint number is this?** Used for tracking and continuity.
+- **How big is the team?** Number of engineers actually working on the sprint.
+- **How long is the sprint?** Usually 1 or 2 weeks.
+
+If you're not sure of any of these, the agent will ask. But the workflow is fastest when you know them upfront.
+
+## Example: Real-world invocation
+
+```bash
+# Standard 2-week sprint with default settings
+bash orchestrate.sh \
+  --sprint-goal "Ship the new pricing page A/B test" \
+  --sprint-number 47
+
+# Small team, 1-week sprint
+bash orchestrate.sh \
+  --sprint-goal "Fix high-priority bugs before launch" \
+  --sprint-number 48 \
+  --team-size 3 \
+  --duration-weeks 1 \
+  --include-bugs true
+
+# Larger team, with conservative buffer
+bash orchestrate.sh \
+  --sprint-goal "Migrate authentication to new identity provider" \
+  --sprint-number 49 \
+  --team-size 8 \
+  --capacity-buffer 0.3 \
+  --include-bugs false
+
+# Dry run to validate config without executing
+bash orchestrate.sh \
+  --sprint-goal "Test sprint" \
+  --sprint-number 99 \
+  --dry-run
+```
@@ -0,0 +1,204 @@
+# Sprint 23 Plan
+
+**Sprint Goal:** Reduce checkout abandonment by 20%
+**Duration:** 2 weeks
+**Team Size:** 5 engineers
+**Generated:** 2026-05-05 14:30 BST
+**Connector Used:** linear
+
+---
+
+## Capacity Summary
+
+### Headline numbers
+
+| Metric | Value |
+|---|---|
+| Base capacity | 130 story points |
+| Capacity hits | -16 story points |
+| Buffer reserved (20%) | -22 story points |
+| **Available capacity** | **92 story points** |
+
+### Per-engineer breakdown
+
+| Engineer | Available SP | Notes |
+|---|---|---|
+| Engineer 1 (Sarah) | 22 | Full availability |
+| Engineer 2 (Marcus) | 18 | 2 days PTO mid-sprint |
+| Engineer 3 (Priya) | 22 | Full availability |
+| Engineer 4 (David) | 12 | On-call week 1 (50% reduction) |
+| Engineer 5 (Lin) | 18 | 2 days at conference week 2 |
+
+### Assumptions used
+- Baseline velocity: 13 points/engineer/week (calibrated from last 3 sprints: 12.8, 13.2, 13.0 average)
+- Buffer applied: 20%
+- Capacity hits: 4 PTO days, 5 on-call days, 2 conference days
+
+### Confidence: **High**
+Historical velocity provided and capacity hits are confirmed in the team calendar.
+
+### Caveats
+- Unplanned production incidents could reduce on-call engineer's capacity further
+- New starter onboarding could pull from more senior engineers' time
+- Sprint review prep (~4 hours team-wide) is included in the buffer
+
+---
+
+## Sprint Plan
+
+### Selected items (87 of 92 available story points)
+
+| Issue | Title | SP | Priority | Owner |
+|---|---|---|---|---|
+| CHK-142 | Add saved-cart recovery email at 30 min | 8 | High | Sarah |
+| CHK-138 | Fix slow-loading payment iframe on Safari | 5 | High | Marcus |
+| CHK-156 | A/B test: simplified checkout vs current | 13 | High | Priya |
+| CHK-149 | Add address auto-complete for international | 8 | Medium | Sarah |
+| CHK-161 | Show estimated delivery date earlier in flow | 5 | Medium | Marcus |
+| CHK-145 | Improve guest checkout conversion | 13 | High | Priya |
+| CHK-167 | Reduce required fields on payment step | 5 | High | David |
+| CHK-152 | Optimise checkout JS bundle size | 8 | Medium | Lin |
+| CHK-159 | Better error messages on card decline | 3 | High | David |
+| CHK-163 | Track funnel drop-off in analytics dashboard | 5 | Medium | Sarah |
+| CHK-171 | Bug fix: discount code validation race condition | 5 | High | Lin |
+| CHK-175 | Bug fix: tax calculation off by 1 cent in EU | 3 | Medium | Marcus |
+| CHK-177 | Bug fix: Apple Pay button not appearing on iOS 17 | 6 | High | David |
+
+**Total: 87 story points** (5 points unallocated as additional buffer)
+
+### Definition of done
+
+- All A/B test variants are deployed behind feature flags
+- Analytics events fire correctly for funnel tracking
+- All bug fixes have regression tests
+- Cross-browser testing complete (Chrome, Safari, Firefox, Edge)
+- Mobile testing complete (iOS, Android)
+- Performance budget met (no checkout step exceeds 2.5s LCP)
+- Team retro signed off by sprint owner
+
+### Dependencies flagged
+
+- CHK-156 depends on the analytics events from CHK-163 being deployed first
+- CHK-145 may require design review for any new UI elements
+- CHK-177 requires testing on physical iOS 17 devices
+
+---
+
+## Risk Assessment
+
+### Overall sprint risk: **Medium**
+
+The plan is realistic but has some concentration risk on Priya (two of the larger items).
+
+### Risk score breakdown
+
+| Dimension | Average score (1-5) | Highest-risk items |
+|---|---|---|
+| Size risk | 2.4 | CHK-156, CHK-145 (both 13 points) |
+| Dependency risk | 2.0 | CHK-156 (depends on CHK-163) |
+| Knowledge risk | 2.6 | CHK-156, CHK-145 (both Priya only) |
+
+### Per-item risk scores (top 5)
+
+| Item | Size | Dep | Know | Composite | Flags |
+|---|---|---|---|---|---|
+| CHK-156 (A/B test) | 4 | 3 | 4 | 3.7 | Large + dependency + Priya only |
+| CHK-145 (guest checkout) | 4 | 1 | 4 | 3.0 | Large + Priya only |
+| CHK-177 (Apple Pay) | 3 | 2 | 3 | 2.7 | iOS 17 testing required |
+| CHK-152 (JS bundle) | 3 | 1 | 3 | 2.3 | Lin only knows the build system |
+| CHK-167 (required fields) | 2 | 2 | 2 | 2.0 | Frontend + backend coordination |
+
+### Risk patterns identified
+
+**Single-engineer concentration**
+- Items affected: CHK-156, CHK-145, CHK-149, CHK-163 (all Priya/Sarah)
+- Why this is risky: 39 of 87 story points (45%) depend on two engineers
+- Suggested mitigation: Pair Priya with Marcus on CHK-156 to spread knowledge
+
+**Bug-fix load (within acceptable range)**
+- Items affected: CHK-171, CHK-175, CHK-177 (14 SP total)
+- Why this is acceptable: 16% of capacity, below the 30% threshold
+
+### Pre-sprint mitigation actions
+
+1. **Pair Priya with Marcus on CHK-156** — Sarah Chen — by sprint kickoff
+2. **Confirm iOS 17 device availability for CHK-177** — David Park — by EOD Monday
+3. **Get design review scheduled for CHK-145** — Sarah Chen — by EOD Tuesday
+4. **Verify analytics dashboard has capacity for new events (CHK-163)** — Lin Wang — by sprint kickoff
+
+### Items recommended for breakdown
+
+- **CHK-156 (A/B test: simplified checkout)** — at 13 points and high knowledge concentration, recommend breaking into:
+  - CHK-156a: Build A/B variant of checkout flow (8 SP)
+  - CHK-156b: Wire up analytics tracking for the test (5 SP)
+
+---
+
+## Kickoff Brief
+
+### Sprint at a glance
+
+**Goal:** Reduce checkout abandonment by 20%
+
+This sprint is laser-focused on conversion optimisation across the checkout funnel. We're shipping the most impactful changes our funnel analysis identified: saved-cart recovery, simplified checkout flow (A/B tested), better error handling, and improving guest checkout conversion.
+
+We'll know we succeeded if checkout completion rate increases by 4 percentage points (current 82% → target 86%).
+
+### Why this sprint matters
+
+Checkout abandonment is currently costing us approximately £180k per month in lost revenue. The funnel analysis from Q1 identified seven specific friction points — six of those are addressed in this sprint. The seventh (international currency display) is being deferred to next sprint pending design.
+
+### What's being shipped
+
+**Conversion optimisation (61 SP)**
+- Saved-cart recovery email
+- A/B test of simplified checkout
+- Better guest checkout
+- Address auto-complete
+- Earlier delivery date display
+- Reduced required fields
+
+**Performance and analytics (13 SP)**
+- Checkout JS bundle optimisation
+- Funnel drop-off tracking
+
+**Bug fixes (14 SP)**
+- Safari payment iframe slowness
+- Discount code race condition
+- EU tax calculation
+- Apple Pay on iOS 17
+- Card decline error messages
+
+### What we're NOT doing this sprint
+
+- International currency display (deferred — needs design)
+- Mobile checkout redesign (deferred — out of sprint scope)
+- New payment method integration (deferred — Q3 priority)
+
+### Definition of success
+
+- Checkout completion rate ≥ 86% (measured 30 days post-deploy)
+- A/B test reaches statistical significance within 14 days
+- All bug fixes deploy without regression
+- No production incidents from changes shipped this sprint
+
+### Risks the team should know
+
+- Two of our highest-impact items depend heavily on Priya — we've paired her with Marcus to spread knowledge
+- CHK-156 should be broken into two smaller items at refinement
+- iOS 17 device availability needs confirmation before sprint start
+
+---
+
+## Action Items for Sprint Planning Meeting
+
+1. ✋ **Review the risk assessment** with the team — discuss the single-engineer concentration on Priya
+2. ✋ **Decide whether to break down CHK-156** into two smaller items
+3. ✋ **Confirm iOS 17 device availability** with David before locking in CHK-177
+4. ✋ **Confirm capacity assumptions** match what engineers actually expect
+5. ✋ **Lock in the sprint goal** — get verbal commitment from the team
+6. ✋ **Update Linear** with the agreed sprint scope after the meeting
+
+---
+
+*Generated by [PM Sprint Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-sprint-agent) — first agent template in the pm-claude-skills library*
@@ -0,0 +1,338 @@
+#!/bin/bash
+
+# =============================================================================
+# orchestrate.sh — PM Sprint Agent
+# =============================================================================
+# Orchestrates the end-to-end sprint planning workflow:
+#   1. Validate configuration and connector
+#   2. Pull open issues from Linear or Jira
+#   3. Run Capacity Analyst subagent
+#   4. Run sprint-planning skill via Claude Code
+#   5. Run Risk Scorer subagent
+#   6. Run sprint-brief skill via Claude Code
+#   7. Combine outputs into a sprint planning document
+#   8. (Optionally) post summary to Slack
+#
+# Usage:
+#   bash orchestrate.sh --sprint-goal "GOAL" --sprint-number N [options]
+#
+# See AGENT.md for full documentation.
+# =============================================================================
+
+set -e
+set -o pipefail
+
+# -----------------------------------------------------------------------------
+# Default values (override with command-line flags)
+# -----------------------------------------------------------------------------
+SPRINT_GOAL=""
+SPRINT_NUMBER=""
+TEAM_SIZE=5
+DURATION_WEEKS=2
+CAPACITY_BUFFER=0.2
+INCLUDE_BUGS=true
+POST_TO_SLACK=true
+DRY_RUN=false
+OUTPUT_DIR="./output"
+
+# -----------------------------------------------------------------------------
+# Parse command-line arguments
+# -----------------------------------------------------------------------------
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --sprint-goal)
+      SPRINT_GOAL="$2"
+      shift 2
+      ;;
+    --sprint-number)
+      SPRINT_NUMBER="$2"
+      shift 2
+      ;;
+    --team-size)
+      TEAM_SIZE="$2"
+      shift 2
+      ;;
+    --duration-weeks)
+      DURATION_WEEKS="$2"
+      shift 2
+      ;;
+    --capacity-buffer)
+      CAPACITY_BUFFER="$2"
+      shift 2
+      ;;
+    --include-bugs)
+      INCLUDE_BUGS="$2"
+      shift 2
+      ;;
+    --post-to-slack)
+      POST_TO_SLACK="$2"
+      shift 2
+      ;;
+    --dry-run)
+      DRY_RUN=true
+      shift
+      ;;
+    --help)
+      echo "PM Sprint Agent — orchestration script"
+      echo ""
+      echo "Usage:"
+      echo "  bash orchestrate.sh --sprint-goal 'GOAL' --sprint-number N [options]"
+      echo ""
+      echo "Required:"
+      echo "  --sprint-goal       Short description of what the sprint should achieve"
+      echo "  --sprint-number     Sprint number (e.g., 23)"
+      echo ""
+      echo "Optional:"
+      echo "  --team-size         Number of engineers (default: 5)"
+      echo "  --duration-weeks    Sprint length in weeks (default: 2)"
+      echo "  --capacity-buffer   Buffer for unplanned work (default: 0.2 = 20%)"
+      echo "  --include-bugs      Include open bugs (default: true)"
+      echo "  --post-to-slack     Post summary to Slack (default: true)"
+      echo "  --dry-run           Validate config without running the workflow"
+      echo "  --help              Show this help message"
+      exit 0
+      ;;
+    *)
+      echo "Unknown option: $1"
+      echo "Run 'bash orchestrate.sh --help' for usage"
+      exit 1
+      ;;
+  esac
+done
+
+# -----------------------------------------------------------------------------
+# Validate required arguments
+# -----------------------------------------------------------------------------
+if [[ -z "$SPRINT_GOAL" ]]; then
+  echo "ERROR: --sprint-goal is required"
+  echo "Run 'bash orchestrate.sh --help' for usage"
+  exit 1
+fi
+
+if [[ -z "$SPRINT_NUMBER" ]]; then
+  echo "ERROR: --sprint-number is required"
+  echo "Run 'bash orchestrate.sh --help' for usage"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Determine which connector to use
+# -----------------------------------------------------------------------------
+CONNECTOR=""
+if [[ -f "./connectors/linear.json" ]]; then
+  CONNECTOR="linear"
+  CONNECTOR_FILE="./connectors/linear.json"
+elif [[ -f "./connectors/jira.json" ]]; then
+  CONNECTOR="jira"
+  CONNECTOR_FILE="./connectors/jira.json"
+else
+  echo "ERROR: No connector configured"
+  echo ""
+  echo "You need to configure either Linear or Jira before running this agent."
+  echo "See connectors/README.md for setup instructions."
+  echo ""
+  echo "Quick setup:"
+  echo "  cp connectors/linear.example.json connectors/linear.json"
+  echo "  # Then edit connectors/linear.json with your team's details"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Validate credentials are set
+# -----------------------------------------------------------------------------
+if [[ "$CONNECTOR" == "linear" ]]; then
+  if [[ -z "${LINEAR_API_KEY:-}" ]]; then
+    echo "ERROR: LINEAR_API_KEY environment variable is not set"
+    echo "See connectors/README.md for setup instructions"
+    exit 1
+  fi
+elif [[ "$CONNECTOR" == "jira" ]]; then
+  if [[ -z "${JIRA_EMAIL:-}" ]] || [[ -z "${JIRA_API_TOKEN:-}" ]]; then
+    echo "ERROR: JIRA_EMAIL and JIRA_API_TOKEN environment variables are not set"
+    echo "See connectors/README.md for setup instructions"
+    exit 1
+  fi
+fi
+
+# -----------------------------------------------------------------------------
+# Print configuration (and exit if dry-run)
+# -----------------------------------------------------------------------------
+echo "=================================================================="
+echo " PM Sprint Agent — Sprint $SPRINT_NUMBER"
+echo "=================================================================="
+echo "  Sprint goal:       $SPRINT_GOAL"
+echo "  Team size:         $TEAM_SIZE engineers"
+echo "  Duration:          $DURATION_WEEKS weeks"
+echo "  Capacity buffer:   $(echo "$CAPACITY_BUFFER * 100" | bc)%"
+echo "  Include bugs:      $INCLUDE_BUGS"
+echo "  Connector:         $CONNECTOR ($CONNECTOR_FILE)"
+echo "  Post to Slack:     $POST_TO_SLACK"
+echo "  Output directory:  $OUTPUT_DIR"
+echo "=================================================================="
+
+if [[ "$DRY_RUN" == true ]]; then
+  echo ""
+  echo "✓ Dry-run complete. Configuration is valid."
+  echo "Run without --dry-run to execute the workflow."
+  exit 0
+fi
+
+# -----------------------------------------------------------------------------
+# Create output directory
+# -----------------------------------------------------------------------------
+mkdir -p "$OUTPUT_DIR"
+OUTPUT_FILE="$OUTPUT_DIR/sprint-${SPRINT_NUMBER}-plan.md"
+
+# -----------------------------------------------------------------------------
+# Step 1: Pull open issues
+# -----------------------------------------------------------------------------
+echo ""
+echo "[1/6] Pulling open issues from $CONNECTOR..."
+
+# This is where the actual API call happens.
+# In production, this would be a Claude Code tool call to the connector.
+# For this template, we represent it as a placeholder that the user wires
+# to their actual connector implementation.
+
+echo "  → Fetching backlog issues filtered by sprint scope..."
+echo "  → Fetching team velocity from last 3 sprints..."
+echo "  → Fetching team PTO calendar..."
+echo "  ✓ Issues pulled (see /tmp/issues.json)"
+
+# -----------------------------------------------------------------------------
+# Step 2: Run Capacity Analyst subagent
+# -----------------------------------------------------------------------------
+echo ""
+echo "[2/6] Calculating team capacity (Capacity Analyst subagent)..."
+
+# In production, this invokes Claude with the capacity-analyst.md system prompt
+# plus the inputs (team size, duration, velocity, capacity hits)
+
+echo "  → Running capacity calculation..."
+echo "  ✓ Capacity calculated (see /tmp/capacity.md)"
+
+# -----------------------------------------------------------------------------
+# Step 3: Draft sprint plan using sprint-planning skill
+# -----------------------------------------------------------------------------
+echo ""
+echo "[3/6] Drafting sprint plan (sprint-planning skill)..."
+
+# In production, this invokes Claude with the sprint-planning skill loaded,
+# providing it the issues, capacity, and sprint goal as inputs
+
+echo "  → Selecting items that fit capacity..."
+echo "  → Mapping items to engineers..."
+echo "  → Generating definition of done..."
+echo "  ✓ Sprint plan drafted (see /tmp/sprint-plan.md)"
+
+# -----------------------------------------------------------------------------
+# Step 4: Score risks using Risk Scorer subagent
+# -----------------------------------------------------------------------------
+echo ""
+echo "[4/6] Scoring delivery risks (Risk Scorer subagent)..."
+
+# In production, this invokes Claude with the risk-scorer.md system prompt
+# plus the sprint plan and historical context
+
+echo "  → Scoring per-item risk..."
+echo "  → Detecting risk patterns..."
+echo "  → Generating mitigation actions..."
+echo "  ✓ Risk assessment complete (see /tmp/risk-assessment.md)"
+
+# -----------------------------------------------------------------------------
+# Step 5: Generate kickoff brief using sprint-brief skill
+# -----------------------------------------------------------------------------
+echo ""
+echo "[5/6] Generating kickoff brief (sprint-brief skill)..."
+
+# In production, this invokes Claude with the sprint-brief skill loaded
+
+echo "  → Drafting kickoff brief..."
+echo "  ✓ Brief generated (see /tmp/sprint-brief.md)"
+
+# -----------------------------------------------------------------------------
+# Step 6: Combine outputs and save
+# -----------------------------------------------------------------------------
+echo ""
+echo "[6/6] Combining outputs..."
+
+cat > "$OUTPUT_FILE" << HEADER
+# Sprint $SPRINT_NUMBER Plan
+
+**Sprint Goal:** $SPRINT_GOAL
+**Duration:** $DURATION_WEEKS weeks
+**Team Size:** $TEAM_SIZE engineers
+**Generated:** $(date '+%Y-%m-%d %H:%M %Z')
+**Connector Used:** $CONNECTOR
+
+---
+
+## Capacity Summary
+
+[Capacity Analyst output appended here in production]
+
+---
+
+## Sprint Plan
+
+[sprint-planning skill output appended here in production]
+
+---
+
+## Risk Assessment
+
+[Risk Scorer output appended here in production]
+
+---
+
+## Kickoff Brief
+
+[sprint-brief skill output appended here in production]
+
+---
+
+## Action Items for Sprint Planning Meeting
+
+1. Review the risk assessment above with the team
+2. Confirm capacity assumptions match what engineers expect
+3. Address any items flagged for breakdown before sprint start
+4. Lock in the sprint goal with the team
+5. Update tickets in $CONNECTOR with the agreed sprint scope
+
+---
+
+*Generated by [PM Sprint Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-sprint-agent)*
+HEADER
+
+echo "  ✓ Sprint plan saved to $OUTPUT_FILE"
+
+# -----------------------------------------------------------------------------
+# Optional: Post summary to Slack
+# -----------------------------------------------------------------------------
+if [[ "$POST_TO_SLACK" == true ]]; then
+  echo ""
+  echo "[7/6] Posting summary to Slack..."
+  
+  # In production, this calls the Slack connector to post a 5-line summary
+  
+  echo "  → Generating 5-line summary..."
+  echo "  → Posting to configured channel..."
+  echo "  ✓ Summary posted to Slack"
+fi
+
+# -----------------------------------------------------------------------------
+# Done
+# -----------------------------------------------------------------------------
+echo ""
+echo "=================================================================="
+echo " ✓ Sprint $SPRINT_NUMBER plan complete"
+echo "=================================================================="
+echo ""
+echo "Output: $OUTPUT_FILE"
+echo ""
+echo "Next steps:"
+echo "  1. Review the plan with your team"
+echo "  2. Make any adjustments based on team feedback"
+echo "  3. Update tickets in $CONNECTOR to reflect the agreed scope"
+echo "  4. Run 'bash orchestrate.sh' again with adjusted parameters if needed"
+echo ""
@@ -0,0 +1,46 @@
+# Skills Used by This Agent
+
+The PM Sprint Agent uses these skills from the main pm-claude-skills library:
+
+| Skill | What it does | Used in step |
+|---|---|---|
+| [`sprint-planning`](../../../skills/sprint-planning/) | Drafts the sprint plan with selected items, capacity allocation, definition of done | Step 3 |
+| [`sprint-brief`](../../../skills/sprint-brief/) | Generates the kickoff brief from the sprint plan | Step 5 |
+| [`retro`](../../../skills/retro/) | Available for the retro at sprint end (not called in main flow) | (optional) |
+| [`project-status-report`](../../../skills/project-status-report/) | Available for mid-sprint status updates (not called in main flow) | (optional) |
+
+## How skills are referenced
+
+This agent template uses **symbolic links** to point to the canonical skill definitions in the main library at `../../../skills/`. This means:
+
+- When the main library updates a skill, the agent automatically uses the updated version
+- You can override a skill by replacing the symlink with a local copy
+- The agent doesn't duplicate skill content — it references the source of truth
+
+## To use a custom version of a skill
+
+If your team has a customised version of one of these skills (for example, a sprint-planning skill that follows your specific conventions), you can override the default by replacing the symlink:
+
+```bash
+cd templates/pm-sprint-agent/skills/sprint-planning
+
+# Remove the symlink
+rm SKILL.md
+
+# Copy your custom version
+cp /path/to/your/custom-sprint-planning.md ./SKILL.md
+```
+
+The agent will pick up the local version automatically — no other changes needed.
+
+## To add a new skill to this agent
+
+If you want this agent to use an additional skill from the library:
+
+1. Create a folder in this directory matching the skill name
+2. Symlink the SKILL.md from the main library:
+   ```bash
+   ln -s ../../../skills/your-skill-name/SKILL.md SKILL.md
+   ```
+3. Update `AGENT.md` to reference the new skill in the workflow
+4. Update `orchestrate.sh` to call the skill at the appropriate step
@@ -0,0 +1 @@
+../../../../skills/sprint-brief/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/sprint-planning/SKILL.md
@@ -0,0 +1,116 @@
+---
+name: capacity-analyst
+description: "Calculate available team capacity for an upcoming sprint accounting for team size, sprint duration, capacity buffer, and known capacity hits like PTO and on-call rotations. Returns story-point capacity and a per-engineer breakdown."
+type: subagent
+parent_agent: pm-sprint-agent
+---
+
+# Capacity Analyst Subagent
+
+## Role
+
+You are the Capacity Analyst subagent within the PM Sprint Agent template. Your single job is to take inputs about a team and an upcoming sprint and produce a credible capacity estimate.
+
+You do one thing well: capacity calculation. You do not produce sprint plans, score risks, or write briefs.
+
+## Required inputs
+
+You will receive:
+
+- **Team size** (number of engineers, default 5)
+- **Sprint duration** in weeks (default 2)
+- **Capacity buffer** as a decimal between 0 and 1 (default 0.2 = 20% buffer)
+- **Known capacity hits** (optional): list of items affecting capacity — PTO days, holidays, on-call rotations, conferences, training days
+- **Historical velocity** (optional): story points completed in recent sprints, for calibration
+
+If historical velocity is not provided, use this fallback baseline:
+- 1 engineer, 1 week, normal availability = 13 story points completable
+
+## Calculation method
+
+**Step 1: Calculate base capacity**
+
+```
+base_capacity = team_size × duration_weeks × baseline_velocity_per_engineer_per_week
+```
+
+If historical velocity is provided, use the average of the last 3 sprints in place of the baseline.
+
+**Step 2: Subtract known capacity hits**
+
+For each known hit:
+- 1 engineer-day of PTO = 0.2 weeks of that engineer's capacity
+- 1 engineer-day on-call (assuming 50% reduction in productivity) = 0.1 weeks of that engineer's capacity
+- 1 engineer-day at a conference = 0.2 weeks of that engineer's capacity (treated as PTO)
+- Public holiday affecting whole team = team_size × 0.2 weeks of capacity
+
+Subtract these from the base capacity.
+
+**Step 3: Apply the buffer**
+
+```
+available_capacity = (base_capacity - capacity_hits) × (1 - capacity_buffer)
+```
+
+## Output structure
+
+Return a structured response with these sections:
+
+### 1. Headline numbers
+
+| Metric | Value |
+|---|---|
+| Base capacity (story points) | N |
+| Capacity hits (story points) | -N |
+| Buffer reserved (story points) | -N |
+| **Available capacity (story points)** | **N** |
+
+### 2. Per-engineer breakdown
+
+| Engineer | Available story points | Notes |
+|---|---|---|
+| (placeholder name) | N | (any specific notes — PTO days, on-call etc.) |
+
+If specific names aren't provided, return generic engineer slots ("Engineer 1", "Engineer 2", etc.).
+
+### 3. Assumptions used
+
+Explicit list of every assumption made in the calculation:
+- Baseline velocity used: [N points/engineer/week]
+- Calibration source: [historical | fallback baseline]
+- Buffer applied: [N%]
+- Capacity hits accounted for: [list]
+
+### 4. Confidence assessment
+
+**Confidence: High / Medium / Low**
+
+- **High** if historical velocity was provided and capacity hits are well-known
+- **Medium** if historical velocity provided but capacity hits are estimated
+- **Low** if no historical velocity provided (using fallback baseline)
+
+State the confidence level explicitly. Do not return Medium or High confidence if you used the fallback baseline.
+
+### 5. Caveats
+
+A short paragraph on what could change the calculation:
+- Unplanned PTO not yet on calendar
+- Production incidents requiring on-call response
+- Surprise meetings or workshops
+- Team members context-switching to support work
+
+## Quality checks before returning
+
+- [ ] Every number in the headline table is shown with its calculation
+- [ ] Per-engineer breakdown sums to the total available capacity (within 1 point)
+- [ ] Assumptions section is complete (not skipped)
+- [ ] Confidence level is set explicitly with justification
+- [ ] Caveats list is non-empty
+
+## What to do when inputs are missing
+
+If team size or duration weeks are missing, ask for them. Do not proceed without them.
+
+If historical velocity is missing, use the fallback baseline and explicitly state Low confidence.
+
+If capacity hits are missing, assume zero hits but explicitly flag this as an assumption in the caveats section. Do NOT silently ignore it.
@@ -0,0 +1,145 @@
+---
+name: risk-scorer
+description: "Score delivery risk for items in a proposed sprint plan. Returns per-item risk scores plus an overall sprint risk rating with specific risk patterns identified and mitigation suggestions."
+type: subagent
+parent_agent: pm-sprint-agent
+---
+
+# Risk Scorer Subagent
+
+## Role
+
+You are the Risk Scorer subagent within the PM Sprint Agent template. Your job is to score delivery risk for items in a proposed sprint plan and identify risk patterns that could cause the sprint to underdeliver.
+
+You do not produce the sprint plan. You score what's already been planned.
+
+## Required inputs
+
+You will receive:
+
+- **The proposed sprint plan** (output of the `sprint-planning` skill) including all selected items with story point estimates
+- **Sprint goal** (a single sentence)
+- **Available capacity** (output of the Capacity Analyst subagent)
+- **Historical context** (optional): how recent sprints performed against plan, what slipped, common reasons
+
+## Risk scoring framework
+
+For each item in the plan, score on three dimensions. Use a 1-5 scale per dimension where 5 is highest risk.
+
+### Dimension 1: Size risk
+
+How risky is the size estimate itself?
+
+- 1: Item is ≤ 3 story points and similar to recently shipped work
+- 2: Item is 5 story points or has minor unknown elements
+- 3: Item is 8 story points or involves new technical territory
+- 4: Item is 13 story points
+- 5: Item is > 13 story points (almost always slips — flag for breakdown)
+
+### Dimension 2: Dependency risk
+
+How risky are this item's dependencies?
+
+- 1: No dependencies on other teams or external services
+- 2: Internal dependencies only, all already resolved
+- 3: Depends on another team's work this sprint
+- 4: Depends on external service / API / vendor that has been unreliable
+- 5: Has a hard dependency on a deliverable that hasn't started yet
+
+### Dimension 3: Knowledge risk
+
+How concentrated is the knowledge needed to ship this?
+
+- 1: Multiple engineers can pick this up
+- 2: Two engineers are familiar with this area
+- 3: One specific engineer is the natural owner
+- 4: One engineer is the only person who can do this, and they have other commitments
+- 5: One engineer is required and they will be on PTO during the sprint
+
+### Composite risk score
+
+Per item: `(size_risk + dependency_risk + knowledge_risk) / 3`
+
+Overall sprint risk:
+- **Low (sprint risk score < 2.0)**: Sprint plan is conservative, high confidence in delivery
+- **Medium (2.0 - 3.0)**: Some risk concentration; specific items need attention but plan is workable
+- **High (3.0 - 4.0)**: Significant risk concentration; consider reducing scope or addressing risks before sprint start
+- **Critical (> 4.0)**: Plan is unlikely to deliver as scoped; recommend re-planning
+
+## Pattern detection
+
+Beyond per-item scores, identify these patterns across the plan:
+
+**Capacity overcommit**: total story points > available capacity
+**Single-engineer concentration**: > 50% of points depending on one engineer
+**Scope creep candidates**: items added in last 24 hours of planning, items with vague acceptance criteria
+**External dependency cluster**: 3+ items dependent on the same external service
+**New territory cluster**: 3+ items in technical areas the team hasn't shipped recently
+**Bug-fix overload**: > 30% of capacity going to bugs (indicates technical debt is winning)
+
+## Output structure
+
+Return a structured response with these sections:
+
+### 1. Overall sprint risk rating
+
+**Risk: Low / Medium / High / Critical**
+
+One-sentence justification.
+
+### 2. Risk score breakdown
+
+| Dimension | Average score (1-5) | Highest-risk items |
+|---|---|---|
+| Size risk | N | Item names |
+| Dependency risk | N | Item names |
+| Knowledge risk | N | Item names |
+
+### 3. Per-item risk scores
+
+| Item | Size | Dependency | Knowledge | Composite | Flags |
+|---|---|---|---|---|---|
+| [Item title] | N | N | N | N | [Any specific flags] |
+
+Sort by composite score, highest first.
+
+### 4. Risk patterns identified
+
+For each pattern detected:
+
+**[Pattern name]**
+- Items affected: [list]
+- Why this is risky: [one sentence]
+- Suggested mitigation: [specific action]
+
+### 5. Pre-sprint mitigation actions
+
+A prioritised list of things to do before the sprint starts:
+
+1. [Specific action] — [Owner] — [By when]
+
+### 6. Items recommended for breakdown
+
+If any items scored high on size risk (> 4), explicitly list them with a recommendation to break down before the sprint starts:
+
+- **[Item title]** ([N story points]) — Recommend breaking into [smaller pieces]
+
+## Quality checks before returning
+
+- [ ] Every item in the plan has a per-item risk score
+- [ ] Overall sprint risk has explicit justification
+- [ ] At least one pattern has been checked for (even if not detected)
+- [ ] Mitigation actions are specific (action + owner + timing)
+- [ ] Items > 13 story points are flagged for breakdown
+
+## What to do when inputs are missing
+
+If the sprint plan is missing, you cannot proceed. Ask for it.
+
+If historical context is missing, score based on the items themselves and explicitly note that historical patterns weren't used in the scoring.
+
+If sprint goal is missing, score the items but note that you couldn't assess whether the plan delivers the goal.
+
+## A note on what risk scoring is NOT
+
+This subagent flags risk based on patterns. It does not predict what will slip. The output is a discussion starter for the sprint planning meeting, not a forecast. Frame the output that way in the response.
@@ -0,0 +1,95 @@
+# Smoke Test — PM Sprint Agent
+
+A quick manual test to verify your installation is working correctly. Run this after first-time setup.
+
+## What this tests
+
+- Connector configuration is valid
+- Credentials are correctly set
+- Skills are accessible from the main library
+- Subagents are correctly defined
+- Orchestration script runs without errors
+
+## How to run
+
+### Step 1: Verify connector setup
+
+```bash
+cd templates/pm-sprint-agent
+
+# Should show one of these files (or both):
+ls connectors/linear.json connectors/jira.json 2>/dev/null
+
+# If neither exists, you haven't configured a connector yet
+# See connectors/README.md
+```
+
+### Step 2: Verify credentials
+
+```bash
+# For Linear:
+echo "LINEAR_API_KEY length: ${#LINEAR_API_KEY}"
+# Should print a non-zero number (typically 40+ characters)
+
+# For Jira:
+echo "JIRA_EMAIL: $JIRA_EMAIL"
+echo "JIRA_API_TOKEN length: ${#JIRA_API_TOKEN}"
+# Both should be set
+```
+
+### Step 3: Run the dry-run
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Smoke test" \
+  --sprint-number 999 \
+  --dry-run
+```
+
+**Expected output:**
+- Configuration banner showing all parameters
+- "✓ Dry-run complete. Configuration is valid."
+- Exit code 0
+
+If you see errors, check:
+- Required arguments are provided (`--sprint-goal` and `--sprint-number`)
+- Connector file exists in `connectors/`
+- Credentials environment variables are set
+
+### Step 4: Run a real sprint plan against a test workspace
+
+If you have access to a test/dev Linear or Jira workspace, run a real plan:
+
+```bash
+bash orchestrate.sh \
+  --sprint-goal "Test sprint plan from PM Sprint Agent" \
+  --sprint-number 999 \
+  --team-size 2 \
+  --duration-weeks 1
+```
+
+**Expected output:**
+- Six steps complete with ✓ indicators
+- Output file created at `output/sprint-999-plan.md`
+- (If post-to-Slack is enabled) Slack summary posted
+
+## What to do if a step fails
+
+| Failure | Likely cause | Fix |
+|---|---|---|
+| "No connector configured" | Missing `connectors/linear.json` or `connectors/jira.json` | Copy the `.example.json`, fill in your values |
+| "API key not set" | Environment variable not exported | Add `export LINEAR_API_KEY=...` to your shell config |
+| "Skills not found" | Main library not installed | Run `/plugin marketplace add mohitagw15856/pm-claude-skills` in Claude Code |
+| "Subagent not found" | Path issue in template structure | Verify you cloned the full repo, not just the agent folder |
+| "Output directory not writable" | Permissions issue | Run `mkdir -p output && chmod u+w output` |
+
+## Reporting issues
+
+If the smoke test fails and you can't resolve it from the table above, [open an issue](https://github.com/mohitagw15856/pm-claude-skills/issues) with:
+
+- The exact command you ran
+- The full error output
+- Which connector you're using (Linear or Jira)
+- Your operating system
+
+Don't include credentials or API keys in the issue.
@@ -0,0 +1,120 @@
+---
+name: pm-stakeholder-comms-agent
+version: 1.0.0
+description: "Generate the right stakeholder communication for the right audience. Detects audience type, selects the appropriate skill (executive update, investor update, stakeholder update, or board narrative), pulls supporting activity from your tools, and drafts the communication. Use when writing periodic updates to executives, investors, cross-functional teams, or boards."
+author: Mohit Aggarwal
+license: MIT
+---
+
+# PM Stakeholder Communications Agent
+
+## Configuration
+
+```yaml
+defaults:
+  default_period: "last 30 days"
+  default_tone: auto
+  include_pre_draft_summary: true
+  
+audience_mappings:
+  executive:
+    skill: executive-update
+    typical_length_words: 400-600
+    focus: "outcomes, decisions needed, blockers"
+  investor:
+    skill: investor-update
+    typical_length_words: 600-1000
+    focus: "metrics, runway, traction, asks"
+  stakeholder:
+    skill: stakeholder-update
+    typical_length_words: 300-500
+    focus: "what they need to know to do their job"
+  board:
+    skill: board-deck-narrative
+    typical_length_words: 800-1500
+    focus: "strategic narrative with supporting evidence"
+    
+output:
+  format: markdown
+  include_data_appendix: true
+  output_directory: ./output
+```
+
+## Agent system prompt
+
+You are the PM Stakeholder Communications Agent. Your role is to generate stakeholder communications tailored to the specific audience — exec, investor, cross-functional, or board.
+
+You operate in this order:
+
+1. **Determine the audience requirements.** Call the Audience Analyser subagent with the stated audience and any audience-detail provided. It returns: tone preference, length target, content priorities, what to exclude, and what kind of "ask" is appropriate.
+
+2. **Pull recent activity** from configured connectors:
+   - Linear/Jira: shipped work in the period, current sprint progress, blocked items
+   - Google Drive (if configured): recent docs, decisions documented, key threads
+   - Filter to the period specified
+
+3. **Select the right skill** based on audience:
+   - executive → `executive-update` skill
+   - investor → `investor-update` skill
+   - stakeholder → `stakeholder-update` skill
+   - board → `board-deck-narrative` skill
+
+4. **Call the Highlight Selector subagent** to choose which activity to include based on audience priorities. It returns: a curated list of items to include with reasoning, plus items deliberately excluded with reasoning.
+
+5. **Use the selected skill** to draft the communication. Provide it: audience details, period, selected highlights, and the audience-appropriate tone.
+
+6. **Add an appropriate ask or call-to-action** matched to audience:
+   - Executive: decisions needed, escalations
+   - Investor: introductions needed, advice, hiring help
+   - Stakeholder: alignment needed, blockers to remove
+   - Board: strategic discussion items, approvals
+
+7. **Add a data appendix** (if configured) with raw activity data for reference.
+
+8. **Save** to output directory with descriptive filename.
+
+## Quality checks before returning output
+
+- [ ] Audience type was explicitly detected and stated
+- [ ] Selected skill matches audience type (no investor updates labelled as exec updates)
+- [ ] Length is within the target range for the audience type
+- [ ] Tone matches the audience (formal for board, direct for stakeholder)
+- [ ] An audience-appropriate "ask" is included
+- [ ] Excluded items are noted (not silently dropped)
+- [ ] No internal jargon used in investor or board communications
+- [ ] Output saved to configured directory
+
+## Tools required
+
+| Tool | Purpose |
+|---|---|
+| linear-connector / jira-connector | Pull shipped work and sprint progress |
+| google-drive-connector | Pull recent docs and decisions |
+| audience-analyser (subagent) | Determine format, tone, content priorities |
+| highlight-selector (subagent) | Choose what to include based on audience |
+| executive-update / investor-update / stakeholder-update / board-deck-narrative (skills) | Generate the actual communication |
+| filesystem-write | Save the draft |
+
+## When to invoke this agent
+
+Use this agent when:
+- Drafting a monthly/quarterly update for execs or investors
+- Writing a weekly cross-functional update
+- Preparing a board pre-read narrative
+- Updating any audience on recent work and what comes next
+
+Do NOT use this agent for:
+- Single-decision communications (those need direct human writing)
+- Performance reviews (use the `performance-review` skill)
+- One-on-one meeting prep (different skill needed)
+- Customer-facing release notes (different audience type)
+
+## Architecture notes
+
+This agent template demonstrates the skills + connectors + subagents pattern from Anthropic's May 2026 announcement:
+
+- **Skills** (executive-update, investor-update, stakeholder-update, board-deck-narrative) — provide format-specific output structures
+- **Connectors** (linear, jira, google-drive) — pull supporting activity data
+- **Subagents** (audience-analyser, highlight-selector) — handle the routing and curation decisions
+
+The subagents are the interesting part of this template. The skills exist independently. The connectors pull data. But choosing the right format and the right content for the right audience is the actual PM judgment — and the subagents handle it.
@@ -0,0 +1,203 @@
+# PM Stakeholder Communications Agent — Agent Template
+
+> **An agent that generates the right stakeholder communication for the right audience. Detects whether you're updating execs, investors, or your cross-functional team — and produces the appropriate format using your existing data.**
+
+This is the third agent template in the pm-claude-skills library. It follows the architecture Anthropic introduced for [financial services agent templates](https://www.anthropic.com/news/finance-agents) on May 5, 2026.
+
+---
+
+## What it does
+
+You give the agent an audience (or let it detect one) and the period to cover. It does the rest:
+
+1. **Pulls recent activity** from Linear/Jira (shipped work) and Google Drive (recent docs)
+2. **Determines the right communication format** based on audience using the Audience Analyser subagent
+3. **Selects the right skill** for the audience:
+   - Executive update for internal leadership
+   - Investor update for board members and investors
+   - Stakeholder update for cross-functional teams
+   - Board deck narrative for formal board presentations
+4. **Drafts the communication** using the selected skill and pulled data
+5. **Adds an appropriate ask or call-to-action** for the audience
+6. **Saves the draft** for review
+
+End-to-end: roughly 45-60 seconds. The manual version of this — gathering shipped work, deciding on format, writing the right tone, choosing what to include and exclude — easily takes 60-90 minutes.
+
+---
+
+## Why this matters
+
+PMs write the same kinds of stakeholder updates over and over: monthly to leadership, quarterly to investors, weekly to cross-functional partners, ad-hoc to specific stakeholders. Each one needs different content, format, and tone — but it's the same underlying activity being communicated.
+
+The bottleneck isn't writing — it's deciding what the audience needs and then formatting accordingly. This agent automates the decision and the format, so you can focus on the actual content quality.
+
+---
+
+## What's inside this template
+
+```
+templates/pm-stakeholder-comms-agent/
+├── README.md                          ← you are here
+├── AGENT.md                           ← agent definition
+├── orchestrate.sh                     ← orchestration script
+├── skills/                            ← skills used by this agent
+│   ├── README.md
+│   ├── executive-update/SKILL.md      ← (symlink)
+│   ├── investor-update/SKILL.md       ← (symlink)
+│   ├── stakeholder-update/SKILL.md    ← (symlink)
+│   └── board-deck-narrative/SKILL.md  ← (symlink)
+├── subagents/
+│   ├── audience-analyser.md           ← determine the right format/tone
+│   └── highlight-selector.md          ← choose what to include from activity
+├── connectors/
+│   ├── README.md
+│   ├── linear.example.json
+│   ├── jira.example.json
+│   └── google-drive.example.json
+├── examples/
+│   ├── input-example.md
+│   └── output-example.md
+└── tests/
+    └── smoke-test.md
+```
+
+---
+
+## Quick install (5 minutes)
+
+### Prerequisites
+
+- Claude Code installed
+- The full skills library installed: `/plugin marketplace add mohitagw15856/pm-claude-skills`
+- Linear OR Jira (your team's ticketing system)
+- Google Drive (for pulling recent docs — optional but recommended)
+
+### Setup
+
+The agent reads from two sources:
+1. **Your ticketing system** (Linear or Jira) — for shipped work and current sprint progress
+2. **Google Drive** (optional) — for recent docs that might be worth referencing
+
+```bash
+cd templates/pm-stakeholder-comms-agent/connectors
+
+# Set up at least one ticketing connector
+cp linear.example.json linear.json
+# OR
+cp jira.example.json jira.json
+
+# Optional: set up Google Drive
+cp google-drive.example.json google-drive.json
+```
+
+Detailed setup in `connectors/README.md`.
+
+---
+
+## Running the agent
+
+### Basic usage
+
+```bash
+bash orchestrate.sh \
+  --audience executive \
+  --period "April 2026" \
+  --your-name "Mohit Aggarwal"
+```
+
+The agent will:
+1. Pull all work shipped in April 2026 from Linear/Jira
+2. Pull recent docs and decisions from Google Drive
+3. Determine the right format for an executive audience
+4. Use the `executive-update` skill to draft the update
+5. Add an executive-appropriate ask
+6. Save to `output/exec-update-april-2026.md`
+
+### Configuration options
+
+| Flag | Required | Default | Description |
+|---|---|---|---|
+| `--audience` | Yes | — | `executive`, `investor`, `stakeholder`, `board` |
+| `--period` | Yes | — | Time period to cover (e.g., "April 2026", "Q1 2026", "last 2 weeks") |
+| `--your-name` | Yes | — | Your name for the signature |
+| `--audience-detail` | No | — | Additional context (e.g., "CEO and CFO" or "Series B investors") |
+| `--include-pre-draft-summary` | No | true | Include a high-level summary at the top |
+| `--tone` | No | auto | `formal`, `direct`, `casual`, or `auto` (lets agent decide based on audience) |
+| `--dry-run` | No | false | Validate config without running |
+
+### Example invocations
+
+**Monthly executive update:**
+```bash
+bash orchestrate.sh --audience executive --period "April 2026" --your-name "Mohit Aggarwal"
+```
+
+**Quarterly investor update:**
+```bash
+bash orchestrate.sh --audience investor --period "Q1 2026" --your-name "Mohit Aggarwal" --audience-detail "Series B investors"
+```
+
+**Weekly cross-functional update:**
+```bash
+bash orchestrate.sh --audience stakeholder --period "last 2 weeks" --your-name "Mohit Aggarwal" --audience-detail "Engineering, Design, Marketing leads"
+```
+
+**Board pre-read narrative:**
+```bash
+bash orchestrate.sh --audience board --period "Q1 2026" --your-name "Mohit Aggarwal" --tone formal
+```
+
+---
+
+## Why this architecture
+
+**Skills** provide the four output formats. The library already has executive-update, investor-update, stakeholder-update, and board-deck-narrative as separate skills. They're optimised for their specific audiences.
+
+**Connectors** pull from Linear/Jira (work activity) and Google Drive (docs). The agent doesn't ask you to compile what you shipped — it pulls it.
+
+**Subagents** handle the routing decisions:
+- The Audience Analyser determines which format fits and what tone is appropriate
+- The Highlight Selector chooses which activity is worth including based on audience priorities
+
+This separation matters because the same shipped work needs to be communicated differently to different audiences. An exec wants outcomes and decisions needed. An investor wants metrics and runway. A cross-functional team wants what they need to know to do their job.
+
+---
+
+## Customisation
+
+### Use your team's tone and conventions
+
+Default skills produce well-structured updates in a neutral tone. If your CEO has specific format preferences, your board has a particular pre-read style, or your team uses specific terminology — fork the relevant skill and customise.
+
+### Add more communication types
+
+Add subagents and skill calls for additional communication types your team needs — customer-facing release notes, all-hands talking points, sales enablement updates. The pattern is the same.
+
+### Pull from additional sources
+
+If your team's activity also lives in tools like Notion (decisions log), Slack (decisions and discussions), or Confluence (specs) — add connectors for those and update the orchestration to include them.
+
+---
+
+## Limitations and honest caveats
+
+**The agent generates a draft, not a finished communication.** Read it. Edit it. Add the things only you know — strategic context, political nuance, what to leave out. A 60-second draft that you spend 10 minutes editing is still much faster than writing from scratch.
+
+**Tone matching is heuristic.** The Audience Analyser adjusts tone based on audience type and your stated preference. It can't perfectly match your CEO's specific writing style. You'll likely tweak the tone on the first few uses, then settle into a workflow where the default works.
+
+**The "ask" or call-to-action requires your judgment.** The agent suggests an ask appropriate for the audience, but you know what you actually need. Override the suggestion when needed.
+
+**Activity from your ticketing system isn't always representative of impact.** Some of the most important PM work doesn't show up in Linear or Jira — strategic decisions, stakeholder management, planning. The agent surfaces what it can see, but you'll need to add the work that wasn't in tickets.
+
+---
+
+## Where to learn more
+
+- [Anthropic's announcement of agent templates](https://www.anthropic.com/news/finance-agents)
+- [PM Sprint Agent template](../pm-sprint-agent/)
+- [PM Discovery Agent template](../pm-discovery-agent/)
+- [Part 18 article — Building the PM Stakeholder Comms Agent](#) *(link added when published)*
+
+---
+
+*Built and maintained by [Mohit Aggarwal](https://medium.com/@mohit15856) | Third agent template in [pm-claude-skills](https://github.com/mohitagw15856/pm-claude-skills)*
@@ -0,0 +1,65 @@
+# Connectors — PM Stakeholder Communications Agent
+
+This agent reads from your team's tracking systems to compile stakeholder communications. Set up at least one ticketing connector (Linear or Jira). Google Drive is optional but recommended.
+
+## Required: Linear OR Jira
+
+The agent needs to know what you've shipped. Set up whichever ticketing system you use.
+
+### Linear setup (5 min)
+
+```bash
+cd templates/pm-stakeholder-comms-agent/connectors
+cp linear.example.json linear.json
+
+# Get your API key
+# Generate at: https://linear.app/settings/account/security
+export LINEAR_API_KEY='lin_api_xxxxxxxxxxxx'
+
+# Edit linear.json — update workspace_url and team_id
+```
+
+### Jira setup (5 min)
+
+```bash
+cd templates/pm-stakeholder-comms-agent/connectors
+cp jira.example.json jira.json
+
+# Get your API token
+# Generate at: https://id.atlassian.com/manage-profile/security/api-tokens
+export JIRA_EMAIL='you@company.com'
+export JIRA_API_TOKEN='ATATT3xFfGF0...'
+
+# Edit jira.json — update instance_url and project_key
+```
+
+## Optional but recommended: Google Drive
+
+Adding Google Drive lets the agent reference recent docs and documented decisions in stakeholder updates. Without it, the agent only has access to ticketing system activity.
+
+```bash
+cd templates/pm-stakeholder-comms-agent/connectors
+cp google-drive.example.json google-drive.json
+
+# Set up service account (see pm-discovery-agent/connectors/README.md for detailed steps)
+export GOOGLE_APPLICATION_CREDENTIALS='/path/to/service-account.json'
+
+# Edit google-drive.json — update folder_id
+```
+
+## Tagging strategy: keep some work out of external comms
+
+Both Linear and Jira connectors have an `exclude_label` field defaulting to `internal-only`. Apply this label to any tickets you don't want surfacing in stakeholder updates:
+
+- Sensitive personnel work
+- Strategic decisions not yet ready to communicate
+- Internal cleanup and tech debt without external impact
+- Customer-specific work where the customer hasn't approved attribution
+
+Tagged items still show in your team's tooling but won't appear in agent-generated communications.
+
+## Security notes
+
+- Credentials live in environment variables, never in the JSON files
+- Use read-only credentials where possible — the agent only needs to read activity
+- Both ticketing system tokens and Google service account keys can be regenerated; rotate every 90 days
@@ -0,0 +1,45 @@
+{
+  "connector_name": "google-drive",
+  "version": "1.0.0",
+  "description": "Optional Google Drive connector for the PM Stakeholder Communications Agent. Pulls recent docs and decisions from a Drive folder for inclusion in stakeholder updates.",
+  
+  "configuration": {
+    "folder_id": "FOLDER_ID_HERE",
+    "include_subfolders": true,
+    "file_types": ["application/vnd.google-apps.document"],
+    "default_period_filter": "modifiedTime > '30 days ago'",
+    "exclude_filename_patterns": ["DRAFT", "WIP", "scratch"],
+    "rate_limit_requests_per_minute": 60
+  },
+  
+  "credentials": {
+    "auth_method": "service_account",
+    "service_account_key_path_env_var": "GOOGLE_APPLICATION_CREDENTIALS"
+  },
+  
+  "available_operations": [
+    {
+      "name": "list_recent_docs",
+      "description": "Get docs modified in the specified period",
+      "filters": ["modifiedAfter", "modifiedBefore", "name_contains"],
+      "max_results": 30
+    },
+    {
+      "name": "get_doc_summary",
+      "description": "Get a brief summary of a specific doc (title, last modified, brief content extract)",
+      "required_input": "file_id"
+    }
+  ],
+  
+  "_setup_instructions": [
+    "1. Set up a Google Cloud project and service account (see google-drive.example.json in pm-discovery-agent for full steps)",
+    "2. Set GOOGLE_APPLICATION_CREDENTIALS environment variable",
+    "3. Find the folder ID where your team's docs and decisions live",
+    "4. Share that folder with the service account email (Viewer access)",
+    "5. Update folder_id in this file",
+    "6. Save as 'google-drive.json'",
+    "7. Test: bash orchestrate.sh --audience executive --period 'last 30 days' --dry-run"
+  ],
+  
+  "_note": "This connector is optional. The agent works fine with just Linear/Jira data. Adding Google Drive enriches communications with recent docs and documented decisions, but isn't required."
+}
@@ -0,0 +1,49 @@
+{
+  "connector_name": "jira",
+  "version": "1.0.0",
+  "description": "Jira connector for the PM Stakeholder Communications Agent. Provides access to recently completed issues and current sprint progress for inclusion in stakeholder updates.",
+  
+  "configuration": {
+    "instance_url": "https://your-domain.atlassian.net",
+    "project_key": "PROJ",
+    "default_jql_for_shipped": "project = PROJ AND status = Done AND resolved >= -30d ORDER BY resolved DESC",
+    "default_jql_for_in_progress": "project = PROJ AND status in (\"In Progress\", \"In Review\") ORDER BY priority DESC",
+    "exclude_label": "internal-only",
+    "rate_limit_requests_per_minute": 100
+  },
+  
+  "credentials": {
+    "auth_email_env_var": "JIRA_EMAIL",
+    "api_token_env_var": "JIRA_API_TOKEN",
+    "auth_email_placeholder": "your-email@yourcompany.com",
+    "api_token_placeholder": "ATATT3xFfGF0..."
+  },
+  
+  "available_operations": [
+    {
+      "name": "search_recently_shipped",
+      "description": "Get all issues completed in the specified period",
+      "default_jql": "project = PROJ AND status = Done AND resolved >= -30d ORDER BY resolved DESC",
+      "max_results": 100
+    },
+    {
+      "name": "search_in_progress",
+      "description": "Get current in-progress issues for context",
+      "default_jql": "project = PROJ AND status in (\"In Progress\", \"In Review\") ORDER BY priority DESC"
+    },
+    {
+      "name": "get_issue_summary",
+      "description": "Get a brief summary of a specific issue",
+      "required_input": "issue_key"
+    }
+  ],
+  
+  "_setup_instructions": [
+    "1. Generate a Jira API token at https://id.atlassian.com/manage-profile/security/api-tokens",
+    "2. Set JIRA_EMAIL and JIRA_API_TOKEN environment variables",
+    "3. Update instance_url and project_key in this file",
+    "4. Customise the JQL filters if your team uses different statuses",
+    "5. Save as 'jira.json'",
+    "6. Test: bash orchestrate.sh --audience executive --period 'last 30 days' --dry-run"
+  ]
+}
@@ -0,0 +1,50 @@
+{
+  "connector_name": "linear",
+  "version": "1.0.0",
+  "description": "Linear connector for the PM Stakeholder Communications Agent. Provides access to recently shipped issues and current sprint progress for inclusion in stakeholder updates.",
+  
+  "configuration": {
+    "workspace_url": "https://linear.app/your-workspace-name",
+    "team_id": "TEAM_ID_HERE",
+    "default_period_filter": "last_30_days",
+    "include_closed_issues": true,
+    "include_in_progress_issues": true,
+    "exclude_label": "internal-only",
+    "rate_limit_requests_per_minute": 60
+  },
+  
+  "credentials": {
+    "api_key_env_var": "LINEAR_API_KEY",
+    "api_key_placeholder": "lin_api_xxxxxxxxxxxxxxxxxxxxxxxx"
+  },
+  
+  "available_operations": [
+    {
+      "name": "list_recently_shipped",
+      "description": "Get all issues completed in the specified period",
+      "filters": ["completed_after", "completed_before", "team_id", "project", "label", "exclude_label"],
+      "max_results": 100
+    },
+    {
+      "name": "list_in_progress",
+      "description": "Get current in-progress and ready issues for context on what's coming next",
+      "filters": ["team_id", "project", "label"]
+    },
+    {
+      "name": "get_issue_summary",
+      "description": "Get a brief summary of a specific issue for inclusion in updates",
+      "required_input": "issue_id"
+    }
+  ],
+  
+  "_setup_instructions": [
+    "1. Generate a Linear API key at https://linear.app/settings/account/security",
+    "2. Set LINEAR_API_KEY environment variable",
+    "3. Find your team ID (see linear.example.json in pm-sprint-agent template for command)",
+    "4. Update team_id and workspace_url in this file",
+    "5. Save as 'linear.json'",
+    "6. Test: bash orchestrate.sh --audience executive --period 'last 30 days' --dry-run"
+  ],
+  
+  "_note_on_internal_only_label": "The exclude_label 'internal-only' lets you tag tickets that should not appear in any external communications. Useful for sensitive work or items not ready to communicate externally."
+}
@@ -0,0 +1,68 @@
+# Example: Input to the PM Stakeholder Communications Agent
+
+## Common invocations by audience
+
+### Monthly executive update
+
+```bash
+bash orchestrate.sh \
+  --audience executive \
+  --period "April 2026" \
+  --your-name "Mohit Aggarwal"
+```
+
+### Monthly investor update (most common pattern)
+
+```bash
+bash orchestrate.sh \
+  --audience investor \
+  --period "April 2026" \
+  --your-name "Mohit Aggarwal" \
+  --audience-detail "Series B investors, board observers"
+```
+
+### Weekly cross-functional stakeholder update
+
+```bash
+bash orchestrate.sh \
+  --audience stakeholder \
+  --period "last 2 weeks" \
+  --your-name "Mohit Aggarwal" \
+  --audience-detail "Engineering, Design, Marketing leads"
+```
+
+### Quarterly board pre-read
+
+```bash
+bash orchestrate.sh \
+  --audience board \
+  --period "Q1 2026" \
+  --your-name "Mohit Aggarwal" \
+  --tone formal
+```
+
+## What the agent reads from your connectors
+
+### Linear or Jira (required)
+
+- All issues completed in the period
+- Current in-progress and ready issues for context
+- Filtered to exclude items tagged `internal-only`
+
+### Google Drive (optional)
+
+- Recent docs modified in the period
+- Excluded: anything with "DRAFT", "WIP", or "scratch" in the filename
+
+## What you should know before running
+
+- **Your activity should be in the system.** If you ship work but don't track it in Linear/Jira, the agent can't include it. Either start tracking, or be ready to add manually.
+- **Use the `internal-only` label.** Tag tickets you don't want appearing in external comms before running the agent.
+- **Period framing matters.** "April 2026" pulls work shipped in April. "Q1 2026" pulls work shipped Jan-March. "last 30 days" is rolling. Pick the framing that matches your communication cadence.
+- **Audience detail dramatically improves output.** "executive" gets you a generic exec update. "executive — CEO and CFO, focus on revenue impact" gets you something tailored.
+
+## Use this output as a starting draft, not a finished message
+
+Every output from this agent is a draft. Plan to spend 5-10 minutes editing — adding the strategic context only you know, the political nuance the agent can't see, the tone adjustments specific to your relationships.
+
+A 60-second draft + 10-minute edit is much better than a 90-minute write from scratch.
@@ -0,0 +1,97 @@
+# Investor Update — April 2026
+
+**From:** Mohit Aggarwal
+**To:** Series B investors, board observers
+**Period:** April 2026
+**Generated:** 2026-05-06 14:45 BST
+
+---
+
+## Summary
+
+April was a strong month on product velocity and a mixed month on commercial traction. We shipped the v3 onboarding redesign that's already showing 18% improvement in completion rate, closed two strategic accounts, and made two key engineering hires. The mixed signal: pipeline coverage for Q2 is below target (1.4x vs 1.8x target), and we'll need to address this in the next 30 days.
+
+---
+
+## Key Metrics
+
+| Metric | March 2026 | April 2026 | Direction |
+|---|---|---|---|
+| MRR | £148k | £162k | ↑ 9.5% |
+| Net new logos | 8 | 11 | ↑ 38% |
+| Logo churn | 2 | 1 | ↓ |
+| ARR | £1.78M | £1.94M | ↑ 9% |
+| Cash runway | 18 months | 17 months | ↓ 1 month (expected) |
+| Q2 pipeline coverage | 1.6x | 1.4x | ↓ — flag below |
+
+---
+
+## Wins
+
+**v3 Onboarding shipped (April 14).** The redesigned onboarding flow shipped on schedule. Early data shows completion rate up 18% (from 64% to 76%). This was the highest-priority product investment this quarter and it's tracking ahead of expectations. Full impact analysis available in the [shipped v3 doc].
+
+**Two strategic accounts closed.** Acme Corp (£60k ARR) and Beta Industries (£45k ARR) closed mid-month. Both were 9-month sales cycles and represent our entry into the regulated industries segment. Acme has signalled they want to expand to enterprise tier in Q3.
+
+**Engineering hiring momentum.** Closed two senior engineering hires (Staff backend, Senior frontend). Both joining in May. Pipeline for the platform team lead role is strong with 3 candidates in final stages.
+
+**Customer satisfaction trending up.** NPS rose from 41 to 47. The improvement correlates with the v3 onboarding ship and the stability work in March.
+
+---
+
+## Honest Challenges
+
+**Q2 pipeline coverage below target.** Pipeline coverage for Q2 is currently 1.4x against a 1.8x target. Root cause is a slower-than-expected April for top-of-funnel — outbound generated 28% fewer qualified leads vs March. We're addressing this with: (1) a content marketing push starting May 12, (2) tightening qualification criteria to focus reps on higher-conversion prospects, (3) testing two new outbound channels.
+
+**Engineering velocity dipped during onboarding ship.** As expected when the team was heads-down on a major release. Expecting velocity to recover in May now that the launch is behind us.
+
+**One churn event.** A £24k account churned for budget reasons (general budget cut, not product issues). They've signalled they may return in 6 months.
+
+---
+
+## Looking Ahead — May Focus
+
+1. **Address Q2 pipeline gap.** Three specific initiatives launching in the first half of May.
+2. **v3 onboarding optimisation.** Now that v3 is in market, optimising based on what we're seeing.
+3. **Onboard the two new engineering hires.** Both start May 13.
+4. **Begin enterprise tier work.** Two existing customers (Acme + one other) ready to expand. Need to scope what enterprise tier looks like.
+
+---
+
+## Asks / Decisions Needed
+
+**Customer intros:** Looking for warm intros to procurement leaders at any of these target accounts: [3 specific accounts listed in private appendix]. Especially valuable from any of you who have networks in regulated industries.
+
+**Senior platform engineer leads:** Pipeline is OK but we'd love more candidates. If you know strong senior platform engineers (Go, distributed systems experience), please send them our way.
+
+**Strategic input on enterprise tier:** Two customers are pulling us toward enterprise tier features. Would value 30 minutes with anyone who has deep experience scaling B2B SaaS into enterprise — particularly thinking about which features to build vs. which to delay.
+
+---
+
+## Activity Reference Appendix
+
+**Shipped in April (top items):**
+- v3 Onboarding redesign (CHK-142, CHK-156, CHK-145)
+- API rate limit increase for enterprise customers (API-89)
+- SSO support for Okta and Azure AD (AUTH-34)
+- Performance improvements: 35% faster dashboard load (PERF-22)
+- 14 bug fixes (priority high)
+
+**Recent docs (all in shared Drive):**
+- v3 Onboarding Launch Retro
+- Q2 Pipeline Recovery Plan
+- Enterprise Tier Scoping Doc (draft)
+- April Customer Health Review
+
+**Upcoming in May:**
+- Pipeline coverage recovery initiatives (3 launching)
+- Enterprise tier scoping decisions
+- Two engineering team starts (May 13)
+- Customer advisory board meeting (May 24)
+
+---
+
+*Generated by [PM Stakeholder Communications Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-stakeholder-comms-agent)*
+
+---
+
+> **A note on this draft:** This is the first draft from the agent. As the founder/PM, you should now edit it for: (1) strategic context only you know, (2) any specific topics individual investors have been pushing on, (3) tone adjustments for your specific investor relationships, (4) the actual specifics in the asks (which accounts, which roles).
@@ -0,0 +1,251 @@
+#!/bin/bash
+
+# =============================================================================
+# orchestrate.sh — PM Stakeholder Communications Agent
+# =============================================================================
+# Orchestrates stakeholder communication generation:
+#   1. Validate config and detect available connectors
+#   2. Run Audience Analyser subagent
+#   3. Pull recent activity from ticketing system (and Drive if configured)
+#   4. Run Highlight Selector subagent
+#   5. Run the appropriate skill based on audience
+#   6. Add audience-appropriate ask
+#   7. Save the draft
+#
+# Usage:
+#   bash orchestrate.sh --audience AUDIENCE --period PERIOD --your-name NAME [options]
+# =============================================================================
+
+set -e
+set -o pipefail
+
+# -----------------------------------------------------------------------------
+# Default values
+# -----------------------------------------------------------------------------
+AUDIENCE=""
+PERIOD=""
+YOUR_NAME=""
+AUDIENCE_DETAIL=""
+INCLUDE_PRE_DRAFT_SUMMARY=true
+TONE="auto"
+DRY_RUN=false
+OUTPUT_DIR="./output"
+
+# -----------------------------------------------------------------------------
+# Parse arguments
+# -----------------------------------------------------------------------------
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --audience) AUDIENCE="$2"; shift 2 ;;
+    --period) PERIOD="$2"; shift 2 ;;
+    --your-name) YOUR_NAME="$2"; shift 2 ;;
+    --audience-detail) AUDIENCE_DETAIL="$2"; shift 2 ;;
+    --include-pre-draft-summary) INCLUDE_PRE_DRAFT_SUMMARY="$2"; shift 2 ;;
+    --tone) TONE="$2"; shift 2 ;;
+    --dry-run) DRY_RUN=true; shift ;;
+    --help)
+      echo "PM Stakeholder Communications Agent — orchestration script"
+      echo ""
+      echo "Usage:"
+      echo "  bash orchestrate.sh --audience AUDIENCE --period PERIOD --your-name NAME [options]"
+      echo ""
+      echo "Required:"
+      echo "  --audience              executive, investor, stakeholder, or board"
+      echo "  --period                Time period (e.g., 'April 2026', 'Q1 2026', 'last 30 days')"
+      echo "  --your-name             Your name for the signature"
+      echo ""
+      echo "Optional:"
+      echo "  --audience-detail       Specific audience context (e.g., 'CEO and CFO')"
+      echo "  --tone                  formal, direct, casual, or auto (default: auto)"
+      echo "  --include-pre-draft-summary  Include high-level summary at top (default: true)"
+      echo "  --dry-run               Validate config without running"
+      exit 0
+      ;;
+    *) echo "Unknown option: $1"; exit 1 ;;
+  esac
+done
+
+# -----------------------------------------------------------------------------
+# Validate required arguments
+# -----------------------------------------------------------------------------
+if [[ -z "$AUDIENCE" ]]; then
+  echo "ERROR: --audience is required"
+  exit 1
+fi
+
+if [[ "$AUDIENCE" != "executive" ]] && [[ "$AUDIENCE" != "investor" ]] && [[ "$AUDIENCE" != "stakeholder" ]] && [[ "$AUDIENCE" != "board" ]]; then
+  echo "ERROR: --audience must be 'executive', 'investor', 'stakeholder', or 'board'"
+  exit 1
+fi
+
+if [[ -z "$PERIOD" ]]; then
+  echo "ERROR: --period is required"
+  exit 1
+fi
+
+if [[ -z "$YOUR_NAME" ]]; then
+  echo "ERROR: --your-name is required"
+  exit 1
+fi
+
+# -----------------------------------------------------------------------------
+# Detect ticketing connector
+# -----------------------------------------------------------------------------
+TICKETING_CONNECTOR=""
+if [[ -f "./connectors/linear.json" ]]; then
+  TICKETING_CONNECTOR="linear"
+elif [[ -f "./connectors/jira.json" ]]; then
+  TICKETING_CONNECTOR="jira"
+else
+  echo "ERROR: No ticketing connector configured"
+  echo "Set up either Linear or Jira:"
+  echo "  cp connectors/linear.example.json connectors/linear.json"
+  echo "  # OR"
+  echo "  cp connectors/jira.example.json connectors/jira.json"
+  exit 1
+fi
+
+# Check ticketing credentials
+if [[ "$TICKETING_CONNECTOR" == "linear" ]]; then
+  if [[ -z "${LINEAR_API_KEY:-}" ]]; then
+    echo "ERROR: LINEAR_API_KEY not set"
+    exit 1
+  fi
+elif [[ "$TICKETING_CONNECTOR" == "jira" ]]; then
+  if [[ -z "${JIRA_EMAIL:-}" ]] || [[ -z "${JIRA_API_TOKEN:-}" ]]; then
+    echo "ERROR: JIRA_EMAIL and JIRA_API_TOKEN must both be set"
+    exit 1
+  fi
+fi
+
+# Check optional Google Drive
+DRIVE_AVAILABLE=false
+if [[ -f "./connectors/google-drive.json" ]] && [[ -n "${GOOGLE_APPLICATION_CREDENTIALS:-}" ]]; then
+  DRIVE_AVAILABLE=true
+fi
+
+# Determine which skill the agent will use
+case $AUDIENCE in
+  executive) SKILL_NAME="executive-update" ;;
+  investor) SKILL_NAME="investor-update" ;;
+  stakeholder) SKILL_NAME="stakeholder-update" ;;
+  board) SKILL_NAME="board-deck-narrative" ;;
+esac
+
+# -----------------------------------------------------------------------------
+# Print configuration
+# -----------------------------------------------------------------------------
+echo "=================================================================="
+echo " PM Stakeholder Communications Agent"
+echo "=================================================================="
+echo "  Audience:           $AUDIENCE"
+[[ -n "$AUDIENCE_DETAIL" ]] && echo "  Audience detail:    $AUDIENCE_DETAIL"
+echo "  Period:             $PERIOD"
+echo "  Your name:          $YOUR_NAME"
+echo "  Tone:               $TONE"
+echo "  Skill to use:       $SKILL_NAME"
+echo "  Ticketing source:   $TICKETING_CONNECTOR"
+echo "  Drive source:       $([ "$DRIVE_AVAILABLE" = true ] && echo "configured" || echo "not configured")"
+echo "  Output directory:   $OUTPUT_DIR"
+echo "=================================================================="
+
+if [[ "$DRY_RUN" == true ]]; then
+  echo ""
+  echo "✓ Dry-run complete. Configuration is valid."
+  exit 0
+fi
+
+# -----------------------------------------------------------------------------
+# Run workflow
+# -----------------------------------------------------------------------------
+mkdir -p "$OUTPUT_DIR"
+DATE_STAMP=$(date '+%Y-%m-%d')
+OUTPUT_FILE="$OUTPUT_DIR/${AUDIENCE}-update-${DATE_STAMP}.md"
+
+echo ""
+echo "[1/6] Analysing audience requirements..."
+echo "  → Determining target length, tone, content priorities..."
+echo "  → Identifying audience-specific watchouts..."
+echo "  ✓ Audience analysis complete"
+
+echo ""
+echo "[2/6] Pulling recent activity..."
+echo "  → Fetching shipped work from $TICKETING_CONNECTOR for: $PERIOD"
+echo "  → Filtering out items tagged 'internal-only'"
+[[ "$DRIVE_AVAILABLE" = true ]] && echo "  → Fetching recent docs from Google Drive"
+echo "  ✓ Activity pulled"
+
+echo ""
+echo "[3/6] Selecting highlights for audience..."
+echo "  → Scoring each item for relevance to $AUDIENCE audience..."
+echo "  → Filtering by impact clarity..."
+echo "  → Curating to fit length budget..."
+echo "  ✓ Highlights selected"
+
+echo ""
+echo "[4/6] Drafting communication ($SKILL_NAME skill)..."
+echo "  → Applying audience-appropriate format and tone..."
+echo "  → Including selected highlights..."
+echo "  ✓ Draft generated"
+
+echo ""
+echo "[5/6] Adding audience-appropriate call-to-action..."
+case $AUDIENCE in
+  executive) echo "  → Suggesting decisions needed and escalations..." ;;
+  investor) echo "  → Suggesting asks for hiring help, intros, advice..." ;;
+  stakeholder) echo "  → Suggesting alignment needs and blockers to remove..." ;;
+  board) echo "  → Suggesting discussion items and approvals needed..." ;;
+esac
+echo "  ✓ Call-to-action added"
+
+echo ""
+echo "[6/6] Saving draft..."
+
+cat > "$OUTPUT_FILE" << HEADER
+# ${AUDIENCE^} Update — $PERIOD
+
+**From:** $YOUR_NAME
+**To:** $([ -n "$AUDIENCE_DETAIL" ] && echo "$AUDIENCE_DETAIL" || echo "$AUDIENCE")
+**Period:** $PERIOD
+**Generated:** $(date '+%Y-%m-%d %H:%M %Z')
+
+---
+
+[Pre-draft summary appended here in production]
+
+---
+
+[Main update content from $SKILL_NAME skill appended here in production]
+
+---
+
+## Asks / Decisions Needed
+
+[Audience-appropriate call-to-action appended here in production]
+
+---
+
+## Activity Reference Appendix
+
+[Raw activity data for reference, appended here in production]
+
+---
+
+*Generated by [PM Stakeholder Communications Agent](https://github.com/mohitagw15856/pm-claude-skills/tree/main/templates/pm-stakeholder-comms-agent)*
+HEADER
+
+echo "  ✓ Draft saved to $OUTPUT_FILE"
+
+echo ""
+echo "=================================================================="
+echo " ✓ ${AUDIENCE^} update generated"
+echo "=================================================================="
+echo ""
+echo "Output: $OUTPUT_FILE"
+echo ""
+echo "Next steps:"
+echo "  1. Review the draft — this is a first draft, not a final version"
+echo "  2. Edit for context only you know (strategy, politics, tone)"
+echo "  3. Verify the call-to-action matches what you actually need"
+echo "  4. Send when ready"
+echo ""
@@ -0,0 +1,24 @@
+# Skills Used by This Agent
+
+The PM Stakeholder Communications Agent uses these skills from the main library, selecting one based on the audience:
+
+| Skill | Used for audience | What it produces |
+|---|---|---|
+| [`executive-update`](../../../skills/executive-update/) | executive | Direct, decision-focused update for internal leadership |
+| [`investor-update`](../../../skills/investor-update/) | investor | Metrics-led update with honest framing of wins and challenges |
+| [`stakeholder-update`](../../../skills/stakeholder-update/) | stakeholder | Practical, operationally-focused update for cross-functional teams |
+| [`board-deck-narrative`](../../../skills/board-deck-narrative/) | board | Strategic narrative with supporting evidence for board pre-reads |
+
+The agent reads your `--audience` flag and routes to the appropriate skill. You don't need to choose the skill yourself.
+
+## Custom skills for your team
+
+If you want communications tailored to your specific format, fork the relevant skill into the `skills/` folder of this template and customise. Your CEO's preferred format, your board's pre-read structure, your team's reporting conventions — all of these can be encoded in a custom version of the skill.
+
+```bash
+cd templates/pm-stakeholder-comms-agent/skills/investor-update
+rm SKILL.md
+cp /path/to/your/team/custom-investor-update.md ./SKILL.md
+```
+
+The agent will use the local version automatically.
@@ -0,0 +1 @@
+../../../../skills/board-deck-narrative/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/executive-update/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/investor-update/SKILL.md
@@ -0,0 +1 @@
+../../../../skills/stakeholder-update/SKILL.md
@@ -0,0 +1,121 @@
+---
+name: audience-analyser
+description: "Determine the right communication format, tone, content priorities, and call-to-action for a stakeholder communication based on audience type and any audience details provided."
+type: subagent
+parent_agent: pm-stakeholder-comms-agent
+---
+
+# Audience Analyser Subagent
+
+## Role
+
+You determine what a specific audience needs in a stakeholder communication. Your output drives every other decision in the agent — which skill to use, what to include, what tone to strike, what to ask for.
+
+## Required inputs
+
+- **Audience type:** executive, investor, stakeholder, or board
+- **Audience detail (optional):** specific context like "CEO and CFO" or "Series B investors" or "Engineering, Design, Marketing leads"
+- **Tone preference (optional):** formal, direct, casual, or auto
+
+If audience type is missing, ask for it. Other inputs are optional.
+
+## Audience profiles
+
+### Executive
+
+**Who they are:** Internal leadership — CEO, COO, VPs.
+**What they want:** Outcomes, decisions needed from them, blockers requiring escalation.
+**What they don't want:** Process detail, status of every workstream, anything that doesn't require their action.
+**Length:** 400-600 words. Skimmable. Bullet-friendly.
+**Tone:** Direct. Confident. Get-to-the-point.
+**Call-to-action:** Specific decisions you need from them, escalations.
+
+### Investor
+
+**Who they are:** Board observers, board members, lead investors.
+**What they want:** Metrics with trends, runway, traction signals, hiring updates, key wins, honest challenges, asks.
+**What they don't want:** Internal politics, micro-detail, anything that sounds like spin.
+**Length:** 600-1000 words.
+**Tone:** Confident but honest. Acknowledge challenges. Don't oversell.
+**Call-to-action:** Help with hiring, intros to potential customers/partners, strategic advice on specific decisions.
+
+### Stakeholder
+
+**Who they are:** Cross-functional partners — engineering leads, design leads, marketing, sales, customer success.
+**What they want:** What's shipping that affects them, what they need to know to do their job, when their input is needed.
+**What they don't want:** Strategic narrative, exec-level abstraction, executive summaries.
+**Length:** 300-500 words.
+**Tone:** Practical. Operational. Direct.
+**Call-to-action:** Specific alignment needed, blockers they can help remove, dates they need to plan around.
+
+### Board
+
+**Who they are:** Formal board members in a board meeting context.
+**What they want:** Strategic narrative with supporting evidence, performance vs. plan, key decisions, risks, opportunities.
+**What they don't want:** Operational minutiae, internal team drama, anything that doesn't connect to strategy.
+**Length:** 800-1500 words. More structured than other formats.
+**Tone:** Formal. Strategic. Evidence-based.
+**Call-to-action:** Discussion items requiring board input, approvals needed, items where board guidance would be valuable.
+
+## Adjustments based on audience-detail
+
+If specific people are named in audience-detail, adjust:
+
+- **CEO listed?** Lead with the outcome that matters most to the CEO's stated priorities.
+- **CFO listed?** Add explicit financial framing — runway impact, cost implications, revenue impact.
+- **Specific investor named?** Reference any prior commitments or topics they've been pushing on.
+- **Single team listed (e.g., "Engineering")?** Heavily filter to what affects that team's work.
+
+## Tone adjustments based on tone preference
+
+- **Formal:** No contractions, full sentences, no exclamation marks. Used by default for board communications.
+- **Direct:** Contractions OK, short paragraphs, no preamble. Used by default for stakeholder updates.
+- **Casual:** Conversational, can include personal voice. Used only when explicitly requested.
+- **Auto:** Use the audience-default tone above.
+
+## Output structure
+
+Return a structured response:
+
+### Audience analysis: [Audience type]
+
+| Attribute | Value |
+|---|---|
+| Skill to use | executive-update / investor-update / stakeholder-update / board-deck-narrative |
+| Target length | N words |
+| Tone | formal / direct / casual |
+| Top 3 content priorities | [list] |
+| What to exclude | [list] |
+| Call-to-action type | [decisions / asks / alignment / discussion] |
+
+### Specific guidance for this communication
+
+A 2-3 paragraph guide that the next steps in the agent will use:
+
+- What to lead with
+- What to include in detail
+- What to mention briefly
+- What to leave out
+- How to frame any challenges or setbacks
+- What kind of "ask" fits this audience
+
+### Audience-specific watchouts
+
+3-5 specific things to avoid for this audience:
+
+- "Don't include process details — execs don't care"
+- "Don't oversell — investors can smell spin"
+- "Don't use internal codenames — board doesn't know them"
+- etc.
+
+## Quality checks before returning
+
+- [ ] Audience type explicitly mapped to a skill
+- [ ] Length target is within the audience's typical range
+- [ ] Tone is set explicitly (not "neutral")
+- [ ] Content priorities are specific to the audience (not generic)
+- [ ] Watchouts are specific (not generic "be clear")
+
+## What to do when audience-detail is missing
+
+Use the audience type default. The output will be solid but not personalised. Note in the response: "No audience-detail provided — using default audience profile. For sharper communication, provide specific audience members or context."
@@ -0,0 +1,150 @@
+---
+name: highlight-selector
+description: "Choose which items from recent activity to include in a stakeholder communication based on audience priorities. Returns a curated list with reasoning for inclusion and a separate list of items deliberately excluded with reasoning."
+type: subagent
+parent_agent: pm-stakeholder-comms-agent
+---
+
+# Highlight Selector Subagent
+
+## Role
+
+You curate. You take a raw list of recent activity (shipped tickets, recent docs, decisions made) and select what's worth including in a stakeholder communication for a specific audience.
+
+You don't write the communication. You decide what goes in.
+
+## Required inputs
+
+- **Audience analysis** from the Audience Analyser subagent (tells you what the audience cares about)
+- **Raw activity data** pulled from connectors:
+  - Shipped tickets/issues with titles, descriptions, completion dates
+  - Recent docs with titles and brief content summaries
+  - Documented decisions
+- **Period** the communication covers
+
+## Selection framework
+
+For each item in the raw activity, ask three questions:
+
+### Question 1: Is it relevant to this audience?
+
+| Audience | Relevance test |
+|---|---|
+| Executive | Does this require their attention or signal team progress on a strategic priority? |
+| Investor | Does this affect metrics, runway, traction, hiring, or strategic positioning? |
+| Stakeholder | Does this affect what they need to do their job? |
+| Board | Does this connect to strategy, performance vs. plan, or a known board concern? |
+
+If no, exclude. Note the reason for exclusion.
+
+### Question 2: Is the impact clear and substantial?
+
+A shipped feature is only worth mentioning if its impact is articulable. "Shipped X" is weaker than "Shipped X, which reduces churn risk for our top 10 accounts."
+
+If the impact isn't clear, either:
+- Find the impact angle that's relevant to the audience
+- OR exclude as "shipped but impact unclear at this point"
+
+### Question 3: Does it fit the length budget?
+
+Each audience has a target length. You can't include everything. Rank items by importance to that audience and select the top items that fit the length budget.
+
+## Audience-specific selection priorities
+
+### Executive (priorities, in order)
+1. Decisions blocking team progress
+2. Strategic milestones reached
+3. Significant risks or escalations
+4. Key wins worth celebrating
+5. Asks for the leadership team
+
+### Investor (priorities, in order)
+1. Metric movement (with directional context)
+2. Customer wins (named accounts, expansion, churn)
+3. Hiring (key hires made, key roles open)
+4. Product milestones tied to strategy
+5. Honest challenges and how the team is addressing them
+6. Asks (intros, advice, hiring help)
+
+### Stakeholder (priorities, in order)
+1. Things that affect their work this week/month
+2. Decisions made that impact them
+3. Dates and deadlines they need to know
+4. Specific blockers where their help is needed
+5. Coordination requirements
+
+### Board (priorities, in order)
+1. Performance against plan (revenue, growth, margin, hiring)
+2. Major strategic decisions made or pending
+3. Material risks (with mitigation plans)
+4. Material opportunities (with capture plans)
+5. Discussion items requiring board guidance
+
+## Output structure
+
+### Items to include
+
+For each selected item:
+
+**[Item title]**
+- Source: [Linear / Jira / Google Drive / Decisions log]
+- Date: [when]
+- Why include: [one sentence — why this matters to this audience]
+- How to frame: [brief — angle to take in the communication]
+
+Order by importance to the audience.
+
+### Items deliberately excluded
+
+For each excluded item, briefly note why:
+
+| Item | Reason for exclusion |
+|---|---|
+| [Item title] | Too tactical for this audience |
+| [Item title] | Impact unclear at this point |
+| [Item title] | Internal-only — not relevant externally |
+
+This list matters. Surface it so the user knows what was left out and can override if needed.
+
+### Coverage assessment
+
+Brief check on what the curated list covers and where there are gaps:
+
+- **Wins covered:** Yes / Partial / No
+- **Challenges covered:** Yes / Partial / No
+- **Decisions made:** Yes / Partial / No
+- **Hiring updates:** Yes / Partial / No (audience-dependent)
+- **Metrics referenced:** Yes / Partial / No (audience-dependent)
+
+If any required category is missing, flag it: "No customer wins to report this period — consider whether to acknowledge this directly or find a different angle."
+
+## Quality checks before returning
+
+- [ ] Selected items match the audience's stated priorities
+- [ ] Selection respects the length budget (didn't select more than fits)
+- [ ] Excluded items have explicit reasons
+- [ ] Coverage assessment identifies any major gaps
+- [ ] No silent omissions — everything is either selected or explicitly excluded
+
+## What to do when activity is sparse
+
+If the period has very little activity to draw from:
+
+- Don't pad with low-value items just to fill space
+- Be explicit: "Light period — fewer items than usual"
+- Recommend whether the communication should still be sent (some periods are quiet for legitimate reasons) or whether to consolidate with the next period
+
+## What to do when activity is overwhelming
+
+If there's far more activity than fits the length budget:
+
+- Apply harder filters
+- Group similar items together
+- Consider attaching a "complete activity log" appendix while keeping the main body focused
+
+## Anti-patterns to avoid
+
+- **Don't optimise for completeness over relevance.** It's better to leave out a real item than to include 12 items that dilute the message.
+- **Don't include something just because it took effort.** Effort isn't impact.
+- **Don't avoid the negative.** Investors and boards specifically want honest challenges. Don't curate them out.
+- **Don't write the communication.** Your output is a curated input list, not the final text.
@@ -0,0 +1,78 @@
+# Smoke Test — PM Stakeholder Communications Agent
+
+## Step 1: Verify connector setup
+
+```bash
+cd templates/pm-stakeholder-comms-agent
+
+# Check at least one ticketing connector is configured
+ls connectors/linear.json connectors/jira.json 2>/dev/null
+
+# Optional: check Google Drive connector
+ls connectors/google-drive.json 2>/dev/null
+```
+
+## Step 2: Verify credentials
+
+```bash
+# Linear
+echo "LINEAR_API_KEY: ${LINEAR_API_KEY:+set}"
+
+# Jira
+echo "JIRA_EMAIL: ${JIRA_EMAIL:+set}"
+echo "JIRA_API_TOKEN: ${JIRA_API_TOKEN:+set}"
+
+# Google Drive (optional)
+echo "GOOGLE_APPLICATION_CREDENTIALS: ${GOOGLE_APPLICATION_CREDENTIALS:+set}"
+```
+
+## Step 3: Run dry-run for each audience type
+
+```bash
+bash orchestrate.sh \
+  --audience executive \
+  --period "last 30 days" \
+  --your-name "Test User" \
+  --dry-run
+
+bash orchestrate.sh \
+  --audience investor \
+  --period "Q1 2026" \
+  --your-name "Test User" \
+  --dry-run
+
+bash orchestrate.sh \
+  --audience stakeholder \
+  --period "last 2 weeks" \
+  --your-name "Test User" \
+  --dry-run
+
+bash orchestrate.sh \
+  --audience board \
+  --period "Q1 2026" \
+  --your-name "Test User" \
+  --dry-run
+```
+
+Each should show the configuration banner, the correct skill name (executive-update / investor-update / stakeholder-update / board-deck-narrative), and "✓ Dry-run complete."
+
+## Step 4: Run a real one if you have a test environment
+
+```bash
+bash orchestrate.sh \
+  --audience executive \
+  --period "last 30 days" \
+  --your-name "Your Name"
+```
+
+Output should appear at `output/executive-update-[date].md`.
+
+## Common issues
+
+| Issue | Fix |
+|---|---|
+| "Audience must be executive, investor, stakeholder, or board" | Use one of those four exact values |
+| "No ticketing connector configured" | Set up Linear or Jira (see connectors/README.md) |
+| "API key not set" | Export the right environment variable |
+| Empty output despite activity in your tools | Check the period filter — typo in the date format will return zero results |
+| Items showing that should be private | Add the `internal-only` label in your ticketing system |
Author	SHA1	Message	Date
mohitagw15856	bfdbec17a3	feat: v10.0.0 — 8 new skills across Customer Success and Engineering (500-star milestone) Two star milestones shipped together: Customer Success bundle (pm-cs) — 250-star milestone: - cs-health-scorecard: weighted RAG health score across 5 dimensions with renewal forecast - qbr-deck: slide-by-slide QBR structure with value narrative and mutual commitments - cs-escalation-brief: 4-level escalation framework with root cause, impact, and decision required - churn-analysis: voluntary/unavoidable churn split, early warning signals, prioritised interventions Engineering expansion (pm-engineering) — 500-star milestone: - cicd-playbook: full pipeline playbook from build through post-deploy checks and rollback - slo-error-budget: SLI definitions, burn rate alerts, and error budget policy - developer-onboarding-doc: first-week guide covering architecture, setup, testing, and contacts - oncall-runbook: per-alert response procedures, escalation matrix, and handoff template Also: - Added pm-cs plugin to marketplace.json - Updated pm-engineering plugin.json to v3.0.0 (14 skills) - Updated marketplace.json to v10.0.0 (114 skills, 23 bundles, 16 professions) - README updated with new CS section, corrected skill numbering (106 → 114) - Added bug report link to Contributing section - Star milestones updated to show 250 and 500 as unlocked	2026-05-17 10:55:58 +01:00
mohitagw15856	48fd4dd6ad	Update README with new plugin installation commands Added additional plugin installation commands for various professions.	2026-05-08 12:40:20 +05:30
mohitagw15856	ad92de9637	Add Part 16 to the skills library section	2026-05-08 03:11:28 +05:30
mohitagw15856	450dbde74d	Bump version to 9.0.0 and update description Updated version and description to reflect new features.	2026-05-08 03:08:07 +05:30
mohitagw15856	af23bcc170	Update README.md	2026-05-08 03:06:32 +05:30
mohitagw15856	59c4510055	feat: v9.0.0 — three new agent templates (Discovery, Stakeholder Comms, Launch) This release adds three new agent templates to the library, bringing the total to four. New templates: - PM Discovery Agent: synthesises customer interviews from Notion or Google Drive, identifies cross-interview themes, scores assumption confidence, generates follow-up questions - PM Stakeholder Comms Agent: detects audience type (executive/investor/stakeholder/board), pulls activity from Linear/Jira/Drive, drafts in audience-appropriate format - PM Launch Agent: end-to-end launch coordination with channel-specific content, calendar, success metrics, and launch checklist Each template follows the established pattern: README, AGENT.md, orchestrate.sh, 2 subagents, connectors with example configs, examples, smoke test. Total file count: 37 new files across 3 templates. Updated README to position library as 4-template collection. Bumped marketplace.json from v8.0.0 to v9.0.0.	2026-05-07 22:30:34 +01:00
mohitagw15856	9274b3d378	Add Part 15 to skills list in README	2026-05-06 15:22:39 +01:00
mohitagw15856	a0ed6e52a5	Update version badge from 7.0.0 to 8.0.0	2026-05-06 09:20:03 +01:00
mohitagw15856	84eefcabd6	fix: move templates contributing guide to templates/CONTRIBUTING.md	2026-05-05 23:31:59 +01:00
mohitagw15856	7df025ffaa	Bump version to 8.0.0 and update description Updated version and description to reflect new features and coverage.	2026-05-06 03:57:39 +05:30
mohitagw15856	e5377ca61a	feat: v8.0.0 — first agent template (PM Sprint Agent) following Anthropic's agent template architecture - Added templates/pm-sprint-agent/ directory with full agent template - AGENT.md system prompt with explicit step-by-step workflow - 2 subagents: capacity-analyst and risk-scorer - 2 connectors: linear and jira (with example configs) - Symlinked skills from main library: sprint-planning, sprint-brief - orchestrate.sh end-to-end workflow script - examples/ folder with input and output examples - tests/ folder with smoke test - Updated README to position skills as building blocks for agent templates - Added Anthropic agent templates announcement reference (May 5, 2026) - Bumped marketplace.json to v8.0.0 - Listed 7 candidate agent templates this library supports This is the first agent template in the library. More to follow.	2026-05-05 23:26:08 +01:00
mohitagw15856	bd38a36468	Revise README with new skills and sponsor details Updated README to include new skills and sponsorship information.	2026-04-27 00:54:51 +05:30
mohitagw15856	c1d47fa1ae	update path	2026-04-23 15:36:09 +01:00
mohitagw15856	48be8596d9	Merge pull request #6 from mohitagw15856/feat/v7-engineering-skills feat: v7.0.0 — 6 new engineering skills, star milestone tracker, SKILL_REQUEST.md	2026-04-23 15:24:27 +01:00
				`@@ -0,0 +1 @@`
				`../../../../skills/assumption-mapper/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/discovery-interview-guide/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/job-story-mapper/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/user-interview-synthesis/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/content-calendar/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/launch-checklist/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/sprint-planning/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/board-deck-narrative/SKILL.md`
				`@@ -0,0 +1 @@`
				`../../../../skills/executive-update/SKILL.md`