Improved Planning

core/prompts/partials/project_tasks.prompt

@@ -1,67 +1,26 @@
-Before we go into the coding part, I want you to split the development process of creating this {{ task_type }} into smaller tasks so that it is easier to develop, debug and make the {{ task_type }} work.
+{# This is actually creation of tasks and not epics. Reason why this prompt uses word "epic" instead of "task" is that LLM gives very detailed description and creates very big plan if we ask him to create tasks. When asked to create epics he focuses on much bigger picture and gives high level description which is what we want. #}
+# Rules for creating epics
 
-Each task needs to be related only to the development of this {{ task_type }} and nothing else - once the {{ task_type }} is fully working, that is it. There shouldn't be a task for researching, deployment, writing documentation, testing or anything that is not writing the actual code.
+## Rule #1
+Every epic must have only coding involved. There should never be a epic that is only testing or ensuring something works. There shouldn't be a epic for researching, deployment, writing documentation, testing or anything that is not writing the actual code. Testing if app works will be done as part of each epic.
 
-**IMPORTANT**
-As an experienced tech lead you always follow rules on how to create tasks. Dividing project into tasks is extremely important job and you have to do it very carefully.
+## Rule #2
+This rule applies to epic scope.
+Each epic must be deliverable that can be verified by non technical user. Each epic must have frontend interface, backend implementation, and a way for non technical user to test epic. Do not use words "backend" and "frontend" in epic descriptions. All details mentioned in project description must be fully implemented once all epics are finished.
 
-Now, based on the project details provided{% if task_type  == 'feature' %} and new feature description{% endif %}, think task by task and create the entire development plan{% if task_type  == 'feature' %} for new feature{% elif task_type  == 'app' %}. {% if state.files %}Continue from the existing code listed above{% else %}Start from the project setup{% endif %} and specify each task until the moment when the entire app should be fully working{% if state.files %}. You should not reimplement what's already done - just continue from the implementation already there{% endif %}{% endif %} while strictly following these rules:
+## Rule #3
+This rule applies to the number of epics you will create.
+Every app should have different number of epics depending on complexity. Think epic by epic and create the minimum number of epics that are needed to develop this app.
+Simple apps should have only 1 epic.
+Medium complexity apps should have 2-5 epics.
+Very complex apps should have 4-8 epics.
 
-Rule #1
-There should never be a task that is only testing or ensuring something works, every task must have coding involved. Have this in mind for every task, but it is extremely important for last task of project. Testing if {{ task_type }} works will be done as part of each task.
+## Rule #4
+This rule applies to writing epic 'description'.
+Every epic must have a clear, high level, and short 1 sentence 'description'. It must be very clear so that even non technical users who are reviewing it and just moved to this project can understand what is goal for the epic.
 
-Rule #2
-This rule applies to the complexity of tasks.
-You have to make sure the project is not split into tasks that are too small or simple for no reason but also not too big or complex so that they are hard to develop, debug and review.
-Have in mind that project already has workspace folder created and only system dependencies installed. You don't have to create tasks for that.
-Here are examples of poorly created tasks:
+## Rule #5
+This rule applies to order of epics.
+Epics will be executed in same order that you output them. You must order them in a logical way so that epics that depend on other functionalities are implemented in later stage.
 
-**too simple tasks**
-- Set up a Node.js project and install all necessary dependencies.
-- Establish a MongoDB database connection using Mongoose with the IP '127.0.0.1'.
-
-**too complex tasks**
-- Set up Node.js project with /home, /profile, /register and /login routes that will have user authentication, connection to MongoDB with user schemas, mailing of new users and frontend with nice design.
-
-You must to avoid creating tasks that are too simple or too complex. You have to aim to create tasks that are medium complexity. Here are examples of tasks that are good:
-
-**good tasks**
-- Set up a Node.js project, install all necessary dependencies and set up an express server with a simple route to `/ping` that returns the status 200.
-- Establish a MongoDB database connection and implement the message schema using Mongoose for persistent storage of messages.
-
-Rule #3
-This rule applies to the number of tasks you will create.
-Every {{ task_type }} should have different number of tasks depending on complexity. Think task by task and create the minimum number of tasks that are relevant for this specific {{ task_type }}.
-{% if task_type  == 'feature' %} If the feature is small, it is ok to have only 1 task.{% endif %}
-Here are some examples of apps with different complexity that can give you guidance on how many tasks you should create:
-
-Example #1:
-app description: "I want to create an app that will just say 'Hello World' when I open it on my localhost:3000."
-number of tasks: 1
-
-Example #2:
-app description: "Create a node.js app that enables users to register and log into the app. On frontend it should have /home (shows user data), /register and /login. It should use sessions to keep user logged in."
-number of tasks: 2-4
-
-Example #3:
-app description: "A cool online shoe store, with a sleek look. In terms of data models, there are shoes, categories and user profiles. For web pages: product listing, details, shopping cart. It must look cool and jazzy."
-number of tasks: 5-15
-
-Rule #4
-This rule applies to writing task 'description'.
-Every task must have a clear and very detailed (must be minimum of 4 sentences but can be more) 'description'. It must be very clear so that even developers who just moved to this project can execute them without additional questions. It is not enough to just write something like "Create a route for /home". You have to describe what needs to be done in that route, what data needs to be returned, what should be the status code, etc. Give as many details as possible and make sure no information is missing that could be needed for this task.
-Here is an example of good and bad task description:
-
-**bad task**
-{
-    "description": "Create a route for /dashboard"
-}
-
-**good task**
-{
-    "description": "In 'route.js' add a route for /dashboard that returns the status 200. Route should be accessible only for logged in users. In 'middlewares.js' there should be a check if user is logged in using session. If user is not logged in, it should redirect to /login. If user is logged in, it should return the user data. User data should be fetched from database in 'users' collection using the user id from session."
-}
-
-Rule #5
-When creating and naming new files, ensure the file naming (camelCase, kebab-case, underscore_case, etc) is consistent with the best practices and coding style of the language.
-Pay attention to file paths: if the command or argument is a file or folder from the project, use paths relative to the project root (for example, use `somedir/somefile` instead of `/somedir/somefile`).
+END OF RULES FOR CREATING EPIC

core/prompts/tech-lead/plan.prompt

@@ -21,5 +21,8 @@ Finally, here is the description of new feature that needs to be added to the ap
 {% if epic.complexity and epic.complexity == 'simple' %}
 This is very low complexity {{ task_type }} and because of that, you have to create ONLY one task that is sufficient to fully implement it.
 {% else %}
+Before we go into the coding part, your job is to split the development process of creating this app into smaller epics.
+Now, based on the project details provided{% if task_type  == 'feature' %} and new feature description{% endif %}, think epic by epic and create the entire development plan{% if task_type  == 'feature' %} for new feature{% elif task_type  == 'app' %}. {% if state.files %}Continue from the existing code listed above{% else %}Start from the project setup{% endif %} and specify each epic until the moment when the entire app should be fully working{% if state.files %}. You should not reimplement what's already done - just continue from the implementation already there{% endif %}{% endif %} while strictly following these rules:
+
 {% include "partials/project_tasks.prompt" %}
 {% endif %}

core/prompts/tech-lead/update_plan.prompt

@@ -2,34 +2,35 @@ You are working on an app called "{{ state.branch.project.name }}".
 
 {% include "partials/project_details.prompt" %}
 
-Development plan for that {{ task_type }} was created and the {{ task_type }} was then broken down to smaller tasks so that it's easier for development.
+{# This is actually updating of tasks and not epics. Reason why this prompt uses word "epic" instead of "task" is that LLM gives very detailed description and creates very big plan if we ask him to create tasks. When asked to create epics he focuses on much bigger picture and gives high level description which is what we want. #}
+Development plan for that {{ task_type }} was created and the {{ task_type }} was then broken down to smaller epics so that it's easier for development.
 
-Here are tasks that are finished so far:
+Here are epic that are finished so far:
 ```
 {% for task in finished_tasks %}
-- Task #{{ loop.index }}
-Description: {{ task }}
+- Epic #{{ loop.index }}
+Description: {{ task.description }}
 
 {% endfor %}
 ```
 
-Here are tasks that still have to be implemented:
+Here are epics that still have to be implemented:
 ```
 {% for task in state.unfinished_tasks %}
-- Task #{{ finished_tasks|length + loop.index }}
-Description: {{ task }}
+- Epic #{{ finished_tasks|length + loop.index }}
+Description: {{ task.description }}
 
 {% endfor %}
 ```
 
 {% if finished_tasks %}
-This is the last task you were working on:
+This is the last epic you were working on:
 ```
 {{ finished_tasks[-1].description }}
 ```
 {% endif %}
 
-While working on that last task, you were iterating based on user feedbacks for this {{ task_type }}. Here is list of all iterations:
+While working on that last epic, you were iterating based on user feedbacks for this {{ task_type }}. Here is list of all iterations:
 ```
 {% for iteration in state.iterations %}
 - Iteration #{{ loop.index }}:
@@ -40,20 +41,21 @@ Developer solution: {{ iteration.description }}
 ```
 
 {% if modified_files|length > 0 %}
-Here are files that were modified during this task implementation:
+Here are files that were modified during this epic implementation:
 ---start_of_current_files---
 {% for file in modified_files %}
 **{{ file.path }}** ({{ file.content.content.splitlines()|length }} lines of code):
 ```
-{{ file.content }}
+{{ file.content.content }}
 ```
 {% endfor %}
 ---end_of_current_files---
 {% endif %}
 
+{% include "partials/project_tasks.prompt" %}
 
-You need to think step by step what was done in last task and update development plan if needed. All iterations that were mentioned were executed and finished successfully and that needs to be reflected in updated development plan.
+You need to think step by step what was done in last epic and update development plan if needed. All iterations that were mentioned were executed and finished successfully and that needs to be reflected in updated development plan.
 As output you have to give 2 things:
-1. Reword/update current task, "updated_current_task", if needed, based on what is implemented so far. Consider current task description, all iterations that were implemented during this task and all changes that were made to the code.
+1. Reword/update current epic, "updated_current_task", ONLY IF NECESSARY, based on what is implemented so far. Consider current epic description, all iterations that were implemented during this epic and all changes that were made to the code.
 
-2. Give me updated list of tasks that still have to be implemented. Take into consideration all tasks in current development plan, previous tasks that were finished and everything that was implemented in this task. There should be minimum possible number of tasks that still have to be executed to finish the app. You must list only tasks that need implementation and were not done in scope of previous tasks or during iterations on current task. Do not create new tasks, only remove tasks from list of tasks that still have to be implemented in case they were implemented during current task.
+2. Give me updated list of epics that still have to be implemented. Take into consideration all epics in current development plan, previous epics that were finished and everything that was implemented in this epic. There should be minimum possible number of epics that still have to be executed to finish the app. You must list only epics that need implementation and were not done in scope of previous epics or during iterations on current epic. Do not create new epics, only remove epics from list of epics that still have to be implemented in case they were implemented during current epic.