product-design-review

Product design review

Coordinates specialist skills into one review and owns only the coordination: which skills run, in what order, how their findings merge, and the final verdict. Every domain rule stays in the skill that owns it; this file never restates one.

For a change-scoped interface review with the better-* family installed, interface-review hands to better-interface, which already orchestrates the six interface specialists. Use this skill when the review is wider than the interface: a whole feature, a launch, or an input that needs the animation, agentic, deceptive-pattern, research or design-system lenses.

Inputs

• The subject: source code, a URL, screenshots, a prototype, or a diff. Say which, because it decides which accessibility skill runs.
• Product context: what the flow is for, platform (web, iOS, Android), whether an AI agent acts in it, whether it takes money, consent or personal data, whether a design system exists.
• Scope limits: what is out of scope for this review.

Workflow

1. Select the lenses

Read the catalog entries (or npm run search) only for the skills named below; do not load others. Pick the smallest set the input needs:

State the selected set and the reason each excluded lens was excluded.

2. Confirm availability

Before running, confirm each selected skill is installed. If one is missing, mark its lens Not reviewed, name the skill, and continue. Never recreate a missing skill's rules from memory or substitute a neighbour for it.

3. Run in order

Foundational failures first so polish does not mask them:

1. interface-review (diffs only) to fix scope and classify Introduced / Regression / Pre-existing.
2. Accessibility lens.
3. dark-pattern-review and agentic-ui-review when selected: they can change what the flow should be, which invalidates later polish findings.
4. better-layout, platform-conventions.
5. better-writing.
6. better-typography, better-colors, better-ui, review-animations.
7. design-debt-audit.

Read each selected SKILL.md completely before applying it, including the files it links. Take each specialist's principles, references and verification checks. Its standalone report format and severity ladder are replaced by the consolidated format below.

4. Consolidate

• Shared severity: HIGH blocks users, exposes money or data, breaks accessibility for a group, or lets an agent act irreversibly without approval. MEDIUM degrades the task for many users. LOW is polish. When a specialist rated differently, keep its rating inside its own domain and note the mapping.
• Deduplicate by root cause: when two lenses flag the same element, keep one finding under the skill whose domain owns the rule (a contrast failure is owned by better-accessibility deciding it fails and better-colors fixing the value; report it once, naming both). Never average two contradictory rules; pick the owner and state the conflict.
• Cap: at most 20 findings in the report; move the rest to an appendix ordered by severity, so the team can act on the top of the list.

5. Report

Scope: <what was reviewed, platform, input type>
Lenses run: <skill ids>   Not reviewed: <skill ids and why>
| Severity | Lens (owner skill) | Location | Finding | Fix |
Verdict: Block | Approve
Skills used: <ids>

Location is path:line, a screen name, or a selector. End with Block when any HIGH remains, Approve otherwise, and always list the skills used so the review is reproducible.

Before you finish