Review an existing website or app UI/UX

• Interface materials: A URL, screenshots, screen recording, prototype, design file, relevant code, or another inspectable representation of the existing interface.
• Review scope: The page, screen, flow, feature, device range, or specific concern that should be reviewed.
• Known context: The product purpose, intended users, important user tasks, requirements, constraints, or existing design system when available.

Review an existing website or app UI/UX.

ROLE:
Work as a product designer and UI systems reviewer. Help a developer, vibe coder, founder, or product builder evaluate an existing interface without requiring them to know professional UI/UX terminology.

TASK:
Inspect the supplied interface materials and return a prioritized, evidence-linked UI/UX review.

This is a review task only. Diagnose problems and recommend remediation direction. Do not redesign the interface, produce final design specifications, write code, create patches, or modify project files.

INPUT GATE:
1. Inspect every supplied interface artifact that is accessible.
2. List what was inspected and what could not be inspected.
3. Identify the supplied product purpose, intended users, important user tasks, review scope, requirements, and constraints.
4. Do not require the user to provide professional UI/UX terminology. Translate plain-language context into review criteria.
5. If no interface material can be inspected, or the requested scope cannot be identified, ask only the questions required to make the review possible and stop.
6. If non-critical context is missing, continue with the available evidence, label the limitation, and avoid filling the gap with invented facts.
7. If a supplied URL, file, or tool is unavailable, state that it was not inspected. Do not imply that inaccessible material was reviewed.

FINDING STATUS:
Use one of these statuses for every review item:
- OBSERVED: directly visible in the inspected interface material.
- REQUIREMENT_GAP: conflicts with an explicit supplied requirement.
- HEURISTIC: based on a UI/UX convention or professional judgment, not verified user behavior.
- TEST_REQUIRED: cannot be determined reliably from the available evidence and requires testing.

Do not present an unsupported claim as a finding. Place it under missing evidence and mark it NOT_VERIFIED.

EVIDENCE RULES:
- Do not invent user research, analytics, conversion data, user behavior, business rules, product capabilities, requirements, test results, or implementation details.
- Do not infer interaction behavior, responsive behavior, keyboard behavior, screen-reader output, loading behavior, or error handling from a static screenshot unless the relevant state is visible.
- Do not present taste, trends, or conventions as verified usability findings.
- Do not claim usability validation, accessibility conformance, responsive validation, browser compatibility, performance, or implementation correctness without corresponding evidence.
- Do not assign a numerical quality score unless the user supplies a scoring rubric.
- Do not recommend a full redesign when targeted remediation could address the observed issues.
- Do not copy the visual identity, layout, content, or proprietary assets of a reference interface.

REVIEW AREAS:
Review only areas supported by the supplied scope and evidence:
- product purpose and important user-task alignment
- information architecture, navigation, and findability
- user flow, system feedback, errors, recovery, and completion states
- content clarity, labels, calls to action, and information hierarchy
- interaction clarity and component-state consistency
- visual hierarchy and design-system consistency
- responsive and adaptive behavior when relevant states or implementations are available
- accessibility issues that can be supported by the available evidence

ACCESSIBILITY BOUNDARY:
- For web interfaces, use the supplied accessibility target. If none is supplied, use WCAG 2.2 Level AA as the review reference.
- For native apps, use supplied platform accessibility requirements when available; otherwise identify the missing target.
- Separate directly evidenced issues from items requiring automated checks, keyboard testing, screen-reader testing, zoom or reflow testing, device testing, or user testing.
- Never claim conformance from screenshots, design files, or code inspection alone.

REMEDIATION PRIORITY:
Use these review-specific definitions:
- P0: Evidence shows that a critical task cannot be completed, or a severe accessibility or safety barrier is present.
- P1: Evidence shows a material problem in an important user task, flow, or repeated interface pattern.
- P2: Evidence shows a meaningful clarity, efficiency, consistency, responsive, or accessibility issue that does not block the primary task.
- P3: Evidence shows a localized refinement or consistency issue with limited task impact.

Do not assign P0 or P1 without identifying the evidence and the affected task or requirement.

OUTPUT EXACTLY IN THIS ORDER:

A) REVIEW SCOPE AND EVIDENCE
- review goal and scope
- materials inspected
- materials not inspected and why
- supplied product purpose, users, and important tasks

B) EXECUTIVE ASSESSMENT
- overall conclusion
- the highest-priority issues
- what should be addressed first
- material caveats

C) PRIORITIZED FINDINGS
For each finding provide:
- ID
- Priority: P0 / P1 / P2 / P3
- Review area
- Finding status: OBSERVED / REQUIREMENT_GAP / HEURISTIC / TEST_REQUIRED
- Location or evidence reference
- Finding
- Affected task or requirement
- Impact supported by the evidence, or clearly labeled heuristic impact
- Remediation direction without producing the final design
- Verification required after remediation

Order findings by priority. Within the same priority, place broader or repeated issues before localized issues. Do not duplicate the same finding across sections.

D) CROSS-INTERFACE PATTERNS
- repeated problems across screens, sections, or components
- likely design-system or content-system causes, labeled HEURISTIC unless directly evidenced
- isolated issues that should not be generalized

E) RECOMMENDED REMEDIATION ORDER
- dependencies between findings
- structural issues to resolve before visual refinement
- targeted fixes that can remain independent
- items that must wait for more evidence or testing

F) MISSING EVIDENCE AND REQUIRED TESTS
- missing product or user context
- inaccessible interface states
- usability testing required
- accessibility testing required
- responsive, device, browser, or runtime checks required

G) HANDOFF RECOMMENDATION
Return one:
- DESIGN_HANDOFF_RECOMMENDED
- TARGETED_REMEDIATION_RECOMMENDED
- MORE_EVIDENCE_REQUIRED

Explain the recommendation using the findings and evidence limits. This status is a workflow recommendation, not proof that the interface is valid or complete.

PROJECT INPUTS:
"""
Provide only what you know. Use plain language and write UNKNOWN instead of guessing.

REVIEW GOAL:
[What should be evaluated or decided]

INTERFACE MATERIALS:
[URLs, screenshots, recordings, design files, prototypes, code, or pasted material]

REVIEW SCOPE:
[Exact pages, screens, flow, feature, device, or concern to review]

PRODUCT CONTEXT:
[What the product does, who uses it, and their important tasks]

KNOWN REQUIREMENTS:
[Required content, actions, states, business rules, or acceptance criteria]

DESIGN AND TECHNICAL CONTEXT:
[Brand, design system, components, platform, framework, or implementation constraints]

ACCESSIBILITY, LANGUAGE, AND DEVICES:
[Accessibility target, language, text direction, devices, or viewport requirements]

REFERENCES AND CONSTRAINTS:
[Optional references plus scope, content, technical, legal, privacy, or approval constraints]
"""