feature-prioritization
Use when you have a backlog of features and need to rank them for the next sprint — scores each feature using Impact × Confidence × Effort matrix with SQL tracking for transparent prioritization.
Best use case
feature-prioritization is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when you have a backlog of features and need to rank them for the next sprint — scores each feature using Impact × Confidence × Effort matrix with SQL tracking for transparent prioritization.
Teams using feature-prioritization should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/feature-prioritization/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How feature-prioritization Compares
| Feature / Agent | feature-prioritization | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when you have a backlog of features and need to rank them for the next sprint — scores each feature using Impact × Confidence × Effort matrix with SQL tracking for transparent prioritization.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Feature Prioritization
Stop arguing about what to build. Use a scoring matrix to make prioritization
decisions fast, defensible, and transparent. Track everything in SQL so the
decision logic is auditable.
## The Matrix
Score each feature on three dimensions (1-5 scale):
| Dimension | 1 (Low) | 3 (Medium) | 5 (High) |
|-----------|---------|-----------|---------|
| **Impact** | Nice-to-have, <5% of users | Useful for core segment | Critical path, >30% of users or major revenue |
| **Confidence** | Hunch / no data | 1-2 data points | Validated by user research / A/B test |
| **Effort** | 5 = lowest (easy) | 3 = medium | 1 = highest (hardest) |
**Score = Impact × Confidence × Effort** (higher = higher priority)
> Note: Effort scoring is **inverted** — easy things score higher because ROI is better.
## Setup
```sql
CREATE TABLE features (
id TEXT PRIMARY KEY,
title TEXT NOT NULL,
description TEXT,
impact INTEGER, -- 1-5
confidence INTEGER, -- 1-5
effort INTEGER, -- 1-5 (5=easy, 1=very hard)
score REAL, -- impact * confidence * effort
status TEXT DEFAULT 'backlog', -- backlog | in_sprint | shipped | rejected
notes TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
```
## Workflow
### Step 1: List and Describe Features
```text
> I have the following feature requests for [product area]:
> [paste feature list or backlog items]
>
> For each feature, write a 1-sentence description of the user benefit.
> Then help me think through the scoring dimensions.
```
### Step 2: Score Each Feature
```text
> Let's score each feature against our prioritization matrix.
>
> For [Feature X]:
> - Impact: What % of users does this affect? Is it on the critical path to revenue?
> - Confidence: Do we have user research, data, or is this a hypothesis?
> - Effort: Engineering complexity estimate (S/M/L → 5/3/1)
>
> Challenge my assumptions if something seems over- or under-valued.
```
### Step 3: Insert into SQL
```sql
INSERT INTO features (id, title, description, impact, confidence, effort, score) VALUES
('f1', 'SSO integration', 'Enable login via corporate SSO (Okta, Azure AD)', 5, 4, 3, 60),
('f2', 'Dark mode', 'UI theme toggle', 2, 3, 4, 24),
('f3', 'Bulk import', 'Import records from CSV', 4, 5, 3, 60),
('f4', 'Email digest', 'Weekly summary email to users', 3, 2, 5, 30),
('f5', 'Public API v2', 'REST API for third-party integrations', 5, 3, 1, 15);
```
### Step 4: Generate the Priority Stack
```sql
-- Prioritized backlog
SELECT id, title, impact, confidence, effort, score,
RANK() OVER (ORDER BY score DESC) as priority_rank
FROM features
WHERE status = 'backlog'
ORDER BY score DESC;
```
### Step 5: Sense-Check with Copilot
```text
> Here's our prioritized feature list:
> [paste SQL output]
>
> Does this ranking look right to you? Are there any features where
> the score doesn't match your intuition? Flag them and explain why.
>
> Also: are there any dependencies between features we haven't accounted for?
```
### Step 6: Sprint Assignment
```sql
-- Move top 3 to current sprint
UPDATE features SET status = 'in_sprint'
WHERE id IN (
SELECT id FROM features
WHERE status = 'backlog'
ORDER BY score DESC
LIMIT 3
);
```
## Adjustments and Special Cases
### Must-Do Items (Compliance, Security)
Some features must be done regardless of score:
```sql
-- Force-rank compliance items
ALTER TABLE features ADD COLUMN is_mandatory INTEGER DEFAULT 0;
UPDATE features SET is_mandatory = 1 WHERE id IN ('gdpr-compliance', 'soc2-logging');
```
Query: mandatory items always come first, then by score.
### Strategic Bets
For high-impact, low-confidence, high-effort features (score is low but strategically important):
```text
> Feature [X] scores low because confidence is low. But strategically it could be
> a major differentiator. What's the cheapest experiment to raise confidence?
```
## Example Run
```text
> Score these 5 features from our Q2 roadmap:
> 1. Audit logs (compliance requirement, requested by 3 enterprise prospects)
> 2. Mobile app (requested by community, no revenue signal yet)
> 3. Faster search (top complaint in support tickets, affects all users)
> 4. Zapier integration (medium demand, very quick to build)
> 5. AI summaries (trendy, uncertain user value, long build time)
```
Expected output: Audit logs and Faster search rank first (high impact + confidence).
Zapier ranks high despite moderate demand (low effort = high ROI).
AI summaries rank low unless confidence can be raised.
## Tips
- **Score as a team**: Alignment on scoring surfaces hidden assumptions
- **Revisit quarterly**: Scores change as you learn more and market shifts
- **Track rejected features**: Record why you said no — prevents relitigating
- **Weight the dimensions**: If velocity is critical, multiply effort score by 2
- **Use SQL for transparency**: Share the scored backlog with stakeholdersRelated Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.