Engineering

Review JavaScript Code with AI

Best-practices review with JavaScript's own traps added: equality coercion, floating promises, this-binding, shared-object mutation.

Overview

JavaScript review needs JavaScript questions. This setup runs the best-practices focus — idioms, framework conventions, deprecated APIs, ecosystem-style error handling, standard library over reinvention — with the JavaScript language pack adding the four traps that generic reviews miss: == comparisons that should be ===, unhandled promise rejections and floating promises, "this" binding in callbacks and class methods, and mutation of shared objects or function arguments. Balanced style keeps the findings prioritized.

Workflow

Review file by file
Single File scope judges structure and imports too — where JavaScript codebases usually drift first.
Take the promise findings seriously
Unhandled rejections are the JavaScript failure mode that skips every test and hits every user.
Escalate to Strict for shared libraries
Code many teams import deserves every finding, including the nits.

Why This Works

Language-pack questions name JavaScript's actual failure modes, not generic style points
Best-practices focus judges code against its ecosystem, not abstract ideals
Balanced style keeps the review readable — JS codebases can drown in nits

Best for

Front-end and Node code reviewed by generalists
Codebases mixing old and modern JavaScript idioms
Scripts where a silent promise rejection means lost data

Not for

TypeScript-specific review — switch the language mode; the traps differ (any-leaks, assertions)
Refactoring the legacy patterns found — review first, then the Refactor Prompt Builder

Use cases

Reviewing front-end scripts against modern JavaScript practice
Catching the floating promise that fails silently in production
Flagging == comparisons before type juggling bites

Customize This Resource

Opens this setup in Code Review Prompt Generator. Generate to get the full review contract — then adjust the focus, scope, language, and style.

Open in Code Review Prompt Generator

Prompt Template

REVIEW OBJECTIVE
Review the checkout page scripts against modern JavaScript practice.
Primary focus: idiomatic practice — judge this code against how its ecosystem expects it to be written.
Review only — report findings; do not rewrite the code.

REVIEW SCOPE
You are reviewing a complete file — judge both the code and the file's structure: imports, ordering, and what this file owns.
Language: JavaScript.

REVIEW CRITERIA
- Language idioms and framework conventions
- Deprecated or discouraged APIs
- Resource disposal the idiomatic way
- Standard library over reinvention
- Public API documentation

SEVERITY RULES
- Tag every finding with exactly one severity: [CRITICAL], [MAJOR], [MINOR], or [NIT].
- CRITICAL: must be fixed before merge — bugs, vulnerabilities, data loss.
- MAJOR: should be fixed — real risk or real debt.
- MINOR: worth fixing — small risk or friction.
- NIT: style preference; fixing is optional.
- Severity reflects impact, not effort to fix.

REVIEW CHECKLIST
Work through every item; report only the items that fail:
1. Does the code follow the language's idioms, or fight them?
2. Are framework conventions respected (lifecycle, naming, structure)?
3. Any deprecated or discouraged APIs in use?
4. Is error handling done the way this ecosystem expects?
5. Are logging levels appropriate (errors aren't info, info isn't debug)?
6. Is resource disposal idiomatic (using/defer/with/try-with-resources)?
7. Is immutability used where the ecosystem expects it?
8. Does the code reinvent things the standard library already provides?
9. Are lint or analyzer suppressions justified with a reason?
10. Do public APIs carry doc comments?
JavaScript-specific:
11. Any == comparisons that should be ===?
12. Are promise rejections handled — no floating promises?
13. Is "this" binding correct in callbacks and class methods?
14. Any mutation of shared objects or function arguments?

REQUIRED OUTPUT FORMAT
- One finding per bullet: [SEVERITY] location — what is wrong and why it matters.
- Group findings by severity, CRITICAL first.
- Cite the exact line, function, or symbol for every finding.
- Do not mention checklist items that pass — findings only.
- Prioritize findings that matter; skip pure style nits unless they hurt readability.
- If something is done notably well, say so once — briefly.

FINAL VERDICT
- End with a verdict: APPROVED, APPROVED WITH COMMENTS, or CHANGES REQUIRED.
- Base the verdict only on the findings listed above.

CODE TO REVIEW
[Paste the file here]

Related Resources

Explore more resources that work well with this one.