Nativ ui
Documentation

Frontend Review Prompts

Review prompts tailored to frontend / website work — UI, accessibility, performance, and component architecture.

Overview

A review prompt focused on frontend & website concerns: component design, accessibility, rendering performance, responsive behavior, and design-system consistency. Paste your component, page, or diff into [CONTENT].

Frontend Code Review

<instruction_set>
  <role>
    Act as a Senior Frontend Engineer and UI Architect. Review the provided frontend code
    against production standards for accessibility, performance, and maintainability.
  </role>
 
  <objective>
    Validate the UI implementation for correctness, accessibility, responsive behavior,
    and rendering performance — with zero "ship it and fix later" compromises.
  </objective>
 
  <process_audit>
    <step>
      <title>Component Architecture</title>
      <challenge_questions>
        - Is the component split at the right boundaries (presentational vs container)?
        - Is state colocated correctly, or lifted/leaked unnecessarily?
        - Are props minimal and typed, or is the API leaking implementation details?
        - Is this reusable across the design system, or hardcoded to one screen?
      </challenge_questions>
    </step>
    <step>
      <title>Accessibility (a11y)</title>
      <challenge_questions>
        - Are semantic elements used, with correct roles and ARIA only where needed?
        - Is it fully keyboard-navigable with a visible focus ring?
        - Do interactive elements meet contrast and hit-target minimums?
        - Are images, icons, and controls labelled for screen readers?
      </challenge_questions>
    </step>
    <step>
      <title>Rendering Performance</title>
      <challenge_questions>
        - Are there unnecessary re-renders (missing memo, unstable props/keys)?
        - Is heavy work deferred, virtualized, or lazy-loaded?
        - Are layout-thrashing reads/writes or large reflows introduced?
        - Are images/fonts/assets optimized and correctly sized?
      </challenge_questions>
    </step>
    <step>
      <title>Responsive & Cross-Browser</title>
      <challenge_questions>
        - Does the layout hold from small mobile to ultra-wide without overflow?
        - Are breakpoints consistent with the design system?
        - Are CSS features used supported on target browsers (or gracefully degraded)?
      </challenge_questions>
    </step>
    <step>
      <title>Design-System Consistency</title>
      <challenge_questions>
        - Are spacing, typography, color, and radius tokens used instead of magic values?
        - Does it match existing component conventions?
      </challenge_questions>
    </step>
  </process_audit>
 
  <missing_context_protocol>
    If something is ambiguous, pause that step and request the missing design spec, token
    definitions, or target-browser matrix. Make no assumptions.
  </missing_context_protocol>
 
  <output_format>
    For each item analyzed:
    - [STATUS] (Approved / Needs Fix / Awaiting Clarification)
    - [CRITIQUE] Concise technical analysis.
    - [FIX] Specific improved code or class change.
    - [QUESTION_IF_NEEDED] Missing context to finalize.
  </output_format>
</instruction_set>
 
<code_to_review>
 
[CONTENT]
 
</code_to_review>

When to use

  • Reviewing a new component or page before merging
  • Auditing accessibility before a release
  • Catching re-render and asset-weight regressions
  • Enforcing design-system token usage

Tips

  1. Feed the design tokens at the top of [CONTENT] so the model can flag magic values
  2. Pair with a screenshot description for layout-specific feedback
  3. Run per-component rather than dumping a whole route