...

.github/prompts/win-0-scrum.prompt.md

@@ -28,7 +28,7 @@
 ## Step 1. Identify the Problem
 
 - The problem I would like to solve is in the chat messages sending with this request.
-- Find `# Problem` or `# Update` in the LATEST chat message. Ignore any `# Problem` or `# Update` in the chat history.
+- Find `# Problem` or `# Update` or `# Learn` in the LATEST chat message. Ignore any `# Problem` or `# Update` in the chat history.
 - If there is a `# Problem` section: it means I am starting a fresh new request.
   - You should override `Copilot_Scrum.md` with only one title `# !!!SCRUM!!!`.
     - At the moment, `Copilot_Scrum.md` may contain old tasks from previous requests, even it may look like the document is already finished for the current scrum, always clean it up.
@@ -37,9 +37,11 @@
 - If there is an `# Update` section: it means I am going to propose some change to `Copilot_Scrum.md`.
   - Copy precisely my problem description in `# Update` from the LATEST chat message to the `# DESIGN REQUEST` section, with a new sub-section `## UPDATE`.
   - The new `## UPDATE` should be appended to the end of the existing `# UPDATES` section (aka before `# TASKS`).
+  - When the number of tasks needs to be changed, due to inserting/removing/splitting/merging tasks:
+    - Adjust task number of unaffected tasks accordingly, throughout the document.
+    - Replace the affected tasks with new content, DO NOT TOUCH unaffected tasks.
   - Follow my update to change the design document.
-  - Find the `(Optional) Step 5. Verify the Document` section to verify the whole document after applying the update.
-- If there is a `# Learn` section: it means I made important updates during the execution of the last task, you should apply them smart enough to future tasks. Find the `(Optional) Step 7. Learning` section for more instruction.
+- If there is a `# Learn` section: it means I made important updates during the execution of the last task, you should apply them smart enough to future tasks. Find the `Optional Step for Learning` section for more instruction.
 - If there is nothing: it means you are accidentally stopped. Please continue your work.
 
 ## Step 2. Understand the Goal and Quality Requirement
@@ -82,22 +84,20 @@
   - Keep the knowledge base to only guidelines and design insights will have you find correct piece of code to read.
 - It is fine that you find nothing to change or add to the knowledge base.
 
-## (Optional) Step 5. Verify the Document (only when # Update appears in the LATEST chat message)
-
-- Verify the content of the whole document again. Make sure when you changing, adding, removing, splitting tasks content being replaced are removed properly.
-
-## Step 6. Mark the Completion
+## Step 5. Mark the Completion
 
 - Ensure there is a `# !!!FINISHED!!!` mark at the end of `Copilot_Scrum.md` to indicate the document reaches the end.
 
-## (Optional) Step 7. Learning (only when # Learn appears in the LATEST chat message)
+## (Optional) Step 6. Learning (only when # Learn appears in the LATEST chat message)
+
 - Ignore this section if there is no `# Learn` in the LATEST chat message
 
-### Step 7.1
+### Step 6.1
 
 - Identify the last completed task.
 
-### Step 7.2
+### Step 6.2
+
 - Read through `Copilot_Execution.md`. There may be some fixing attempts, that were done by you.
 - Compare existing source code with `Copilot_Execution.md`, finding what is changed.
   - During comparing, you need to take into consideration of the fixing attempts, as sometimes you didn't update the main content of the document.
@@ -113,14 +113,14 @@
 - Add your finding to `Copilot_Execution.md` at the very end with the topic `# Comparing to User Edit`.
   - If every changes are ignored by the rule above, or if you can't find any user edit, just write `No user edit found`.
 
-### Step 7.3
+### Step 6.3
 
 - There will be multiple `# UPDATES` or `# FIXING ATTEMPTS` or `# Comparing to User Edit` sections in `Copilot_Task.md`, `Copilot_Planning.md` and `Copilot_Execution.md`.
 - These 3 files recorded how you interpreted the last completed task, and how I wanted you to adjust  your understanding.
 - Find out what you can learn from the updates, about my philosophy and preferences.
 - Check all future tasks, apply what you have learned, and adjust your approach accordingly.
 
-### Step 7.4
+### Step 6.4
 
 - Find and execute `copilotPrepare.ps1 -Backup`. You MUST use the `-Backup` parameter.
 

.github/prompts/win-3-summarizing.prompt.md

@@ -46,13 +46,19 @@
     - Remove only the explanatory text between code blocks
     - Keep ALL actual code
   - DO NOT copy `# UPDATES` from `Copilot_Planning.md` to `Copilot_Execution.md`. The `# UPDATES` in `Copilot_Execution.md` is for update requests for `Copilot_Execution.md` and the actual source code.
+  - In each code change, ensure the context information is complete:
+    - Which file to edit?
+    - Insert/Delete/Update which part of the file? Is it better to define "which part" by line number or surrounding code?
+    - The code block to be written to the file.
+    - In `Copilot_Planning.md`, the code block might be incomplete or containing above metadata, do not update `Copilot_Planning.md` but instead fix them in `Copilot_Execution.md` following the rule:
+      - Each code block only contain consecutive code to be written to the file.
+      - If the original code block contains metadata, do not include it.
+      - If the original code block contains code change in multiple places or even multiple files, split it.
 
 ## Step 3. Document Quality Check List
 
