josiadmin/awesome-copilot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial setup of repo with prompts and instructions

Browse Source
This commit is contained in:
Aaron Powell 2025-06-19 11:50:55 +10:00
commit 4c8ad05afd
29 changed files with 1908 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitignore vendored Normal file
View File

@ -0,0 +1,2 @@
node_modules
*.orig

9
CODE_OF_CONDUCT.md Normal file
View File

@ -0,0 +1,9 @@
# Microsoft Open Source Code of Conduct
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
Resources:
- [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/)
- [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
- Contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with questions or concerns

85
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,85 @@
# Contributing to GitHub Copilot Instructions
Thank you for your interest in contributing to the GitHub Copilot Instructions repository! We welcome contributions from the community to help expand our collection of custom instructions and prompts.
## How to Contribute
### Adding Instructions
Instructions help customize GitHub Copilot's behavior for specific technologies, coding practices, or domains.
1. **Create your instruction file**: Add a new `.md` file in the `instructions/` directory
2. **Follow the naming convention**: Use descriptive, lowercase filenames with hyphens (e.g., `python-django.md`)
3. **Structure your content**: Start with a clear heading and organize your instructions logically
4. **Test your instructions**: Make sure your instructions work well with GitHub Copilot
#### Example instruction format:
```markdown
# Your Technology/Framework Name
## Instructions
- Provide clear, specific guidance for GitHub Copilot
- Include best practices and conventions
- Use bullet points for easy reading
## Additional Guidelines
- Any additional context or examples
```
### Adding Prompts
Prompts are ready-to-use templates for specific development scenarios and tasks.
1. **Create your prompt file**: Add a new `.prompt.md` file in the `prompts/` directory
2. **Follow the naming convention**: Use descriptive, lowercase filenames with hyphens and the `.prompt.md` extension (e.g., `react-component-generator.prompt.md`)
3. **Include frontmatter**: Add metadata at the top of your file (optional but recommended)
4. **Structure your prompt**: Provide clear context and specific instructions
#### Example prompt format:
```markdown
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Brief description of what this prompt does"
---
# Prompt Title
Your goal is to...
## Specific Instructions
- Clear, actionable instructions
- Include examples where helpful
```
## Submitting Your Contribution
1. **Fork this repository**
2. **Create a new branch** for your contribution
3. **Add your instruction or prompt file** following the guidelines above
4. **Run the update script** (optional): `node update-readme.js` to update the README with your new file
5. **Submit a pull request** with:
- A clear title describing your contribution
- A brief description of what your instruction/prompt does
- Any relevant context or usage notes
## Quality Guidelines
- **Be specific**: Generic instructions are less helpful than specific, actionable guidance
- **Test your content**: Ensure your instructions or prompts work well with GitHub Copilot
- **Follow conventions**: Use consistent formatting and naming
- **Keep it focused**: Each file should address a specific technology, framework, or use case
- **Write clearly**: Use simple, direct language
## Code of Conduct
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
## License
By contributing to this repository, you agree that your contributions will be licensed under the MIT License.

21
LICENSE Normal file
View File

@ -0,0 +1,21 @@
MIT License
Copyright (c) Microsoft Corporation.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE

84
README.md Normal file
View File

@ -0,0 +1,84 @@
# 🤖 Awesome GitHub Copilot Customizations
Enhance your GitHub Copilot experience with community-contributed instructions, prompts, and configurations. Get consistent AI assistance that follows your team's coding standards and project requirements.
## 🎯 GitHub Copilot Customization Features
GitHub Copilot provides three main ways to customize AI responses and tailor assistance to your specific workflows, team guidelines, and project requirements:
| **🔧 Custom Instructions** | **📝 Reusable Prompts** | **🎭 Custom Chat Modes** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Define common guidelines for tasks like code generation, reviews, and commit messages. Describe *how* tasks should be performed<br><br>**Benefits:**<br>• Automatic inclusion in every chat request<br>• Repository-wide consistency<br>• Multiple implementation options | Create reusable, standalone prompts for specific tasks. Describe *what* should be done with optional task-specific guidelines<br><br>**Benefits:**<br>• Eliminate repetitive prompt writing<br>• Shareable across teams<br>• Support for variables and dependencies | Define chat behavior, available tools, and codebase interaction patterns within specific boundaries for each request<br><br>**Benefits:**<br>• Context-aware assistance<br>• Tool configuration<br>• Role-specific workflows |
> **💡 Pro Tip:** Custom instructions only affect Copilot Chat (not inline code completions). You can combine all three customization types - use custom instructions for general guidelines, prompt files for specific tasks, and chat modes to control the interaction context.
## 📝 Contributing
We welcome contributions! Please see our [Contributing Guide](./CONTRIBUTING.md) for details on how to submit new instructions and prompts.
## 📋 Custom Instructions
Team and project-specific instructions to enhance GitHub Copilot's behavior for specific technologies and coding practices:
- [Angular Development Instructions](instructions/angular.md) - Angular-specific coding standards and best practices
- [ASP.NET REST API Development](instructions/aspnet-rest-apis.md) - Guidelines for building REST APIs with ASP.NET
- [Azure Functions Typescript](instructions/azure-functions-typescript.md) - TypeScript patterns for Azure Functions
- [Bicep Code Best Practices](instructions/bicep-code-best-practices.md) - Infrastructure as Code with Bicep
- [Blazor](instructions/blazor.md) - Blazor component and application patterns
- [Cmake Vcpkg](instructions/cmake-vcpkg.md) - C++ project configuration and package management
- [Genaiscript](instructions/genaiscript.md) - AI-powered script generation guidelines
- [Generate Modern Terraform Code For Azure](instructions/generate-modern-terraform-code-for-azure.md) - Guidelines for generating modern Terraform code for Azure
- [Markdown](instructions/markdown.md) - Documentation and content creation standards
- [Next.js + Tailwind Development Instructions](instructions/nextjs-tailwind.md) - Next.js + Tailwind development standards and instructions
- [Python Coding Conventions](instructions/python.md) - Python coding conventions and guidelines
> 💡 **Usage**: Copy these instructions to your `.github/copilot-instructions.md` file or create task-specific `.instructions.md` files in your workspace.
## 🎯 Reusable Prompts
Ready-to-use prompt templates for specific development scenarios and tasks. These `.prompt.md` files can be executed directly in VS Code chat as slash commands or through the `Chat: Run Prompt` command.
### Backend Development
- [ASP.NET Minimal API with OpenAPI](prompts/aspnet-minimal-api-openapi.prompt.md) - Generate API endpoints with proper documentation
- [Entity Framework Core Best Practices](prompts/ef-core.prompt.md) - Database operations and ORM patterns
- [Multi-Stage Dockerfile](prompts/multi-stage-dockerfile.prompt.md) - Optimized container builds for any technology
### Testing & Quality
- [C# Async Programming](prompts/csharp-async.prompt.md) - Asynchronous programming best practices
- [MSTest Best Practices](prompts/csharp-mstest.prompt.md) - MSTest unit testing with data-driven tests
- [NUnit Best Practices](prompts/csharp-nunit.prompt.md) - NUnit testing patterns and assertions
- [XUnit Best Practices](prompts/csharp-xunit.prompt.md) - XUnit testing with modern C# features
- [JavaScript/TypeScript Jest](prompts/javascript-typescript-jest.prompt.md) - Jest testing patterns, mocking, and structure
### Documentation & Project Management
- [Comment Code Generate Tutorial](prompts/comment-code-generate-a-tutorial.prompt.md) - Transform code into educational content
- [Generate Specs as Issues](prompts/gen-specs-as-issues.prompt.md) - Convert requirements into GitHub issues
> 💡 **Usage**: Use `/prompt-name` in VS Code chat or run `Chat: Run Prompt` command. Prompt files support variables like `${input:name}` for dynamic content.
## 📚 Additional Resources
- [VS Code Copilot Customization Documentation](https://code.visualstudio.com/docs/copilot/copilot-customization) - Official Microsoft documentation
- [GitHub Copilot Chat Documentation](https://code.visualstudio.com/docs/copilot/chat/copilot-chat) - Complete chat feature guide
- [Custom Chat Modes](https://code.visualstudio.com/docs/copilot/chat/chat-modes) - Advanced chat configuration
- [VS Code Settings](https://code.visualstudio.com/docs/getstarted/settings) - General VS Code configuration guide
## 📄 License
This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.
## 🤝 Code of Conduct
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
## ™️ Trademarks
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
trademarks or logos is subject to and must follow
[Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general).
Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
Any use of third-party trademarks or logos are subject to those third-party's policies.

41
SECURITY.md Normal file
View File

@ -0,0 +1,41 @@
<!-- BEGIN MICROSOFT SECURITY.MD V0.0.9 BLOCK -->
## Security
Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet) and [Xamarin](https://github.com/xamarin).
If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/security.md/definition), please report it to us as described below.
## Reporting Security Issues
**Please do not report security vulnerabilities through public GitHub issues.**
Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/security.md/msrc/create-report).
If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/security.md/msrc/pgp).
You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://www.microsoft.com/msrc).
Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
* Full paths of source file(s) related to the manifestation of the issue
* The location of the affected source code (tag/branch/commit or direct URL)
* Any special configuration required to reproduce the issue
* Step-by-step instructions to reproduce the issue
* Proof-of-concept or exploit code (if possible)
* Impact of the issue, including how an attacker might exploit the issue
This information will help us triage your report more quickly.
If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/security.md/msrc/bounty) page for more details about our active programs.
## Preferred Languages
We prefer all communications to be in English.
## Policy
Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/security.md/cvd).
<!-- END MICROSOFT SECURITY.MD BLOCK -->

25
SUPPORT.md Normal file
View File

@ -0,0 +1,25 @@
# TODO: The maintainer of this repo has not yet edited this file
**REPO OWNER**: Do you want Customer Service & Support (CSS) support for this product/project?
- **No CSS support:** Fill out this template with information about how to file issues and get help.
- **Yes CSS support:** Fill out an intake form at [aka.ms/onboardsupport](https://aka.ms/onboardsupport). CSS will work with/help you to determine next steps.
- **Not sure?** Fill out an intake as though the answer were "Yes". CSS will help you decide.
*Then remove this first heading from this SUPPORT.MD file before publishing your repo.*
# Support
## How to file issues and get help
This project uses GitHub Issues to track bugs and feature requests. Please search the existing
issues before filing new issues to avoid duplicates. For new issues, file your bug or
feature request as a new Issue.
For help and questions about using this project, please **REPO MAINTAINER: INSERT INSTRUCTIONS HERE
FOR HOW TO ENGAGE REPO OWNERS OR COMMUNITY FOR HELP. COULD BE A STACK OVERFLOW TAG OR OTHER
CHANNEL. WHERE WILL YOU HELP PEOPLE?**.
## Microsoft Support Policy
Support for this **PROJECT or PRODUCT** is limited to the resources listed above.

104
instructions/angular.md Normal file
View File

@ -0,0 +1,104 @@
---
description: |
Angular-specific coding standards and best practices
---
# Angular Development Instructions
Instructions for generating high-quality Angular applications with TypeScript, using Angular Signals for state management, adhering to Angular best practices as outlined at https://angular.dev.
## Project Context
- Latest Angular version (use standalone components by default)
- TypeScript for type safety
- Angular CLI for project setup and scaffolding
- Follow Angular Style Guide (https://angular.dev/style-guide)
- Use Angular Material or other modern UI libraries for consistent styling (if specified)
## Development Standards
### Architecture
- Use standalone components unless modules are explicitly required
- Organize code by feature modules or domains for scalability
- Implement lazy loading for feature modules to optimize performance
- Use Angular's built-in dependency injection system effectively
- Structure components with a clear separation of concerns (smart vs. presentational components)
### TypeScript
- Enable strict mode in `tsconfig.json` for type safety
- Define clear interfaces and types for components, services, and models
- Use type guards and union types for robust type checking
- Implement proper error handling with RxJS operators (e.g., `catchError`)
- Use typed forms (e.g., `FormGroup`, `FormControl`) for reactive forms
### Component Design
- Follow Angular's component lifecycle hooks best practices
- Use `@Input()` and `@Output()` for component communication
- Leverage Angular's change detection strategy (default or `OnPush` for performance)
- Keep templates clean and logic in component classes or services
- Use Angular directives and pipes for reusable functionality
### Styling
- Use Angular's component-level CSS encapsulation (default: ViewEncapsulation.Emulated)
- Prefer SCSS for styling with consistent theming
- Implement responsive design using CSS Grid, Flexbox, or Angular CDK Layout utilities
- Follow Angular Material's theming guidelines if used
- Maintain accessibility (a11y) with ARIA attributes and semantic HTML
### State Management
- Use Angular Signals for reactive state management in components and services
- Leverage `signal()`, `computed()`, and `effect()` for reactive state updates
- Use writable signals for mutable state and computed signals for derived state
- Handle loading and error states with signals and proper UI feedback
- Use Angular's `AsyncPipe` to handle observables in templates when combining signals with RxJS
### Data Fetching
- Use Angular's `HttpClient` for API calls with proper typing
- Implement RxJS operators for data transformation and error handling
- Use Angular's `inject()` function for dependency injection in standalone components
- Implement caching strategies (e.g., `shareReplay` for observables)
- Store API response data in signals for reactive updates
- Handle API errors with global interceptors for consistent error handling
### Security
- Sanitize user inputs using Angular's built-in sanitization
- Implement route guards for authentication and authorization
- Use Angular's `HttpInterceptor` for CSRF protection and API authentication headers
- Validate form inputs with Angular's reactive forms and custom validators
- Follow Angular's security best practices (e.g., avoid direct DOM manipulation)
### Performance
- Enable production builds with `ng build --prod` for optimization
- Use lazy loading for routes to reduce initial bundle size
- Optimize change detection with `OnPush` strategy and signals for fine-grained reactivity
- Use trackBy in `ngFor` loops to improve rendering performance
- Implement server-side rendering (SSR) or static site generation (SSG) with Angular Universal (if specified)
### Testing
- Write unit tests for components, services, and pipes using Jasmine and Karma
- Use Angular's `TestBed` for component testing with mocked dependencies
- Test signal-based state updates using Angular's testing utilities
- Write end-to-end tests with Cypress or Playwright (if specified)
- Mock HTTP requests using `HttpClientTestingModule`
- Ensure high test coverage for critical functionality
## Implementation Process
1. Plan project structure and feature modules
2. Define TypeScript interfaces and models
3. Scaffold components, services, and pipes using Angular CLI
4. Implement data services and API integrations with signal-based state
5. Build reusable components with clear inputs and outputs
6. Add reactive forms and validation
7. Apply styling with SCSS and responsive design
8. Implement lazy-loaded routes and guards
9. Add error handling and loading states using signals
10. Write unit and end-to-end tests
11. Optimize performance and bundle size
## Additional Guidelines
- Follow Angular's naming conventions (e.g., `feature.component.ts`, `feature.service.ts`)
- Use Angular CLI commands for generating boilerplate code
- Document components and services with clear JSDoc comments
- Ensure accessibility compliance (WCAG 2.1) where applicable
- Use Angular's built-in i18n for internationalization (if specified)
- Keep code DRY by creating reusable utilities and shared modules
- Use signals consistently for state management to ensure reactive updates

109
instructions/aspnet-rest-apis.md Normal file
View File

@ -0,0 +1,109 @@
---
description: Guidelines for building REST APIs with ASP.NET
---
# ASP.NET REST API Development
## Instruction
- Guide users through building their first REST API using ASP.NET Core 9.
- Explain both traditional Web API controllers and the newer Minimal API approach.
- Provide educational context for each implementation decision to help users understand the underlying concepts.
- Emphasize best practices for API design, testing, documentation, and deployment.
- Focus on providing explanations alongside code examples rather than just implementing features.
## API Design Fundamentals
- Explain REST architectural principles and how they apply to ASP.NET Core APIs.
- Guide users in designing meaningful resource-oriented URLs and appropriate HTTP verb usage.
- Demonstrate the difference between traditional controller-based APIs and Minimal APIs.
- Explain status codes, content negotiation, and response formatting in the context of REST.
- Help users understand when to choose Controllers vs. Minimal APIs based on project requirements.
## Project Setup and Structure
- Guide users through creating a new ASP.NET Core 9 Web API project with the appropriate templates.
- Explain the purpose of each generated file and folder to build understanding of the project structure.
- Demonstrate how to organize code using feature folders or domain-driven design principles.
- Show proper separation of concerns with models, services, and data access layers.
- Explain the Program.cs and configuration system in ASP.NET Core 9 including environment-specific settings.
## Building Controller-Based APIs
- Guide the creation of RESTful controllers with proper resource naming and HTTP verb implementation.
- Explain attribute routing and its advantages over conventional routing.
- Demonstrate model binding, validation, and the role of [ApiController] attribute.
- Show how dependency injection works within controllers.
- Explain action return types (IActionResult, ActionResult<T>, specific return types) and when to use each.
## Implementing Minimal APIs
- Guide users through implementing the same endpoints using the Minimal API syntax.
- Explain the endpoint routing system and how to organize route groups.
- Demonstrate parameter binding, validation, and dependency injection in Minimal APIs.
- Show how to structure larger Minimal API applications to maintain readability.
- Compare and contrast with controller-based approach to help users understand the differences.
## Data Access Patterns
- Guide the implementation of a data access layer using Entity Framework Core.
- Explain different options (SQL Server, SQLite, In-Memory) for development and production.
- Demonstrate repository pattern implementation and when it's beneficial.
- Show how to implement database migrations and data seeding.
- Explain efficient query patterns to avoid common performance issues.
## Authentication and Authorization
- Guide users through implementing authentication using JWT Bearer tokens.
- Explain OAuth 2.0 and OpenID Connect concepts as they relate to ASP.NET Core.
- Show how to implement role-based and policy-based authorization.
- Demonstrate integration with Microsoft Entra ID (formerly Azure AD).
- Explain how to secure both controller-based and Minimal APIs consistently.
## Validation and Error Handling
- Guide the implementation of model validation using data annotations and FluentValidation.
- Explain the validation pipeline and how to customize validation responses.
- Demonstrate a global exception handling strategy using middleware.
- Show how to create consistent error responses across the API.
- Explain problem details (RFC 7807) implementation for standardized error responses.
## API Versioning and Documentation
- Guide users through implementing and explaining API versioning strategies.
- Demonstrate Swagger/OpenAPI implementation with proper documentation.
- Show how to document endpoints, parameters, responses, and authentication.
- Explain versioning in both controller-based and Minimal APIs.
- Guide users on creating meaningful API documentation that helps consumers.
## Logging and Monitoring
- Guide the implementation of structured logging using Serilog or other providers.
- Explain the logging levels and when to use each.
- Demonstrate integration with Application Insights for telemetry collection.
- Show how to implement custom telemetry and correlation IDs for request tracking.
- Explain how to monitor API performance, errors, and usage patterns.
## Testing REST APIs
- Guide users through creating unit tests for controllers, Minimal API endpoints, and services.
- Explain integration testing approaches for API endpoints.
- Demonstrate how to mock dependencies for effective testing.
- Show how to test authentication and authorization logic.
- Explain test-driven development principles as applied to API development.
## Performance Optimization
- Guide users on implementing caching strategies (in-memory, distributed, response caching).
- Explain asynchronous programming patterns and why they matter for API performance.
- Demonstrate pagination, filtering, and sorting for large data sets.
- Show how to implement compression and other performance optimizations.
- Explain how to measure and benchmark API performance.
## Deployment and DevOps
- Guide users through containerizing their API using .NET's built-in container support (`dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer`).
- Explain the differences between manual Dockerfile creation and .NET's container publishing features.
- Explain CI/CD pipelines for ASP.NET Core applications.
- Demonstrate deployment to Azure App Service, Azure Container Apps, or other hosting options.
- Show how to implement health checks and readiness probes.
- Explain environment-specific configurations for different deployment stages.

13
instructions/azure-functions-typescript.md Normal file
View File

@ -0,0 +1,13 @@
---
description: TypeScript patterns for Azure Functions
---
## Guidance for Code Generation
- Generate modern TypeScript code for Node.js
- Use `async/await` for asynchronous code
- Whenever possible, use Node.js v20 built-in modules instead of external packages
- Always use Node.js async functions, like `node:fs/promises` instead of `fs` to avoid blocking the event loop
- Ask before adding any extra dependencies to the project
- The API is built using Azure Functions using `@azure/functions@4` package.
- Each endpoint should have its own function file, and use the following naming convention: `src/functions/<resource-name>-<http-verb>.ts`
- When making changes to the API, make sure to update the OpenAPI schema (if it exists) and `README.md` file accordingly.

54
instructions/bicep-code-best-practices.md Normal file
View File

@ -0,0 +1,54 @@
---
description: Infrastructure as Code with Bicep
applyTo: "**/*.bicep"
---
## Naming Conventions
- When writing Bicep code, use lowerCamelCase for all names (variables, parameters, resources)
- Use resource type descriptive symbolic names (e.g., 'storageAccount' not 'storageAccountName')
- Avoid using 'name' in a symbolic name as it represents the resource, not the resource's name
- Avoid distinguishing variables and parameters by the use of suffixes
## Structure and Declaration
- Always declare parameters at the top of files with @description decorators
- Use latest stable API versions for all resources
- Use descriptive @description decorators for all parameters
- Specify minimum and maximum character length for naming parameters
## Parameters
- Set default values that are safe for test environments (use low-cost pricing tiers)
- Use @allowed decorator sparingly to avoid blocking valid deployments
- Use parameters for settings that change between deployments
## Variables
- Variables automatically infer type from the resolved value
- Use variables to contain complex expressions instead of embedding them directly in resource properties
## Resource References
- Use symbolic names for resource references instead of reference() or resourceId() functions
- Create resource dependencies through symbolic names (resourceA.id) not explicit dependsOn
- For accessing properties from other resources, use the 'existing' keyword instead of passing values through outputs
## Resource Names
- Use template expressions with uniqueString() to create meaningful and unique resource names
- Add prefixes to uniqueString() results since some resources don't allow names starting with numbers
## Child Resources
- Avoid excessive nesting of child resources
- Use parent property or nesting instead of constructing resource names for child resources
## Security
- Never include secrets or keys in outputs
- Use resource properties directly in outputs (e.g., storageAccount.properties.primaryEndpoints)
## Documentation
- Include helpful // comments within your Bicep files to improve readability

77
instructions/blazor.md Normal file
View File

@ -0,0 +1,77 @@
---
description: Blazor component and application patterns
appliesTo: "**/*.razor, **/*.cs"
---
## Blazor Code Style and Structure
- Write idiomatic and efficient Blazor and C# code.
- Follow .NET and Blazor conventions.
- Use Razor Components appropriately for component-based UI development.
- Prefer inline functions for smaller components but separate complex logic into code-behind or service classes.
- Async/await should be used where applicable to ensure non-blocking UI operations.
## Naming Conventions
- Follow PascalCase for component names, method names, and public members.
- Use camelCase for private fields and local variables.
- Prefix interface names with "I" (e.g., IUserService).
## Blazor and .NET Specific Guidelines
- Utilize Blazor's built-in features for component lifecycle (e.g., OnInitializedAsync, OnParametersSetAsync).
- Use data binding effectively with @bind.
- Leverage Dependency Injection for services in Blazor.
- Structure Blazor components and services following Separation of Concerns.
- Use C# 10+ features like record types, pattern matching, and global usings.
## Error Handling and Validation
- Implement proper error handling for Blazor pages and API calls.
- Use logging for error tracking in the backend and consider capturing UI-level errors in Blazor with tools like ErrorBoundary.
- Implement validation using FluentValidation or DataAnnotations in forms.
## Blazor API and Performance Optimization
- Utilize Blazor server-side or WebAssembly optimally based on the project requirements.
- Use asynchronous methods (async/await) for API calls or UI actions that could block the main thread.
- Optimize Razor components by reducing unnecessary renders and using StateHasChanged() efficiently.
- Minimize the component render tree by avoiding re-renders unless necessary, using ShouldRender() where appropriate.
- Use EventCallbacks for handling user interactions efficiently, passing only minimal data when triggering events.
## Caching Strategies
- Implement in-memory caching for frequently used data, especially for Blazor Server apps. Use IMemoryCache for lightweight caching solutions.
- For Blazor WebAssembly, utilize localStorage or sessionStorage to cache application state between user sessions.
- Consider Distributed Cache strategies (like Redis or SQL Server Cache) for larger applications that need shared state across multiple users or clients.
- Cache API calls by storing responses to avoid redundant calls when data is unlikely to change, thus improving the user experience.
## State Management Libraries
- Use Blazor's built-in Cascading Parameters and EventCallbacks for basic state sharing across components.
- Implement advanced state management solutions using libraries like Fluxor or BlazorState when the application grows in complexity.
- For client-side state persistence in Blazor WebAssembly, consider using Blazored.LocalStorage or Blazored.SessionStorage to maintain state between page reloads.
- For server-side Blazor, use Scoped Services and the StateContainer pattern to manage state within user sessions while minimizing re-renders.
## API Design and Integration
- Use HttpClient or other appropriate services to communicate with external APIs or your own backend.
- Implement error handling for API calls using try-catch and provide proper user feedback in the UI.
## Testing and Debugging in Visual Studio
- All unit testing and integration testing should be done in Visual Studio Enterprise.
- Test Blazor components and services using xUnit, NUnit, or MSTest.
- Use Moq or NSubstitute for mocking dependencies during tests.
- Debug Blazor UI issues using browser developer tools and Visual Studio's debugging tools for backend and server-side issues.
- For performance profiling and optimization, rely on Visual Studio's diagnostics tools.
## Security and Authentication
- Implement Authentication and Authorization in the Blazor app where necessary using ASP.NET Identity or JWT tokens for API authentication.
- Use HTTPS for all web communication and ensure proper CORS policies are implemented.
## API Documentation and Swagger
- Use Swagger/OpenAPI for API documentation for your backend API services.
- Ensure XML documentation for models and API methods for enhancing Swagger documentation.

9
instructions/cmake-vcpkg.md Normal file
View File

@ -0,0 +1,9 @@
---
description: C++ project configuration and package management
---
This project uses vcpkg in manifest mode. Please keep this in mind when giving vcpkg suggestions. Do not provide suggestions like vcpkg install library, as they will not work as expected.
Prefer setting cache variables and other types of things through CMakePresets.json if possible.
Give information about any CMake Policies that might affect CMake variables that are suggested or mentioned.
This project needs to be cross-platform and cross-compiler for MSVC, Clang, and GCC.
When providing OpenCV samples that use the file system to read files, please always use absolute file paths rather than file names, or relative file paths. For example, use `video.open("C:/project/file.mp4")`, not `video.open("file.mp4")`.

22
instructions/genaiscript.md Normal file
View File

@ -0,0 +1,22 @@
---
applyTo: "**/*.genai.*"
description: AI-powered script generation guidelines
---
## Role
You are an expert at the GenAIScript programming language (https://microsoft.github.io/genaiscript). Your task is to generate GenAIScript script
or answer questions about GenAIScript.
## Reference
- [GenAIScript docs](../../.genaiscript/docs/llms-full.txt)
- [GenAIScript ambient type definitions](../../.genaiscript/genaiscript.d.ts)
## Guidance for Code Generation
- you always generate TypeScript code using ESM models for Node.JS.
- you prefer using APIs from GenAIScript 'genaiscript.d.ts' rather node.js. Avoid node.js imports.
- you keep the code simple, avoid exception handlers or error checking.
- you add TODOs where you are unsure so that the user can review them
- you use the global types in genaiscript.d.ts are already loaded in the global context, no need to import them.

82
instructions/generate-modern-terraform-code-for-azure.md Normal file
View File

@ -0,0 +1,82 @@
---
description: Guidelines for generating modern Terraform code for Azure
applyTo: "**/*.tf"
---
## 1. Use Latest Terraform and Providers
Always target the latest stable Terraform version and Azure providers. In code, specify the required Terraform and provider versions to enforce this. Keep provider versions updated to get new features and fixes.
## 2. Organize Code Cleanly
Structure Terraform configurations with logical file separation:
- Use `main.tf` for resources
- Use `variables.tf` for inputs
- Use `outputs.tf` for outputs
- Follow consistent naming conventions and formatting (`terraform fmt`)
This makes the code easy to navigate and maintain.
## 3. Encapsulate in Modules
Use Terraform modules to group reusable infrastructure components. For any resource set that will be used in multiple contexts:
- Create a module with its own variables/outputs
- Reference it rather than duplicating code
- This promotes reuse and consistency
## 4. Leverage Variables and Outputs
- **Parameterize** all configurable values using variables with types and descriptions
- **Provide default values** where appropriate for optional variables
- **Use outputs** to expose key resource attributes for other modules or user reference
- **Mark sensitive values** accordingly to protect secrets
## 5. Provider Selection (AzureRM vs AzAPI)
- **Use `azurerm` provider** for most scenarios – it offers high stability and covers the majority of Azure services
- **Use `azapi` provider** only for cases where you need:
- The very latest Azure features
- A resource not yet supported in `azurerm`
- **Document the choice** in code comments
- Both providers can be used together if needed, but prefer `azurerm` when in doubt
## 6. Minimal Dependencies
- **Do not introduce** additional providers or modules beyond the project's scope without confirmation
- If a special provider (e.g., `random`, `tls`) or external module is needed:
- Add a comment to explain
- Ensure the user approves it
- Keep the infrastructure stack lean and avoid unnecessary complexity
## 7. Ensure Idempotency
- Write configurations that can be applied repeatedly with the same outcome
- **Avoid non-idempotent actions**:
- Scripts that run on every apply
- Resources that might conflict if created twice
- **Test by doing multiple `terraform apply` runs** and ensure the second run results in zero changes
- Use resource lifecycle settings or conditional expressions to handle drift or external changes gracefully
## 8. State Management
- **Use a remote backend** (like Azure Storage with state locking) to store Terraform state securely
- Enable team collaboration
- **Never commit state files** to source control
- This prevents conflicts and keeps the infrastructure state consistent
## 9. Document and Diagram
- **Maintain up-to-date documentation**
- **Update README.md** with any new variables, outputs, or usage instructions whenever the code changes
- Consider using tools like `terraform-docs` for automation
- **Update architecture diagrams** to reflect infrastructure changes after each significant update
- Well-documented code and diagrams ensure the whole team understands the infrastructure
## 10. Validate and Test Changes
- **Run `terraform validate`** and review the `terraform plan` output before applying changes
- Catch errors or unintended modifications early
- **Consider implementing automated checks**:
- CI pipeline
- Pre-commit hooks
- Enforce formatting, linting, and basic validation

52
instructions/markdown.md Normal file
View File

@ -0,0 +1,52 @@
---
description: Documentation and content creation standards
applyTo: "**/*.md"
---
## Markdown Content Rules
The following markdown content rules are enforced in the validators:
1. **Headings**: Use appropriate heading levels (H2, H3, etc.) to structure your content. Do not use an H1 heading, as this will be generated based on the title.
2. **Lists**: Use bullet points or numbered lists for lists. Ensure proper indentation and spacing.
3. **Code Blocks**: Use fenced code blocks for code snippets. Specify the language for syntax highlighting.
4. **Links**: Use proper markdown syntax for links. Ensure that links are valid and accessible.
5. **Images**: Use proper markdown syntax for images. Include alt text for accessibility.
6. **Tables**: Use markdown tables for tabular data. Ensure proper formatting and alignment.
7. **Line Length**: Limit line length to 400 characters for readability.
8. **Whitespace**: Use appropriate whitespace to separate sections and improve readability.
9. **Front Matter**: Include YAML front matter at the beginning of the file with required metadata fields.
## Formatting and Structure
Follow these guidelines for formatting and structuring your markdown content:
- **Headings**: Use `##` for H2 and `###` for H3. Ensure that headings are used in a hierarchical manner. Recommend restructuring if content includes H4, and more strongly recommend for H5.
- **Lists**: Use `-` for bullet points and `1.` for numbered lists. Indent nested lists with two spaces.
- **Code Blocks**: Use triple backticks (`) to create fenced code blocks. Specify the language after the opening backticks for syntax highlighting (e.g., `csharp).
- **Links**: Use `[link text](URL)` for links. Ensure that the link text is descriptive and the URL is valid.
- **Images**: Use `![alt text](image URL)` for images. Include a brief description of the image in the alt text.
- **Tables**: Use `|` to create tables. Ensure that columns are properly aligned and headers are included.
- **Line Length**: Break lines at 80 characters to improve readability. Use soft line breaks for long paragraphs.
- **Whitespace**: Use blank lines to separate sections and improve readability. Avoid excessive whitespace.
## Validation Requirements
Ensure compliance with the following validation requirements:
- **Front Matter**: Include the following fields in the YAML front matter:
- `post_title`: The title of the post.
- `author1`: The primary author of the post.
- `post_slug`: The URL slug for the post.
- `microsoft_alias`: The Microsoft alias of the author.
- `featured_image`: The URL of the featured image.
- `categories`: The categories for the post. These categories must be from the list in /categories.txt.
- `tags`: The tags for the post.
- `ai_note`: Indicate if AI was used in the creation of the post.
- `summary`: A brief summary of the post. Recommend a summary based on the content when possible.
- `post_date`: The publication date of the post.
- **Content Rules**: Ensure that the content follows the markdown content rules specified above.
- **Formatting**: Ensure that the content is properly formatted and structured according to the guidelines.
- **Validation**: Run the validation tools to check for compliance with the rules and guidelines.

71
instructions/nextjs-tailwind.md Normal file
View File

@ -0,0 +1,71 @@
---
description: Next.js + Tailwind development standards and instructions
---
# Next.js + Tailwind Development Instructions
Instructions for high-quality Next.js applications with Tailwind CSS styling and TypeScript.
## Project Context
- Latest Next.js (App Router)
- TypeScript for type safety
- Tailwind CSS for styling
## Development Standards
### Architecture
- App Router with server and client components
- Group routes by feature/domain
- Implement proper error boundaries
- Use React Server Components by default
- Leverage static optimization where possible
### TypeScript
- Strict mode enabled
- Clear type definitions
- Proper error handling with type guards
- Zod for runtime type validation
### Styling
- Tailwind CSS with consistent color palette
- Responsive design patterns
- Dark mode support
- Follow container queries best practices
- Maintain semantic HTML structure
### State Management
- React Server Components for server state
- React hooks for client state
- Proper loading and error states
- Optimistic updates where appropriate
### Data Fetching
- Server Components for direct database queries
- React Suspense for loading states
- Proper error handling and retry logic
- Cache invalidation strategies
### Security
- Input validation and sanitization
- Proper authentication checks
- CSRF protection
- Rate limiting implementation
- Secure API route handling
### Performance
- Image optimization with next/image
- Font optimization with next/font
- Route prefetching
- Proper code splitting
- Bundle size optimization
## Implementation Process
1. Plan component hierarchy
2. Define types and interfaces
3. Implement server-side logic
4. Build client components
5. Add proper error handling
6. Implement responsive styling
7. Add loading states
8. Write tests

55
instructions/python.md Normal file
View File

@ -0,0 +1,55 @@
---
description: Python coding conventions and guidelines
---
# Python Coding Conventions
## Python Instructions
- Write clear and concise comments for each function.
- Ensure functions have descriptive names and include type hints.
- Provide docstrings following PEP 257 conventions.
- Use the `typing` module for type annotations (e.g., `List[str]`, `Dict[str, int]`).
- Break down complex functions into smaller, more manageable functions.
## General Instructions
- Always prioritize readability and clarity.
- For algorithm-related code, include explanations of the approach used.
- Write code with good maintainability practices, including comments on why certain design decisions were made.
- Handle edge cases and write clear exception handling.
- For libraries or external dependencies, mention their usage and purpose in comments.
- Use consistent naming conventions and follow language-specific best practices.
- Write concise, efficient, and idiomatic code that is also easily understandable.
## Code Style and Formatting
- Follow the **PEP 8** style guide for Python.
- Maintain proper indentation (use 4 spaces for each level of indentation).
- Ensure lines do not exceed 79 characters.
- Place function and class docstrings immediately after the `def` or `class` keyword.
- Use blank lines to separate functions, classes, and code blocks where appropriate.
## Edge Cases and Testing
- Always include test cases for critical paths of the application.
- Account for common edge cases like empty inputs, invalid data types, and large datasets.
- Include comments for edge cases and the expected behavior in those cases.
- Write unit tests for functions and document them with docstrings explaining the test cases.
## Example of Proper Documentation
```python
def calculate_area(radius: float) -> float:
"""
Calculate the area of a circle given the radius.
Parameters:
radius (float): The radius of the circle.
Returns:
float: The area of the circle, calculated as π * radius^2.
"""
import math
return math.pi * radius ** 2
```

41
prompts/aspnet-minimal-api-openapi.prompt.md Normal file
View File

@ -0,0 +1,41 @@
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Create ASP.NET Minimal API endpoints with proper OpenAPI documentation"
---
Your goal is to help me create well-structured ASP.NET Minimal API endpoints with correct types and comprehensive OpenAPI/Swagger documentation.
## API Organization
- Group related endpoints using `MapGroup()` extension
- Use endpoint filters for cross-cutting concerns
- Structure larger APIs with separate endpoint classes
- Consider using a feature-based folder structure for complex APIs
## Request and Response Types
- Define explicit request and response DTOs/models
- Create clear model classes with proper validation attributes
- Use record types for immutable request/response objects
- Use meaningful property names that align with API design standards
- Apply `[Required]` and other validation attributes to enforce constraints
## Type Handling
- Use strongly-typed route parameters with explicit type binding
- Apply proper parameter binding with `[FromBody]`, `[FromRoute]`, `[FromQuery]`
- Use `Results<T1, T2>` to represent multiple response types
- Return `TypedResults` instead of `Results` for strongly-typed responses
- Leverage C# 10+ features like nullable annotations and init-only properties
## OpenAPI / Swagger Documentation
- Add explicit OpenAPI operation details with `.WithOpenApi()`
- Define operation summary and description
- Document response types with `.Produces<T>(statusCode)`
- Document request bodies with `.WithRequestBody()`
- Set proper content types for requests and responses
- Include examples using `SwaggerRequestExampleAttribute`
- Document authentication requirements with `.RequireAuthorization()`
- Use XML documentation comments for descriptive API documentation

21
prompts/comment-code-generate-a-tutorial.prompt.md Normal file
View File

@ -0,0 +1,21 @@
Transform this Python script into a polished, beginner-friendly project by refactoring the code, adding clear instructional comments, and generating a complete markdown tutorial.
1. **Refactor the code**
- Apply standard Python best practices
- Ensure code follows the PEP 8 style guide
- Rename unclear variables and functions if needed for clarity
1. **Add comments throughout the code**
- Use a beginner-friendly, instructional tone
- Explain what each part of the code is doing and why it's important
- Focus on the logic and reasoning, not just syntax
- Avoid redundant or superficial comments
1. **Generate a tutorial as a `README.md` file**
Include the following sections:
- **Project Overview:** What the script does and why it's useful
- **Setup Instructions:** Prerequisites, dependencies, and how to run the script
- **How It Works:** A breakdown of the code logic based on the comments
- **Example Usage:** A code snippet showing how to use it
- **Sample Output:** (Optional) Include if the script returns visible results
- Use clear, readable Markdown formatting

50
prompts/csharp-async.prompt.md Normal file
View File

@ -0,0 +1,50 @@
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Get best practices for C# async programming"
---
# C# Async Programming Best Practices
Your goal is to help me follow best practices for asynchronous programming in C#.
## Naming Conventions
- Use the 'Async' suffix for all async methods
- Match method names with their synchronous counterparts when applicable (e.g., `GetDataAsync()` for `GetData()`)
## Return Types
- Return `Task<T>` when the method returns a value
- Return `Task` when the method doesn't return a value
- Consider `ValueTask<T>` for high-performance scenarios to reduce allocations
- Avoid returning `void` for async methods except for event handlers
## Exception Handling
- Use try/catch blocks around await expressions
- Avoid swallowing exceptions in async methods
- Use `ConfigureAwait(false)` when appropriate to prevent deadlocks in library code
- Propagate exceptions with `Task.FromException()` instead of throwing in async Task returning methods
## Performance
- Use `Task.WhenAll()` for parallel execution of multiple tasks
- Use `Task.WhenAny()` for implementing timeouts or taking the first completed task
- Avoid unnecessary async/await when simply passing through task results
- Consider cancellation tokens for long-running operations
## Common Pitfalls
- Never use `.Wait()`, `.Result`, or `.GetAwaiter().GetResult()` in async code
- Avoid mixing blocking and async code
- Don't create async void methods (except for event handlers)
- Always await Task-returning methods
## Implementation Patterns
- Implement the async command pattern for long-running operations
- Use async streams (IAsyncEnumerable<T>) for processing sequences asynchronously
- Consider the task-based asynchronous pattern (TAP) for public APIs
When reviewing my C# code, identify these issues and suggest improvements that follow these best practices.

68
prompts/csharp-mstest.prompt.md Normal file
View File

@ -0,0 +1,68 @@
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Get best practices for MSTest unit testing, including data-driven tests"
---
# MSTest Best Practices
Your goal is to help me write effective unit tests with MSTest, covering both standard and data-driven testing approaches.
## Project Setup
- Use a separate test project with naming convention `[ProjectName].Tests`
- Reference Microsoft.NET.Test.Sdk, MSTest.TestAdapter, and MSTest.TestFramework packages
- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
- Use .NET SDK test commands: `dotnet test` for running tests
## Test Structure
- Use `[TestClass]` attribute for test classes
- Use `[TestMethod]` attribute for test methods
- Follow the Arrange-Act-Assert (AAA) pattern
- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
- Use `[TestInitialize]` and `[TestCleanup]` for per-test setup and teardown
- Use `[ClassInitialize]` and `[ClassCleanup]` for per-class setup and teardown
- Use `[AssemblyInitialize]` and `[AssemblyCleanup]` for assembly-level setup and teardown
## Standard Tests
- Keep tests focused on a single behavior
- Avoid testing multiple behaviors in one test method
- Use clear assertions that express intent
- Include only the assertions needed to verify the test case
- Make tests independent and idempotent (can run in any order)
- Avoid test interdependencies
## Data-Driven Tests
- Use `[DataTestMethod]` combined with data source attributes
- Use `[DataRow]` for inline test data
- Use `[DynamicData]` for programmatically generated test data
- Use `[TestProperty]` to add metadata to tests
- Consider `[CsvDataSource]` for external data sources
- Use meaningful parameter names in data-driven tests
## Assertions
* Use `Assert.AreEqual` for value equality
* Use `Assert.AreSame` for reference equality
* Use `Assert.IsTrue`/`Assert.IsFalse` for boolean conditions
* Use `CollectionAssert` for collection comparisons
* Use `StringAssert` for string-specific assertions
* Use `Assert.ThrowsException<T>` to test exceptions
* Ensure assertions are simple in nature and have a message provided for clarity on failure
## Mocking and Isolation
* Consider using Moq or NSubstitute alongside MSTest
* Mock dependencies to isolate units under test
* Use interfaces to facilitate mocking
* Consider using a DI container for complex test setups
## Test Organization
* Group tests by feature or component
* Use test categories with `[TestCategory("Category")]`
* Use test priorities with `[Priority(1)]` for critical tests
* Use `[Owner("DeveloperName")]` to indicate ownership

72
prompts/csharp-nunit.prompt.md Normal file
View File

@ -0,0 +1,72 @@
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Get best practices for NUnit unit testing, including data-driven tests"
---
# NUnit Best Practices
Your goal is to help me write effective unit tests with NUnit, covering both standard and data-driven testing approaches.
## Project Setup
- Use a separate test project with naming convention `[ProjectName].Tests`
- Reference Microsoft.NET.Test.Sdk, NUnit, and NUnit3TestAdapter packages
- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
- Use .NET SDK test commands: `dotnet test` for running tests
## Test Structure
- Apply `[TestFixture]` attribute to test classes
- Use `[Test]` attribute for test methods
- Follow the Arrange-Act-Assert (AAA) pattern
- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
- Use `[SetUp]` and `[TearDown]` for per-test setup and teardown
- Use `[OneTimeSetUp]` and `[OneTimeTearDown]` for per-class setup and teardown
- Use `[SetUpFixture]` for assembly-level setup and teardown
## Standard Tests
- Keep tests focused on a single behavior
- Avoid testing multiple behaviors in one test method
- Use clear assertions that express intent
- Include only the assertions needed to verify the test case
- Make tests independent and idempotent (can run in any order)
- Avoid test interdependencies
## Data-Driven Tests
- Use `[TestCase]` for inline test data
- Use `[TestCaseSource]` for programmatically generated test data
- Use `[Values]` for simple parameter combinations
- Use `[ValueSource]` for property or method-based data sources
- Use `[Random]` for random numeric test values
- Use `[Range]` for sequential numeric test values
- Use `[Combinatorial]` or `[Pairwise]` for combining multiple parameters
## Assertions
- Use `Assert.That` with constraint model (preferred NUnit style)
- Use constraints like `Is.EqualTo`, `Is.SameAs`, `Contains.Item`
- Use `Assert.AreEqual` for simple value equality (classic style)
- Use `CollectionAssert` for collection comparisons
- Use `StringAssert` for string-specific assertions
- Use `Assert.Throws<T>` or `Assert.ThrowsAsync<T>` to test exceptions
- Use descriptive messages in assertions for clarity on failure
## Mocking and Isolation
- Consider using Moq or NSubstitute alongside NUnit
- Mock dependencies to isolate units under test
- Use interfaces to facilitate mocking
- Consider using a DI container for complex test setups
## Test Organization
- Group tests by feature or component
- Use categories with `[Category("CategoryName")]`
- Use `[Order]` to control test execution order when necessary
- Use `[Author("DeveloperName")]` to indicate ownership
- Use `[Description]` to provide additional test information
- Consider `[Explicit]` for tests that shouldn't run automatically
- Use `[Ignore("Reason")]` to temporarily skip tests

69
prompts/csharp-xunit.prompt.md Normal file
View File

@ -0,0 +1,69 @@
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Get best practices for XUnit unit testing, including data-driven tests"
---
# XUnit Best Practices
Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
## Project Setup
- Use a separate test project with naming convention `[ProjectName].Tests`
- Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
- Use .NET SDK test commands: `dotnet test` for running tests
## Test Structure
- No test class attributes required (unlike MSTest/NUnit)
- Use fact-based tests with `[Fact]` attribute for simple tests
- Follow the Arrange-Act-Assert (AAA) pattern
- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
- Use constructor for setup and `IDisposable.Dispose()` for teardown
- Use `IClassFixture<T>` for shared context between tests in a class
- Use `ICollectionFixture<T>` for shared context between multiple test classes
## Standard Tests
- Keep tests focused on a single behavior
- Avoid testing multiple behaviors in one test method
- Use clear assertions that express intent
- Include only the assertions needed to verify the test case
- Make tests independent and idempotent (can run in any order)
- Avoid test interdependencies
## Data-Driven Tests
- Use `[Theory]` combined with data source attributes
- Use `[InlineData]` for inline test data
- Use `[MemberData]` for method-based test data
- Use `[ClassData]` for class-based test data
- Create custom data attributes by implementing `DataAttribute`
- Use meaningful parameter names in data-driven tests
## Assertions
- Use `Assert.Equal` for value equality
- Use `Assert.Same` for reference equality
- Use `Assert.True`/`Assert.False` for boolean conditions
- Use `Assert.Contains`/`Assert.DoesNotContain` for collections
- Use `Assert.Matches`/`Assert.DoesNotMatch` for regex pattern matching
- Use `Assert.Throws<T>` or `await Assert.ThrowsAsync<T>` to test exceptions
- Use fluent assertions library for more readable assertions
## Mocking and Isolation
- Consider using Moq or NSubstitute alongside XUnit
- Mock dependencies to isolate units under test
- Use interfaces to facilitate mocking
- Consider using a DI container for complex test setups
## Test Organization
- Group tests by feature or component
- Use `[Trait("Category", "CategoryName")]` for categorization
- Use collection fixtures to group tests with shared dependencies
- Consider output helpers (`ITestOutputHelper`) for test diagnostics
- Skip tests conditionally with `Skip = "reason"` in fact/theory attributes

76
prompts/ef-core.prompt.md Normal file
View File

@ -0,0 +1,76 @@
---
mode: "agent"
tools: ["codebase", "terminalCommand"]
description: "Get best practices for Entity Framework Core"
---
# Entity Framework Core Best Practices
Your goal is to help me follow best practices when working with Entity Framework Core.
## Data Context Design
- Keep DbContext classes focused and cohesive
- Use constructor injection for configuration options
- Override OnModelCreating for fluent API configuration
- Separate entity configurations using IEntityTypeConfiguration
- Consider using DbContextFactory pattern for console apps or tests
## Entity Design
- Use meaningful primary keys (consider natural vs surrogate keys)
- Implement proper relationships (one-to-one, one-to-many, many-to-many)
- Use data annotations or fluent API for constraints and validations
- Implement appropriate navigational properties
- Consider using owned entity types for value objects
## Performance
- Use AsNoTracking() for read-only queries
- Implement pagination for large result sets with Skip() and Take()
- Use Include() to eager load related entities when needed
- Consider projection (Select) to retrieve only required fields
- Use compiled queries for frequently executed queries
- Avoid N+1 query problems by properly including related data
## Migrations
- Create small, focused migrations
- Name migrations descriptively
- Verify migration SQL scripts before applying to production
- Consider using migration bundles for deployment
- Add data seeding through migrations when appropriate
## Querying
- Use IQueryable judiciously and understand when queries execute
- Prefer strongly-typed LINQ queries over raw SQL
- Use appropriate query operators (Where, OrderBy, GroupBy)
- Consider database functions for complex operations
- Implement specifications pattern for reusable queries
## Change Tracking & Saving
- Use appropriate change tracking strategies
- Batch your SaveChanges() calls
- Implement concurrency control for multi-user scenarios
- Consider using transactions for multiple operations
- Use appropriate DbContext lifetimes (scoped for web apps)
## Security
- Avoid SQL injection by using parameterized queries
- Implement appropriate data access permissions
- Be careful with raw SQL queries
- Consider data encryption for sensitive information
- Use migrations to manage database user permissions
## Testing
- Use in-memory database provider for unit tests
- Create separate testing contexts with SQLite for integration tests
- Mock DbContext and DbSet for pure unit tests
- Test migrations in isolated environments
- Consider snapshot testing for model changes
When reviewing my EF Core code, identify issues and suggest improvements that follow these best practices.

160
prompts/gen-specs-as-issues.prompt.md Normal file
View File

@ -0,0 +1,160 @@
# Product Manager Assistant: Feature Identification and Specification
This workflow guides you through a systematic approach to identify missing features, prioritize them, and create detailed specifications for implementation.
## 1. Project Understanding Phase
- Review the project structure to understand its organization
- Read the README.md and other documentation files to understand the project's core functionality
- Identify the existing implementation status by examining:
- Main entry points (CLI, API, UI, etc.)
- Core modules and their functionality
- Tests to understand expected behavior
- Any placeholder implementations
**Guiding Questions:**
- What is the primary purpose of this project?
- What user problems does it solve?
- What patterns exist in the current implementation?
- Which features are mentioned in documentation but not fully implemented?
## 2. Gap Analysis Phase
- Compare the documented capabilities ONLY against the actual implementation
- Identify "placeholder" code that lacks real functionality
- Look for features mentioned in documentation but missing robust implementation
- Consider the user journey and identify broken or missing steps
- Focus on core functionality first (not nice-to-have features)
**Output Creation:**
- Create a list of potential missing features (5-7 items)
- For each feature, note:
- Current implementation status
- References in documentation
- Impact on user experience if missing
## 3. Prioritization Phase
- Apply a score to each identified gap:
**Scoring Matrix (1-5 scale):**
- User Impact: How many users benefit?
- Strategic Alignment: Fits core mission?
- Implementation Feasibility: Technical complexity?
- Resource Requirements: Development effort needed?
- Risk Level: Potential negative impacts?
**Priority = (User Impact × Strategic Alignment) / (Implementation Effort × Risk Level)**
**Output Creation:**
- Present the top 3 highest-priority missing features based on the scoring
- For each, provide:
- Feature name
- Current status
- Impact if not implemented
- Dependencies on other features
## 4. Specification Development Phase
- For each prioritized feature, develop a detailed but practical specification:
- Begin with the philosophical approach: simplicity over complexity
- Focus on MVP functionality first
- Consider the developer experience
- Keep the specification implementation-friendly
**For Each Feature Specification:**
1. **Overview & Scope**
- What problem does it solve?
- What's included and what's explicitly excluded?
2. **Technical Requirements**
- Core functionality needed
- User-facing interfaces (API, UI, CLI, etc.)
- Integration points with existing code
3. **Implementation Plan**
- Key modules/files to create or modify
- Simple code examples showing the approach
- Clear data structures and interfaces
4. **Acceptance Criteria**
- How will we know when it's done?
- What specific functionality must work?
- What tests should pass?
## 5. GitHub Issue Creation Phase
- For each specification, create a GitHub issue:
- Clear, descriptive title
- Comprehensive specification in the body
- Appropriate labels (enhancement, high-priority, etc.)
- Explicitly mention MVP philosophy where relevant
**Issue Template Structure:**
# [Feature Name]
## Overview
[Brief description of the feature and its purpose]
## Scope
[What's included and what's explicitly excluded]
## Technical Requirements
[Specific technical needs and constraints]
## Implementation Plan
[Step-by-step approach with simple code examples]
## Acceptance Criteria
[Clear list of requirements to consider the feature complete]
## Priority
[Justification for prioritization]
## Dependencies
- **Blocks:** [List of issues blocked by this one]
- **Blocked by:** [List of issues this one depends on]
## Implementation Size
- **Estimated effort:** [Small/Medium/Large]
- **Sub-issues:** [Links to sub-issues if this is a parent issue]
## 5.5 Work Distribution Optimization
- **Independence Analysis**
- Review each specification to identify truly independent components
- Refactor specifications to maximize independent work streams
- Create clear boundaries between interdependent components
- **Dependency Mapping**
- For features with unavoidable dependencies, establish clear issue hierarchies
- Create parent issues for the overall feature with sub-issues for components
- Explicitly document "blocked by" and "blocks" relationships
- **Workload Balancing**
- Break down large specifications into smaller, manageable sub-issues
- Ensure each sub-issue represents 1-3 days of development work
- Include sub-issue specific acceptance criteria
**Implementation Guidelines:**
- Use GitHub issue linking syntax to create explicit relationships
- Add labels to indicate dependency status (e.g., "blocked", "prerequisite")
- Include estimated complexity/effort for each issue to aid sprint planning
## 6. Final Review Phase
- Summarize all created specifications
- Highlight implementation dependencies between features
- Suggest a logical implementation order
- Note any potential challenges or considerations
Remember throughout this process:
- Favor simplicity over complexity
- Start with minimal viable implementations that work
- Focus on developer experience
- Build a foundation that can be extended later
- Consider the open-source community and contribution model
This workflow embodiment of our approach should help maintain consistency in how features are specified and prioritized, ensuring that software projects evolve in a thoughtful, user-centered way.

43
prompts/javascript-typescript-jest.prompt.md Normal file
View File

@ -0,0 +1,43 @@
---
description: "Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns."
---
### Test Structure
- Name test files with `.test.ts` or `.test.js` suffix
- Place test files next to the code they test or in a dedicated `__tests__` directory
- Use descriptive test names that explain the expected behavior
- Use nested describe blocks to organize related tests
- Follow the pattern: `describe('Component/Function/Class', () => { it('should do something', () => {}) })`
### Effective Mocking
- Mock external dependencies (APIs, databases, etc.) to isolate your tests
- Use `jest.mock()` for module-level mocks
- Use `jest.spyOn()` for specific function mocks
- Use `mockImplementation()` or `mockReturnValue()` to define mock behavior
- Reset mocks between tests with `jest.resetAllMocks()` in `afterEach`
### Testing Async Code
- Always return promises or use async/await syntax in tests
- Use `resolves`/`rejects` matchers for promises
- Set appropriate timeouts for slow tests with `jest.setTimeout()`
### Snapshot Testing
- Use snapshot tests for UI components or complex objects that change infrequently
- Keep snapshots small and focused
- Review snapshot changes carefully before committing
### Testing React Components
- Use React Testing Library over Enzyme for testing components
- Test user behavior and component accessibility
- Query elements by accessibility roles, labels, or text content
- Use `userEvent` over `fireEvent` for more realistic user interactions
## Common Jest Matchers
- Basic: `expect(value).toBe(expected)`, `expect(value).toEqual(expected)`
- Truthiness: `expect(value).toBeTruthy()`, `expect(value).toBeFalsy()`
- Numbers: `expect(value).toBeGreaterThan(3)`, `expect(value).toBeLessThanOrEqual(3)`
- Strings: `expect(value).toMatch(/pattern/)`, `expect(value).toContain('substring')`
- Arrays: `expect(array).toContain(item)`, `expect(array).toHaveLength(3)`
- Objects: `expect(object).toHaveProperty('key', value)`
- Exceptions: `expect(fn).toThrow()`, `expect(fn).toThrow(Error)`
- Mock functions: `expect(mockFn).toHaveBeenCalled()`, `expect(mockFn).toHaveBeenCalledWith(arg1, arg2)`

47
prompts/multi-stage-dockerfile.prompt.md Normal file
View File

@ -0,0 +1,47 @@
---
mode: "agent"
tools: ["codebase"]
description: "Create optimized multi-stage Dockerfiles for any language or framework"
---
Your goal is to help me create efficient multi-stage Dockerfiles that follow best practices, resulting in smaller, more secure container images.
## Multi-Stage Structure
- Use a builder stage for compilation, dependency installation, and other build-time operations
- Use a separate runtime stage that only includes what's needed to run the application
- Copy only the necessary artifacts from the builder stage to the runtime stage
- Use meaningful stage names with the `AS` keyword (e.g., `FROM node:18 AS builder`)
- Place stages in logical order: dependencies → build → test → runtime
## Base Images
- Start with official, minimal base images when possible
- Specify exact version tags to ensure reproducible builds (e.g., `python:3.11-slim` not just `python`)
- Consider distroless images for runtime stages where appropriate
- Use Alpine-based images for smaller footprints when compatible with your application
- Ensure the runtime image has the minimal necessary dependencies
## Layer Optimization
- Organize commands to maximize layer caching
- Place commands that change frequently (like code changes) after commands that change less frequently (like dependency installation)
- Use `.dockerignore` to prevent unnecessary files from being included in the build context
- Combine related RUN commands with `&&` to reduce layer count
- Consider using COPY --chown to set permissions in one step
## Security Practices
- Avoid running containers as root - use `USER` instruction to specify a non-root user
- Remove build tools and unnecessary packages from the final image
- Scan the final image for vulnerabilities
- Set restrictive file permissions
- Use multi-stage builds to avoid including build secrets in the final image
## Performance Considerations
- Use build arguments for configuration that might change between environments
- Leverage build cache efficiently by ordering layers from least to most frequently changing
- Consider parallelization in build steps when possible
- Set appropriate environment variables like NODE_ENV=production to optimize runtime behavior
- Use appropriate healthchecks for the application type with the HEALTHCHECK instruction

346
update-readme.js Executable file
View File

@ -0,0 +1,346 @@
#!/usr/bin/env node
const fs = require("fs");
const path = require("path");
function extractTitle(filePath) {
try {
const content = fs.readFileSync(filePath, "utf8");
// For prompt files, look for the main heading after frontmatter
if (filePath.includes(".prompt.md")) {
const lines = content.split("\n");
let inFrontmatter = false;
let frontmatterEnded = false;
for (const line of lines) {
if (line.trim() === "---") {
if (!inFrontmatter) {
inFrontmatter = true;
} else if (inFrontmatter && !frontmatterEnded) {
frontmatterEnded = true;
}
continue;
}
if (frontmatterEnded && line.startsWith("# ")) {
return line.substring(2).trim();
}
}
// For prompt files without heading, clean up filename
const basename = path.basename(filePath, ".prompt.md");
return basename
.replace(/[-_]/g, " ")
.replace(/\b\w/g, (l) => l.toUpperCase());
}
// For instruction files, look for the first heading
const lines = content.split("\n");
for (const line of lines) {
if (line.startsWith("# ")) {
return line.substring(2).trim();
}
}
// Fallback to filename
const basename = path.basename(filePath, path.extname(filePath));
return basename
.replace(/[-_]/g, " ")
.replace(/\b\w/g, (l) => l.toUpperCase());
} catch (error) {
// Fallback to filename
const basename = path.basename(filePath, path.extname(filePath));
return basename
.replace(/[-_]/g, " ")
.replace(/\b\w/g, (l) => l.toUpperCase());
}
}
function extractDescription(filePath) {
try {
const content = fs.readFileSync(filePath, "utf8");
// Parse frontmatter for description (for both prompts and instructions)
const lines = content.split("\n");
let inFrontmatter = false;
let frontmatterEnded = false;
// For multi-line descriptions
let isMultilineDescription = false;
let multilineDescription = [];
for (let i = 0; i < lines.length; i++) {
const line = lines[i];
if (line.trim() === "---") {
if (!inFrontmatter) {
inFrontmatter = true;
} else if (inFrontmatter && !frontmatterEnded) {
frontmatterEnded = true;
break;
}
continue;
}
if (inFrontmatter && !frontmatterEnded) {
// Check for multi-line description with pipe syntax (|)
const multilineMatch = line.match(/^description:\s*\|(\s*)$/);
if (multilineMatch) {
isMultilineDescription = true;
// Continue to next line to start collecting the multi-line content
continue;
}
// If we're collecting a multi-line description
if (isMultilineDescription) {
// If the line has no indentation or has another frontmatter key, stop collecting
if (!line.startsWith(" ") || line.match(/^[a-zA-Z0-9_-]+:/)) {
isMultilineDescription = false;
// Join the collected lines and return
return multilineDescription.join(" ").trim();
}
// Add the line to our multi-line collection (removing the 2-space indentation)
multilineDescription.push(line.substring(2));
} else {
// Look for single-line description field in frontmatter
const descriptionMatch = line.match(
/^description:\s*['"]?(.+?)['"]?$/
);
if (descriptionMatch) {
return descriptionMatch[1];
}
}
}
}
// If we've collected multi-line description but the frontmatter ended
if (multilineDescription.length > 0) {
return multilineDescription.join(" ").trim();
}
return null;
} catch (error) {
return null;
}
}
function generateReadme() {
const instructionsDir = path.join(__dirname, "instructions");
const promptsDir = path.join(__dirname, "prompts");
const readmePath = path.join(__dirname, "README.md");
// Check if README file exists
if (!fs.existsSync(readmePath)) {
console.error(
"README.md not found! Please create a base README.md file first."
);
process.exit(1);
}
// Read the current README content
let currentReadme = fs.readFileSync(readmePath, "utf8");
// Get all instruction files
const instructionFiles = fs
.readdirSync(instructionsDir)
.filter((file) => file.endsWith(".md"))
.sort();
// Get all prompt files - we'll use this to find new prompts
const promptFiles = fs
.readdirSync(promptsDir)
.filter((file) => file.endsWith(".prompt.md"))
.sort();
// Update instructions section - rebuild the whole list
const instructionsSection = currentReadme.match(
/## 📋 Custom Instructions\n\nTeam and project-specific instructions.+?(?=\n\n>)/s
);
if (instructionsSection) {
let instructionsListContent = "\n\n";
// Generate alphabetically sorted list of instruction links
for (const file of instructionFiles) {
const filePath = path.join(instructionsDir, file);
const title = extractTitle(filePath);
const link = `instructions/${file}`;
// Check if there's a description in the frontmatter
const customDescription = extractDescription(filePath);
if (customDescription) {
// Use the description from frontmatter
instructionsListContent += `- [${title}](${link}) - ${customDescription}\n`;
} else {
// Fallback to the default approach - use last word of title for description, removing trailing 's' if present
const topic = title.split(" ").pop().replace(/s$/, "");
instructionsListContent += `- [${title}](${link}) - ${topic} specific coding standards and best practices\n`;
}
}
// Replace the current instructions section with the updated one
const newInstructionsSection =
"## 📋 Custom Instructions\n\nTeam and project-specific instructions to enhance GitHub Copilot's behavior for specific technologies and coding practices:" +
instructionsListContent;
currentReadme = currentReadme.replace(
instructionsSection[0],
newInstructionsSection
);
}
// Extract existing prompt links from README
const existingPromptLinks = [];
const promptLinkRegex = /\[.*?\]\(prompts\/(.+?)\)/g;
let match;
while ((match = promptLinkRegex.exec(currentReadme)) !== null) {
existingPromptLinks.push(match[1]);
}
// Find new prompts that aren't already in the README
const newPromptFiles = promptFiles.filter(
(file) => !existingPromptLinks.includes(file)
);
if (newPromptFiles.length === 0) {
console.log("No new prompts to add.");
return currentReadme; // No changes needed
}
console.log(`Found ${newPromptFiles.length} new prompts to add.`);
// Create content for new prompts (in Uncategorised section)
let newPromptsContent = "";
// Check if we already have an Uncategorised section
const uncategorisedSectionRegex = /### Uncategorised\n/;
const hasUncategorisedSection = uncategorisedSectionRegex.test(currentReadme);
// If we need to add the section header
if (!hasUncategorisedSection) {
newPromptsContent += "### Uncategorised\n";
}
// Add each new prompt
for (const file of newPromptFiles) {
const filePath = path.join(promptsDir, file);
const title = extractTitle(filePath);
const description = extractDescription(filePath);
const link = `prompts/${file}`;
if (description) {
newPromptsContent += `- [${title}](${link}) - ${description}\n`;
} else {
newPromptsContent += `- [${title}](${link})\n`;
}
}
// Add a newline if we created a new section
if (!hasUncategorisedSection) {
newPromptsContent += "\n";
}
// Update the README content - insert new content in the right place
if (hasUncategorisedSection) {
// Add to existing Uncategorised section
const uncategorisedSectionPos = currentReadme.match(
uncategorisedSectionRegex
).index;
const sectionEndRegex = /\n\n/;
let sectionEndMatch = sectionEndRegex.exec(
currentReadme.slice(uncategorisedSectionPos + 16)
); // 16 is length of "### Uncategorised\n"
let insertPos;
if (sectionEndMatch) {
insertPos = uncategorisedSectionPos + 16 + sectionEndMatch.index;
} else {
// If we can't find the end of the section, just insert at the end of the section header
insertPos = uncategorisedSectionPos + 16;
}
currentReadme =
currentReadme.slice(0, insertPos) +
newPromptsContent +
currentReadme.slice(insertPos);
} else {
// No Uncategorised section exists yet - find where to add it
// Look for the "Ready-to-use prompt templates" section and the next section after it
const promptSectionRegex =
/## 🎯 Reusable Prompts\n\nReady-to-use prompt templates/;
const promptSectionMatch = currentReadme.match(promptSectionRegex);
if (promptSectionMatch) {
// Find where to insert the new section - after any existing categories
let insertPos;
// First check if there are any existing categories
const existingCategoriesRegex = /### [^\n]+\n/g;
let lastCategoryMatch = null;
while ((match = existingCategoriesRegex.exec(currentReadme)) !== null) {
lastCategoryMatch = match;
}
if (lastCategoryMatch) {
// Find the end of the last category section
const afterLastCategory = currentReadme.slice(
lastCategoryMatch.index + lastCategoryMatch[0].length
);
const nextSectionRegex = /\n\n>/;
const nextSectionMatch = afterLastCategory.match(nextSectionRegex);
if (nextSectionMatch) {
insertPos =
lastCategoryMatch.index +
lastCategoryMatch[0].length +
nextSectionMatch.index;
} else {
// If we can't find the next section, add at the end of the prompt section
insertPos = currentReadme.indexOf(
"> 💡 **Usage**: Use `/prompt-name`"
);
if (insertPos === -1) {
// Fallback position - before Additional Resources
insertPos = currentReadme.indexOf("## 📚 Additional Resources");
}
}
} else {
// No categories yet, add right after the intro text
const afterIntroRegex = /prompt\` command\.\n\n/;
const afterIntroMatch = currentReadme.match(afterIntroRegex);
if (afterIntroMatch) {
insertPos = afterIntroMatch.index + afterIntroMatch[0].length;
} else {
// Fallback position - before Additional Resources
insertPos = currentReadme.indexOf("## 📚 Additional Resources");
}
}
if (insertPos !== -1) {
currentReadme =
currentReadme.slice(0, insertPos) +
newPromptsContent +
currentReadme.slice(insertPos);
} else {
console.error("Could not find a suitable place to insert new prompts.");
}
} else {
console.error(
"Could not find the Reusable Prompts section in the README."
);
}
}
return currentReadme;
}
// Generate and write the README
const updatedReadme = generateReadme();
// Only write file if we have content to write
if (updatedReadme) {
fs.writeFileSync(path.join(__dirname, "README.md"), updatedReadme);
console.log("README.md updated successfully!");
}