Claude Code Review Prompts: Requesting Bug Evidence and Reproduction Conditions

Key takeaway: When assigning code review, specify which changes and behavioral criteria to inspect rather than asking for many problems. Findings need file locations, occurrence conditions, user impact, and evidence. Prompts and calculation functions below are review exercises created by the author, not reviews of an actual repository.

1. Define review scope and correct behavior first

State whether the target is current changes, a particular file, or an entire feature flow. With Git, establish the comparison baseline in the actual repository. Vague full-code reviews can mix older problems, new regressions, and stylistic preferences.

Explain correct behavior through brief input/output examples. For search, state whether empty input shows all results or only guidance. Without defining desired output, identical implementations can be judged differently. Provide existing design and test locations if available.

2. Basic code review prompt

이번 변경을 코드 리뷰해 줘. 파일은 아직 수정하지 마.
검토 범위: [실제 변경 파일 또는 비교 기준]
요구 동작: [입력과 기대 결과]
우선 확인: 잘못된 결과, 예외 처리, 기존 기능의 회귀.
스타일 선호만으로 문제를 만들지 마.
각 지적은 아래 형식으로 적어 줘.
- 파일과 위치
- 어떤 입력 또는 상태에서 발생하는지
- 사용자에게 어떤 영향이 있는지
- 코드·테스트·실행 결과 중 확인 근거
- 실제로 확인한 문제인지, 아직 확인할 가설인지
실행하지 않은 테스트는 실행했다고 쓰지 마.

Review and repair are separate tasks: read findings, select valid issues, then request changes. Problems unclear from appearance need call paths and real data conditions checked. This format collects judgment-relevant information rather than maximizing findings.

3. Hypothetical example: reviewing a discount function

Consider a function taking price and discount percentage to calculate final price. Set criteria: price nonnegative, discount between 0 and 100, invalid input explicitly handled. A 20% discount on 10,000 won should yield 8,000 won. This is a manually calculated illustration, not code execution output.

• Normal range: matches the expected value for 10,000 won and 20%.
• Boundaries: treatment of 0% and 100% discounts.
• Invalid values: negative, empty, and nonnumeric inputs.
• Connected flow: where UI strings become numbers.
• Display rules: where decimals and rounding are handled.

Even if the function looks correct, input conversion or display can fail. Conversely, a function receiving only externally validated inputs may not need every defensive check duplicated. Include whether the input can actually reach it.

4. Distinguish facts, hypotheses, and improvement suggestions

“An empty array caused an exception” is actual reproduction; “an empty array may cause an exception” is code interpretation. Without logs, ask which command and input verified the former. If execution is unavailable, retain a proposed checking method.

Anthropic'sClaude Code recommended workflowsalso describe providing validation criteria and independently reviewing results. Compare each finding's path and impact rather than treating the answer as definitive. Specific explanations can still rest on wrong assumptions.

Assign states such as reproduced, further checking needed, or outside current scope. Check occurrence conditions before complicating code to address unsupported findings.

5. Recheck under identical conditions after fixing

Check original reproduction and normal conditions. Blocking invalid discounts while breaking valid 20% inputs creates regression. Follow project tests and commands. Creating a test name differs from executing and passing it.

A completion report can state changed files, cause, executed validation, and remaining checks.Official workflow examplesalso address tests and change review in stages. Request explicit unexecuted items so readers do not infer missing validation was performed.

6. Distinguish change review from requirements review

Finding bugs introduced by changes differs from checking every planned requirement. The former examines before/after paths and regressions; the latter pairs requirements with implementation and validation evidence. State which is intended so an implemented feature missing one condition is meaningfully classified.

At the check date, official recommendations also describe the built-in /code-review feature, with a separate subagent reviewing the current diff. Define whether your purpose is change-error review or plan comparison rather than assuming every review method is equivalent. Calling a feature alone does not establish reproduced bugs or fulfillment of every requirement.

7. Follow evidence through a hypothetical function

