Sync Copilot agent instructions

2026-08-17 17:31:44 +08:00 · 2026-07-04 19:11:15 -07:00
parent bc6afa3a40
commit 860a9ffefe
6 changed files with 178 additions and 16 deletions
@@ -4,6 +4,13 @@
 - Go to `Linux Specific` section if you are on Linux.
 - Go to `macOS Specific` section if you are on macOS.

+When the model `gpt-5.3-codex-spark` is available:
+- If multiple steps need to be done to operate the GUI:
+  - Summarize what to look for and what to do.
+  - Start a sub agent with this model to perform all GUI operations.
+  - If the target application has bugs, it is normal that steps can't be performed to the end. The sub agent should summarize what is going wrong to prevent steps to be done.
+  - This model is fast, it significantly improves the performance of operating the GUI.
+
 ## Windows Specific

 - You are strongly recommended to attach a debugger when running any GacUI application.
@@ -47,6 +47,12 @@ I am starting a fresh new request.
  - If the problem description consists of multiple `## Task N` or `## Task TITLE`:
    - You should strictly follow `## Git Commits and Multi-Task Request`.
    - For each `## Task X`, perform the work, git commit and push, before starting the next `## Task X`.
+- If there is an `## REVIEW COMMENTS` section in the request:
+  - This section must be copied along with the problem description.
+  - Answers to these review comments are my direct input, they are very important.
+  - Some review comments may be tagged with `[CLOSED]`:
+    - DO NOT include the tag in the problem description.
+    - All comments and answers are equally important, no matter if the review comment is closed or not.
 - Jump to `Step 2` directly.

 ### Continue Investigation (only when "# Continue" appears in the LATEST chat message)
@@ -0,0 +1,38 @@
+# Knowledge Base Refine
+
+- Check out `Accessing Task Documents`, `(Windows Specific) Accessing Script Files`, and `(Linux Specific) Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
+- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
+  - The `Copilot_KB.md` file should already exist, it may or may not contain content from the last knowledge base writing.
+  - If you cannot find the file, you are looking at a wrong folder.
+- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find the knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
+  - `Index.md` below means the main entry file.
+  - `Index_<PROJECT>.md` below means the project-specific guidance file linked from the corresponding project section in `Index.md`.
+
+## Goal and Constraints
+
+- Your goal is to update any knowledge base pages that fall behind the current code base.
+- You are only allowed to update `Index_<PROJECT>.md` and pages referenced by it for the current repo.
+- You are not allowed to modify any other files.
+- Code references must be wrapped in either `single-line` or ```multi-line``` quotes.
+
+## Identify Changes
+
+You need to identify source changes in both the following two ways, in order to come up with a complete list of changes that need to be reflected in the knowledge base:
+- Go through all files in `REPO-ROOT/.github/Learning/**/*.md`:
+  - These files recorded what has been done in recent changes.
+- Go through all knowledge base pages referenced by `Index_<PROJECT>.md`:
+  - These files are potential candidates for updates, by go through all of them you can compare details with the source code, and find out what as been changed without putting into the the knowledge base.
+
+## Limit Scope of Changing
+
+- When a knowledge base page enumerates a list of something, like sub classes for a type, enum items, overloaded functions, options, etc:
+  - You need to delete any items that are no longer exist.
+  - You need to add any items that are not in the knowledge base.
+  - You need to update any items that have been changed.
+- Otherwise, when there is a complete new feature or topic that is not in the knowledge base:
+  - Ignore them, we only update existing knowledges, we do not add new stuff.
+- This instruction is supposed to be executed very frequently, so most of the time you will find that nothing needs to update, this is completely normal.
+
+## Updating Knowledge Base
+
+- You need to update the knowledge base pages according to the changes you identified in the previous step.
@@ -0,0 +1,71 @@
+# Review Task for Investigation
+
+- Check out `Accessing Task Documents`, `(Windows Specific) Accessing Script Files`, and `(Linux Specific) Accessing Script Files` in `REPO-ROOT/.github/copilot-instructions.md` for context about mentioned `*.md`, `*.ps1` and `*.sh` files.
+- All `*.md`, `*.ps1` and `*.sh` files should exist; you should not create any new files unless explicitly instructed.
+- Following `Leveraging the Knowledge Base` in `REPO-ROOT/.github/copilot-instructions.md`, find the knowledge and documents for this project in `REPO-ROOT/.github/KnowledgeBase/Index.md`.
+
+## Goal and Constraints
+
+- Your goal is to review a task about to be investigated.
+  - The task will be in a tagged file,
+  - You are going to change this file and put additional review comments in it.
+- You are not allowed to modify any source code, unless directly instructed in answers to review comments.
+- You are not going to execute the task, you are just reviewing it.
+
+## Identify the Task File
+
+- The task file will be tagged in the LATEST chat message.
+
+## Format of Review Comments
+
+- Every review comment should have its own section, like:
+```
+## REVIEW COMMENTS
+
+### SHORT DESCRIPTION
+
+**review comment**: the first round of the review comment
+
+I will put my reply here
+
+**review comment**: the second round of the review comment
+
+I will put my reply here
+
+...
+
+### ANOTHER REVIEW COMMENT
+
+...
+```
+
+## Response to my Replies
+
+- Find `## REVIEW COMMENTS` 
+  - If you cant find this section, it means no review has been performed yet, skip this step.
+- Read all replies to the review comments which are not tagged with `[CLOSED]`. There will be basically two categories:
+  - I agree with your comment, which points out that something is wrong, and I instructed you to change in the reply:
+    - Delete that specific comment section.
+    - Update the content of the task file or source code accordingly.
+      - Such code changes are usually interfaces or declarations to be implemented.
+      - No need to do building or testing, if the code does not compile, it is fine, as all following work will be done when executing the task.
+  - I agree with your comment, which points out missing details in the task. Or I disagree with your comment. Or I provide detailed explanation:
+    - If you agree with my reply:
+      - Keep the comment and the reply, as this will be taken as important hints when executing the task.
+      - Append `[CLOSED]` after the specific comment section, so you don't need to process them the next time.
+    - If you have further comments:
+      - Put new comments.
+      - DO NOT tag it with `[CLOSED]`.
+
+## Review the Task
+
+- If there is no `## REVIEW COMMENTS` section, add it to the very last of the file.
+- All new review comments should be added under this section, to the very last of the file:
+- You are going to review the task and figure out if:
+  - There is any ambiguity or conflict in the task.
+  - There is anything unreasonable, it includes but not limited to:
+    - Interface to be implemented does not make sense, such interface could be in the task file or in the source code.
+    - Potential error handling issues.
+    - Potential synchronization and multi-threading issues.
+    - Potential performance issues.
+- Take into accounts of my replies to all review comments.