justin/pm-claude-skills

Files

T

mohitagw15856 036511ab3e 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

4.5 KiB

Raw Blame History

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:

[Feature] — [1-line rationale]
[Feature] — [1-line rationale]
...

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