Neon Digital Playbook

Appearance

Pull Request Review Checklist ​

Pull Request reviews exist to ensure code is correct, understandable, and aligned with Neon standards. A review is not a rewrite—it is a verification that the work meets expectations and can be safely merged.

1. Correctness & Intent ​

  • The PR solves the problem it claims to solve
  • The implementation matches the job specification and acceptance criteria
  • No unrelated changes or drive-by refactors included
  • Commit messages and description explain why, not just what

If the reviewer cannot understand the intention, the PR is not ready.

2. Behaviour & UX ​

  • The feature behaves as described in the specification
  • User flows are logical and consistent with existing patterns
  • Validation, error handling, and messaging make sense
  • No unexpected or surprising interactions

Reviewers focus on functional UX sanity—not subjective aesthetics.

3. Code Quality & Maintainability ​

  • Code is readable without needing explanations
  • Names reflect intent (variables, methods, classes)
  • Logic is simple where possible—no unnecessary cleverness
  • No tightly coupled modules or hidden side effects
  • No commented-out code, unused imports, or debug logs

Ask: Will future developers understand this without context?

4. Security & Data Integrity ​

  • Input validated server-side, not just in the UI
  • Restricted actions gated by permissions or roles
  • No sensitive data logged, leaked, or returned unnecessarily
  • No assumptions about client input or trust in the browser

If this introduces new mutation paths, they must be explicit and safe.

5. Tests & Coverage (Where Applicable) ​

  • Relevant tests updated or added
  • Test names describe behaviour, not implementation
  • Tests reflect real-world usage, not internal quirks
  • No brittle tests relying on hidden assumptions

Absence of tests is acceptable only when justified.

6. Performance & Dependencies ​

  • No obvious inefficiencies or repeated queries
  • External dependencies introduced only when justified
  • No regressions to existing performance

Not micro-optimisation—just sanity.

7. Documentation & Comments ​

  • Complex decisions documented in the PR or code comments
  • Public-facing changes reflected in docs (if required)
  • Comments explain why, not what

Code should tell the story; comments should justify the plot twist.

8. Merge Readiness ​

  • Feature flag or config toggles correct (if used)
  • No console errors or warnings in runtime
  • Branch up to date with main branch
  • Migration scripts tested and safe to run repeatedly (if included)

The PR should be mergeable without follow-up chores.

Out of Scope for PR Review ​

Reviewers do not evaluate:

  • The original problem definition
  • High-level UX strategy or branding decisions
  • Architectural direction (unless it deviates from known patterns)
  • Personal preference or stylistic opinions

These belong to specification, architecture, and UX processes—not PR reviews.

Definition of Approval ​

A PR is approved when:

The reviewer trusts this code to run in production without causing confusion, regressions, or embarrassment.

If the reviewer hesitates, the PR is not ready.