Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add assimovt/productskills --skill feature-prioritizationgit clone --depth 1 https://github.com/assimovt/productskillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/assimovt/productskills/feature-prioritization)<a href="https://agentmods.dev/skills/assimovt/productskills/feature-prioritization"><img src="https://agentmods.dev/badge/skills/assimovt/productskills/feature-prioritization/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/assimovt/productskills/feature-prioritization"><img src="https://agentmods.dev/badge/skills/assimovt/productskills/feature-prioritization.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00051 | $0.00760 |
| Opus 5 | $0.00026 | $0.00380 |
| Sonnet 5 | $0.00010 | $0.00152 |
| Haiku 4.5 | $0.00005 | $0.00076 |
Grade A, and why
feature-prioritization scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Prioritize with math, not opinions. RICE scoring forces explicit tradeoffs. The enabler/blocker lens from Linear ensures you're not just building fun things while adoption barriers remain.
RICE Scoring
Score every candidate feature on four dimensions:
- Reach: How many users/accounts will this affect in a set time period? Use real numbers from analytics, not gut feel. "500 users/quarter" not "a lot."
- Impact: How much will this move the target metric per user? Score 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive). Be honest — most features are a 1.
- Confidence: How sure are you about Reach and Impact? 100% = hard data. 80% = strong evidence. 50% = gut feel. NEVER score 100% without quantitative data.
- Effort: Person-weeks of work. Include design, engineering, QA, and any cross-team coordination. Round up.
RICE = (Reach x Impact x Confidence) / Effort
Example: SSO — Reach: 500 users/qtr, Impact: 2 (high — unlocks enterprise deals), Confidence: 80%, Effort: 4 person-weeks. RICE = (500 x 2 x 0.8) / 4 = 200. Tag: Blocker.
Rank by score. The math won't be perfect, but it forces you to justify each dimension.
Enablers vs Blockers (Linear)
After RICE scoring, classify each feature:
- Blocker: Removes a barrier to adoption or retention. Users are churning, stuck, or can't even start because this is missing. Examples: missing SSO for enterprise deals, broken mobile experience, no data export.
- Enabler: Delights existing users or deepens engagement. Users are already successful but this makes them more so. Examples: keyboard shortcuts, advanced filters, integrations.
Rule: Prioritize blockers over enablers when growing. Removing friction > adding delight when you're trying to grow. Flip this when retention is strong but engagement is flat.
Running a Prioritization Session
- List all candidates with a one-sentence description
- Score each on R, I, C, E independently — don't anchor on each other
- Calculate RICE scores and rank
- Tag each as Blocker or Enabler
- Check: are any Blockers ranked below Enablers? Justify or re-rank.
- Top 3-5 items = your next cycle
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 56 lines · 51 tokens per session scan A 05c3dfc79d9e
feature-prioritization is a skill published in the GitHub repository assimovt/productskills (68 stars, last pushed 6mo ago), licensed MIT. It adds 51 tokens to every session and 760 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
customise-workflow
Customise the prd-taskmaster plugin workflow via curated brainstorm questions. The AI asks, the user answers in plain English, and the skill writes their preferences to .atlas-ai/config/atlas.json. Future runs of prd-taskmaster read that file and apply user preferences to phase gates, validation strictness, default…
expand-tasks
Expand all TaskMaster tasks with deep research before coding begins. Reads tasks.json, launches parallel research agents per task in waves using the research-expander agent. Writes findings back to tasks.json. Part of the prd-taskmaster toolkit. Use after PRD is parsed and before implementation. Invoke with…
recipe-define
Creates a delivery-ready PRD from validated hypotheses with material 4 Risks evidence and necessary traceability. Use when turning validation results into requirements or user stories.
PRD Mastery: Context-Aware, Expert-Driven, and Token-Efficient Refinement
A skill that blends the wisdom of top industry experts, ensures token-efficient PRDs, and organizes outputs in a clear folder structure.
prd-os
PRD creation and PRD execution operating system. Use when the founder asks to turn a rough idea into a PRD, run a Codex review on a PRD or issue, decompose an approved PRD into issue specs, or execute an issue with scope enforcement and receipt-based closeout. Not for general product ideation or casual drafting; this…
decision-logger
Capture decision traces — the reasoning behind key PM decisions. Use after PRD approvals, scope changes, launch/kill calls, prioritization shifts, or any significant product decision.