These work best with tools that can read your whole project at once like Claude Code, Cursor, Aider, etc. The output is only a starting point. Review everything, especially the security stuff.

Security

1. Surface every place user input touches the database

Scan this codebase for every place where user-supplied input like forms, query strings, headers, cookies, or API payloads, is used in a database query. Flag any cases where the input is interpolated directly into SQL strings rather than passed through parameterized queries or a prepared statement. Show me file name, line number, and a short snippet for each case. Prioritize anything on public-facing routes.

SQL injection is a problem that never goes away. Legacy code often predates ORM conventions and mixes raw query strings with user input everywhere. Some modern code is also getting away from the use of ORMs as well, so this is good no matter what. An LLM can trace data flow across the whole codebase in one shot.

2. Find hardcoded secrets and credentials

Search the entire codebase (including config files, scripts, and test files) for hardcoded secrets. API keys, passwords, tokens, private keys, database connection strings with credentials, anything that should be in an environment variable but isn't. List every match with file path and line number.

Sometimes hardcoded secrets make their way into code. Sometimes, when code was made, it didn’t have access to a secrets manager.This is usually the highest-severity finding.

3. Audit authentication and session handling

Review how this application handles authentication and sessions. How are session tokens generated and stored? Are there routes that should require authentication but don't check for it? Anything that looks like a custom auth implementation with potential flaws? Flag anything that deviates from modern best practices — rolling session tokens, secure cookie flags, short expiry.

Auth code from five years ago often predates today’s conventions. Forgotten admin routes that skip middleware, missing httpOnly flags, rolled-from-scratch session systems — all common.

4. Look for XSS vulnerabilities in rendered output

Find every place where user-controlled data is rendered into HTML without being escaped or sanitized. Templates, server-side rendering, innerHTML in the frontend should all be included. Flag anything where content from the database, URL params, or user profiles could allow script injection.

Especially valuable for projects using older templating engines. XSS can sit in a database for years before anyone notices.

Code quality

5. Map the biggest, most tangled functions

Find the 10 most complex functions or methods in this codebase. Look for deeply nested conditionals, long chains of branches, functions doing clearly too many things. For each one: name, file, approximate line count, one-sentence description of what it does.

These are where most bugs live. Knowing which files and functions to review as a priority will help reduce future bugs.

6. Find duplicated business logic

Look for business logic that's duplicated across multiple files or modules. I want cases where the same concept (calculating a price, validating an email, checking permissions) is implemented in more than one place in slightly different ways. List the duplicates and suggest which should be the canonical version.

Unlike a linter, an LLM can spot semantic duplication.

7. Identify dead code and unused dependencies

Scan for code that appears to be dead where functions are never called, feature flags are always on or off, commented-out blocks that are no longer relevant, imports or dependencies that don't appear to be used anywhere, etc. For package dependencies, flag anything not imported in source. Give me a prioritized list of what's safe to remove.

Dead code is overhead for every developer who reads it. It’s accumulated but irrelevant code.

8. Summarize the overall architecture

Read through this codebase and give me a plain-English architectural overview. What are the main layers or modules? Where does data flow in and out? What patterns is it using? What are the biggest architectural decisions that weren't documented? Write it so a new engineer could get oriented.

This is the clearest use case that wasn’t possible before. No one ever writes this documentation and if they do, it becomes stale fast.

Accessibility

9. Audit for WCAG 2.2 violations

Review the frontend templates and components for accessibility violations: images missing alt text, form inputs without labels, interactive elements that aren't keyboard-reachable, missing ARIA roles, colour as the only means of conveying information, tabindex values greater than 0. For each issue, give me the file, the problem, and the WCAG 2.2 criterion it violates.

Most teams building don’t think about this. The legal landscape has also changed where accessibility lawsuits have increased a lot. This gives you a list mapped to specific standards, which is what you need for a real remediation plan.

10. Find keyboard navigation gaps

Look for interactive elements such as dropdowns, modals, custom components, carousels, date pickers, that rely entirely on mouse or touch events with no keyboard equivalents. Also flag cases where focus is moved programmatically without being returned to a logical place when the interaction ends (e.g. a modal that doesn't return focus to the trigger on close).

Keyboard accessibility matters for more than screen reader users: power users, people with motor disabilities, enterprise keyboards.

Performance

11. Find N+1 query patterns

Look through the data access layer and any ORM usage for N+1 query patterns (queries made inside loops, or related records loaded one-by-one instead of with a join or eager load) Show me each case with context for what's being fetched and suggest whether it should be a batch query, eager load, or join.

N+1 queries are responsible for a disproportionate amount of performance problems in apps. Oftentimes, queries run faster than the code that supports them or depends on them, so do more in the database directly.

12. Identify synchronous operations that should be async

Find places where slow or blocking operations (sending email, resizing images, generating PDFs, making third-party API calls) happen synchronously in the request/response cycle instead of being queued or deferred. For each case, explain the user-facing impact and suggest whether it should move to a background job or async handler.

Background job infrastructure usually gets added reactively. This helps you get ahead of it.

Documentation

13. Write docstrings for the most-called functions

Find the top functions or methods referenced from the most places in the codebase. For each one that lacks a docstring or has an inadequate one, write a proper docstring: what it does, its parameters, what it returns, any side effects or exceptions. Use the docstring style appropriate for this language.

Documentation is important, period.

14. Surface implicit assumptions and tribal knowledge

Read through this codebase and identify things a new developer would need to know that aren't obvious from the code. Magic numbers or strings with no explanation, environment or deployment assumptions baked in, implicit ordering dependencies between services or scripts, etc. List each one and suggest where it should be documented.

When the people who built the thing leave, this is what goes with them. This prompt surfaces the implicit contracts no one ever wrote down.

Testing

15. Find the most dangerous untested code paths

Identify areas with low or no test coverage that handle the highest-risk operations (payment processing, permission checks, data deletion, authentication, external API calls). Give me a prioritized list of specific functions or modules where missing tests represent the greatest risk, with a brief explanation of why each one matters.

You may not need to write tests for everything, but you should prioritize key flows for your application.