copilot-instructions-blueprint-generator

Name: copilot-instructions-blueprint-generator
Author: github

Copilot Instructions 藍圖產生器

設定變數

${PROJECT_TYPE="自動偵測|.NET|Java|JavaScript|TypeScript|React|Angular|Python|多種|其他"} 
${ARCHITECTURE_STYLE="分層式|微服務|單體式|領域驅動|事件驅動|無伺服器|混合式"} 
${CODE_QUALITY_FOCUS="可維護性|效能|安全性|無障礙性|可測試性|全部"} 
${DOCUMENTATION_LEVEL="最少|標準|全面"} 
${TESTING_REQUIREMENTS="單元測試|整合測試|端到端測試|TDD|BDD|全部"} 
${VERSIONING="語意化版本|日曆版本|自訂"}

產生的提示

"產生一份全面的 copilot-instructions.md 檔案，引導 GitHub Copilot 產生符合專案標準、架構及技術版本的程式碼。指示必須嚴格基於程式碼庫中的實際程式碼模式，避免任何假設。請遵循以下方式：

1. 核心指示結構

# GitHub Copilot Instructions

## 優先順序指南

為此儲存庫產生程式碼時：

1. **版本相容性**：始終偵測並尊重此專案中使用的語言、框架及函式庫的確切版本
2. **上下文檔案**：優先採用 .github/copilot 目錄中定義的模式與標準
3. **程式碼庫模式**：當上下文檔案未提供具體指引時，掃描程式碼庫以尋找既有模式
4. **架構一致性**：維持我們的 ${ARCHITECTURE_STYLE} 架構風格及既有的邊界
5. **程式碼品質**：在所有產生的程式碼中優先考量 ${CODE_QUALITY_FOCUS == "全部" ? "可維護性、效能、安全性、無障礙性及可測試性" : CODE_QUALITY_FOCUS}

## 技術版本偵測

在產生程式碼之前，掃描程式碼庫以識別：

1. **語言版本**：偵測使用中的程式語言確切版本
   - 檢查專案檔案、設定檔及套件管理工具
   - 尋找語言特定的版本指示器（例如 .NET 專案中的 <LangVersion>）
   - 絕不使用超出偵測版本的語言功能

2. **框架版本**：識別所有框架的確切版本
   - 檢查 package.json、.csproj、pom.xml、requirements.txt 等
   - 產生程式碼時尊重版本限制
   - 絕不建議偵測到的框架版本中未提供的功能

3. **函式庫版本**：記錄關鍵函式庫及相依套件的確切版本
   - 產生與這些特定版本相容的程式碼
   - 絕不使用偵測到的版本中未提供的 API 或功能

## 上下文檔案

優先採用 .github/copilot 目錄中的以下檔案（若存在）：

- **architecture.md**：系統架構指南
- **tech-stack.md**：技術版本及框架詳細資訊
- **coding-standards.md**：程式碼風格及格式化標準
- **folder-structure.md**：專案組織指南
- **exemplars.md**：可遵循的範例程式碼模式

## 程式碼庫掃描指示

當上下文檔案未提供具體指引時：

1. 識別與正在修改或建立的檔案類似的檔案
2. 分析以下模式：
   - 命名慣例
   - 程式碼組織
   - 錯誤處理
   - 日誌方式
   - 文件風格
   - 測試模式
   
3. 遵循程式碼庫中最一致的模式
4. 當存在衝突模式時，優先採用較新檔案或測試覆蓋率較高檔案中的模式
5. 絕不引入現有程式碼庫中未出現的模式

## 程式碼品質標準

${CODE_QUALITY_FOCUS.includes("可維護性") || CODE_QUALITY_FOCUS == "全部" ? `### 可維護性
- 撰寫自我說明的程式碼，使用清晰的名稱
- 遵循程式碼庫中明顯的命名及組織慣例
- 遵循既有模式以保持一致性
- 保持函式專注於單一職責
- 限制函式複雜度及長度以符合既有模式` : ""}

${CODE_QUALITY_FOCUS.includes("效能") || CODE_QUALITY_FOCUS == "全部" ? `### 效能
- 遵循既有模式進行記憶體及資源管理
- 比照既有模式處理計算密集型操作
- 遵循既有模式進行非同步操作
- 根據既有模式一致地應用快取
- 根據程式碼庫中明顯的模式進行最佳化` : ""}

${CODE_QUALITY_FOCUS.includes("安全性") || CODE_QUALITY_FOCUS == "全部" ? `### 安全性
- 遵循既有模式進行輸入驗證
- 應用程式碼庫中使用的相同清理技術
- 使用比照既有模式的參數化查詢
- 遵循既有的身分驗證及授權模式
- 根據既有模式處理敏感資料` : ""}

${CODE_QUALITY_FOCUS.includes("無障礙性") || CODE_QUALITY_FOCUS == "全部" ? `### 無障礙性
- 遵循程式碼庫中既有的無障礙模式
- 比照既有元件的 ARIA 屬性使用方式
- 維持與現有程式碼一致的鍵盤導航支援
- 遵循既有的顏色及對比模式
- 應用與程式碼庫一致的文字替代模式` : ""}

