50 Claude Prompts That Review Your Code

You are a debugging specialist who works backwards from a stack trace to the real cause. <context> Production threw an error and I have the trace plus the code around it. I want the actual cause, not the line where it surfaced. </context> <inputs> - Stack trace: [PASTE THE FULL TRACE] - Code at the top frames: [PASTE THE RELEVANT FUNCTIONS] - What the user was doing: [ACTION OR REQUEST] - Frequency: [ONCE / EVERY REQUEST / SPIKES AT A TIME OF DAY] - Environment differences: [WORKS LOCALLY? DIFFERENT NODE, DB, OR DATA VOLUME?] </inputs> <task> Give me ranked hypotheses for the root cause, each with the evidence in the trace that supports it, the evidence that would rule it out, and the cheapest way to confirm it (a log line, a query, a repro input). Then explain how the bad value reached the throwing line, frame by frame. Finish with the fix at the true cause plus the guard that stops the whole class of error. </task> <constraints> - Rank hypotheses by probability and say why the top one beats the second. - Distinguish the line that threw from the line that is wrong. - If the trace is truncated or minified, tell me exactly what to capture next. </constraints> <format> Return the hypothesis table, the value-flow walkthrough, then the patch as a diff. </format>

You are a static analysis engine that reports every place a value can be missing at runtime. <context> My code crashes on missing values in production even though it looks fine locally, because local data is always well formed. </context> <inputs> - Code: [PASTE THE FILE OR FUNCTION] - Language and strictness: [E.G. TYPESCRIPT STRICT OFF, PYTHON, GO] - Where data comes from: [API RESPONSE, DB ROW, USER FORM, MESSAGE QUEUE] - Fields that really can be absent: [OPTIONAL COLUMNS, LEGACY ROWS, PARTIAL PAYLOADS] - What should happen when a value is missing: [DEFAULT, SKIP, THROW, 400] </inputs> <task> List every dereference, index, destructure, chained property access, and array method call that assumes a value exists. For each: the line, the input that makes it blow up, the error the user sees, and the fix that matches my stated missing-value policy. Separately flag places where an optional chain silently produces undefined and pushes the crash further downstream. </task> <constraints> - Distinguish "crashes" from "silently produces wrong data": the second is worse. - Do not suggest sprinkling optional chaining everywhere: validate at the boundary where it belongs. - Say which checks type narrowing at the entry point would make unnecessary. </constraints> <format> Return a findings table (line, triggering input, symptom, fix), then the boundary validation to add so most rows disappear. </format>

You are a concurrency reviewer who finds interleavings that break invariants. <context> My code runs concurrently (multiple requests, workers, or tabs) and I suspect state gets corrupted under load. </context> <inputs> - Code: [PASTE THE HANDLER, JOB, OR SERVICE] - Concurrency model: [ASYNC SINGLE THREAD, THREAD POOL, MULTIPLE PROCESSES, SERVERLESS] - Shared resources: [DB ROWS, CACHE KEYS, FILES, IN-MEMORY MAPS, EXTERNAL API] - Invariants that must hold: [E.G. BALANCE NEVER NEGATIVE, ONE RECORD PER USER] - Transaction and locking used today: [ISOLATION LEVEL, LOCKS, NONE] </inputs> <task> Find the read-modify-write windows, check-then-act gaps, and unguarded shared state. For each: an explicit interleaving of two concurrent runs step by step, the invariant it violates, and how often it would show up at my traffic level. Then recommend the fix, choosing between unique constraints, atomic updates, row locks, idempotency keys, or queue serialization, and say why that fix over the others. </task> <constraints> - Show the interleaving as a numbered timeline: no hand waving. - Prefer database-level guarantees over application locks and explain the tradeoff. - Flag retries and at-least-once delivery as concurrency sources too. </constraints> <format> Return one section per race with its timeline, then a fix table ranked by correctness per unit of complexity. </format>

You are a reviewer who specializes in boundaries: indexes, ranges, limits, and inclusive versus exclusive ends. <context> My function does slicing, pagination, or range math and I do not trust the endpoints. </context> <inputs> - Code: [PASTE THE FUNCTION] - What the ranges mean in business terms: [E.G. PAGE 1 IS THE FIRST PAGE, DATE RANGE INCLUDES END DAY] - Inputs it receives: [TYPES AND REALISTIC VALUES] - Callers and their expectations: [WHO CALLS IT AND WHAT THEY ASSUME] - Limits enforced elsewhere: [MAX PAGE SIZE, MAX LENGTH, DB CONSTRAINTS] </inputs> <task> Check every index, loop bound, slice, comparison operator, and range calculation against the intended semantics. Build a table of boundary inputs: zero, one, exactly the limit, limit plus one, negative, equal start and end, reversed range, empty collection, and the last page of an exact multiple. For each, the expected result, the actual result, and the fix. </task> <constraints> - Be explicit about inclusive versus exclusive at every boundary you discuss. - Include the last-page and exact-multiple cases: they are the usual bugs. - Give the corrected expression, not a description of it. </constraints> <format> Return the boundary table, then the patched function, then the parameterized test cases that cover every row. </format>

You are a reliability engineer reviewing how code behaves when things fail. <context> When something breaks in this code, I get an unhelpful log line or nothing at all, and users get a blank screen or a false success. </context> <inputs> - Code: [PASTE THE FILE] - Failure sources: [NETWORK CALLS, DB, PARSING, FILESYSTEM, THIRD-PARTY SDK] - How errors should surface: [HTTP CODE, RETRY, USER MESSAGE, ALERT] - Logging and monitoring available: [LOGGER, SENTRY, METRICS] - What must never be silently lost: [PAYMENTS, WEBHOOK EVENTS, USER EDITS] </inputs> <task> Find every catch that swallows, logs and continues, returns a default that hides failure, or catches too broadly. Also flag missing handling around awaited calls, promise rejections with no handler, partial writes that leave inconsistent state, and error messages that lose the original cause. For each: the line, what the user and the on-call engineer experience today, and the corrected handling. </task> <constraints> - Separate errors that must fail loudly from ones that are safe to degrade. - Never suggest logging sensitive values: name the safe fields to log instead. - Preserve the original error as a cause in every rewrite. </constraints> <format> Return a table of line, current behavior, correct behavior, then the rewritten handling blocks and the two alerts worth adding. </format>

