Give Gemini the error, the reproduction, and the relevant code, then ask for the most likely root cause, a minimal fix, and how to confirm it — before touching anything else.
프롬프트
Here is a bug. Symptom: [SYMPTOM]. Reproduction: [STEPS]. Relevant code: [CODE/FILES]. Identify the most likely root cause with reasoning, propose the minimal fix, and tell me how to confirm it works. Do not suggest unrelated refactors. If you are unsure, list what to check next.
변수 바꾸기
[SYMPTOM]Exact error text or wrong behaviour.
[STEPS]How to reproduce.
[CODE/FILES]The smallest slice that contains the bug.
사용할 모델
- Gemini 3.1 Pro — Root-cause reasoning over multiple files is stronger on Pro.
예시 입력
- [SYMPTOM] = "TypeError: cannot read property id of undefined on checkout".
예시 출력
저희는 실제 모델 실행의 예시 출력만 게시합니다. 이 템플릿은 아직 공식적으로 테스트되지 않아 출력이 표시되지 않습니다. 위의 입력값으로 직접 실행해 보세요.
이 구조가 작동하는 이유
- Anchoring on reproduction keeps the model from guessing in the dark.
- Banning unrelated refactors keeps the diff small and reviewable.
흔한 실패와 수정
It guesses without the real code.
수정: Paste the actual failing function and stack trace.
알려진 한계
- Confirm the fix by reproducing the bug first, then re-running.