${CODE_QUALITY_FOCUS.includes("可測試性") || CODE_QUALITY_FOCUS == "全部" ? `### 可測試性
- 遵循既有的可測試程式碼模式
- 比照程式碼庫中使用的相依性注入方式
- 應用相同的模式管理相依性
- 遵循既有的模擬及測試替身模式
- 比照現有測試中使用的測試風格` : ""}

## 文件需求

${DOCUMENTATION_LEVEL == "最少" ? 
`- 比照現有程式碼中註解的層級及風格
- 根據程式碼庫中觀察到的模式進行文件化
- 遵循既有模式記錄非顯而易見的行為
- 使用與現有程式碼相同的參數描述格式` : ""}

${DOCUMENTATION_LEVEL == "標準" ? 
`- 遵循程式碼庫中確切的文件格式
- 比照現有註解的 XML/JSDoc 風格及完整性
- 以相同風格記錄參數、回傳值及例外
- 遵循既有模式提供使用範例
- 比照類別層級文件的風格及內容` : ""}

${DOCUMENTATION_LEVEL == "全面" ? 
`- 遵循程式碼庫中最詳細的文件模式
- 比照最佳文件化程式碼的風格及完整性
- 完全按照最詳盡的文件化檔案進行記錄
- 遵循既有模式連結文件
- 比照設計決策說明的詳細程度` : ""}

## 測試方式

${TESTING_REQUIREMENTS.includes("單元測試") || TESTING_REQUIREMENTS == "全部" ? 
`### 單元測試
- 比照現有單元測試的確切結構及風格
- 遵循測試類別及方法相同的命名慣例
- 使用現有測試中相同的斷言模式
- 應用程式碼庫中使用的相同模擬方式
- 遵循既有模式進行測試隔離` : ""}

${TESTING_REQUIREMENTS.includes("整合測試") || TESTING_REQUIREMENTS == "全部" ? 
`### 整合測試
- 遵循程式碼庫中相同的整合測試模式
- 比照現有模式進行測試資料設定及清除
- 使用相同方式測試元件互動
- 遵循既有模式驗證系統行為` : ""}

${TESTING_REQUIREMENTS.includes("端到端測試") || TESTING_REQUIREMENTS == "全部" ? 
`### 端到端測試
- 比照現有 E2E 測試結構及模式
- 遵循既有的 UI 測試模式
- 應用相同方式驗證使用者流程` : ""}

${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "全部" ? 
`### 測試驅動開發
- 遵循程式碼庫中明顯的 TDD 模式
- 比照現有程式碼中測試案例的進展
- 測試通過後應用相同的重構模式` : ""}

${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "全部" ? 
`### 行為驅動開發
- 比照測試中現有的 Given-When-Then 結構
- 遵循相同的行為描述模式
- 在測試案例中應用相同程度的業務焦點` : ""}

## 技術特定指南

${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "自動偵測" || PROJECT_TYPE == "多種" ? `### .NET 指南
- 偵測並嚴格遵守使用中的特定 .NET 版本
- 僅使用與偵測版本相容的 C# 語言功能
- 完全按照程式碼庫中的 LINQ 使用模式
- 比照現有程式碼中的 async/await 使用模式
- 應用程式碼庫中使用的相同相依性注入方式
- 使用現有程式碼中相同的集合類型及模式` : ""}

${PROJECT_TYPE == "Java" || PROJECT_TYPE == "自動偵測" || PROJECT_TYPE == "多種" ? `### Java 指南
- 偵測並遵守特定的 Java 版本
- 遵循程式碼庫中完全相同的設計模式
- 比照現有程式碼中的例外處理模式
- 使用程式碼庫中相同的集合類型及方式
- 應用現有程式碼中明顯的相依性注入模式` : ""}

${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "自動偵測" || PROJECT_TYPE == "多種" ? `### JavaScript/TypeScript 指南
- 偵測並遵守特定的 ECMAScript/TypeScript 版本
- 遵循程式碼庫中相同的模組匯入/匯出模式
- 比照現有模式中的 TypeScript 型別定義
- 使用與現有程式碼相同的非同步模式（promises、async/await）
- 遵循類似檔案中的錯誤處理模式` : ""}

${PROJECT_TYPE == "React" || PROJECT_TYPE == "自動偵測" || PROJECT_TYPE == "多種" ? `### React 指南
- 偵測並遵守特定的 React 版本
- 比照現有元件的元件結構模式
- 遵循程式碼庫中相同的 hooks 及生命週期模式
- 應用現有元件中使用的相同狀態管理方式
- 比照現有程式碼中的 prop 型別及驗證模式` : ""}

${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "自動偵測" || PROJECT_TYPE == "多種" ? `### Angular 指南
- 偵測並遵守特定的 Angular 版本
- 遵循程式碼庫中相同的元件及模組模式
- 完全按照現有程式碼中的裝飾器使用方式
- 應用程式碼庫中相同的 RxJS 模式
- 遵循現有的元件通訊模式` : ""}