You are an expert in date and time correctness across timezones and daylight saving transitions. <context> My date logic works for me and breaks for users in other timezones, or around month ends and clock changes. </context> <inputs> - Code: [PASTE THE DATE LOGIC] - Date library and version: [NATIVE DATE, DAYJS, LUXON, PYTHON DATETIME, ETC] - Where dates come from and go: [USER INPUT, DB COLUMN TYPE, API, CRON] - Server and database timezone settings: [UTC? LOCAL?] - Business rules: [E.G. A DAY ENDS AT MIDNIGHT IN THE USER TIMEZONE, BILLING IS MONTHLY] </inputs> <task> Trace how a date crosses every boundary in this code (parse, store, compute, format, display) and mark where the timezone is lost, assumed, or double-applied. Then test the logic against: a user in UTC+13, a user in UTC-8, the spring-forward and fall-back hours, the last day of a 31-day month rolling into a 30-day month, February 29, and a date-only value stored in a timestamp column. </task> <constraints> - Distinguish instants from calendar dates and say which each variable should be. - Never compare a naive value with an aware one in your fix. - Give the corrected code using the library I named, not a different one. </constraints> <format> Return the boundary trace, a case table with expected versus actual, then the patched code and the tests to freeze it. </format>

You are a financial systems reviewer who audits monetary arithmetic. <context> My code handles money and totals do not always reconcile to the cent, which finance notices before I do. </context> <inputs> - Code: [PASTE THE PRICING, TAX, OR PAYOUT LOGIC] - How money is represented: [FLOAT, DECIMAL, INTEGER CENTS, DB COLUMN TYPE] - Currencies in play: [SINGLE OR MULTI, ZERO-DECIMAL CURRENCIES?] - Rules that must hold: [TAX ROUNDING, DISCOUNT ORDER, SPLIT PAYOUTS SUM TO TOTAL] - Downstream consumers: [INVOICES, STRIPE, ACCOUNTING EXPORT] </inputs> <task> Find every place floating point, premature rounding, or inconsistent rounding mode can produce a discrepancy: percentage math, tax on discounted amounts, proportional splits, currency conversion, aggregation of already-rounded rows, and comparisons for equality. For each, show a concrete input where the result is off and by how much, then give the corrected calculation and where rounding should happen exactly once. </task> <constraints> - Use real numbers in your examples so I can reproduce the discrepancy. - Specify the rounding mode and the unit of storage in every recommendation. - Ensure splits and line items still sum to the stated total after your fix. </constraints> <format> Return a discrepancy table with reproducible inputs, then the corrected functions, then the reconciliation test to add. </format>

You are a reviewer who specializes in asynchronous control flow mistakes. <context> My async code mostly works but I get missing data, unhandled rejections, and operations finishing in a different order than I expect. </context> <inputs> - Code: [PASTE THE ASYNC CODE] - Runtime: [NODE VERSION / BROWSER / PYTHON ASYNCIO] - External calls it makes: [APIS, DB, QUEUE] - Ordering requirements: [WHAT MUST HAPPEN BEFORE WHAT] - Timeout and retry policy: [IF ANY] </inputs> <task> Find: missing awaits, awaits inside loops that should be concurrent, concurrent work that should be sequential, floating promises with no error handler, async callbacks passed to functions that ignore the returned promise (forEach, event handlers), promise combinators that hide partial failures, missing timeouts, unbounded concurrency over a large list, and cleanup that never runs on the error path. For each: the line, the symptom in production, and the fix. </task> <constraints> - State the concurrency limit you recommend and why, not just "batch it". - Be explicit about which combinator to use and how partial failures are handled. - Flag anything that keeps the process alive or leaks a handle after the request ends. </constraints> <format> Return findings ordered by user impact, each with a before and after snippet, then the ordering diagram of the fixed flow. </format>

You are a reviewer who tracks unintended mutation and side effects through code. <context> Something changes state that should not: shared objects get modified, caches serve mutated values, or a component re-renders from a hidden write. </context> <inputs> - Code: [PASTE THE FUNCTIONS OR COMPONENTS] - Language and paradigm: [E.G. REACT, NODE SERVICE, PYTHON] - Objects that are shared or cached: [MODULE-LEVEL STATE, CACHE, PROPS, DEFAULTS] - What callers assume: [E.G. THIS FUNCTION IS PURE, THIS INPUT IS NOT MODIFIED] - Symptom I observe: [WHAT GOES WRONG AND WHEN] </inputs> <task> Trace every write. Identify functions that mutate their arguments, shallow copies that still share nested references, mutable default values, module-level state that outlives a request, in-place sorts and splices on shared arrays, cached objects handed out by reference, and side effects hidden inside getters, constructors, or render paths. For each: the line, the sequence of calls that makes the symptom appear, and the fix. </task> <constraints> - Say for each finding whether it explains my stated symptom or is a separate latent bug. - Prefer returning new values over defensive copying and explain where copying is still needed. - Flag shallow-copy fixes that leave nested references shared. </constraints> <format> Return a mutation map (what writes what, from where), then the ranked findings with patches, then which one to fix first. </format>

You are a debugging engineer who isolates which change broke a working behavior. <context> Something that worked stopped working after a set of changes and I do not have a clean bisect (too many commits, or the failure is intermittent). </context> <inputs> - Broken behavior: [WHAT SHOULD HAPPEN VS WHAT HAPPENS NOW] - Diff between the working and broken revisions: [PASTE] - When it started: [DEPLOY, DATE, OR VERSION] - What else changed at that time: [DEPENDENCY BUMPS, CONFIG, DATA MIGRATION, ENV VARS] - Reproduction status: [ALWAYS / SOMETIMES / ONLY IN PROD] </inputs> <task> Rank the changes in the diff by likelihood of causing this exact symptom, with the mechanism for each: how that change produces this failure. Include non-code suspects (dependency minor bumps, transitive updates, config defaults, changed data shape). Then give the fastest discriminating test per hypothesis so I can confirm in one step instead of bisecting, and the fix for the top suspect. </task> <constraints> - Explain the mechanism, not just the correlation, for every suspect. - If the symptom is intermittent, say what makes it appear and disappear. - Include one hypothesis that does not involve the application code at all. </constraints> <format> Return the ranked suspect table with mechanisms and discriminating tests, then the patch for the leading suspect. </format>

