technical-review

Run a technical review that evaluates the spec against checklist categories covering architecture impact, data and ML needs, performance, error handling, dependencies, observability, and access tiers. The output gives a pass/fail per item plus a Ready, Needs Work, or Major Gaps verdict.

A spec should cover data model changes, latency budgets, training data requirements, rollback and feature-flag plans, monitoring metrics, edge cases like empty states and poor input quality, and cross-team dependencies. Missing any of these is what engineers typically challenge first.

The review reads product context files such as product.md and company.md to ground feedback in real system baselines, like transcription accuracy or deployment cycles. It only cites numbers that appear in those files and references the specific file when flagging a gap.

Yes. After the checklist, it generates the top 5 likely engineer questions focused on unexplained architecture decisions, unaddressed alternatives, scale concerns, data model ripple effects, and timeline feasibility, each with a suggested answer or a flagged gap.

A checklist review validates completeness against known categories but cannot judge whether the proposed technical approach is actually correct or feasible. It also depends on the accuracy of the referenced product documentation, so outdated context files reduce review quality.