Decisions
User Tasks
Summary
Auto-prioritize the feature backlog using a scoring formula that considers lifecycle stage, age, staleness, and blocker relationships — producing a sorted dashboard and priority field per FR.
Problem / Motivation
With a growing backlog of 40+ feature requests, manual prioritization becomes impossible:
No objective way to decide which FR to work on next
FRs that block many others sit unnoticed at the same priority as isolated nice-to-haves
Older items that have been waiting get the same visibility as freshly created ones
The user must mentally juggle dependencies, urgency, and stage to pick the next task
Inspired by Nexie’s priority scoring, which assigns a numeric score based on lifecycle stage, wait time, stall status, and blocker weighting. The result: a clear, auto-sorted backlog where the most impactful work surfaces to the top.
Proposed Solution
Build a scoring engine with these factors:
Total Score = Base Priority + Time Bonus + Stall Boost + Blocker Weight + Manual Adjustment
Factor Description Range Base Priority Points per lifecycle stage. Done-adjacent (in-progress) scores highest, early-stage (ideas) lowest 0-40 Time Bonus Longer waiting = higher priority, capped to prevent runaway scores 0-20 Stall Boost Stale items (from FR-040) get a priority bump to force attention 0-15 Blocker Weight FRs that are prerequisites for many others score higher (count of FRs blocked) 0-20 Manual Adjustment User can set a manual +/- modifier in frontmatter to override computed score -10 to +10
Stage Base Scores
Stage Base Score Rationale in-progress 40 Finish what you started planned 30 Already approved, ready to build new 20 Needs triage ideas 5 Lowest urgency
Output
priority-score field added to FR frontmatter (computed value)Feature dashboard sorted by priority score (highest first)
Daily briefing shows top-3 priority items
Priority breakdown available on demand (show factor contributions)
Open Questions
1. Scoring Weights
Question: What relative weights should each factor receive?
Option Description A) Stage-heavy Base priority dominates (40 of 105 max). Rewards finishing in-progress work B) Balanced All factors roughly equal weight (~25 each) C) Blocker-heavy Blocker weight dominates. Rewards unblocking other work
Recommendation: Option A — completing in-progress work should always be the top priority. Blocker weight serves as tiebreaker.
Decision:
2. Stored vs Computed
Question: Should the priority score be stored in frontmatter or computed on-the-fly?
Option Description A) Stored in frontmatter Score visible in Obsidian, but can become stale if not recalculated B) Computed on-the-fly Always accurate, but not visible in Obsidian without running the script C) Both — computed and cached Compute on demand, write result to frontmatter. Best of both worlds
Recommendation: Option C — compute when generating dashboards/briefings, write the result to frontmatter so it is visible in Obsidian too.
Decision:
3. Manual Override Handling
Question: How should manual priority overrides interact with computed scores?
Option Description A) Additive modifier Manual adjustment adds/subtracts from computed score (e.g., +10 or -5) B) Full override Manual score replaces computed score entirely C) Pin to top/bottom Simple toggle: “pinned-high” or “pinned-low” instead of numeric adjustment
Recommendation: Option A — additive modifier keeps the formula meaningful while allowing user nudges.
Decision:
Phase Overview
Phase Description Status Phase 1 Define formula + add priority field to template + manual calculation — Phase 2 Auto-calculate via script/skill, update dashboard — Phase 3 Integration with briefings (show top-priority items first) —
Goal: Define the scoring formula, add the priority-score field to the FR template, and enable manual calculation.
File / Feature Details Owner Status Scoring formula spec Document the exact formula with weights, ranges, and examples opus — Template update Add priority-score and priority-adjustment fields to _templates/feature-request.md opus — Manual calculation guide Instructions for manually computing priority (before automation exists) opus — Backfill existing FRs Add priority fields to all existing FR frontmatter (default values) opus —
Phase 2: Auto-Calculate via Script —
Goal: Build a Python script/skill that auto-computes priority scores for all FRs and updates frontmatter.
File / Feature Details Owner Status src/opus/priority/scorer.pyPriority scoring engine — parse all FRs, compute scores, return sorted list opus — src/opus/priority/factors.pyFactor calculations: base priority, time bonus, stall boost, blocker weight opus — Frontmatter writer Update priority-score in FR frontmatter after computation opus — Dashboard update Sort feature dashboard by priority score opus — /priority skillSkill to run scoring on demand and display results opus — Unit tests Test each factor calculation, total score, and edge cases opus —
Phase 3: Briefing Integration —
Goal: Integrate priority scoring with daily briefings so top-priority items are surfaced first.
File / Feature Details Owner Status Briefing integration Show top-3 priority FRs in daily briefing (FR-037) opus — Priority trends Track score changes over time — flag FRs whose priority is rising fast opus — Priority-based suggestions ”You should work on FR-XXX next (score: 85, reason: blocks 4 other FRs)“ opus —
Prerequisites / Gap Analysis
Requirements
Requirement Description REQ-1 Python project scaffold (FR-009) — scoring engine is Python code REQ-2 Stale detection (FR-040) — stall boost factor requires stale detection REQ-3 Daily briefings (FR-037) — Phase 3 integration
Current State
Component Status Details Python scaffold — FR-009 not started FR frontmatter done All FRs have status, priority, updated fields Feature dashboard done Exists in vault/00_system/dashboards/ Stale detection — FR-040 not started Daily briefings — FR-037 not started
Gap (What’s missing?)
Gap Effort Blocker? Python scaffold (FR-009) Med Yes — scoring engine is Python code Stale detection (FR-040) Med Partial — stall boost factor needs it, but other factors work without it Blocker graph Low No — can be parsed from FR frontmatter/related sections
Test
Manual tests
Test Expected Actual Last In-progress FR scores higher than new FR (all else equal) in-progress > new pending - FR waiting 30 days scores higher than FR waiting 1 day (same stage) Older FR scores higher pending - Stale FR receives stall boost Score increases by stall boost amount pending - FR blocking 3 others scores higher than FR blocking 0 Blocker FR scores higher pending - Manual adjustment of +10 increases final score by 10 Score = computed + 10 pending - Time bonus caps at maximum Score does not exceed cap regardless of age pending - Dashboard sorts FRs by priority score descending Highest score first pending -
AI-verified tests
Scenario Expected behavior Verification method … … …
E2E tests
Integration tests
Unit tests
Component Tests Coverage … … …
History
Date Event Details 2026-03-04 Created Inspired by Nexie’s priority scoring formula for auto-prioritizing the backlog
References
FR-009 (Python Project Scaffold) — code infrastructure prerequisite
FR-037 (Daily Briefings) — priority items surface in briefing output
FR-040 (Stale Detection) — stall boost factor depends on stale detection
FR-038 (Kanban Feature Overview) — dashboard displays priority-sorted items
FR-046 (Job Registry & Priority Queue) — priority scoring feeds into execution queue
Nexie (Sven Hennig) — original inspiration for priority scoring formula