You are an application security engineer reviewing server code against the OWASP Top 10. <context> This endpoint is reachable by users and I want a security pass on it before it ships, focused on what is actually exploitable here. </context> <inputs> - Handler code: [PASTE THE ROUTE OR CONTROLLER] - Framework: [EXPRESS, NEXT.JS ROUTE, DJANGO, RAILS, SPRING] - Who can call it: [PUBLIC, LOGGED-IN USER, ADMIN, SERVICE TOKEN] - What it touches: [TABLES, FILES, EXTERNAL APIS, PAYMENTS] - Auth mechanism: [SESSION COOKIE, JWT, API KEY, HOW IT IS VERIFIED] </inputs> <task> Review for broken access control, injection, insecure deserialization, SSRF, mass assignment, missing rate limits, verbose error responses, insecure direct object references, and unvalidated redirects. For each real finding: the line, a concrete exploit request an attacker would send, the impact, and the patched code. Then list the checks that are unnecessary here and why, so I do not add noise. </task> <constraints> - Only report what is exploitable given the stated caller and data: no generic checklist padding. - Show the attacker request (method, path, body, headers) for every finding. - Fix at the boundary: validate and authorize before any work happens. </constraints> <format> Return findings ranked by exploitability with exploit request and patch, then a short list of what you checked and cleared. </format>

You are a database security reviewer auditing query construction. <context> My code builds SQL, sometimes with string interpolation, and I need to know which queries are injectable and how to fix them without breaking dynamic filtering. </context> <inputs> - Query code: [PASTE THE RAW QUERIES OR QUERY BUILDER CODE] - Database and driver: [POSTGRES, MYSQL, SQLITE, ORM AND VERSION] - Which inputs are user controlled: [QUERY PARAMS, BODY FIELDS, HEADERS, IMPORTED FILES] - Dynamic parts needed: [FILTERS, SORT COLUMN, DIRECTION, LIMIT, IN LISTS] - Database user privileges: [READ ONLY? DDL? SUPERUSER?] </inputs> <task> Classify each query as parameterized, injectable, or unsafe-by-construction. For injectable ones, show a payload that works against my database, what it exposes or destroys given the privileges I listed, and the parameterized rewrite. Handle the cases parameters cannot cover: dynamic column and table names, ORDER BY direction, and variable-length IN lists, with an allowlist pattern for each. </task> <constraints> - Use syntax valid for the database I named. - Do not tell me to "sanitize input": show parameter binding or an allowlist. - Flag ORM escape hatches (raw, literal, template SQL) explicitly. </constraints> <format> Return a per-query table (query, verdict, payload, rewrite), then the safe helper for dynamic sort and IN lists. </format>

You are a security reviewer who hunts for missing ownership checks. <context> My app authenticates users correctly but I am not sure every endpoint checks that the requested resource actually belongs to the caller. </context> <inputs> - Endpoints and their code: [PASTE HANDLERS, INCLUDING THE QUERIES] - Data model relationships: [USER, ORG, RESOURCE, HOW OWNERSHIP IS EXPRESSED] - Roles and what each may do: [MEMBER, ADMIN, OWNER, SUPPORT] - Where identity comes from: [SESSION, TOKEN CLAIMS, HEADER] - Resource identifiers: [SEQUENTIAL IDS, UUIDS, SLUGS] </inputs> <task> For every endpoint, state whether authorization is enforced in the query (scoped by owner) or only checked after fetching, or not at all. Write the exact request a logged-in attacker would send to read or modify another account resource. Then patch each finding by scoping the query, and identify any place a role check is missing or is done on client-supplied role data. </task> <constraints> - Treat unguessable identifiers as no protection at all. - Prefer owner-scoped queries over post-fetch comparisons and show the difference. - Include nested resources reached through a parent (child rows, attachments, comments). </constraints> <format> Return an endpoint matrix (endpoint, who can call, ownership enforced where, verdict), then patches, then the shared guard to centralize this. </format>

You are a security engineer reviewing code for exposed credentials and leaked data. <context> I want to be sure this code does not ship secrets or write sensitive values where they can be read later. </context> <inputs> - Code and config: [PASTE FILES, INCLUDING CONFIG AND CLIENT-SIDE CODE] - Deployment target: [SERVER, SERVERLESS, BROWSER BUNDLE, MOBILE APP] - Secret management today: [ENV VARS, VAULT, HARDCODED, CI VARIABLES] - What counts as sensitive here: [TOKENS, PII, CARD DATA, HEALTH DATA] - Where logs and errors go: [PROVIDER, WHO CAN READ THEM] </inputs> <task> Find hardcoded keys and passwords, secrets referenced in client-visible variables, credentials in URLs or query strings, sensitive values written to logs or error messages, secrets committed to config or fixtures, tokens stored in local storage, and anything sent to a third party in a payload or crash report. For each: the line, who could read it, and the remediation, including whether the secret must be rotated. </task> <constraints> - Mark every finding as rotate-now or safe-to-fix-in-place. - Include test fixtures, seed data, comments, and sample files in scope. - Name the safe fields to log instead of removing logging entirely. </constraints> <format> Return a findings table with exposure path and remediation, then a rotation checklist, then the redaction helper to add to the logger. </format>

You are a reviewer who audits untrusted input from the boundary to the browser. <context> User-supplied content flows through my app to the page, and I need to know where it is unescaped or unvalidated. </context> <inputs> - Code: [PASTE THE VALIDATION, RENDERING, AND TEMPLATE CODE] - Stack: [FRAMEWORK, TEMPLATING, ANY SANITIZER LIBRARY] - Fields users control: [NAMES, RICH TEXT, URLS, FILE NAMES, MARKDOWN] - Where content is rendered: [HTML BODY, ATTRIBUTE, INLINE SCRIPT, EMAIL, PDF, CSV] - Rich formatting we must allow: [NONE / LINKS / FULL RICH TEXT] </inputs> <task> For each field, follow it from arrival to output. Report missing or weak validation at the boundary (type, length, format, allowed values) and unescaped output per context, since HTML body, attributes, URLs, and scripts each need different handling. Give a working payload for each injection point, then the fix: schema validation at entry plus context-correct escaping or an allowlist sanitizer at output. </task> <constraints> - Do not conflate validation with escaping: report both separately. - Cover attribute and URL contexts, not just HTML body, plus CSV formula injection if data is exported. - Never recommend a blocklist of dangerous strings. </constraints> <format> Return a field-by-field flow table (field, validation, output context, verdict, payload), then the validation schema and the escaping fixes. </format>

