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>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,128 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Apply prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items. Use when asked to prioritise features, rank a backlog, decide what to build next, or evaluate tradeoffs between competing ideas. Produces a scored, ranked feature list with framework-specific tables, recommended build order, deprioritised items, and assumptions made."
|
||||
---
|
||||
|
||||
# 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,94 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Create well-structured OKRs (Objectives and Key Results) for product teams, startups, and individuals. Use when asked to write OKRs, set quarterly goals, define key results, or review existing OKRs. Produces a complete OKR set with objectives, measurable key results, baselines, and a scoring guide."
|
||||
---
|
||||
|
||||
# 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,145 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Structure pricing strategy decisions, packaging options, and tier design for SaaS and digital products. Use when reviewing or setting pricing, designing pricing tiers, evaluating freemium vs paid, or preparing a pricing change. Produces a pricing strategy recommendation with model rationale, tier structure, competitive positioning, and rollout plan."
|
||||
---
|
||||
|
||||
# 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,70 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Scores features using both RICE and strategic alignment for nuanced prioritisation. Use when asked to prioritise features, build a priority matrix, combine quantitative scoring with strategic fit, or decide what to build next with multiple competing initiatives. Produces a scored priority matrix with RICE scores, strategic alignment ratings, quadrant placement, and sequencing recommendations."
|
||||
---
|
||||
|
||||
# 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,85 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Scores and ranks product initiatives using the RICE framework. Use when asked to prioritise features, rank a backlog using RICE, score initiatives for quarterly planning, or apply an objective framework to a list of competing ideas. Produces a ranked RICE table with scores, quick wins and moonshot flags, dependency notes, and a recommended sequencing order."
|
||||
---
|
||||
|
||||
# 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,64 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Transform a prioritised initiative list into a compelling strategic roadmap narrative. Use when asked to write a roadmap narrative, explain the product roadmap to non-technical stakeholders, connect roadmap items to company goals, or produce an exec-shareable roadmap story. Produces a themed narrative with strategic context, quarter progression arc, an executive summary, and a 'what's not on the roadmap' section."
|
||||
---
|
||||
|
||||
# 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,138 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Create structured roadmap presentations calibrated to any audience. Use when asked to build a product roadmap, present roadmap to leadership, create a roadmap slide, or communicate quarterly plans to execs, teams, or customers. Produces an audience-calibrated Now/Next/Later roadmap with strategic context, initiative tables, success metrics, and explicit deprioritisation rationale."
|
||||
---
|
||||
|
||||
# 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
|
||||
Reference in New Issue
Block a user