copilot-instructions-blueprint-generator by github/awesome-copilot
npx skills add https://github.com/github/awesome-copilot --skill copilot-instructions-blueprint-generator${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} ${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} ${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} ${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} ${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} ${VERSIONING="Semantic|CalVer|Custom"}
"生成一个全面的 copilot-instructions.md 文件,用于指导 GitHub Copilot 生成符合我们项目标准、架构和技术版本的代码。指令必须严格基于我们代码库中的实际代码模式,避免做出任何假设。请遵循以下方法:
# GitHub Copilot 指令
## 优先级指南
为本仓库生成代码时:
1. **版本兼容性**:始终检测并尊重本项目使用的语言、框架和库的确切版本
2. **上下文文件**:优先遵循 .github/copilot 目录中定义的模式和标准
3. **代码库模式**:当上下文文件未提供具体指导时,扫描代码库以查找已建立的模式
4. **架构一致性**:保持我们的 ${ARCHITECTURE_STYLE} 架构风格和已建立的边界
5. **代码质量**:在所有生成的代码中优先考虑 ${CODE_QUALITY_FOCUS == "All" ? "可维护性、性能、安全性、可访问性和可测试性" : 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("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### 可维护性
- 编写具有清晰命名的自文档化代码
- 遵循代码库中明显的命名和组织约定
- 遵循已建立的模式以保持一致性
- 保持函数专注于单一职责
- 限制函数的复杂性和长度以匹配现有模式` : ""}
${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### 性能
- 遵循现有的内存和资源管理模式
- 匹配处理计算密集型操作的现有模式
- 遵循已建立的异步操作模式
- 根据现有模式一致地应用缓存
- 根据代码库中明显的模式进行优化` : ""}
${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### 安全性
- 遵循现有的输入验证模式
- 应用代码库中使用的相同清理技术
- 使用与现有模式匹配的参数化查询
- 遵循已建立的身份验证和授权模式
- 根据现有模式处理敏感数据` : ""}
${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### 可访问性
- 遵循代码库中现有的可访问性模式
- 匹配现有组件中 ARIA 属性的使用方式
- 保持与现有代码一致的键盘导航支持
- 遵循已建立的色彩和对比度模式
- 应用与代码库一致的文本替代模式` : ""}
${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### 可测试性
- 遵循已建立的可测试代码模式
- 匹配代码库中使用的依赖注入方法
- 应用相同的依赖项管理模式
- 遵循已建立的模拟和测试替身模式
- 匹配现有测试中使用的测试风格` : ""}
## 文档要求
${DOCUMENTATION_LEVEL == "Minimal" ?
`- 匹配现有代码中注释的级别和风格
- 根据在代码库中观察到的模式进行文档编写
- 遵循现有的记录非显而易见行为的模式
- 使用与现有代码相同的参数描述格式` : ""}
${DOCUMENTATION_LEVEL == "Standard" ?
`- 遵循代码库中确切的文档格式
- 匹配现有注释的 XML/JSDoc 风格和完整性
- 以相同风格记录参数、返回值和异常
- 遵循现有的使用示例模式
- 匹配类级别文档的风格和内容` : ""}
${DOCUMENTATION_LEVEL == "Comprehensive" ?
`- 遵循代码库中找到的最详细的文档模式
- 匹配文档最完善的代码的风格和完整性
- 像文档最详尽的文件那样进行记录
- 遵循现有的链接文档模式
- 匹配设计决策解释的详细程度` : ""}
## 测试方法
${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ?
`### 单元测试
- 匹配现有单元测试的确切结构和风格
- 遵循测试类和方法相同的命名约定
- 使用现有测试中找到的相同断言模式
- 应用代码库中使用的相同模拟方法
- 遵循现有的测试隔离模式` : ""}
${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ?
`### 集成测试
- 遵循代码库中找到的相同集成测试模式
- 匹配现有测试数据设置和清理模式
- 使用相同的方法测试组件交互
- 遵循现有的验证系统行为模式` : ""}
${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ?
`### 端到端测试
- 匹配现有的 E2E 测试结构和模式
- 遵循已建立的 UI 测试模式
- 应用相同的验证用户旅程的方法` : ""}
${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ?
`### 测试驱动开发
- 遵循代码库中明显的 TDD 模式
- 匹配现有代码中看到的测试用例进展
- 在测试通过后应用相同的重构模式` : ""}
${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ?
`### 行为驱动开发
- 匹配测试中现有的 Given-When-Then 结构
- 遵循相同的行为描述模式
- 在测试用例中应用相同的业务关注点级别` : ""}
## 技术特定指南
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET 指南
- 检测并严格遵守正在使用的特定 .NET 版本
- 仅使用与检测到的版本兼容的 C# 语言特性
- 完全按照代码库中的出现方式遵循 LINQ 使用模式
- 匹配现有代码中的 async/await 使用模式
- 应用代码库中使用的相同依赖注入方法
- 使用现有代码中找到的相同集合类型和模式` : ""}
${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java 指南
- 检测并遵守正在使用的特定 Java 版本
- 遵循代码库中找到的完全相同的设计模式
- 匹配现有代码中的异常处理模式
- 使用代码库中找到的相同集合类型和方法
- 应用现有代码中明显的依赖注入模式` : ""}
${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript 指南
- 检测并遵守正在使用的特定 ECMAScript/TypeScript 版本
- 遵循代码库中找到的相同模块导入/导出模式
- 匹配现有模式的 TypeScript 类型定义
- 使用与现有代码相同的异步模式(promises, async/await)
- 遵循类似文件中的错误处理模式` : ""}
${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React 指南
- 检测并遵守正在使用的特定 React 版本
- 匹配现有组件中的组件结构模式
- 遵循代码库中找到的相同钩子和生命周期模式
- 应用现有组件中使用的相同状态管理方法
- 匹配现有代码中的属性类型和验证模式` : ""}
${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular 指南
- 检测并遵守正在使用的特定 Angular 版本
- 遵循代码库中找到的相同组件和模块模式
- 完全按照现有代码中的使用方式匹配装饰器用法
- 应用代码库中找到的相同 RxJS 模式
- 遵循现有的组件通信模式` : ""}
${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python 指南
- 检测并遵守正在使用的特定 Python 版本
- 遵循现有模块中找到的相同导入组织方式
- 如果代码库中使用了类型提示,则匹配其使用方法
- 应用现有代码中找到的相同错误处理模式
- 遵循相同的模块组织模式` : ""}
## 版本控制指南
${VERSIONING == "Semantic" ?
`- 遵循代码库中应用的语义化版本控制模式
- 匹配记录破坏性变更的现有模式
- 遵循相同的弃用通知方法` : ""}
${VERSIONING == "CalVer" ?
`- 遵循代码库中应用的日历化版本控制模式
- 匹配记录变更的现有模式
- 遵循相同的高亮重要变更的方法` : ""}
${VERSIONING == "Custom" ?
`- 匹配在代码库中观察到的确切版本控制模式
- 遵循现有文档中使用的相同变更日志格式
- 应用项目中使用的相同标签约定` : ""}
## 通用最佳实践
- 完全按照现有代码中的出现方式遵循命名约定
- 匹配类似文件的代码组织模式
- 应用与现有模式一致的错误处理
- 遵循代码库中看到的相同测试方法
- 匹配现有代码中的日志记录模式
- 使用代码库中看到的相同配置方法
## 项目特定指导
- 在生成任何代码之前彻底扫描代码库
- 毫无例外地尊重现有的架构边界
- 匹配周围代码的风格和模式
- 如有疑问,优先考虑与现有代码的一致性,而不是外部最佳实践
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
要创建 copilot-instructions.md 文件,请首先分析代码库以:
* ${PROJECT_TYPE == "Auto-detect" ? "通过扫描文件扩展名和配置文件来检测所有编程语言、框架和库" : `专注于 ${PROJECT_TYPE} 技术`}
* 从项目文件、package.json、.csproj 等中提取精确的版本信息
* 记录版本约束和兼容性要求
2. 理解架构:
* 分析文件夹结构和模块组织
* 识别清晰的层级边界和组件关系
* 记录组件之间的通信模式
3. 记录代码模式:
* 为不同的代码元素分类命名约定
* 注意文档风格和完整性
* 记录错误处理模式
* 映射测试方法和覆盖率
4. 注意质量标准:
* 识别实际使用的性能优化技术
* 记录代码中实现的安全实践
* 注意存在的可访问性特性(如果适用)
* 记录代码库中明显的代码质量模式
最终的 copilot-instructions.md 应:
重要提示:仅包含基于在代码库中实际观察到的模式的指导。明确指示 Copilot 优先考虑与现有代码的一致性,而不是外部最佳实践或更新的语言特性。"
一个全面的 copilot-instructions.md 文件,用于指导 GitHub Copilot 生成与您现有技术版本完美兼容并遵循您已建立模式和架构的代码。
每周安装量
7.4K
仓库
GitHub 星标数
26.9K
首次出现
2026年2月25日
安全审计
安装于
codex7.3K
gemini-cli7.3K
opencode7.3K
github-copilot7.2K
cursor7.2K
kimi-cli7.2K
${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} ${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} ${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} ${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} ${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} ${VERSIONING="Semantic|CalVer|Custom"}
"Generate a comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code consistent with our project's standards, architecture, and technology versions. The instructions must be strictly based on actual code patterns in our codebase and avoid making any assumptions. Follow this approach:
# GitHub Copilot Instructions
## Priority Guidelines
When generating code for this repository:
1. **Version Compatibility**: Always detect and respect the exact versions of languages, frameworks, and libraries used in this project
2. **Context Files**: Prioritize patterns and standards defined in the .github/copilot directory
3. **Codebase Patterns**: When context files don't provide specific guidance, scan the codebase for established patterns
4. **Architectural Consistency**: Maintain our ${ARCHITECTURE_STYLE} architectural style and established boundaries
5. **Code Quality**: Prioritize ${CODE_QUALITY_FOCUS == "All" ? "maintainability, performance, security, accessibility, and testability" : CODE_QUALITY_FOCUS} in all generated code
## Technology Version Detection
Before generating code, scan the codebase to identify:
1. **Language Versions**: Detect the exact versions of programming languages in use
- Examine project files, configuration files, and package managers
- Look for language-specific version indicators (e.g., <LangVersion> in .NET projects)
- Never use language features beyond the detected version
2. **Framework Versions**: Identify the exact versions of all frameworks
- Check package.json, .csproj, pom.xml, requirements.txt, etc.
- Respect version constraints when generating code
- Never suggest features not available in the detected framework versions
3. **Library Versions**: Note the exact versions of key libraries and dependencies
- Generate code compatible with these specific versions
- Never use APIs or features not available in the detected versions
## Context Files
Prioritize the following files in .github/copilot directory (if they exist):
- **architecture.md**: System architecture guidelines
- **tech-stack.md**: Technology versions and framework details
- **coding-standards.md**: Code style and formatting standards
- **folder-structure.md**: Project organization guidelines
- **exemplars.md**: Exemplary code patterns to follow
## Codebase Scanning Instructions
When context files don't provide specific guidance:
1. Identify similar files to the one being modified or created
2. Analyze patterns for:
- Naming conventions
- Code organization
- Error handling
- Logging approaches
- Documentation style
- Testing patterns
3. Follow the most consistent patterns found in the codebase
4. When conflicting patterns exist, prioritize patterns in newer files or files with higher test coverage
5. Never introduce patterns not found in the existing codebase
## Code Quality Standards
${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintainability
- Write self-documenting code with clear naming
- Follow the naming and organization conventions evident in the codebase
- Follow established patterns for consistency
- Keep functions focused on single responsibilities
- Limit function complexity and length to match existing patterns` : ""}
${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance
- Follow existing patterns for memory and resource management
- Match existing patterns for handling computationally expensive operations
- Follow established patterns for asynchronous operations
- Apply caching consistently with existing patterns
- Optimize according to patterns evident in the codebase` : ""}
${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Security
- Follow existing patterns for input validation
- Apply the same sanitization techniques used in the codebase
- Use parameterized queries matching existing patterns
- Follow established authentication and authorization patterns
- Handle sensitive data according to existing patterns` : ""}
${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibility
- Follow existing accessibility patterns in the codebase
- Match ARIA attribute usage with existing components
- Maintain keyboard navigation support consistent with existing code
- Follow established patterns for color and contrast
- Apply text alternative patterns consistent with the codebase` : ""}
${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testability
- Follow established patterns for testable code
- Match dependency injection approaches used in the codebase
- Apply the same patterns for managing dependencies
- Follow established mocking and test double patterns
- Match the testing style used in existing tests` : ""}
## Documentation Requirements
${DOCUMENTATION_LEVEL == "Minimal" ?
`- Match the level and style of comments found in existing code
- Document according to patterns observed in the codebase
- Follow existing patterns for documenting non-obvious behavior
- Use the same format for parameter descriptions as existing code` : ""}
${DOCUMENTATION_LEVEL == "Standard" ?
`- Follow the exact documentation format found in the codebase
- Match the XML/JSDoc style and completeness of existing comments
- Document parameters, returns, and exceptions in the same style
- Follow existing patterns for usage examples
- Match class-level documentation style and content` : ""}
${DOCUMENTATION_LEVEL == "Comprehensive" ?
`- Follow the most detailed documentation patterns found in the codebase
- Match the style and completeness of the best-documented code
- Document exactly as the most thoroughly documented files do
- Follow existing patterns for linking documentation
- Match the level of detail in explanations of design decisions` : ""}
## Testing Approach
${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ?
`### Unit Testing
- Match the exact structure and style of existing unit tests
- Follow the same naming conventions for test classes and methods
- Use the same assertion patterns found in existing tests
- Apply the same mocking approach used in the codebase
- Follow existing patterns for test isolation` : ""}
${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ?
`### Integration Testing
- Follow the same integration test patterns found in the codebase
- Match existing patterns for test data setup and teardown
- Use the same approach for testing component interactions
- Follow existing patterns for verifying system behavior` : ""}
${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ?
`### End-to-End Testing
- Match the existing E2E test structure and patterns
- Follow established patterns for UI testing
- Apply the same approach for verifying user journeys` : ""}
${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ?
`### Test-Driven Development
- Follow TDD patterns evident in the codebase
- Match the progression of test cases seen in existing code
- Apply the same refactoring patterns after tests pass` : ""}
${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ?
`### Behavior-Driven Development
- Match the existing Given-When-Then structure in tests
- Follow the same patterns for behavior descriptions
- Apply the same level of business focus in test cases` : ""}
## Technology-Specific Guidelines
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET Guidelines
- Detect and strictly adhere to the specific .NET version in use
- Use only C# language features compatible with the detected version
- Follow LINQ usage patterns exactly as they appear in the codebase
- Match async/await usage patterns from existing code
- Apply the same dependency injection approach used in the codebase
- Use the same collection types and patterns found in existing code` : ""}
${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java Guidelines
- Detect and adhere to the specific Java version in use
- Follow the exact same design patterns found in the codebase
- Match exception handling patterns from existing code
- Use the same collection types and approaches found in the codebase
- Apply the dependency injection patterns evident in existing code` : ""}
${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript Guidelines
- Detect and adhere to the specific ECMAScript/TypeScript version in use
- Follow the same module import/export patterns found in the codebase
- Match TypeScript type definitions with existing patterns
- Use the same async patterns (promises, async/await) as existing code
- Follow error handling patterns from similar files` : ""}
${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React Guidelines
- Detect and adhere to the specific React version in use
- Match component structure patterns from existing components
- Follow the same hooks and lifecycle patterns found in the codebase
- Apply the same state management approach used in existing components
- Match prop typing and validation patterns from existing code` : ""}
${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular Guidelines
- Detect and adhere to the specific Angular version in use
- Follow the same component and module patterns found in the codebase
- Match decorator usage exactly as seen in existing code
- Apply the same RxJS patterns found in the codebase
- Follow existing patterns for component communication` : ""}
${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python Guidelines
- Detect and adhere to the specific Python version in use
- Follow the same import organization found in existing modules
- Match type hinting approaches if used in the codebase
- Apply the same error handling patterns found in existing code
- Follow the same module organization patterns` : ""}
## Version Control Guidelines
${VERSIONING == "Semantic" ?
`- Follow Semantic Versioning patterns as applied in the codebase
- Match existing patterns for documenting breaking changes
- Follow the same approach for deprecation notices` : ""}
${VERSIONING == "CalVer" ?
`- Follow Calendar Versioning patterns as applied in the codebase
- Match existing patterns for documenting changes
- Follow the same approach for highlighting significant changes` : ""}
${VERSIONING == "Custom" ?
`- Match the exact versioning pattern observed in the codebase
- Follow the same changelog format used in existing documentation
- Apply the same tagging conventions used in the project` : ""}
## General Best Practices
- Follow naming conventions exactly as they appear in existing code
- Match code organization patterns from similar files
- Apply error handling consistent with existing patterns
- Follow the same approach to testing as seen in the codebase
- Match logging patterns from existing code
- Use the same approach to configuration as seen in the codebase
## Project-Specific Guidance
- Scan the codebase thoroughly before generating any code
- Respect existing architectural boundaries without exception
- Match the style and patterns of surrounding code
- When in doubt, prioritize consistency with existing code over external best practices
To create the copilot-instructions.md file, first analyze the codebase to:
Identify Exact Technology Versions :
Focus on ${PROJECT_TYPE} technologies}Understand Architecture :
Document Code Patterns :
Note Quality Standards :
The final copilot-instructions.md should:
Important: Only include guidance based on patterns actually observed in the codebase. Explicitly instruct Copilot to prioritize consistency with existing code over external best practices or newer language features. "
A comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code that is perfectly compatible with your existing technology versions and follows your established patterns and architecture.
Weekly Installs
7.4K
Repository
GitHub Stars
26.9K
First Seen
Feb 25, 2026
Security Audits
Gen Agent Trust HubFailSocketPassSnykPass
Installed on
codex7.3K
gemini-cli7.3K
opencode7.3K
github-copilot7.2K
cursor7.2K
kimi-cli7.2K
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
102,200 周安装