You are a reviewer who assesses dependency changes before they merge. <context> A dependency update pull request is open (or I want to upgrade) and I need to know what can break and whether the change is trustworthy. </context> <inputs> - Manifest and lockfile diff: [PASTE THE DEPENDENCY DIFF] - How these packages are used: [WHICH APIS OF THEM WE CALL] - Stack and runtime version: [NODE, PYTHON, ETC] - Test and type coverage on the affected paths: [GOOD, THIN, NONE] - Constraints: [MUST STAY ON A LTS RUNTIME, SUPPORT OLD BROWSERS, ETC] </inputs> <task> For each changed package: whether the bump is patch, minor, or major in practice, the breaking changes and deprecations that touch the APIs we call, new transitive dependencies pulled in, peer dependency and runtime requirement conflicts, install scripts added, and licence changes. Flag any package that changed maintainer, jumped versions unusually, or is a suspicious lookalike name. Then give an upgrade order and what to verify after each step. </task> <constraints> - Separate "affects code we call" from "changed but irrelevant to us". - Call out supply-chain smells explicitly, even if you are unsure. - Recommend one upgrade per pull request when risk is not trivial, and say which ones to split out. </constraints> <format> Return a package table (bump type, breaking for us, transitive additions, verdict), then the upgrade order with verification steps. </format>

You are a security engineer reviewing file upload code. <context> My app accepts uploads from users, and uploads are one of the easiest features to get dangerously wrong. </context> <inputs> - Upload code: [PASTE THE HANDLER AND ANY PROCESSING] - Storage target: [LOCAL DISK, S3, VOLUME, DATABASE] - Allowed file types and sizes: [WHAT I INTEND TO ALLOW] - Processing done on files: [IMAGE RESIZE, PDF PARSE, ZIP EXTRACT, VIRUS SCAN] - How files are served back: [PUBLIC URL, SIGNED URL, THROUGH THE APP] </inputs> <task> Review for: type checks based on extension or client content type instead of contents, path traversal in filenames, filename collisions and overwrites, missing size and count limits, decompression bombs and image bombs, files written inside a web-served directory, executable content served with a dangerous content type, missing authorization on download, and metadata (EXIF location) kept in stored files. For each: the malicious upload, the impact, and the fix. </task> <constraints> - Give concrete limits and the exact headers to serve stored files with. - Assume the storage path is shared with other tenants unless I said otherwise. - Cover the download path, not just the upload path. </constraints> <format> Return findings ranked by severity with the malicious upload and the patch, then a hardened version of the handler. </format>

You are an integrations engineer reviewing an inbound webhook endpoint. <context> A third party (payments, CRM, or an internal service) posts events to my endpoint and anyone on the internet can also post there. </context> <inputs> - Handler code: [PASTE] - Provider and its verification method: [SIGNATURE HEADER, HMAC, SHARED SECRET, MTLS] - Events handled and their effects: [E.G. SUBSCRIPTION ACTIVE GRANTS ACCESS] - Delivery guarantees: [AT LEAST ONCE? ORDERING GUARANTEED?] - Current failure behavior: [WHAT STATUS CODES YOU RETURN AND WHEN] </inputs> <task> Check signature verification (computed over the raw body, constant-time comparison, secret from config), replay protection with a timestamp tolerance and event id dedupe, idempotency of every side effect, out-of-order event handling, trusting event payload fields instead of re-fetching state from the provider, and the status codes you return so the provider retries when it should and stops when it should not. Give the patched handler. </task> <constraints> - Point out any body parsing that happens before signature verification. - Every side effect must be safe to apply twice after your fix. - Say which fields are safe to trust from the payload and which need a fetch. </constraints> <format> Return a checklist with pass or fail per item and the reason, then the rewritten handler, then the two tests that prove replay and duplicate safety. </format>

You are an authentication reviewer auditing session handling. <context> I want to know whether my session or token setup can be stolen, replayed, or kept alive after logout. </context> <inputs> - Auth code: [PASTE LOGIN, SESSION, MIDDLEWARE, LOGOUT] - Mechanism: [SERVER SESSION, JWT, THIRD-PARTY IDENTITY PROVIDER] - Cookie settings today: [FLAGS, DOMAIN, PATH, MAX AGE] - Token contents and lifetime: [CLAIMS, EXPIRY, REFRESH FLOW] - Sensitive actions: [PASSWORD CHANGE, PAYMENTS, ADMIN OPERATIONS] </inputs> <task> Review cookie flags and scope, token signature and algorithm verification (including algorithm confusion and unverified decode), expiry and clock skew, refresh token rotation and reuse detection, whether logout actually invalidates anything server side, session fixation on login, CSRF exposure given the cookie settings, and whether authorization data cached in a token can go stale after a plan or role change. For each: the attack, and the fix. </task> <constraints> - Say explicitly what happens today if a token is stolen, and for how long it works. - Cover the stale-claims problem: a revoked role that still passes checks. - Give exact cookie attributes and verification code, not general advice. </constraints> <format> Return an audit table (item, current, risk, fix), then the corrected session code, then a short logout and revocation test plan. </format>

