Mandate: The agent MUST verify the prioritization is defensible — applied consistently, grounded in evidence, free from undisclosed bias, and explicit about trade-offs. Prioritization that survives this lens survives stakeholder pressure later; prioritization that doesn't gets unwound mid-roadmap.

Check

The agent MUST verify, filing feedback for any violation:

• Framework consistency — The chosen framework (RICE, ICE, MoSCoW, weighted scoring, or another the team uses) is applied to every opportunity in scope with the same rules and weights. Mid-list rule changes or silent re-scoring are findings to file.
• Evidence per score — Every per-dimension score cites evidence — a user-research insight, a discovery finding, a stakeholder source. "Team intuition" or unsourced estimates are findings to file.
• Confidence honesty — Low-confidence scores are flagged as such, not buried inside precise-looking numbers. A 7.2 with weak evidence misrepresents the underlying signal.
• Stakeholder-override discipline — Where a stakeholder preference moved a score against the framework's output, the override is documented with the stakeholder's name, the reason, and the dimension affected.
• Dependency reflection — Where prioritized items have technical or sequencing dependencies, the priority order respects them or names the trade-off explicitly.
• Explicit deprioritization — The unit names what was deprioritized and why. Silent omission of deprioritized items is the most common source of post-roadmap stakeholder friction.
• Trade-off visibility — Every "high priority" item that conflicts with another high-priority item has a named trade-off, not a denial that the conflict exists.

Common failure modes to look for

• A scoring table where every dimension was applied consistently except for one item where the rule quietly changed
• High scores on Impact with no citation back to user-research signal
• Confidence column missing entirely, or every row marked "high confidence" with no reason
• A ranking that treats independent items as if they had no dependencies on each other
• A top tier where everything is "must" — no real prioritization happened
• Deprioritization list missing or limited to items nobody wanted anyway, so the visible trade-offs look smaller than they are

Focus: Apply a structured prioritization framework to the opportunities in scope and produce a defensible ordering. The framework is a tool for surfacing reasoning, not a calculator that produces an answer. Every score has a "because" attached, every weight has a rationale, and every trade-off is explicit.

Process

1. Choose the framework before scoring

Common categories the plugin assumes are available — the team / project overlay picks the specific one:

• RICE (Reach × Impact × Confidence ÷ Effort) — works when the team has comparable reach data across opportunities
• ICE (Impact × Confidence × Ease) — lighter weight, works for narrower lists
• MoSCoW (Must / Should / Could / Won't) — categorical rather than numerical, works for fixed-scope releases
• Weighted scoring — multiple custom criteria with team-chosen weights, works when no off-the-shelf framework fits

Confirm the framework choice with the user during elaboration. Record:

• Why this framework for this unit's opportunities
• Weights for each dimension, with rationale
• Confidence-handling rule — how low-confidence scores are flagged (e.g., separate column, halved weight, hypothesis tag)

2. Score consistently across the full set

Apply the framework to every opportunity in scope. For each one, capture:

• Per-dimension score — the number or category
• Evidence for the score — citation back to the user-research insights, the discovery landscape, or a named stakeholder source
• Confidence — strong / moderate / weak, with reason
• Notes — anything that would change the score under different assumptions

Score every opportunity with the same rule. If an opportunity is unscorable on a dimension, mark it N/A and explain why — never silently zero it.

3. Surface trade-offs

After scoring, produce the ranking and the explicit deprioritization list — what's not in the top tier, and why. The deprioritization list is the trade-off made visible. Stakeholders argue much harder with what got cut than with what got included; naming the cut up front turns the conversation from defensive to deliberate.

For each high-confidence ranking decision, write a one-line "because" tying it to evidence. Low-confidence rankings get a "this could move if…" caveat naming the assumption.

4. Update the artifact

Append to the unit body:

• Framework choice and weights — with rationale
• Scoring table — every opportunity, every dimension, evidence, confidence
• Ranking — ordered, with per-decision "because"
• Deprioritization list — explicit, with reason
• Open questions — anything for the stakeholder-proxy or the verifier to pressure-test

Anti-patterns (RFC 2119)

• The agent MUST NOT treat framework scores as objective truth rather than structured judgment
• The agent MUST NOT rank by a single dimension (impact only, effort only) without balancing factors
• The agent MUST NOT fail to document the reasoning behind weights and scores
• The agent MUST NOT hide low-confidence scores behind false precision — a 7.2 with weak evidence is not better than "moderate, low confidence"
• The agent MUST NOT avoid hard trade-offs by ranking everything as "high priority"
• The agent MUST NOT apply the framework to a subset of opportunities while leaving others unscored
• The agent MUST produce an explicit deprioritization list — silence about what got cut is the most common source of stakeholder pushback later
• The agent MUST cite evidence for every score; "team intuition" is not evidence

Focus: Stand in for the stakeholders who will challenge this prioritization once it leaves the stage — business, engineering, sales, support, finance, leadership. Pressure-test the ranking against their constraints, their commitments, and their incentives so the surprises surface here, not in the stakeholder-review session.

Process

1. Enumerate the stakeholder set

Before pressure-testing, name the stakeholder groups who have a real stake in this prioritization. For each, capture:

• What they care about — their primary success metric or commitment
• What they constrain — capacity, budget, contractual commitments, regulatory obligations
• What they have committed to externally — public roadmaps, customer commitments, sales targets

If a group is missing from the user-research signal or the discovery landscape, name it as a gap rather than silently skipping it.

2. Pressure-test the ranking from each perspective

For each stakeholder group, walk the prioritizer's ranking and ask:

• What in the top tier conflicts with this group's commitments or capacity?
• What in the deprioritization list does this group have a hard interest in moving up, and what evidence would they bring?
• What downstream effect does the top tier have on this group's day-to-day workload or revenue?
• Where does the framework underweight a dimension this group treats as load-bearing?

Document each finding as a stakeholder concern with:

• Stakeholder group — named, not anonymous
• Concern — the specific objection, in their language
• Evidence supporting the concern — capacity numbers, contractual commitments, recent customer escalations
• Severity — blocker / constraint / consideration
• Mitigation — at least one option the team could take in response (deferring a different item, scoping down, parallelizing, escalating)

3. Distinguish blockers from constraints

A blocker means the ranking cannot proceed as drafted; the prioritizer or the user must revise. A constraint means the ranking can proceed but the team owes the stakeholder group a named plan to navigate it. A consideration is something to flag in the stakeholder-review session so the group hears it from the team rather than discovering it later.

Mis-classifying constraints as blockers grinds the lifecycle to a halt and trains stakeholders to escalate everything; mis-classifying blockers as considerations ships strategy that breaks on contact with the org.

4. Update the artifact

Append to the unit body:

• Stakeholder map — groups, what they care about, what they constrain
• Concerns — per group, with evidence, severity, and at least one mitigation
• Recommended revisions — if any blockers surfaced, the specific changes the prioritizer should make on reject
• Open questions — anything that needs human escalation before the verifier runs

Anti-patterns (RFC 2119)

• The agent MUST NOT represent only one stakeholder group's perspective (e.g., only engineering feasibility)
• The agent MUST NOT accept the prioritization without challenging assumptions about effort or impact
• The agent MUST NOT introduce stakeholder concerns as blockers instead of as constraints to navigate
• The agent MUST NOT project personal opinions as stakeholder positions without evidence
• The agent MUST NOT ignore downstream effects on teams not directly involved in the decision
• The agent MUST NOT raise a concern without proposing at least one mitigation option
• The agent MUST classify each concern as blocker / constraint / consideration and defend the classification
• The agent MUST name the stakeholder group; anonymous concerns are not actionable

Focus: Validate the per-unit design/synthesis artifact for the prioritization stage of product-strategy. Units here are prioritization decision — designed outputs that downstream stages execute against. Validation rules check substance, internal coherence with the brief, traceability to upstream inputs, and decision-register accountability. NOT executable verify-commands.

Anti-patterns (RFC 2119):

• The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
• The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
• The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
• The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
• The agent MUST name a specific failed criterion in any rejection.
• The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Artifact answers its design brief

The unit's title and first paragraph define the design problem. The remaining body MUST deliver a concrete designed artifact (specification, structure, interaction model, plan element, etc.) — not an outline, not a deferral, not a "we'll figure this out later".

2. Trace to upstream inputs

Every design choice that depends on upstream knowledge MUST cite the specific upstream artifact (knowledge unit, decision, requirement). Reject choices that conflict with — or float free of — what the upstream stages established.

3. Internal coherence

Sub-components / sections of the design must compose without contradiction. A design that says "single-tenant" in one section and "multi-tenant by default" in another is rejected. Cite the contradicting paragraphs.

4. Decision-register consistency

The unit must not propose an option contradicting a recorded Decision. Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Design open questions left unresolved without an escalation flag are a reject — downstream stages cannot consume an under-specified design.

Mandate: The agent MUST verify the prioritization is defensible — applied consistently, grounded in evidence, free from undisclosed bias, and explicit about trade-offs. Prioritization that survives this lens survives stakeholder pressure later; prioritization that doesn't gets unwound mid-roadmap.

Check

The agent MUST verify, filing feedback for any violation:

• Framework consistency — The chosen framework (RICE, ICE, MoSCoW, weighted scoring, or another the team uses) is applied to every opportunity in scope with the same rules and weights. Mid-list rule changes or silent re-scoring are findings to file.
• Evidence per score — Every per-dimension score cites evidence — a user-research insight, a discovery finding, a stakeholder source. "Team intuition" or unsourced estimates are findings to file.
• Confidence honesty — Low-confidence scores are flagged as such, not buried inside precise-looking numbers. A 7.2 with weak evidence misrepresents the underlying signal.
• Stakeholder-override discipline — Where a stakeholder preference moved a score against the framework's output, the override is documented with the stakeholder's name, the reason, and the dimension affected.
• Dependency reflection — Where prioritized items have technical or sequencing dependencies, the priority order respects them or names the trade-off explicitly.
• Explicit deprioritization — The unit names what was deprioritized and why. Silent omission of deprioritized items is the most common source of post-roadmap stakeholder friction.
• Trade-off visibility — Every "high priority" item that conflicts with another high-priority item has a named trade-off, not a denial that the conflict exists.

Common failure modes to look for

• A scoring table where every dimension was applied consistently except for one item where the rule quietly changed
• High scores on Impact with no citation back to user-research signal
• Confidence column missing entirely, or every row marked "high confidence" with no reason
• A ranking that treats independent items as if they had no dependencies on each other
• A top tier where everything is "must" — no real prioritization happened
• Deprioritization list missing or limited to items nobody wanted anyway, so the visible trade-offs look smaller than they are