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

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>
2026-06-17 23:15:38 +01:00
parent 123aabe5e3
commit 036511ab3e
358 changed files with 60408 additions and 38 deletions
@@ -0,0 +1,123 @@
+# Feature Prioritisation Skill
+
+Apply the right prioritisation framework to any backlog and produce a clear, defensible ranking with rationale — not just a sorted list.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **List of features or initiatives to prioritise**
+- **Goal or metric** being prioritised against (OKR, launch, sprint)
+- **Preferred framework** (or recommend based on context below)
+- **Team data**: reach estimates, effort estimates, velocity (for RICE)
+
+## Framework Selection Guide
+
+Ask the user which framework they prefer, or recommend based on context:
+
+| Situation | Recommended Framework |
+|---|---|
+| Need a quick, data-driven score | RICE |
+| Stakeholder alignment meeting | MoSCoW |
+| Understanding customer delight vs expectations | Kano |
+| Early-stage startup, fast decisions | ICE |
+| Identifying underserved customer needs | Opportunity Scoring |
+| Strategic portfolio decisions | Value vs Effort Matrix |
+
+---
+
+## RICE Scoring
+
+**Formula:** (Reach × Impact × Confidence) ÷ Effort
+
+| Factor | Definition | Scale |
+|---|---|---|
+| Reach | Users impacted per quarter | Actual number |
+| Impact | Effect on goal per user | 0.25 / 0.5 / 1 / 2 / 3 |
+| Confidence | How certain are you? | 50% / 80% / 100% |
+| Effort | Person-months required | Actual number |
+
+Output table:
+| Feature | Reach | Impact | Confidence | Effort | RICE Score | Priority |
+|---|---|---|---|---|---|---|
+
+---
+
+## MoSCoW Method
+
+Categorise each feature as:
+- **Must Have** — non-negotiable for launch/sprint; product fails without it
+- **Should Have** — important but not critical; workarounds exist
+- **Could Have** — nice to have; include only if time allows
+- **Won't Have (this time)** — explicitly out of scope now; may revisit
+
+Always ask: "Must have for *what*?" — define the scope (launch, sprint, quarter) before categorising.
+
+---
+
+## ICE Scoring (Startup/fast mode)
+
+**Formula:** Impact + Confidence + Ease (each 1–10)
+
+Quick, subjective — good for early decisions before data exists.
+
+---
+
+## Kano Model
+
+Classify features into:
+- **Basic (Must-be):** Expected; absence causes dissatisfaction
+- **Performance:** More = better satisfaction; linear relationship
+- **Excitement (Delighters):** Unexpected; creates delight; absence is neutral
+- **Indifferent:** Users don't care either way
+- **Reverse:** Some users want it, others don't
+
+Recommend building: all Basic features first → Performance features for key use cases → 1–2 Excitement features per release.
+
+---
+
+## Output Format
+
+### Feature Prioritisation — [Product/Team] — [Date]
+
+**Framework Used:** [RICE / MoSCoW / ICE / Kano / Custom]
+**Scope:** [Sprint / Quarter / Release]
+**Goal being prioritised against:** [Metric or objective]
+
+[Scored table using selected framework]
+
+**Recommended Build Order:**
+1. [Feature] — [1-line rationale]
+2. [Feature] — [1-line rationale]
+3. ...
+
+**Explicitly Deprioritised:**
+- [Feature] — Reason: [brief]
+
+**Assumptions Made:**
+- [Any estimates or judgements used in scoring]
+
+---
+
+## Guidelines
+
+- Always anchor prioritisation to a specific goal or metric — never prioritise in a vacuum
+- Flag when two features have similar scores but very different risk profiles
+- If stakeholder politics are influencing prioritisation, name it explicitly and suggest separating the framework score from the final decision
+- Recommend revisiting priorities every 2 weeks minimum
+- Never produce a single-column ranked list without rationale — explain the top 3 and bottom 3 decisions
+
+## Quality Checks
+
+- [ ] Every item is scored against the same goal or metric (not different goals per item)
+- [ ] Deprioritised items are explicitly listed with reasons (not just absent from the ranked list)
+- [ ] Assumptions used in scoring are documented
+- [ ] Stakeholder politics or personal preferences are separated from framework score
+- [ ] Prioritisation is anchored to a specific scope (sprint / quarter / launch)
+
+## Anti-Patterns
+
+- [ ] Do not score items against different goals — every item in a prioritisation session must be scored against the same objective
+- [ ] Do not omit deprioritised items — explicitly listing what was cut and why is as important as the ranked list
+- [ ] Do not let stakeholder politics override framework scores without documenting the override and reason
+- [ ] Do not mix RICE, ICE, or MoSCoW scores across frameworks in a single session — pick one framework per prioritisation exercise
+- [ ] Do not treat the output as final without documenting the assumptions used in scoring — assumptions change, and the list must be revisitable
@@ -0,0 +1,89 @@
+# OKR Builder Skill
+
+Write ambitious, measurable OKRs that connect product work to company strategy. Avoid vanity metrics, output-focused key results, and objectives that sound like task lists.
+
+## OKR Fundamentals
+
+**Objective:** Qualitative, inspiring, time-bound. Answers "where are we going?"
+**Key Result:** Quantitative, specific, measurable. Answers "how will we know we've arrived?"
+
+### The Test for a Good KR
+- Can it be scored 0.0–1.0 at the end of the period?
+- Does it measure outcome, not output? ("Revenue from new customers increased by 30%" not "Launch 3 features")
+- Is it ambitious but achievable? (Aim for 70% attainment as the gold standard)
+- Is it within the team's control?
+
+## Common OKR Anti-Patterns to Flag and Fix
+
+| Anti-Pattern | Example | Better Version |
+|---|---|---|
+| Task masquerading as KR | "Launch onboarding redesign" | "New user activation rate increases from 42% to 65%" |
+| Vanity metric | "Get 10,000 app downloads" | "30-day retention for new users reaches 40%" |
+| Binary KR | "Ship API v2" | "API v2 adopted by 80% of active integrations" |
+| Too many KRs | 6+ per objective | Max 3–4 KRs per objective |
+| No baseline | "Improve NPS" | "NPS increases from 32 to 50" |
+
+Always flag anti-patterns and offer a rewrite.
+
+## Output Format
+
+### [Quarter] OKRs — [Team/Product Area]
+
+---
+
+**Objective 1: [Inspiring, qualitative statement]**
+
+*Why this matters:* [1–2 sentence strategic context]
+
+| # | Key Result | Baseline | Target | Measurement Method |
+|---|---|---|---|---|
+| KR1 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
+| KR2 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
+| KR3 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
+
+*Owner:* [Name/Role]
+*Check-in cadence:* Weekly
+
+---
+
+Repeat for each objective. Recommend 2–4 objectives per team per quarter.
+
+## Scoring Guide to Include
+
+At quarter end, score each KR:
+- 0.7–1.0 = Excellent (0.7 is the "sweet spot" — if all KRs score 1.0, they weren't ambitious enough)
+- 0.4–0.6 = Made progress but missed
+- 0.0–0.3 = Missed — needs retrospective discussion
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Team or individual** the OKRs are for
+- **Quarter and year**
+- **Company or product North Star metric** (OKRs should connect to this)
+- **Top 3 priorities or goals for this quarter** (rough notes are fine)
+- **Any existing OKRs to review or improve** (optional)
+
+## Guidelines
+
+- Always ask for the company-level or product-level North Star metric before writing OKRs
+- Recommend no more than 3 objectives per team per quarter
+- If user provides output-based goals, always reframe as outcomes
+- Include a "health check" section flagging which KRs have no current baseline data
+- Remind user: OKRs are not performance reviews — they should be ambitious enough that missing them is okay
+
+## Quality Checks
+
+- [ ] Each KR is measurable with a baseline and target
+- [ ] No output-based KRs (no "launch X" or "complete Y")
+- [ ] Maximum 4 KRs per objective
+- [ ] OKRs connect to the company or product North Star
+- [ ] Ambitious enough that 0.7 attainment is the expected score
+
+## Anti-Patterns
+
+- [ ] Do not accept output-based key results — any KR phrased as "launch X" or "complete Y" must be rewritten as an outcome with a baseline and target
+- [ ] Do not write OKRs without asking for the company or product North Star — OKRs disconnected from the strategic context are just a goal-setting exercise
+- [ ] Do not write more than 4 KRs per objective — too many KRs dilute focus and make scoring ambiguous at quarter end
+- [ ] Do not use binary KRs (ship/don't ship) — every KR must be scorable on a 0.0–1.0 scale based on degree of achievement
+- [ ] Do not skip the health check section on baselines — OKRs without current baselines cannot be scored objectively at quarter end
@@ -0,0 +1,140 @@
+# Pricing Strategy Skill
+
+Build pricing that reflects value delivered — not cost to build. Structure every pricing decision with customer segmentation, value metric identification, competitive context, and a packaging recommendation.
+
+## Pricing Foundations
+
+Three questions to answer before any pricing decision:
+1. **Who is our buyer?** (Role, company size, willingness to pay)
+2. **What value do we deliver?** (Quantifiable outcome — time saved, revenue generated, risk reduced)
+3. **What is our pricing model?** (Per seat, usage-based, flat, hybrid)
+
+---
+
+## Pricing Models
+
+| Model | Best For | Risk |
+|---|---|---|
+| **Per Seat** | Collaboration tools, team software | Disincentivises adoption as team grows |
+| **Usage-Based** | APIs, infrastructure, consumption tools | Revenue unpredictability for both sides |
+| **Flat Rate** | Simple tools, early-stage | Leaves money on table from power users |
+| **Tiered** | Products with clear user segments | Feature gatekeeping frustrates users |
+| **Freemium** | Viral/PLG products with low marginal cost | Conversion to paid is hard to engineer |
+| **Value-Based** | Enterprise, outcomes-driven products | Requires strong ROI story |
+
+---
+
+## Freemium Decision Framework
+
+Use freemium when:
+- ✅ Marginal cost per free user is near zero
+- ✅ Product is inherently viral (network effects or sharing)
+- ✅ Free tier creates genuine value (not just a demo)
+- ✅ Clear upgrade trigger exists (feature, volume, or team size)
+- ✅ Conversion benchmark is realistic (2–5% free-to-paid is typical)
+
+Avoid freemium when:
+- ❌ Support cost per free user is high
+- ❌ No natural upgrade trigger in the product
+- ❌ Core value requires features you'd need to gate
+
+---
+
+## Packaging / Tiering Framework
+
+Recommended 3-tier structure for SaaS:
+
+| Tier | Target | Price Signal | Key Features | Lock-in Mechanism |
+|---|---|---|---|---|
+| **Free / Starter** | Individual, early discovery | $0 | Core value, usage-limited | Invite colleagues, export limit |
+| **Pro / Growth** | SMB, growing teams | $[X]/seat/mo | Full features, higher limits | Team collaboration, integrations |
+| **Business / Enterprise** | Mid-market, enterprise | $[X]/seat/mo or custom | Admin, SSO, SLAs, dedicated support | Security, compliance, volume |
+
+Tier design rules:
+- Each tier should be genuinely sufficient for its target segment
+- The upgrade trigger should be felt naturally — not manufactured
+- Price jumps of 3–5x between tiers are normal and defensible
+
+---
+
+## Competitive Pricing Context
+
+| Competitor | Model | Price | Key Differentiator |
+|---|---|---|---|
+| [Name] | [Model] | [Price] | [What they lead with] |
+
+Positioning options:
+- **Premium:** Price 20–40% above market. Justify with enterprise features, support, or brand.
+- **Parity:** Match the market leader. Win on product or distribution.
+- **Value:** Price below market. Win on volume. Dangerous without strong unit economics.
+
+---
+
+## Output Format
+
+### Pricing Strategy Recommendation — [Product] — [Date]
+
+**Current State:** [What pricing exists today, if any]
+**Problem to Solve:** [Why pricing is being reviewed]
+
+**Recommended Pricing Model:** [Model name + rationale]
+
+**Value Metric:** [The single unit that scales with customer value — e.g., "active users", "API calls", "documents processed"]
+
+**Proposed Tiers:**
+
+[Table using 3-tier structure above]
+
+**Free-to-Paid Upgrade Trigger:** [Specific moment or threshold that creates natural upgrade pressure]
+
+**Competitive Position:** [Premium / Parity / Value + reasoning]
+
+**Pricing Change Rollout (if applicable):**
+- Grandfathering: [Yes / No — recommendation and rationale]
+- Communication plan: [How to tell customers + timing]
+- Rollback plan: [Under what conditions you'd revert]
+
+**Risks:**
+- [Risk] → Mitigation: [Action]
+
+**Metrics to Monitor Post-Change:**
+- Conversion rate (free to paid)
+- Churn rate by tier
+- Average revenue per user (ARPU)
+- Expansion revenue
+
+---
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Product or service** being priced
+- **Current pricing** (if any — and why it's being reviewed)
+- **Target customer segments** (size, role, willingness to pay)
+- **Key competitors and their pricing** (if known)
+- **Business model** (SaaS / Marketplace / Usage-based / Other)
+- **Primary goal** (grow adoption / increase ARPU / reduce churn / new market entry)
+
+## Quality Checks
+
+- [ ] Value metric is defined (the unit that scales with customer value)
+- [ ] Free-to-paid upgrade trigger is specific (not "when they need more")
+- [ ] Competitive positioning is chosen and justified (premium / parity / value)
+- [ ] Pricing change rollout plan includes grandfathering decision
+- [ ] Counter-metrics are defined to catch perverse incentives
+- [ ] Risks have specific mitigations (not just listed)
+
+## Anti-Patterns
+
+- [ ] Do not base pricing solely on cost-plus — pricing must reflect value delivered to the customer
+- [ ] Do not design tiers where the middle tier is clearly worse value — it undermines trust and pushes customers to extremes
+- [ ] Do not change pricing without a migration plan for existing customers — surprise price changes cause churn
+- [ ] Do not set enterprise pricing as "contact us" without a floor — it deters self-serve evaluation and qualification
+- [ ] Do not skip competitive positioning — pricing in isolation from the market is incomplete strategy
+
+## Guidelines
+
+- Never price based on cost — price based on value delivered to the customer
+- Always A/B test price changes where possible; use geographic holdouts if A/B isn't feasible
+- Recommend annual pricing with 15–20% discount — improves cash flow and reduces churn
+- If enterprise pricing is "contact us", recommend adding a price floor to qualify inbound
@@ -0,0 +1,65 @@
+# RICE + Strategic Alignment Skill
+
+Produce a prioritisation output that balances quantitative RICE scoring with qualitative strategic fit — because the highest RICE score isn't always the right next bet.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **List of initiatives or features to prioritise** (names and brief descriptions)
+- **Current strategic priorities or OKRs** (needed to rate strategic alignment)
+- **Reach estimates** (users affected per quarter — even rough estimates work)
+- **Effort estimates** (person-months — from engineering if available)
+- **Quarter or planning period**
+
+## Two-Stage Process
+
+### Stage 1: RICE Scoring
+- Reach: Users affected per quarter
+- Impact: 3/2/1/0.5/0.25 scale
+- Confidence: 100% / 80% / 50%
+- Effort: Person-months
+- RICE = (R × I × C) / E
+
+### Stage 2: Strategic Alignment Score
+Rate each initiative against your current strategic priorities (provided as input):
+- Directly supports top OKR: +3
+- Supports secondary OKR: +2
+- Neutral: +1
+- Contradicts strategic direction: -1
+
+### Final Priority Score
+Combined Score = RICE Score + (Strategic Alignment × 10)
+
+**Validate** — Flag any initiative where RICE score and strategic alignment conflict sharply (e.g., high RICE, low alignment). These require an explicit team conversation before sequencing.
+
+## Output Structure
+
+### Priority Matrix — [Quarter]
+| Initiative | RICE Score | Strategic Alignment | Combined Score | Quadrant | Recommendation |
+|------------|------------|--------------------|--------------------|----------|----------------|
+| [name] | [score] | [score] | [combined] | [Now/Next/Later/Drop] | [action] |
+
+#### Quadrant Definitions
+- **Now:** High RICE + High Strategic Alignment → Build this quarter
+- **Next:** High RICE + Lower Alignment → Queue for next quarter
+- **Later:** Lower RICE + High Alignment → Revisit when capacity allows
+- **Drop:** Low RICE + Low Alignment → Remove from backlog
+
+#### Recommendations
+[Top 5 initiatives with rationale for sequencing]
+
+## Quality Checks
+
+- [ ] All RICE components have an estimate (even if low confidence — flag those)
+- [ ] Strategic alignment is rated against specific OKRs, not general "feels strategic"
+- [ ] Conflicts between RICE rank and strategic alignment are explicitly flagged
+- [ ] "Drop" recommendations are specific — not just "low priority, deprioritise"
+- [ ] Confidence levels on estimates are noted where weak (drives the 50% confidence flag)
+
+## Anti-Patterns
+
+- [ ] Do not treat the combined score as a definitive ranking — use it to structure a conversation, not replace one
+- [ ] Do not rate strategic alignment as "high" because an initiative feels important without mapping it to a specific OKR
+- [ ] Do not place all initiatives in the "Now" quadrant — a matrix with no "Drop" recommendations is not credible
+- [ ] Do not ignore the conflict flag when RICE rank and strategic alignment sharply diverge
+- [ ] Do not accept 100% confidence on estimates that have not been validated with data
@@ -0,0 +1,80 @@
+# RICE Prioritisation Skill
+
+Apply consistent, criteria-based RICE scoring to a list of features or initiatives to produce an objective prioritisation ranking.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **List of initiatives or features to score** (names and brief descriptions)
+- **Reach estimates** (users affected per quarter — from analytics if available)
+- **Impact estimates** (use the standard scale below)
+- **Effort estimates** (person-months — from engineering if available)
+- **Quarter or planning period**
+
+## RICE Definitions (adapt to your context)
+- **Reach:** Number of users affected per quarter (use actual DAU/MAU data where available)
+- **Impact:** Effect on your primary metric — use scale: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
+- **Confidence:** How certain are we about R and I estimates? 100%=high, 80%=medium, 50%=low
+- **Effort:** Person-months required across all functions
+
+## RICE Formula
+RICE Score = (Reach × Impact × Confidence) / Effort
+
+## Programmatic Helper
+
+This skill ships with a stdlib-only Python script that calculates and ranks RICE scores so the maths is consistent and the quick-win / moonshot flags are applied by rule, not by feel. Feed it the initiatives once R, I, C, and E are gathered.
+
+```bash
+# From a JSON file (confidence accepts 0.8 or 80)
+python3 scripts/rice_calculator.py initiatives.json
+
+# Or from a CSV with header: name,reach,impact,confidence,effort
+python3 scripts/rice_calculator.py initiatives.csv --format csv
+
+# Or piped in
+echo '[{"name":"Onboarding","reach":5000,"impact":2,"confidence":0.8,"effort":3}]' \
+  | python3 scripts/rice_calculator.py -
+```
+
+It outputs a ranked table with computed RICE scores and auto-flags **quick-win** (strong score, low relative effort), **moonshot** (high impact, high effort), and **low-confidence** (≤50%) items. Use the computed ranking as the starting point, then apply the validation step below — never accept a surprising top rank without checking the estimates behind it.
+
+## Process
+1. For each initiative provided, gather or estimate R, I, C, E values
+2. Flag where estimates are weak and note what data would improve them
+3. Calculate RICE score for each
+4. Rank highest to lowest
+5. Flag any "quick wins" (high RICE score, low effort) and "moonshots" (high impact, high effort)
+6. Note dependencies between items that affect sequencing
+7. **Validate** — Cross-check: if the top-ranked item surprises the team, investigate whether an estimate is inflated. RICE is a tool, not a verdict.
+
+## Output Structure
+
+### RICE Prioritisation: [Backlog/Quarter]
+| Initiative | Reach | Impact | Confidence | Effort | RICE Score | Notes |
+|------------|-------|--------|------------|--------|------------|-------|
+| [name] | [n] | [score] | [%] | [months] | [score] | [flags] |
+
+#### Recommended Sequence
+[Top 5 initiatives with rationale]
+
+#### Quick Wins (high score, low effort)
+[Items to pick up alongside bigger bets]
+
+#### Data Gaps to Address
+[What information would most improve scoring accuracy]
+
+## Quality Checks
+
+- [ ] Every initiative has all four RICE components estimated (even roughly)
+- [ ] Confidence is 50% for anything without data backing (not 100% as a default)
+- [ ] Quick wins and moonshots are explicitly called out
+- [ ] Dependencies that affect sequencing are noted
+- [ ] Any surprising ranking is investigated before accepting it
+
+## Anti-Patterns
+
+- [ ] Do not default to 100% confidence on estimates that lack supporting data — this inflates scores and misleads planning
+- [ ] Do not treat RICE scores as a final decision — a ranking that surprises the team must be investigated before it is accepted
+- [ ] Do not omit effort estimates from engineering — PM-only effort estimates are frequently optimistic and skew results
+- [ ] Do not forget to note dependencies that would change the sequencing even if RICE scores suggest otherwise
+- [ ] Do not score every initiative at the same impact level — if everything is "high impact," the framework produces no useful signal
@@ -0,0 +1,59 @@
+# Roadmap Narrative Skill
+
+Convert a ranked list of product initiatives into a clear, strategic narrative that connects individual items to company goals and communicates a coherent product direction.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Prioritised initiative list** (with rough timelines or quarters)
+- **Company OKRs or strategic priorities** (to connect roadmap to company goals)
+- **Audience** (all-hands, board, investors, sales team — changes tone and depth)
+- **Items explicitly NOT on the roadmap** (optional but strengthens credibility)
+
+## Process
+1. Review the prioritised initiative list and company OKRs provided
+2. Identify 2-3 strategic themes that group the initiatives naturally
+3. For each theme, articulate: the problem it addresses, the customer it serves, the metric it moves
+4. Write a quarter-level narrative that shows progression — how does H1 set up H2?
+5. Draft an executive summary (3-4 sentences max) that non-technical stakeholders can repeat
+6. **Validate** — Confirm every initiative maps to a theme. If an initiative is orphaned, either create a theme or flag it as a narrative gap to address
+
+## Output Structure
+
+### Product Roadmap: [Quarter/Half/Year]
+**Strategic Context:** [1 paragraph: market moment, key challenge, our response]
+
+#### Theme 1: [Theme Name]
+- Strategic rationale
+- Initiatives included
+- Primary metric impacted
+- Dependencies
+
+[Repeat for each theme]
+
+**What's Not on the Roadmap (and Why):**
+[2-3 items with rationale — shows strategic discipline, not just prioritisation]
+
+**Executive Summary (shareable):**
+[3-4 sentences that could be shared in an all-hands or board update]
+
+## Tone Guidelines
+- Write for a CFO, not an engineer
+- Lead with customer outcomes, not features
+- Be honest about what's NOT on the roadmap and why
+
+## Quality Checks
+
+- [ ] Every initiative in the input maps to a strategic theme
+- [ ] The executive summary can stand alone and be repeated correctly after one reading
+- [ ] Progression narrative shows causal links between quarters (not just chronological listing)
+- [ ] "What's not on the roadmap" section includes at least 2 items with clear rationale
+- [ ] Language throughout is free of engineering jargon — tested by asking: "could a CFO repeat this?"
+
+## Anti-Patterns
+
+- [ ] Do not produce a list of features with dates and call it a narrative — every initiative must connect to a strategic theme
+- [ ] Do not omit the "what's not on the roadmap" section — without it, the narrative lacks strategic discipline
+- [ ] Do not write progression as a chronological list — show causal links between quarters (Q1 enables Q2 because…)
+- [ ] Do not write the executive summary last and treat it as a summary — write it as the version stakeholders will repeat
+- [ ] Do not let orphaned initiatives appear without a theme — either create a theme or flag the gap explicitly
@@ -0,0 +1,133 @@
+# Roadmap Presentation Skill
+
+Build roadmaps that tell a strategy story — not just a list of features with dates. Every roadmap output is audience-calibrated: executives get outcomes, teams get specificity, customers get value.
+
+## Required Inputs
+
+Ask the user for these if not provided:
+- **Audience** (executive/board, cross-functional, engineering, customers — changes format significantly)
+- **Prioritised initiative list** with rough timelines or quarters
+- **Company OKRs or strategic goals** (to anchor the narrative)
+- **Period covered** (Q1, H1, full year, etc.)
+
+## Audience Calibration
+
+Always ask who the audience is before building:
+
+| Audience | They care about | Format |
+|---|---|---|
+| **Executive / Board** | Business outcomes, revenue, risk, strategic alignment | Outcome-led, 3 columns (Now / Next / Later), no sprint detail |
+| **Cross-functional stakeholders** | Dependencies, timelines, their team's involvement | Theme-based, with dependency callouts |
+| **Engineering team** | Specificity, sequencing, technical constraints | Detailed, with epics and rough sizing |
+| **Customers / External** | Value delivered, no internal detail | Benefits-focused, no dates — "Coming soon / In progress / Done" |
+
+---
+
+## The Now / Next / Later Framework
+
+Standard output structure:
+
+**NOW** (Current quarter — high confidence, committed)
+- What we're building and why
+- Expected outcomes
+
+**NEXT** (Following quarter — medium confidence, directional)
+- Themes and initiatives
+- Key hypotheses being tested
+
+**LATER** (6–12 months — low confidence, aspirational)
+- Strategic bets
+- Dependencies that need to resolve first
+
+⚠️ Never put specific dates on "Later" items. Use quarters or halves.
+
+---
+
+## Roadmap Narrative Template
+
+Every roadmap needs a narrative, not just a timeline. Structure it as:
+
+1. **Where we are** — current product state and key metrics
+2. **The problem we're solving** — what's holding customers or the business back
+3. **Our strategic bets** — the themes that guide this roadmap
+4. **What we're building** — Now / Next / Later breakdown
+5. **How we'll know it's working** — success metrics per theme
+6. **What we're not doing** — explicit deprioritisation with rationale
+
+---
+
+## Output Format
+
+### Product Roadmap — [Product Area] — [Quarter/Year]
+
+**Audience:** [Executive / Team / Customer]
+**Roadmap Owner:** [PM Name]
+**Last Updated:** [Date]
+**Confidence Level:** Now = High | Next = Medium | Later = Low
+
+---
+
+**Strategic Context:**
+> [2–3 sentences: what company/product goal does this roadmap serve?]
+
+**Guiding Themes This Period:**
+1. [Theme 1] — [1-line rationale]
+2. [Theme 2] — [1-line rationale]
+3. [Theme 3] — [1-line rationale]
+
+---
+
+**NOW — [Quarter]**
+
+| Theme | Initiative | Outcome Expected | Team | Status |
+|---|---|---|---|---|
+| [Theme] | [What we're building] | [Metric it moves] | [Owner] | In Progress / Starting |
+
+**NEXT — [Quarter]**
+
+| Theme | Initiative | Hypothesis | Dependencies |
+|---|---|---|---|
+| [Theme] | [What we plan to build] | [If we build X, we expect Y] | [What needs to be true first] |
+
+**LATER — [H2 / Next Year]**
+
+| Theme | Strategic Bet | Why Later |
+|---|---|---|
+| [Theme] | [What we might build] | [What's blocking or uncertain] |
+
+---
+
+**What We're NOT Building (and Why):**
+- [Requested initiative] — Deprioritised because: [reason]
+- [Requested initiative] — Deprioritised because: [reason]
+
+**Success Metrics for This Roadmap:**
+| Metric | Now Target | End of Year Target |
+|---|---|---|
+| [Metric] | [X] | [Y] |
+
+---
+
+## Guidelines
+
+- Never let a roadmap become a commitment list — frame everything outside "Now" as directional
+- Always include a "not doing" section — it prevents the roadmap from becoming a wish list in disguise
+- For executive audiences: lead with the outcome the roadmap delivers to the business, not the features
+- Recommend a roadmap review cadence: monthly for Now items, quarterly for Next/Later
+- If dates are demanded for Later items: use quarters (Q3 2026), not specific dates
+
+## Quality Checks
+
+- [ ] Format matches the audience (executives don't get sprint-level detail)
+- [ ] NOW items are committed with owners; NEXT items are directional; LATER items are aspirational
+- [ ] "What We're NOT Building" section has at least 2 items with rationale
+- [ ] Success metrics are specified per theme (not just a list of features)
+- [ ] Language is free of internal jargon — tested by asking: "could an external stakeholder understand this?"
+
+## Anti-Patterns
+
+- [ ] Do not put specific dates on NEXT or LATER items — use quarters or halves to signal appropriate confidence levels
+- [ ] Do not show the same level of detail to executives and engineers — calibrate depth to audience or you lose both
+- [ ] Do not omit the "What We're NOT Building" section — a roadmap without explicit deprioritisation becomes a wish list
+- [ ] Do not present LATER items as commitments — frame everything outside NOW as directional, not promised
+- [ ] Do not skip the success metrics section — without it, stakeholders cannot evaluate whether the roadmap is working