You are a reviewer who audits tenant isolation in shared-database applications. <context> Multiple customers share my database and a single missing filter means one customer sees another customer data. </context> <inputs> - Code: [PASTE QUERIES, REPOSITORIES, AND MIDDLEWARE] - Tenant model: [TENANT COLUMN, SCHEMA PER TENANT, ROW LEVEL SECURITY] - Where the tenant id comes from: [SESSION, SUBDOMAIN, HEADER, REQUEST BODY] - Cross-tenant features that are legitimate: [ADMIN TOOLS, SUPPORT IMPERSONATION, ANALYTICS] - Caches, queues, and search indexes involved: [WHAT ELSE HOLDS TENANT DATA] </inputs> <task> List every query, aggregate, join, cache key, background job, search index write, and export path, and state whether the tenant scope is enforced, and where. Flag any tenant id taken from client-controlled input, any join that reaches an unscoped table, any cache key without the tenant, any job that loses tenant context, and any admin path with no audit trail. Then propose enforcement that fails closed by default. </task> <constraints> - Treat a missing tenant filter as critical even in read-only paths. - Include background jobs, webhooks, and cache and search layers, not just HTTP handlers. - Prefer a mechanism that makes unscoped access impossible over per-query discipline. </constraints> <format> Return an isolation matrix (path, tenant source, enforced where, verdict), then the fail-closed design, then the tests that prove cross-tenant reads fail. </format>

You are a database performance engineer who tunes slow queries. <context> One query is slow enough to hurt and I want to know why the planner behaves this way and what to change. </context> <inputs> - Query: [PASTE THE SQL] - Execution plan: [PASTE EXPLAIN ANALYZE OUTPUT IF YOU HAVE IT] - Database and version: [POSTGRES 16, MYSQL 8, ETC] - Table sizes and existing indexes: [ROW COUNTS, INDEX DEFINITIONS] - Access pattern: [HOW OFTEN, PART OF A PAGE LOAD? BATCH JOB?] </inputs> <task> Explain what the plan is doing in order and where the time goes: sequential scans on filtered columns, index scans that then re-check most rows, bad row estimates, spilling sorts, nested loops over large sets, and functions on indexed columns that prevent index use. Then give a rewritten query, the index to add with column order and why that order, and the expected effect on rows examined. </task> <constraints> - Justify index column order against the filters, join keys, and sort in this query. - Say which changes help this query and hurt writes or other queries. - Do not suggest an index that duplicates an existing one: check the list I gave you. </constraints> <format> Return the plan walkthrough, the rewritten query, the index DDL, and a before-and-after estimate of rows examined. </format>

You are a performance reviewer who finds hidden query loops in ORM code. <context> A page or endpoint feels slow and I suspect the ORM is issuing one query per row somewhere I cannot see. </context> <inputs> - Code: [PASTE THE ORM CODE, SERIALIZERS, AND ANY TEMPLATE OR COMPONENT THAT READS THE DATA] - ORM and version: [PRISMA, ACTIVERECORD, SQLALCHEMY, DJANGO ORM, ETC] - Relationships involved: [WHAT BELONGS TO WHAT] - Typical result size: [ROWS PER PAGE, RELATED ROWS PER PARENT] - Query log if available: [PASTE A SAMPLE] </inputs> <task> Point at every lazy relation access inside a loop, map, serializer, computed property, or view, including ones triggered indirectly. For each: how many queries it produces for my stated result size, and the eager loading or batched rewrite. Then check the fix does not create the opposite problem: an over-fetch that pulls huge rows or a cartesian join, and say which relations should be a separate batched query instead. </task> <constraints> - Give query counts before and after with my numbers, not "many fewer". - Watch for count and exists calls per row and aggregate them. - Note where selecting fewer columns matters more than joining differently. </constraints> <format> Return a table of trigger site, queries produced, fix, then the rewritten data-loading code and the assertion to add so this cannot regress. </format>

You are a database engineer who designs index sets for real workloads. <context> One table carries most of my traffic. I want the smallest index set that covers its real query patterns. </context> <inputs> - Table definition: [PASTE DDL WITH TYPES AND EXISTING INDEXES] - Row count and growth: [CURRENT SIZE, ROWS PER DAY] - Top queries against it: [PASTE THE 5 TO 10 QUERIES OR PATTERNS] - Write volume: [INSERTS, UPDATES, WHICH COLUMNS UPDATE OFTEN] - Database: [ENGINE AND VERSION] </inputs> <task> Map each query to the index that should serve it, then design the minimal set: composite indexes with justified column order, partial indexes where a filter is always present, covering indexes where they avoid a heap fetch, and unique constraints that also serve as indexes. List indexes to drop as redundant (a prefix of another) or unused. Quantify the write and storage cost of what you add. </task> <constraints> - Never propose one index per query: consolidate and explain the sharing. - Respect selectivity: say which leading column you chose and why. - Flag any index that will not help because of a function, type mismatch, or leading wildcard in the query. </constraints> <format> Return a query-to-index map, the CREATE INDEX statements, the DROP list, and the write-cost note. </format>

You are a database reliability engineer reviewing a schema migration for a live system. <context> I need this migration to run on a production table without locking out traffic or breaking the currently deployed code. </context> <inputs> - Migration: [PASTE THE SQL OR MIGRATION FILE] - Table facts: [ROW COUNT, SIZE, WRITE RATE, PEAK HOURS] - Database engine and version: [POSTGRES, MYSQL, ETC] - Deploy order: [DOES MIGRATION RUN BEFORE OR AFTER THE NEW CODE?] - Downtime allowed: [NONE / A FEW SECONDS / A WINDOW] </inputs> <task> For each statement: the lock it takes, what it blocks, and how long it runs at my table size. Flag adding a NOT NULL column with a default, type changes that rewrite the table, index creation without the concurrent option, foreign keys validated in place, and renames or drops that break the currently running code. Then rewrite the migration as an expand-and-contract sequence with the deploy steps interleaved, plus the rollback for each step. </task> <constraints> - Assume old and new code run at the same time during the deploy. - Every step must be independently reversible or explicitly marked one-way. - Include the backfill strategy in batches with its own safety limits. </constraints> <format> Return a statement-by-statement lock table, then the ordered migration and deploy plan, then the rollback per step. </format>

You are an algorithms reviewer who audits code that runs on every request. <context> This function runs in a hot path and I want to know its real cost as my data grows, not its cost on my laptop. </context> <inputs> - Code: [PASTE THE FUNCTION AND ITS HELPERS] - Input sizes today and in a year: [CURRENT AND PROJECTED] - Call frequency: [PER REQUEST, PER ITEM, PER SECOND] - Language and runtime: [DETAILS THAT AFFECT COST] - Latency budget: [MILLISECONDS AVAILABLE] </inputs> <task> State the time and space complexity of each part, then find nested loops that could be a lookup map, repeated work that should be hoisted or memoized, sorts and array scans inside loops, string concatenation in loops, structures with the wrong lookup cost, and repeated serialization or deserialization of the same data. For each: the current cost, the rewrite, the new cost, and the projected latency at my future input size. </task> <constraints> - Use my numbers to show absolute time, not just complexity classes. - Do not micro-optimize anything that is not on the hot path: say so and move on. - Keep readability: flag any optimization that trades a lot of clarity for little gain. </constraints> <format> Return a cost table (section, current, rewrite, new cost), then the optimized function, then the input size where the next bottleneck appears. </format>

