fix(plugins): sync all 171 plugin SKILL.md files with fixed skills/ versions
Propagates Anti-Patterns sections, description rewrites, Required Inputs additions, and Quality Checks format fixes from skills/ to matching plugin SKILL.md copies. https://claude.ai/code/session_01MuGKn3a3Gbqoe8uM5Lmuqt
This commit is contained in:
Mohit
@@ -118,3 +118,11 @@ Recommend building: all Basic features first → Performance features for key us
|
||||
- [ ] 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
|
||||
|
||||
@@ -84,3 +84,11 @@ Ask the user for these if not provided:
|
||||
- [ ] 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
|
||||
|
||||
@@ -129,6 +129,14 @@ Ask the user for these if not provided:
|
||||
- [ ] 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
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: rice-impact-matrix
|
||||
description: "Score features using RICE and plot against 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."
|
||||
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
|
||||
@@ -60,3 +60,11 @@ Combined Score = RICE Score + (Strategic Alignment × 10)
|
||||
- [ ] 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
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: rice-prioritisation
|
||||
description: "Score and rank 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."
|
||||
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
|
||||
@@ -57,3 +57,11 @@ RICE Score = (Reach × Impact × Confidence) / Effort
|
||||
- [ ] 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
|
||||
|
||||
@@ -54,3 +54,11 @@ Ask the user for these if not provided:
|
||||
- [ ] 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
|
||||
|
||||
@@ -128,3 +128,11 @@ Every roadmap needs a narrative, not just a timeline. Structure it as:
|
||||
- [ ] "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