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 agentmods add rules/kaelsensei/magicaibuilder/us-prioritizationgit clone --depth 1 https://github.com/KaelSensei/MagicAIBuilderWrote 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/rules/kaelsensei/magicaibuilder/us-prioritization)<a href="https://agentmods.dev/rules/kaelsensei/magicaibuilder/us-prioritization"><img src="https://agentmods.dev/badge/rules/kaelsensei/magicaibuilder/us-prioritization.svg" alt="Measured on agentmods" 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.04157 | $0.04157 |
| Opus 5 | $0.02079 | $0.02079 |
| Sonnet 5 | $0.00831 | $0.00831 |
| Haiku 4.5 | $0.00416 | $0.00416 |
Grade A, and why
us-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 5d 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 — 415 lines — stays where its author put it; the contents beside it link to each section on GitHub.
NOTE: Cursor .cursor/skills/*.mdc files use alwaysApply frontmatter.
Set to false so it only applies when relevant.
alwaysApply: false
User Story Prioritization & Weighting
Master the three core frameworks for prioritizing user stories, estimating effort, and making data-driven decisions about what to build next.
Overview
Three complementary methodologies exist for prioritization, each optimized for different contexts:
| Framework | Best For | Core Metric | Effort | Data Need |
|---|---|---|---|---|
| Story Points | Team capacity planning | Relative complexity | Low | Internal only |
| MoSCoW | Risk/scope management | Business category | Minimal | Strategic alignment |
| RICE Scoring | Product-led growth | Quantified ROI | Medium | Usage + analytics |
Best practice: Use all three in parallel. They answer different questions:
- Story Points → Can we deliver this in the sprint?
- MoSCoW → Will this break the product if we skip it?
- RICE → Which delivers the most business value per engineering day?
Story Points (Planning Poker)
What It Is
A Fibonacci-scaled (1, 2, 3, 5, 8, 13, 21) estimation of relative complexity, not time. Forces binary choice between "close to this story" vs. "further away."
Why Fibonacci?
- 1, 2, 3: Fine-grain distinctions for small tasks
- 5, 8, 13: Clear jumps for complexity gaps
- 21+: Signals overscoping — usually needs splitting
When to Use
✅ Stable team, established velocity ✅ Predictable feature work (bug fixes, increments) ✅ Need to track burndown / capacity ✅ Multiple sprints planned ahead
❌ New team (velocity unknown) ❌ Emergency/ad-hoc work (can't predict velocity) ❌ Highly variable task scope (infrastructure, research)
Running Planning Poker
- Read the story aloud; clarify questions
- Each person silently picks a point value (1–21) without discussion
- Reveal simultaneously — outliers explain their thinking
- Re-estimate once if there was a wide spread
- Accept the estimate (don't aim for consensus, aim for reasonableness)
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.
- 5d ago First seen · 415 lines · 4,157 tokens per session scan A 24d74aa5b528
us-prioritization is a cursor rule published in the GitHub repository KaelSensei/MagicAIBuilder (2 stars, last pushed 3d ago), licensed MIT. It adds 4,157 tokens to every session, about $0.0208 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-31.
Other cursor rules, from other repositories
server-actions
Server Action, service and tenancy contract.
project
Product, stack and layer contract. Always applies.
ui-design-system
UI, design tokens and mobile-first rules.
performance
Navigation, caching and PWA contract.
prisma-schema
Prisma schema and migration conventions.
tdd-domain
TDD contract for business logic.