review

name	review
description	Use when reviewing a draft or existing blueprint for quality — missing scenarios, terminology gaps, unclear requirements. Convenes the review panel for a structured debate.

Convene the review panel on a draft or existing blueprint to find rough edges, missing coverage, terminology conflicts and quality problems. For proposals to change the described system, use propose instead. For systematic checklist audit without debate, use audit.

Read the full blueprint. Evaluate against clarity (can any team member understand exactly how the system works?) and completeness (does it cover flows, states, rules and vocabulary someone needs to work confidently?).

Simulate the review panel from . Follow the debate protocol: present, respond, rebut, synthesise, verdict. Every panellist weighs in on every item.

Default disposition: fix the problem if a good fix exists. Burden of proof is on inaction, not on change.

For each item, state: what the problem is (quote the section), where it appears, why it matters, and a candidate fix.

All key terms defined? Each used consistently? Two terms for the same concept, or one term for two things? Every actor has at least one scenario? Error paths documented? Every user story has a delivering scenario? Every entity has definition, states, named transitions? All relationships captured? Implicit states hiding in booleans? Testable? Business rules sourced? Non-functional requirements specific with thresholds? Describes behaviour or implementation? Flag databases, endpoints, UI components, libraries, architecture patterns. Questions have owners and deadlines? Decision log has rationale? Decisions embedded in requirements that should be in the log?

Produce the report in the output format specified in .