You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: pilot/const/function_calls.py
+1-1
Original file line number
Diff line number
Diff line change
@@ -496,7 +496,7 @@ def command_definition(description_command='A single command that needs to be ex
496
496
"decision": {
497
497
"type": "string",
498
498
"enum": ["apply", "ignore", "rework"],
499
-
"description": "Whether to apply this hunk (if it's a valid change with no problems), rework (a valid change but does something incorrectly), or ignore it (unwanted change)."
499
+
"description": "Whether to apply this hunk, rework, or ignore it."
Copy file name to clipboardexpand all lines: pilot/prompts/development/implement_changes.prompt
+20-4
Original file line number
Diff line number
Diff line change
@@ -3,17 +3,33 @@ I need to modify file `{{ file_name }}` that currently looks like this:
3
3
{{ file_content }}
4
4
```
5
5
6
-
I want you to implement changes described in previous message and show me the COMPLETE NEW VERSION of this file in this format:
6
+
**IMPORTANT**
7
+
I want you to implement changes described in previous message, that starts with `{{ prev_message_prefix }}` and ends with `{{ prev_message_postfix }}`. Make sure you don't make any mistakes, especially ones that could affect rest of project. Your changes will be reviewed by very detailed reviewer. Because of that, it is extremely important that you are STRICTLY following ALL the following rules while implementing changes:
8
+
9
+
**IMPORTANT** Output format
10
+
You must output the COMPLETE NEW VERSION of this file in following format:
**IMPORTANT**:If the instructions have comments like `// ..add code here...` or `# placeholder for code`, instead of copying the comment, interpret the instructions and output the relevant code.
17
+
**IMPORTANT** Comprehensive Codebase Insight
18
+
It's crucial to grasp the full scope of the codebase related to your tasks to avert mistakes. Check the initial conversation message for a list of files. Pay a lot of attention to files that are directly included in the file you are currently modifying or that are importing your file.
19
+
Consider these examples to guide your approach and thought process:
- UI components or templates: Instead of placing scripts directly on specific pages, integrating them in the <head> section or as reusable partials enhances application-wide consistency and reusability.
22
+
- Database operations: Be careful not to execute an action, like password hashing, both in a routing function and a model's pre('save') hook, which could lead to redundancy and errors.
23
+
- Adding backend logic: Prior to creating new functions, verify if an equivalent function exists in the codebase that you could import and use, preventing unnecessary code duplication and keeping the project efficient.
Write high-quality code, first organize it logically with clear, meaningful names for variables, functions, and classes. Aim for simplicity and adhere to the DRY (Don't Repeat Yourself) principle to avoid code duplication. Ensure your codebase is structured and modular for easy navigation and updates.
28
+
29
+
**IMPORTANT** If the instructions have comments like `// ..add code here...` or `# placeholder for code`, instead of copying the comment, interpret the instructions and output the relevant code.
14
30
15
-
**IMPORTANT**: Your reply MUST NOT omit any code in the new implementation or substitute anything with comments like `// .. rest of the code goes here ..` or `# insert existing code here`, because I will overwrite the existing file with the content you provide. Output ONLY the content for this file, without additional explanation, suggestions or notes. Your output MUST start with ``` and MUST end with ``` and include only the complete file contents.
31
+
**IMPORTANT** Your reply MUST NOT omit any code in the new implementation or substitute anything with comments like `// .. rest of the code goes here ..` or `# insert existing code here`, because I will overwrite the existing file with the content you provide. Output ONLY the content for this file, without additional explanation, suggestions or notes. Your output MUST start with ``` and MUST end with ``` and include only the complete file contents.
16
32
17
-
**IMPORTANT**: For hardcoded configuration values that the user needs to change, mark the line that needs user configuration with `INPUT_REQUIRED {config_description}` comment, where `config_description` is a description of the value that needs to be set by the user. Use appropriate syntax for comments in the file you're saving (for example `// INPUT_REQUIRED {config_description}` in JavaScript). NEVER ask the user to write code or provide implementation, even if the instructions suggest it! If the file type doesn't support comments (eg JSON), don't add any.
33
+
**IMPORTANT** For hardcoded configuration values that the user needs to change, mark the line that needs user configuration with `INPUT_REQUIRED {config_description}` comment, where `config_description` is a description of the value that needs to be set by the user. Use appropriate syntax for comments in the file you're saving (for example `// INPUT_REQUIRED {config_description}` in JavaScript). NEVER ask the user to write code or provide implementation, even if the instructions suggest it! If the file type doesn't support comments (eg JSON), don't add any.
Copy file name to clipboardexpand all lines: pilot/prompts/development/review_changes.prompt
+8-35
Original file line number
Diff line number
Diff line change
@@ -15,42 +15,15 @@ Here is the diff of the changes:
15
15
16
16
As you can see, there {% if hunks|length == 1 %}is only one hunk in this diff, and it{% else %}are {{hunks|length}} hunks in this diff, and each{% endif %} starts with the `@@` header line.
17
17
18
-
Think carefully about the instructions and review the proposed changes. For each hunk of change, provide a detailed rationale, and decide whether it should be:
19
-
* applied - if the change is correct
20
-
* ignored - for example if it is a code deletion or change that wasn't asked for
21
-
* reworked - if the change does something correctly but also makes a serious mistake, in which case both applying and ignoring the entire hunk would be incorrect
18
+
When reviewing the code changes, apply these principles to decide on each hunk:
19
+
- Apply: Approve and integrate the hunk into our core codebase if it accurately delivers the intended functionality or enhancement, aligning with our project objectives. This action confirms the change is beneficial and meets our quality standards.
20
+
- Ignore: Use this option sparingly, only when you're certain the entire hunk is incorrect or will introduce errors (logical, syntax, etc.) that could negatively impact the project. Ignoring means the hunk will be completely removed. This should be reserved for cases where the inclusion of the code is definitively more harmful than its absence. Emphasize careful consideration before choosing 'Ignore.' It's crucial for situations where the hunk's removal is the only option to prevent significant issues. Otherwise, 'Rework' might be the better choice to ensure the code's integrity and functionality.
21
+
- Rework: Suggest this option if the concept behind the change is valid and necessary but is implemented in a way that introduces problems. This indicates a need for a revision of the hunk to refine its integration without fully discarding the underlying idea.
22
22
23
-
Finally, if the changes miss something that was in the instructions, mention that. Keep in mind you're just reviewing one file, `{{ file_name }}`. You don't need to consider if other files are created, dependent packages installed, etc. Focus only on reviewing the changes in this file based on the instructions in the previous message.
23
+
When deciding what should be done with the hunk you are currently reviewing, pick an option that most reviewers of your skill would choose. Your decisions have to be consistent.
24
24
25
-
Note that the developer may add, modify or delete logging (including `gpt_pilot_debugging_log`) or error handling that's not explicitly asked for, but is a part of good development practice. Unless these logging and error handling additions break something, your decision to apply, ignore or rework the hunk should not be based on this. Base your decision only on functional changes - comments or logging are less important. Importantly, don't ask for a rework just because of logging or error handling changes. Also, take into account this is a junior developer and while the approach they take may not be the best practice, if it's not *wrong*, let it pass. Ask for rework only if the change is clearly bad and would break something.
25
+
Keep in mind you're just reviewing current file. You don't need to consider if other files are created, dependent packages installed, etc. Focus only on reviewing the changes in this file based on the instructions in the previous message.
26
26
27
-
Here is an example output if 2 of 4 hunks in the change should be applied, one of them should be ignored, one should be reworked, and no other changes are needed:
28
-
```
29
-
{
30
-
"hunks": [
31
-
{
32
-
"number": 1,
33
-
"reason": "Some explanation why this part of the change is important. The reasoning here should be as detailed as possible as that will help you reach the correct conclusion.",
34
-
"decision": "apply"
35
-
},
36
-
{
37
-
"number": 2,
38
-
"reason": "Another explanation, for the 2nd hunk",
39
-
"decision": "apply"
40
-
},
41
-
{
42
-
"number": 3,
43
-
"reason": "This hunk accidentally deletes important code without any useful change",
44
-
"decision": "ignore"
45
-
},
46
-
{
47
-
"number": 4,
48
-
"reason": "This hunk does something correctly but also does something really wrong. It would be incorrect to either apply or ignore it fully, so it should be reworked.",
49
-
"decision": "rework"
50
-
},
51
-
],
52
-
"review_notes": "General review notes, if something is missing from the change you can comment about it here"
53
-
}
54
-
```
27
+
Note that the developer may add, modify or delete logging (including `gpt_pilot_debugging_log`) or error handling that's not explicitly asked for, but is a part of good development practice. Unless these logging and error handling additions break something, your decision to apply, ignore or rework the hunk should not be based on this. Base your decision only on functional changes - comments or logging are less important. Importantly, don't ask for a rework just because of logging or error handling changes. Also, take into account this is a junior developer and while the approach they take may not be the best practice, if it's not *wrong*, let it pass. Ask for rework only if the change is clearly bad and would break something.
55
28
56
-
IMPORTANT: The developer that wrote this is sloppy and has probably deleted some parts of the code that should not be deleted. Pay special attention to that in your review!
29
+
The developer that wrote this is sometimes sloppy and has could have deleted some parts of the code that contain important functionality and should not be deleted. Pay special attention to that in your review.
0 commit comments