Code Review Checklist Generator

Are user-provided values rendered safely instead of relying on dangerous HTML insertion or client-side trust?

Are authentication, authorization, and permission checks enforced in the correct layer?

Are inputs validated, sanitized, and encoded before they reach persistence or rendering?

Are secrets, tokens, and personal data kept out of logs, source control, and client bundles?

Did the change add or upgrade dependencies, and were the new security risks reviewed?

Are components avoiding unnecessary re-renders from unstable props, duplicated state, or over-broad context updates?

Will this change avoid obvious N+1 queries, redundant requests, and repeated expensive work?

Are loops, allocations, and data transforms reasonable for the expected traffic or dataset size?

Are caching, batching, pagination, or lazy loading used where they materially improve performance?

Could this code increase bundle size, startup time, or memory use in a way that should be measured?

Do hooks and component responsibilities stay small instead of mixing fetching, view logic, and side effects?

Are names, abstractions, and file boundaries clear enough that another engineer can follow the change quickly?

Is duplicated logic removed or intentionally shared through a small, understandable abstraction?

Do comments explain intent or tradeoffs instead of restating the code?

Has dead code, debug output, and leftover TODOs been removed or made actionable?

Do effects clean up subscriptions, timers, and async work to avoid stale updates or memory leaks?

Are failure states handled explicitly, with useful logs or messages and without swallowing the real error?

Do retries, fallbacks, timeouts, and cleanup behavior match the risk of the operation?

Are null, undefined, empty, or partial data cases covered instead of assuming the happy path?

Will the change fail safely without exposing data or leaving inconsistent state behind?

Do component tests validate user behavior rather than private implementation details?

Do tests cover the main path, high-risk edge cases, and the expected failure path for this change?

Are assertions specific enough to catch regressions instead of only checking implementation details?

Do fixtures, mocks, and seeded data stay realistic and easy to maintain?

If production behavior changed, does the PR explain how it was verified locally or in staging?

Do custom controls expose the same semantics and keyboard behavior as native elements?

If UI changed, are semantic structure, visible labels, and accessible names preserved?

If UI changed, can the flow be used with keyboard navigation, focus states, and screen readers?

Are color contrast, motion, and status messages appropriate for users with different needs?

Do interactive controls communicate validation, loading, and error states accessibly?

If props or component contracts changed, were usage examples or stories updated?

Does the pull request explain the why, what changed, and any rollout or migration steps?

Are new environment variables, feature flags, jobs, or operational runbooks documented?

If the change alters APIs or user-facing behavior, is the contract updated in docs or examples?

Are follow-up tasks, tradeoffs, and known limitations captured where the team will see them?