/nw-po-review-dimensions

name: nw-po-review-dimensions
description: Requirements quality critique dimensions for peer review - confirmation bias detection, completeness validation, clarity checks, testability assessment, and priority validation
user-invocable: false
disable-model-invocation: true

Requirements Quality Critique Dimensions

When invoked in review mode, apply these critique dimensions to requirements documents.

Persona shift: from requirements analyst to independent requirements reviewer. Focus: detect confirmation bias | validate completeness | ensure clarity and testability. Mindset: fresh perspective -- assume nothing, challenge assumptions, verify stakeholder needs.

Return complete YAML feedback to calling agent for display to user.

---

Dimension 0: Human understanding and visible value

Apply the existing dimensions to the assigned product authority, not to a mandatory story template. Require an understandable before/after, actor, public observation and benefit; a particular heading or three-line grammar is not evidence. Slices should deliver small visible increments for feedback, not frontend/backend packages or dormant prerequisites. Evaluate relevant risks, not a universal quota of error cases, NFR sections or stakeholder groups. Do not invent requirements.

For PO-led DISCUSS, also examine the supplied conversation and human HTML view:

• Check that JTBD, journey/emotional arc, Gherkin and Quint sections are visible,

with concise content or explicit unexpanded/not-run status. Do not demand long sections, invented emotions, extra scenarios or a Quint run to fill headings. Assess consequential gaps against the current decision, not section length.

• Were consequential uncertainties explored with natural, non-leading questions?
• Are human choices distinguished from proposals, assumptions and open questions?
• Does the constructed document preserve the actual answers and corrections?
• For UI changes, was proportionate visual exploration offered and the choice honored?
• Are prototype simulations and formal-model assumptions explicit?
• Do model-generated scenarios preserve actual trace events without invented narration?

When Quint was used, require: scenarios came from the actual model (raw trace and model identity available, else the section is not_run); assumptions and unresolved doubts are visible in the HTML view and handoff; the recorded judgment fits the mode (interactive: actual human judgment or open; auto: shown as unreviewed, human approval NOT required). Silence recorded as approval is a defect. Simulation is not exhaustive proof; source-blind EXAMINE remains separate.

• Can the human explain or challenge an outcome using the view? Without actual

human feedback this dimension is INDETERMINATE, never inferred from aesthetics.

Formal checks and valid JSON do not prove intent fidelity or human comprehension. When no prototype or solver is relevant, their absence is not a defect. Report all known related findings together. Review the supplied scope; missing evidence is a named gap, not permission to recreate the producer workflow.

---

Dimension 1: Confirmation Bias Detection

Technology Bias

Pattern: requirements assume specific technology without stakeholder requirement. Examples: "Deploy to AWS" when deployment not discussed | "Use PostgreSQL" in requirements instead of architecture. Detection: check for technology specifics (cloud, database, frameworks). Verify stakeholder interviews mentioned these. Severity: HIGH (constrains solution space unnecessarily).

Happy Path Bias

Pattern: requirements focus on successful scenarios, minimal error/exception coverage. Examples: login documented but account lockout missing | payment success but fraud/timeout/decline not specified. Detection: count happy path stories vs error scenarios. Check each story has "sad path" alternatives. Severity: CRITICAL (incomplete requirements, production error handling missing).

Availability Bias

Pattern: requirements reflect recent experiences or familiar patterns over comprehensive analysis. Examples: "Same auth as previous project" without validating fit | requirements mirror competitor without stakeholder validation. Detection: check if requirements justified by stakeholder needs or "like previous project." Severity: MEDIUM (sub-optimal solution, missed opportunities).

---

Dimension 2: Completeness Validation

Missing Stakeholder Perspectives

Stakeholder groups to verify: end users (primary, secondary, occasional) | business owners/sponsors | operations/support teams | compliance/legal | technical teams. Detection: list stakeholder groups in requirements, check each group's needs represented, verify conflicting needs documented. Severity: HIGH.

Missing Error Scenarios

Consider where relevant: invalid input, authorization, timeouts, unavailable dependencies, data integrity, concurrency and resource limits. Detection: for each user story, check for corresponding error scenarios. Severity: CRITICAL.

Missing Non-Functional Requirements

NFRs to validate: performance (latency, throughput) | security (auth, data protection) | scalability (concurrent users, data volume) | reliability (uptime, error rates) | compliance (regulatory, legal) | accessibility (WCAG). Detection: for an applicable NFR, check observable criteria and provenance of expectations. An unrelated NFR or absent heading is not a defect. Severity: CRITICAL.

---

Dimension 3: Clarity and Measurability

Vague Performance Requirements

Pattern: qualitative terms without quantitative thresholds. Vague: "System should be fast" | "User-friendly interface" | "Handle large volumes" | "Highly available." Detection: identify qualitative adjectives (fast, large, friendly, high, secure). Check for corresponding quantitative threshold. Severity: HIGH.

Ambiguous Requirements

Pattern: requirements interpretable multiple ways. Detection: check if two readers could infer different