v1.0

pm-execution/.claude-plugin/plugin.json

@@ -0,0 +1,25 @@
+{
+  "name": "pm-execution",
+  "version": "1.0.0",
+  "description": "Execution and product management skills: PRDs, OKRs, roadmaps, sprints, pre-mortems, stakeholder maps, user stories, prioritization frameworks, and more.",
+  "author": {
+    "name": "Paweł Huryn",
+    "email": "pawel@productcompass.pm",
+    "url": "https://www.productcompass.pm"
+  },
+  "keywords": [
+    "product-management",
+    "execution",
+    "prd",
+    "okrs",
+    "roadmap",
+    "sprint",
+    "pre-mortem",
+    "user-stories",
+    "backlog",
+    "prioritization",
+    "agile"
+  ],
+  "homepage": "https://www.productcompass.pm",
+  "license": "MIT"
+}

pm-execution/README.md

@@ -0,0 +1,58 @@
+# pm-execution
+
+Execution and product management skills: PRDs, OKRs, roadmaps, sprints, pre-mortems, stakeholder maps, user stories, prioritization frameworks, and more.
+
+## Overview
+
+This plugin provides 15 skills and 10 commands for product managers.
+
+## Skills
+
+- **brainstorm-okrs** — Brainstorm team-level OKRs aligned with company objectives.
+- **create-prd** — Create a Product Requirements Document using a comprehensive 8-section template.
+- **dummy-dataset** — Generate realistic dummy datasets for testing with customizable columns, constraints, and output formats.
+- **job-stories** — Create job stories using the 'When [situation], I want to [motivation], so I can [outcome]' format.
+- **outcome-roadmap** — Transform an output-focused roadmap into an outcome-focused one.
+- **pre-mortem** — Run a pre-mortem analysis on a PRD.
+- **prioritization-frameworks** — Reference guide to 9 prioritization frameworks with formulas, when-to-use guidance, and templates.
+- **release-notes** — Generate user-facing release notes from tickets, PRDs, or changelogs.
+- **retro** — Facilitate a structured sprint retrospective.
+- **sprint-plan** — Plan a sprint with capacity estimation, story selection, dependency mapping, and risk identification.
+- **stakeholder-map** — Build a stakeholder map using a power/interest grid with communication strategies.
+- **summarize-meeting** — Summarize a meeting transcript into structured notes with decisions and action items.
+- **test-scenarios** — Create comprehensive test scenarios from user stories.
+- **user-stories** — Create user stories following the 3 C's and INVEST criteria.
+- **wwas** — Create product backlog items in Why-What-Acceptance format.
+
+## Commands
+
+- `/pm-execution:generate-data` — Generate realistic dummy datasets for testing
+- `/pm-execution:meeting-notes` — Summarize a meeting transcript into structured notes with decisions, action items, and follow-ups
+- `/pm-execution:plan-okrs` — Brainstorm team-level OKRs aligned with company objectives
+- `/pm-execution:pre-mortem` — Run a pre-mortem risk analysis on a PRD, launch plan, or feature
+- `/pm-execution:sprint` — Sprint lifecycle — plan a sprint, run a retrospective, or generate release notes
+- `/pm-execution:stakeholder-map` — Map stakeholders on a Power × Interest grid and create a tailored communication plan
+- `/pm-execution:test-scenarios` — Generate comprehensive test scenarios from user stories or feature specs
+- `/pm-execution:transform-roadmap` — Convert a feature-based roadmap into an outcome-focused roadmap
+- `/pm-execution:write-prd` — Create a comprehensive Product Requirements Document from a feature idea or problem statement
+- `/pm-execution:write-stories` — Break a feature into backlog items — user stories, job stories, or WWA format
+
+## Installation
+
+```bash
+/install pm-execution
+```
+
+Or use directly:
+
+```bash
+cc --plugin-dir /path/to/pm-execution
+```
+
+## Author
+
+Paweł Huryn — [The Product Compass Newsletter](https://www.productcompass.pm)
+
+## License
+
+MIT

pm-execution/commands/generate-data.md

@@ -0,0 +1,82 @@
+---
+description: Generate realistic dummy datasets for testing — CSV, JSON, SQL inserts, or Python scripts
+argument-hint: "<description of the data you need>"
+---
+
+# /generate-data -- Test Data Generator
+
+Create realistic dummy datasets for development, testing, demos, or prototyping. Outputs as ready-to-use files in your preferred format.
+
+## Invocation
+
+```
+/generate-data 1000 users with names, emails, plan tier, signup date, and activity score
+/generate-data E-commerce orders dataset: products, customers, timestamps, amounts
+/generate-data Sample data matching this schema: [paste table definition]
+```
+
+## Workflow
+
+### Step 1: Define the Dataset
+
+Understand:
+- What entities? (users, orders, events, products, etc.)
+- What columns? (with data types and constraints)
+- How many rows?
+- Any relationships between tables?
+- Any specific distributions? (e.g., "80% should be on the free plan")
+- Any realistic constraints? (emails should be unique, dates should be chronological)
+
+### Step 2: Generate the Data
+
+Apply the **dummy-dataset** skill:
+
+- Create a Python script that generates the dataset
+- Use realistic-looking data (not random strings): proper names, valid email formats, real-seeming dates
+- Respect constraints: unique IDs, foreign key relationships, chronological ordering
+- Apply specified distributions
+- Execute the script and produce the output file
+
+### Step 3: Deliver
+
+Output in the requested format (or ask):
+- **CSV**: Most common, works everywhere
+- **JSON**: For API testing or frontend development
+- **SQL INSERT**: For populating test databases
+- **Python script**: For reproducible generation (user can tweak and re-run)
+
+```
+## Generated Dataset: [Description]
+
+**Rows**: [count]
+**Columns**: [list]
+**Format**: [CSV / JSON / SQL / Python]
+
+### Schema
+| Column | Type | Constraints | Distribution |
+|--------|------|-----------|-------------|
+
+### Sample (first 5 rows)
+[Preview of the data]
+
+### Files
+- [data file]
+- [generator script, if applicable]
+```
+
+Save data file and generator script to the user's workspace.
+
+### Step 4: Offer Follow-ups
+
+- "Want me to **add more columns** or **increase the dataset size**?"
+- "Should I **create related tables** (e.g., orders for these users)?"
+- "Want me to **write test scenarios** that use this data?"
+- "Should I **create SQL queries** to analyze this dataset?"
+
+## Notes
+
+- Always provide the generator script so the user can regenerate with different parameters
+- For demo datasets, make the data tell a story (e.g., seasonal trends, a retention problem, a power user segment)
+- Respect realistic cardinality: 1000 users don't have 1000 unique cities
+- For financial data, use realistic price distributions — not uniform random
+- Never include real personal data — all names, emails, and identifiers must be fake

pm-execution/commands/meeting-notes.md

@@ -0,0 +1,89 @@
+---
+description: Summarize a meeting transcript into structured notes with decisions, action items, and follow-ups
+argument-hint: "<transcript or meeting notes>"
+---
+
+# /meeting-notes -- Meeting Summary
+
+Transform a raw meeting transcript or rough notes into clear, structured meeting minutes with decisions captured and action items assigned.
+
+## Invocation
+
+```
+/meeting-notes [paste transcript]
+/meeting-notes [upload transcript file, audio summary, or notes]
+```
+
+## Workflow
+
+### Step 1: Accept the Transcript
+
+Accept in any format:
+- Full transcript (from Otter, Fireflies, Google Meet, Zoom, etc.)
+- Rough notes taken during the meeting
+- Audio summary or meeting recap from a transcription tool
+- Multiple inputs (e.g., transcript + the user's own notes)
+
+If the input is sparse, work with what's available and flag gaps.
+
+### Step 2: Extract and Structure
+
+Apply the **summarize-meeting** skill:
+
+Parse the content to identify:
+- **Participants**: Who was present (from introductions, speaker labels, or mentions)
+- **Topics discussed**: Major agenda items or conversation threads
+- **Decisions made**: Explicit agreements or conclusions reached
+- **Action items**: Tasks assigned, with owner and deadline if mentioned
+- **Open questions**: Unresolved items that need follow-up
+- **Key quotes**: Important statements worth preserving verbatim
+- **Context**: Meeting type, project, and background
+
+### Step 3: Generate Meeting Summary
+
+```
+## Meeting Summary
+
+**Date**: [date if known]
+**Participants**: [names/roles]
+**Meeting type**: [standup, planning, review, 1:1, stakeholder, etc.]
+**Topic**: [primary subject]
+
+### Summary
+[3-5 sentence overview of what was discussed and concluded]
+
+### Key Decisions
+1. **[Decision]** — [context and rationale]
+2. ...
+
+### Action Items
+| # | Action | Owner | Deadline | Status |
+|---|--------|-------|----------|--------|
+
+### Discussion Highlights
+**[Topic 1]**: [key points, different perspectives, conclusion]
+**[Topic 2]**: [key points, different perspectives, conclusion]
+
+### Open Questions
+- [Question] — needs input from [person/team]
+
+### Next Steps
+- [What happens next]
+- Next meeting: [if mentioned]
+```
+
+Save as markdown.
+
+### Step 4: Offer Follow-ups
+
+- "Want me to **email these notes** to participants?"
+- "Should I **create tickets** from the action items?"
+- "Want me to **draft a stakeholder update** based on the decisions made?"
+
+## Notes
+
+- Decisions are the most valuable output — make sure every decision is captured clearly
+- Action items without owners are useless — if no owner was mentioned, flag it
+- Keep the summary concise — people who weren't in the meeting should get the gist in 30 seconds
+- If the transcript is very long (60+ min meeting), offer a TL;DR before the full summary
+- Distinguish between "discussed" and "decided" — many topics are explored without reaching a conclusion

pm-execution/commands/plan-okrs.md

@@ -0,0 +1,98 @@
+---
+description: Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results
+argument-hint: "<team, product area, or company objective>"
+---
+
+# /plan-okrs -- Team OKR Planning
+
+Generate well-structured OKRs that connect team work to company strategy. Produces 3 OKR sets with qualitative objectives and quantitative key results.
+
+## Invocation
+
+```
+/plan-okrs Growth team Q2 — company goal is 50% ARR increase
+/plan-okrs Onboarding squad aligned to "improve activation rate"
+/plan-okrs [upload company OKRs or strategy doc]
+```
+
+## Workflow
+
+### Step 1: Gather Context
+
+Ask the user:
+- What team or product area are these OKRs for?
+- What time period? (quarterly is standard, but could be annual or custom)
+- What are the company-level objectives these should ladder up to?
+- What happened last quarter? (hits, misses, learnings)
+- Any constraints or known priorities?
+
+Accept company OKRs or strategy documents as uploads.
+
+### Step 2: Generate OKRs
+
+Apply the **brainstorm-okrs** skill:
+
+- Create 3 OKR sets (Objective + 3-5 Key Results each)
+- **Objectives**: Qualitative, inspiring, ambitious but achievable, action-oriented
+- **Key Results**: Quantitative, measurable, time-bound, have clear owners
+- Ensure OKRs ladder to company objectives with visible connection
+- Balance leading indicators (activity) with lagging indicators (outcomes)
+
+### Step 3: Validate Quality
+
+Check each OKR against best practices:
+- Is the Objective inspiring? (Would you rally a team around it?)
+- Are Key Results measurable? (Can you check completion with data, not judgment?)
+- Are targets ambitious but not demoralizing? (70% achievement = well-calibrated)
+- Are there 3-5 KRs per Objective? (More = unfocused)
+- Do KRs avoid gaming? (e.g., "ship 5 features" incentivizes shipping junk)
+
+Flag any issues and suggest improvements.
+
+### Step 4: Present and Iterate
+
+```
+## Team OKRs: [Team Name] — [Period]
+
+**Aligned to**: [Company Objective(s)]
+
+### Objective 1: [Inspiring qualitative statement]
+| # | Key Result | Baseline | Target | Owner |
+|---|-----------|----------|--------|-------|
+| KR1 | [measurable result] | [current] | [target] | [team/person] |
+| KR2 | ... | ... | ... | ... |
+| KR3 | ... | ... | ... | ... |
+
+### Objective 2: [Inspiring qualitative statement]
+[same format]
+
+### Objective 3: [Inspiring qualitative statement]
+[same format]
+
+### Alignment Map
+Company Objective → Team Objective → Key Results → Expected Impact
+
+### Scoring Guide
+- 0.0-0.3: Significant miss — investigate and learn
+- 0.4-0.6: Progress made but fell short
+- 0.7-0.9: Well-calibrated stretch goal — this is the target zone
+- 1.0: Either nailed it or target wasn't ambitious enough
+
+### Check-in Cadence
+- **Weekly**: Quick traffic-light update on each KR
+- **Mid-quarter**: Deep review, adjust targets if context changed
+- **End of quarter**: Score, reflect, feed into next quarter
+```
+
+Offer:
+- "Want me to **adjust ambition levels** — make them more/less aggressive?"
+- "Should I **create a metrics dashboard** for tracking these?"
+- "Want me to **draft a stakeholder update** introducing these OKRs?"
+
+## Notes
+
+- OKRs should describe outcomes, not outputs ("Increase activation by 20%" not "Ship onboarding redesign")
+- If the user doesn't have company OKRs, help them derive team objectives from product strategy or business goals
+- Maximum 3 objectives per team per quarter — more means less focus
+- Key Results should be stretch goals — if you're certain you'll hit them, they're not ambitious enough
+- Flag any KR that could be gamed and suggest a counter-metric

pm-execution/commands/pre-mortem.md

@@ -0,0 +1,104 @@
+---
+description: Run a pre-mortem risk analysis on a PRD, launch plan, or feature — identify what could go wrong before it does
+argument-hint: "<PRD, plan, or feature description>"
+---
+
+# /pre-mortem -- Pre-Launch Risk Analysis
+
+Imagine your launch has failed. Now work backward to figure out why. This command applies the Tigers/Paper Tigers/Elephants framework to surface real risks and create mitigation plans.
+
+## Invocation
+
+```
+/pre-mortem [paste or upload a PRD, launch plan, or feature spec]
+/pre-mortem We're launching a self-serve billing portal next month
+```
+
+## Workflow
+
+### Step 1: Accept the Plan
+
+Accept in any format: PRD, feature spec, launch plan, project brief, or verbal description. The more detail provided, the sharper the risk analysis.
+
+### Step 2: Risk Identification
+
+Apply the **pre-mortem** skill:
+
+Imagine the product has launched and failed. Generate risks across categories:
+- **Technical**: Performance, scalability, integration failures, data issues
+- **User**: Adoption barriers, usability problems, unmet expectations
+- **Business**: Revenue impact, competitive response, market timing
+- **Operational**: Support load, documentation gaps, training needs
+- **Dependencies**: Third-party services, cross-team handoffs, regulatory
+
+### Step 3: Classify Risks
+
+Categorize each risk:
+
+**Tigers** — Real, substantive risks that could cause failure
+- Assess severity: Launch-blocking / Fast-follow / Track
+- For launch-blocking Tigers: immediate mitigation required
+- For fast-follow Tigers: plan to address within first sprint post-launch
+- For track Tigers: monitor but don't delay launch
+
+**Paper Tigers** — Risks that feel scary but are overblown
+- Explain why the concern is manageable
+- Note what would need to change for this to become a real Tiger
+
+**Elephants** — Unspoken risks the team knows about but avoids discussing
+- Surface political, organizational, or uncomfortable risks
+- Frame constructively with suggested conversation starters
+
+### Step 4: Generate Pre-Mortem Report
+
+```
+## Pre-Mortem: [Feature/Launch]
+
+**Date**: [today]
+**Status**: [Draft / Reviewed]
+
+### Risk Summary
+- **Tigers**: [count] ([launch-blocking], [fast-follow], [track])
+- **Paper Tigers**: [count]
+- **Elephants**: [count]
+
+### Launch-Blocking Tigers
+| # | Risk | Likelihood | Impact | Mitigation | Owner | Deadline |
+|---|------|-----------|--------|-----------|-------|----------|
+
+### Fast-Follow Tigers
+| # | Risk | Likelihood | Impact | Planned Response | Owner |
+|---|------|-----------|--------|-----------------|-------|
+
+### Track Tigers
+[Risks to monitor post-launch with trigger conditions]
+
+### Paper Tigers
+[Concerns that seem big but are manageable — with reasoning]
+
+### Elephants in the Room
+[Uncomfortable truths the team should discuss]
+
+### Go/No-Go Checklist
+- [ ] All launch-blocking Tigers mitigated
+- [ ] Fast-follow plan documented and assigned
+- [ ] Monitoring in place for Track Tigers
+- [ ] Rollback plan defined
+- [ ] Support team briefed
+```
+
+Save as markdown.
+
+### Step 5: Offer Next Steps
+
+- "Want me to **update the PRD** with risk mitigations?"
+- "Should I **create test scenarios** for the riskiest areas?"
+- "Want me to **draft a launch checklist** from these findings?"
+
+## Notes
+
+- The best pre-mortems happen when the plan is 80% done — early enough to change course, late enough to have substance
+- Push past the obvious risks — the most dangerous risks are the ones nobody mentions
+- Elephants are the highest-value output — surfacing what the team avoids discussing
+- For each Tiger, the mitigation should be specific and assignable, not "be careful"
+- If the pre-mortem reveals too many launch-blocking Tigers, recommend delaying or phasing the launch

pm-execution/commands/sprint.md

@@ -0,0 +1,193 @@
+---
+description: Sprint lifecycle — plan a sprint, run a retrospective, or generate release notes
+argument-hint: "[plan|retro|release-notes] <context>"
+---
+
+# /sprint -- Sprint Lifecycle
+
+Three modes covering the sprint lifecycle: **plan** for sprint planning, **retro** for retrospectives, **release-notes** for shipping communication.
+
+## Invocation
+
+```
+/sprint plan 2-week sprint, 4 engineers, focus on checkout improvements
+/sprint retro [paste team feedback or sprint data]
+/sprint release-notes [paste tickets, changelog, or PRD]
+/sprint                    # asks which phase you're in
+```
+
+## Modes
+
+---
+
+### Plan Mode
+
+Prepare for sprint planning with capacity estimation, story selection, and risk identification.
+
+#### Workflow
+
+**Step 1: Gather Sprint Context**
+- Sprint duration (1 or 2 weeks)
+- Team composition (engineers, designers, QA — and availability)
+- Sprint goal or focus area
+- Backlog items to consider (paste, upload, or describe)
+- Any carry-over from last sprint
+- Known interruptions (holidays, on-call, meetings)
+
+**Step 2: Estimate Capacity**
+
+Apply the **sprint-plan** skill:
+
+- Calculate available engineering hours/points after meetings, on-call, PTO
+- Apply a velocity adjustment based on historical data (if provided) or industry standard (70% of theoretical capacity)
+- Show capacity breakdown per team member
+
+**Step 3: Select and Sequence Stories**
+
+- Recommend which stories fit within capacity
+- Flag dependency chains (A must complete before B starts)
+- Identify risks: stories that are underspecified, have external dependencies, or need design input
+- Balance quick wins with larger items
+- Ensure every story has acceptance criteria
+
+**Step 4: Generate Sprint Plan**
+
+```
+## Sprint Plan: [Sprint Name/Number]
+
+**Duration**: [dates]
+**Sprint Goal**: [one sentence]
+**Team**: [members and availability]
+
+### Capacity
+| Member | Available Days | Points/Hours | Notes |
+|--------|--------------|-------------|-------|
+
+**Total capacity**: [X] points/hours
+**Recommended commitment**: [Y] points/hours (with buffer)
+
+### Selected Stories
+| # | Story | Points | Owner | Dependencies | Risk |
+|---|-------|--------|-------|-------------|------|
+
+### Sprint Risks
+1. [Risk] — Mitigation: [action]
+
+### Definition of Done
+- [ ] Code reviewed
+- [ ] Tests passing
+- [ ] Deployed to staging
+- [ ] QA approved
+- [ ] Documentation updated (if applicable)
+```
+
+---
+
+### Retro Mode
+
+Facilitate a structured retrospective that produces actionable improvements.
+
+#### Workflow
+
+**Step 1: Gather Sprint Feedback**
+
+Accept input as:
+- Team feedback (pasted from a survey, Slack, or collaborative doc)
+- Sprint metrics (velocity, bugs, incidents)
+- The user's own observations
+
+Ask: "Which retro format do you prefer?"
+- **Start/Stop/Continue** (simple, fast)
+- **4Ls** (Liked, Learned, Lacked, Longed for)
+- **Sailboat** (Wind = helps, Anchor = slows, Rocks = risks, Island = goals)
+
+**Step 2: Analyze and Structure**
+
+Apply the **retro** skill:
+
+- Categorize feedback into the chosen framework
+- Identify themes and patterns
+- Separate symptoms from root causes
+- Highlight wins worth celebrating
+
+**Step 3: Generate Retro Summary**
+
+```
+## Sprint Retrospective: [Sprint Name]
+
+**Date**: [today]
+**Format**: [Start/Stop/Continue | 4Ls | Sailboat]
+**Participants**: [if known]
+
+### What Went Well
+[Grouped themes with supporting evidence]
+
+### What Didn't Go Well
+[Grouped themes with root cause analysis]
+
+### Key Insights
+[2-3 patterns that emerged]
+
+### Action Items
+| # | Action | Owner | Deadline | Priority |
+|---|--------|-------|----------|----------|
+
+### Metrics This Sprint
+| Metric | This Sprint | Last Sprint | Trend |
+|--------|-----------|------------|-------|
+```
+
+---
+
+### Release Notes Mode
+
+Generate user-facing release notes from technical artifacts.
+
+#### Workflow
+
+**Step 1: Accept Release Content**
+
+Accept:
+- Jira/Linear tickets or changelog
+- PRD or feature specs
+- Git commit messages or PR descriptions
+- Team's internal summary of what shipped
+
+**Step 2: Transform**
+
+Apply the **release-notes** skill:
+
+- Translate technical language into user benefits
+- Categorize as: New Features, Improvements, Bug Fixes
+- Write in the product's voice (ask about tone if not clear)
+- Highlight the most impactful change first
+
+**Step 3: Generate Release Notes**
+
+```
+## What's New — [Version/Date]
+
+### Highlights
+[1-2 sentence summary of the most important change]
+
+### New Features
+- **[Feature Name]** — [user-facing benefit in plain language]
+
+### Improvements
+- **[Improvement]** — [what's better now]
+
+### Bug Fixes
+- Fixed [issue] that caused [user impact]
+
+### Coming Soon
+[Optional teaser for next release]
+```
+
+Save as markdown and offer to format for different channels (blog post, in-app, email, Slack announcement).
+
+## Notes
+
+- For plan mode: protect 20% buffer for unplanned work — teams that plan at 100% capacity always miss
+- For retro mode: focus on 2-3 high-impact action items, not 10 things nobody will do
+- For release notes: always frame changes as user benefits, not technical implementations
+- Each mode can chain to the others: plan → (sprint happens) → retro → release-notes

pm-execution/commands/stakeholder-map.md

@@ -0,0 +1,107 @@
+---
+description: Map stakeholders on a Power × Interest grid and create a tailored communication plan
+argument-hint: "<project, initiative, or launch>"
+---
+
+# /stakeholder-map -- Stakeholder Mapping & Communication Plan
+
+Identify all stakeholders for a project, map them by influence and interest, and generate a communication plan that ensures the right people get the right information at the right time.
+
+## Invocation
+
+```
+/stakeholder-map New analytics platform launch
+/stakeholder-map Pricing model change affecting all customers
+/stakeholder-map [upload a project brief or org chart]
+```
+
+## Workflow
+
+### Step 1: Understand the Initiative
+
+Ask:
+- What is the project or initiative?
+- What phase is it in? (planning, building, launching, post-launch)
+- Who are the obvious stakeholders you already know about?
+- Are there any politically sensitive dynamics to be aware of?
+
+### Step 2: Identify Stakeholders
+
+Brainstorm stakeholders the user might not have considered:
+- **Internal**: Engineering, Design, QA, Data, Legal, Finance, Marketing, Sales, Support, Leadership
+- **External**: Customers, partners, vendors, regulators, board members
+- **Often missed**: Adjacent teams, on-call engineers, customer success, documentation team
+
+### Step 3: Map to Power × Interest Grid
+
+Apply the **stakeholder-map** skill:
+
+Place each stakeholder in a quadrant:
+
+```
+                    HIGH INTEREST
+                         │
+    KEEP SATISFIED       │      MANAGE CLOSELY
+    (High Power,         │      (High Power,
+     Low Interest)       │       High Interest)
+                         │
+   ──────────────────────┼──────────────────────
+                         │
+    MONITOR              │      KEEP INFORMED
+    (Low Power,          │      (Low Power,
+     Low Interest)       │       High Interest)
+                         │
+                    LOW INTEREST
+```
+
+### Step 4: Generate Communication Plan
+
+```
+## Stakeholder Map: [Initiative]
+
+### Stakeholder Grid
+| Stakeholder | Role | Power | Interest | Quadrant | Stance |
+|------------|------|-------|----------|----------|--------|
+
+### Communication Plan
+
+#### Manage Closely (High Power, High Interest)
+| Stakeholder | Channel | Frequency | Content | Owner |
+|------------|---------|-----------|---------|-------|
+
+#### Keep Satisfied (High Power, Low Interest)
+| Stakeholder | Channel | Frequency | Content | Owner |
+|------------|---------|-----------|---------|-------|
+
+#### Keep Informed (Low Power, High Interest)
+| Stakeholder | Channel | Frequency | Content | Owner |
+|------------|---------|-----------|---------|-------|
+
+#### Monitor (Low Power, Low Interest)
+[Minimal communication — include in broad updates only]
+
+### Potential Conflicts
+[Where stakeholder interests may clash — with mitigation strategies]
+
+### Escalation Path
+[Who to go to when decisions are blocked]
+
+### RACI Matrix
+| Decision Area | Responsible | Accountable | Consulted | Informed |
+|--------------|-------------|-------------|-----------|----------|
+```
+
+Save as markdown.
+
+### Step 5: Offer Next Steps
+
+- "Want me to **draft the first stakeholder update** for the 'Manage Closely' group?"
+- "Should I **create a meeting prep brief** for key stakeholder conversations?"
+- "Want me to **set up a communication cadence** as a recurring checklist?"
+
+## Notes
+
+- The "Manage Closely" quadrant is where PMs spend most of their political capital — get these relationships right
+- "Stance" (supportive, neutral, resistant) helps prioritize where to invest relationship-building effort
+- Don't forget downstream stakeholders: support, docs, and sales enablement teams are often surprised by launches
+- Update the map as the project evolves — stakeholder interest shifts with project phase

pm-execution/commands/test-scenarios.md

@@ -0,0 +1,83 @@
+---
+description: Generate comprehensive test scenarios from user stories or feature specs — happy paths, edge cases, and error handling
+argument-hint: "<user stories, feature spec, or description>"
+---
+
+# /test-scenarios -- Test Scenario Generator
+
+Turn user stories or feature descriptions into comprehensive test scenarios that QA can execute immediately. Covers happy paths, edge cases, error handling, and cross-browser/device considerations.
+
+## Invocation
+
+```
+/test-scenarios [paste user stories or acceptance criteria]
+/test-scenarios [upload a PRD or feature spec]
+/test-scenarios User can reset their password via email link
+```
+
+## Workflow
+
+### Step 1: Accept Input
+
+Accept: user stories, acceptance criteria, PRD sections, feature descriptions, or any specification of expected behavior.
+
+### Step 2: Generate Test Scenarios
+
+Apply the **test-scenarios** skill:
+
+For each user story or requirement, generate:
+
+**Happy Path Scenarios**: The expected user flow works correctly
+**Edge Cases**: Boundary conditions, unusual inputs, concurrent operations
+**Error Scenarios**: What happens when things go wrong
+**Security Scenarios**: If applicable (auth, permissions, data access)
+**Performance Scenarios**: If applicable (load, timeout, large data)
+
+### Step 3: Structure Output
+
+```
+## Test Scenarios: [Feature]
+
+**Source**: [user stories / PRD / description]
+**Total scenarios**: [count]
+**Coverage**: [happy path / edge cases / errors / security / performance]
+
+### Scenario 1: [Title]
+**Tests**: [which story or requirement]
+**Preconditions**: [setup needed]
+**User role**: [who is performing this]
+
+| Step | Action | Expected Result |
+|------|--------|----------------|
+| 1 | [user action] | [expected system response] |
+| 2 | [user action] | [expected system response] |
+
+**Postconditions**: [state after completion]
+**Priority**: [Critical / High / Medium / Low]
+
+---
+[Repeat for each scenario]
+
+### Coverage Matrix
+| Requirement | Happy Path | Edge Cases | Error Handling | Notes |
+|------------|-----------|-----------|---------------|-------|
+
+### Test Data Requirements
+[What test data is needed to execute these scenarios]
+```
+
+Save as markdown.
+
+### Step 4: Offer Next Steps
+
+- "Want me to **generate the test data** for these scenarios?"
+- "Should I **add more edge cases** for any specific scenario?"
+- "Want me to **create the user stories** that these scenarios test?"
+
+## Notes
+
+- Happy paths first, then layer in edge cases — ensure basic flows work before testing boundaries
+- Every acceptance criterion from the original story should map to at least one test scenario
+- Include both positive tests (it works) and negative tests (it fails gracefully)
+- For APIs, include scenarios for rate limiting, timeout, malformed requests, and auth failures
+- Flag scenarios that require specific test environments or third-party service mocking

pm-execution/commands/transform-roadmap.md

@@ -0,0 +1,96 @@
+---
+description: Convert a feature-based roadmap into an outcome-focused roadmap that communicates strategic intent
+argument-hint: "<roadmap as text, file, or list of planned features>"
+---
+
+# /transform-roadmap -- Outcome-Focused Roadmap
+
+Take a list of planned features or an output-focused roadmap and rewrite it as an outcome-focused roadmap that communicates *why* instead of *what*.
+
+## Invocation
+
+```
+/transform-roadmap [paste your feature list or roadmap]
+/transform-roadmap [upload a roadmap doc, spreadsheet, or screenshot]
+```
+
+## Workflow
+
+### Step 1: Accept the Current Roadmap
+
+Accept in any format:
+- Feature list or backlog items
+- Roadmap document (Now/Next/Later, quarterly, timeline)
+- Spreadsheet or Gantt chart export
+- Screenshot of a roadmap tool
+
+Parse each item to extract: feature name, description, target date/timeframe, and any context.
+
+### Step 2: Understand Strategic Context
+
+Ask:
+- What are the product goals or OKRs for this period?
+- Who is the audience for this roadmap? (execs, engineering, customers, board)
+- What format do you prefer? (Now/Next/Later, quarterly, timeline)
+
+### Step 3: Transform Each Item
+
+Apply the **outcome-roadmap** skill:
+
+For each feature/output on the roadmap:
+1. Identify the **user or business outcome** it's trying to achieve
+2. Rewrite as an outcome statement: "[Verb] [metric/experience] for [user segment]"
+3. Group features that serve the same outcome under one initiative
+4. Add success metrics to each outcome
+
+**Before → After examples:**
+- "Build SSO integration" → "Reduce enterprise onboarding friction — target: 50% faster time-to-first-value for enterprise accounts"
+- "Redesign dashboard" → "Help power users find insights faster — target: 30% reduction in time-to-insight"
+- "Add CSV export" → "Enable teams to share data outside the product — target: 25% increase in report sharing"
+
+### Step 4: Generate Transformed Roadmap
+
+```
+## Outcome-Focused Roadmap: [Product] — [Period]
+
+**Strategic themes**: [2-3 high-level themes]
+
+### Now (Current Quarter)
+**Theme: [Strategic Theme]**
+| Outcome | Success Metric | Key Initiatives | Status |
+|---------|---------------|----------------|--------|
+
+### Next (Next Quarter)
+**Theme: [Strategic Theme]**
+| Outcome | Success Metric | Key Initiatives | Confidence |
+|---------|---------------|----------------|------------|
+
+### Later (Future)
+**Theme: [Strategic Theme]**
+| Outcome | Success Metric | Key Initiatives | Dependencies |
+|---------|---------------|----------------|-------------|
+
+### Transformation Notes
+| Original Feature | Transformed Outcome | Why This Framing |
+|-----------------|--------------------|-----------------|
+
+### What Changed
+[Summary of how the roadmap narrative shifted]
+```
+
+Save as a markdown file.
+
+### Step 5: Review
+
+Offer:
+- "Want me to **add OKR alignment** for each outcome?"
+- "Should I **draft a stakeholder presentation** of this roadmap?"
+- "Want me to **identify risks** for the Now items?"
+
+## Notes
+
+- Outcomes should be measurable and have a clear "done" state
+- Multiple features can map to one outcome — this is a feature, not a bug
+- If an output doesn't clearly serve an outcome, flag it for the user to justify or deprioritize
+- The audience matters: exec roadmaps should be outcome-only, engineering roadmaps can include deliverables under each outcome
+- "Later" items should be less specific — outcomes without committed solutions

pm-execution/commands/write-prd.md

@@ -0,0 +1,118 @@
+---
+description: Create a comprehensive Product Requirements Document from a feature idea or problem statement
+argument-hint: "<feature or problem statement>"
+---
+
+# /write-prd -- Product Requirements Document
+
+Create a structured PRD that aligns stakeholders and guides development. Accepts anything from a vague idea to a detailed brief.
+
+## Invocation
+
+```
+/write-prd SSO support for enterprise customers
+/write-prd Users are dropping off during onboarding — we need to fix step 3
+/write-prd [upload a brief, research doc, or strategy deck]
+```
+
+## Workflow
+
+### Step 1: Understand the Feature
+
+Accept the input in any form:
+- A feature name ("SSO support")
+- A problem statement ("Enterprise customers keep asking for centralized auth")
+- A user request ("Users want to export their data as CSV")
+- A vague idea ("We should do something about onboarding drop-off")
+- An uploaded document (brief, research, Slack thread, email)
+
+### Step 2: Gather Context
+
+Ask conversationally — most important questions first, fill gaps as you go:
+
+1. **User problem**: What problem does this solve? Who experiences it? How painful is it?
+2. **Target users**: Which user segment(s)? How many? What's their current workaround?
+3. **Success metrics**: How will we know this worked? What moves if we nail it?
+4. **Constraints**: Technical constraints, timeline, regulatory, dependencies on other teams?
+5. **Prior art**: Has this been attempted before? Existing solutions in the market?
+6. **Scope preference**: Full solution or phased approach?
+
+If the user provides a document with context, extract what's available and only ask about gaps.
+
+### Step 3: Generate the PRD
+
+Apply the **create-prd** skill to produce an 8-section document:
+
+```
+## Product Requirements Document: [Feature Name]
+
+**Author**: [user]
+**Date**: [today]
+**Status**: Draft
+**Stakeholders**: [if known]
+
+### 1. Executive Summary
+[2-3 sentences: what, for whom, why now]
+
+### 2. Background & Context
+[Problem space, prior research, market context, what prompted this]
+
+### 3. Objectives & Success Metrics
+**Goals** (what success looks like):
+1. [Specific, measurable goal]
+2. [...]
+
+**Non-Goals** (explicitly out of scope):
+1. [What we're not doing, and why]
+2. [...]
+
+**Success Metrics**:
+| Metric | Current | Target | Measurement |
+|--------|---------|--------|-------------|
+
+### 4. Target Users & Segments
+[Who this serves, user profiles, segment sizing]
+
+### 5. User Stories & Requirements
+
+**P0 — Must Have**:
+| # | User Story | Acceptance Criteria |
+|---|-----------|-------------------|
+
+**P1 — Should Have**:
+| # | User Story | Acceptance Criteria |
+|---|-----------|-------------------|
+
+**P2 — Nice to Have / Future**:
+| # | User Story | Acceptance Criteria |
+|---|-----------|-------------------|
+
+### 6. Solution Overview
+[High-level approach, key design decisions, technical approach if known]
+
+### 7. Open Questions
+| Question | Owner | Deadline |
+|----------|-------|----------|
+
+### 8. Timeline & Phasing
+[Milestones, dependencies, phasing if applicable]
+```
+
+### Step 4: Review and Iterate
+
+After generating, offer:
+- "Want me to **tighten the scope**? I can challenge which P1s should really be P2s."
+- "Should I **run a pre-mortem** on this PRD?"
+- "Want me to **break this into user stories** for engineering?"
+- "Should I **create a stakeholder update** to socialize this?"
+
+Save the PRD as a markdown file to the user's workspace.
+
+## Notes
+
+- Be opinionated about scope — a tight PRD is better than an expansive vague one
+- If the idea is too big, proactively suggest phasing and spec only Phase 1
+- Non-goals are as important as goals — they prevent scope creep
+- Success metrics must be specific: "improve NPS" is bad, "increase NPS from 32 to 45 within 90 days of launch" is good
+- Open questions should be genuinely unresolved — don't list things you can answer from context
+- If the user provides research, weave insights into the Background section with attribution

pm-execution/commands/write-stories.md

@@ -0,0 +1,112 @@
+---
+description: Break a feature into backlog items — user stories, job stories, or WWA format with acceptance criteria
+argument-hint: "[user|job|wwa] <feature description or PRD>"
+---
+
+# /write-stories -- Backlog Item Generator
+
+Break a feature into well-structured backlog items. Choose from three formats based on your team's preference, each with full acceptance criteria.
+
+## Invocation
+
+```
+/write-stories user Allow users to export reports as PDF and CSV
+/write-stories job Notification system for task deadlines
+/write-stories wwa Dark mode for the mobile app
+/write-stories [upload a PRD or feature spec]      # asks format preference
+/write-stories                                      # asks for feature and format
+```
+
+## Formats
+
+### User Stories
+**Format**: "As a [user type], I want [capability], so that [benefit]"
+Apply the **user-stories** skill:
+- Follow the 3 C's: Card (brief), Conversation (context), Confirmation (acceptance criteria)
+- Validate against INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
+- Include design links or mockup references where relevant
+
+### Job Stories
+**Format**: "When [situation], I want to [motivation], so I can [outcome]"
+Apply the **job-stories** skill:
+- Focus on the situation and context, not the user role
+- Ground in real user scenarios observed in research
+- Ideal for JTBD-oriented teams
+
+### WWA (Why-What-Acceptance)
+**Format**: Why [strategic context] → What [deliverable] → Acceptance [criteria]
+Apply the **wwas** skill:
+- Includes strategic reasoning (why we're building this)
+- Produces independent, valuable, testable items
+- Good for cross-functional teams that need business context
+
+## Workflow
+
+### Step 1: Accept the Feature
+
+Accept in any form: PRD, feature description, user research finding, or verbal idea. If a PRD is provided, extract the requirements to decompose.
+
+### Step 2: Determine Format
+
+If not specified in the invocation, ask:
+- "Which format does your team use? **User stories**, **Job stories**, or **WWA**?"
+- If unsure, recommend user stories as the default
+
+### Step 3: Decompose the Feature
+
+- Break the feature into 5-15 independent stories (small enough to complete in one sprint)
+- Ensure each story is independently valuable (delivers user value on its own)
+- Order by dependency and priority
+- Write 3-5 acceptance criteria per story
+- Flag stories that need design input or technical spikes
+
+### Step 4: Generate Stories
+
+```
+## Backlog: [Feature Name]
+
+**Format**: [User Stories / Job Stories / WWA]
+**Total stories**: [count]
+**Estimated total effort**: [if possible]
+
+### Stories
+
+#### Story 1: [Short title]
+**[The story in chosen format]**
+
+Acceptance Criteria:
+- [ ] [Criterion 1]
+- [ ] [Criterion 2]
+- [ ] [Criterion 3]
+
+Priority: [P0/P1/P2] | Effort: [S/M/L] | Dependencies: [none or list]
+
+---
+[Repeat for each story]
+
+### Story Map
+[Visual ordering: must-have → should-have → nice-to-have]
+
+### Technical Notes
+[Cross-cutting concerns: API changes, data migration, infrastructure]
+
+### Open Questions
+[Things that need answers before implementation can start]
+```
+
+Save as markdown.
+
+### Step 5: Offer Next Steps
+
+- "Want me to **generate test scenarios** for these stories?"
+- "Should I **create dummy data** for development and testing?"
+- "Want me to **estimate sprint capacity** for these stories?"
+- "Should I **convert to a different format** (user stories ↔ job stories ↔ WWA)?"
+
+## Notes
+
+- One story = one deployable unit of value — if it needs another story to be useful, they should be combined
+- Acceptance criteria should be testable by QA without additional interpretation
+- Error handling and edge cases deserve their own stories, not bullet points within a happy-path story
+- If the feature is large (15+ stories), suggest grouping into epics or phases
+- Flag any story that requires a spike (technical investigation before estimation is possible)

pm-execution/skills/brainstorm-okrs/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: brainstorm-okrs
+description: "Brainstorm team-level OKRs aligned with company objectives. Creates 3 OKR sets with qualitative objectives and quantitative key results. Use when setting quarterly OKRs, aligning team goals with company strategy, or drafting objectives. Triggers: OKRs, objectives key results, team goals, quarterly planning, goal setting."
+---
+
+# Brainstorm Team OKRs
+
+## Purpose
+
+You are a veteran product leader responsible for defining Objectives and Key Results (OKRs) for the team working on $ARGUMENTS. Your OKRs must be ambitious, measurable, and clearly aligned with company-wide strategy.
+
+## Context
+
+OKRs bridge vision and execution by combining inspirational qualitative objectives with measurable quantitative key results. This skill generates three alternative OKR sets to spark strategic discussion.
+
+## Domain Context
+
+**OKR** (Christina Wodtke, *Radical Focus*):
+- **Objective** (Why, What, When): Qualitative, inspirational, time-bound goal. Typically quarterly. Should be SMART.
+- **Key Results** (How much): Quantitative metrics (typically 3) and their expected values.
+
+**OKRs, KPIs, and NSM are interconnected — not alternatives.** Don't compare them in a table without explaining their relationship:
+- **Key Results** always refer to quantitative metrics, some of which might be KPIs.
+- **KPIs** = a few key quantitative metrics tracked over a longer period. Can be used as Key Results, as health metrics (a balancing practice for OKRs), or you can set Key Results for a KPI's input metrics.
+- **North Star Metric** = a single, customer-centric KPI. A leading indicator of business success. You can use Key Results to express expected change in NSM.
+
+OKRs are fundamentally about: (1) Setting a single, inspiring goal. (2) Empowering a team to determine the optimal approach. (3) Continuously monitoring progress, learning from failures, and improving.
+
+## Instructions
+
+1. **Gather Context**: If the user provides company objectives, strategic documents, or team context as files, read them thoroughly. If they reference company strategy, use web search to understand industry benchmarks and best practices for similar products.
+
+2. **Understand the Framework**: OKRs have two components:
+   - **Objective**: A qualitative, inspirational goal describing the directional intent
+   - **Key Results**: 3 quantitative metrics (typically) measuring progress toward the objective
+
+3. **Think Step by Step**:
+   - What is the company strategy?
+   - What are the 3-5 most impactful areas the team can influence?
+   - How do team efforts ladder up to company goals?
+   - What would success look like for customers and the business?
+
+4. **Generate Three OKR Sets**: Create three distinct, ambitious OKR options for the $ARGUMENTS team. For each set:
+   - Start with a clear, inspiring Objective statement
+   - Define exactly 3 Key Results that are:
+     - Measurable (can be tracked numerically)
+     - Achievable but ambitious (60-70% confidence level)
+     - Aligned with company strategy
+
+5. **Example Format**:
+   ```
+   Objective: Delight new users with an effortless onboarding experience
+   Key Results:
+   - CSAT score >= 75% on onboarding survey
+   - 66%+ of onboardings completed within two days
+   - Average time-to-value (TTV) <= 20 minutes
+   ```
+
+6. **Structure Output**: Present all three OKR sets with equal weight. For each, include:
+   - Objective (1-2 sentences)
+   - Three Key Results (specific metrics with targets)
+   - Brief rationale (why this matters to the company and team)
+
+7. **Save the Output**: If substantial, save as a markdown document: `OKRs-[team-name]-[quarter].md`
+
+## Notes
+
+- Ensure each Key Result is independently measurable
+- Avoid output-focused metrics (e.g., "launch 5 features"); focus on outcomes
+- All three OKR sets should be credible, not one clearly better than others
+- Flag any assumptions about data availability
+
+---
+
+### Further Reading
+
+- [Objectives and Key Results (OKRs) 101](https://www.productcompass.pm/p/okrs-101-advanced-techniques)
+- [OKR vs KPI: What's the Difference?](https://www.productcompass.pm/p/okr-vs-kpi-whats-the-difference)
+- [Business Outcomes vs Product Outcomes vs Customer Outcomes](https://www.productcompass.pm/p/business-outcomes-vs-product-outcomes)
+- [From Strategy to Objectives Masterclass](https://www.productcompass.pm/p/product-vision-strategy-objectives-course) (video course)

pm-execution/skills/create-prd/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: create-prd
+description: "Create a Product Requirements Document using a comprehensive 8-section template covering summary, background, objectives, market segments, value propositions, solution details, and release planning. Use when writing a PRD, documenting product requirements, creating a feature spec, or preparing a product brief. Triggers: PRD, product requirements, feature spec, product brief, requirements document."
+---
+
+# Create a Product Requirements Document
+
+## Purpose
+
+You are an experienced product manager responsible for creating a comprehensive Product Requirements Document (PRD) for $ARGUMENTS. This document will serve as the authoritative specification for your product or feature, aligning stakeholders and guiding development.
+
+## Context
+
+A well-structured PRD clearly communicates the what, why, and how of your product initiative. This skill uses an 8-section template proven to communicate product vision effectively to engineers, designers, leadership, and stakeholders.
+
+## Instructions
+
+1. **Gather Information**: If the user provides files, read them carefully. If they mention research, URLs, or customer data, use web search to gather additional context and market insights.
+
+2. **Think Step by Step**: Before writing, analyze:
+   - What problem are we solving?
+   - Who are we solving it for?
+   - How will we measure success?
+   - What are our constraints and assumptions?
+
+3. **Apply the PRD Template**: Create a document with these 8 sections:
+
+   **1. Summary** (2-3 sentences)
+   - What is this document about?
+
+   **2. Contacts**
+   - Name, role, and comment for key stakeholders
+
+   **3. Background**
+   - Context: What is this initiative about?
+   - Why now? Has something changed?
+   - Is this something that just recently became possible?
+
+   **4. Objective**
+   - What's the objective? Why does it matter?
+   - How will it benefit the company and customers?
+   - How does it align with vision and strategy?
+   - Key Results: How will you measure success? (Use SMART OKR format)
+
+   **5. Market Segment(s)**
+   - For whom are we building this?
+   - What constraints exist?
+   - Note: Markets are defined by people's problems/jobs, not demographics
+
+   **6. Value Proposition(s)**
+   - What customer jobs/needs are we addressing?
+   - What will customers gain?
+   - Which pains will they avoid?
+   - Which problems do we solve better than competitors?
+   - Consider the Value Curve framework
+
+   **7. Solution**
+   - 7.1 UX/Prototypes (wireframes, user flows)
+   - 7.2 Key Features (detailed feature descriptions)
+   - 7.3 Technology (optional, only if relevant)
+   - 7.4 Assumptions (what we believe but haven't proven)
+
+   **8. Release**
+   - How long could it take?
+   - What goes in the first version vs. future versions?
+   - Avoid exact dates; use relative timeframes
+
+4. **Use Accessible Language**: Write for a primary school graduate. Avoid jargon. Use clear, short sentences.
+
+5. **Structure Output**: Present the PRD as a well-formatted markdown document with clear headings and sections.
+
+6. **Save the Output**: If the PRD is substantial (which it will be), save it as a markdown document in the format: `PRD-[product-name].md`
+
+## Notes
+
+- Be specific and data-driven where possible
+- Link each section back to the overall strategy
+- Flag assumptions clearly so the team can validate them
+- Keep the document concise but complete
+
+---
+
+### Further Reading
+
+- [How to Write a Product Requirements Document? The Best PRD Template.](https://www.productcompass.pm/p/prd-template)
+- [A Proven AI PRD Template by Miqdad Jaffer (Product Lead @ OpenAI)](https://www.productcompass.pm/p/ai-prd-template)

pm-execution/skills/dummy-dataset/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: dummy-dataset
+description: "Generate realistic dummy datasets for testing with customizable columns, constraints, and output formats (CSV, JSON, SQL, Python script). Use when creating test data, generating sample datasets, or building realistic mock data for development. Triggers: dummy data, test data, mock dataset, sample data, generate data."
+---
+# Dummy Dataset Generation
+
+Generate realistic dummy datasets for testing with customizable columns, constraints, and output formats (CSV, JSON, SQL, Python script). Creates executable scripts or direct data files for immediate use.
+
+**Use when:** Creating test data, generating sample datasets, building realistic mock data for development, or populating test environments.
+
+**Arguments:**
+- `$PRODUCT`: The product or system name
+- `$DATASET_TYPE`: Type of data (e.g., customer feedback, transactions, user profiles)
+- `$ROWS`: Number of rows to generate (default: 100)
+- `$COLUMNS`: Specific columns or fields to include
+- `$FORMAT`: Output format (CSV, JSON, SQL, Python script)
+- `$CONSTRAINTS`: Additional constraints or business rules
+
+## Step-by-Step Process
+
+1. **Identify dataset type** - Understand the data domain
+2. **Define column specifications** - Names, data types, and value ranges
+3. **Determine row count** - How many sample records needed
+4. **Select output format** - CSV, JSON, SQL INSERT, or Python script
+5. **Apply realistic patterns** - Ensure data looks authentic and valid
+6. **Add business constraints** - Respect business logic and relationships
+7. **Generate or script data** - Create executable output
+8. **Validate output** - Ensure data quality and completeness
+
+## Template: Python Script Output
+
+```python
+import csv
+import json
+from datetime import datetime, timedelta
+import random
+
+# Configuration
+ROWS = $ROWS
+FILENAME = "$DATASET_TYPE.csv"
+
+# Column definitions with realistic value generators
+columns = {
+    "id": "auto-increment",
+    "name": "first_last_name",
+    "email": "email",
+    "created_at": "timestamp",
+    # Add more columns...
+}
+
+def generate_dataset():
+    """Generate realistic dummy dataset"""
+    data = []
+    for i in range(1, ROWS + 1):
+        record = {
+            "id": f"U{i:06d}",
+            # Generate values based on column definitions
+        }
+        data.append(record)
+    return data
+
+def save_as_csv(data, filename):
+    """Save dataset as CSV"""
+    with open(filename, 'w', newline='') as f:
+        writer = csv.DictWriter(f, fieldnames=data[0].keys())
+        writer.writeheader()
+        writer.writerows(data)
+
+if __name__ == "__main__":
+    dataset = generate_dataset()
+    save_as_csv(dataset, FILENAME)
+    print(f"Generated {len(dataset)} records in {FILENAME}")
+```
+
+## Example Dataset Specification
+
+**Dataset Type:** Customer Feedback
+
+**Columns:**
+- feedback_id (auto-increment, U001, U002...)
+- customer_name (realistic names)
+- email (valid email format)
+- feedback_date (dates last 90 days)
+- rating (1-5 stars)
+- category (Bug, Feature Request, Complaint, Praise)
+- text (realistic feedback)
+- product (electronics, clothing, home)
+
+**Constraints:**
+- Ratings skewed: 40% 5-star, 30% 4-star, 20% 3-star, 10% 1-2 star
+- Bug category only with ratings 1-3
+- Feature requests only with ratings 3-5
+- Email domains realistic (gmail, yahoo, company.com)
+
+## Output Deliverables
+
+- Ready-to-execute Python script OR direct data file
+- CSV file with proper headers and formatting
+- JSON file with valid structure and types
+- SQL INSERT statements for database population
+- Data validation and constraint compliance
+- Realistic, business-appropriate values
+- Documentation of data generation logic
+- Quick-start instructions for using the dataset
+
+## Output Formats
+
+**CSV:** Flat tabular format, easy to import into spreadsheets and databases
+
+**JSON:** Nested structure, ideal for APIs and NoSQL databases
+
+**SQL:** INSERT statements, directly executable on relational databases
+
+**Python Script:** Executable generator for custom or large datasets

pm-execution/skills/job-stories/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: job-stories
+description: "Create job stories using the 'When [situation], I want to [motivation], so I can [outcome]' format with detailed acceptance criteria. Use when writing job stories, expressing user situations and motivations, or creating JTBD-style backlog items. Triggers: job stories, JTBD story, situation motivation outcome."
+---
+# Job Stories
+
+Create job stories using the 'When [situation], I want to [motivation], so I can [outcome]' format. Generates stories with detailed acceptance criteria focused on user situations and outcomes.
+
+**Use when:** Writing job stories, expressing user situations and motivations, creating JTBD-style backlog items, or focusing on user context rather than roles.
+
+**Arguments:**
+- `$PRODUCT`: The product or system name
+- `$FEATURE`: The new feature to break into job stories
+- `$DESIGN`: Link to design files (Figma, Miro, etc.)
+- `$CONTEXT`: User situations or job scenarios
+
+## Step-by-Step Process
+
+1. **Identify user situations** that trigger the need
+2. **Define motivations** underlying the user's behavior
+3. **Clarify outcomes** the user wants to achieve
+4. **Apply JTBD framework:** Focus on the job, not the role
+5. **Create acceptance criteria** that validate the outcome is achieved
+6. **Use observable, measurable language**
+7. **Link to design mockups** or prototypes
+8. **Output job stories** with detailed acceptance criteria
+
+## Story Template
+
+**Title:** [Job outcome or result]
+
+**Description:** When [situation], I want to [motivation], so I can [outcome].
+
+**Design:** [Link to design files]
+
+**Acceptance Criteria:**
+1. [Situation is properly recognized]
+2. [System enables the desired motivation]
+3. [Progress or feedback is visible]
+4. [Outcome is achieved efficiently]
+5. [Edge cases are handled gracefully]
+6. [Integration and notifications work]
+
+## Example Job Story
+
+**Title:** Track Weekly Snack Spending
+
+**Description:** When I'm preparing my weekly allowance for snacks (situation), I want to quickly see how much I've spent so far (motivation), so I can make sure I don't run out of money before the weekend (outcome).
+
+**Design:** [Figma link]
+
+**Acceptance Criteria:**
+1. Display Spending Summary with 'Weekly Spending Overview' section
+2. Real-Time Update when expense logged
+3. Progress Indicator (progress bar showing 0-100% of weekly budget)
+4. Remaining Budget Highlight in prominent color
+5. Detailed Spending Log with breakdown by category
+6. Notifications at 80% budget threshold
+7. Weekend-Specific Reminder at 90% by Thursday evening
+8. Easy Access and Navigation to detailed breakdown
+
+## Output Deliverables
+
+- Complete set of job stories for the feature
+- Each story follows the 'When...I want...so I can' format
+- 6-8 acceptance criteria focused on outcomes
+- Stories emphasize user situations and motivations
+- Clear links to design and prototypes
+
+---
+
+### Further Reading
+
+- [Jobs-to-be-Done Masterclass with Tony Ulwick and Sabeen Sattar](https://www.productcompass.pm/p/jobs-to-be-done-masterclass-with) (video course)

pm-execution/skills/outcome-roadmap/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: outcome-roadmap
+description: "Transform an output-focused roadmap into an outcome-focused one. Rewrites initiatives as outcome statements reflecting user and business impacts. Use when shifting from output to outcome roadmaps, rewriting a feature roadmap, or making a roadmap more strategic. Triggers: outcome roadmap, outcome-focused, rewrite roadmap, strategic roadmap, outcome statements."
+---
+
+# Transform Roadmap to Outcome-Focused Format
+
+## Purpose
+
+You are an experienced product manager helping $ARGUMENTS shift from output-focused roadmaps (which emphasize features) to outcome-focused roadmaps (which emphasize customer and business impact). This skill rewrites initiatives as outcome statements that inspire and measure what matters.
+
+## Context
+
+Output-focused roadmaps create false precision and misalign teams around features rather than results. Outcome-focused roadmaps clarify the customer problems being solved and the business value expected, enabling flexible execution and strategic thinking.
+
+## Instructions
+
+1. **Gather Information**: If the user provides a current roadmap, read it carefully. If they mention strategy documents or company objectives, use web search to understand how the roadmap should align with broader goals.
+
+2. **Think Step by Step**:
+   - For each initiative, ask: "What outcome are we trying to achieve?"
+   - What customer problem are we solving?
+   - What business metric will improve?
+   - How will this impact the customer experience or business?
+   - Is there a better, different way to achieve the same outcome?
+
+3. **Transformation Process**: For each initiative on the roadmap:
+   - **Identify the Output**: What feature or project is planned?
+   - **Uncover the Outcome**: Why are we building it? What changes for customers or business?
+   - **Rewrite as Outcome Statement**: Use this format:
+     ```
+     Enable [customer segment] to [desired customer outcome] so that [business impact]
+     ```
+
+4. **Example Transformation**:
+   - **Output (Old)**: Q2: Build advanced search filters, implement AI recommendations, redesign dashboard
+   - **Outcome (New)**:
+     - Q2: Enable customers to find products 50% faster through intuitive discovery
+     - Q2: Increase average order value by 20% through personalized AI recommendations
+     - Q2: Help operators monitor all systems with 80% reduction in dashboard load time
+
+5. **Structure Output**: Present the transformed roadmap with:
+   - Original initiatives listed by quarter/phase
+   - Outcome statements for each initiative
+   - Key metrics that will indicate success
+   - Dependencies or sequencing notes
+
+6. **Include Strategic Context**: For the overall roadmap, add:
+   - How outcomes align with company strategy
+   - Key assumptions about customer needs
+   - Flexible release windows (quarters, not specific dates)
+
+7. **Save the Output**: If substantial, save as a markdown document: `Outcome-Roadmap-[year].md`
+
+## Notes
+
+- An outcome should be testable and measurable
+- Multiple outputs may achieve one outcome; focus on the outcome, not the feature list
+- Outcome roadmaps are more resilient to change—embrace flexibility
+- If unsure what outcome a feature drives, ask: "So what?" until you reach real customer/business value
+
+---
+
+### Further Reading
+
+- [Product Vision vs Strategy vs Objectives vs Roadmap: The Advanced Edition](https://www.productcompass.pm/p/product-vision-strategy-goals-and)
+- [Objectives and Key Results (OKRs) 101](https://www.productcompass.pm/p/okrs-101-advanced-techniques)
+- [Business Outcomes vs Product Outcomes vs Customer Outcomes](https://www.productcompass.pm/p/business-outcomes-vs-product-outcomes)

pm-execution/skills/pre-mortem/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: pre-mortem
+description: "Run a pre-mortem analysis on a PRD. Categorizes risks as Tigers (real problems), Paper Tigers (overblown concerns), and Elephants (unspoken worries), then classifies Tigers as launch-blocking, fast-follow, or track. Use when preparing for launch, risk-assessing a PRD, or stress-testing a product plan. Triggers: pre-mortem, launch risks, what could go wrong, risk analysis PRD, stress test plan."
+---
+
+# Pre-Mortem: Risk Analysis for Product Launch
+
+## Purpose
+
+You are a veteran product manager conducting a pre-mortem analysis on $ARGUMENTS. This skill imagines launch failure and works backward to identify real risks, distinguish them from perceived worries, and create action plans to mitigate launch-blocking issues.
+
+## Context
+
+A pre-mortem is a structured risk-identification exercise that forces teams to think critically about what could go wrong before launch, when there's still time to act. By assuming failure, we surface hidden concerns and separate legitimate threats from overblown worries.
+
+## Instructions
+
+1. **Gather the PRD**: If the user provides a PRD or product plan file, read it thoroughly. Understand the product, target market, key assumptions, and timeline. If relevant, use web search to research competitive landscape or market conditions.
+
+2. **Think Step by Step**:
+   - Imagine the product launches in 14 days
+   - Now imagine it fails—customers don't adopt it, revenue targets miss, reputation takes a hit
+   - What went wrong?
+   - What did we miss or not execute well?
+   - What were we overconfident about?
+
+3. **Categorize Risks**: Classify each potential failure as one of three types:
+
+   **Tigers**: Real problems you personally see that could derail the project
+   - Based on evidence, past experience, or clear logic
+   - Should keep you awake at night
+   - Require action
+
+   **Paper Tigers**: Problems others might worry about, but you don't believe in them
+   - Valid concerns on the surface, but unlikely or overblown
+   - Not worth significant resource investment
+   - Worth documenting to align stakeholders
+
+   **Elephants**: Something you're not sure is a problem, but the team isn't discussing it enough
+   - Unspoken concerns or assumptions nobody is validating
+   - Could be real; you're unsure
+   - Deserve investigation before launch
+
+4. **Classify Tigers by Urgency**:
+
+   **Launch-Blocking**: Must be solved before launch
+   - Example: Core feature broken, regulatory blocker, key customer dependency unmet
+
+   **Fast-Follow**: Must be solved within 30 days post-launch
+   - Example: Performance issues, secondary features incomplete
+
+   **Track**: Monitor post-launch; solve if it becomes an issue
+   - Example: Nice-to-have features, edge cases
+
+5. **Create Action Plans**: For every Launch-Blocking Tiger:
+   - Describe the risk clearly
+   - Suggest a concrete mitigation action
+   - Identify the best owner (function/person)
+   - Set a decision/completion date
+
+6. **Structure Output**: Present the analysis as:
+
+   ```
+   ## Pre-Mortem Analysis: [Product Name]
+
+   ### Tigers (Real Risks)
+   [List each real risk with category and mitigation plan]
+
+   ### Paper Tigers (Overblown Concerns)
+   [List each, explain why it's not a true risk]
+
+   ### Elephants (Unspoken Worries)
+   [List each, recommend investigation approach]
+
+   ### Action Plans for Launch-Blocking Tigers
+   [For each, include: Risk, Mitigation, Owner, Due Date]
+   ```
+
+7. **Save the Output**: Save as a markdown document: `PreMortem-[product-name]-[date].md`
+
+## Notes
+
+- Be honest and constructive—the goal is to improve launch readiness, not assign blame
+- Default to "Tiger" if unsure; it's better to address risks early
+- Involve cross-functional perspectives (engineering, design, go-to-market) in your analysis
+- Revisit the pre-mortem 2-3 weeks before launch to verify mitigations are on track
+
+---
+
+### Further Reading
+
+- [How Meta and Instagram Use Pre-Mortems to Avoid Post-Mortems](https://www.productcompass.pm/p/how-to-run-pre-mortem-template)
+- [How to Manage Risks as a Product Manager](https://www.productcompass.pm/p/how-to-manage-risks-as-a-product-manager)

pm-execution/skills/prioritization-frameworks/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: prioritization-frameworks
+description: "Reference guide to 9 prioritization frameworks with formulas, when-to-use guidance, and templates. Covers Opportunity Score, ICE, RICE, Kano, MoSCoW, and more. Use when selecting a prioritization method, comparing frameworks, or needing formula definitions. Triggers: prioritization framework, which framework, ICE, RICE, opportunity score, Kano, MoSCoW, how to prioritize."
+---
+
+## Prioritization Frameworks Reference
+
+A reference guide to help you select and apply the right prioritization framework for your context.
+
+### Core Principle
+
+Never allow customers to design solutions. Prioritize **problems (opportunities)**, not features.
+
+### Opportunity Score (Dan Olsen, *The Lean Product Playbook*)
+
+The recommended framework for prioritizing customer problems.
+
+Survey customers on **Importance** and **Satisfaction** for each need (normalize to 0–1 scale).
+
+Three related formulas:
+- **Current value** = Importance × Satisfaction
+- **Opportunity Score** = Importance × (1 − Satisfaction)
+- **Customer value created** = Importance × (S2 − S1), where S1 = satisfaction before, S2 = satisfaction after
+
+High Importance + low Satisfaction = highest Opportunity Score = best opportunities. Plot on an Importance vs Satisfaction chart — upper-left quadrant is the sweet spot. Prioritizes customer problems, not solutions.
+
+### ICE Framework
+
+Useful for prioritizing initiatives and ideas. Considers not only value but also risk and economic factors.
+
+- **I** (Impact) = Opportunity Score × Number of Customers affected
+- **C** (Confidence) = How confident are we? (1-10). Accounts for risk.
+- **E** (Ease) = How easy is it to implement? (1-10). Accounts for economic factors.
+
+**Score** = I × C × E. Higher = prioritize first.
+
+### RICE Framework
+
+Splits ICE's Impact into two separate factors. Useful for larger teams that need more granularity.
+
+- **R** (Reach) = Number of customers affected
+- **I** (Impact) = Opportunity Score (value per customer)
+- **C** (Confidence) = How confident are we? (0-100%)
+- **E** (Effort) = How much effort to implement? (person-months)
+
+**Score** = (R × I × C) / E
+
+### 9 Frameworks Overview
+
+| Framework | Best For | Key Insight |
+|-----------|----------|-------------|
+| Eisenhower Matrix | Personal tasks | Urgent vs Important — for individual PM task management |
+| Impact vs Effort | Tasks/initiatives | Simple 2×2 — quick triage, not rigorous for strategic decisions |
+| Risk vs Reward | Initiatives | Like Impact vs Effort but accounts for uncertainty |
+| **Opportunity Score** | Customer problems | **Recommended.** Importance × (1 − Satisfaction). Normalize to 0–1. |
+| Kano Model | Understanding expectations | Must-be, Performance, Attractive, Indifferent, Reverse. For understanding, not prioritizing. |
+| Weighted Decision Matrix | Multi-factor decisions | Assign weights to criteria, score each option. Useful for stakeholder buy-in. |
+| **ICE** | Ideas/initiatives | Impact × Confidence × Ease. Recommended for quick prioritization. |
+| **RICE** | Ideas at scale | (Reach × Impact × Confidence) / Effort. Adds Reach to ICE. |
+| MoSCoW | Requirements | Must/Should/Could/Won't. Caution: project management origin. |
+
+### Templates
+
+- [Opportunity Score intro (PDF)](https://drive.google.com/file/d/1ENbYPmk1i1AKO7UnfyTuULL5GucTVufW/view)
+- [Importance vs Satisfaction Template — Dan Olsen (Google Slides)](https://docs.google.com/presentation/d/1jg-LuF_3QHsf6f1nE1f98i4C0aulnRNMOO1jftgti8M/edit#slide=id.g796641d975_0_3)
+- [ICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1LUfnsPolhZgm7X2oij-7EUe0CJT-Dwr-/edit?usp=share_link&ouid=111307342557889008106&rtpof=true&sd=true)
+- [RICE Template (Google Sheets)](https://docs.google.com/spreadsheets/d/1S-6QpyOz5MCrV7B67LUWdZkAzn38Eahv/edit?usp=sharing&ouid=111307342557889008106&rtpof=true&sd=true)
+
+---
+
+### Further Reading
+
+- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium)
+- [Kano Model: How to Delight Your Customers Without Becoming a Feature Factory](https://www.productcompass.pm/p/kano-model-how-to-delight-your-customers)
+- [Continuous Product Discovery Masterclass (CPDM)](https://www.productcompass.pm/p/cpdm) (video course)

pm-execution/skills/release-notes/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: release-notes
+description: "Generate user-facing release notes from tickets, PRDs, or changelogs. Creates clear, engaging summaries organized by category (new features, improvements, fixes). Use when writing release notes, creating changelogs, announcing product updates, or summarizing a release. Triggers: release notes, changelog, what's new, product update, release announcement, ship notes."
+---
+
+## Release Notes Generator
+
+Transform technical tickets, PRDs, or internal changelogs into polished, user-facing release notes.
+
+### Context
+
+You are writing release notes for **$ARGUMENTS**.
+
+If the user provides files (JIRA exports, Linear tickets, PRDs, Git logs, or internal changelogs), read them first. If they mention a product URL, use web search to understand the product and audience.
+
+### Instructions
+
+1. **Gather raw material**: Read all provided tickets, changelogs, or descriptions. Extract:
+   - What changed (feature, improvement, or fix)
+   - Who it affects (which user segment)
+   - Why it matters (the user benefit)
+
+2. **Categorize changes**:
+   - **New Features**: Entirely new capabilities
+   - **Improvements**: Enhancements to existing features
+   - **Bug Fixes**: Issues resolved
+   - **Breaking Changes**: Anything that requires user action (migrations, API changes)
+   - **Deprecations**: Features being sunset
+
+3. **Write each entry** following these principles:
+   - Lead with the user benefit, not the technical change
+   - Use plain language — avoid jargon, internal codenames, or ticket numbers
+   - Keep each entry to 1-3 sentences
+   - Include visuals or screenshots if the user provides them
+
+   **Example transformations**:
+   - Technical: "Implemented Redis caching layer for dashboard API endpoints"
+   - User-facing: "Dashboards now load up to 3× faster, so you spend less time waiting and more time analyzing."
+
+   - Technical: "Fixed race condition in concurrent checkout flow"
+   - User-facing: "Fixed an issue where some orders could fail during high-traffic periods."
+
+4. **Structure the release notes**:
+
+   ```
+   # [Product Name] — [Version / Date]
+
+   ## New Features
+   - **[Feature name]**: [1-2 sentence description of what it does and why it matters]
+
+   ## Improvements
+   - **[Area]**: [What got better and how it helps]
+
+   ## Bug Fixes
+   - Fixed [issue description in user terms]
+
+   ## Breaking Changes (if any)
+   - **Action required**: [What users need to do]
+   ```
+
+5. **Adjust tone** to match the product's voice — professional for B2B, friendly for consumer, developer-focused for APIs.
+
+Save as a markdown document. If the user wants HTML or another format, convert accordingly.

pm-execution/skills/retro/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: retro
+description: "Facilitate a structured sprint retrospective. Analyzes what went well, what didn't, and generates prioritized action items with owners and deadlines. Use when running a retrospective, reflecting on a sprint, or creating action items from team feedback. Triggers: retro, retrospective, sprint retro, what went well, lessons learned, team reflection."
+---
+
+## Sprint Retrospective Facilitator
+
+Run a structured retrospective that surfaces insights and produces actionable improvements.
+
+### Context
+
+You are facilitating a retrospective for **$ARGUMENTS**.
+
+If the user provides files (sprint data, velocity charts, team feedback, or previous retro notes), read them first.
+
+### Instructions
+
+1. **Choose a retro format** based on context (or let the user pick):
+
+   **Format A — Start / Stop / Continue**:
+   - **Start**: What should we begin doing?
+   - **Stop**: What should we stop doing?
+   - **Continue**: What's working well that we should keep?
+
+   **Format B — 4Ls (Liked / Learned / Lacked / Longed For)**:
+   - **Liked**: What did the team enjoy?
+   - **Learned**: What new knowledge was gained?
+   - **Lacked**: What was missing?
+   - **Longed For**: What do we wish we had?
+
+   **Format C — Sailboat**:
+   - **Wind (propels us)**: What's driving us forward?
+   - **Anchor (holds us back)**: What's slowing us down?
+   - **Rocks (risks)**: What dangers lie ahead?
+   - **Island (goal)**: Where are we trying to get to?
+
+2. **If the user provides raw feedback** (e.g., sticky notes, survey responses, Slack messages):
+   - Group similar items into themes
+   - Identify the most frequently mentioned topics
+   - Note sentiment patterns (frustration, energy, confusion)
+
+3. **Analyze the sprint performance**:
+   - Sprint goal: achieved or not?
+   - Velocity vs. commitment (over-committed? under-committed?)
+   - Blockers encountered and how they were resolved
+   - Collaboration patterns (what worked, what didn't)
+
+4. **Generate prioritized action items**:
+
+   | Priority | Action Item | Owner | Deadline | Success Metric |
+   |---|---|---|---|---|
+   | 1 | [Specific, actionable improvement] | [Name/Role] | [Date] | [How we'll know it worked] |
+
+   - Limit to 2-3 action items (more won't get done)
+   - Each must be specific, assignable, and measurable
+   - Reference previous retro actions if available — were they completed?
+
+5. **Create the retro summary**:
+   ```
+   ## Sprint [X] Retrospective — [Date]
+
+   ### Sprint Performance
+   - Goal: [Achieved / Partially / Missed]
+   - Committed: [X pts] | Completed: [Y pts]
+
+   ### Key Themes
+   1. [Theme] — [summary]
+
+   ### Action Items
+   1. [Action] — [Owner] — [By date]
+
+   ### Carry-over from Last Retro
+   - [Previous action] — [Status: Done / In Progress / Not Started]
+   ```
+
+Save as markdown. Keep the tone constructive — the goal is improvement, not blame.

pm-execution/skills/sprint-plan/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: sprint-plan
+description: "Plan a sprint with capacity estimation, story selection, dependency mapping, and risk identification. Use when preparing for sprint planning, estimating team capacity, selecting stories for a sprint, or balancing sprint scope. Triggers: sprint plan, sprint planning, capacity planning, sprint scope, what fits in the sprint, story points."
+---
+
+## Sprint Planning
+
+Plan a sprint by estimating team capacity, selecting and sequencing stories, and identifying risks.
+
+### Context
+
+You are helping plan a sprint for **$ARGUMENTS**.
+
+If the user provides files (backlogs, velocity data, team rosters, or previous sprint reports), read them first.
+
+### Instructions
+
+1. **Estimate team capacity**:
+   - Number of team members and their availability (PTO, meetings, on-call)
+   - Historical velocity (average story points per sprint from last 3 sprints)
+   - Capacity buffer: reserve 15-20% for unexpected work, bugs, and tech debt
+   - Calculate available capacity in story points or ideal hours
+
+2. **Review and select stories**:
+   - Pull from the prioritized backlog (highest priority first)
+   - Verify each story meets the Definition of Ready (clear AC, estimated, no blockers)
+   - Flag stories that need refinement before committing
+   - Stop adding stories when capacity is reached
+
+3. **Map dependencies**:
+   - Identify stories that depend on other stories or external teams
+   - Sequence dependent stories appropriately
+   - Flag external dependencies and owners
+   - Identify the critical path
+
+4. **Identify risks and mitigations**:
+   - Stories with high uncertainty or complexity
+   - External dependencies that could slip
+   - Knowledge concentration (only one person can do it)
+   - Suggest mitigations for each risk
+
+5. **Create the sprint plan summary**:
+
+   ```
+   Sprint Goal: [One sentence describing what success looks like]
+   Duration: [2 weeks / 1 week / etc.]
+   Team Capacity: [X story points]
+   Committed Stories: [Y story points across Z stories]
+   Buffer: [remaining capacity]
+
+   Stories:
+   1. [Story title] — [points] — [owner] — [dependencies]
+   ...
+
+   Risks:
+   - [Risk] → [Mitigation]
+   ```
+
+6. **Define the sprint goal**: A single, clear sentence that captures the sprint's primary value delivery.
+
+Think step by step. Save as markdown.
+
+---
+
+### Further Reading
+
+- [Product Owner vs Product Manager: What's the difference?](https://www.productcompass.pm/p/product-manager-vs-product-owner)

pm-execution/skills/stakeholder-map/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: stakeholder-map
+description: "Build a stakeholder map using a power/interest grid, identify communication strategies per quadrant, and generate a communication plan. Use when managing stakeholders, preparing for a launch, aligning cross-functional teams, or planning stakeholder engagement. Triggers: stakeholder map, stakeholder analysis, power interest grid, stakeholder management, communication plan, who to align."
+---
+
+## Stakeholder Mapping & Communication Plan
+
+Map stakeholders on a Power × Interest grid and create a tailored communication plan for each group.
+
+### Context
+
+You are helping build a stakeholder map for **$ARGUMENTS**.
+
+If the user provides files (org charts, project briefs, team rosters), read them first. If they describe the product or initiative, use that context to infer likely stakeholders.
+
+### Instructions
+
+1. **Identify stakeholders**: List all relevant individuals and groups — executives, engineering leads, designers, marketing, sales, support, legal, finance, external partners, and end users.
+
+2. **Classify each stakeholder** on two dimensions:
+   - **Power** (High/Low): Their ability to influence decisions, resources, or outcomes
+   - **Interest** (High/Low): How much the project directly affects them or how engaged they are
+
+3. **Place stakeholders in the Power × Interest grid**:
+
+   | | High Interest | Low Interest |
+   |---|---|---|
+   | **High Power** | **Manage Closely** — Regular 1:1s, involve in decisions, seek their input early | **Keep Satisfied** — Periodic updates, escalate only critical issues |
+   | **Low Power** | **Keep Informed** — Regular status updates, invite to demos, gather feedback | **Monitor** — Light-touch updates, available on request |
+
+4. **For each quadrant**, recommend:
+   - Communication frequency (daily, weekly, bi-weekly, monthly)
+   - Communication format (1:1, email, Slack, meeting, dashboard)
+   - Key messages and framing
+   - Potential risks if this stakeholder is neglected
+
+5. **Create a communication plan table**:
+
+   | Stakeholder | Role | Power | Interest | Strategy | Frequency | Channel | Key Message |
+   |---|---|---|---|---|---|---|---|
+
+6. **Flag potential conflicts**: Identify stakeholders with competing interests and suggest alignment strategies.
+
+Think step by step. Save the stakeholder map as a markdown document.
+
+---
+
+### Further Reading
+
+- [The Product Management Frameworks Compendium + Templates](https://www.productcompass.pm/p/the-product-frameworks-compendium)
+- [Team Topologies: A Handbook to Set and Scale Product Teams](https://www.productcompass.pm/p/team-topologies-a-handbook-to-set)

pm-execution/skills/summarize-meeting/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: summarize-meeting
+description: "Summarize a meeting transcript into a structured template with date, participants, topic, summary points, and action items. Use when processing meeting recordings, creating meeting notes, or summarizing any internal meeting. Triggers: summarize meeting, meeting notes, meeting summary, meeting minutes, recap meeting."
+---
+
+# Summarize Meeting
+
+## Purpose
+
+You are an experienced product manager responsible for creating clear, actionable meeting summaries from $ARGUMENTS. This skill transforms raw meeting transcripts into structured, accessible summaries that keep teams aligned and accountable.
+
+## Context
+
+Meeting summaries are how knowledge spreads and accountability stays clear in product teams. A well-structured summary captures decisions, key points, and action items in language everyone can understand, regardless of who attended.
+
+## Instructions
+
+1. **Gather the Meeting Content**: If the user provides a meeting transcript, recording, or notes file, read them thoroughly. If they mention a meeting that needs context, use web search to find any related materials or background documents.
+
+2. **Think Step by Step**:
+   - Who attended and what were their roles?
+   - What was the main topic or agenda?
+   - What decisions were made?
+   - What are the next steps and who owns them?
+   - Are there open questions or blockers?
+
+3. **Extract Key Information**:
+   - Identify main discussion topics
+   - Note decisions made during the meeting
+   - Flag any disagreements or concerns
+   - Determine action items with owners and due dates
+
+4. **Create Structured Summary**: Use this template:
+
+   ```
+   ## Meeting Summary
+
+   **Date & Time**: [Date and start/end time]
+
+   **Participants**: [Full names and roles, if available]
+
+   **Topic**: [Short title—what was the meeting about?]
+
+   **Summary**
+
+   - **Point 1**: [Key discussion point or decision]
+   - **Point 2**: [Key discussion point or decision]
+   - **Point 3**: [Key discussion point or decision]
+   - [Additional points as needed]
+
+   **Action Items**
+
+   | Due Date | Owner | Action |
+   |----------|-------|--------|
+   | [Date] | [Name] | [What needs to happen] |
+   | [Date] | [Name] | [What needs to happen] |
+
+   **Decisions Made**
+   - [Decision 1]
+   - [Decision 2]
+
+   **Open Questions**
+   - [Unresolved question 1]
+   - [Unresolved question 2]
+   ```
+
+5. **Use Accessible Language**: Write for a primary school graduate. Use simple terms. Avoid jargon or explain it briefly.
+
+6. **Prioritize Clarity**: Focus on:
+   - What decisions affect the roadmap or strategy?
+   - What does each person need to do?
+   - By when do they need to do it?
+
+7. **Save the Output**: Save as a markdown document: `Meeting-Summary-[date]-[topic].md`
+
+## Notes
+
+- Be objective—summarize what was discussed, not personal opinions
+- Highlight action items clearly so nothing falls through the cracks
+- If the meeting was large or complex, consider breaking points into sections by topic
+- Use "we" language to keep the team feel inclusive and collaborative

pm-execution/skills/test-scenarios/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: test-scenarios
+description: "Create comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step actions, and expected outcomes. Use when writing QA test cases, creating test plans, or defining acceptance tests. Triggers: test scenarios, test cases, QA scenarios, acceptance tests."
+---
+# Test Scenarios
+
+Create comprehensive test scenarios from user stories with test objectives, starting conditions, user roles, step-by-step test actions, and expected outcomes.
+
+**Use when:** Writing QA test cases, creating test plans, defining acceptance test scenarios, or validating user story implementations.
+
+**Arguments:**
+- `$PRODUCT`: The product or system name
+- `$USER_STORY`: The user story to test (title and acceptance criteria)
+- `$CONTEXT`: Additional testing context or constraints
+
+## Step-by-Step Process
+
+1. **Review the user story** and acceptance criteria
+2. **Define test objectives** - What specific behavior to validate
+3. **Establish starting conditions** - System state, data setup, configurations
+4. **Identify user roles** - Who performs the test actions
+5. **Create test steps** - Break down interactions step-by-step
+6. **Define expected outcomes** - Observable results after each step
+7. **Consider edge cases** - Invalid inputs, boundary conditions
+8. **Output detailed test scenarios** - Ready for QA execution
+
+## Scenario Template
+
+**Test Scenario:** [Clear scenario name]
+
+**Test Objective:** [What this test validates]
+
+**Starting Conditions:**
+- [System state required]
+- [Data or configuration needed]
+- [User setup or permissions]
+
+**User Role:** [Who performs the test]
+
+**Test Steps:**
+1. [First action and its expected result]
+2. [Second action and observable outcome]
+3. [Third action and system behavior]
+4. [Completion action and final state]
+
+**Expected Outcomes:**
+- [Observable result 1]
+- [Observable result 2]
+- [Observable result 3]
+
+## Example Test Scenario
+
+**Test Scenario:** View Recently Viewed Products on Product Page
+
+**Test Objective:** Verify that the 'Recently viewed' section displays correctly and excludes the current product.
+
+**Starting Conditions:**
+- User is logged in or has browser history enabled
+- User has viewed at least 2 products in the current session
+- User is now on a product page different from previously viewed items
+
+**User Role:** Online Shopper
+
+**Test Steps:**
+1. Navigate to any product page → Section should appear at bottom with previously viewed items
+2. Scroll to bottom of page → "Recently viewed" section is visible with product cards
+3. Verify product thumbnails → Images, titles, and prices are displayed correctly
+4. Check current product → Current product is NOT in the recently viewed list
+5. Click on a product card → User navigates to the corresponding product page
+
+**Expected Outcomes:**
+- Recently viewed section appears only after viewing at least 1 prior product
+- Section displays 4-8 product cards with complete information
+- Current product is excluded from the list
+- Each card shows "Viewed X minutes/hours ago" timestamp
+- Clicking cards navigates to correct product pages
+- Performance: Section loads within 2 seconds
+
+## Output Deliverables
+
+- Comprehensive test scenarios for each acceptance criterion
+- Clear test objectives aligned with user story intent
+- Detailed step-by-step test actions
+- Observable expected outcomes after each step
+- Edge case and error scenario coverage
+- Ready for QA team execution and documentation

pm-execution/skills/user-stories/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: user-stories
+description: "Create user stories following the 3 C's (Card, Conversation, Confirmation) and INVEST criteria with descriptions, design links, and acceptance criteria. Use when writing user stories, breaking down features, or creating backlog items. Triggers: user stories, backlog story, acceptance criteria."
+---
+# User Stories
+
+Create user stories following the 3 C's (Card, Conversation, Confirmation) and INVEST criteria. Generates stories with descriptions, design links, and acceptance criteria.
+
+**Use when:** Writing user stories, breaking down features into stories, creating backlog items, or defining acceptance criteria.
+
+**Arguments:**
+- `$PRODUCT`: The product or system name
+- `$FEATURE`: The new feature to break into stories
+- `$DESIGN`: Link to design files (Figma, Miro, etc.)
+- `$ASSUMPTIONS`: Key assumptions or context
+
+## Step-by-Step Process
+
+1. **Analyze the feature** based on provided design and context
+2. **Identify user roles** and distinct user journeys
+3. **Apply 3 C's framework:**
+   - Card: Simple title and one-liner
+   - Conversation: Detailed discussion of intent
+   - Confirmation: Clear acceptance criteria
+4. **Respect INVEST criteria:** Independent, Negotiable, Valuable, Estimable, Small, Testable
+5. **Use plain language** a primary school graduate can understand
+6. **Link to design files** for visual reference
+7. **Output user stories** in structured format
+
+## Story Template
+
+**Title:** [Feature name]
+
+**Description:** As a [user role], I want to [action], so that [benefit].
+
+**Design:** [Link to design files]
+
+**Acceptance Criteria:**
+1. [Clear, testable criterion]
+2. [Observable behavior]
+3. [System validates correctly]
+4. [Edge case handling]
+5. [Performance or accessibility consideration]
+6. [Integration point]
+
+## Example User Story
+
+**Title:** Recently Viewed Section
+
+**Description:** As an Online Shopper, I want to see a 'Recently viewed' section on the product page to easily revisit items I considered.
+
+**Design:** [Figma link]
+
+**Acceptance Criteria:**
+1. The 'Recently viewed' section is displayed at the bottom of the product page for every user who has previously viewed at least 1 product.
+2. It is not displayed for users visiting the first product page of their session.
+3. The current product itself is excluded from the displayed items.
+4. The section showcases product cards or thumbnails with images, titles, and prices.
+5. Each product card indicates when it was viewed (e.g., 'Viewed 5 minutes ago').
+6. Clicking on a product card leads the user to the corresponding product page.
+
+## Output Deliverables
+
+- Complete set of user stories for the feature
+- Each story includes title, description, design link, and 4-6 acceptance criteria
+- Stories are independent and can be developed in any order
+- Stories are sized for one sprint cycle
+- Stories reference related design documentation
+
+---
+
+### Further Reading
+
+- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories)

pm-execution/skills/wwas/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: wwas
+description: "Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context. Use when writing backlog items or breaking features into work items. Triggers: WWA, why what acceptance, backlog items, work items."
+---
+# Why-What-Acceptance (WWA)
+
+Create product backlog items in Why-What-Acceptance format. Produces independent, valuable, testable items with strategic context.
+
+**Use when:** Writing backlog items, creating product increments, breaking features into work items, or communicating strategic intent to teams.
+
+**Arguments:**
+- `$PRODUCT`: The product or system name
+- `$FEATURE`: The new feature or capability
+- `$DESIGN`: Link to design files (Figma, Miro, etc.)
+- `$ASSUMPTIONS`: Key assumptions and strategic context
+
+## Step-by-Step Process
+
+1. **Define the strategic Why** - Connect work to business and team objectives
+2. **Describe the What** - Keep descriptions concise, reference designs
+3. **Write Acceptance Criteria** - High-level, not detailed specifications
+4. **Ensure independence** - Items can be developed in any order
+5. **Keep items negotiable** - Invite team conversation, not constraints
+6. **Make items valuable** - Each delivers measurable user or business value
+7. **Ensure testability** - Outcomes are observable and verifiable
+8. **Size appropriately** - Small enough for one sprint estimate
+
+## Item Template
+
+**Title:** [What will be delivered]
+
+**Why:** [1-2 sentences connecting to strategic context and team objectives]
+
+**What:** [Short description and design link. 1-2 paragraphs maximum. A reminder of discussion, not detailed specification.]
+
+**Acceptance Criteria:**
+- [Observable outcome 1]
+- [Observable outcome 2]
+- [Observable outcome 3]
+- [Observable outcome 4]
+
+## Example WWA Item
+
+**Title:** Implement Real-Time Spending Tracker
+
+**Why:** Users need immediate feedback on spending to make conscious budget decisions. This directly supports our goal to improve financial awareness and reduce overspending.
+
+**What:** Add a real-time spending tracker that updates as users log expenses. The tracker displays their current week's spending against their set budget. Designs available in [Figma link]. This is a reminder of our discussions - detailed specifications will emerge during development conversations with the team.
+
+**Acceptance Criteria:**
+- Spending totals update within 2 seconds of logging an expense
+- Budget progress is visually indicated with a progress bar
+- Users can see remaining budget amount at a glance
+- System handles multiple expense categories correctly
+
+## Output Deliverables
+
+- Complete set of backlog items for the feature
+- Each item includes Why, What, and Acceptance Criteria sections
+- Items are independent and deliverable in any order
+- Items are sized for estimation and completion in one sprint
+- Strategic context is clear for team decision-making
+- Design references are included for implementation guidance
+
+---
+
+### Further Reading
+
+- [How to Write User Stories: The Ultimate Guide](https://www.productcompass.pm/p/how-to-write-user-stories)