nw-po-review-dimensions

# 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 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...