Claude can review its own work two ways: for engineering correctness, and for how a user actually experiences it. The review engine is built into Claude Code — you don't build it. What's yours is what you point it at. Here are the two checklists I use.
/code-review command and its subagents — it reads your diff, spins up parallel agents to find issues, then validates each one so you only get high-signal findings. You don't write that part. Your contribution is the lens: a prompt that tells the review what your world cares about. Below are two of mine.
Point the review at Salesforce best practice — bulkification, limits, security, coverage. For when "does it work" needs to mean "will it survive production".
Review the Apex you just wrote for my org against Salesforce best practices, and tell me in plain English where it stands. I'm an admin — I can follow the gist, but I'm relying on you to hold it to the standard. Check it against: 1. Bulkification — no SOQL or DML inside loops; safe at hundreds or thousands of records 2. Governor limits — flag anything that risks hitting them 3. Security — sharing model, field-level security, CRUD/FLS enforcement, no unexpected system-mode access 4. Null and edge-case handling 5. Test coverage — is there a test class, does it cover the real paths, does it bulk-test 200 records 6. Naming, structure, and whether it follows the patterns Salesforce documents For each one, tell me: pass, or here's the risk and here's the fix. Then give me a short list of exactly what I should test in a sandbox before this goes anywhere near production.
Same engine, different standard. This reads your LWC the way a user would — keyboard, screen reader, contrast, clear states. An admin's edge: you know how the thing is actually used.
Review this Lightning Web Component for accessibility and UX, the way a user would experience it — not the engineering, the front end. I'm an admin and I want this to be usable by everyone. Check it against: 1. Semantic HTML — correct elements for the job, not divs standing in for buttons and headings 2. Keyboard access — can every interactive element be reached and operated without a mouse 3. Screen-reader support — labels, ARIA roles and states where needed, sensible reading order 4. Colour contrast — text and interactive elements meet WCAG AA against their background 5. Focus handling — visible focus, and focus moved sensibly after actions like opening a dialog 6. Clear states — loading, empty, and error states are obvious and worded plainly For each one: pass, or here's the issue and the fix in the markup. Flag the highest-impact accessibility problems first.
If you want to understand what's happening under the hood — the command, the subagents, and the review paths available — these are the official docs.
Claude Code · Subagents → Anthropic · code-review plugin →