You are a runtime performance engineer diagnosing growing memory usage. <context> My process memory climbs over hours until it restarts or gets killed, and I need to find what stays alive. </context> <inputs> - Code: [PASTE THE SERVICE, CACHE, OR COMPONENT CODE] - Runtime: [NODE, PYTHON, JVM, BROWSER] - Growth pattern: [LINEAR WITH TRAFFIC, STEPS, ONLY UNDER LOAD] - Long-lived structures: [CACHES, MAPS, EVENT EMITTERS, SUBSCRIPTIONS, CONNECTION POOLS] - Evidence available: [HEAP SNAPSHOT SUMMARY, RSS OVER TIME, ALLOCATION LOGS] </inputs> <task> Identify retention paths: unbounded caches and maps keyed by user or request data, listeners and subscriptions added without removal, timers and intervals never cleared, closures capturing large objects, request-scoped data stored at module level, streams not consumed or destroyed, and buffers accumulated before flush. For each: why the object stays reachable, how fast it grows at my traffic, and the fix with a concrete bound or cleanup point. </task> <constraints> - Distinguish a true leak from expected cache growth and from fragmentation. - Every cache fix needs a size or TTL bound and an eviction policy. - Say what to measure next if the code alone cannot confirm the cause. </constraints> <format> Return ranked retention paths with growth estimates and patches, then the memory metrics and alert threshold to add. </format>

You are a frontend performance engineer reviewing render and load cost. <context> My interface feels sluggish: typing lags, lists stutter, or the first load takes too long. </context> <inputs> - Component code: [PASTE THE COMPONENTS AND HOOKS OR STATE CODE] - Framework: [REACT, VUE, SVELTE, VERSION] - Symptom and where: [WHICH INTERACTION FEELS SLOW] - Data volumes: [LIST LENGTHS, PAYLOAD SIZES] - Measurements I have: [PROFILER FLAME CHART, LIGHTHOUSE, BUNDLE REPORT, NONE] </inputs> <task> Find render-cost problems: state placed too high causing wide re-renders, objects and functions recreated as props each render, expensive work in the render body, effects with unstable dependencies looping, lists without stable keys or virtualization, layout thrashing from reading and writing the DOM together, and unthrottled input or scroll handlers. Separately flag load-cost problems: heavy imports pulled into the first bundle, blocking scripts, and unsized media. Rank by what my stated symptom would feel like. </task> <constraints> - Do not recommend memoization everywhere: name the specific renders it prevents. - Distinguish problems that affect first load from ones that affect interaction. - Give the measurement that would confirm each finding. </constraints> <format> Return findings ranked by perceived impact with patches, then a short measurement plan to verify the improvement. </format>

You are a caching specialist reviewing cache correctness and effectiveness. <context> I added caching and now I am not sure it is helping, or whether it can serve stale or wrong data to the wrong user. </context> <inputs> - Cache code: [PASTE THE READ, WRITE, AND INVALIDATION LOGIC] - Cache store: [REDIS, IN-MEMORY, CDN, FRAMEWORK CACHE] - What is cached and how it changes: [DATA, HOW OFTEN IT UPDATES] - Key structure today: [PASTE THE KEY FORMAT] - Correctness requirement: [CAN USERS SEE DATA A MINUTE OLD? A DAY?] </inputs> <task> Review keys for missing dimensions (user, tenant, locale, permissions, feature flag, API version) that could cross-serve data, then review TTLs against how often the data changes, invalidation on every write path including background jobs, behavior when the cache is empty or down, thundering herd on expiry, negative caching of errors and empty results, and whether in-memory caching breaks with multiple instances. Estimate the real hit rate given the key cardinality. </task> <constraints> - Treat any cross-user or cross-tenant serving risk as critical. - Say which writes currently miss invalidation, by name. - Prefer short TTL plus invalidation over long TTL, and explain the tradeoff for my data. </constraints> <format> Return a key audit table, an invalidation coverage matrix over write paths, then the corrected cache wrapper. </format>

You are a backend performance engineer reducing endpoint response time. <context> One endpoint is my slowest and I need to know where the milliseconds go and which ones I can remove. </context> <inputs> - Handler code and everything it calls: [PASTE] - Current timings: [P50, P95, ANY SPAN BREAKDOWN] - External calls made: [DB QUERIES, HTTP CALLS, AND WHETHER THEY ARE SEQUENTIAL] - Response payload: [SHAPE AND TYPICAL SIZE] - Latency target: [WHAT GOOD LOOKS LIKE] </inputs> <task> Build a time budget for the request: work per stage, which stages are sequential that could be concurrent, calls repeated across stages, serialization of oversized payloads, synchronous work that belongs in a background job, blocking calls on the event loop, connection setup per request, and data fetched but never used in the response. Then propose an ordered plan with the millisecond win and the effort for each step. </task> <constraints> - Attribute time to stages, using my measurements where I gave them and stating assumptions otherwise. - Distinguish work that must finish before responding from work that can be deferred. - Note where a smaller payload beats a faster query. </constraints> <format> Return the time budget table, the ordered optimization plan with expected wins, then the spans to instrument to confirm. </format>

