Skip to content
This repository was archived by the owner on Mar 6, 2024. It is now read-only.

Commit 164b539

Browse files
committed
update prompt
1 parent 021d3bb commit 164b539

File tree

1 file changed

+16
-53
lines changed

1 file changed

+16
-53
lines changed

src/prompts.ts

Lines changed: 16 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -99,63 +99,26 @@ $description
9999
$short_summary
100100
\`\`\`
101101
102-
## Instructions
103-
104-
The format for changes provided in the example below consists of
105-
multiple change sections, each containing a new hunk (annotated with
106-
line numbers), an old hunk, and optionally, existing comment chains.
107-
Note that the old hunk code has been replaced by the new hunk. Some
108-
lines on the new hunk may be annotated with line numbers.
109-
110-
Your task is to meticulously perform line-by-line review of new hunks,
111-
identifying substantial issues only. Respond only in the below example format,
112-
consisting of review sections. Each review section must have a line number range
113-
and a review comment for that range. Use separator after each review section.
114-
Line number ranges for each review section must be within the range of a specific
115-
new hunk. Start line number must belong to the same hunk as the end line number.
116-
Provide the exact line number range (inclusive) for each review comment. To leave
117-
a review comment on a single line, use the same line number for start and end.
118-
119-
Take into consideration the context provided by old hunks, comment threads, and
120-
file content during your review. Remember, the hunk under review is a fragment of a
121-
larger codebase and may not show all relevant sections, such as definitions,
122-
imports, or usage of functions or variables. Expect incomplete code fragments or
123-
references to elements defined beyond the provided context. Do NOT flag missing
124-
definitions, imports, or usages unless the context strongly suggests an issue.
125-
Do NOT restate information readily apparent in the code or the pull request.
126-
Do NOT provide general feedback, summaries, explanations of changes, or praises
127-
for making good additions. Do NOT question the developer's intentions behind the
128-
changes or warn them about potential compatibility issues with other dependencies.
129-
Avoid making assumptions about broader impacts beyond the given context or the
130-
necessity of the changes. Do NOT request the developer to review their changes.
131-
Given your knowledge may be outdated, it is essential to trust the developer when
132-
they appear to utilize newer APIs and methods. Presume the developer has
133-
exhaustively tested their changes and is fully aware of their system-wide
134-
implications. Focus solely on offering specific, objective insights based on the
135-
actual code and refrain from making broad comments about potential impacts on
136-
the system.
137-
138-
Use GitHub flavored markdown format for review comment text
139-
and fenced code blocks for code snippets using the relevant
140-
language identifier. Do NOT annotate the code snippet with
141-
line numbers. The code snippet must be correctly
142-
formatted & indented.
143-
144-
If applicable, you may provide a replacement snippet to fix
145-
issues within a hunk by using \`diff\` code blocks, clearly
146-
marking the lines that need to be added or removed with \`+\`
147-
and \`-\` annotations. The line number range for the review
148-
comment that includes a replacement snippet must precisely map
149-
to the line number range that has to be completely replaced
150-
within a hunk. Do NOT use \`suggestion\` code blocks for
151-
replacement snippets.
102+
## IMPORTANT Instructions
103+
104+
Input: New hunks annotated with line numbers and old hunks (replaced code). Hunks represent incomplete code fragments.
105+
Additional Context: PR title, description, summaries and comment chains.
106+
Task: Review new hunks for substantive issues using provided context and respond with comments if necessary.
107+
Output: Review comments in markdown with exact line number ranges in new hunks. Start and end line numbers must be within the same hunk. For single-line comments, start=end line number. Must use example response format below.
108+
Use fenced code blocks using the relevant language identifier where applicable.
109+
Don't annotate code snippets with line numbers. Format and indent code correctly.
110+
Do not use \`suggestion\` code blocks.
111+
For fixes, use \`diff\` code blocks, marking changes with \`+\` or \`-\`. The line number range for comments with fix snippets must exactly match the range to replace in the new hunk.
112+
113+
- Do NOT provide general feedback, summaries, explanations of changes, or praises
114+
for making good additions.
115+
- Focus solely on offering specific, objective insights based on the
116+
given context and refrain from making broad comments about potential impacts on
117+
the system or question intentions behind the changes.
152118
153119
If there are no issues found on a line range, you MUST respond with the
154120
text \`LGTM!\` for that line range in the review section.
155121
156-
Reflect on your comments thoroughly before posting them to
157-
ensure accuracy and compliance with the above guidelines.
158-
159122
## Example
160123
161124
### Example changes

0 commit comments

Comments
 (0)