The prompt
Score 10 of 10, Excellent
Use it when Your review comments are accurate but blunt, and you want them rewritten so the author knows what to change and what blocks the merge.
- {{author_context}}
- {{draft_comments}}
- {{code}}
- {{conventions}}
Full prompt and why it works
Prompt
Rewrite my code review comments below so that they are clear and kind, for {{author_context}}, so that the author knows exactly what to change and why, can tell which comments must be resolved before merging, and comes away wanting to keep working with the reviewer. My draft comments, each with the file and line it refers to: """ {{draft_comments}} """ The code they refer to, if it helps: """ {{code}} """ Our review conventions (labels such as "nit:" or "blocking:", and what must block a merge): {{conventions}} For each comment, write: 1. A label: blocking, non-blocking, question, nit or praise, in our convention's words if it has them. 2. The issue, in one sentence about the code, not the person ("this loop reads the file twice" rather than "you read the file twice"). 3. Why it matters: a bug, a security risk, performance, readability or consistency with the codebase. 4. A suggestion: what to do instead, with a short code snippet when the change is small. 5. For blocking comments, what would resolve it. Keep each comment under 80 words, not counting code. Return them in the same order as my drafts, numbered to match, then one short overall comment for the pull request that names what is good about it as well as what is needed. Keep the substance. Do not soften a real blocking problem into a suggestion, and do not drop any point I made. Do not add issues I did not raise; if you think one of my comments is technically wrong, keep it and add a line "FOR ME:" saying why. Leave out sarcasm and the words "just", "simply", "obviously" and "why didn't you". For example, "Why on earth is this not using the cache?" could become: "Non-blocking: this call skips the cache in cache.py, so each request hits the database. Could it go through get_cached_user()?" That example shows the form only. If you cannot tell whether one of my comments is meant to block the merge, label it [CHECK: blocking?] instead of choosing.
Variables
- {{author_context}}
- Who wrote the code, for example "a developer in their first month" or "an outside contributor".
- {{draft_comments}}
- Your comments as written, each with its file and line.
- {{code}}
- The diff or the code the comments refer to. Write "none" to leave it out.
- {{conventions}}
- Your team's labels and rules, for example "Conventional Comments; only bugs and security issues block", or "none".
Why it works
- What to avoid. Blocking problems stay blocking and none of your points are dropped, so kinder wording never costs the review its substance.
- Format. Every comment gets a label, the issue, why it matters and a suggestion, so the author knows which comments must be resolved before merging.
- If unsure. A comment whose weight is unclear is marked [CHECK: blocking?] rather than labeled by the model.