Define a narrow review scope first

Start by deciding exactly what the review must accomplish. A broad request such as "review this folder" gives the model too many variables and produces generic output.

Instead, state a single objective: check for security issues in the authentication module, verify that a policy document matches the latest regulatory text, or confirm that new API endpoints follow the existing error-handling pattern. This single-objective approach keeps the model focused on one task at a time and reduces the risk of scattered or contradictory suggestions.

A narrow scope also makes it easier to measure whether the review succeeded. When the objective is stated clearly up front, later checks can confirm that every comment returned actually addresses that objective rather than drifting into unrelated areas.

  • Write the objective in one sentence before selecting files.
  • List only the files that directly support that objective.
  • Exclude supporting libraries, test data, or older versions unless they are required for comparison.
  • Revisit the objective after the first pass to confirm no extra files crept in during preparation.

Use descriptive, stable file names

File names become part of the context the model reads. Names that describe purpose and version reduce the chance the AI misinterprets content or suggests changes to the wrong file.

Adopt a short convention such as purpose-scope-date or purpose-owner-status. Keep names under 60 characters and avoid spaces or special characters that can break automated tools. Consistent naming also helps when the same package is reused for follow-up reviews or handed to a different reviewer.

Stable names further support traceability. When each file carries its purpose in the name, it becomes simpler to reconstruct why a particular file was included and what the review was meant to achieve.

  • Replace generic names like draft.docx or utils.py with policy-v2-2026-07.md or auth-middleware.ts.
  • Include a short status suffix when files move through stages: -review, -approved, -final.
  • Update the name when content changes rather than overwriting the same file.
  • Apply the same naming pattern across related documents so the model can infer relationships without extra explanation.

Attach only the supporting context the model needs

AI reviews improve when the model receives the minimum additional information required to judge the file. Extra documents dilute attention and increase token cost.

Provide a short context file or inline notes that answer three questions: what problem the file solves, which rules or standards apply, and what outcome counts as success. This focused context keeps the model from guessing at background details or inventing constraints that were never stated.

Limiting context also respects practical limits on input size. By supplying only what is essential, the review stays within reasonable token budgets while still giving the model enough information to produce targeted feedback.

  • Create a one-page CONTEXT.md that lists the review goal, relevant standards, and any constraints.
  • Reference existing internal links such as the preflight context budget guidance when the review involves code.
  • Omit large unrelated files; link to them only if the model must fetch them itself.
  • Review the context file for redundancy before attaching it so no sentence repeats information already present in the target files.

Test the prepared package before sending it

After scoping, naming, and adding context, run a quick self-check. Open the selected files and the context note together and confirm that a human reviewer could understand the task from those items alone.

If gaps appear, add the missing detail to the context file rather than expanding the file list. This step catches problems while they are still easy to fix and prevents the model from receiving an incomplete or confusing package.

A final verification also creates a reusable record. Documenting the exact contents of each prepared package makes it possible to repeat or compare reviews later without guessing what was originally supplied.

  • Verify that every referenced standard or rule is either quoted or linked.
  • Remove any file that is not mentioned in the context note.
  • Record the exact file list and context version so later reviews can be compared.
  • Run the self-check from the perspective of someone who has never seen the project before to surface hidden assumptions.