prd-architecture-review

Load both the PRD and the architecture document it claims to implement, then analyze the PRD through six lenses: architectural mismatches, vague areas, incorrect requirement translation, weak acceptance criteria, errors, and footguns. Classify each finding by severity and provide specific fixes.

Acceptance criteria are weak when they use qualitative measures without quantitative thresholds, such as "should be fast" or "user-friendly." Strong criteria are objectively verifiable, like "emits at most 20% of escape sequences versus full redraw, measured via a mock terminal."

Run the review after PRD creation and before any implementation starts, when architecture changes require PRD updates, and during review of PRD changes. Catching mismatches at this stage prevents costly rework during coding.

Findings are classified as Critical (will cause implementation failure or serious bugs, must fix), Moderate (causes friction or edge case bugs, should fix), or Minor (cleanup and consistency improvements, fix opportunistically).

Common anti-patterns include vague phrases like "handle appropriately" or "as needed," unmeasurable terms like "efficient" or "optimized," subjective claims like "user-friendly," untested compatibility claims, and unexplained magic numbers. Each should be replaced with explicit, measurable specifications.