最近終於從孤獨的開發者轉到多人協作開發同一個 git repository 的工作環境中。於是開始想辦法把自己的舒適圈擴大到這個環境裡面。
最近想將 VSCode copilot 的 instructions 資料夾移動到外面。主要有幾個目的：
- 方便管理，我可以將 instructions 資料夾作一個 git 管理，一次變更多處同步。
- 基於各種原因，我不想將 git 中 .github/instructions 推進 git 版控中。
第二點原因有很多種，例如協作環境中，大家負責的項目不同，可能需要的規範/指南也不一樣。或是大家都 commit 自己的指南，容易衝突或是可能因為嘗試的狀態下，容易產生大量的變更，造成無關的 pr 的困擾（還需要整理有點累）。基於與一般協作管理 instructions 剛好相反的需求之下，也有一些既有限制：
- git repo 內的環境設定相關檔案儘量不要動到
- .github 已經在版控裡面了（不想把檔案更新上 git)
如果你也剛好有一樣的狀況，那麼恭喜，接下來設定很適合你。
如果你不知道 instructions 是什麼，可以先看這篇。簡單來說他是 AI 工具之一，他有提供使用 instructions 來作為提示詞的規範指南，可以參考這裡介紹。其中介紹中有說到的重點節錄如下：
VS Code 支援多種基於 Markdown 的指令檔。如果您的專案中存在多種類型的指令文件，VS Code 會將它們合併並添加到聊天上下文中，但不會保證特定的順序。
- 單一
.github/copilot-instructions.md文件- 自動套用於工作區中的所有聊天請求。
- 儲存在工作區中
- 一個或多個
.instructions.md文件- 為特定任務或文件而創建
- 使用
a pplyTofrontmatter 定義指令應應用於哪些檔案。 - 儲存在工作區或使用者設定檔中
- 單一
AGENTS.md文件（實驗性）- 如果您在工作空間中使用多個 AI 代理，這將非常有用。
- 自動套用於工作區中的所有聊天請求。
- 儲存在工作區的根目錄中。
指令之間的空格將被忽略，因此指令可以寫成一個段落，每條指令另起一行，或者為了方便閱讀，可以用空行分隔。
要在說明中引用特定上下文（例如文件或 URL），可以使用 Markdown 連結。
今天我們針對的就是第 1 點和第 2 點操作。
先講注意事項：
- instructions 不是越多越好，請建立分類放好，不同工作區引用適合的 instructions 檔案。
- 善用 applyTo 和 description 屬性，如果你不知道是啥，請參考這裡。
- instructions 需要定期維護，自己更板不知道幾次了，這也是需要統一管理的好理由。
- 指定路徑我是設定為絕對路徑，但這不利於同步使用者設定，所以如果你有多台電腦就要個別處理或想辦法整包同步的。
- 我測試過在 .vscode/settings.json 裡面設定，沒理我。可能是因為 .code-workspace 放在別的路徑的關係。
好，操作開始：
首先，有一個從個人設定檔著手的方式，這目的是把他寫在個人設定之中。
請搜尋「chat.instructionsFilesLocations」設定，於「使用者」的 tab 中，把路徑複製打上去即可。
如果你不想讓整個使用者都用同樣的指南，畢竟有時要跑不同語言、不同專案，光是 README 就會用到不同屬性或樣板的指引。可以把設定改到「工作區」的 tab 中，分不同工作區當作不同專案使用即可。
除了這個設定之外，也有其他設定可以參考這裡。
另外有一個 .github/copilot-instructions.md 文件，他可以透過 vscode 自動解析專案生成（介紹），如果用 copilot 操作 AI Agent 時，強烈推薦可以先生成一個跑 agent 會稍微比較聰明一些。分類上我認為這個檔案會比較像是 for 專案用途，不太需要共用，建議可以建立工作區之後建立一個 .github 資料夾把他放進去。
如果不想要和目前 git 版控牽扯的話，建議可以把 repo 放到一個資料夾中，再外面資料夾把 .github/copilot-instructions.md 建好（甚至 .vscode 設定也行），要注意的是會有覆蓋的問題，我理解的是原則上覆蓋都會是由最近的資料夾設定優先，可以想像是 js 中 closest 方法的操作邏輯。結構大概會長這樣，這是目前 git-auto-push 這個自動化工具的專案目錄：
執行更新 README 指令會得到以下參考。參考的規範指南部分是我的另外一個 repo 內容。
紅色是把檔案路經遮起來，提醒一下檔案路徑儘量還是不要暴露出來比較保險。如果有看到也互相提醒一下比較好，資訊安全人人有責。
最後提醒一下，如果使用 sepc-kit 或 krio 作 SDD 的朋友，可能外層蓋一個資料夾的方式就不太可行，意味著 spec-kit 產生的 sh 或 py 檔案等要避開 git 版控又不動到 .gitignore 設定的機會滿小的，我個人目前偏向自己作一個 SDD 的工作流或是改現成的 SDD 陣法，畢竟魔法就是探索的過程中才有趣（中二），之後有遇到再說。
