Copilot Instructions Blueprint Generator

Configuration Variables

${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} <!-- Primary technology --> ${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} <!-- Architectural approach --> ${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} <!-- Quality priorities --> ${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} <!-- Documentation requirements --> ${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} <!-- Testing approach --> ${VERSIONING="Semantic|CalVer|Custom"} <!-- Versioning approach -->

Generated Prompt

"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:

1. Core Instruction Structure

markdown
1# GitHub Copilot Instructions
2
3## Priority Guidelines
4
5When generating code for this repository:
6
71. **Version Compatibility**: Always detect and respect the exact versions of languages, frameworks, and libraries used in this project
82. **Context Files**: Prioritize patterns and standards defined in the .github/copilot directory
93. **Codebase Patterns**: When context files don't provide specific guidance, scan the codebase for established patterns
104. **Architectural Consistency**: Maintain our ${ARCHITECTURE_STYLE} architectural style and established boundaries
115. **Code Quality**: Prioritize ${CODE_QUALITY_FOCUS == "All" ? "maintainability, performance, security, accessibility, and testability" : CODE_QUALITY_FOCUS} in all generated code
12
13## Technology Version Detection
14
15Before generating code, scan the codebase to identify:
16
171. **Language Versions**: Detect the exact versions of programming languages in use
18   - Examine project files, configuration files, and package managers
19   - Look for language-specific version indicators (e.g., <LangVersion> in .NET projects)
20   - Never use language features beyond the detected version
21
222. **Framework Versions**: Identify the exact versions of all frameworks
23   - Check package.json, .csproj, pom.xml, requirements.txt, etc.
24   - Respect version constraints when generating code
25   - Never suggest features not available in the detected framework versions
26
273. **Library Versions**: Note the exact versions of key libraries and dependencies
28   - Generate code compatible with these specific versions
29   - Never use APIs or features not available in the detected versions
30
31## Context Files
32
33Prioritize the following files in .github/copilot directory (if they exist):
34
35- **architecture.md**: System architecture guidelines
36- **tech-stack.md**: Technology versions and framework details
37- **coding-standards.md**: Code style and formatting standards
38- **folder-structure.md**: Project organization guidelines
39- **exemplars.md**: Exemplary code patterns to follow
40
41## Codebase Scanning Instructions
42
43When context files don't provide specific guidance:
44
451. Identify similar files to the one being modified or created
462. Analyze patterns for:
47   - Naming conventions
48   - Code organization
49   - Error handling
50   - Logging approaches
51   - Documentation style
52   - Testing patterns
53   
543. Follow the most consistent patterns found in the codebase
554. When conflicting patterns exist, prioritize patterns in newer files or files with higher test coverage
565. Never introduce patterns not found in the existing codebase
57
58## Code Quality Standards
59
60${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintainability
61- Write self-documenting code with clear naming
62- Follow the naming and organization conventions evident in the codebase
63- Follow established patterns for consistency
64- Keep functions focused on single responsibilities
65- Limit function complexity and length to match existing patterns` : ""}
66
67${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance
68- Follow existing patterns for memory and resource management
69- Match existing patterns for handling computationally expensive operations
70- Follow established patterns for asynchronous operations
71- Apply caching consistently with existing patterns
72- Optimize according to patterns evident in the codebase` : ""}
73
74${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Security
75- Follow existing patterns for input validation
76- Apply the same sanitization techniques used in the codebase
77- Use parameterized queries matching existing patterns
78- Follow established authentication and authorization patterns
79- Handle sensitive data according to existing patterns` : ""}
80
81${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibility
82- Follow existing accessibility patterns in the codebase
83- Match ARIA attribute usage with existing components
84- Maintain keyboard navigation support consistent with existing code
85- Follow established patterns for color and contrast
86- Apply text alternative patterns consistent with the codebase` : ""}
87
88${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testability
89- Follow established patterns for testable code
90- Match dependency injection approaches used in the codebase
91- Apply the same patterns for managing dependencies
92- Follow established mocking and test double patterns
93- Match the testing style used in existing tests` : ""}
94
95## Documentation Requirements
96
97${DOCUMENTATION_LEVEL == "Minimal" ? 
98`- Match the level and style of comments found in existing code
99- Document according to patterns observed in the codebase
100- Follow existing patterns for documenting non-obvious behavior
101- Use the same format for parameter descriptions as existing code` : ""}
102
103${DOCUMENTATION_LEVEL == "Standard" ? 
104`- Follow the exact documentation format found in the codebase
105- Match the XML/JSDoc style and completeness of existing comments
106- Document parameters, returns, and exceptions in the same style
107- Follow existing patterns for usage examples
108- Match class-level documentation style and content` : ""}
109
110${DOCUMENTATION_LEVEL == "Comprehensive" ? 
111`- Follow the most detailed documentation patterns found in the codebase
112- Match the style and completeness of the best-documented code
113- Document exactly as the most thoroughly documented files do
114- Follow existing patterns for linking documentation
115- Match the level of detail in explanations of design decisions` : ""}
116
117## Testing Approach
118
119${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ? 
120`### Unit Testing
121- Match the exact structure and style of existing unit tests
122- Follow the same naming conventions for test classes and methods
123- Use the same assertion patterns found in existing tests
124- Apply the same mocking approach used in the codebase
125- Follow existing patterns for test isolation` : ""}
126
127${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ? 
128`### Integration Testing
129- Follow the same integration test patterns found in the codebase
130- Match existing patterns for test data setup and teardown
131- Use the same approach for testing component interactions
132- Follow existing patterns for verifying system behavior` : ""}
133
134${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ? 
135`### End-to-End Testing
136- Match the existing E2E test structure and patterns
137- Follow established patterns for UI testing
138- Apply the same approach for verifying user journeys` : ""}
139
140${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ? 
141`### Test-Driven Development
142- Follow TDD patterns evident in the codebase
143- Match the progression of test cases seen in existing code
144- Apply the same refactoring patterns after tests pass` : ""}
145
146${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ? 
147`### Behavior-Driven Development
148- Match the existing Given-When-Then structure in tests
149- Follow the same patterns for behavior descriptions
150- Apply the same level of business focus in test cases` : ""}
151
152## Technology-Specific Guidelines
153
154${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET Guidelines
155- Detect and strictly adhere to the specific .NET version in use
156- Use only C# language features compatible with the detected version
157- Follow LINQ usage patterns exactly as they appear in the codebase
158- Match async/await usage patterns from existing code
159- Apply the same dependency injection approach used in the codebase
160- Use the same collection types and patterns found in existing code` : ""}
161
162${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java Guidelines
163- Detect and adhere to the specific Java version in use
164- Follow the exact same design patterns found in the codebase
165- Match exception handling patterns from existing code
166- Use the same collection types and approaches found in the codebase
167- Apply the dependency injection patterns evident in existing code` : ""}
168
169${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript Guidelines
170- Detect and adhere to the specific ECMAScript/TypeScript version in use
171- Follow the same module import/export patterns found in the codebase
172- Match TypeScript type definitions with existing patterns
173- Use the same async patterns (promises, async/await) as existing code
174- Follow error handling patterns from similar files` : ""}
175
176${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React Guidelines
177- Detect and adhere to the specific React version in use
178- Match component structure patterns from existing components
179- Follow the same hooks and lifecycle patterns found in the codebase
180- Apply the same state management approach used in existing components
181- Match prop typing and validation patterns from existing code` : ""}
182
183${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular Guidelines
184- Detect and adhere to the specific Angular version in use
185- Follow the same component and module patterns found in the codebase
186- Match decorator usage exactly as seen in existing code
187- Apply the same RxJS patterns found in the codebase
188- Follow existing patterns for component communication` : ""}
189
190${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python Guidelines
191- Detect and adhere to the specific Python version in use
192- Follow the same import organization found in existing modules
193- Match type hinting approaches if used in the codebase
194- Apply the same error handling patterns found in existing code
195- Follow the same module organization patterns` : ""}
196
197## Version Control Guidelines
198
199${VERSIONING == "Semantic" ? 
200`- Follow Semantic Versioning patterns as applied in the codebase
201- Match existing patterns for documenting breaking changes
202- Follow the same approach for deprecation notices` : ""}
203
204${VERSIONING == "CalVer" ? 
205`- Follow Calendar Versioning patterns as applied in the codebase
206- Match existing patterns for documenting changes
207- Follow the same approach for highlighting significant changes` : ""}
208
209${VERSIONING == "Custom" ? 
210`- Match the exact versioning pattern observed in the codebase
211- Follow the same changelog format used in existing documentation
212- Apply the same tagging conventions used in the project` : ""}
213
214## General Best Practices
215
216- Follow naming conventions exactly as they appear in existing code
217- Match code organization patterns from similar files
218- Apply error handling consistent with existing patterns
219- Follow the same approach to testing as seen in the codebase
220- Match logging patterns from existing code
221- Use the same approach to configuration as seen in the codebase
222
223## Project-Specific Guidance
224
225- Scan the codebase thoroughly before generating any code
226- Respect existing architectural boundaries without exception
227- Match the style and patterns of surrounding code
228- When in doubt, prioritize consistency with existing code over external best practices

2. Codebase Analysis Instructions

To create the copilot-instructions.md file, first analyze the codebase to:

1. Identify Exact Technology Versions:

   • ${PROJECT_TYPE == "Auto-detect" ? "Detect all programming languages, frameworks, and libraries by scanning file extensions and configuration files" : Focus on ${PROJECT_TYPE} technologies}
   • Extract precise version information from project files, package.json, .csproj, etc.
   • Document version constraints and compatibility requirements

2. Understand Architecture:

   • Analyze folder structure and module organization
   • Identify clear layer boundaries and component relationships
   • Document communication patterns between components

3. Document Code Patterns:

   • Catalog naming conventions for different code elements
   • Note documentation styles and completeness
   • Document error handling patterns
   • Map testing approaches and coverage

4. Note Quality Standards:

   • Identify performance optimization techniques actually used
   • Document security practices implemented in the code
   • Note accessibility features present (if applicable)
   • Document code quality patterns evident in the codebase

3. Implementation Notes

The final copilot-instructions.md should:

• Be placed in the .github/copilot directory
• Reference only patterns and standards that exist in the codebase
• Include explicit version compatibility requirements
• Avoid prescribing any practices not evident in the code
• Provide concrete examples from the codebase
• Be comprehensive yet concise enough for Copilot to effectively use

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. "

Expected Output

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.