mirror of
https://github.com/OMGeeky/gpt-pilot.git
synced 2026-01-06 19:29:33 +01:00
Simplifying the flow - updated prompts
This commit is contained in:
@@ -53,7 +53,7 @@ Let's start with the task #0:
|
||||
```
|
||||
{{ array_of_objects_to_string(sibling_tasks[current_task_index]) }}
|
||||
```
|
||||
|
||||
{#
|
||||
Think step by step about what needs to be done to complete this task.
|
||||
{% if sibling_tasks[current_task_index]['type'] == 'COMMAND' %}
|
||||
Respond with all commands that need to be run to fulfill this step.
|
||||
@@ -65,8 +65,19 @@ First, you need to know the code that's currently written so that you can approp
|
||||
|
||||
You can get the list of files by calling `get_files` function.
|
||||
{% else %}
|
||||
#}
|
||||
|
||||
First, just make a list of steps we need to do to fulfill this task. It should be in a JSON array. Every step must NOT contain both a command that needs to be run and the code that needs to be changed. It can be either command (or multiple commands) that need to be run or a change in the code.
|
||||
{#
|
||||
Each step must start with a keyword `command` in case the step consists of commands that need to be run or `code_change` in case it consists of changes in the code. After the keyword, write a description of what will be done in that step. Do not write what needs to be done for each step but only list them in an array.
|
||||
#}
|
||||
If a step involves changing the code, it must include code changes for only one single file. In case you need to change multiple files, split it into multiple steps where each involves changes for a single file.
|
||||
|
||||
First, just make a list of steps we need to do to fulfill this task. It should be in a JSON array. Every step must NOT contain both a command that needs to be run and the code that needs to be changed. It can be either command (or multiple commands) that need to be run or a change in the code. Each step must start with a keyword `command` in case the step consists of commands that need to be run or `code_change` in case it consists of changes in the code. After the keyword, write a description of what will be done in that step. Do not write what needs to be done for each step but only list them in an array. Also, keep in mind that you also need to write test (or tests) that will programmatically verify that your task is complete.
|
||||
You can also request a human intervention if needed. For example, if you need an API key to some service, you should make one task for human to get an API key and put it where you think is appropriate. Just make sure that you describe the task is enough details so that a person reading it can be completely sure what to do.
|
||||
|
||||
{% endif %}
|
||||
You have all the technologies installed on the machine (not dependencies but the technologies like databases, etc.) and you have a folder set up for this project. All commands that you specify will be ran within that folder.
|
||||
|
||||
Also, keep in mind that you also need to write test (or tests) that will programmatically verify that your task is complete.
|
||||
{#
|
||||
{% endif %}
|
||||
#}
|
||||
@@ -1,18 +1,19 @@
|
||||
You need to implement the current changes into a codebase:
|
||||
{#You need to implement the current changes into a codebase:
|
||||
-- INSTRUCTIONS --
|
||||
{{ instructions }}
|
||||
-- END OF INSTRUCTIONS --
|
||||
-- END OF INSTRUCTIONS --#}
|
||||
{% if step_index != 0 %}
|
||||
So far, steps {{ finished_steps }} are finished so let's do
|
||||
{% else %}
|
||||
Let's start with the
|
||||
{% endif %}
|
||||
step #{{ step_index }} - `{{ step_description }}`.
|
||||
|
||||
I will give you each file that needs to be changed and you will implement changes from the instructions. To do this, you will need to see the currently implemented files so first, filter the files outlined above that are relevant for the instructions. Then, tell me files that you need to see so that you can make appropriate changes to the code. If no files are needed (eg. if you need to create a file), just return an empty array.
|
||||
|
||||
Here is the current folder tree:
|
||||
```
|
||||
{{ directory_tree }}
|
||||
```
|
||||
|
||||
You are currently working on this step from the instructions above:
|
||||
```
|
||||
{{ step_description }}
|
||||
```
|
||||
|
||||
I will give you each file that needs to be changed and you will implement changes from the instructions. To do this, you will need to see the currently implemented files so first, filter the files outlined above that are relevant for the instructions. Then, tell me files that you need to see so that you can make appropriate changes to the code. If no files are needed (eg. if you need to create a file), just return an empty array.
|
||||
|
||||
Remember, ask for files relative to the project root. For example, if you need a file with path `{project_root}/models/model.py`, you need to request the file `models/model.py`.
|
||||
@@ -1,5 +1,5 @@
|
||||
Now, we need to verify if this change was successfully implemented. We can do that in 3 ways:
|
||||
1. By writing an automated test or by running a previously written test - this is the preferred way since we can then test if this functionality works in the future. You write automated tests in Jest and you always try finding a way to test a functionality with an automated test. Even if changes seem visual or UI-based, try to find a way to validate them using an automated test, such as verifying HTTP responses or elements rendered on the page.
|
||||
1. By writing an automated test or by running a previously written test - this is the preferred way since we can then test if this functionality works in the future. You write automated tests in Jest and you always try finding a way to test a functionality with an automated test. Even if changes seem visual or UI-based, try to find a way to validate them using an automated test, such as verifying HTTP responses or elements rendered on the page. If you choose this type of test, make sure that you describe it in as much details as needed so that when someone looks at this test can know exactly what needs to be done to implement this automated test.
|
||||
|
||||
2. By running a command (or multiple commands) - this is good for when an automated test is an overkill. For example, if we installed a new package or changed some configuration. Keep in mind that in this case, there shouldn't be any human intervention needed - I will run the commands you will give me and show you the CLI output and from that, you should be able to determine if the test passed or failed.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user