prioritize agent: blocker RICE score must be at least as high as blocked issues

[ifireball]

What happens

The prioritize agent scores each issue in isolation and writes a RICE Score to the project board using (reach × impact × confidence) / effort (see internal/scaffold/fullsend-repo/scripts/post-prioritize.sh). A blocking issue can end up with a lower RICE Score than one or more issues it blocks.

When the board is sorted by RICE Score, blocked work can rank above its blocker even though it cannot proceed until the blocker is resolved.

What should happen

For any open issue that blocks other open issues, its computed RICE Score should be greater than or equal to the RICE Score of every issue it blocks.

Example: if issue A blocks B (score 2.4) and C (score 1.8), A’s score must be ≥ 2.4 and ≥ 1.8.

How to reproduce

1. Identify an open issue A that blocks other open issues B/C (e.g. via triage blocked label and blocked_by URL, GitHub blocked-by linkage, or an explicit dependency called out in comments).
2. Ensure B and/or C already have RICE Scores on the project board.
3. Run the prioritize agent on A (scheduler or manual dispatch).
4. Compare A’s new RICE Score to the scores on B and C.

Observed: A’s score can be lower than a blocked issue’s score.

Expected: A’s score is at least as high as each blocked issue’s score.

Context

• The prioritize agent prompt (agents/prioritize.md) does not instruct the agent to consider blocking or dependency relationships when scoring.
• The triage agent already searches for blocking relationships and records blocked_by URLs (agents/triage.md), but that signal is not consumed by prioritize today.
• Per-issue scorer epic: Agent: per-issue priority scorer #329
• Related: customer-feedback loop for scoring (Establish continuous customer feedback loop for agent-driven prioritization #633) — separate from dependency ordering, but both affect score quality.

[fullsend-ai-triage]

Triage Summary

Category: Feature — the prioritize agent has never considered blocking relationships when scoring.

Problem: The prioritize agent scores each issue in isolation. A blocker can end up with a lower RICE Score than the issues it blocks, causing the project board to misrank work.

Root cause: Neither the agent prompt (agents/prioritize.md) nor the post-processing script (post-prioritize.sh) queries or considers blocked issues' scores.

Recommended approach:

Two options (can be combined):

1. Agent prompt update — instruct the prioritize agent to look up issues blocked by the current issue, read their RICE scores from the project board, and floor its own score at the max.
2. Post-script enforcement — add a step in post-prioritize.sh that queries blocked issues' scores and bumps the blocker if needed. This provides a hard guarantee.

Proposed test case:

Given: Issue A blocks issues B (score 2.4) and C (score 1.8)
When:  Prioritize agent runs on issue A
Then:  A's final RICE Score >= 2.4

Edge cases:
- A blocks no issues → score unchanged
- A's organic score already >= all blocked scores → score unchanged
- Blocked issue has no score yet → skip it
- Circular dependencies → no infinite loop

The referenced epic #329 is closed, and #633 (customer feedback loop) is noted as separate work. This feature can be implemented independently.

---

Labels: Issue affects the prioritize agent scaffolded files and is a medium-priority enhancement to board ranking accuracy.