-- [ ] Can someone copy-paste ONLY from Execution.md and apply all changes? (No need to refer to Planning.md)
-- [ ] Does every STEP show the complete code to write, not just describe it?
-- [ ] Is there any phrase like "including:", "such as:", "etc.", "refer to"? (If yes, you did it wrong!)
-- [ ] Count lines of code in Planning.md STEP X vs Execution.md STEP X - are they similar?
+- Is `Copilot_Execution.md` contains enough information so that one can follow the document to make actual code change, without having to refer to `Copilot_Planning.md`?
+- Is `Copilot_Execution.md` include all code changes mentioned in `Copilot_Planning.md`?
 
 ## Step 4. Completion
 - Ensure there is a `# !!!FINISHED!!!` mark at the end of `Copilot_Execution.md` to indicate the document reaches the end.

.github/prompts/win-4-execution.prompt.md

@@ -22,14 +22,27 @@
   - Follow my update to change the execution document and the source code.
 - If there is nothing:
   - Apply all code changes in `Copilot_Execution.md` to the source code.
+    - Make sure indentation and line breaks are applied correctly, following the same style in the target file.
   - After applying each step in `Copilot_Execution.md`, mark the step as completed by appending `[DONE]` after the step title. This allow you to find where you are if you are interrupted.
 
 ## Step 2. Make Sure the Code Compiles but DO NOT Run Unit Test
 
 - Check out `Compile the Solution` for details about compiling the solution but DO NOT run unit test.
   - `Compile the Solution` is the only way to build the project. DO NOT call any other tools or scripts.
+  - Each attempt of build-fix process should be executed in a sub agent.
+    - One build-fix process includes one attempt following `Build Unit Test` and `Fix Compile Errors`.
+    - The main agent should call different sub agent for each build-fix process.
+    - Do not build and retrieve build results in the main agent.
+
+### Use a sub agent to run the following instructions (`Build Unit Test` and `Fix Compile Errors`)
+
+#### Build Unit Test
+
 - Find out if there is any warning or error.
   - `Compile the Solution` has the instruction about how to check compile result.
+
+#### Fix Compile Errors
+
 - If there is any compilation error, address all of them:
   - If there is any compile warning, only fix warnings that caused by your code change. Do no fix any other warnings.
   - If there is any compile error, you need to carefully identify, is the issue in the callee side or the caller side. Check out similar code before making a decision.
@@ -38,10 +51,18 @@
     - Explain what you need to do.
     - Explain why you think it would solve the build break.
     - Log these in `Copilot_Execution.md`, with section `## Fixing attempt No.<attempt_number>` in `# FIXING ATTEMPTS`.
-  - Go back to `Step 2. Make Sure the Code Compiles but DO NOT Run Unit Test`.
+- After finishing fixing, exit and tell the main agent to go back to `Step 2. Make Sure the Code Compiles but DO NOT Run Unit Test`.
 - When the code compiles:
   - DO NOT run any tests, the code will be verified in future tasks.
 
+# Step 3. Verify Coding Style
+
+- Code changes in `Copilot_Execution.md` may not consider about indentation and coding style.
+  - Go over each code change and ensure:
+    - Indentation is correct and consistent with the surrounding code.
+    - Coding style especially line breaks follows the same conventions as the surrounding code.
+- Ensure any empty line does not contain spaces or tabs.
+
 # External Tools Environment and Context
 
 - You are on Windows running in Visual Studio Code.

.github/prompts/win-5-verifying.prompt.md

@@ -20,8 +20,20 @@
 
 - Check out `Compile the Solution` for details about compiling the solution but DO NOT run unit test yet.
   - `Compile the Solution` is the only way to build the project. DO NOT call any other tools or scripts.
+  - Each attempt of build-fix process should be executed in a sub agent.
+    - One build-fix process includes one attempt following `Build Unit Test` and `Fix Compile Errors`.
+    - The main agent should call different sub agent for each build-fix process.
+    - Do not build and retrieve build results in the main agent.
+
+### Use a sub agent to run the following instructions (`Build Unit Test` and `Fix Compile Errors`)
+
+#### Build Unit Test
+
 - Find out if there is any warning or error.
   - `Compile the Solution` has the instruction about how to check compile result.
+
+#### Fix Compile Errors
+
 - If there is any compilation error, address all of them:
   - If there is any compile warning, only fix warnings that caused by your code change. Do no fix any other warnings.
   - If there is any compile error, you need to carefully identify, is the issue in the callee side or the caller side. Check out similar code before making a decision.
@@ -30,12 +42,21 @@
     - Explain what you need to do.
     - Explain why you think it would solve the build break or test break.
     - Log these in `Copilot_Execution.md`, with section `## Fixing attempt No.<attempt_number>` in `# FIXING ATTEMPTS`.
