jerseycheese Issue Prioritization
1. Discover the repo
If the user didn't specify a repo, infer it:
gh repo view --json nameWithOwner -q .nameWithOwner
2. Fetch all open issues
Pull the full backlog — not just recent issues:
gh issue list --state open --limit 200 --json number,title,labels,createdAt,body,milestone,comments
If the repo has more than 200 open issues, paginate. Also fetch any recent comments on the top candidates to catch context updates:
gh issue view [NUMBER] --json number,title,body,labels,comments,createdAt,milestone
3. Pre-filter
Skip issues labeled wontfix, duplicate, invalid, or question. Skip closed issues (should be excluded by the list query, but double-check).
4. Score each issue
For each issue, assess these dimensions. You don't need to output the raw scores — use them internally to reason about rank.
Value (0-10)
| Factor | Points |
|---|---|
| User-facing bug that breaks functionality | +3 |
| User-facing improvement | +2 |
| Internal/no user impact | +0-1 |
| Unblocks multiple other issues | +2 |
| Unblocks one other issue | +1 |
| Aligned with active milestone or roadmap goal | +2-3 |
Labels: critical, blocking, P0 |
+2 |
Effort (0-10, lower is better)
| Factor | Points |
|---|---|
| Major architectural change | +4 |
| Touches many files/systems | +3 |
| Moderate complexity | +2 |
| Simple, well-scoped change | +1 |
| Requires extensive E2E + manual testing | +3 |
| Unit tests only | +1 |
| Breaking changes or migrations | +3 |
| Low-risk, isolated change | +0-1 |
Labels: good first issue, small, quick |
-1 (lower effort) |
Age bonus
Issues that have been open longer tend to get pushed down unfairly. Apply a small bonus:
- Open 2-8 weeks: +0.1
- Open 2-6 months: +0.3
- Open 6+ months: +0.5
This is a tiebreaker, not a primary driver. A low-value chore open for a year still loses to a critical bug opened yesterday.
Priority score
score = (value * 2) / (effort + 1) + age_bonus
5. Select top 5
Rank by score. Among ties, prefer:
- Issues that unblock other work
- Older issues (age bonus already helps here)
- Better roadmap alignment
6. Create technical specs for top 3
For each of the top 3 candidates:
Problem statement — 1-2 sentences explaining the actual problem.
Scope boundaries
- What IS included
- What is NOT included (be explicit about adjacent work that's out of scope)
Technical approach — Brief approach that leverages existing patterns in the codebase. Check what's already there before assuming new code is needed.
Existing code to leverage — List specific components, utilities, or patterns that apply.
Implementation plan — 3-5 concrete steps.
MVP test plan — 2-4 tests that directly map to acceptance criteria. No "renders without crashing" tests.
Files to modify / create — Based on codebase exploration, not guessing.
Success criteria — Checkboxes pulled directly from the issue.
7. Output format
# Issue Priority Analysis
Total open issues analyzed: [N]
## Top 5 Candidates
### 1. #[number] — [title]
Priority score: [X]
- Value/Effort: [ratio and reasoning]
- Roadmap alignment: [High/Medium/Low — one sentence]
- Effort: [Small/Medium/Large]
- Dependencies: [list or "none"]
[Repeat for 2-5]
---
## Technical Specs (Top 3)
### #[number]: [title]
**Problem**
[1-2 sentences]
**Scope**
In: [list]
Out: [list]
**Approach**
[Brief technical approach]
**Existing code to leverage**
[List]
**Implementation plan**
1. [step]
2. [step]
3. [step]
**MVP tests**
1. [test and what it validates]
2. [test and what it validates]
**Files**
- Modify: [paths]
- Create: [paths]
**Success criteria**
- [ ] [criterion from issue]
---
[Repeat for other top candidates]
## Recommended next action
Work on #[NUMBER]. [One sentence on why this one over the others right now.]
Leave out emojis. Keep the output scannable — the user will skim it to make a final call.
8. Handing off to implementation
Once a candidate is picked, suggest driving the build with /goal rather than manual turn-by-turn iteration — e.g. /goal "issue #N acceptance criteria met, PR open, CI green". A separate evaluator decides when it's done, so the run doesn't need babysitting. For working several candidates at once, kick them off as background sessions (claude --bg) and watch them in Agent View (claude agents).