diff --git a/.github/Guidelines/SourceFileManagement.md b/.github/Guidelines/SourceFileManagement.md
index cf123cfa..520c085b 100644
--- a/.github/Guidelines/SourceFileManagement.md
+++ b/.github/Guidelines/SourceFileManagement.md
@@ -15,6 +15,27 @@
 
 - All affected `*.vcxitems`, `*.vcxproj`, `*.vcxitems.filters` and `*.vcxproj.filters` must be updated.
 
+## Adding new C++ Project
+
+- There are two kinds of projects: `*.vcxproj` and `*.vcxitems`.
+  - Usually `*.vcxproj` comes with a `*.vcxproj.filters` because solution explorer organization of source files are always needed.
+  - Usually `*.vcxitems` does not come with a `*.vcxitems.filters` because all files are just listed below the project in the solution explorer.
+- When adding a new project, find a existing project to copy.
+- For a typical `*.vcxproj` project, there will always be solution explorer folders `Header Files`, `Resource Files` and `Source Files`.
+  - `Header Files` and `Resource Files` should be kept during copy even when there will be no files adding to them.
+  - `Header Files` is never used, all source files, including header files, should be in `Source Files` or custom created folders.
+  - If all options are correctly copied from another `*.vcxproj` files, it should be good but you still need to make sure that:
+    - `Debug` and `Release` are always needed.
+    - `Win32` and `x64` are always needed.
+    - All configuration should define `VCZH_DEBUG_NO_REFLECTION` macro, unless there is special requirement to enable C++ reflection.
+    - All `Debug` configuration should define `VCZH_CHECK_MEMORY_LEAKS`.
+- When `*.vcxproj` is added to the solution, you need to build the solution against all configuration to make sure everything works:
+  - `Debug` and `Release`.
+  - `Win32` and `x64`.
+  - Even if you find any pre-existing issues, you should fix them.
+  - You can skip the test, as adding new project should not affect test cases, unless existing projects are modified as part of the refactoring.
+- Only add the `/bigobj` compiler option to a `*.cpp` file when needed.
+
 ## Working on Linux
 
 `makefile` for each project is generated from MSBuild project files during the build.
diff --git a/.github/prompts/investigate.prompt.md b/.github/prompts/investigate.prompt.md
index adee448a..adc1f775 100644
--- a/.github/prompts/investigate.prompt.md
+++ b/.github/prompts/investigate.prompt.md
@@ -188,3 +188,11 @@ Propose any solution you can think of and write them down in the document, you m
   - When different `## Task X` happens in different repos, you are going to change the `Copilot_Investigate.md` in that repo.
     - If multiple repos are involved, for all involved repos that has the `Copilot_Investigate.md` file, decide which repo is the main repo for the task and update that file in the main repo.
     - If the repo does not have such document, you are allowed not to create one, skip writing such file.
+- When `git push` is blocked because of needing to merge, you are allowed to rebase by yourself:
+  - Always rebase to the latest change of the remote branch, instead of making a rebase commit.
+  - Usually there is only documentation or instruction changes. In this case, you can rebase and skip the testing.
+  - When there is code conflict, you are required to rebase all local changes first (when multiple commits are created for one task), and redo the testing process.
+  - There are two kinds of source code:
+    - Code files for manual editing, you need to carefully resolve all conflicts.
+    - Code files that is auto generated, you can just accept the remote change, and redo the testing process to regenerate these file and ensure all test cases passed. `git commit` all local changes during the process.
+  - After the rebase is done and all test cases passed, `git push` it again.