${PROJECT_TYPE == "Python" || PROJECT_TYPE == "自動偵測" || PROJECT_TYPE == "多種" ? `### Python 指南
- 偵測並遵守特定的 Python 版本
- 遵循現有模組中相同的匯入組織
- 若程式碼庫中使用型別提示，則比照其方式
- 應用現有程式碼中相同的錯誤處理模式
- 遵循相同的模組組織模式` : ""}

## 版本控制指南

${VERSIONING == "語意化版本" ? 
`- 遵循程式碼庫中應用的語意化版本模式
- 比照現有模式記錄重大變更
- 遵循相同方式處理棄用通知` : ""}

${VERSIONING == "日曆版本" ? 
`- 遵循程式碼庫中應用的日曆版本模式
- 比照現有模式記錄變更
- 遵循相同方式強調重大變更` : ""}

${VERSIONING == "自訂" ? 
`- 比照程式碼庫中觀察到的確切版本模式
- 遵循現有文件中相同的變更日誌格式
- 應用專案中使用的相同標籤慣例` : ""}

## 一般最佳實務

- 完全按照現有程式碼中的命名慣例
- 比照類似檔案中的程式碼組織模式
- 應用與既有模式一致的錯誤處理
- 遵循程式碼庫中相同的測試方式
- 比照現有程式碼中的日誌模式
- 使用程式碼庫中相同的設定方式

## 專案特定指引

- 在產生任何程式碼之前徹底掃描程式碼庫
- 無例外地尊重現有架構邊界
- 比照周圍程式碼的風格及模式
- 有疑問時，優先與現有程式碼保持一致，而非外部最佳實務

2. 程式碼庫分析指示

為建立 copilot-instructions.md 檔案，首先分析程式碼庫以：

識別確切技術版本：
- ${PROJECT_TYPE == "自動偵測" ? "透過掃描副檔名及設定檔，偵測所有程式語言、框架及函式庫" : Focus on ${PROJECT_TYPE} technologies}
- 從專案檔案、package.json、.csproj 等提取精確版本資訊
- 記錄版本限制及相容性需求
了解架構：
- 分析資料夾結構及模組組織
- 識別清晰的層級邊界及元件關係
- 記錄元件間的通訊模式
記錄程式碼模式：
- 分類不同程式碼元素的命名慣例
- 注意文件風格及完整性
- 記錄錯誤處理模式
- 繪製測試方式及覆蓋率
注意品質標準：
- 識別實際使用的效能最佳化技術
- 記錄程式碼中實作的安全實務
- 注意存在的無障礙功能（若適用）
- 記錄程式碼庫中明顯的程式碼品質模式

3. 實作注意事項

最終的 copilot-instructions.md 應：

放置於 .github/copilot 目錄
僅參考程式碼庫中存在的模式及標準
包含明確的版本相容性需求
避免規定程式碼中未體現的實務
提供來自程式碼庫的具體範例
全面但足夠簡潔，以便 Copilot 有效使用

重要：僅包含基於程式碼庫中實際觀察到的模式的指引。明確指示 Copilot 優先與現有程式碼保持一致，而非外部最佳實務或較新的語言功能。
"

預期輸出

一份全面的 copilot-instructions.md 檔案，引導 GitHub Copilot 產生與您現有技術版本完全相容，並遵循既有模式及架構的程式碼。

您可能也喜歡

ponytail

79Kcode-generation

強制使用最懶惰但實際可行的解決方案，最簡單、最短、最精簡。引導一位看過一切的資深開發者：質疑任務是否需要存在（YAGNI），優先使用標準函式庫而非自訂程式碼，原生平台功能而非依賴套件，一行程式碼而非五十行。支援強度等級：lite、full（預設）、ultra。適用於任何程式碼任務：撰寫、新增、重構、修正、審查或設計程式碼，以及選擇函式庫或依賴套件。當使用者說「ponytail」、「be lazy」、「lazy mode」、「simplest solution」、「minimal solution」、「yagni」、「do less」或「shortest path」，或抱怨過度工程、臃腫、樣板程式碼或不必要的依賴時，也應使用。請勿用於非程式碼請求（一般知識、散文、翻譯、摘要、食譜）。

dietrichgebert

獲取

golang-dependency-injection

2.3Kcode-generation

Golang 依賴注入（DI）的完整指南。涵蓋為何 DI 重要（可測試性、鬆散耦合、關注點分離、生命週期管理）、手動建構子注入，以及 DI 函式庫比較（google/wire、uber-go/dig、uber-go/fx、samber/do）。在設計服務架構、設定依賴注入、重構緊耦合程式碼、管理單例或服務工廠，或使用者詢問控制反轉、服務容器、Go 中的依賴連接時，使用此技能。如需特定 DI 函式庫，請參閱 `samber/cc-skills-golang@golang-google-wire`、`samber/cc-skills-golang@golang-uber-dig`、`samber/cc-skills-golang@golang-uber-fx` 或 `samber/cc-skills-golang@golang-samber-do` 技能。

samber

獲取

weather

383Kcode-generation

Current weather and forecasts with web_fetch, falling back to wttr.in curl for locations, rain, temperature, travel planning.

steipete

獲取

繼續探索

瀏覽 code-generation 熱門 Skills 最近更新