From ae9a26d11e973c602df84c8612ef646505ee3931 Mon Sep 17 00:00:00 2001 From: vczh Date: Wed, 12 Nov 2025 23:52:00 -0800 Subject: [PATCH] ... --- .github/prompts/win-0-scrum.prompt.md | 26 +++++++++---------- .github/prompts/win-3-summarizing.prompt.md | 14 ++++++++--- .github/prompts/win-4-execution.prompt.md | 23 ++++++++++++++++- .github/prompts/win-5-verifying.prompt.md | 28 ++++++++++++++++++--- .github/prompts/win-code.prompt.md | 28 ++++++++++++++++++--- 5 files changed, 95 insertions(+), 24 deletions(-) diff --git a/.github/prompts/win-0-scrum.prompt.md b/.github/prompts/win-0-scrum.prompt.md index a46a7fcf..f52e6494 100644 --- a/.github/prompts/win-0-scrum.prompt.md +++ b/.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. diff --git a/.github/prompts/win-3-summarizing.prompt.md b/.github/prompts/win-3-summarizing.prompt.md index d6a1b6d5..41a9d734 100644 --- a/.github/prompts/win-3-summarizing.prompt.md +++ b/.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. diff --git a/.github/prompts/win-4-execution.prompt.md b/.github/prompts/win-4-execution.prompt.md index 8d6dc504..cabef038 100644 --- a/.github/prompts/win-4-execution.prompt.md +++ b/.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.` 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. diff --git a/.github/prompts/win-5-verifying.prompt.md b/.github/prompts/win-5-verifying.prompt.md index a17af03c..b0115ace 100644 --- a/.github/prompts/win-5-verifying.prompt.md +++ b/.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.` 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.` 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. diff --git a/.github/prompts/win-code.prompt.md b/.github/prompts/win-code.prompt.md index b3b7fdab..b95b8eed 100644 --- a/.github/prompts/win-code.prompt.md +++ b/.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.