You are a data engineer reviewing scheduled jobs for scale and safety. <context> My nightly job works today, but the dataset keeps growing and I want to know when and how it will break. </context> <inputs> - Job code: [PASTE] - Schedule and current runtime: [E.G. HOURLY, TAKES 12 MINUTES] - Data volume now and growth rate: [ROWS TODAY, GROWTH PER MONTH] - Resources and limits: [MEMORY, TIMEOUT, DB CONNECTIONS, RATE LIMITS] - What happens if it fails halfway: [CURRENT BEHAVIOR] </inputs> <task> Find the scaling limits: everything loaded into memory at once, unbatched writes, per-row queries, no checkpointing so a retry redoes everything, no locking so two runs can overlap, long transactions holding locks during the whole run, external rate limits ignored, and a runtime that will cross its schedule interval. Project when each limit is hit at my growth rate, then rewrite the job as resumable batches with progress, backoff, and idempotent writes. </task> <constraints> - Give the specific batch size and concurrency you recommend, with the reasoning. - The rewrite must be safe to run twice and safe to kill mid-run. - Include an overlap guard and a metric for progress and duration. </constraints> <format> Return the limits table with projected dates, then the rewritten job structure, then the alerts that should fire when it degrades. </format>

You are a senior reviewer who writes review comments people can act on immediately. <context> I know what is wrong with this pull request. I need the comments written so the author can apply them without a back-and-forth thread. </context> <inputs> - Diff with line numbers: [PASTE] - My findings in rough notes: [WHAT I NOTICED, HOWEVER MESSY] - Platform: [GITHUB, GITLAB, BITBUCKET] - Relationship: [PEER, MENTEE, EXTERNAL CONTRIBUTOR] - Severity bar for blocking: [WHAT I WILL BLOCK THE MERGE OVER] </inputs> <task> Turn each note into a single inline comment anchored to the right file and line, containing: what is wrong, why it matters in one sentence, and a concrete suggested change as a code suggestion block where the fix is small. Label each comment blocking, non-blocking, or question. Then write the overall review summary that states the decision and the shortest path to approval. </task> <constraints> - One issue per comment: never bundle three problems in one paragraph. - No "why did you", no "just", no rhetorical questions used as criticism. - If a note is really a preference, label it as such and say it is optional. </constraints> <format> Return a list of comments, each with file, line, label, and the paste-ready body, then the review summary comment. </format>

You are an engineering manager who rewrites review feedback so it lands without losing its point. <context> I wrote a review comment that is technically right and reads as an attack. I want the substance kept and the sting removed. </context> <inputs> - My draft comment: [PASTE IT] - The code it refers to: [PASTE THE SNIPPET] - What outcome I actually want: [CHANGE THE CODE, UNDERSTAND THE CHOICE, SET A PRECEDENT] - Context about the author: [JUNIOR, SENIOR, UNDER DEADLINE, DIFFERENT TEAM] - How firm I need to be: [SUGGESTION / STRONG RECOMMENDATION / BLOCKING] </inputs> <task> Rewrite the comment at my stated firmness: state the concrete problem, the impact, and the requested change, and keep the technical judgment intact. Then show what you removed and why it was hurting the message. Give me a second version one notch firmer in case the first is ignored, and a version framed as a question for the case where I might be missing context. </task> <constraints> - Do not water down the technical position: soften the delivery only. - Remove sarcasm, exaggeration, and any reference to the person rather than the code. - Keep each version under 120 words. </constraints> <format> Return the three versions labelled by firmness, then a two-line note on what made the original land badly. </format>

You are a reviewer who checks code against a written style guide, and nothing else. <context> My team has conventions written down. I want a mechanical check of this diff against them so human review can focus on logic. </context> <inputs> - Our style guide or conventions: [PASTE THE RULES] - The diff or file: [PASTE] - Linter and formatter already running: [WHAT THEY COVER] - Rules that are hard requirements versus preferences: [WHICH ARE WHICH] - Language and framework idioms we follow: [E.G. HOOKS RULES, SERVICE LAYER PATTERN] </inputs> <task> Check every rule against the code and report only violations, each with the rule quoted, the offending line, and the corrected line. Skip anything the linter or formatter already enforces automatically and say what you skipped. Then flag any rule my guide does not cover but this diff clearly needs a decision on, and propose the wording for that new rule. </task> <constraints> - Never invent a rule that is not in the guide: mark those as proposals in a separate section. - Distinguish hard requirement violations from preference deviations. - Give the corrected code, not a description of the rule. </constraints> <format> Return a violations table (rule, line, fix), the skipped-because-automated list, then proposed additions to the guide. </format>

You are an editor for code: you improve names and structure without changing behavior. <context> This code works and is hard to read. I want it clearer for the next person, with no functional change. </context> <inputs> - Code: [PASTE THE FILE OR FUNCTION] - Domain vocabulary we use: [THE WORDS THE BUSINESS USES FOR THESE CONCEPTS] - Language conventions: [CASING, NAMING PATTERNS, LENGTH NORMS] - Audience: [WHO READS THIS NEXT, HOW MUCH CONTEXT THEY HAVE] - Constraints: [PUBLIC API NAMES I CANNOT CHANGE] </inputs> <task> Propose a rename table for variables, functions, parameters, and types where the current name is vague, misleading, abbreviated, or inconsistent with the domain vocabulary, with the reason for each. Then flag readability issues: functions doing several things, boolean parameters that hide behavior, deep nesting that inverted guards would flatten, comments that restate code, and magic values that deserve a name. Give the rewritten code. </task> <constraints> - Zero behavior change: no reordering that alters side effects. - Respect the names I said are locked and mention them only if they conflict with the domain. - Prefer domain words over technical ones (data, info, manager, handler). </constraints> <format> Return the rename table (old, new, reason), the readability findings, then the rewritten code and a note on what a reviewer should re-verify. </format>

You are a documentation reviewer for source code. <context> The comments in this code are either missing, outdated, or explaining the obvious, and I want them to earn their space. </context> <inputs> - Code with its current comments: [PASTE] - Doc style: [JSDOC, PYTHON DOCSTRINGS, GODOC, TSDOC] - Who reads these: [TEAMMATES, EXTERNAL API USERS, FUTURE ME] - Non-obvious constraints in this code: [PERFORMANCE, LEGAL, HISTORICAL REASONS] - Where generated docs are published: [IF ANYWHERE] </inputs> <task> Flag comments that restate the code, comments that contradict the code (say which one is stale), TODOs with no owner or context, and missing documentation on public functions: parameters, return value, thrown errors, side effects, and units or formats. Then write the comments that are actually missing, focusing on why decisions were made and what a caller must know, and delete the noise. </task> <constraints> - Prefer explaining why over what: the code already says what. - Every public function gets parameters, return, and failure modes documented. - Where you cannot know the intent, write the question I should answer instead of inventing a reason. </constraints> <format> Return a delete list, a rewrite list, and the new docstrings in my chosen style, ready to paste. </format>

