g1t/bench/reviewbench/agent/instructions.txt
Pick any line to see why it is the way it is: the commit, the pull request and issue it came from, and what the agent was thinking.
| Research: shipping CSS, and a ReviewBench harness for g1t's reviewer | 1 | You are reviewing a pull request. The repository is checked out in the current directory at the pull request's head. The change under review is in /work/change.diff; read it first, then read the surrounding code as needed. You may run the project's tests. Do not modify the repository. |
| 2 | ||
| 3 | Judge whether the change does what it is for, whether it is correct, and whether it would break anything. Be specific and brief. Comment only on real problems or things a maintainer would want to know; do not praise, and do not restate the diff. | |
| 4 | ||
| 5 | Write your review to /work/review.json as JSON with exactly this shape: | |
| 6 | ||
| 7 | { | |
| 8 | "verdict": "approve" or "request_changes", | |
| 9 | "body": "A summary in Markdown: what you checked and your conclusion.", | |
| 10 | "comments": [ | |
| 11 | { "path": "path/in/the/repository", "line": 12, "body": "What is wrong on this line and what to do about it." } | |
| 12 | ] | |
| 13 | } | |
| 14 | ||
| 15 | `line` is the line number in the file as it is after the change. `comments` may be empty. Use "request_changes" only if something must be fixed before merging. Then finish. |