How to prepare a codebase for AI code review
An AI code review is only as useful as the evidence you give it. Paste one changed file without its caller, types, tests, or configuration and the review will often sound plausible while missing the real risk.
The answer is not to upload every byte of a repository. Good AI code review uses a focused context pack: the small set of files needed to understand the change, prepared with clear paths, source boundaries, a task, and no secrets.
Start with the review question
Before selecting files, state what the reviewer should decide. “Review this code” is too broad. A better task names the change and the risk you care about.
Review this change for correctness, regressions, security risks, and missing tests. Focus on the new payment retry path and its interaction with existing idempotency handling.
This turns file selection into a practical question: what would a reviewer need to verify that claim?
Include the files that explain the change
For most pull-request-sized reviews, include the changed module plus the nearest files that define its contract. That commonly means:
- The changed source files and their direct caller or entry point.
- Types, schemas, interfaces, or API contracts used by the change.
- One or two relevant tests, including a missing edge case if you know it.
- Configuration that changes runtime behavior.
- A short README, architecture note, issue description, or acceptance criteria.
- A representative error log only when the review concerns a production failure.
If a file does not help the reviewer understand the task, leave it out. More files are not automatically more context.
Exclude noise before it consumes the context window
| Usually exclude | Why | Exception |
|---|---|---|
node_modules, vendor code | It obscures your own code and wastes tokens. | Include a tiny dependency snippet only if the bug is inside an integration contract. |
dist, build output, generated files | The reviewer should inspect the source of truth. | Include a generated artifact when generation itself is the issue. |
| Lockfiles | They are large and rarely explain a logic change. | Dependency-resolution or supply-chain review. |
| Unrelated modules | They dilute attention and create false assumptions. | Include the dependency boundary, not the whole subsystem. |
| Secrets and production data | They should never enter an AI prompt raw. | Use a redacted example or safe fixture instead. |
A folder review is useful here because ignored and generated files can remain visible without being silently included. Keep the ability to override a default when a file is genuinely relevant.
Keep the code review private
Private repositories frequently contain API keys, internal URLs, customer identifiers, stack traces, and credentials in configs or logs. Do not treat source code as automatically safe to paste.
Review environment files, copied request headers, fixture data, analytics exports, and support logs. Replace real identifiers with clearly labeled placeholders where the exact value is not needed. For a detailed checklist, read what files should never be pasted into ChatGPT or Claude.
The model usually needs the structure of a configuration value, not the credential itself.
Give the reviewer a useful instruction
Make the review output actionable. Ask the model to rank findings and distinguish confirmed issues from questions. It is also useful to tell it what not to do, such as proposing a rewrite before identifying a specific failure mode.
Review the included project context. Return findings ordered by severity. For each finding, cite the file and relevant behavior, explain the failure mode, and propose the smallest safe fix. If there is not enough evidence, say what file or test is missing. Do not report style preferences as bugs.
Build the pack locally
MarkDone's AI Context Builder lets you choose a project folder or individual files, preserves relative paths, applies local ignore rules, shows an included-file tree, estimates tokens, and scans for common secrets before it creates context.md. Nothing is uploaded to MarkDone.
Select the built-in Code review profile to prefill a review task and a coding-agent token target. Review the generated Markdown, remove any low-value source, and then copy or download the final pack for Claude, Codex, ChatGPT, or another tool.
Open AI Context Builder
How large should an AI code-review pack be?
There is no universal file count. Start with the changed code, its contracts, and tests. If the pack becomes large, split the review by concern: correctness first, security second, architecture third. A smaller pack with a precise task is normally easier for both you and the model to audit.
For bigger projects or recurring review workflows, MarkDone Pro removes the Free plan’s file and token limits and lets you save local context-pack profiles. The output remains local and provider-neutral.
Final checklist
- Name the change and the review question.
- Add changed files, contracts, relevant tests, and only necessary configuration.
- Exclude dependencies, build output, unrelated modules, and raw secrets.
- Scan and redact before sending.
- Ask for ranked findings with file-level evidence.
- Split a large review into smaller task-specific packs.
For a debugging-specific version of this workflow, read how to give Claude context for a bug fix. For a broader explanation of portable project handoffs, see how to give Claude or Codex your whole project as context.