fix(prioritize-epics): prevent anchoring on current priority during re-sort

The Phase 3 coarse-sort sub-agent reads each epic via `ticket show <id>`,
which surfaces the current `priority` field. Without explicit guidance, an
LLM evaluator can anchor on existing P0–P4 values — defaulting a stale P4
epic into `out_of_scope` even when its content aligns with the new North
Star. Same anchoring risk exists in Phase 4's high/low value scoring.

- coarse-sort-batch.md: add explicit "do NOT use current priority as a
  bucket signal" rule with concrete P0/P4 reclassification examples.
- phase-4-granular-sort.md: add anti-anchor rule near the priority
  mapping table covering all of Step 1–3.

Author: claude

plugins/dso/skills/prioritize-epics/phases/phase-4-granular-sort.md

@@ -12,6 +12,8 @@ Priority mapping for this phase:
 | Optional additions | High value | **P2** |
 | Optional additions | Low value | **P3** |
 
+**Anti-anchor rule (applies to every step in this phase)**: an epic's *current* priority MUST NOT influence its new priority. The bucket decision from Phase 3 (computed without reference to current priority — see `prompts/coarse-sort-batch.md` Calibration) is the only input. A previously-P4 epic that landed in `BUCKETS.north_star` becomes P0 or P1 like any other North Star epic; a previously-P0 epic that landed in `BUCKETS.out_of_scope` becomes P4. Re-prioritization is the whole point of the skill.
+
 ## Step 1 — Out of scope → P4
 
 For every epic in `BUCKETS.out_of_scope` (including Phase 1 `OUT_OF_SCOPE_IDS`, which were already set to P4 in Phase 1 Step 2 — re-running is idempotent):

plugins/dso/skills/prioritize-epics/prompts/coarse-sort-batch.md

@@ -72,5 +72,6 @@ Every ID in the input `epic_ids` MUST appear exactly once in `assignments`.
 
 - **High-confidence** means a sober reader would agree on the bucket without needing to ask follow-up questions. If you find yourself wanting to ask the user "did you mean X or Y?" — that's a `needs_review` signal, not a forced choice.
 - **Do NOT bias toward North Star.** Many epics in a healthy backlog are "in scope but not strategic" — that's exactly what `optional_additions` is for. The North Star bucket should be the strict subset that directly drives the user's stated single-most-important value.
+- **Do NOT use the epic's current `priority` field as a bucket signal.** This skill exists precisely to re-prioritize; existing P0–P4 values reflect prior context that may no longer be current. A P4 epic that aligns with today's North Star belongs in `north_star`; a P0 epic that conflicts with today's Out of Scope belongs in `out_of_scope`. Evaluate the epic's content against the supplied `north_star` / `out_of_scope_definition` only — never against `pr`/`priority` in the `ticket show` output.
 - **Do NOT use child counts, completion percentage, or last-modified date as bucket signals.** Those are work-readiness signals, not prioritization signals.
 - **Keep rationales to a single sentence.** Cite the specific phrase in the North Star or Out of Scope definition that drove the decision.