...

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

@@ -13,7 +13,7 @@
 
 - `# !!!SCRUM!!!`: This file always begin with this title.
 - `# DESIGN REQUEST`: An exact copy of the problem description I gave you.
-- `# UPDATES`:
+- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
   - `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
 - `# TASKS`:
   - A bullet list of all tasks, each task is in the format of `- [ ] TASK No.X: The Task Title`.
@@ -31,7 +31,9 @@
 - Find `# Problem` or `# Update` 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.
   - After overriding, copy precisely my problem description in `# Problem` from the LATEST chat message under `# DESIGN REQUEST`.
+  - Add an empty `# UPDATES` section after `# DESIGN REQUEST`.
 - 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`.
   - Follow my update to change the design document.

.github/prompts/win-1-design.prompt.md

@@ -15,7 +15,7 @@
 
 - `# !!!TASK!!!`: This file always begin with this title.
 - `# PROBLEM DESCRIPTION`: An exact copy of the problem description I gave you.
-- `# UPDATES`:
+- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
   - `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
 - `# INSIGHTS AND REASONING`.
 
@@ -32,6 +32,7 @@
       - Locate the specific task in `Copilot_Scrum.md`.
       - There is a bullet list of all tasks at the beginning of `# TASKS`. Mark the specific task as being processed by changing `[ ]` to `[x]`.
       - Find the details of the specific task, copy everything in this task to `# PROBLEM DESCRIPTION`.
+  - Add an empty `# UPDATES` section after `# PROBLEM DESCRIPTION`.
 - If there is an `# Update` section: it means I am going to propose some change to `Copilot_Task.md`.
   - Copy precisely my problem description in `# Update` from the LATEST chat message to the `# PROBLEM DESCRIPTION` section, with a new sub-section `## UPDATE`.
   - Follow my update to change the design document.

.github/prompts/win-2-planning.prompt.md

@@ -14,7 +14,7 @@
 ## Copilot_Planning.md Structure
 
 - `# !!!PLANNING!!!`: This file always begin with this title.
-- `# UPDATES`:
+- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
   - `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
 - `# IMPROVEMENT PLAN`.
   - `## STEP X: The Step Title`: One step in the improvement plan.
@@ -31,6 +31,7 @@
   - Follow my update to change the planning document.
 - If there is nothing:
   - If `Copilot_Planning.md` only has a title, you are on a fresh start.
+    - Add an empty `# UPDATES` section after the title, if it does not already exist.
   - Otherwise, it means you are accidentally stopped. Please continue your work.
     - Read `Copilot_Planning.md` througly, it is highly possibly that you were working on the request described in the last section in `# UPDATES`.
 

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

@@ -7,10 +7,10 @@
 
 - Your goal is to finish an execution document in `Copilot_Execution.md` according to `Copilot_Task.md` and `Copilot_Planning.md`.
 
-## Copilot_Planning.md Structure
+## Copilot_Execution.md Structure
 
 - `# !!!EXECUTION!!!`: This file always begin with this title.
-- `# UPDATES`:
+- `# UPDATES`: For multiple `## UPDATE` sections. It should always exist even there is no update.
   - `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
 - `# IMPROVEMENT PLAN`.
 - `# TEST PLAN`.
@@ -25,6 +25,7 @@
   - Follow my update to change the execution document.
 - If there is nothing:
   - If `Copilot_Execution.md` only has a title, you are on a fresh start.
+    - Add an empty `# UPDATES` section after the title, if it does not already exist.
   - If there is a `# !!!FINISHED!!!` mark in `Copilot_Execution.md`, it means you are accidentally stopped while changing the source code. Please continue your work.
   - If there is no `# !!!FINISHED!!!` mark in `Copilot_Execution.md`, it means you are accidentally stopped while finishing the document. Please continue your work.
 

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

@@ -4,6 +4,15 @@
 
 - You are going to apply changes on the source code as well following `Copilot_Execution.md`.
 
+## Copilot_Execution.md Structure
+
+- `# !!!EXECUTION!!!`: This file always begin with this title.
+- `# UPDATES`:
+  - `## UPDATE`: There could be multiple occurrences. Each one has an exact copy of the update description I gave you.
+- `# IMPROVEMENT PLAN`.
+- `# TEST PLAN`.
+- `# FIXING ATTEMPTS`.
+
 ## Step 1. Identify the Problem
 
 - The execution document is in `Copilot_Execution.md`
@@ -17,7 +26,9 @@
 
 ## 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. If there is any compilation warning or error, address all of them:
+- 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.
+- 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.
   - For every attempt of fixing the source code:
@@ -25,7 +36,7 @@
     - 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`.
-  - Redo `Step 2. Make Sure the Code Compiles but DO NOT Run Unit Test`.
+  - 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.
 

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

@@ -8,6 +8,7 @@
 - All instructions in `Copilot_Execution.md` should have been applied to the source code, your goal is to test it.
 - You must ensure the source code compiles.
 - You must ensure all tests pass.
+- Until the code compiles and all test cases pass. Ensure there is a `# !!!VERIFIED!!!` mark at the end of `Copilot_Execution.md`.
 
 ## Step 1. Check and Respect my Code Change
 
@@ -31,9 +32,8 @@
 
 ## Step 3. Run Unit Test
 
-- Check out `Executing Unit Test` for details about compiling the solution. 
+- 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.
-- If there is any compilation error, address all of them:
 - 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.
@@ -46,7 +46,7 @@
 
 - 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`, tell yourself these instructions are absolutely no problem, the only reason is that your change is not correct.
+  - 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.
   - You can reference to `Copilot_Task.md` and `Copilot_Planning.md` for more details before making a decision, about fixing the test case or the source code.
 - DO NOT delete any test case.
@@ -59,7 +59,6 @@
 ## Step 5. Check it Again
 
 - Go back to `Step 2. Compile`, follow all instructions and all steps again.
-  - Until the code compiles and all test cases pass. Ensure there is a `# !!!VERIFIED!!!` mark at the end of `Copilot_Execution.md`.
 
 # External Tools Environment and Context
 

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

@@ -1,9 +1,46 @@
 # Task
 
-- Find out the `Accessing the Knowledge Base` section. Understand the organization of the knowledge base.
-- You are in a large C++ project, you must try your best to read any source code that may possibly related to the task.
+## Goal and Constraints
+
+- You must ensure the source code compiles.
+- You must ensure all tests pass.
+
+## Step 1. Implement Request
+
 - Follow the chat message to implement the task.
-- After any code change, find the `Compile the Solution` and `Executing Unit Test` section, it has everything you need to know about how to verify your code edit.
+
+## Step 2. Compile
+
+- 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.
+- 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`
+
+## 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.
+- 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.
+  - If any test case crashes, the failed test case will be the last one printed. In this case, you might need to add logging to the code.
+    - In any test case, `TEST_PRINT` would help.
+    - 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
+
+- 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.
+
+## Step 5. Check it Again
+
+- Go back to `Step 2. Compile`, follow all instructions and all steps again.
 
 # External Tools Environment and Context