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

Windsurf + Aider targets, MCP server, and demo placement (#33)

Browse Source 
Broadens both reach (more tools) and content types (an MCP server), continuing
the multi-platform story.

Windsurf + Aider:
- build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules,
  trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`).
  Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider).
- install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider ->
  .aider/skills with a --read hint); generated README index is excluded from copies.
- One-line windsurf-install.sh / aider-install.sh wrappers for parity.

MCP server (new content type):
- mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills,
  search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp).
  Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents
  client config.

Also: README hero "See it in action" demo placement (ready to swap in a GIF;
recording guide in web/docs-assets/README.md), Works-With table + exports +
install docs updated, CHANGELOG Unreleased. package.json files/bin updated.


Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px

Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
2026-06-17 23:15:38 +01:00
committed by GitHub
parent 123aabe5e3
commit 036511ab3e
358 changed files with 60408 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
exports/windsurf/pm-delivery/ab-test-planner/ab-test-planner.md
+121
View File
@@ -0,0 +1,121 @@
---
trigger: model_decision
description: "Design statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide."
---
# A/B Test Planner Skill
Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
## Required Inputs
Ask the user for these if not provided:
- **What is being tested** (feature, UI change, copy, pricing, onboarding step)
- **Hypothesis** (or ask to help formulate one)
- **Primary metric** (conversion rate, click-through, completion rate, etc.)
- **Baseline rate** and **minimum detectable effect** (MDE)
- **Daily eligible users** (to calculate duration)
## Experiment Design Checklist
Before running any test, confirm:
- [ ] Clear hypothesis with predicted direction
- [ ] Single primary metric (plus up to 2 guardrail metrics)
- [ ] Minimum detectable effect (MDE) defined
- [ ] Sample size calculated
- [ ] Test duration estimated
- [ ] Segment isolated (no overlap with other running tests)
- [ ] Rollback plan defined
## Hypothesis Template
> "We believe that [change] will cause [primary metric] to [increase/decrease] by [X%] for [user segment], because [rationale based on data or insight]."
Never run a test without a directional hypothesis. "Let's just see what happens" is not a hypothesis.
## Sample Size Calculator Logic
Use this formula (provide the output, not the formula, to the user):
- **Baseline conversion rate:** Current rate of primary metric
- **MDE:** Smallest change worth detecting (recommend 10–20% relative lift for most features)
- **Statistical power:** 80% (standard)
- **Significance level:** 95% (p < 0.05)
For common scenarios, provide pre-calculated estimates:
| Baseline Rate | MDE (Relative) | Required Sample per Variant |
|---|---|---|
| 5% | 20% | ~19,000 |
| 10% | 15% | ~14,000 |
| 20% | 10% | ~15,000 |
| 40% | 10% | ~9,500 |
| 60% | 5% | ~42,000 |
Always warn: "These are estimates. Use a tool like Evan Miller's calculator or Statsig for precision."
## Test Duration Guidance
Minimum: 2 full weeks (to capture weekly seasonality)
Maximum: 4 weeks (novelty effect distorts results beyond this)
`Duration = Required sample ÷ (Daily traffic × % exposed)`
Flag if traffic is too low to reach significance in under 8 weeks — recommend a different approach (e.g., holdout test, qualitative research).
## Output Format
### A/B Test Plan — [Test Name] — [Date]
**Hypothesis:**
> [Filled hypothesis template]
**Variants:**
- Control (A): [Current experience]
- Treatment (B): [Changed experience — be specific]
**Primary Metric:** [Metric name + how measured]
**Guardrail Metrics:** [Metrics that must not degrade]
**Target Segment:** [Who sees the test — % of traffic, user type]
**Traffic Split:** [50/50 recommended unless ramp-up needed]
**Sample Size Required:** ~[N] users per variant
**Estimated Duration:** [X] weeks (based on [Y] daily eligible users)
**Significance Threshold:** 95% confidence, 80% power
**Exclusions:** [Any user segments to exclude and why]
**Rollback Trigger:** If [guardrail metric] degrades by [X%], stop the test immediately.
**Results Interpretation Guide:**
- ✅ Ship if: Treatment shows [X%]+ lift on primary metric at 95% confidence AND guardrail metrics are stable
- 🔄 Iterate if: Direction is positive but not significant — consider extending or redesigning
- ❌ Reject if: No lift or negative direction at significance
- ⚠️ Inconclusive: Do not ship. Do not call it a win.
---
## Guidelines
- Always recommend against peeking at results before the test reaches planned sample size — explain p-hacking risk
- If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
## Anti-Patterns
- [ ] Do not run a test without a directional hypothesis — "let's see what happens" produces uninterpretable results
- [ ] Do not declare a winner before reaching the pre-planned sample size — peeking at results inflates false positive rates
- [ ] Do not test multiple independent changes in a single variant — you won't know which change caused the result
- [ ] Do not use engagement metrics (clicks, time-on-page) as the primary metric when the goal is revenue or retention — proxy metrics mislead
- [ ] Do not ignore guardrail metrics — a conversion lift that causes a support ticket spike is not a win
## Quality Checks
- [ ] Hypothesis is directional (predicts a specific direction and magnitude, not "let's see")
- [ ] Primary metric is singular (guardrail metrics are secondary)
- [ ] Sample size is calculated from actual MDE and baseline (not guessed)
- [ ] Test duration accounts for weekly seasonality (minimum 2 weeks)
- [ ] Guardrail metrics are defined (at least one to protect revenue or core engagement)
- [ ] Rollback trigger is specified with a concrete threshold
exports/windsurf/pm-delivery/go-to-market-planner/go-to-market-planner.md
+141
View File
@@ -0,0 +1,141 @@
---
trigger: model_decision
description: "Build a go-to-market plan for any product launch, feature release, or new market entry. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Produces a tiered GTM plan with messaging, cross-functional activity tracker, success metrics, and launch day checklist."
---
# Go-to-Market Planner Skill
Produce a complete, cross-functional GTM plan that aligns product, marketing, sales, and support around a single launch — with clear owners, timelines, and success metrics.
## Launch Tier Framework
Before planning, classify the launch:
| Tier | Scope | Typical Effort | Examples |
|---|---|---|---|
| **Tier 1 — Major Launch** | New product / significant platform change | 8–12 weeks | New pricing model, platform rebrand, new product line |
| **Tier 2 — Feature Launch** | Significant new capability | 4–6 weeks | Major feature, API release, new integration |
| **Tier 3 — Incremental Release** | Improvement, bug fix, minor feature | 1–2 weeks | UI tweak, performance improvement, small enhancement |
Always confirm tier with the user before proceeding.
---
## GTM Plan Output Format
### GTM Plan — [Product/Feature Name] — [Launch Date]
**Launch Tier:** [1 / 2 / 3]
**Launch Owner (PM):** [Name]
**Target Launch Date:** [Date]
**Soft Launch Date (Beta/Limited):** [Date, if applicable]
---
### 1. What We're Launching
**One-line description:** [What it is, for whom, and why now]
**Key customer problem solved:** [Specific pain point]
**Key differentiator:** [Why ours, why now]
---
### 2. Target Audience
**Primary segment:** [Who benefits most — be specific]
**Secondary segment:** [Who else benefits]
**Not for:** [Who this is NOT for — helps sales and support]
---
### 3. Messaging
**Headline:** [Customer-facing headline — lead with outcome, not feature]
**Sub-headline:** [Supporting context — how it works or why it matters]
**3 key messages:**
1. [Problem solved]
2. [How it works / what's new]
3. [Proof / social proof / data]
**Elevator pitch (30 seconds):**
> [For [target user] who [has this problem], [product/feature] is a [category] that [key benefit]. Unlike [alternative], we [differentiator].]
---
### 4. Launch Activities by Function
| Function | Activity | Owner | Due Date | Status |
|---|---|---|---|---|
| Product | Feature flagging / rollout plan | PM | [date] | |
| Marketing | Blog post / landing page | Marketing | [date] | |
| Marketing | Email campaign to existing users | Marketing | [date] | |
| Marketing | Social media content | Marketing | [date] | |
| Sales | Sales enablement deck | PM + Sales | [date] | |
| Sales | FAQ for sales team | PM | [date] | |
| Support | Help centre articles | Support | [date] | |
| Support | Support team training | Support | [date] | |
| Engineering | Monitoring/alerting in place | Eng | [date] | |
---
### 5. Success Metrics
| Metric | Baseline | Target | Measurement Window |
|---|---|---|---|
| [Adoption metric] | [X] | [Y] | 30 days post-launch |
| [Engagement metric] | [X] | [Y] | 60 days post-launch |
| [Business metric] | [X] | [Y] | 90 days post-launch |
---
### 6. Risks & Contingencies
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [Risk] | H/M/L | H/M/L | [Action if it happens] |
---
### 7. Launch Day Checklist
- [ ] Feature live for [X%] of users
- [ ] Monitoring dashboard active
- [ ] Support team briefed
- [ ] Blog post published
- [ ] Email sent / scheduled
- [ ] Sales team notified
- [ ] Executive announcement sent (if Tier 1)
- [ ] Rollback procedure confirmed
---
## Required Inputs
Ask the user for these if not provided:
- **Product or feature name**
- **Target launch date**
- **Launch tier** (Tier 1 / 2 / 3 — or describe scope and the skill will classify)
- **Target audience** (who benefits and who it's NOT for)
- **Key message** (what's the headline outcome for the customer)
- **PM and launch owner**
## Guidelines
- Never plan a Tier 1 launch without at least 8 weeks of lead time
- Always include a "Not for" section — it prevents misdirected sales and support tickets
- Recommend a soft launch to 5–10% of users before full rollout for any Tier 1 or 2 launch
- Post-launch retrospective should be scheduled at launch planning time — don't leave it to chance
## Quality Checks
- [ ] Launch tier is confirmed and appropriate for scope
- [ ] "Not for" section is included to prevent misdirected sales and support
- [ ] Every function has at least one activity with a named owner and due date
- [ ] Success metrics include a measurement window (30/60/90 days)
- [ ] Rollback procedure is confirmed for Tier 1 and 2 launches
- [ ] Post-launch retrospective is scheduled
## Anti-Patterns
- [ ] Do not build a Tier 1 GTM plan for an incremental feature update — tier the launch appropriately before planning
- [ ] Do not create activity lists without named owners and due dates — unowned tasks do not get done
- [ ] Do not skip the rollback procedure for Tier 1 and 2 launches — every significant launch must have an abort plan
- [ ] Do not treat marketing and engineering as separate tracks — cross-functional coordination is the whole point of a GTM plan
- [ ] Do not set success metrics without a defined measurement window — "increase signups" is not a measurable target
exports/windsurf/pm-delivery/pptx-slide-auditor/pptx-slide-auditor.md
+101
View File
@@ -0,0 +1,101 @@
---
trigger: model_decision
description: "Audit a PowerPoint presentation for layout issues, text overflow, visual hierarchy problems, and consistency gaps. Use when asked to review a slide deck, check a presentation before a meeting, audit slides for layout problems, or QA a deck before sharing. Produces a slide-by-slide report with issues ranked by severity and specific fixes. Best used with Claude Opus 4.7 or newer for reliable slide-level vision analysis."
---
# PPTX Slide Auditor Skill
Runs a systematic visual and structural audit of a PowerPoint presentation — identifying layout issues, text overflow, inconsistent styling, weak visual hierarchy, and slides that will cause problems in a presentation setting. Built to leverage Opus 4.7 vision improvements for pixel-level layout analysis.
## Required Inputs
Ask the user for these if not provided:
- **The deck** (upload the .pptx file or individual slide screenshots)
- **Audience** (internal team / executive / external client / conference / investor)
- **Presentation mode** (presented live / sent to read / shared async on video)
- **Areas of concern** (optional — e.g. "I think slide 12 is overcrowded")
## Output Structure
### 1. Deck Overview
| Metric | Result |
|---|---|
| Total slides | N |
| Overall status | Ready / Minor fixes needed / Major revisions required |
| Readability score | /10 |
| Visual consistency score | /10 |
| Most common issue | [Pattern observed across multiple slides] |
### 2. Slide-by-Slide Audit
For each slide with issues:
**Slide N: [Slide title]**
- Status: Ready / Fix before sending / Major revision
- Issues found:
- [Specific issue with exact location — e.g. "Body text extends beyond the text frame on the right side"]
- [Issue 2]
- Suggested fix: [Specific action — move element, reduce text, resize]
Slides with no issues: just list the slide numbers. Do not write anything else about them.
### 3. Pattern Issues Across the Deck
Issues that repeat across multiple slides:
**[Pattern title — e.g. "Inconsistent body text size"]**
- Slides affected: [list]
- Root cause: [master slide issue / manual overrides / mixed templates]
- Fix: [Single action to resolve across all affected slides]
### 4. Visual Hierarchy Check
| Dimension | Status | Notes |
|---|---|---|
| Title consistency (size, font, colour) | Pass / Fail | |
| Body text readability at presentation distance | Pass / Fail | |
| Image placement alignment | Pass / Fail | |
| Whitespace and breathing room | Pass / Fail | |
| Data visualisation clarity | Pass / Fail / N/A | |
### 5. Audience-Specific Flags
Based on the stated audience:
- **Executive audience:** flag slides with too much text, complex tables, or unclear bottom-line messages
- **External client:** flag slides with internal jargon, unfinished placeholder text, or confidentiality concerns
- **Live presentation:** flag slides that will be hard to read from the back of a room
- **Async/video:** flag slides that assume a presenter voiceover
### 6. Prioritised Fix List
| # | Fix | Slide | Effort | Impact |
|---|---|---|---|---|
| 1 | [Specific fix] | Slide N | Low/Med/High | High |
Order by: fixes before handoff (critical) > consistency fixes (high) > polish (medium).
## Quality Checks
- [ ] Every issue references a specific slide number and location on the slide
- [ ] Pattern issues are identified separately from slide-specific issues
- [ ] Fix list is ordered by impact, not by slide order
- [ ] Audience-appropriate concerns flagged explicitly
- [ ] Slides without issues are listed briefly, not ignored
## Anti-Patterns
- [ ] Do not flag stylistic preferences as issues — only report genuine layout problems, overflow, and consistency errors
- [ ] Do not produce a flat list of issues — group by severity (Critical / Major / Minor) so fixes can be prioritised
- [ ] Do not skip slides without commenting — every slide must have an explicit pass or issue status
- [ ] Do not suggest redesigning content — the audit scope is layout, consistency, and readability, not messaging
- [ ] Do not report the same issue type repeatedly across slides without summarising the pattern — consolidate repeated issues
## Example Trigger Phrases
- "Audit this slide deck before my board meeting"
- "Review this PowerPoint for layout issues"
- "Check this presentation for consistency problems"
- "QA my deck before I send it to the client"
- "What is wrong with slide 7 in this deck?"
## Why This Works Better on Opus 4.7
Earlier models struggled with precise spatial analysis of slide layouts — they would hallucinate issues or miss obvious overflow problems. Opus 4.7 vision improvements mean coordinates map 1:1 to pixels, making slide-level issue detection reliable without manual screenshot annotation.
exports/windsurf/pm-delivery/product-launch-checklist/product-launch-checklist.md
+142
View File
@@ -0,0 +1,142 @@
---
trigger: model_decision
description: "Generate a comprehensive pre-launch, launch day, and post-launch checklist for any product release. Use when preparing for a product launch, feature release, or major update. Produces a role-assigned, tiered checklist covering engineering readiness, marketing and comms, support, and post-launch monitoring."
---
# Product Launch Checklist Skill
Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
## Required Inputs
Ask the user for these if not provided:
- **Launch name** and planned launch date
- **Launch tier** (1 = major product launch, 2 = significant feature release, 3 = incremental update)
- **Team members and their roles** (engineering lead, PM, marketing, support, etc.)
- **Feature description** (what is being launched)
- **Rollback capability** (can this be feature-flagged or reverted quickly?)
## How to Use This Skill
Provide:
- Launch name and date
- Launch tier (1 = major, 2 = feature, 3 = incremental)
- Team members and their roles
The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections.
---
## Output Format
### Launch Checklist — [Feature/Product Name] — Target Date: [Date]
**Launch Tier:** [1 / 2 / 3]
**Launch Owner:** [PM Name]
**Engineering Lead:** [Name]
**Go/No-Go Decision By:** [Date and time — typically 24 hours before launch]
---
### 🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks)
- [ ] Feature flag created and tested in staging
- [ ] All acceptance criteria signed off by PM
- [ ] Code reviewed and merged to main
- [ ] QA sign-off completed (regression + new feature)
- [ ] Performance testing completed (load, latency)
- [ ] Security review completed (if data or auth changes)
- [ ] Rollback procedure documented and tested
- [ ] Monitoring and alerting configured
- [ ] Error logging in place with correct severity levels
- [ ] Database migrations tested on staging with production data volume
### 📢 PRE-LAUNCH — Marketing & Comms (T-1 week)
- [ ] Blog post written, reviewed, and scheduled
- [ ] In-app announcement or tooltip configured
- [ ] Email campaign drafted and QA'd
- [ ] Social media posts drafted and scheduled
- [ ] Landing page or feature page live in staging
- [ ] Press outreach sent (Tier 1 only)
- [ ] Product Hunt / community posts prepared (Tier 1 only)
### 🎓 PRE-LAUNCH — Sales & Support (T-1 week)
- [ ] Sales enablement one-pager completed
- [ ] FAQ document shared with sales and support teams
- [ ] Help centre articles written and published
- [ ] Support team demo / training completed
- [ ] Customer success team briefed on top accounts
- [ ] Pricing updated (if applicable)
- [ ] Contracts / ToS updated (if applicable)
### 📊 PRE-LAUNCH — Analytics (T-1 week)
- [ ] Analytics events firing correctly in staging
- [ ] Dashboard configured for launch metrics
- [ ] Baseline metrics documented
- [ ] Success criteria documented and shared with team
- [ ] A/B test configured (if applicable)
---
### ✅ GO / NO-GO DECISION — T-24 hours
| Criteria | Status | Owner |
|---|---|---|
| All critical bugs resolved | 🟢 / 🔴 | Eng Lead |
| QA sign-off complete | 🟢 / 🔴 | QA |
| Rollback tested | 🟢 / 🔴 | Eng Lead |
| Help centre articles live | 🟢 / 🔴 | Support |
| Monitoring active | 🟢 / 🔴 | Eng Lead |
| PM sign-off | 🟢 / 🔴 | PM |
**Go / No-Go Decision:** [GO / NO-GO]
**Decision Owner:** [PM + Eng Lead jointly]
---
### 🚀 LAUNCH DAY
- [ ] Feature flag enabled for [X%] of users (start low — 5–10%)
- [ ] Launch confirmed in team Slack/channel
- [ ] Metrics dashboard open and being monitored
- [ ] Error rate checked at T+15 min, T+1 hr, T+4 hr
- [ ] Blog post published / email sent
- [ ] Social posts live
- [ ] Support team on standby for first 4 hours
- [ ] PM available and reachable all day
- [ ] Feature flag expanded to 50% if T+2hr checks pass
- [ ] Feature flag expanded to 100% if T+4hr checks pass
---
### 📈 POST-LAUNCH (D+7, D+30)
- [ ] D+7 metrics review: adoption, errors, support tickets
- [ ] D+7 customer feedback synthesised
- [ ] Retrospective scheduled
- [ ] Learnings documented
- [ ] D+30 success metrics reviewed against targets
- [ ] Feature flag removed from codebase (clean up)
- [ ] Follow-up features added to backlog based on feedback
---
## Quality Checks
- [ ] Launch tier confirmed before generating checklist (scope determines depth)
- [ ] Go/No-Go decision has a named owner and a specific decision time
- [ ] Rollback procedure is documented and tested (not just planned)
- [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once
- [ ] Post-launch retrospective is scheduled at launch time
## Anti-Patterns
- [ ] Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist
- [ ] Do not launch on a Friday without confirmed weekend engineering coverage
- [ ] Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual
- [ ] Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live
- [ ] Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after
## Guidelines
- The Go/No-Go decision must have a named owner — "the team" is not an owner
- Never launch on a Friday unless you have weekend engineering coverage
- Recommend starting all launches at <10% traffic — even for simple features
- Document rollback time: "We can revert this in X minutes" should be known before launch
exports/windsurf/pm-delivery/retro-analysis/retro-analysis.md
+61
View File
@@ -0,0 +1,61 @@
---
trigger: model_decision
description: "Analyses sprint delivery data and produces a structured retrospective brief. Use when asked to run a retrospective, analyse sprint data, prepare a retro brief, or turn sprint metrics into discussion prompts. Produces a data-grounded retrospective brief with completion stats, pattern analysis, Start/Stop/Continue prompts, and one concrete experiment for next sprint."
---
# Retrospective Analysis Skill
Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
## Required Inputs
Ask the user for these if not provided:
- **Sprint tickets: planned vs. completed**
- **Carry-over tickets and reasons** (if known)
- **Tickets reopened after closing** (quality signal)
- **Any incidents or unplanned work** (scope creep signal)
- **Sprint velocity vs. historical average** (trend context)
## Process
1. Calculate: completion rate, carry-over rate, unplanned work percentage
2. Identify patterns: which ticket types were most likely to carry over? Which caused blockers?
3. Note any process or communication breakdowns visible in the data
4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
6. **Validate** — Confirm each prompt is specific to this sprint (not a recycled generic prompt), and that the recommended experiment is concrete and measurable
## Output Structure
### Sprint [Number] Retrospective Brief
**By the Numbers:**
- Planned: [n] tickets | Completed: [n] | Carry-over: [n] | Completion rate: [%]
- Unplanned work: [n] tickets ([%] of capacity)
- Velocity: [points] vs. [average] average
**What the Data Suggests:**
[2-3 observations grounded in the numbers above]
**Discussion Prompts:**
- Start: [specific prompt based on this sprint's data]
- Stop: [specific prompt based on this sprint's data]
- Continue: [specific prompt based on this sprint's data]
**Suggested Experiment for Next Sprint:**
[One concrete, testable process change — with a specific success metric]
## Quality Checks
- [ ] Each Start/Stop/Continue prompt names a specific behaviour, not a vague category
- [ ] The recommended experiment is testable in one sprint
- [ ] Carry-over analysis identifies the ticket type or cause, not just the count
- [ ] Data observations don't assign blame — they describe patterns
- [ ] Velocity trend is mentioned in context (is this a one-off or a pattern?)
## Anti-Patterns
- [ ] Do not assign blame to individuals in the retrospective brief — observations must describe patterns, not people
- [ ] Do not produce Start/Stop/Continue prompts that are vague categories — each must name a specific behaviour
- [ ] Do not recommend an experiment that cannot be completed within one sprint — small, testable experiments only
- [ ] Do not treat carry-over tickets as a velocity problem without first identifying the root cause category
- [ ] Do not run the same retrospective format every sprint — vary the format to prevent engagement fatigue
exports/windsurf/pm-delivery/sprint-brief/sprint-brief.md
+61
View File
@@ -0,0 +1,61 @@
---
trigger: model_decision
description: "Generate a structured sprint brief from sprint data and goals. Use when asked to write a sprint brief, create a sprint summary, document sprint goals and scope, or produce a team-facing sprint overview. Produces a scannable brief with sprint goal, rationale, grouped work, critical path, risks, and definition of done."
---
# Sprint Brief Skill
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
## Required Inputs
Ask the user for these if not provided:
- **Sprint name and number**
- **Sprint goal** (1-2 sentences — flag if too vague)
- **Ticket list with owners** (or a description of the work)
- **Known dependencies or blockers**
- **Carry-over items from previous sprint** (if any)
## Process
1. Read sprint goal and check it's specific and measurable — flag if it's too vague
2. Group tickets by theme or feature area
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
5. Note carry-over items and whether they affect this sprint's goal
6. **Validate** — Confirm the sprint goal is achievable given the ticket scope and capacity. If the critical path items alone would fill the sprint, flag it as overloaded.
## Output Structure
### Sprint [Number] Brief — [Dates]
**Sprint Goal:** [1-2 sentences — specific and measurable]
**Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
**What We're Building:**
- [Theme 1]: [tickets and owners]
- [Theme 2]: [tickets and owners]
**Critical Path:** [The 2-3 tickets everything else depends on]
**Risks to Flag:**
- [Risk 1 + mitigation]
- [Risk 2 + mitigation]
**Carry-over from Last Sprint:** [List + impact on current goal]
**Definition of Done:** [Specific, agreed criteria for sprint success]
## Quality Checks
- [ ] Sprint goal is specific enough to score pass/fail at the end of the sprint
- [ ] Critical path items are named — not just "the important ones"
- [ ] Every risk has a mitigation or owner (not just "this is a risk")
- [ ] Carry-over items are connected to their impact on this sprint's goal
- [ ] Definition of Done is agreed criteria, not a task list
## Anti-Patterns
- [ ] Do not write a sprint goal as a task list — the goal must be a single outcome-focused statement that can be scored pass/fail
- [ ] Do not leave the critical path unnamed — "the important tickets" is not a critical path
- [ ] Do not list risks without a mitigation or owner — a risk without a response is just a worry list
- [ ] Do not ignore carry-over items' impact on this sprint's capacity and goal
- [ ] Do not write a Definition of Done that mixes task completion with outcome criteria — they must be observable and agreed before the sprint starts
exports/windsurf/pm-delivery/sprint-planning/sprint-planning.md
+121
View File
@@ -0,0 +1,121 @@
---
trigger: model_decision
description: "Structure and facilitate sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning agendas. Produces a sprint goal, velocity-calibrated backlog, capacity plan, risk flags, and a structured sprint planning meeting agenda."
---
# Sprint Planning Skill
Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.
## What This Skill Produces
- **Sprint Goal** — single, outcome-focused sentence the whole team can rally around
- **Sprint Backlog** — prioritised list of user stories with story point estimates and acceptance criteria
- **Capacity Plan** — team availability breakdown accounting for holidays, meetings, and focus time
- **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings
- **Risk Flags** — blockers or dependencies that could derail the sprint
## Required Inputs
Ask for (if not already provided):
- Sprint duration (1 or 2 weeks)
- Team size and velocity (average story points per sprint)
- Top 3–5 backlog items or epics to pull from
- Any known absences, holidays, or team events
- Previous sprint's incomplete items (carry-overs)
## Sprint Goal Formula
Use this structure:
> "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]."
Never write sprint goals as task lists. Always outcome-first.
## Story Point Calibration
| Complexity | Points | Description |
|---|---|---|
| Trivial | 1 | Clearly understood, no unknowns |
| Small | 2 | Straightforward, minor effort |
| Medium | 3 | Some complexity, clear path |
| Large | 5 | Complex, needs design or research |
| Very Large | 8 | High uncertainty, may need splitting |
| Epic | 13+ | Too large — must be split before sprint |
Flag any item estimated at 8+ and recommend splitting.
## Capacity Formula
```
Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor
Focus hours/day: 6 (accounting for meetings, Slack, admin)
Availability factor: 0.7–0.85 depending on holidays/events
Story points to commit = Historical velocity × Availability factor
```
## Programmatic Helper
This skill ships with a stdlib-only Python script that computes capacity instead of estimating it by hand. Use it whenever the team's numbers are known — it applies the availability and 80% commit-ratio rules consistently.
```bash
# Quick estimate from flags
python3 scripts/capacity_calculator.py --team 5 --days 10 --velocity 30 --availability 0.8 --carryover 5
# Detailed estimate from per-member availability (JSON via stdin or --input file.json)
echo '{"sprint_days":10,"historical_velocity":40,"carryover_points":8,
"members":[{"name":"Ada","available_days":10},{"name":"Linus","available_days":7}]}' \
| python3 scripts/capacity_calculator.py --input -
```
The script returns available focus hours, a velocity figure adjusted for real availability, the **recommended commitment** (capped at 80% of velocity), and the remaining **capacity for new work** after carry-overs. Run it first, then build the sprint backlog to fit the recommended number. Add `--json` to pipe the result into other tooling.
## Output Format
### Sprint [N] — [Start Date] to [End Date]
**Sprint Goal:**
> [Goal statement]
**Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability)
**Sprint Backlog:**
| Priority | Story | Points | Owner | Acceptance Criteria |
|---|---|---|---|---|
| 1 | [Story title] | [N] | [Team member] | [When X then Y] |
**Carry-Overs from Previous Sprint:**
- [Item] — Reason for carry-over: [brief explanation]
**Risks & Dependencies:**
- [Risk description] → Mitigation: [action]
**Sprint Planning Agenda:**
- 00:00–00:10 — Review sprint goal and team capacity
- 00:10–00:40 — Walk through backlog items, confirm estimates
- 00:40–01:20 — Assign stories, identify dependencies
- 01:20–01:50 — Review acceptance criteria per story
- 01:50–02:00 — Confirm sprint commitment and close
## Guidelines
- Always challenge stories missing acceptance criteria — flag them explicitly
- Recommend the team commits to 80% of available capacity, not 100%
- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
- Highlight any story with unclear ownership as a blocker
## Quality Checks
- [ ] Sprint goal is outcome-focused (not "implement X" — something like "users can do Y")
- [ ] Team capacity is calculated using actual availability, not theoretical 100%
- [ ] Every story has an acceptance criterion (flag any that don't)
- [ ] Stories estimated at 8+ points are flagged for splitting
- [ ] Carry-overs from last sprint are accounted for in capacity
## Anti-Patterns
- [ ] Do not write sprint goals as task lists — goals must be outcome-focused and scoreable pass/fail at sprint end
- [ ] Do not commit to 100% of available capacity — always recommend 80% to preserve slack for unplanned work
- [ ] Do not carry stories with no acceptance criteria into the sprint — flag them as blockers before committing
- [ ] Do not allow stories estimated at 8+ points into the sprint without splitting them first
- [ ] Do not ignore carry-over items when calculating capacity — they consume capacity and must be accounted for before new work is pulled in
exports/windsurf/pm-delivery/technical-spec-template/technical-spec-template.md
+157
View File
@@ -0,0 +1,157 @@
---
trigger: model_decision
description: "Create structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Produces a complete spec with problem statement, proposed solution, data model, API design, alternatives considered, security considerations, testing plan, and rollout strategy."
---
# Technical Spec Template Skill
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
## Required Inputs
Ask the user for these if not provided:
- **Feature or system description** (what needs to be specced)
- **Related PRD or product brief** (if available)
- **Engineering reviewers** (whose sign-off is needed)
- **Known constraints** (technical limitations, security requirements, performance targets)
## When to Write a Tech Spec
Write a tech spec when:
- The feature requires changes to 2+ systems
- There are significant architectural decisions to make
- More than one engineer will work on the implementation
- The feature has security, privacy, or compliance implications
- Estimated effort is >5 story points
Skip the spec for trivial bug fixes or 1-2 hour changes.
---
## Technical Spec Output Format
### Technical Specification — [Feature Name]
**Author:** [Name]
**Status:** Draft | In Review | Approved | Implemented
**Created:** [Date] | **Last Updated:** [Date]
**Reviewers:** [Eng Lead, Architect, PM, Security if needed]
**Related PRD:** [Link] | **Jira Epic:** [Link]
---
#### 1. Problem Statement
> [2–3 sentences. What problem are we solving and why now? No solution language here.]
#### 2. Goals & Non-Goals
**Goals (in scope):**
- [Specific, measurable outcome]
- [Specific, measurable outcome]
**Non-Goals (explicitly out of scope):**
- [What this spec does NOT cover]
- [Common assumption to shut down early]
#### 3. Background & Context
[Any prior art, related systems, or context engineers need to understand the decision space. Link to previous specs, ADRs, or research.]
#### 4. Proposed Solution
**High-Level Approach:**
[2–4 sentences describing the chosen solution. Why this approach vs alternatives?]
**System Architecture Diagram:**
[Describe or embed: which services are involved, how data flows, what APIs are called]
**Data Model Changes:**
```sql
-- New tables or schema changes
[Include DDL or schema definition]
```
**API Design:**
```
[Endpoint] [Method]
Request: { [fields and types] }
Response: { [fields and types] }
Error codes: [list]
```
**Key Implementation Details:**
- [Important technical constraint or approach]
- [Edge case handling]
- [Third-party dependency and version]
#### 5. Alternative Approaches Considered
| Option | Pros | Cons | Why Rejected |
|---|---|---|---|
| [Alt 1] | [Benefits] | [Drawbacks] | [Reason not chosen] |
| [Alt 2] | [Benefits] | [Drawbacks] | [Reason not chosen] |
#### 6. Security & Privacy Considerations
- Data stored: [What PII or sensitive data is involved]
- Authentication: [How is access controlled]
- Authorisation: [What permissions are required]
- Encryption: [At rest / in transit requirements]
- Compliance implications: [GDPR, SOC2, etc. if relevant]
#### 7. Performance & Scalability
- Expected load: [Requests/second, data volume]
- Latency requirements: [P50 / P95 targets]
- Caching strategy: [If applicable]
- Database indexing: [New indexes required]
- Known bottlenecks: [Where to watch]
#### 8. Testing Plan
- Unit tests: [Key scenarios to cover]
- Integration tests: [System boundaries to test]
- Load tests: [If performance-critical]
- Edge cases: [Known tricky scenarios]
- Rollback plan: [How to revert if something goes wrong]
#### 9. Rollout Plan
- Feature flag: [Yes / No — name of flag]
- Rollout stages: [% of users at each stage]
- Monitoring: [Metrics and alerts to set up]
- Success criteria to progress rollout: [What needs to be true]
- Rollback trigger: [What would cause immediate rollback]
#### 10. Open Questions
| Question | Owner | Due Date | Resolution |
|---|---|---|---|
| [Unresolved question] | [Name] | [Date] | [Pending] |
#### 11. Implementation Timeline (Rough)
| Phase | Work | Estimated Effort |
|---|---|---|
| [Phase 1] | [What gets built] | [X days/points] |
| [Phase 2] | [What gets built] | [X days/points] |
| Total | | [X story points] |
---
## Guidelines
- The spec is a decision record, not a task list — document *why* decisions were made
- All open questions must have an owner and due date
- Security and privacy sections are never optional for features that touch user data
- Recommend async review: engineers read first, then a 30-minute sync to resolve questions
- Keep the spec updated as implementation progresses — stale specs are worse than no specs
## Quality Checks
- [ ] Problem statement contains no solution language
- [ ] Non-goals explicitly list at least 2 things that might be assumed in scope
- [ ] At least 2 alternative approaches are documented with reasons for rejection
- [ ] Security and privacy section is completed for any feature touching user data
- [ ] All open questions have a named owner and due date (not "TBD")
## Anti-Patterns
- [ ] Do not include solution language in the problem statement — the problem must be described independently of the proposed solution
- [ ] Do not omit alternatives considered — a spec that considers only one approach has not been properly evaluated
- [ ] Do not leave open questions as "TBD" without a named owner and due date — unresolved questions are blockers
- [ ] Do not skip security and privacy sections for any feature that touches user data
- [ ] Do not write a non-goals section that is empty — always list at least two things that might be assumed in scope
exports/windsurf/pm-delivery/user-story-writer/user-story-writer.md
+226
View File
@@ -0,0 +1,226 @@
---
trigger: model_decision
description: "Write well-structured user stories with acceptance criteria and edge cases. Use when asked to write user stories, create tickets from a feature brief, convert a PRD into stories, or write acceptance criteria. Produces ready-to-estimate stories in the standard format with clear acceptance criteria, edge cases, and definition of done."
---
# User Story Writer Skill
This skill produces production-ready user stories from a feature brief, PRD section, or verbal description. Each story follows the standard format with a clear who/what/why, behavioural acceptance criteria in Given/When/Then format, edge cases, and definition of done. Output is ready to paste into Jira, Linear, or your planning tool.
## Required Inputs
Ask the user for these if not provided:
- **Feature or change** to break into stories — paste the brief, PRD section, or describe the feature
- **User types / personas** involved (e.g. admin, end user, guest, API consumer)
- **Scope** — are we writing one story or decomposing an epic into a full set of stories?
- **Acceptance criteria format preference** — Given/When/Then, bullet checklist, or both?
- **Technical constraints or notes** — anything the engineering team has flagged that should shape the stories
## Output Structure
For each story:
---
## Story: [Short title — verb + noun, e.g. "Filter search results by date range"]
**Epic:** [Parent epic name — e.g. "Advanced Search"]
**Story ID:** [Jira/Linear ID — leave blank if not yet created]
**Priority:** [P1 / P2 / P3]
**Story points:** [Leave blank — for engineering to estimate]
---
### User Story
> **As a** [specific user type — not "user"],
> **I want to** [concrete action they want to take],
> **So that** [the outcome they achieve — business value, not feature description].
**Example:**
> As an **account manager**,
> I want to **filter my client list by last contact date**,
> so that I **can quickly identify clients I haven't spoken to in over 30 days and prioritise outreach**.
---
### Context
[1–3 sentences of context that aren't in the user story itself: when does this story matter, what triggers the need, how does it fit into a larger flow. This helps engineers understand why before they ask.]
---
### Acceptance Criteria
**Format: Given / When / Then**
Each criterion tests one specific behaviour. Write one GWT per observable outcome — not one GWT for the whole feature.
**AC1: [Short name for this criterion]**
```
Given [starting state or context]
When [user action]
Then [observable system behaviour]
```
**AC2: [Short name]**
```
Given [...]
When [...]
Then [...]
```
**AC3: [Short name]**
```
Given [...]
When [...]
Then [...]
```
---
### Edge Cases
[List scenarios that are non-obvious but must be handled. These become additional ACs or notes to engineering.]
- [ ] **[Edge case 1]:** [e.g. User applies a date filter that returns 0 results — show empty state with clear messaging and a "clear filters" action]
- [ ] **[Edge case 2]:** [e.g. User has >10,000 clients — filter must not degrade load time >200ms]
- [ ] **[Edge case 3]:** [e.g. Date filter persists across page refresh — or explicitly should not if that's the decision]
- [ ] **[Permission edge case]:** [e.g. Read-only users can see the filter but cannot save filter presets]
---
### Out of Scope
[Explicitly state what this story does NOT cover — prevents scope creep and clarifies where the next story begins.]
- Saving and sharing filter presets (separate story — see [Story X])
- Bulk actions on filtered results
- Exporting filtered client list to CSV
---
### Definition of Done
- [ ] Acceptance criteria all pass
- [ ] Edge cases handled (or explicitly deferred with a new ticket raised)
- [ ] Unit tests written for each AC
- [ ] Works on mobile viewport (if applicable)
- [ ] Accessibility: keyboard navigable and screen-reader compatible
- [ ] Error states are handled and copy approved
- [ ] Product and design have reviewed in staging
- [ ] No console errors in production build
---
## Epic Decomposition Template
If the user provides an epic or feature brief, decompose it into a full set of stories before writing them:
**Epic:** [Name]
**Goal:** [What outcome does completing this epic achieve?]
**Stories:**
| # | Story | Notes | Dependencies |
|---|---|---|---|
| 1 | [Core happy path story — the simplest version of the feature that delivers value] | | |
| 2 | [Validation / error handling story] | | Depends on #1 |
| 3 | [Edge case or power user story] | | Depends on #1 |
| 4 | [Admin or configuration story] | | |
| 5 | [Performance or scale story — if applicable] | | Depends on #1 |
**Suggested sprint order:** [Which stories are P1 for MVP? Which can follow in a later sprint?]
---
## Common Story Anti-Patterns — and Fixes
Use these to review stories before handing to engineering:
| Anti-pattern | Example | Fix |
|---|---|---|
| **Solution in the story** | "As a user I want a dropdown filter" | Remove the UI decision — "As a user I want to filter by date range" |
| **Vague "so that"** | "so that it's easier to use" | Make it specific — "so that I can prioritise outreach without opening each record manually" |
| **Too big** | Story covers 5 distinct user flows | Split into separate stories per flow |
| **No acceptance criteria** | Story has description only | Add at least 3 GWT criteria before engineering starts |
| **ACs that test the solution, not the behaviour** | "Given the dropdown is open, When I select an option" | Test the outcome — "Given I have applied a date filter, When I view my results, Then only clients last contacted in that date range appear" |
| **Missing empty state** | No AC for what happens with 0 results | Add it — empty states are part of the feature |
| **Missing error state** | No AC for network failure or invalid input | Add error handling ACs explicitly |
---
## Example: Full Story Set for a Feature
**Feature brief:** "Allow users to export their invoice history as a PDF or CSV"
---
### Story 1: Export invoice list as CSV
> As a **finance admin**,
> I want to **export my invoice history as a CSV file**,
> so that I can **import it into our accounting software without manual data entry**.
**AC1: Successful export**
```
Given I am on the Invoices page with at least one invoice
When I click "Export" and select "CSV"
Then a CSV file is downloaded containing all visible invoices with columns: Invoice ID, Date, Amount, Status, Customer Name
```
**AC2: Empty state**
```
Given I am on the Invoices page with no invoices
When I click "Export"
Then the export button is disabled and a tooltip reads "No invoices to export"
```
**AC3: Filtered export**
```
Given I have applied a date filter showing invoices from Jan 2026 only
When I click "Export" and select "CSV"
Then the export contains only invoices from Jan 2026 — not all invoices
```
**Edge cases:**
- [ ] Export with >10,000 invoices — must complete in <30s or show a progress indicator
- [ ] Export triggered on mobile — downloads to device's default download location
**Out of scope:** PDF export (Story 2), scheduled exports (future epic)
---
### Story 2: Export invoice list as PDF
> As a **finance admin**,
> I want to **export my invoice history as a formatted PDF**,
> so that I can **share a professional summary with our accountant**.
[... ACs follow same pattern ...]
---
## Quality Checks
- [ ] Every story has a specific user type — not "a user" or "the system"
- [ ] The "so that" explains business value — not just feature description
- [ ] Each AC tests one observable outcome — not a bundle of behaviours
- [ ] Empty states, error states, and edge cases are explicitly handled
- [ ] Out of scope is documented — not assumed
- [ ] Stories are independent — they can be shipped individually without depending on unreleased work (except where explicitly noted)
## Anti-Patterns
- [ ] Do not write user stories from a technical perspective — every story must be from the user's point of view and state their goal
- [ ] Do not write acceptance criteria that are untestable — every criterion must have a clear pass/fail condition
- [ ] Do not create stories that are too large to complete in a single sprint — break epics into estimable, independently deliverable stories
- [ ] Do not omit edge cases — unhappy paths and error states are required, not optional
- [ ] Do not skip the Definition of Done — without it, "done" means different things to different people
## Example Trigger Phrases
- "Write user stories for [feature] from this brief"
- "Break this PRD section into user stories with acceptance criteria"
- "Convert these feature requirements into Jira tickets"
- "Write the user stories and ACs for [feature name]"
- "Decompose this epic into individual stories ready for sprint planning"