The following JavaScript is fictional practice code, with no actual execution results. Assume the screen converts “20%” into the number 20 before passing it. A design passing 0.2 would change judgment, so define the input contract first.

function finalPrice(price, discountPercent) {
  return price * (1 - discountPercent);
}

Under that contract, inputs 10,000 and 20 produce 10,000 × (1 − 20) = −190,000, not the required 8,000. This is substitution into an equation, not an execution log. A finding such as “With a contract receiving percentage 20, missing ratio conversion makes normal input negative” reveals cause and conditions better than “discount function looks wrong.”

Even dividing percentage by 100 does not automatically define rejection, decimals, or currency display. A 15% discount on 999 won is mathematically 849.15 won; rounding or truncation must follow project requirements. Provide criteria so reviewers do not substitute their own pricing preferences.

이 함수의 입력 계약은 할인 비율을 0~100 숫자로 받는 것입니다.
호출부에서 실제로 이 계약을 지키는지 먼저 추적해 줘.
10,000 / 20% 사례의 식과 기대값 차이를 설명해 줘.
실행 로그가 없으면 '정적 검토와 계산으로 판단'이라고 표시해 줘.
입력 검증·반올림 정책은 기존 문서에서 확인하고,
근거가 없으면 별도 결정 사항으로 남겨 줘.

8. Questions and categories reducing false positives

If a finding says strings may fail but the caller converts and validates them, inspect whether those inputs reach the function. Trace calls and conversion before adopting findings instead of stacking defenses for unchecked paths. This verifies occurrence conditions rather than ignoring errors.

리뷰 지적 2번을 다시 검토해 줘.
주장한 입력이 외부에서 해당 함수까지 오는 호출 경로를 제시해 줘.
중간 검증이 있다면 그 파일과 조건을 확인해 줘.
현재 코드로 발생할 수 없는 가정이면 지적을 철회하고 이유를 적어 줘.
검토 범위에서 호출부를 찾지 못했다면 '추가 확인 필요'로 남겨 줘.
같은 이유를 표현만 바꿔 여러 지적으로 나누지 마.

Assess impact and evidence separately. Incorrect payments may have large impact, but an unverified path must remain marked accordingly. “Severe” does not make it reproduced; a small simple reproduction does not make user impact small either.

9. Fix selected problems and compare results

Include behavior to preserve in the repair request. Correcting discount conversion differs from redesigning the whole screen. Follow existing test procedures; if none exist, state key expected outputs and determine verification first. Do not invent nonexistent test commands as executed results.

채택한 지적: [번호와 원인]
수정 범위: 할인 비율 변환과 직접 관련된 코드.
유지 조건: 기존 화면·공개 함수 입력 형식 유지.
검증 기준: 정상 20%, 경계 0%와 100%, 기존 입력 거부 정책.
실제 프로젝트의 검증 명령을 근거 파일에서 찾아 사용해 줘.
완료 보고에는 변경 파일, 해결한 원인, 실행 명령과 결과,
실행하지 못한 항목·이유를 나눠 적어 줘.
검증 중 다른 문제가 나오면 이번 수정과 관련 여부를 구분해 줘.

Finally reread the diff for out-of-scope changes. If tests passed, check which tests and environment; retain separately pending items such as price display. One passing test supports only that test's scope, not every input across the service.

Can code be reviewed without tests running?

Static review of conditions and call paths is possible. Mark execution unperformed and state inputs and checks needed. For environment limits, separating static findings from remaining behavioral checks helps the next person continue better than merely “review failed.”

Frequently asked questions and common mistakes

Is “no problems found” the end? Check reviewed scope and execution status.What if there are too many style comments? Specify priority for functional errors and requirement violations.Can I assign automatic repairs too? State selected findings and repair scope, then verify under the same conditions.

Official sources and check date

• Best practices for Claude Code
• Common workflows

Official documents checked: October 3, 2026. Screens and availability can change afterward.