Merge branch 'main' into main
This commit is contained in:
Aaron Powell
GitHub
commit
5e195d2634
10
README.md
10
README.md
@ -6,7 +6,7 @@ Enhance your GitHub Copilot experience with community-contributed instructions,
|
||||
|
||||
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** |
|
||||
| **📋 [Custom Instructions](#-custom-instructions)** | **🎯 [Reusable Prompts](#-reusable-prompts)** | **🧩 [Custom Chat Modes](#-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 |
|
||||
|
||||
@ -38,6 +38,7 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
|
||||
| [Generate Modern Terraform Code For Azure](instructions/generate-modern-terraform-code-for-azure.instructions.md) | Guidelines for generating modern Terraform code for Azure | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgenerate-modern-terraform-code-for-azure.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgenerate-modern-terraform-code-for-azure.instructions.md) |
|
||||
| [GitHub Actions CI/CD Best Practices](instructions/github-actions-ci-cd-best-practices.instructions.md) | Comprehensive guide for building robust, secure, and efficient CI/CD pipelines using GitHub Actions. Covers workflow structure, jobs, steps, environment variables, secret management, caching, matrix strategies, testing, and deployment strategies. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgithub-actions-ci-cd-best-practices.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgithub-actions-ci-cd-best-practices.instructions.md) |
|
||||
| [Go Development Instructions](instructions/go.instructions.md) | Instructions for writing Go code following idiomatic Go practices and community standards | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgo.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgo.instructions.md) |
|
||||
| [Java Development](instructions/java.instructions.md) | Guidelines for building Java base applications | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fjava.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fjava.instructions.md) |
|
||||
| [Kubernetes Deployment Best Practices](instructions/kubernetes-deployment-best-practices.instructions.md) | Comprehensive best practices for deploying and managing applications on Kubernetes. Covers Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, health checks, resource limits, scaling, and security contexts. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fkubernetes-deployment-best-practices.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fkubernetes-deployment-best-practices.instructions.md) |
|
||||
| [Guidance for Localization](instructions/localization.instructions.md) | Guidelines for localizing markdown documents | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Flocalization.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Flocalization.instructions.md) |
|
||||
| [Markdown](instructions/markdown.instructions.md) | Documentation and content creation standards | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmarkdown.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmarkdown.instructions.md) |
|
||||
@ -47,7 +48,9 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
|
||||
| [PowerShell Cmdlet Development Guidelines](instructions/powershell.instructions.md) | PowerShell cmdlet and scripting best practices based on Microsoft guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell.instructions.md) |
|
||||
| [Python Coding Conventions](instructions/python.instructions.md) | Python coding conventions and guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpython.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpython.instructions.md) |
|
||||
| [Quarkus](instructions/quarkus.instructions.md) | Quarkus development standards and instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fquarkus.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fquarkus.instructions.md) |
|
||||
| [Ruby on Rails](instructions/ruby-on-rails.instructions.md) | Ruby on Rails coding conventions and guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fruby-on-rails.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fruby-on-rails.instructions.md) |
|
||||
| [Secure Coding and OWASP Guidelines](instructions/security-and-owasp.instructions.md) | Comprehensive secure coding instructions for all languages and frameworks, based on OWASP Top 10 and industry best practices. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fsecurity-and-owasp.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fsecurity-and-owasp.instructions.md) |
|
||||
| [Spring Boot Development](instructions/springboot.instructions.md) | Guidelines for building Spring Boot base applications | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fspringboot.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fspringboot.instructions.md) |
|
||||
| [Taming Copilot](instructions/taming-copilot.instructions.md) | Prevent Copilot from wreaking havoc across your codebase, keeping it under control. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftaming-copilot.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftaming-copilot.instructions.md) |
|
||||
| [TanStack Start with Shadcn/ui Development Guide](instructions/tanstack-start-shadcn-tailwind.md) | Guidelines for building TanStack Start applications | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftanstack-start-shadcn-tailwind.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftanstack-start-shadcn-tailwind.md) |
|
||||
|
||||
@ -61,6 +64,7 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| ----- | ----------- | ------- |
|
||||
| [ASP.NET Minimal API with OpenAPI](prompts/aspnet-minimal-api-openapi.prompt.md) | Create ASP.NET Minimal API endpoints with proper OpenAPI documentation | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Faspnet-minimal-api-openapi.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Faspnet-minimal-api-openapi.prompt.md) |
|
||||
| [Azure Cost Optimize](prompts/az-cost-optimize.prompt.md) | Analyze Azure resources used in the app (IaC files and/or resources in a target rg) and optimize costs - creating GitHub issues for identified optimizations. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Faz-cost-optimize.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Faz-cost-optimize.prompt.md) |
|
||||
| [Azure Resource Health & Issue Diagnosis](prompts/azure-resource-health-diagnose.prompt.md) | Analyze Azure resource health, diagnose issues from logs and telemetry, and create a remediation plan for identified problems. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fazure-resource-health-diagnose.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fazure-resource-health-diagnose.prompt.md) |
|
||||
| [Comment Code Generate A Tutorial](prompts/comment-code-generate-a-tutorial.prompt.md) | Transform this Python script into a polished, beginner-friendly project by refactoring the code, adding clear instructional comments, and generating a complete markdown tutorial. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcomment-code-generate-a-tutorial.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcomment-code-generate-a-tutorial.prompt.md) |
|
||||
| [Create Architectural Decision Record](prompts/create-architectural-decision-record.prompt.md) | Create an Architectural Decision Record (ADR) document for AI-optimized decision documentation. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-architectural-decision-record.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-architectural-decision-record.prompt.md) |
|
||||
| [Create GitHub Issue from Specification](prompts/create-github-issue-feature-from-specification.prompt.md) | Create GitHub Issue for feature request from specification file using feature_request.yml template. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issue-feature-from-specification.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issue-feature-from-specification.prompt.md) |
|
||||
@ -81,7 +85,11 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [.NET/C# Design Pattern Review](prompts/dotnet-design-pattern-review.prompt.md) | Review the C#/.NET code for design pattern implementation and suggest improvements. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fdotnet-design-pattern-review.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fdotnet-design-pattern-review.prompt.md) |
|
||||
| [Entity Framework Core Best Practices](prompts/ef-core.prompt.md) | Get best practices for Entity Framework Core | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fef-core.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fef-core.prompt.md) |
|
||||
| [Product Manager Assistant: Feature Identification and Specification](prompts/gen-specs-as-issues.prompt.md) | This workflow guides you through a systematic approach to identify missing features, prioritize them, and create detailed specifications for implementation. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fgen-specs-as-issues.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fgen-specs-as-issues.prompt.md) |
|
||||
| [Java Documentation (Javadoc) Best Practices](prompts/java-docs.prompt.md) | Ensure that Java types are documented with Javadoc comments and follow best practices for documentation. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-docs.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-docs.prompt.md) |
|
||||
| [JUnit 5+ Best Practices](prompts/java-junit.prompt.md) | Get best practices for JUnit 5 unit testing, including data-driven tests | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-junit.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-junit.prompt.md) |
|
||||
| [Spring Boot Best Practices](prompts/java-springboot.prompt.md) | Get best practices for developing applications with Spring Boot. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-springboot.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjava-springboot.prompt.md) |
|
||||
| [Javascript Typescript Jest](prompts/javascript-typescript-jest.prompt.md) | Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjavascript-typescript-jest.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjavascript-typescript-jest.prompt.md) |
|
||||
| [Spring Boot with Kotlin Best Practices](prompts/kotlin-springboot.prompt.md) | Get best practices for developing applications with Spring Boot and Kotlin. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fkotlin-springboot.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fkotlin-springboot.prompt.md) |
|
||||
| [Multi Stage Dockerfile](prompts/multi-stage-dockerfile.prompt.md) | Create optimized multi-stage Dockerfiles for any language or framework | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmulti-stage-dockerfile.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmulti-stage-dockerfile.prompt.md) |
|
||||
| [My Issues](prompts/my-issues.prompt.md) | List my issues in the current repository | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-issues.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-issues.prompt.md) |
|
||||
| [My Pull Requests](prompts/my-pull-requests.prompt.md) | List my pull requests in the current repository | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-pull-requests.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fmy-pull-requests.prompt.md) |
|
||||
|
||||
64
instructions/java.instructions.md
Normal file
64
instructions/java.instructions.md
Normal file
@ -0,0 +1,64 @@
|
||||
---
|
||||
description: 'Guidelines for building Java base applications'
|
||||
applyTo: '**/*.java'
|
||||
---
|
||||
|
||||
# Java Development
|
||||
|
||||
## General Instructions
|
||||
|
||||
- First, prompt the user if they want to integrate static analysis tools (SonarQube, PMD, Checkstyle)
|
||||
into their project setup. If yes, provide guidance on tool selection and configuration.
|
||||
- If the user declines static analysis tools or wants to proceed without them, continue with implementing the Best practices, bug patterns and code smell prevention guidelines outlined below.
|
||||
- Address code smells proactively during development rather than accumulating technical debt.
|
||||
- Focus on readability, maintainability, and performance when refactoring identified issues.
|
||||
- Use IDE / Code editor reported warnings and suggestions to catch common patterns early in development.
|
||||
|
||||
## Best practices
|
||||
|
||||
- **Records**: For classes primarily intended to store data (e.g., DTOs, immutable data structures), **Java Records should be used instead of traditional classes**.
|
||||
- **Pattern Matching**: Utilize pattern matching for `instanceof` and `switch` expression to simplify conditional logic and type casting.
|
||||
- **Type Inference**: Use `var` for local variable declarations to improve readability, but only when the type is explicitly clear from the right-hand side of the expression.
|
||||
- **Immutability**: Favor immutable objects. Make classes and fields `final` where possible. Use collections from `List.of()`/`Map.of()` for fixed data. Use `Stream.toList()` to create immutable lists.
|
||||
- **Streams and Lambdas**: Use the Streams API and lambda expressions for collection processing. Employ method references (e.g., `stream.map(Foo::toBar)`).
|
||||
- **Null Handling**: Avoid returning or accepting `null`. Use `Optional<T>` for possibly-absent values and `Objects` utility methods like `equals()` and `requireNonNull()`.
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
- Follow Google's Java style guide:
|
||||
- `UpperCamelCase` for class and interface names.
|
||||
- `lowerCamelCase` for method and variable names.
|
||||
- `UPPER_SNAKE_CASE` for constants.
|
||||
- `lowercase` for package names.
|
||||
- Use nouns for classes (`UserService`) and verbs for methods (`getUserById`).
|
||||
- Avoid abbreviations and Hungarian notation.
|
||||
|
||||
### Bug Patterns
|
||||
|
||||
| Rule ID | Description | Example / Notes |
|
||||
| ------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
|
||||
| `S2095` | Resources should be closed | Use try-with-resources when working with streams, files, sockets, etc. |
|
||||
| `S1698` | Objects should be compared with `.equals()` instead of `==` | Especially important for Strings and boxed primitives. |
|
||||
| `S1905` | Redundant casts should be removed | Clean up unnecessary or unsafe casts. |
|
||||
| `S3518` | Conditions should not always evaluate to true or false | Watch for infinite loops or if-conditions that never change. |
|
||||
| `S108` | Unreachable code should be removed | Code after `return`, `throw`, etc., must be cleaned up. |
|
||||
|
||||
## Code Smells
|
||||
|
||||
| Rule ID | Description | Example / Notes |
|
||||
| ------- | ------------------------------------------------------ | ----------------------------------------------------------------------------- |
|
||||
| `S107` | Methods should not have too many parameters | Refactor into helper classes or use builder pattern. |
|
||||
| `S121` | Duplicated blocks of code should be removed | Consolidate logic into shared methods. |
|
||||
| `S138` | Methods should not be too long | Break complex logic into smaller, testable units. |
|
||||
| `S3776` | Cognitive complexity should be reduced | Simplify nested logic, extract methods, avoid deep `if` trees. |
|
||||
| `S1192` | String literals should not be duplicated | Replace with constants or enums. |
|
||||
| `S1854` | Unused assignments should be removed | Avoid dead variables—remove or refactor. |
|
||||
| `S109` | Magic numbers should be replaced with constants | Improves readability and maintainability. |
|
||||
| `S1188` | Catch blocks should not be empty | Always log or handle exceptions meaningfully. |
|
||||
|
||||
## Build and Verification
|
||||
|
||||
- After adding or modifying code, verify the project continues to build successfully.
|
||||
- If the project uses Maven, run `mvn clean install`.
|
||||
- If the project uses Gradle, run `./gradlew build` (or `gradlew.bat build` on Windows).
|
||||
- Ensure all tests pass as part of the build.
|
||||
124
instructions/ruby-on-rails.instructions.md
Normal file
124
instructions/ruby-on-rails.instructions.md
Normal file
@ -0,0 +1,124 @@
|
||||
---
|
||||
description: 'Ruby on Rails coding conventions and guidelines'
|
||||
applyTo: '**/*.rb'
|
||||
---
|
||||
|
||||
# Ruby on Rails
|
||||
|
||||
## General Guidelines
|
||||
|
||||
- Follow the RuboCop Style Guide and use tools like `rubocop`, `standardrb`, or `rufo` for consistent formatting.
|
||||
- Use snake_case for variables/methods and CamelCase for classes/modules.
|
||||
- Keep methods short and focused; use early returns, guard clauses, and private methods to reduce complexity.
|
||||
- Favor meaningful names over short or generic ones.
|
||||
- Comment only when necessary — avoid explaining the obvious.
|
||||
- Apply the Single Responsibility Principle to classes, methods, and modules.
|
||||
- Prefer composition over inheritance; extract reusable logic into modules or services.
|
||||
- Keep controllers thin — move business logic into models, services, or command/query objects.
|
||||
- Apply the “fat model, skinny controller” pattern thoughtfully and with clean abstractions.
|
||||
- Extract business logic into service objects for reusability and testability.
|
||||
- Use partials or view components to reduce duplication and simplify views.
|
||||
- Use `unless` for negative conditions, but avoid it with `else` for clarity.
|
||||
- Avoid deeply nested conditionals — favor guard clauses and method extractions.
|
||||
- Use safe navigation (`&.`) instead of multiple `nil` checks.
|
||||
- Prefer `.present?`, `.blank?`, and `.any?` over manual nil/empty checks.
|
||||
- Follow RESTful conventions in routing and controller actions.
|
||||
- Use Rails generators to scaffold resources consistently.
|
||||
- Use strong parameters to whitelist attributes securely.
|
||||
- Prefer enums and typed attributes for better model clarity and validations.
|
||||
- Keep migrations database-agnostic; avoid raw SQL when possible.
|
||||
- Always add indexes for foreign keys and frequently queried columns.
|
||||
- Define `null: false` and `unique: true` at the DB level, not just in models.
|
||||
- Use `find_each` for iterating over large datasets to reduce memory usage.
|
||||
- Scope queries in models or use query objects for clarity and reuse.
|
||||
- Use `before_action` callbacks sparingly — avoid business logic in them.
|
||||
- Use `Rails.cache` to store expensive computations or frequently accessed data.
|
||||
- Construct file paths with `Rails.root.join(...)` instead of hardcoding.
|
||||
- Use `class_name` and `foreign_key` in associations for explicit relationships.
|
||||
- Keep secrets and config out of the codebase using `Rails.application.credentials` or ENV variables.
|
||||
- Write isolated unit tests for models, services, and helpers.
|
||||
- Cover end-to-end logic with request/system tests.
|
||||
- Use background jobs (ActiveJob) for non-blocking operations like sending emails or calling APIs.
|
||||
- Use `FactoryBot` (RSpec) or fixtures (Minitest) to set up test data cleanly.
|
||||
- Avoid using `puts` — debug with `byebug`, `pry`, or logger utilities.
|
||||
- Document complex code paths and methods with YARD or RDoc.
|
||||
|
||||
## App Directory Structure
|
||||
|
||||
- Define service objects in the `app/services` directory to encapsulate business logic.
|
||||
- Use form objects located in `app/forms` to manage validation and submission logic.
|
||||
- Implement JSON serializers in the `app/serializers` directory to format API responses.
|
||||
- Define authorization policies in `app/policies` to control user access to resources.
|
||||
- Structure the GraphQL API by organizing schemas, queries, and mutations inside `app/graphql`.
|
||||
- Create custom validators in `app/validators` to enforce specialized validation logic.
|
||||
- Isolate and encapsulate complex ActiveRecord queries in `app/queries` for better reuse and testability.
|
||||
- Define custom data types and coercion logic in the `app/types` directory to extend or override ActiveModel type behavior.
|
||||
|
||||
## Commands
|
||||
|
||||
- Use `rails generate` to create new models, controllers, and migrations.
|
||||
- Use `rails db:migrate` to apply database migrations.
|
||||
- Use `rails db:seed` to populate the database with initial data.
|
||||
- Use `rails db:rollback` to revert the last migration.
|
||||
- Use `rails console` to interact with the Rails application in a REPL environment.
|
||||
- Use `rails server` to start the development server.
|
||||
- Use `rails test` to run the test suite.
|
||||
- Use `rails routes` to list all defined routes in the application.
|
||||
- Use `rails assets:precompile` to compile assets for production.
|
||||
|
||||
|
||||
## API Development Best Practices
|
||||
|
||||
- Structure routes using Rails' `resources` to follow RESTful conventions.
|
||||
- Use namespaced routes (e.g., `/api/v1/`) for versioning and forward compatibility.
|
||||
- Serialize responses using `ActiveModel::Serializer` or `fast_jsonapi` for consistent output.
|
||||
- Return proper HTTP status codes for each response (e.g., 200 OK, 201 Created, 422 Unprocessable Entity).
|
||||
- Use `before_action` filters to load and authorize resources, not business logic.
|
||||
- Leverage pagination (e.g., `kaminari` or `pagy`) for endpoints returning large datasets.
|
||||
- Rate limit and throttle sensitive endpoints using middleware or gems like `rack-attack`.
|
||||
- Return errors in a structured JSON format including error codes, messages, and details.
|
||||
- Sanitize and whitelist input parameters using strong parameters.
|
||||
- Use custom serializers or presenters to decouple internal logic from response formatting.
|
||||
- Avoid N+1 queries by using `includes` when eager loading related data.
|
||||
- Implement background jobs for non-blocking tasks like sending emails or syncing with external APIs.
|
||||
- Log request/response metadata for debugging, observability, and auditing.
|
||||
- Document endpoints using OpenAPI (Swagger), `rswag`, or `apipie-rails`.
|
||||
- Use CORS headers (`rack-cors`) to allow cross-origin access to your API when needed.
|
||||
- Ensure sensitive data is never exposed in API responses or error messages.
|
||||
|
||||
## Frontend Development Best Practices
|
||||
|
||||
- Use `app/javascript` as the main directory for managing JavaScript packs, modules, and frontend logic in Rails 6+ with Webpacker or esbuild.
|
||||
- Structure your JavaScript by components or domains, not by file types, to keep things modular.
|
||||
- Leverage Hotwire (Turbo + Stimulus) for real-time updates and minimal JavaScript in Rails-native apps.
|
||||
- Use Stimulus controllers for binding behavior to HTML and managing UI logic declaratively.
|
||||
- Organize styles using SCSS modules, Tailwind, or BEM conventions under `app/assets/stylesheets`.
|
||||
- Keep view logic clean by extracting repetitive markup into partials or components.
|
||||
- Use semantic HTML tags and follow accessibility (a11y) best practices across all views.
|
||||
- Avoid inline JavaScript and styles; instead, move logic to separate `.js` or `.scss` files for clarity and reusability.
|
||||
- Optimize assets (images, fonts, icons) using the asset pipeline or bundlers for caching and compression.
|
||||
- Use `data-*` attributes to bridge frontend interactivity with Rails-generated HTML and Stimulus.
|
||||
- Test frontend functionality using system tests (Capybara) or integration tests with tools like Cypress or Playwright.
|
||||
- Use environment-specific asset loading to prevent unnecessary scripts or styles in production.
|
||||
- Follow a design system or component library to keep UI consistent and scalable.
|
||||
- Optimize time-to-first-paint (TTFP) and asset loading using lazy loading, Turbo Frames, and deferring JS.
|
||||
|
||||
## Testing Guidelines
|
||||
|
||||
- Write unit tests for models using `test/models` (Minitest) or `spec/models` (RSpec) to validate business logic.
|
||||
- Use fixtures (Minitest) or factories with `FactoryBot` (RSpec) to manage test data cleanly and consistently.
|
||||
- Organize controller specs under `test/controllers` or `spec/requests` to test RESTful API behavior.
|
||||
- Prefer `before` blocks in RSpec or `setup` in Minitest to initialize common test data.
|
||||
- Avoid hitting external APIs in tests — use `WebMock`, `VCR`, or `stub_request` to isolate test environments.
|
||||
- Use `system tests` in Minitest or `feature specs` with Capybara in RSpec to simulate full user flows.
|
||||
- Isolate slow and expensive tests (e.g., external services, file uploads) into separate test types or tags.
|
||||
- Run test coverage tools like `SimpleCov` to ensure adequate code coverage.
|
||||
- Avoid `sleep` in tests; use `perform_enqueued_jobs` (Minitest) or `ActiveJob::TestHelper` with RSpec.
|
||||
- Use database cleaning tools (`rails test:prepare`, `DatabaseCleaner`, or `transactional_fixtures`) to maintain clean state between tests.
|
||||
- Test background jobs by enqueuing and performing jobs using `ActiveJob::TestHelper` or `have_enqueued_job` matchers.
|
||||
- Ensure tests run consistently across environments using CI tools (e.g., GitHub Actions, CircleCI).
|
||||
- Use custom matchers (RSpec) or custom assertions (Minitest) for reusable and expressive test logic.
|
||||
- Tag tests by type (e.g., `:model`, `:request`, `:feature`) for faster and targeted test runs.
|
||||
- Avoid brittle tests — don’t rely on specific timestamps, randomized data, or order unless explicitly necessary.
|
||||
- Write integration tests for end-to-end flows across multiple layers (model, view, controller).
|
||||
- Keep tests fast, reliable, and as DRY as production code.
|
||||
58
instructions/springboot.instructions.md
Normal file
58
instructions/springboot.instructions.md
Normal file
@ -0,0 +1,58 @@
|
||||
---
|
||||
description: 'Guidelines for building Spring Boot base applications'
|
||||
applyTo: '**/*.java, **/*.kt'
|
||||
---
|
||||
|
||||
# Spring Boot Development
|
||||
|
||||
## General Instructions
|
||||
|
||||
- Make only high confidence suggestions when reviewing code changes.
|
||||
- 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.
|
||||
|
||||
## Spring Boot Instructions
|
||||
|
||||
### Dependency Injection
|
||||
|
||||
- Use constructor injection for all required dependencies.
|
||||
- Declare dependency fields as `private final`.
|
||||
|
||||
### Configuration
|
||||
|
||||
- Use YAML files (`application.yml`) for externalized configuration.
|
||||
- Environment Profiles: Use Spring profiles for different environments (dev, test, prod)
|
||||
- Configuration Properties: Use @ConfigurationProperties for type-safe configuration binding
|
||||
- Secrets Management: Externalize secrets using environment variables or secret management systems
|
||||
|
||||
### Code Organization
|
||||
|
||||
- Package Structure: Organize by feature/domain rather than by layer
|
||||
- Separation of Concerns: Keep controllers thin, services focused, and repositories simple
|
||||
- Utility Classes: Make utility classes final with private constructors
|
||||
|
||||
### Service Layer
|
||||
|
||||
- Place business logic in `@Service`-annotated classes.
|
||||
- Services should be stateless and testable.
|
||||
- Inject repositories via the constructor.
|
||||
- Service method signatures should use domain IDs or DTOs, not expose repository entities directly unless necessary.
|
||||
|
||||
### Logging
|
||||
|
||||
- Use SLF4J for all logging (`private static final Logger logger = LoggerFactory.getLogger(MyClass.class);`).
|
||||
- Do not use concrete implementations (Logback, Log4j2) or `System.out.println()` directly.
|
||||
- Use parameterized logging: `logger.info("User {} logged in", userId);`.
|
||||
|
||||
### Security & Input Handling
|
||||
|
||||
- Use parameterized queries | Always use Spring Data JPA or `NamedParameterJdbcTemplate` to prevent SQL injection.
|
||||
- Validate request bodies and parameters using JSR-380 (`@NotNull`, `@Size`, etc.) annotations and `BindingResult`
|
||||
|
||||
## Build and Verification
|
||||
|
||||
- After adding or modifying code, verify the project continues to build successfully.
|
||||
- If the project uses Maven, run `mvn clean install`.
|
||||
- If the project uses Gradle, run `./gradlew build` (or `gradlew.bat build` on Windows).
|
||||
- Ensure all tests pass as part of the build.
|
||||
290
prompts/azure-resource-health-diagnose.prompt.md
Normal file
290
prompts/azure-resource-health-diagnose.prompt.md
Normal file
@ -0,0 +1,290 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Analyze Azure resource health, diagnose issues from logs and telemetry, and create a remediation plan for identified problems.'
|
||||
---
|
||||
|
||||
# Azure Resource Health & Issue Diagnosis
|
||||
|
||||
This workflow analyzes a specific Azure resource to assess its health status, diagnose potential issues using logs and telemetry data, and develop a comprehensive remediation plan for any problems discovered.
|
||||
|
||||
## Prerequisites
|
||||
- Azure MCP server configured and authenticated
|
||||
- Target Azure resource identified (name and optionally resource group/subscription)
|
||||
- Resource must be deployed and running to generate logs/telemetry
|
||||
- Prefer Azure MCP tools (`azmcp-*`) over direct Azure CLI when available
|
||||
|
||||
## Workflow Steps
|
||||
|
||||
### Step 1: Get Azure Best Practices
|
||||
**Action**: Retrieve diagnostic and troubleshooting best practices
|
||||
**Tools**: Azure MCP best practices tool
|
||||
**Process**:
|
||||
1. **Load Best Practices**:
|
||||
- Execute Azure best practices tool to get diagnostic guidelines
|
||||
- Focus on health monitoring, log analysis, and issue resolution patterns
|
||||
- Use these practices to inform diagnostic approach and remediation recommendations
|
||||
|
||||
### Step 2: Resource Discovery & Identification
|
||||
**Action**: Locate and identify the target Azure resource
|
||||
**Tools**: Azure MCP tools + Azure CLI fallback
|
||||
**Process**:
|
||||
1. **Resource Lookup**:
|
||||
- If only resource name provided: Search across subscriptions using `azmcp-subscription-list`
|
||||
- Use `az resource list --name <resource-name>` to find matching resources
|
||||
- If multiple matches found, prompt user to specify subscription/resource group
|
||||
- Gather detailed resource information:
|
||||
- Resource type and current status
|
||||
- Location, tags, and configuration
|
||||
- Associated services and dependencies
|
||||
|
||||
2. **Resource Type Detection**:
|
||||
- Identify resource type to determine appropriate diagnostic approach:
|
||||
- **Web Apps/Function Apps**: Application logs, performance metrics, dependency tracking
|
||||
- **Virtual Machines**: System logs, performance counters, boot diagnostics
|
||||
- **Cosmos DB**: Request metrics, throttling, partition statistics
|
||||
- **Storage Accounts**: Access logs, performance metrics, availability
|
||||
- **SQL Database**: Query performance, connection logs, resource utilization
|
||||
- **Application Insights**: Application telemetry, exceptions, dependencies
|
||||
- **Key Vault**: Access logs, certificate status, secret usage
|
||||
- **Service Bus**: Message metrics, dead letter queues, throughput
|
||||
|
||||
### Step 3: Health Status Assessment
|
||||
**Action**: Evaluate current resource health and availability
|
||||
**Tools**: Azure MCP monitoring tools + Azure CLI
|
||||
**Process**:
|
||||
1. **Basic Health Check**:
|
||||
- Check resource provisioning state and operational status
|
||||
- Verify service availability and responsiveness
|
||||
- Review recent deployment or configuration changes
|
||||
- Assess current resource utilization (CPU, memory, storage, etc.)
|
||||
|
||||
2. **Service-Specific Health Indicators**:
|
||||
- **Web Apps**: HTTP response codes, response times, uptime
|
||||
- **Databases**: Connection success rate, query performance, deadlocks
|
||||
- **Storage**: Availability percentage, request success rate, latency
|
||||
- **VMs**: Boot diagnostics, guest OS metrics, network connectivity
|
||||
- **Functions**: Execution success rate, duration, error frequency
|
||||
|
||||
### Step 4: Log & Telemetry Analysis
|
||||
**Action**: Analyze logs and telemetry to identify issues and patterns
|
||||
**Tools**: Azure MCP monitoring tools for Log Analytics queries
|
||||
**Process**:
|
||||
1. **Find Monitoring Sources**:
|
||||
- Use `azmcp-monitor-workspace-list` to identify Log Analytics workspaces
|
||||
- Locate Application Insights instances associated with the resource
|
||||
- Identify relevant log tables using `azmcp-monitor-table-list`
|
||||
|
||||
2. **Execute Diagnostic Queries**:
|
||||
Use `azmcp-monitor-log-query` with targeted KQL queries based on resource type:
|
||||
|
||||
**General Error Analysis**:
|
||||
```kql
|
||||
// Recent errors and exceptions
|
||||
union isfuzzy=true
|
||||
AzureDiagnostics,
|
||||
AppServiceHTTPLogs,
|
||||
AppServiceAppLogs,
|
||||
AzureActivity
|
||||
| where TimeGenerated > ago(24h)
|
||||
| where Level == "Error" or ResultType != "Success"
|
||||
| summarize ErrorCount=count() by Resource, ResultType, bin(TimeGenerated, 1h)
|
||||
| order by TimeGenerated desc
|
||||
```
|
||||
|
||||
**Performance Analysis**:
|
||||
```kql
|
||||
// Performance degradation patterns
|
||||
Perf
|
||||
| where TimeGenerated > ago(7d)
|
||||
| where ObjectName == "Processor" and CounterName == "% Processor Time"
|
||||
| summarize avg(CounterValue) by Computer, bin(TimeGenerated, 1h)
|
||||
| where avg_CounterValue > 80
|
||||
```
|
||||
|
||||
**Application-Specific Queries**:
|
||||
```kql
|
||||
// Application Insights - Failed requests
|
||||
requests
|
||||
| where timestamp > ago(24h)
|
||||
| where success == false
|
||||
| summarize FailureCount=count() by resultCode, bin(timestamp, 1h)
|
||||
| order by timestamp desc
|
||||
|
||||
// Database - Connection failures
|
||||
AzureDiagnostics
|
||||
| where ResourceProvider == "MICROSOFT.SQL"
|
||||
| where Category == "SQLSecurityAuditEvents"
|
||||
| where action_name_s == "CONNECTION_FAILED"
|
||||
| summarize ConnectionFailures=count() by bin(TimeGenerated, 1h)
|
||||
```
|
||||
|
||||
3. **Pattern Recognition**:
|
||||
- Identify recurring error patterns or anomalies
|
||||
- Correlate errors with deployment times or configuration changes
|
||||
- Analyze performance trends and degradation patterns
|
||||
- Look for dependency failures or external service issues
|
||||
|
||||
### Step 5: Issue Classification & Root Cause Analysis
|
||||
**Action**: Categorize identified issues and determine root causes
|
||||
**Process**:
|
||||
1. **Issue Classification**:
|
||||
- **Critical**: Service unavailable, data loss, security breaches
|
||||
- **High**: Performance degradation, intermittent failures, high error rates
|
||||
- **Medium**: Warnings, suboptimal configuration, minor performance issues
|
||||
- **Low**: Informational alerts, optimization opportunities
|
||||
|
||||
2. **Root Cause Analysis**:
|
||||
- **Configuration Issues**: Incorrect settings, missing dependencies
|
||||
- **Resource Constraints**: CPU/memory/disk limitations, throttling
|
||||
- **Network Issues**: Connectivity problems, DNS resolution, firewall rules
|
||||
- **Application Issues**: Code bugs, memory leaks, inefficient queries
|
||||
- **External Dependencies**: Third-party service failures, API limits
|
||||
- **Security Issues**: Authentication failures, certificate expiration
|
||||
|
||||
3. **Impact Assessment**:
|
||||
- Determine business impact and affected users/systems
|
||||
- Evaluate data integrity and security implications
|
||||
- Assess recovery time objectives and priorities
|
||||
|
||||
### Step 6: Generate Remediation Plan
|
||||
**Action**: Create a comprehensive plan to address identified issues
|
||||
**Process**:
|
||||
1. **Immediate Actions** (Critical issues):
|
||||
- Emergency fixes to restore service availability
|
||||
- Temporary workarounds to mitigate impact
|
||||
- Escalation procedures for complex issues
|
||||
|
||||
2. **Short-term Fixes** (High/Medium issues):
|
||||
- Configuration adjustments and resource scaling
|
||||
- Application updates and patches
|
||||
- Monitoring and alerting improvements
|
||||
|
||||
3. **Long-term Improvements** (All issues):
|
||||
- Architectural changes for better resilience
|
||||
- Preventive measures and monitoring enhancements
|
||||
- Documentation and process improvements
|
||||
|
||||
4. **Implementation Steps**:
|
||||
- Prioritized action items with specific Azure CLI commands
|
||||
- Testing and validation procedures
|
||||
- Rollback plans for each change
|
||||
- Monitoring to verify issue resolution
|
||||
|
||||
### Step 7: User Confirmation & Report Generation
|
||||
**Action**: Present findings and get approval for remediation actions
|
||||
**Process**:
|
||||
1. **Display Health Assessment Summary**:
|
||||
```
|
||||
🏥 Azure Resource Health Assessment
|
||||
|
||||
📊 Resource Overview:
|
||||
• Resource: [Name] ([Type])
|
||||
• Status: [Healthy/Warning/Critical]
|
||||
• Location: [Region]
|
||||
• Last Analyzed: [Timestamp]
|
||||
|
||||
🚨 Issues Identified:
|
||||
• Critical: X issues requiring immediate attention
|
||||
• High: Y issues affecting performance/reliability
|
||||
• Medium: Z issues for optimization
|
||||
• Low: N informational items
|
||||
|
||||
🔍 Top Issues:
|
||||
1. [Issue Type]: [Description] - Impact: [High/Medium/Low]
|
||||
2. [Issue Type]: [Description] - Impact: [High/Medium/Low]
|
||||
3. [Issue Type]: [Description] - Impact: [High/Medium/Low]
|
||||
|
||||
🛠️ Remediation Plan:
|
||||
• Immediate Actions: X items
|
||||
• Short-term Fixes: Y items
|
||||
• Long-term Improvements: Z items
|
||||
• Estimated Resolution Time: [Timeline]
|
||||
|
||||
❓ Proceed with detailed remediation plan? (y/n)
|
||||
```
|
||||
|
||||
2. **Generate Detailed Report**:
|
||||
```markdown
|
||||
# Azure Resource Health Report: [Resource Name]
|
||||
|
||||
**Generated**: [Timestamp]
|
||||
**Resource**: [Full Resource ID]
|
||||
**Overall Health**: [Status with color indicator]
|
||||
|
||||
## 🔍 Executive Summary
|
||||
[Brief overview of health status and key findings]
|
||||
|
||||
## 📊 Health Metrics
|
||||
- **Availability**: X% over last 24h
|
||||
- **Performance**: [Average response time/throughput]
|
||||
- **Error Rate**: X% over last 24h
|
||||
- **Resource Utilization**: [CPU/Memory/Storage percentages]
|
||||
|
||||
## 🚨 Issues Identified
|
||||
|
||||
### Critical Issues
|
||||
- **[Issue 1]**: [Description]
|
||||
- **Root Cause**: [Analysis]
|
||||
- **Impact**: [Business impact]
|
||||
- **Immediate Action**: [Required steps]
|
||||
|
||||
### High Priority Issues
|
||||
- **[Issue 2]**: [Description]
|
||||
- **Root Cause**: [Analysis]
|
||||
- **Impact**: [Performance/reliability impact]
|
||||
- **Recommended Fix**: [Solution steps]
|
||||
|
||||
## 🛠️ Remediation Plan
|
||||
|
||||
### Phase 1: Immediate Actions (0-2 hours)
|
||||
```bash
|
||||
# Critical fixes to restore service
|
||||
[Azure CLI commands with explanations]
|
||||
```
|
||||
|
||||
### Phase 2: Short-term Fixes (2-24 hours)
|
||||
```bash
|
||||
# Performance and reliability improvements
|
||||
[Azure CLI commands with explanations]
|
||||
```
|
||||
|
||||
### Phase 3: Long-term Improvements (1-4 weeks)
|
||||
```bash
|
||||
# Architectural and preventive measures
|
||||
[Azure CLI commands and configuration changes]
|
||||
```
|
||||
|
||||
## 📈 Monitoring Recommendations
|
||||
- **Alerts to Configure**: [List of recommended alerts]
|
||||
- **Dashboards to Create**: [Monitoring dashboard suggestions]
|
||||
- **Regular Health Checks**: [Recommended frequency and scope]
|
||||
|
||||
## ✅ Validation Steps
|
||||
- [ ] Verify issue resolution through logs
|
||||
- [ ] Confirm performance improvements
|
||||
- [ ] Test application functionality
|
||||
- [ ] Update monitoring and alerting
|
||||
- [ ] Document lessons learned
|
||||
|
||||
## 📝 Prevention Measures
|
||||
- [Recommendations to prevent similar issues]
|
||||
- [Process improvements]
|
||||
- [Monitoring enhancements]
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
- **Resource Not Found**: Provide guidance on resource name/location specification
|
||||
- **Authentication Issues**: Guide user through Azure authentication setup
|
||||
- **Insufficient Permissions**: List required RBAC roles for resource access
|
||||
- **No Logs Available**: Suggest enabling diagnostic settings and waiting for data
|
||||
- **Query Timeouts**: Break down analysis into smaller time windows
|
||||
- **Service-Specific Issues**: Provide generic health assessment with limitations noted
|
||||
|
||||
## Success Criteria
|
||||
- ✅ Resource health status accurately assessed
|
||||
- ✅ All significant issues identified and categorized
|
||||
- ✅ Root cause analysis completed for major problems
|
||||
- ✅ Actionable remediation plan with specific steps provided
|
||||
- ✅ Monitoring and prevention recommendations included
|
||||
- ✅ Clear prioritization of issues by business impact
|
||||
- ✅ Implementation steps include validation and rollback procedures
|
||||
@ -11,7 +11,7 @@ Your goal is to help me write effective unit tests with MSTest, covering both st
|
||||
## Project Setup
|
||||
|
||||
- Use a separate test project with naming convention `[ProjectName].Tests`
|
||||
- Reference Microsoft.NET.Test.Sdk, MSTest.TestAdapter, and MSTest.TestFramework packages
|
||||
- Reference MSTest package
|
||||
- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
|
||||
- Use .NET SDK test commands: `dotnet test` for running tests
|
||||
|
||||
@ -36,33 +36,32 @@ Your goal is to help me write effective unit tests with MSTest, covering both st
|
||||
|
||||
## Data-Driven Tests
|
||||
|
||||
- Use `[DataTestMethod]` combined with data source attributes
|
||||
- Use `[TestMethod]` 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
|
||||
- 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.Throws<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
|
||||
- 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
|
||||
- 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
|
||||
|
||||
24
prompts/java-docs.prompt.md
Normal file
24
prompts/java-docs.prompt.md
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'Ensure that Java types are documented with Javadoc comments and follow best practices for documentation.'
|
||||
---
|
||||
|
||||
# Java Documentation (Javadoc) Best Practices
|
||||
|
||||
- Public and protected members should be documented with Javadoc comments.
|
||||
- It is encouraged to document package-private and private members as well, especially if they are complex or not self-explanatory.
|
||||
- The first sentence of the Javadoc comment is the summary description. It should be a concise overview of what the method does and end with a period.
|
||||
- Use `@param` for method parameters. The description starts with a lowercase letter and does not end with a period.
|
||||
- Use `@return` for method return values.
|
||||
- Use `@throws` or `@exception` to document exceptions thrown by methods.
|
||||
- Use `@see` for references to other types or members.
|
||||
- Use `{@inheritDoc}` to inherit documentation from base classes or interfaces.
|
||||
- Unless there is major behavior change, in which case you should document the differences.
|
||||
- Use `@param <T>` for type parameters in generic types or methods.
|
||||
- Use `{@code}` for inline code snippets.
|
||||
- Use `<pre>{@code ... }</pre>` for code blocks.
|
||||
- Use `@since` to indicate when the feature was introduced (e.g., version number).
|
||||
- Use `@version` to specify the version of the member.
|
||||
- Use `@author` to specify the author of the code.
|
||||
- Use `@deprecated` to mark a member as deprecated and provide an alternative.
|
||||
64
prompts/java-junit.prompt.md
Normal file
64
prompts/java-junit.prompt.md
Normal file
@ -0,0 +1,64 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems', 'search']
|
||||
description: 'Get best practices for JUnit 5 unit testing, including data-driven tests'
|
||||
---
|
||||
|
||||
# JUnit 5+ Best Practices
|
||||
|
||||
Your goal is to help me write effective unit tests with JUnit 5, covering both standard and data-driven testing approaches.
|
||||
|
||||
## Project Setup
|
||||
|
||||
- Use a standard Maven or Gradle project structure.
|
||||
- Place test source code in `src/test/java`.
|
||||
- Include dependencies for `junit-jupiter-api`, `junit-jupiter-engine`, and `junit-jupiter-params` for parameterized tests.
|
||||
- Use build tool commands to run tests: `mvn test` or `gradle test`.
|
||||
|
||||
## Test Structure
|
||||
|
||||
- Test classes should have a `Test` suffix, e.g., `CalculatorTests` for a `Calculator` class.
|
||||
- Use `@Test` for test methods.
|
||||
- Follow the Arrange-Act-Assert (AAA) pattern.
|
||||
- Name tests using a descriptive convention, like `methodName_should_expectedBehavior_when_scenario`.
|
||||
- Use `@BeforeEach` and `@AfterEach` for per-test setup and teardown.
|
||||
- Use `@BeforeAll` and `@AfterAll` for per-class setup and teardown (must be static methods).
|
||||
- Use `@DisplayName` to provide a human-readable name for test classes and methods.
|
||||
|
||||
## Standard Tests
|
||||
|
||||
- Keep tests focused on a single behavior.
|
||||
- Avoid testing multiple conditions in one test method.
|
||||
- Make tests independent and idempotent (can run in any order).
|
||||
- Avoid test interdependencies.
|
||||
|
||||
## Data-Driven (Parameterized) Tests
|
||||
|
||||
- Use `@ParameterizedTest` to mark a method as a parameterized test.
|
||||
- Use `@ValueSource` for simple literal values (strings, ints, etc.).
|
||||
- Use `@MethodSource` to refer to a factory method that provides test arguments as a `Stream`, `Collection`, etc.
|
||||
- Use `@CsvSource` for inline comma-separated values.
|
||||
- Use `@CsvFileSource` to use a CSV file from the classpath.
|
||||
- Use `@EnumSource` to use enum constants.
|
||||
|
||||
## Assertions
|
||||
|
||||
- Use the static methods from `org.junit.jupiter.api.Assertions` (e.g., `assertEquals`, `assertTrue`, `assertNotNull`).
|
||||
- For more fluent and readable assertions, consider using a library like AssertJ (`assertThat(...).is...`).
|
||||
- Use `assertThrows` or `assertDoesNotThrow` to test for exceptions.
|
||||
- Group related assertions with `assertAll` to ensure all assertions are checked before the test fails.
|
||||
- Use descriptive messages in assertions to provide clarity on failure.
|
||||
|
||||
## Mocking and Isolation
|
||||
|
||||
- Use a mocking framework like Mockito to create mock objects for dependencies.
|
||||
- Use `@Mock` and `@InjectMocks` annotations from Mockito to simplify mock creation and injection.
|
||||
- Use interfaces to facilitate mocking.
|
||||
|
||||
## Test Organization
|
||||
|
||||
- Group tests by feature or component using packages.
|
||||
- Use `@Tag` to categorize tests (e.g., `@Tag("fast")`, `@Tag("integration")`).
|
||||
- Use `@TestMethodOrder(MethodOrderer.OrderAnnotation.class)` and `@Order` to control test execution order when strictly necessary.
|
||||
- Use `@Disabled` to temporarily skip a test method or class, providing a reason.
|
||||
- Use `@Nested` to group tests in a nested inner class for better organization and structure.
|
||||
66
prompts/java-springboot.prompt.md
Normal file
66
prompts/java-springboot.prompt.md
Normal file
@ -0,0 +1,66 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems', 'search']
|
||||
description: 'Get best practices for developing applications with Spring Boot.'
|
||||
---
|
||||
|
||||
# Spring Boot Best Practices
|
||||
|
||||
Your goal is to help me write high-quality Spring Boot applications by following established best practices.
|
||||
|
||||
## Project Setup & Structure
|
||||
|
||||
- **Build Tool:** Use Maven (`pom.xml`) or Gradle (`build.gradle`) for dependency management.
|
||||
- **Starters:** Use Spring Boot starters (e.g., `spring-boot-starter-web`, `spring-boot-starter-data-jpa`) to simplify dependency management.
|
||||
- **Package Structure:** Organize code by feature/domain (e.g., `com.example.app.order`, `com.example.app.user`) rather than by layer (e.g., `com.example.app.controller`, `com.example.app.service`).
|
||||
|
||||
## Dependency Injection & Components
|
||||
|
||||
- **Constructor Injection:** Always use constructor-based injection for required dependencies. This makes components easier to test and dependencies explicit.
|
||||
- **Immutability:** Declare dependency fields as `private final`.
|
||||
- **Component Stereotypes:** Use `@Component`, `@Service`, `@Repository`, and `@Controller`/`@RestController` annotations appropriately to define beans.
|
||||
|
||||
## Configuration
|
||||
|
||||
- **Externalized Configuration:** Use `application.yml` (or `application.properties`) for configuration. YAML is often preferred for its readability and hierarchical structure.
|
||||
- **Type-Safe Properties:** Use `@ConfigurationProperties` to bind configuration to strongly-typed Java objects.
|
||||
- **Profiles:** Use Spring Profiles (`application-dev.yml`, `application-prod.yml`) to manage environment-specific configurations.
|
||||
- **Secrets Management:** Do not hardcode secrets. Use environment variables, or a dedicated secret management tool like HashiCorp Vault or AWS Secrets Manager.
|
||||
|
||||
## Web Layer (Controllers)
|
||||
|
||||
- **RESTful APIs:** Design clear and consistent RESTful endpoints.
|
||||
- **DTOs (Data Transfer Objects):** Use DTOs to expose and consume data in the API layer. Do not expose JPA entities directly to the client.
|
||||
- **Validation:** Use Java Bean Validation (JSR 380) with annotations (`@Valid`, `@NotNull`, `@Size`) on DTOs to validate request payloads.
|
||||
- **Error Handling:** Implement a global exception handler using `@ControllerAdvice` and `@ExceptionHandler` to provide consistent error responses.
|
||||
|
||||
## Service Layer
|
||||
|
||||
- **Business Logic:** Encapsulate all business logic within `@Service` classes.
|
||||
- **Statelessness:** Services should be stateless.
|
||||
- **Transaction Management:** Use `@Transactional` on service methods to manage database transactions declaratively. Apply it at the most granular level necessary.
|
||||
|
||||
## Data Layer (Repositories)
|
||||
|
||||
- **Spring Data JPA:** Use Spring Data JPA repositories by extending `JpaRepository` or `CrudRepository` for standard database operations.
|
||||
- **Custom Queries:** For complex queries, use `@Query` or the JPA Criteria API.
|
||||
- **Projections:** Use DTO projections to fetch only the necessary data from the database.
|
||||
|
||||
## Logging
|
||||
|
||||
- **SLF4J:** Use the SLF4J API for logging.
|
||||
- **Logger Declaration:** `private static final Logger logger = LoggerFactory.getLogger(MyClass.class);`
|
||||
- **Parameterized Logging:** Use parameterized messages (`logger.info("Processing user {}...", userId);`) instead of string concatenation to improve performance.
|
||||
|
||||
## Testing
|
||||
|
||||
- **Unit Tests:** Write unit tests for services and components using JUnit 5 and a mocking framework like Mockito.
|
||||
- **Integration Tests:** Use `@SpringBootTest` for integration tests that load the Spring application context.
|
||||
- **Test Slices:** Use test slice annotations like `@WebMvcTest` (for controllers) or `@DataJpaTest` (for repositories) to test specific parts of the application in isolation.
|
||||
- **Testcontainers:** Consider using Testcontainers for reliable integration tests with real databases, message brokers, etc.
|
||||
|
||||
## Security
|
||||
|
||||
- **Spring Security:** Use Spring Security for authentication and authorization.
|
||||
- **Password Encoding:** Always encode passwords using a strong hashing algorithm like BCrypt.
|
||||
- **Input Sanitization:** Prevent SQL injection by using Spring Data JPA or parameterized queries. Prevent Cross-Site Scripting (XSS) by properly encoding output.
|
||||
71
prompts/kotlin-springboot.prompt.md
Normal file
71
prompts/kotlin-springboot.prompt.md
Normal file
@ -0,0 +1,71 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems', 'search']
|
||||
description: 'Get best practices for developing applications with Spring Boot and Kotlin.'
|
||||
---
|
||||
|
||||
# Spring Boot with Kotlin Best Practices
|
||||
|
||||
Your goal is to help me write high-quality, idiomatic Spring Boot applications using Kotlin.
|
||||
|
||||
## Project Setup & Structure
|
||||
|
||||
- **Build Tool:** Use Maven (`pom.xml`) or Gradle (`build.gradle`) with the Kotlin plugins (`kotlin-maven-plugin` or `org.jetbrains.kotlin.jvm`).
|
||||
- **Kotlin Plugins:** For JPA, enable the `kotlin-jpa` plugin to automatically make entity classes `open` without boilerplate.
|
||||
- **Starters:** Use Spring Boot starters (e.g., `spring-boot-starter-web`, `spring-boot-starter-data-jpa`) as usual.
|
||||
- **Package Structure:** Organize code by feature/domain (e.g., `com.example.app.order`, `com.example.app.user`) rather than by layer.
|
||||
|
||||
## Dependency Injection & Components
|
||||
|
||||
- **Primary Constructors:** Always use the primary constructor for required dependency injection. It's the most idiomatic and concise approach in Kotlin.
|
||||
- **Immutability:** Declare dependencies as `private val` in the primary constructor. Prefer `val` over `var` everywhere to promote immutability.
|
||||
- **Component Stereotypes:** Use `@Service`, `@Repository`, and `@RestController` annotations just as you would in Java.
|
||||
|
||||
## Configuration
|
||||
|
||||
- **Externalized Configuration:** Use `application.yml` for its readability and hierarchical structure.
|
||||
- **Type-Safe Properties:** Use `@ConfigurationProperties` with `data class` to create immutable, type-safe configuration objects.
|
||||
- **Profiles:** Use Spring Profiles (`application-dev.yml`, `application-prod.yml`) to manage environment-specific configurations.
|
||||
- **Secrets Management:** Never hardcode secrets. Use environment variables or a dedicated secret management tool like HashiCorp Vault or AWS Secrets Manager.
|
||||
|
||||
## Web Layer (Controllers)
|
||||
|
||||
- **RESTful APIs:** Design clear and consistent RESTful endpoints.
|
||||
- **Data Classes for DTOs:** Use Kotlin `data class` for all DTOs. This provides `equals()`, `hashCode()`, `toString()`, and `copy()` for free and promotes immutability.
|
||||
- **Validation:** Use Java Bean Validation (JSR 380) with annotations (`@Valid`, `@NotNull`, `@Size`) on your DTO data classes.
|
||||
- **Error Handling:** Implement a global exception handler using `@ControllerAdvice` and `@ExceptionHandler` for consistent error responses.
|
||||
|
||||
## Service Layer
|
||||
|
||||
- **Business Logic:** Encapsulate business logic within `@Service` classes.
|
||||
- **Statelessness:** Services should be stateless.
|
||||
- **Transaction Management:** Use `@Transactional` on service methods. In Kotlin, this can be applied to class or function level.
|
||||
|
||||
## Data Layer (Repositories)
|
||||
|
||||
- **JPA Entities:** Define entities as classes. Remember they must be `open`. It's highly recommended to use the `kotlin-jpa` compiler plugin to handle this automatically.
|
||||
- **Null Safety:** Leverage Kotlin's null-safety (`?`) to clearly define which entity fields are optional or required at the type level.
|
||||
- **Spring Data JPA:** Use Spring Data JPA repositories by extending `JpaRepository` or `CrudRepository`.
|
||||
- **Coroutines:** For reactive applications, leverage Spring Boot's support for Kotlin Coroutines in the data layer.
|
||||
|
||||
## Logging
|
||||
|
||||
- **Companion Object Logger:** The idiomatic way to declare a logger is in a companion object.
|
||||
```kotlin
|
||||
companion object {
|
||||
private val logger = LoggerFactory.getLogger(MyClass::class.java)
|
||||
}
|
||||
```
|
||||
- **Parameterized Logging:** Use parameterized messages (`logger.info("Processing user {}...", userId)`) for performance and clarity.
|
||||
|
||||
## Testing
|
||||
|
||||
- **JUnit 5:** JUnit 5 is the default and works seamlessly with Kotlin.
|
||||
- **Idiomatic Testing Libraries:** For more fluent and idiomatic tests, consider using **Kotest** for assertions and **MockK** for mocking. They are designed for Kotlin and offer a more expressive syntax.
|
||||
- **Test Slices:** Use test slice annotations like `@WebMvcTest` or `@DataJpaTest` to test specific parts of the application.
|
||||
- **Testcontainers:** Use Testcontainers for reliable integration tests with real databases, message brokers, etc.
|
||||
|
||||
## Coroutines & Asynchronous Programming
|
||||
|
||||
- **`suspend` functions:** For non-blocking asynchronous code, use `suspend` functions in your controllers and services. Spring Boot has excellent support for coroutines.
|
||||
- **Structured Concurrency:** Use `coroutineScope` or `supervisorScope` to manage the lifecycle of coroutines.
|
||||
@ -13,7 +13,7 @@ Enhance your GitHub Copilot experience with community-contributed instructions,
|
||||
|
||||
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** |
|
||||
| **📋 [Custom Instructions](#-custom-instructions)** | **🎯 [Reusable Prompts](#-reusable-prompts)** | **🧩 [Custom Chat Modes](#-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 |
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user