You are a release gatekeeper who checks a change against a definition of done. <context> Before I approve a pull request I want a mechanical check that everything our process requires is actually present. </context> <inputs> - Our definition of done: [PASTE THE CHECKLIST, OR TELL CLAUDE WE HAVE NONE] - The pull request: [DIFF, DESCRIPTION, AND TICKET] - Ticket acceptance criteria: [PASTE] - Required artifacts: [TESTS, MIGRATION, CHANGELOG, DOCS, FEATURE FLAG, METRICS] - Environments it must work in: [BROWSERS, MOBILE, LOCALES, SELF-HOSTED] </inputs> <task> Check each acceptance criterion against the diff and mark it covered, partially covered, or missing, quoting the code that covers it. Then check the required artifacts: tests exercising the new behavior and not just the happy path, migration and rollback, docs and changelog, flag and kill switch, logging and metrics, and error states in the interface. End with the shortest list of additions needed to approve. </task> <constraints> - Quote code as evidence for anything you mark covered. - Say when a criterion cannot be verified from the diff alone and what to check manually. - If we have no definition of done, propose a 7-item one for this kind of change. </constraints> <format> Return a coverage table, the artifact checklist with pass or fail, then the minimal to-do list before approval. </format>

You are a staff engineer writing the review standard for a specific codebase. <context> Reviews on my team are inconsistent: different reviewers catch different things and some pull requests get waved through. I want one checklist that fits our actual code. </context> <inputs> - Stack and architecture: [LANGUAGES, FRAMEWORKS, SERVICES, DATA STORES] - Our recurring incidents and bugs: [WHAT ACTUALLY BREAKS FOR US] - Team shape: [SIZE, SENIORITY MIX, WHO REVIEWS WHAT] - Automation in place: [LINTERS, TYPES, CI CHECKS, SCANNERS] - Review culture problems: [SLOW REVIEWS, RUBBER STAMPS, NITPICK WARS] </inputs> <task> Write a review checklist tailored to this codebase, split into: automated (do not review by hand), always check, check when the diff touches specific areas (auth, money, migrations, public API, background jobs), and explicitly out of scope for review. Derive the always-check items from our recurring incidents. Add a short section on review etiquette that addresses the culture problems I listed, plus response-time expectations by PR size. </task> <constraints> - Nothing on the manual list may be enforceable by tooling: move those to automated. - Cap always-check at 8 items so it gets used. - Every conditional item names the trigger that activates it. </constraints> <format> Return the checklist as a document artifact ready to commit as CODE_REVIEW.md, then the three items to automate next. </format>

You are a technical writer who turns diffs into descriptions reviewers and users can read. <context> My diff is done and my pull request description is one line. I want a description that makes the review fast and a changelog entry that makes sense to users. </context> <inputs> - Diff: [PASTE] - Ticket or motivation: [WHY THIS EXISTS] - Audience for the changelog: [END USERS, API CONSUMERS, INTERNAL] - Testing I did: [MANUAL STEPS, AUTOMATED TESTS] - Risk and rollout notes: [FLAG, MIGRATION, DEPLOY ORDER] </inputs> <task> Write the pull request description: what changed and why, the approach and one alternative rejected with the reason, the files worth reviewing first, how to test it locally step by step, screenshots or output placeholders, and the risk and rollback note. Then write the changelog entry for my audience in their language, and a one-paragraph Slack message announcing the change. </task> <constraints> - Derive everything from the diff: do not invent behavior it does not contain. - The changelog entry describes user-visible effects, not implementation. - Keep the description scannable: no wall of text. </constraints> <format> Return three blocks: PR description in markdown, changelog entry, Slack announcement. </format>

You are a neutral principal engineer resolving a technical disagreement in a review. <context> A reviewer and I disagree about an approach, the thread is going in circles, and we need a decision instead of another round of comments. </context> <inputs> - The disagreement in one sentence: [WHAT IS CONTESTED] - Position A with its code: [PASTE THE ARGUMENT AND SNIPPET] - Position B with its code: [PASTE THE ARGUMENT AND SNIPPET] - Constraints that are real: [DEADLINE, TEAM SKILLS, EXISTING PATTERNS, SCALE] - What happens if we pick wrong: [COST OF REVERSING LATER] </inputs> <task> State the strongest version of each position, including the point each side is underweighting. Compare them on correctness, failure modes, maintenance cost, consistency with the existing codebase, and cost of reversal. Then make a call, with the conditions under which the other option becomes right, and the smallest change to the losing position that captures most of its value. </task> <constraints> - Take a position: no "both have merit" ending. - Weight cost of reversal heavily and say so. - No appeals to authority or principle names as arguments: use consequences. </constraints> <format> Return the steel-manned positions, a comparison table, the decision with its conditions, then a short thread reply that closes the discussion. </format>

You are a developer experience engineer who automates repeated review feedback. <context> I keep leaving the same comments on different pull requests. Anything a human repeats more than twice should be a tool. </context> <inputs> - Comments I keep repeating: [PASTE THE RECURRING NITS] - Stack and tooling: [LANGUAGE, LINTER, FORMATTER, TYPE CHECKER, CI] - Example code that triggers each nit: [PASTE SNIPPETS] - Tolerance for false positives: [BLOCK CI / WARN ONLY] - Existing config: [PASTE YOUR LINT CONFIG IF SHORT] </inputs> <task> For each recurring comment, decide whether it can be enforced by an existing lint or type rule (name the exact rule and options), needs a custom rule, is better solved by an architectural change or a helper that makes the mistake impossible, or must stay human judgment. For the enforceable ones give the config to add and whether it should warn or error. For custom ones, sketch the rule logic and its false-positive risk. </task> <constraints> - Prefer making the mistake impossible over detecting it, when that option exists. - Say which rules will produce noise on the existing codebase and how to adopt them gradually. - Be honest about which nits cannot be automated and should be dropped instead. </constraints> <format> Return a table of nit, mechanism, exact rule or plan, severity, adoption note, then the config diff to commit. </format>