-  - Go back to `Step 2. Compile`
+- After finishing fixing, exit and tell the main agent to go back to `Step 2. Compile`
 
 ## Step 3. Run Unit Test
 
 - Check out `Executing Unit Test` for details about running unit test projects.
   - `Executing Unit Test` is the only way to run the unit test. DO NOT call any other tools or scripts.
+  - Each attempt of test-fix process should be executed in a sub agent.
+    - One test-fix process includes one attempt following `Execute Unit Test` and `Fix Failed Test Cases`.
+    - The main agent should call different sub agent for each test-fix process.
+    - Do not test and retrieve test results in the main agent.
+
+### Use a sub agent to run the following instructions (`Execute Unit Test` and `Fix Failed Test Cases`)
+
+#### Execute Unit Test
+
 - Run the unit test and see if they passed. If anything is good, you will only see test files and test cases that are executed.
   - Make sure added test cases are actually executed.
   - If any test case fails on a test assertion, the content of `TEST_ASSERT` or other macros will be printed to the output.
@@ -44,7 +65,7 @@
     - In other source code, `vl::console::Console::WriteLine` would help. In `Vlpp` project, you should `#include` `Console.h`. In other projects, the `Console` class should just be available.
     - When added logging are not longer necessary, you should remove all of them.
 
-## Step 4. Fix Failed Test Cases
+#### Fix Failed Test Cases
 
 - If there are failed test cases, fix the code to make it work.
   - If your change did not change the test result, make sure you followed `Step 2. Compile` to compile the code.
@@ -57,8 +78,9 @@
   - Explain what you need to do.
   - Explain why you think it would solve the build break or test break.
   - Log these in `Copilot_Execution.md`, with section `## Fixing attempt No.<attempt_number>` in `# FIXING ATTEMPTS`.
+- After finishing fixing, exit and tell the main agent to go back to `Step 2. Compile`
 
-## Step 5. Check it Again
+## Step 4. Check it Again
 
 - Go back to `Step 2. Compile`, follow all instructions and all steps again.
 

.github/prompts/win-code.prompt.md

@@ -13,17 +13,38 @@
 
 - Check out `Compile the Solution` for details about compiling the solution but DO NOT run unit test yet.
   - `Compile the Solution` is the only way to build the project. DO NOT call any other tools or scripts.
+  - Each attempt of build-fix process should be executed in a sub agent.
+    - One build-fix process includes one attempt following `Build Unit Test` and `Fix Compile Errors`.
+    - The main agent should call different sub agent for each build-fix process.
+    - Do not build and retrieve build results in the main agent.
+
+### Use a sub agent to run the following instructions (`Build Unit Test` and `Fix Compile Errors`)
+
+#### Build Unit Test
+
 - Find out if there is any warning or error.
   - `Compile the Solution` has the instruction about how to check compile result.
+
+#### Fix Compile Errors
+
 - If there is any compilation error, address all of them:
   - If there is any compile warning, only fix warnings that caused by your code change. Do no fix any other warnings.
   - If there is any compile error, you need to carefully identify, is the issue in the callee side or the caller side. Check out similar code before making a decision.
-  - Go back to `Step 2. Compile`
+- After finishing fixing, exit and tell the main agent to go back to `Step 2. Compile`
 
 ## Step 3. Run Unit Test
 
 - Check out `Executing Unit Test` for details about running unit test projects.
   - `Executing Unit Test` is the only way to run the unit test. DO NOT call any other tools or scripts.
+  - Each attempt of test-fix process should be executed in a sub agent.
+    - One test-fix process includes one attempt following `Execute Unit Test` and `Fix Failed Test Cases`.
+    - The main agent should call different sub agent for each test-fix process.
+    - Do not test and retrieve test results in the main agent.
+
+### Use a sub agent to run the following instructions (`Execute Unit Test` and `Fix Failed Test Cases`)
+
+#### Execute Unit Test
+
 - Run the unit test and see if they passed. If anything is good, you will only see test files and test cases that are executed.
   - Make sure added test cases are actually executed.
   - If any test case fails on a test assertion, the content of `TEST_ASSERT` or other macros will be printed to the output.
@@ -32,15 +53,16 @@
     - In other source code, `vl::console::Console::WriteLine` would help. In `Vlpp` project, you should `#include` `Console.h`. In other projects, the `Console` class should just be available.
     - When added logging are not longer necessary, you should remove all of them.
 
-## Step 4. Fix Failed Test Cases
+#### Fix Failed Test Cases
 
 - If there are failed test cases, fix the code to make it work.
   - If your change did not change the test result, make sure you followed `Step 2. Compile` to compile the code.
   - If the test result still not changed after redoing `Step 2. Compile` and `Step 3. Run Unit Test`, these two steps are absolutely no problem, the only reason is that your change is not correct.
 - You must carefully identify, if the cause is in the source code or in the failed test. In most of the cases, the cause is in the source code.
 - DO NOT delete any test case.
+- After finishing fixing, exit and tell the main agent to go back to `Step 2. Compile`
 
-## Step 5. Check it Again
+## Step 4. Check it Again
 
 - Go back to `Step 2. Compile`, follow all instructions and all steps again.