Guide
How a product team can review specs with AI before building
A product team can have AI review every spec the same way before engineering starts. Ask it to walk the flow as a first-time user and log every point where the spec doesn't say what happens next. Then check each screen's empty, loading, error, partial-data and no-permission states; flag words like "fast", "simple" and "as needed" that two people would test differently; check limits and what happens to existing data; check for one success metric with a baseline and a target; and check that the feature can roll out gradually and be switched off without a release. Findings come back ranked as blocking, should fix or nit, each quoting the spec with a proposed fix.
Short answer
- Walk the flow as a first-time user.
- Every screen's states: empty, loading, error, no permission.
- Vague words, limits, metric, rollback.
- Ranked findings, each with a quote and a fix.
The brief to copy
Spec review brief
"Review this spec before we build it.
Walk the flow as a first-time user from where they arrive. Log every step where the spec doesn't say what they see next, and every label a new user would puzzle over.
For each screen, check empty, loading, error, partial data, no permission and success.
Flag 'fast', 'easy', 'simple', 'should', 'etc.', 'some', 'as needed' and any requirement two readers could test differently.
Check who can do this, how many, what happens at the limit, and what happens to existing data. Check for one primary metric with a baseline and target. Check rollout (flag, who first) and rollback (what triggers it, can it be switched off without a release).
Rank findings: blocking, should fix, nit. Quote the spec, say why it matters, propose a fix.
Spec: [paste]"
A worked example
Illustration: a made-up business. A product team at a 40-person invoicing company writes a spec for "recurring invoices". From the review:
From the review
Blocking: "Users can set invoices to repeat." The spec doesn't say what happens to a recurring invoice when the customer record is deleted. Fix: decide whether future invoices stop or keep the last details, and say so.
Blocking: no rollback. Fix: release behind a flag to 10% of accounts, with a switch that stops new recurring invoices without a release.
Should fix: the schedule screen has no empty state for a first-time user. Fix: one line on what recurring invoices do and a "Set up your first" button.
Should fix: "Invoices go out quickly after the due date." Fix: a number, such as "within 15 minutes of 9:00 in the account's time zone".
Should fix: no metric. Fix: share of invoices sent on schedule, with today's manual baseline and a target.
The product manager fixes the two blocking items before the planning meeting and leaves the nits for the copy review.
Make it the team's habit
- Run the same review on every spec before it goes to planning.
- Attach the findings to the spec, with what was decided.
- Treat blocking findings as a gate for the planning meeting.
- Keep customer data out of specs you paste into a personal account.
- Add a check when the same gap reaches production twice.
Next step: make it a skill in the repository
A review the whole team runs belongs where everyone's AI reads it. Creating a skill in Claude Code covers putting it in the repository, and SKILL.md vs AGENTS.md covers what goes where.
Skills for this
- ProductSpec review before buildReviews a PRD or spec before build for ambiguity, missing empty/loading/error/permission states, metrics, rollout, and a first-time user walk-through.
- ProductPRD from messy notesTurns notes, Slack threads, and call notes into a PRD: problem with evidence, goals and non-goals, metrics, must/should/could requirements, and flagged gaps.
- ProductUser stories with acceptance criteriaTurns a feature into user stories with Given/When/Then acceptance criteria, edge cases, out-of-scope notes, and an INVEST check per story.
- ProductFeature prioritization with RICEScores a backlog with RICE or ICE, shows the math per item, tests sensitivity, recommends a cut line for capacity, and flags dependencies.
Questions
Can AI review a product spec?
Yes, as a consistent first reviewer. Ask it to walk the flow as a first-time user, check every screen for empty, loading, error, partial-data and no-permission states, flag vague words like 'fast' or 'as needed', check limits, the success metric and the rollout and rollback plan, and rank findings as blocking, should fix or nit, each quoting the spec.
What should a spec review check?
That a new user can get through the flow, that every screen has its states, that every requirement can be tested one way, that limits and existing data are covered, that there is one metric with a baseline and target, and that the feature can be rolled out gradually and switched off without a release.
Does an AI spec review replace the team's review?
No. It gives every spec the same baseline checks so the team's review time goes to the product decisions. The product manager decides which findings to act on.
AI skill
Have your AI review a spec before anyone builds it
Put this skill in AI Skill Pod and everyone on your team gets it in their Claude, Cursor or ChatGPT (Pro, Business, Enterprise): one invite link, free to start. Spec review before build has your AI review each spec: the flow walked as a first-time user, every screen's states checked, vague words flagged, limits, metrics and rollback checked, and findings ranked with a quote and a fix.
14 days free · No card needed
Sources
- Nielsen Norman Group: Designing empty states — show system status, teach how to start, give a direct path to the task (read 2026-11-04)
- Nielsen Norman Group: Error-message guidelines (read 2026-11-04)
- Martin Fowler: Feature toggles — release toggles, gradual rollouts and kill switches (read 2026-11-04)