|
41 | 41 | - "Potential Issues" |
42 | 42 | - "Improvements" |
43 | 43 |
|
| 44 | +Make sure to look for the following issues in the code logic: |
| 45 | +[ |
| 46 | + "Syntax Errors", |
| 47 | + "Logic Errors", |
| 48 | + "Off-by-one Errors", |
| 49 | + "Infinite Loops", |
| 50 | + "Null or Undefined Values", |
| 51 | + "Resource Leaks", |
| 52 | + "Race Conditions", |
| 53 | + "Integration Issues", |
| 54 | + "Performance Issues", |
| 55 | + "Security Vulnerabilities" |
| 56 | +] |
| 57 | +
|
44 | 58 | For "request_for_change", only make it true when topic is part of "Improvements" or "Potential Issues" or something which you think needs attention of the developer. |
45 | 59 |
|
| 60 | +For "solution" make sure to point out whats wrong and how to fix it in current code. Try to be as precise as possible. |
| 61 | +
|
46 | 62 | Generate all relevant and actionable feedback. Avoid duplicate feedbacks for same line, try to merge them. |
47 | 63 | For each piece of feedback, clearly reference the specific file(s) and line number(s) of code being addressed for each comment. Use markdown code blocks to quote relevant snippets of code when necessary. |
48 | | -Keep comments concise but make sure they have actionable points pointing to the code or line having the issue. Avoid duplicate feedback, merge when necessary. |
| 64 | +Keep comments concise but make sure they have actionable and useful points pointing to the code or line having the issue. Avoid generic comments. Avoid duplicate feedback, merge when necessary. |
49 | 65 |
|
50 | 66 | If there is no feedback, return an empty JSON object: {{"review": []}} |
51 | 67 |
|
|
94 | 110 | - "Potential Issues" |
95 | 111 | - "Improvements" |
96 | 112 |
|
| 113 | +Make sure to look for the following issues in the code logic: |
| 114 | +[ |
| 115 | + "Syntax Errors", |
| 116 | + "Logic Errors", |
| 117 | + "Off-by-one Errors", |
| 118 | + "Infinite Loops", |
| 119 | + "Null or Undefined Values", |
| 120 | + "Resource Leaks", |
| 121 | + "Race Conditions", |
| 122 | + "Integration Issues", |
| 123 | + "Performance Issues", |
| 124 | + "Security Vulnerabilities" |
| 125 | +] |
| 126 | +
|
97 | 127 | For "request_for_change", only make it true when topic is part of "Improvements" or "Potential Issues" or something which you think needs attention of the developer. |
98 | 128 |
|
| 129 | +For "solution" make sure to point out whats wrong and how to fix it in current code. Try to be as precise as possible. |
| 130 | +
|
99 | 131 | Generate all relevant and actionable feedback. Avoid duplicate feedbacks for same line, try to merge them. |
100 | 132 | For each piece of feedback, clearly reference the specific file(s) and line number(s) of code being addressed for each comment. Use markdown code blocks to quote relevant snippets of code when necessary. |
101 | | -Keep comments concise but make sure they have actionable points pointing to the code or line having the issue. Avoid duplicate feedback, merge when necessary. |
| 133 | +Keep comments concise but make sure they have actionable and useful points pointing to the code or line having the issue. Avoid generic comments. Avoid duplicate feedback, merge when necessary. |
102 | 134 |
|
103 | 135 | If there is no feedback, return an empty JSON object: {{"review": []}} |
104 | 136 |
|
|
0 commit comments