Merge branch 'main' into feat/ai-unrestricted-master
This commit is contained in:
Aung Myo Kyaw
GitHub
commit
05924c9f90
18
README.md
18
README.md
@ -37,6 +37,7 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
|
||||
| [DevOps Core Principles](instructions/devops-core-principles.instructions.md) | Foundational instructions covering core DevOps principles, culture (CALMS), and key metrics (DORA) to guide GitHub Copilot in understanding and promoting effective software delivery. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fdevops-core-principles.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%2Fdevops-core-principles.instructions.md) |
|
||||
| [DDD Systems & .NET Guidelines](instructions/dotnet-architecture-good-practices.instructions.md) | DDD and .NET architecture guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fdotnet-architecture-good-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%2Fdotnet-architecture-good-practices.instructions.md) |
|
||||
| [.NET MAUI](instructions/dotnet-maui.instructions.md) | .NET MAUI component and application patterns | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fdotnet-maui.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%2Fdotnet-maui.instructions.md) |
|
||||
| [Dotnet Wpf](instructions/dotnet-wpf.instructions.md) | .NET WPF component and application patterns | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fdotnet-wpf.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%2Fdotnet-wpf.instructions.md) |
|
||||
| [Genaiscript](instructions/genaiscript.instructions.md) | AI-powered script generation guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgenaiscript.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%2Fgenaiscript.instructions.md) |
|
||||
| [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) |
|
||||
| [Gilfoyle Code Review Instructions](instructions/gilfoyle-code-review.instructions.md) | Gilfoyle-style code review instructions that channel the sardonic technical supremacy of Silicon Valley's most arrogant systems architect. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgilfoyle-code-review.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%2Fgilfoyle-code-review.instructions.md) |
|
||||
@ -53,9 +54,11 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
|
||||
| [Next.js + Tailwind Development Instructions](instructions/nextjs-tailwind.instructions.md) | Next.js + Tailwind 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%2Fnextjs-tailwind.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%2Fnextjs-tailwind.instructions.md) |
|
||||
| [Next.js Best Practices for LLMs (2025)](instructions/nextjs.instructions.md) | (2025) specific coding standards and best practices | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnextjs.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%2Fnextjs.instructions.md) |
|
||||
| [Code Generation Guidelines](instructions/nodejs-javascript-vitest.instructions.md) | Guidelines for writing Node.js and JavaScript code with Vitest testing | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnodejs-javascript-vitest.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%2Fnodejs-javascript-vitest.instructions.md) |
|
||||
| [Object Calisthenics Rules](instructions/object-calisthenics.instructions.md) | Enforces Object Calisthenics principles for business domain code to ensure clean, maintainable, and robust code | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fobject-calisthenics.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%2Fobject-calisthenics.instructions.md) |
|
||||
| [Performance Optimization Best Practices](instructions/performance-optimization.instructions.md) | The most comprehensive, practical, and engineer-authored performance optimization instructions for all languages, frameworks, and stacks. Covers frontend, backend, and database best practices with actionable guidance, scenario-based checklists, troubleshooting, and pro tips. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fperformance-optimization.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%2Fperformance-optimization.instructions.md) |
|
||||
| [Playwright Typescript](instructions/playwright-typescript.instructions.md) | Playwright test generation instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fplaywright-typescript.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%2Fplaywright-typescript.instructions.md) |
|
||||
| [Power Platform Connectors Schema Development Instructions](instructions/power-platform-connector.instructions.md) | Comprehensive development guidelines for Power Platform Custom Connectors using JSON Schema definitions. Covers API definitions (Swagger 2.0), API properties, and settings configuration with Microsoft extensions. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpower-platform-connector.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%2Fpower-platform-connector.instructions.md) |
|
||||
| [PowerShell Pester v5 Testing Guidelines](instructions/powershell-pester-5.instructions.md) | PowerShell Pester testing best practices based on Pester v5 conventions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell-pester-5.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-pester-5.instructions.md) |
|
||||
| [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 MCP Server](instructions/quarkus-mcp-server-sse.instructions.md) | Quarkus and MCP Server with HTTP SSE transport 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-mcp-server-sse.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-mcp-server-sse.instructions.md) |
|
||||
@ -80,11 +83,15 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| Title | Description | Install |
|
||||
| ----- | ----------- | ------- |
|
||||
| [AI Prompt Engineering Safety Review & Improvement](prompts/ai-prompt-engineering-safety-review.prompt.md) | Comprehensive AI prompt engineering safety review and improvement prompt. Analyzes prompts for safety, bias, security vulnerabilities, and effectiveness while providing detailed improvement recommendations with extensive frameworks, testing methodologies, and educational content. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fai-prompt-engineering-safety-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%2Fai-prompt-engineering-safety-review.prompt.md) |
|
||||
| [Comprehensive Project Architecture Blueprint Generator](prompts/architecture-blueprint-generator.prompt.md) | Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Farchitecture-blueprint-generator.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%2Farchitecture-blueprint-generator.prompt.md) |
|
||||
| [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) |
|
||||
| [Code Exemplars Blueprint Generator](prompts/code-exemplars-blueprint-generator.prompt.md) | Technology-agnostic prompt generator that creates customizable AI prompts for scanning codebases and identifying high-quality code exemplars. Supports multiple programming languages (.NET, Java, JavaScript, TypeScript, React, Angular, Python) with configurable analysis depth, categorization methods, and documentation formats to establish coding standards and maintain consistency across development teams. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcode-exemplars-blueprint-generator.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%2Fcode-exemplars-blueprint-generator.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) |
|
||||
| [Copilot Instructions Blueprint Generator](prompts/copilot-instructions-blueprint-generator.prompt.md) | Technology-agnostic blueprint generator for creating comprehensive copilot-instructions.md files that guide GitHub Copilot to produce code consistent with project standards, architecture patterns, and exact technology versions by analyzing existing codebase patterns and avoiding assumptions. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcopilot-instructions-blueprint-generator.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%2Fcopilot-instructions-blueprint-generator.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 Actions Workflow Specification](prompts/create-github-action-workflow-specification.prompt.md) | Create a formal specification for an existing GitHub Actions CI/CD workflow, optimized for AI consumption and workflow maintenance. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-action-workflow-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-action-workflow-specification.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) |
|
||||
| [Create GitHub Issue from Implementation Plan](prompts/create-github-issues-feature-from-implementation-plan.prompt.md) | Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issues-feature-from-implementation-plan.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-issues-feature-from-implementation-plan.prompt.md) |
|
||||
| [Create GitHub Issues for Unmet Specification Requirements](prompts/create-github-issues-for-unmet-specification-requirements.prompt.md) | Create GitHub Issues for unimplemented requirements from specification files 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-issues-for-unmet-specification-requirements.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-issues-for-unmet-specification-requirements.prompt.md) |
|
||||
@ -104,6 +111,7 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [.NET/C# Best Practices](prompts/dotnet-best-practices.prompt.md) | Ensure .NET/C# code meets best practices for the solution/project. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fdotnet-best-practices.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-best-practices.prompt.md) |
|
||||
| [.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) |
|
||||
| [Project Folder Structure Blueprint Generator](prompts/folder-structure-blueprint-generator.prompt.md) | Comprehensive technology-agnostic prompt for analyzing and documenting project folder structures. Auto-detects project types (.NET, Java, React, Angular, Python, Node.js, Flutter), generates detailed blueprints with visualization options, naming conventions, file placement patterns, and extension templates for maintaining consistent code organization across diverse technology stacks. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Ffolder-structure-blueprint-generator.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%2Ffolder-structure-blueprint-generator.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) |
|
||||
@ -114,9 +122,16 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [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) |
|
||||
| [Next Intl Add Language](prompts/next-intl-add-language.prompt.md) | Add new language to a Next.js + next-intl application | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fnext-intl-add-language.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%2Fnext-intl-add-language.prompt.md) |
|
||||
| [PostgreSQL Code Review Assistant](prompts/postgresql-code-review.prompt.md) | PostgreSQL-specific code review assistant focusing on PostgreSQL best practices, anti-patterns, and unique quality standards. Covers JSONB operations, array usage, custom types, schema design, function optimization, and PostgreSQL-exclusive security features like Row Level Security (RLS). | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fpostgresql-code-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%2Fpostgresql-code-review.prompt.md) |
|
||||
| [PostgreSQL Development Assistant](prompts/postgresql-optimization.prompt.md) | PostgreSQL-specific development assistant focusing on unique PostgreSQL features, advanced data types, and PostgreSQL-exclusive capabilities. Covers JSONB operations, array types, custom types, range/geometric types, full-text search, window functions, and PostgreSQL extensions ecosystem. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fpostgresql-optimization.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%2Fpostgresql-optimization.prompt.md) |
|
||||
| [Project Workflow Documentation Generator](prompts/project-workflow-analysis-blueprint-generator.prompt.md) | Comprehensive technology-agnostic prompt generator for documenting end-to-end application workflows. Automatically detects project architecture patterns, technology stacks, and data flow patterns to generate detailed implementation blueprints covering entry points, service layers, data access, error handling, and testing approaches across multiple technologies including .NET, Java/Spring, React, and microservices architectures. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fproject-workflow-analysis-blueprint-generator.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%2Fproject-workflow-analysis-blueprint-generator.prompt.md) |
|
||||
| [README Generator Prompt](prompts/readme-blueprint-generator.prompt.md) | Intelligent README.md generation prompt that analyzes project documentation structure and creates comprehensive repository documentation. Scans .github/copilot directory files and copilot-instructions.md to extract project information, technology stack, architecture, development workflow, coding standards, and testing approaches while generating well-structured markdown documentation with proper formatting, cross-references, and developer-focused content. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Freadme-blueprint-generator.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%2Freadme-blueprint-generator.prompt.md) |
|
||||
| [Review And Refactor](prompts/review-and-refactor.prompt.md) | Review and refactor code in your project according to defined instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Freview-and-refactor.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%2Freview-and-refactor.prompt.md) |
|
||||
| [SQL Code Review](prompts/sql-code-review.prompt.md) | Universal SQL code review assistant that performs comprehensive security, maintainability, and code quality analysis across all SQL databases (MySQL, PostgreSQL, SQL Server, Oracle). Focuses on SQL injection prevention, access control, code standards, and anti-pattern detection. Complements SQL optimization prompt for complete development coverage. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsql-code-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%2Fsql-code-review.prompt.md) |
|
||||
| [SQL Performance Optimization Assistant](prompts/sql-optimization.prompt.md) | Universal SQL performance optimization assistant for comprehensive query tuning, indexing strategies, and database performance analysis across all SQL databases (MySQL, PostgreSQL, SQL Server, Oracle). Provides execution plan analysis, pagination optimization, batch operations, and performance monitoring guidance. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsql-optimization.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%2Fsql-optimization.prompt.md) |
|
||||
| [Suggest Awesome GitHub Copilot Chatmodes](prompts/suggest-awesome-github-copilot-chatmodes.prompt.md) | Suggest relevant GitHub Copilot chatmode files from the awesome-copilot repository based on current repository context and chat history, avoiding duplicates with existing chatmodes in this repository. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsuggest-awesome-github-copilot-chatmodes.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%2Fsuggest-awesome-github-copilot-chatmodes.prompt.md) |
|
||||
| [Suggest Awesome GitHub Copilot Prompts](prompts/suggest-awesome-github-copilot-prompts.prompt.md) | Suggest relevant GitHub Copilot prompt files from the awesome-copilot repository based on current repository context and chat history, avoiding duplicates with existing prompts in this repository. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fsuggest-awesome-github-copilot-prompts.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%2Fsuggest-awesome-github-copilot-prompts.prompt.md) |
|
||||
| [Comprehensive Technology Stack Blueprint Generator](prompts/technology-stack-blueprint-generator.prompt.md) | Comprehensive technology stack blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks, programming languages, and implementation patterns across multiple platforms (.NET, Java, JavaScript, React, Python). Generates configurable blueprints with version information, licensing details, usage patterns, coding conventions, and visual diagrams. Provides implementation-ready templates and maintains architectural consistency for guided development. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Ftechnology-stack-blueprint-generator.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%2Ftechnology-stack-blueprint-generator.prompt.md) |
|
||||
| [Update Azure Verified Modules in Bicep Files](prompts/update-avm-modules-in-bicep.prompt.md) | Update Azure Verified Modules (AVM) to latest versions in Bicep files. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-avm-modules-in-bicep.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%2Fupdate-avm-modules-in-bicep.prompt.md) |
|
||||
| [Update Implementation Plan](prompts/update-implementation-plan.prompt.md) | Update an existing implementation plan file with new or update requirements to provide new features, refactoring existing code or upgrading packages, design, architecture or infrastructure. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-implementation-plan.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%2Fupdate-implementation-plan.prompt.md) |
|
||||
| [Update LLMs.txt File](prompts/update-llms.prompt.md) | Update the llms.txt file in the root folder to reflect changes in documentation or specifications following the llms.txt specification at https://llmstxt.org/ | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-llms.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%2Fupdate-llms.prompt.md) |
|
||||
@ -167,6 +182,9 @@ Custom chat modes define specific behaviors and tools for GitHub Copilot Chat, e
|
||||
| [Idea Generator mode instructions](chatmodes/simple-app-idea-generator.chatmode.md) | Brainstorm and develop new application ideas through fun, interactive questioning until ready for specification creation. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fsimple-app-idea-generator.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fsimple-app-idea-generator.chatmode.md) |
|
||||
| [Software Engineer Agent v1](chatmodes/software-engineer-agent-v1.chatmode.md) | Expert-level software engineering agent. Deliver production-ready, maintainable code. Execute systematically and specification-driven. Document comprehensively. Operate autonomously and adaptively. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fsoftware-engineer-agent-v1.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fsoftware-engineer-agent-v1.chatmode.md) |
|
||||
| [Specification mode instructions](chatmodes/specification.chatmode.md) | Generate or update specification documents for new or existing functionality. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fspecification.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fspecification.chatmode.md) |
|
||||
| [TDD Green Phase - Make Tests Pass Quickly](chatmodes/tdd-green.chatmode.md) | Implement minimal code to satisfy GitHub issue requirements and make failing tests pass without over-engineering. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftdd-green.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftdd-green.chatmode.md) |
|
||||
| [TDD Red Phase - Write Failing Tests First](chatmodes/tdd-red.chatmode.md) | Guide test-first development by writing failing tests that describe desired behaviour from GitHub issue context before implementation exists. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftdd-red.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftdd-red.chatmode.md) |
|
||||
| [TDD Refactor Phase - Improve Quality & Security](chatmodes/tdd-refactor.chatmode.md) | Improve code quality, apply security best practices, and enhance design whilst maintaining green tests and GitHub issue compliance. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftdd-refactor.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftdd-refactor.chatmode.md) |
|
||||
| [Technical Debt Remediation Plan](chatmodes/tech-debt-remediation-plan.chatmode.md) | Generate technical debt remediation plans for code, tests, and documentation. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftech-debt-remediation-plan.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Ftech-debt-remediation-plan.chatmode.md) |
|
||||
| [voidBeast_GPT41Enhanced 1.0 - Elite Developer AI Assistant](chatmodes/voidbeast-gpt41enhanced.chatmode.md) | 4.1 voidBeast_GPT41Enhanced 1.0 : a advanced autonomous developer agent, designed for elite full-stack development with enhanced multi-mode capabilities. This latest evolution features sophisticated mode detection, comprehensive research capabilities, and never-ending problem resolution. Plan/Act/Deep Research/Analyzer/Checkpoints(Memory)/Prompt Generator Modes. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fvoidbeast-gpt41enhanced.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fvoidbeast-gpt41enhanced.chatmode.md) |
|
||||
| [Wg Code Alchemist](chatmodes/wg-code-alchemist.chatmode.md) | Ask WG Code Alchemist to transform your code with Clean Code principles and SOLID design | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fwg-code-alchemist.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fwg-code-alchemist.chatmode.md) |
|
||||
|
||||
@ -63,6 +63,10 @@ All implementation plans must strictly adhere to the following template. Each se
|
||||
- Tables must include all required columns with specific task details
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
## Status
|
||||
|
||||
The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Plan's Goal]
|
||||
@ -70,11 +74,14 @@ version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
59
chatmodes/tdd-green.chatmode.md
Normal file
59
chatmodes/tdd-green.chatmode.md
Normal file
@ -0,0 +1,59 @@
|
||||
---
|
||||
description: 'Implement minimal code to satisfy GitHub issue requirements and make failing tests pass without over-engineering.'
|
||||
tools: ['github', 'findTestFiles', 'editFiles', 'runTests', 'runCommands', 'codebase', 'filesystem', 'search', 'problems', 'testFailure', 'terminalLastCommand']
|
||||
---
|
||||
# TDD Green Phase - Make Tests Pass Quickly
|
||||
|
||||
Write the minimal code necessary to satisfy GitHub issue requirements and make failing tests pass. Resist the urge to write more than required.
|
||||
|
||||
## GitHub Issue Integration
|
||||
|
||||
### Issue-Driven Implementation
|
||||
- **Reference issue context** - Keep GitHub issue requirements in focus during implementation
|
||||
- **Validate against acceptance criteria** - Ensure implementation meets issue definition of done
|
||||
- **Track progress** - Update issue with implementation progress and blockers
|
||||
- **Stay in scope** - Implement only what's required by current issue, avoid scope creep
|
||||
|
||||
### Implementation Boundaries
|
||||
- **Issue scope only** - Don't implement features not mentioned in the current issue
|
||||
- **Future-proofing later** - Defer enhancements mentioned in issue comments for future iterations
|
||||
- **Minimum viable solution** - Focus on core requirements from issue description
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Minimal Implementation
|
||||
- **Just enough code** - Implement only what's needed to satisfy issue requirements and make tests pass
|
||||
- **Fake it till you make it** - Start with hard-coded returns based on issue examples, then generalise
|
||||
- **Obvious implementation** - When the solution is clear from issue, implement it directly
|
||||
- **Triangulation** - Add more tests based on issue scenarios to force generalisation
|
||||
|
||||
### Speed Over Perfection
|
||||
- **Green bar quickly** - Prioritise making tests pass over code quality
|
||||
- **Ignore code smells temporarily** - Duplication and poor design will be addressed in refactor phase
|
||||
- **Simple solutions first** - Choose the most straightforward implementation path from issue context
|
||||
- **Defer complexity** - Don't anticipate requirements beyond current issue scope
|
||||
|
||||
### C# Implementation Strategies
|
||||
- **Start with constants** - Return hard-coded values from issue examples initially
|
||||
- **Progress to conditionals** - Add if/else logic as more issue scenarios are tested
|
||||
- **Extract to methods** - Create simple helper methods when duplication emerges
|
||||
- **Use basic collections** - Simple List<T> or Dictionary<T,V> over complex data structures
|
||||
|
||||
## Execution Guidelines
|
||||
|
||||
1. **Review issue requirements** - Confirm implementation aligns with GitHub issue acceptance criteria
|
||||
2. **Run the failing test** - Confirm exactly what needs to be implemented
|
||||
3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
|
||||
4. **Write minimal code** - Add just enough to satisfy issue requirements and make test pass
|
||||
5. **Run all tests** - Ensure new code doesn't break existing functionality
|
||||
6. **Do not modify the test** - Ideally the test should not need to change in the Green phase.
|
||||
7. **Update issue progress** - Comment on implementation status if needed
|
||||
|
||||
## Green Phase Checklist
|
||||
- [ ] Implementation aligns with GitHub issue requirements
|
||||
- [ ] All tests are passing (green bar)
|
||||
- [ ] No more code written than necessary for issue scope
|
||||
- [ ] Existing tests remain unbroken
|
||||
- [ ] Implementation is simple and direct
|
||||
- [ ] Issue acceptance criteria satisfied
|
||||
- [ ] Ready for refactoring phase
|
||||
59
chatmodes/tdd-red.chatmode.md
Normal file
59
chatmodes/tdd-red.chatmode.md
Normal file
@ -0,0 +1,59 @@
|
||||
---
|
||||
description: 'Guide test-first development by writing failing tests that describe desired behaviour from GitHub issue context before implementation exists.'
|
||||
tools: ['github', 'findTestFiles', 'editFiles', 'runTests', 'runCommands', 'codebase', 'filesystem', 'search', 'problems', 'testFailure', 'terminalLastCommand']
|
||||
---
|
||||
# TDD Red Phase - Write Failing Tests First
|
||||
|
||||
Focus on writing clear, specific failing tests that describe the desired behaviour from GitHub issue requirements before any implementation exists.
|
||||
|
||||
## GitHub Issue Integration
|
||||
|
||||
### Branch-to-Issue Mapping
|
||||
- **Extract issue number** from branch name pattern: `*{number}*` that will be the title of the GitHub issue
|
||||
- **Fetch issue details** using MCP GitHub, search for GitHub Issues matching `*{number}*` to understand requirements
|
||||
- **Understand the full context** from issue description and comments, labels, and linked pull requests
|
||||
|
||||
|
||||
### Issue Context Analysis
|
||||
- **Requirements extraction** - Parse user stories and acceptance criteria
|
||||
- **Edge case identification** - Review issue comments for boundary conditions
|
||||
- **Definition of Done** - Use issue checklist items as test validation points
|
||||
- **Stakeholder context** - Consider issue assignees and reviewers for domain knowledge
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Test-First Mindset
|
||||
- **Write the test before the code** - Never write production code without a failing test
|
||||
- **One test at a time** - Focus on a single behaviour or requirement from the issue
|
||||
- **Fail for the right reason** - Ensure tests fail due to missing implementation, not syntax errors
|
||||
- **Be specific** - Tests should clearly express what behaviour is expected per issue requirements
|
||||
|
||||
### Test Quality Standards
|
||||
- **Descriptive test names** - Use clear, behaviour-focused naming like `Should_ReturnValidationError_When_EmailIsInvalid_Issue{number}`
|
||||
- **AAA Pattern** - Structure tests with clear Arrange, Act, Assert sections
|
||||
- **Single assertion focus** - Each test should verify one specific outcome from issue criteria
|
||||
- **Edge cases first** - Consider boundary conditions mentioned in issue discussions
|
||||
|
||||
### C# Test Patterns
|
||||
- Use **xUnit** with **FluentAssertions** for readable assertions
|
||||
- Apply **AutoFixture** for test data generation
|
||||
- Implement **Theory tests** for multiple input scenarios from issue examples
|
||||
- Create **custom assertions** for domain-specific validations outlined in issue
|
||||
|
||||
## Execution Guidelines
|
||||
|
||||
1. **Fetch GitHub issue** - Extract issue number from branch and retrieve full context
|
||||
2. **Analyse requirements** - Break down issue into testable behaviours
|
||||
3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
|
||||
4. **Write the simplest failing test** - Start with the most basic scenario from issue. NEVER write multiple tests at once. You will iterate on RED, GREEN, REFACTOR cycle with one test at a time
|
||||
5. **Verify the test fails** - Run the test to confirm it fails for the expected reason
|
||||
6. **Link test to issue** - Reference issue number in test names and comments
|
||||
|
||||
## Red Phase Checklist
|
||||
- [ ] GitHub issue context retrieved and analysed
|
||||
- [ ] Test clearly describes expected behaviour from issue requirements
|
||||
- [ ] Test fails for the right reason (missing implementation)
|
||||
- [ ] Test name references issue number and describes behaviour
|
||||
- [ ] Test follows AAA pattern
|
||||
- [ ] Edge cases from issue discussion considered
|
||||
- [ ] No production code written yet
|
||||
84
chatmodes/tdd-refactor.chatmode.md
Normal file
84
chatmodes/tdd-refactor.chatmode.md
Normal file
@ -0,0 +1,84 @@
|
||||
---
|
||||
description: 'Improve code quality, apply security best practices, and enhance design whilst maintaining green tests and GitHub issue compliance.'
|
||||
tools: ['github', 'findTestFiles', 'editFiles', 'runTests', 'runCommands', 'codebase', 'filesystem', 'search', 'problems', 'testFailure', 'terminalLastCommand']
|
||||
---
|
||||
# TDD Refactor Phase - Improve Quality & Security
|
||||
|
||||
Clean up code, apply security best practices, and enhance design whilst keeping all tests green and maintaining GitHub issue compliance.
|
||||
|
||||
## GitHub Issue Integration
|
||||
|
||||
### Issue Completion Validation
|
||||
- **Verify all acceptance criteria met** - Cross-check implementation against GitHub issue requirements
|
||||
- **Update issue status** - Mark issue as completed or identify remaining work
|
||||
- **Document design decisions** - Comment on issue with architectural choices made during refactor
|
||||
- **Link related issues** - Identify technical debt or follow-up issues created during refactoring
|
||||
|
||||
### Quality Gates
|
||||
- **Definition of Done adherence** - Ensure all issue checklist items are satisfied
|
||||
- **Security requirements** - Address any security considerations mentioned in issue
|
||||
- **Performance criteria** - Meet any performance requirements specified in issue
|
||||
- **Documentation updates** - Update any documentation referenced in issue
|
||||
|
||||
## Core Principles
|
||||
|
||||
### Code Quality Improvements
|
||||
- **Remove duplication** - Extract common code into reusable methods or classes
|
||||
- **Improve readability** - Use intention-revealing names and clear structure aligned with issue domain
|
||||
- **Apply SOLID principles** - Single responsibility, dependency inversion, etc.
|
||||
- **Simplify complexity** - Break down large methods, reduce cyclomatic complexity
|
||||
|
||||
### Security Hardening
|
||||
- **Input validation** - Sanitise and validate all external inputs per issue security requirements
|
||||
- **Authentication/Authorisation** - Implement proper access controls if specified in issue
|
||||
- **Data protection** - Encrypt sensitive data, use secure connection strings
|
||||
- **Error handling** - Avoid information disclosure through exception details
|
||||
- **Dependency scanning** - Check for vulnerable NuGet packages
|
||||
- **Secrets management** - Use Azure Key Vault or user secrets, never hard-code credentials
|
||||
- **OWASP compliance** - Address security concerns mentioned in issue or related security tickets
|
||||
|
||||
### Design Excellence
|
||||
- **Design patterns** - Apply appropriate patterns (Repository, Factory, Strategy, etc.)
|
||||
- **Dependency injection** - Use DI container for loose coupling
|
||||
- **Configuration management** - Externalise settings using IOptions pattern
|
||||
- **Logging and monitoring** - Add structured logging with Serilog for issue troubleshooting
|
||||
- **Performance optimisation** - Use async/await, efficient collections, caching
|
||||
|
||||
### C# Best Practices
|
||||
- **Nullable reference types** - Enable and properly configure nullability
|
||||
- **Modern C# features** - Use pattern matching, switch expressions, records
|
||||
- **Memory efficiency** - Consider Span<T>, Memory<T> for performance-critical code
|
||||
- **Exception handling** - Use specific exception types, avoid catching Exception
|
||||
|
||||
## Security Checklist
|
||||
- [ ] Input validation on all public methods
|
||||
- [ ] SQL injection prevention (parameterised queries)
|
||||
- [ ] XSS protection for web applications
|
||||
- [ ] Authorisation checks on sensitive operations
|
||||
- [ ] Secure configuration (no secrets in code)
|
||||
- [ ] Error handling without information disclosure
|
||||
- [ ] Dependency vulnerability scanning
|
||||
- [ ] OWASP Top 10 considerations addressed
|
||||
|
||||
## Execution Guidelines
|
||||
|
||||
1. **Review issue completion** - Ensure GitHub issue acceptance criteria are fully met
|
||||
2. **Ensure green tests** - All tests must pass before refactoring
|
||||
3. **Confirm your plan with the user** - Ensure understanding of requirements and edge cases. NEVER start making changes without user confirmation
|
||||
4. **Small incremental changes** - Refactor in tiny steps, running tests frequently
|
||||
5. **Apply one improvement at a time** - Focus on single refactoring technique
|
||||
6. **Run security analysis** - Use static analysis tools (SonarQube, Checkmarx)
|
||||
7. **Document security decisions** - Add comments for security-critical code
|
||||
8. **Update issue** - Comment on final implementation and close issue if complete
|
||||
|
||||
## Refactor Phase Checklist
|
||||
- [ ] GitHub issue acceptance criteria fully satisfied
|
||||
- [ ] Code duplication eliminated
|
||||
- [ ] Names clearly express intent aligned with issue domain
|
||||
- [ ] Methods have single responsibility
|
||||
- [ ] Security vulnerabilities addressed per issue requirements
|
||||
- [ ] Performance considerations applied
|
||||
- [ ] All tests remain green
|
||||
- [ ] Code coverage maintained or improved
|
||||
- [ ] Issue marked as complete or follow-up issues created
|
||||
- [ ] Documentation updated as specified in issue
|
||||
79
instructions/dotnet-wpf.instructions.md
Normal file
79
instructions/dotnet-wpf.instructions.md
Normal file
@ -0,0 +1,79 @@
|
||||
---
|
||||
description: '.NET WPF component and application patterns'
|
||||
applyTo: '**/*.xaml, **/*.cs'
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
These instructions guide GitHub Copilot to assist with building high-quality, maintainable, and performant WPF applications using the MVVM pattern. It includes best practices for XAML, data binding, UI responsiveness, and .NET performance.
|
||||
|
||||
## Ideal project types
|
||||
|
||||
- Desktop applications using C# and WPF
|
||||
- Applications following the MVVM (Model-View-ViewModel) design pattern
|
||||
- Projects using .NET 8.0 or later
|
||||
- UI components built in XAML
|
||||
- Solutions emphasizing performance and responsiveness
|
||||
|
||||
## Goals
|
||||
|
||||
- Generate boilerplate for `INotifyPropertyChanged` and `RelayCommand`
|
||||
- Suggest clean separation of ViewModel and View logic
|
||||
- Encourage use of `ObservableCollection<T>`, `ICommand`, and proper binding
|
||||
- Recommend performance tips (e.g., virtualization, async loading)
|
||||
- Avoid tightly coupling code-behind logic
|
||||
- Produce testable ViewModels
|
||||
|
||||
## Example prompt behaviors
|
||||
|
||||
### ✅ Good Suggestions
|
||||
- "Generate a ViewModel for a login screen with properties for username and password, and a LoginCommand"
|
||||
- "Write a XAML snippet for a ListView that uses UI virtualization and binds to an ObservableCollection"
|
||||
- "Refactor this code-behind click handler into a RelayCommand in the ViewModel"
|
||||
- "Add a loading spinner while fetching data asynchronously in WPF"
|
||||
|
||||
### ❌ Avoid
|
||||
- Suggesting business logic in code-behind
|
||||
- Using static event handlers without context
|
||||
- Generating tightly coupled XAML without binding
|
||||
- Suggesting WinForms or UWP approaches
|
||||
|
||||
## Technologies to prefer
|
||||
- C# with .NET 8.0+
|
||||
- XAML with MVVM structure
|
||||
- `CommunityToolkit.Mvvm` or custom `RelayCommand` implementations
|
||||
- Async/await for non-blocking UI
|
||||
- `ObservableCollection`, `ICommand`, `INotifyPropertyChanged`
|
||||
|
||||
## Common Patterns to Follow
|
||||
- ViewModel-first binding
|
||||
- Dependency Injection using .NET or third-party containers (e.g., Autofac, SimpleInjector)
|
||||
- XAML naming conventions (PascalCase for controls, camelCase for bindings)
|
||||
- Avoiding magic strings in binding (use `nameof`)
|
||||
|
||||
## Sample Instruction Snippets Copilot Can Use
|
||||
|
||||
```csharp
|
||||
public class MainViewModel : ObservableObject
|
||||
{
|
||||
[ObservableProperty]
|
||||
private string userName;
|
||||
|
||||
[ObservableProperty]
|
||||
private string password;
|
||||
|
||||
[RelayCommand]
|
||||
private void Login()
|
||||
{
|
||||
// Add login logic here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```xml
|
||||
<StackPanel>
|
||||
<TextBox Text="{Binding UserName, UpdateSourceTrigger=PropertyChanged}" />
|
||||
<PasswordBox x:Name="PasswordBox" />
|
||||
<Button Content="Login" Command="{Binding LoginCommand}" />
|
||||
</StackPanel>
|
||||
```
|
||||
302
instructions/object-calisthenics.instructions.md
Normal file
302
instructions/object-calisthenics.instructions.md
Normal file
@ -0,0 +1,302 @@
|
||||
---
|
||||
applyTo: '**/*.{cs,ts,java}'
|
||||
description: Enforces Object Calisthenics principles for business domain code to ensure clean, maintainable, and robust code
|
||||
---
|
||||
# Object Calisthenics Rules
|
||||
|
||||
> ⚠️ **Warning:** This file contains the 9 original Object Calisthenics rules. No additional rules must be added, and none of these rules should be replaced or removed.
|
||||
> Examples may be added later if needed.
|
||||
|
||||
## Objective
|
||||
This rule enforces the principles of Object Calisthenics to ensure clean, maintainable, and robust code in the backend, **primarily for business domain code**.
|
||||
|
||||
## Scope and Application
|
||||
- **Primary focus**: Business domain classes (aggregates, entities, value objects, domain services)
|
||||
- **Secondary focus**: Application layer services and use case handlers
|
||||
- **Exemptions**:
|
||||
- DTOs (Data Transfer Objects)
|
||||
- API models/contracts
|
||||
- Configuration classes
|
||||
- Simple data containers without business logic
|
||||
- Infrastructure code where flexibility is needed
|
||||
|
||||
## Key Principles
|
||||
|
||||
|
||||
1. **One Level of Indentation per Method**:
|
||||
- Ensure methods are simple and do not exceed one level of indentation.
|
||||
|
||||
```csharp
|
||||
// Bad Example - this method has multiple levels of indentation
|
||||
public void SendNewsletter() {
|
||||
foreach (var user in users) {
|
||||
if (user.IsActive) {
|
||||
// Do something
|
||||
mailer.Send(user.Email);
|
||||
}
|
||||
}
|
||||
}
|
||||
// Good Example - Extracted method to reduce indentation
|
||||
public void SendNewsletter() {
|
||||
foreach (var user in users) {
|
||||
SendEmail(user);
|
||||
}
|
||||
}
|
||||
private void SendEmail(User user) {
|
||||
if (user.IsActive) {
|
||||
mailer.Send(user.Email);
|
||||
}
|
||||
}
|
||||
|
||||
// Good Example - Filtering users before sending emails
|
||||
public void SendNewsletter() {
|
||||
var activeUsers = users.Where(user => user.IsActive);
|
||||
|
||||
foreach (var user in activeUsers) {
|
||||
mailer.Send(user.Email);
|
||||
}
|
||||
}
|
||||
```
|
||||
2. **Don't Use the ELSE Keyword**:
|
||||
|
||||
- Avoid using the `else` keyword to reduce complexity and improve readability.
|
||||
- Use early returns to handle conditions instead.
|
||||
- Use Fail Fast principle
|
||||
- Use Guard Clauses to validate inputs and conditions at the beginning of methods.
|
||||
|
||||
```csharp
|
||||
// Bad Example - Using else
|
||||
public void ProcessOrder(Order order) {
|
||||
if (order.IsValid) {
|
||||
// Process order
|
||||
} else {
|
||||
// Handle invalid order
|
||||
}
|
||||
}
|
||||
// Good Example - Avoiding else
|
||||
public void ProcessOrder(Order order) {
|
||||
if (!order.IsValid) return;
|
||||
// Process order
|
||||
}
|
||||
```
|
||||
|
||||
Sample Fail fast principle:
|
||||
```csharp
|
||||
public void ProcessOrder(Order order) {
|
||||
if (order == null) throw new ArgumentNullException(nameof(order));
|
||||
if (!order.IsValid) throw new InvalidOperationException("Invalid order");
|
||||
// Process order
|
||||
}
|
||||
```
|
||||
|
||||
3. **Wrapping All Primitives and Strings**:
|
||||
- Avoid using primitive types directly in your code.
|
||||
- Wrap them in classes to provide meaningful context and behavior.
|
||||
|
||||
```csharp
|
||||
// Bad Example - Using primitive types directly
|
||||
public class User {
|
||||
public string Name { get; set; }
|
||||
public int Age { get; set; }
|
||||
}
|
||||
// Good Example - Wrapping primitives
|
||||
public class User {
|
||||
private string name;
|
||||
private Age age;
|
||||
public User(string name, Age age) {
|
||||
this.name = name;
|
||||
this.age = age;
|
||||
}
|
||||
}
|
||||
public class Age {
|
||||
private int value;
|
||||
public Age(int value) {
|
||||
if (value < 0) throw new ArgumentOutOfRangeException(nameof(value), "Age cannot be negative");
|
||||
this.value = value;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
4. **First Class Collections**:
|
||||
- Use collections to encapsulate data and behavior, rather than exposing raw data structures.
|
||||
First Class Collections: a class that contains an array as an attribute should not contain any other attributes
|
||||
|
||||
```csharp
|
||||
// Bad Example - Exposing raw collection
|
||||
public class Group {
|
||||
public int Id { get; private set; }
|
||||
public string Name { get; private set; }
|
||||
public List<User> Users { get; private set; }
|
||||
|
||||
public int GetNumberOfUsersIsActive() {
|
||||
return Users
|
||||
.Where(user => user.IsActive)
|
||||
.Count();
|
||||
}
|
||||
}
|
||||
|
||||
// Good Example - Encapsulating collection behavior
|
||||
public class Group {
|
||||
public int Id { get; private set; }
|
||||
public string Name { get; private set; }
|
||||
|
||||
public GroupUserCollection userCollection { get; private set; } // The list of users is encapsulated in a class
|
||||
|
||||
public int GetNumberOfUsersIsActive() {
|
||||
return userCollection
|
||||
.GetActiveUsers()
|
||||
.Count();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
5. **One Dot per Line**:
|
||||
- Limit the number of method calls in a single line to improve readability and maintainability.
|
||||
|
||||
```csharp
|
||||
// Bad Example - Multiple dots in a single line
|
||||
public void ProcessOrder(Order order) {
|
||||
var userEmail = order.User.GetEmail().ToUpper().Trim();
|
||||
// Do something with userEmail
|
||||
}
|
||||
// Good Example - One dot per line
|
||||
public void ProcessOrder(Order order) {
|
||||
var user = order.User;
|
||||
var email = user.GetEmail();
|
||||
var userEmail = email.ToUpper().Trim();
|
||||
// Do something with userEmail
|
||||
}
|
||||
```
|
||||
|
||||
6. **Don't abbreviate**:
|
||||
- Use meaningful names for classes, methods, and variables.
|
||||
- Avoid abbreviations that can lead to confusion.
|
||||
|
||||
```csharp
|
||||
// Bad Example - Abbreviated names
|
||||
public class U {
|
||||
public string N { get; set; }
|
||||
}
|
||||
// Good Example - Meaningful names
|
||||
public class User {
|
||||
public string Name { get; set; }
|
||||
}
|
||||
```
|
||||
|
||||
7. **Keep entities small (Class, method, namespace or package)**:
|
||||
- Limit the size of classes and methods to improve code readability and maintainability.
|
||||
- Each class should have a single responsibility and be as small as possible.
|
||||
|
||||
Constraints:
|
||||
- Maximum 10 methods per class
|
||||
- Maximum 50 lines per class
|
||||
- Maximum 10 classes per package or namespace
|
||||
|
||||
```csharp
|
||||
// Bad Example - Large class with multiple responsibilities
|
||||
public class UserManager {
|
||||
public void CreateUser(string name) { /*...*/ }
|
||||
public void DeleteUser(int id) { /*...*/ }
|
||||
public void SendEmail(string email) { /*...*/ }
|
||||
}
|
||||
|
||||
// Good Example - Small classes with single responsibility
|
||||
public class UserCreator {
|
||||
public void CreateUser(string name) { /*...*/ }
|
||||
}
|
||||
public class UserDeleter {
|
||||
public void DeleteUser(int id) { /*...*/ }
|
||||
}
|
||||
|
||||
public class UserUpdater {
|
||||
public void UpdateUser(int id, string name) { /*...*/ }
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
8. **No Classes with More Than Two Instance Variables**:
|
||||
- Encourage classes to have a single responsibility by limiting the number of instance variables.
|
||||
- Limit the number of instance variables to two to maintain simplicity.
|
||||
- Do not count ILogger or any other logger as instance variable.
|
||||
|
||||
```csharp
|
||||
// Bad Example - Class with multiple instance variables
|
||||
public class UserCreateCommandHandler {
|
||||
// Bad: Too many instance variables
|
||||
private readonly IUserRepository userRepository;
|
||||
private readonly IEmailService emailService;
|
||||
private readonly ILogger logger;
|
||||
private readonly ISmsService smsService;
|
||||
|
||||
public UserCreateCommandHandler(IUserRepository userRepository, IEmailService emailService, ILogger logger, ISmsService smsService) {
|
||||
this.userRepository = userRepository;
|
||||
this.emailService = emailService;
|
||||
this.logger = logger;
|
||||
this.smsService = smsService;
|
||||
}
|
||||
}
|
||||
|
||||
// Good: Class with two instance variables
|
||||
public class UserCreateCommandHandler {
|
||||
private readonly IUserRepository userRepository;
|
||||
private readonly INotificationService notificationService;
|
||||
private readonly ILogger logger; // This is not counted as instance variable
|
||||
|
||||
public UserCreateCommandHandler(IUserRepository userRepository, INotificationService notificationService, ILogger logger) {
|
||||
this.userRepository = userRepository;
|
||||
this.notificationService = notificationService;
|
||||
this.logger = logger;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
9. **No Getters/Setters in Domain Classes**:
|
||||
- Avoid exposing setters for properties in domain classes.
|
||||
- Use private constructors and static factory methods for object creation.
|
||||
- **Note**: This rule applies primarily to domain classes, not DTOs or data transfer objects.
|
||||
|
||||
```csharp
|
||||
// Bad Example - Domain class with public setters
|
||||
public class User { // Domain class
|
||||
public string Name { get; set; } // Avoid this in domain classes
|
||||
}
|
||||
|
||||
// Good Example - Domain class with encapsulation
|
||||
public class User { // Domain class
|
||||
private string name;
|
||||
private User(string name) { this.name = name; }
|
||||
public static User Create(string name) => new User(name);
|
||||
}
|
||||
|
||||
// Acceptable Example - DTO with public setters
|
||||
public class UserDto { // DTO - exemption applies
|
||||
public string Name { get; set; } // Acceptable for DTOs
|
||||
}
|
||||
```
|
||||
|
||||
## Implementation Guidelines
|
||||
- **Domain Classes**:
|
||||
- Use private constructors and static factory methods for creating instances.
|
||||
- Avoid exposing setters for properties.
|
||||
- Apply all 9 rules strictly for business domain code.
|
||||
|
||||
- **Application Layer**:
|
||||
- Apply these rules to use case handlers and application services.
|
||||
- Focus on maintaining single responsibility and clean abstractions.
|
||||
|
||||
- **DTOs and Data Objects**:
|
||||
- Rules 3 (wrapping primitives), 8 (two instance variables), and 9 (no getters/setters) may be relaxed for DTOs.
|
||||
- Public properties with getters/setters are acceptable for data transfer objects.
|
||||
|
||||
- **Testing**:
|
||||
- Ensure tests validate the behavior of objects rather than their state.
|
||||
- Test classes may have relaxed rules for readability and maintainability.
|
||||
|
||||
- **Code Reviews**:
|
||||
- Enforce these rules during code reviews for domain and application code.
|
||||
- Be pragmatic about infrastructure and DTO code.
|
||||
|
||||
## References
|
||||
- [Object Calisthenics - Original 9 Rules by Jeff Bay](https://www.cs.helsinki.fi/u/luontola/tdd-2009/ext/ObjectCalisthenics.pdf)
|
||||
- [ThoughtWorks - Object Calisthenics](https://www.thoughtworks.com/insights/blog/object-calisthenics)
|
||||
- [Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin](https://www.oreilly.com/library/view/clean-code-a/9780136083238/)
|
||||
197
instructions/powershell-pester-5.instructions.md
Normal file
197
instructions/powershell-pester-5.instructions.md
Normal file
@ -0,0 +1,197 @@
|
||||
---
|
||||
applyTo: '**/*.Tests.ps1'
|
||||
description: 'PowerShell Pester testing best practices based on Pester v5 conventions'
|
||||
---
|
||||
|
||||
# PowerShell Pester v5 Testing Guidelines
|
||||
|
||||
This guide provides PowerShell-specific instructions for creating automated tests using PowerShell Pester v5 module. Follow PowerShell cmdlet development guidelines in [powershell.instructions.md](./powershell.instructions.md) for general PowerShell scripting best practices.
|
||||
|
||||
## File Naming and Structure
|
||||
|
||||
- **File Convention:** Use `*.Tests.ps1` naming pattern
|
||||
- **Placement:** Place test files next to tested code or in dedicated test directories
|
||||
- **Import Pattern:** Use `BeforeAll { . $PSScriptRoot/FunctionName.ps1 }` to import tested functions
|
||||
- **No Direct Code:** Put ALL code inside Pester blocks (`BeforeAll`, `Describe`, `Context`, `It`, etc.)
|
||||
|
||||
## Test Structure Hierarchy
|
||||
|
||||
```powershell
|
||||
BeforeAll { # Import tested functions }
|
||||
Describe 'FunctionName' {
|
||||
Context 'When condition' {
|
||||
BeforeAll { # Setup for context }
|
||||
It 'Should behavior' { # Individual test }
|
||||
AfterAll { # Cleanup for context }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Core Keywords
|
||||
|
||||
- **`Describe`**: Top-level grouping, typically named after function being tested
|
||||
- **`Context`**: Sub-grouping within Describe for specific scenarios
|
||||
- **`It`**: Individual test cases, use descriptive names
|
||||
- **`Should`**: Assertion keyword for test validation
|
||||
- **`BeforeAll/AfterAll`**: Setup/teardown once per block
|
||||
- **`BeforeEach/AfterEach`**: Setup/teardown before/after each test
|
||||
|
||||
## Setup and Teardown
|
||||
|
||||
- **`BeforeAll`**: Runs once at start of containing block, use for expensive operations
|
||||
- **`BeforeEach`**: Runs before every `It` in block, use for test-specific setup
|
||||
- **`AfterEach`**: Runs after every `It`, guaranteed even if test fails
|
||||
- **`AfterAll`**: Runs once at end of block, use for cleanup
|
||||
- **Variable Scoping**: `BeforeAll` variables available to child blocks (read-only), `BeforeEach/It/AfterEach` share same scope
|
||||
|
||||
## Assertions (Should)
|
||||
|
||||
- **Basic Comparisons**: `-Be`, `-BeExactly`, `-Not -Be`
|
||||
- **Collections**: `-Contain`, `-BeIn`, `-HaveCount`
|
||||
- **Numeric**: `-BeGreaterThan`, `-BeLessThan`, `-BeGreaterOrEqual`
|
||||
- **Strings**: `-Match`, `-Like`, `-BeNullOrEmpty`
|
||||
- **Types**: `-BeOfType`, `-BeTrue`, `-BeFalse`
|
||||
- **Files**: `-Exist`, `-FileContentMatch`
|
||||
- **Exceptions**: `-Throw`, `-Not -Throw`
|
||||
|
||||
## Mocking
|
||||
|
||||
- **`Mock CommandName { ScriptBlock }`**: Replace command behavior
|
||||
- **`-ParameterFilter`**: Mock only when parameters match condition
|
||||
- **`-Verifiable`**: Mark mock as requiring verification
|
||||
- **`Should -Invoke`**: Verify mock was called specific number of times
|
||||
- **`Should -InvokeVerifiable`**: Verify all verifiable mocks were called
|
||||
- **Scope**: Mocks default to containing block scope
|
||||
|
||||
```powershell
|
||||
Mock Get-Service { @{ Status = 'Running' } } -ParameterFilter { $Name -eq 'TestService' }
|
||||
Should -Invoke Get-Service -Exactly 1 -ParameterFilter { $Name -eq 'TestService' }
|
||||
```
|
||||
|
||||
## Test Cases (Data-Driven Tests)
|
||||
|
||||
Use `-TestCases` or `-ForEach` for parameterized tests:
|
||||
|
||||
```powershell
|
||||
It 'Should return <Expected> for <Input>' -TestCases @(
|
||||
@{ Input = 'value1'; Expected = 'result1' }
|
||||
@{ Input = 'value2'; Expected = 'result2' }
|
||||
) {
|
||||
Get-Function $Input | Should -Be $Expected
|
||||
}
|
||||
```
|
||||
|
||||
## Data-Driven Tests
|
||||
|
||||
- **`-ForEach`**: Available on `Describe`, `Context`, and `It` for generating multiple tests from data
|
||||
- **`-TestCases`**: Alias for `-ForEach` on `It` blocks (backwards compatibility)
|
||||
- **Hashtable Data**: Each item defines variables available in test (e.g., `@{ Name = 'value'; Expected = 'result' }`)
|
||||
- **Array Data**: Uses `$_` variable for current item
|
||||
- **Templates**: Use `<variablename>` in test names for dynamic expansion
|
||||
|
||||
```powershell
|
||||
# Hashtable approach
|
||||
It 'Returns <Expected> for <Name>' -ForEach @(
|
||||
@{ Name = 'test1'; Expected = 'result1' }
|
||||
@{ Name = 'test2'; Expected = 'result2' }
|
||||
) { Get-Function $Name | Should -Be $Expected }
|
||||
|
||||
# Array approach
|
||||
It 'Contains <_>' -ForEach 'item1', 'item2' { Get-Collection | Should -Contain $_ }
|
||||
```
|
||||
|
||||
## Tags
|
||||
|
||||
- **Available on**: `Describe`, `Context`, and `It` blocks
|
||||
- **Filtering**: Use `-TagFilter` and `-ExcludeTagFilter` with `Invoke-Pester`
|
||||
- **Wildcards**: Tags support `-like` wildcards for flexible filtering
|
||||
|
||||
```powershell
|
||||
Describe 'Function' -Tag 'Unit' {
|
||||
It 'Should work' -Tag 'Fast', 'Stable' { }
|
||||
It 'Should be slow' -Tag 'Slow', 'Integration' { }
|
||||
}
|
||||
|
||||
# Run only fast unit tests
|
||||
Invoke-Pester -TagFilter 'Unit' -ExcludeTagFilter 'Slow'
|
||||
```
|
||||
|
||||
## Skip
|
||||
|
||||
- **`-Skip`**: Available on `Describe`, `Context`, and `It` to skip tests
|
||||
- **Conditional**: Use `-Skip:$condition` for dynamic skipping
|
||||
- **Runtime Skip**: Use `Set-ItResult -Skipped` during test execution (setup/teardown still run)
|
||||
|
||||
```powershell
|
||||
It 'Should work on Windows' -Skip:(-not $IsWindows) { }
|
||||
Context 'Integration tests' -Skip { }
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
- **Continue on Failure**: Use `Should.ErrorAction = 'Continue'` to collect multiple failures
|
||||
- **Stop on Critical**: Use `-ErrorAction Stop` for pre-conditions
|
||||
- **Test Exceptions**: Use `{ Code } | Should -Throw` for exception testing
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Descriptive Names**: Use clear test descriptions that explain behavior
|
||||
- **AAA Pattern**: Arrange (setup), Act (execute), Assert (verify)
|
||||
- **Isolated Tests**: Each test should be independent
|
||||
- **Avoid Aliases**: Use full cmdlet names (`Where-Object` not `?`)
|
||||
- **Single Responsibility**: One assertion per test when possible
|
||||
- **Test File Organization**: Group related tests in Context blocks. Context blocks can be nested.
|
||||
|
||||
## Example Test Pattern
|
||||
|
||||
```powershell
|
||||
BeforeAll {
|
||||
. $PSScriptRoot/Get-UserInfo.ps1
|
||||
}
|
||||
|
||||
Describe 'Get-UserInfo' {
|
||||
Context 'When user exists' {
|
||||
BeforeAll {
|
||||
Mock Get-ADUser { @{ Name = 'TestUser'; Enabled = $true } }
|
||||
}
|
||||
|
||||
It 'Should return user object' {
|
||||
$result = Get-UserInfo -Username 'TestUser'
|
||||
$result | Should -Not -BeNullOrEmpty
|
||||
$result.Name | Should -Be 'TestUser'
|
||||
}
|
||||
|
||||
It 'Should call Get-ADUser once' {
|
||||
Get-UserInfo -Username 'TestUser'
|
||||
Should -Invoke Get-ADUser -Exactly 1
|
||||
}
|
||||
}
|
||||
|
||||
Context 'When user does not exist' {
|
||||
BeforeAll {
|
||||
Mock Get-ADUser { throw "User not found" }
|
||||
}
|
||||
|
||||
It 'Should throw exception' {
|
||||
{ Get-UserInfo -Username 'NonExistent' } | Should -Throw "*not found*"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
Configuration is defined **outside** test files when calling `Invoke-Pester` to control execution behavior.
|
||||
|
||||
```powershell
|
||||
# Create configuration (Pester 5.2+)
|
||||
$config = New-PesterConfiguration
|
||||
$config.Run.Path = './Tests'
|
||||
$config.Output.Verbosity = 'Detailed'
|
||||
$config.TestResult.Enabled = $true
|
||||
$config.TestResult.OutputFormat = 'NUnitXml'
|
||||
$config.Should.ErrorAction = 'Continue'
|
||||
Invoke-Pester -Configuration $config
|
||||
```
|
||||
|
||||
**Key Sections**: Run (Path, Exit), Filter (Tag, ExcludeTag), Output (Verbosity), TestResult (Enabled, OutputFormat), CodeCoverage (Enabled, Path), Should (ErrorAction), Debug
|
||||
321
prompts/architecture-blueprint-generator.prompt.md
Normal file
321
prompts/architecture-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,321 @@
|
||||
---
|
||||
description: 'Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development.'
|
||||
---
|
||||
|
||||
# Comprehensive Project Architecture Blueprint Generator
|
||||
|
||||
## Configuration Variables
|
||||
${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"} <!-- Primary technology -->
|
||||
${ARCHITECTURE_PATTERN="Auto-detect|Clean Architecture|Microservices|Layered|MVVM|MVC|Hexagonal|Event-Driven|Serverless|Monolithic|Other"} <!-- Primary architectural pattern -->
|
||||
${DIAGRAM_TYPE="C4|UML|Flow|Component|None"} <!-- Architecture diagram type -->
|
||||
${DETAIL_LEVEL="High-level|Detailed|Comprehensive|Implementation-Ready"} <!-- Level of detail to include -->
|
||||
${INCLUDES_CODE_EXAMPLES=true|false} <!-- Include sample code to illustrate patterns -->
|
||||
${INCLUDES_IMPLEMENTATION_PATTERNS=true|false} <!-- Include detailed implementation patterns -->
|
||||
${INCLUDES_DECISION_RECORDS=true|false} <!-- Include architectural decision records -->
|
||||
${FOCUS_ON_EXTENSIBILITY=true|false} <!-- Emphasize extension points and patterns -->
|
||||
|
||||
## Generated Prompt
|
||||
|
||||
"Create a comprehensive 'Project_Architecture_Blueprint.md' document that thoroughly analyzes the architectural patterns in the codebase to serve as a definitive reference for maintaining architectural consistency. Use the following approach:
|
||||
|
||||
### 1. Architecture Detection and Analysis
|
||||
- ${PROJECT_TYPE == "Auto-detect" ? "Analyze the project structure to identify all technology stacks and frameworks in use by examining:
|
||||
- Project and configuration files
|
||||
- Package dependencies and import statements
|
||||
- Framework-specific patterns and conventions
|
||||
- Build and deployment configurations" : "Focus on ${PROJECT_TYPE} specific patterns and practices"}
|
||||
|
||||
- ${ARCHITECTURE_PATTERN == "Auto-detect" ? "Determine the architectural pattern(s) by analyzing:
|
||||
- Folder organization and namespacing
|
||||
- Dependency flow and component boundaries
|
||||
- Interface segregation and abstraction patterns
|
||||
- Communication mechanisms between components" : "Document how the ${ARCHITECTURE_PATTERN} architecture is implemented"}
|
||||
|
||||
### 2. Architectural Overview
|
||||
- Provide a clear, concise explanation of the overall architectural approach
|
||||
- Document the guiding principles evident in the architectural choices
|
||||
- Identify architectural boundaries and how they're enforced
|
||||
- Note any hybrid architectural patterns or adaptations of standard patterns
|
||||
|
||||
### 3. Architecture Visualization
|
||||
${DIAGRAM_TYPE != "None" ? `Create ${DIAGRAM_TYPE} diagrams at multiple levels of abstraction:
|
||||
- High-level architectural overview showing major subsystems
|
||||
- Component interaction diagrams showing relationships and dependencies
|
||||
- Data flow diagrams showing how information moves through the system
|
||||
- Ensure diagrams accurately reflect the actual implementation, not theoretical patterns` : "Describe the component relationships based on actual code dependencies, providing clear textual explanations of:
|
||||
- Subsystem organization and boundaries
|
||||
- Dependency directions and component interactions
|
||||
- Data flow and process sequences"}
|
||||
|
||||
### 4. Core Architectural Components
|
||||
For each architectural component discovered in the codebase:
|
||||
|
||||
- **Purpose and Responsibility**:
|
||||
- Primary function within the architecture
|
||||
- Business domains or technical concerns addressed
|
||||
- Boundaries and scope limitations
|
||||
|
||||
- **Internal Structure**:
|
||||
- Organization of classes/modules within the component
|
||||
- Key abstractions and their implementations
|
||||
- Design patterns utilized
|
||||
|
||||
- **Interaction Patterns**:
|
||||
- How the component communicates with others
|
||||
- Interfaces exposed and consumed
|
||||
- Dependency injection patterns
|
||||
- Event publishing/subscription mechanisms
|
||||
|
||||
- **Evolution Patterns**:
|
||||
- How the component can be extended
|
||||
- Variation points and plugin mechanisms
|
||||
- Configuration and customization approaches
|
||||
|
||||
### 5. Architectural Layers and Dependencies
|
||||
- Map the layer structure as implemented in the codebase
|
||||
- Document the dependency rules between layers
|
||||
- Identify abstraction mechanisms that enable layer separation
|
||||
- Note any circular dependencies or layer violations
|
||||
- Document dependency injection patterns used to maintain separation
|
||||
|
||||
### 6. Data Architecture
|
||||
- Document domain model structure and organization
|
||||
- Map entity relationships and aggregation patterns
|
||||
- Identify data access patterns (repositories, data mappers, etc.)
|
||||
- Document data transformation and mapping approaches
|
||||
- Note caching strategies and implementations
|
||||
- Document data validation patterns
|
||||
|
||||
### 7. Cross-Cutting Concerns Implementation
|
||||
Document implementation patterns for cross-cutting concerns:
|
||||
|
||||
- **Authentication & Authorization**:
|
||||
- Security model implementation
|
||||
- Permission enforcement patterns
|
||||
- Identity management approach
|
||||
- Security boundary patterns
|
||||
|
||||
- **Error Handling & Resilience**:
|
||||
- Exception handling patterns
|
||||
- Retry and circuit breaker implementations
|
||||
- Fallback and graceful degradation strategies
|
||||
- Error reporting and monitoring approaches
|
||||
|
||||
- **Logging & Monitoring**:
|
||||
- Instrumentation patterns
|
||||
- Observability implementation
|
||||
- Diagnostic information flow
|
||||
- Performance monitoring approach
|
||||
|
||||
- **Validation**:
|
||||
- Input validation strategies
|
||||
- Business rule validation implementation
|
||||
- Validation responsibility distribution
|
||||
- Error reporting patterns
|
||||
|
||||
- **Configuration Management**:
|
||||
- Configuration source patterns
|
||||
- Environment-specific configuration strategies
|
||||
- Secret management approach
|
||||
- Feature flag implementation
|
||||
|
||||
### 8. Service Communication Patterns
|
||||
- Document service boundary definitions
|
||||
- Identify communication protocols and formats
|
||||
- Map synchronous vs. asynchronous communication patterns
|
||||
- Document API versioning strategies
|
||||
- Identify service discovery mechanisms
|
||||
- Note resilience patterns in service communication
|
||||
|
||||
### 9. Technology-Specific Architectural Patterns
|
||||
${PROJECT_TYPE == "Auto-detect" ? "For each detected technology stack, document specific architectural patterns:" : `Document ${PROJECT_TYPE}-specific architectural patterns:`}
|
||||
|
||||
${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### .NET Architectural Patterns (if detected)
|
||||
- Host and application model implementation
|
||||
- Middleware pipeline organization
|
||||
- Framework service integration patterns
|
||||
- ORM and data access approaches
|
||||
- API implementation patterns (controllers, minimal APIs, etc.)
|
||||
- Dependency injection container configuration" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### Java Architectural Patterns (if detected)
|
||||
- Application container and bootstrap process
|
||||
- Dependency injection framework usage (Spring, CDI, etc.)
|
||||
- AOP implementation patterns
|
||||
- Transaction boundary management
|
||||
- ORM configuration and usage patterns
|
||||
- Service implementation patterns" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### React Architectural Patterns (if detected)
|
||||
- Component composition and reuse strategies
|
||||
- State management architecture
|
||||
- Side effect handling patterns
|
||||
- Routing and navigation approach
|
||||
- Data fetching and caching patterns
|
||||
- Rendering optimization strategies" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### Angular Architectural Patterns (if detected)
|
||||
- Module organization strategy
|
||||
- Component hierarchy design
|
||||
- Service and dependency injection patterns
|
||||
- State management approach
|
||||
- Reactive programming patterns
|
||||
- Route guard implementation" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### Python Architectural Patterns (if detected)
|
||||
- Module organization approach
|
||||
- Dependency management strategy
|
||||
- OOP vs. functional implementation patterns
|
||||
- Framework integration patterns
|
||||
- Asynchronous programming approach" : ""}
|
||||
|
||||
### 10. Implementation Patterns
|
||||
${INCLUDES_IMPLEMENTATION_PATTERNS ?
|
||||
"Document concrete implementation patterns for key architectural components:
|
||||
|
||||
- **Interface Design Patterns**:
|
||||
- Interface segregation approaches
|
||||
- Abstraction level decisions
|
||||
- Generic vs. specific interface patterns
|
||||
- Default implementation patterns
|
||||
|
||||
- **Service Implementation Patterns**:
|
||||
- Service lifetime management
|
||||
- Service composition patterns
|
||||
- Operation implementation templates
|
||||
- Error handling within services
|
||||
|
||||
- **Repository Implementation Patterns**:
|
||||
- Query pattern implementations
|
||||
- Transaction management
|
||||
- Concurrency handling
|
||||
- Bulk operation patterns
|
||||
|
||||
- **Controller/API Implementation Patterns**:
|
||||
- Request handling patterns
|
||||
- Response formatting approaches
|
||||
- Parameter validation
|
||||
- API versioning implementation
|
||||
|
||||
- **Domain Model Implementation**:
|
||||
- Entity implementation patterns
|
||||
- Value object patterns
|
||||
- Domain event implementation
|
||||
- Business rule enforcement" : "Mention that detailed implementation patterns vary across the codebase."}
|
||||
|
||||
### 11. Testing Architecture
|
||||
- Document testing strategies aligned with the architecture
|
||||
- Identify test boundary patterns (unit, integration, system)
|
||||
- Map test doubles and mocking approaches
|
||||
- Document test data strategies
|
||||
- Note testing tools and frameworks integration
|
||||
|
||||
### 12. Deployment Architecture
|
||||
- Document deployment topology derived from configuration
|
||||
- Identify environment-specific architectural adaptations
|
||||
- Map runtime dependency resolution patterns
|
||||
- Document configuration management across environments
|
||||
- Identify containerization and orchestration approaches
|
||||
- Note cloud service integration patterns
|
||||
|
||||
### 13. Extension and Evolution Patterns
|
||||
${FOCUS_ON_EXTENSIBILITY ?
|
||||
"Provide detailed guidance for extending the architecture:
|
||||
|
||||
- **Feature Addition Patterns**:
|
||||
- How to add new features while preserving architectural integrity
|
||||
- Where to place new components by type
|
||||
- Dependency introduction guidelines
|
||||
- Configuration extension patterns
|
||||
|
||||
- **Modification Patterns**:
|
||||
- How to safely modify existing components
|
||||
- Strategies for maintaining backward compatibility
|
||||
- Deprecation patterns
|
||||
- Migration approaches
|
||||
|
||||
- **Integration Patterns**:
|
||||
- How to integrate new external systems
|
||||
- Adapter implementation patterns
|
||||
- Anti-corruption layer patterns
|
||||
- Service facade implementation" : "Document key extension points in the architecture."}
|
||||
|
||||
${INCLUDES_CODE_EXAMPLES ?
|
||||
"### 14. Architectural Pattern Examples
|
||||
Extract representative code examples that illustrate key architectural patterns:
|
||||
|
||||
- **Layer Separation Examples**:
|
||||
- Interface definition and implementation separation
|
||||
- Cross-layer communication patterns
|
||||
- Dependency injection examples
|
||||
|
||||
- **Component Communication Examples**:
|
||||
- Service invocation patterns
|
||||
- Event publication and handling
|
||||
- Message passing implementation
|
||||
|
||||
- **Extension Point Examples**:
|
||||
- Plugin registration and discovery
|
||||
- Extension interface implementations
|
||||
- Configuration-driven extension patterns
|
||||
|
||||
Include enough context with each example to show the pattern clearly, but keep examples concise and focused on architectural concepts." : ""}
|
||||
|
||||
${INCLUDES_DECISION_RECORDS ?
|
||||
"### 15. Architectural Decision Records
|
||||
Document key architectural decisions evident in the codebase:
|
||||
|
||||
- **Architectural Style Decisions**:
|
||||
- Why the current architectural pattern was chosen
|
||||
- Alternatives considered (based on code evolution)
|
||||
- Constraints that influenced the decision
|
||||
|
||||
- **Technology Selection Decisions**:
|
||||
- Key technology choices and their architectural impact
|
||||
- Framework selection rationales
|
||||
- Custom vs. off-the-shelf component decisions
|
||||
|
||||
- **Implementation Approach Decisions**:
|
||||
- Specific implementation patterns chosen
|
||||
- Standard pattern adaptations
|
||||
- Performance vs. maintainability tradeoffs
|
||||
|
||||
For each decision, note:
|
||||
- Context that made the decision necessary
|
||||
- Factors considered in making the decision
|
||||
- Resulting consequences (positive and negative)
|
||||
- Future flexibility or limitations introduced" : ""}
|
||||
|
||||
### ${INCLUDES_DECISION_RECORDS ? "16" : INCLUDES_CODE_EXAMPLES ? "15" : "14"}. Architecture Governance
|
||||
- Document how architectural consistency is maintained
|
||||
- Identify automated checks for architectural compliance
|
||||
- Note architectural review processes evident in the codebase
|
||||
- Document architectural documentation practices
|
||||
|
||||
### ${INCLUDES_DECISION_RECORDS ? "17" : INCLUDES_CODE_EXAMPLES ? "16" : "15"}. Blueprint for New Development
|
||||
Create a clear architectural guide for implementing new features:
|
||||
|
||||
- **Development Workflow**:
|
||||
- Starting points for different feature types
|
||||
- Component creation sequence
|
||||
- Integration steps with existing architecture
|
||||
- Testing approach by architectural layer
|
||||
|
||||
- **Implementation Templates**:
|
||||
- Base class/interface templates for key architectural components
|
||||
- Standard file organization for new components
|
||||
- Dependency declaration patterns
|
||||
- Documentation requirements
|
||||
|
||||
- **Common Pitfalls**:
|
||||
- Architecture violations to avoid
|
||||
- Common architectural mistakes
|
||||
- Performance considerations
|
||||
- Testing blind spots
|
||||
|
||||
Include information about when this blueprint was generated and recommendations for keeping it updated as the architecture evolves."
|
||||
125
prompts/code-exemplars-blueprint-generator.prompt.md
Normal file
125
prompts/code-exemplars-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,125 @@
|
||||
---
|
||||
description: 'Technology-agnostic prompt generator that creates customizable AI prompts for scanning codebases and identifying high-quality code exemplars. Supports multiple programming languages (.NET, Java, JavaScript, TypeScript, React, Angular, Python) with configurable analysis depth, categorization methods, and documentation formats to establish coding standards and maintain consistency across development teams.'
|
||||
---
|
||||
|
||||
# Code Exemplars Blueprint Generator
|
||||
|
||||
## Configuration Variables
|
||||
${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Other"} <!-- Primary technology -->
|
||||
${SCAN_DEPTH="Basic|Standard|Comprehensive"} <!-- How deeply to analyze the codebase -->
|
||||
${INCLUDE_CODE_SNIPPETS=true|false} <!-- Include actual code snippets in addition to file references -->
|
||||
${CATEGORIZATION="Pattern Type|Architecture Layer|File Type"} <!-- How to organize exemplars -->
|
||||
${MAX_EXAMPLES_PER_CATEGORY=3} <!-- Maximum number of examples per category -->
|
||||
${INCLUDE_COMMENTS=true|false} <!-- Include explanatory comments for each exemplar -->
|
||||
|
||||
## Generated Prompt
|
||||
|
||||
"Scan this codebase and generate an exemplars.md file that identifies high-quality, representative code examples. The exemplars should demonstrate our coding standards and patterns to help maintain consistency. Use the following approach:
|
||||
|
||||
### 1. Codebase Analysis Phase
|
||||
- ${PROJECT_TYPE == "Auto-detect" ? "Automatically detect primary programming languages and frameworks by scanning file extensions and configuration files" : `Focus on ${PROJECT_TYPE} code files`}
|
||||
- Identify files with high-quality implementation, good documentation, and clear structure
|
||||
- Look for commonly used patterns, architecture components, and well-structured implementations
|
||||
- Prioritize files that demonstrate best practices for our technology stack
|
||||
- Only reference actual files that exist in the codebase - no hypothetical examples
|
||||
|
||||
### 2. Exemplar Identification Criteria
|
||||
- Well-structured, readable code with clear naming conventions
|
||||
- Comprehensive comments and documentation
|
||||
- Proper error handling and validation
|
||||
- Adherence to design patterns and architectural principles
|
||||
- Separation of concerns and single responsibility principle
|
||||
- Efficient implementation without code smells
|
||||
- Representative of our standard approaches
|
||||
|
||||
### 3. Core Pattern Categories
|
||||
|
||||
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" ? `#### .NET Exemplars (if detected)
|
||||
- **Domain Models**: Find entities that properly implement encapsulation and domain logic
|
||||
- **Repository Implementations**: Examples of our data access approach
|
||||
- **Service Layer Components**: Well-structured business logic implementations
|
||||
- **Controller Patterns**: Clean API controllers with proper validation and responses
|
||||
- **Dependency Injection Usage**: Good examples of DI configuration and usage
|
||||
- **Middleware Components**: Custom middleware implementations
|
||||
- **Unit Test Patterns**: Well-structured tests with proper arrangement and assertions` : ""}
|
||||
|
||||
${(PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "React" || PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? `#### Frontend Exemplars (if detected)
|
||||
- **Component Structure**: Clean, well-structured components
|
||||
- **State Management**: Good examples of state handling
|
||||
- **API Integration**: Well-implemented service calls and data handling
|
||||
- **Form Handling**: Validation and submission patterns
|
||||
- **Routing Implementation**: Navigation and route configuration
|
||||
- **UI Components**: Reusable, well-structured UI elements
|
||||
- **Unit Test Examples**: Component and service tests` : ""}
|
||||
|
||||
${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" ? `#### Java Exemplars (if detected)
|
||||
- **Entity Classes**: Well-designed JPA entities or domain models
|
||||
- **Service Implementations**: Clean service layer components
|
||||
- **Repository Patterns**: Data access implementations
|
||||
- **Controller/Resource Classes**: API endpoint implementations
|
||||
- **Configuration Classes**: Application configuration
|
||||
- **Unit Tests**: Well-structured JUnit tests` : ""}
|
||||
|
||||
${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" ? `#### Python Exemplars (if detected)
|
||||
- **Class Definitions**: Well-structured classes with proper documentation
|
||||
- **API Routes/Views**: Clean API implementations
|
||||
- **Data Models**: ORM model definitions
|
||||
- **Service Functions**: Business logic implementations
|
||||
- **Utility Modules**: Helper and utility functions
|
||||
- **Test Cases**: Well-structured unit tests` : ""}
|
||||
|
||||
### 4. Architecture Layer Exemplars
|
||||
|
||||
- **Presentation Layer**:
|
||||
- User interface components
|
||||
- Controllers/API endpoints
|
||||
- View models/DTOs
|
||||
|
||||
- **Business Logic Layer**:
|
||||
- Service implementations
|
||||
- Business logic components
|
||||
- Workflow orchestration
|
||||
|
||||
- **Data Access Layer**:
|
||||
- Repository implementations
|
||||
- Data models
|
||||
- Query patterns
|
||||
|
||||
- **Cross-Cutting Concerns**:
|
||||
- Logging implementations
|
||||
- Error handling
|
||||
- Authentication/authorization
|
||||
- Validation
|
||||
|
||||
### 5. Exemplar Documentation Format
|
||||
|
||||
For each identified exemplar, document:
|
||||
- File path (relative to repository root)
|
||||
- Brief description of what makes it exemplary
|
||||
- Pattern or component type it represents
|
||||
${INCLUDE_COMMENTS ? "- Key implementation details and coding principles demonstrated" : ""}
|
||||
${INCLUDE_CODE_SNIPPETS ? "- Small, representative code snippet (if applicable)" : ""}
|
||||
|
||||
${SCAN_DEPTH == "Comprehensive" ? `### 6. Additional Documentation
|
||||
|
||||
- **Consistency Patterns**: Note consistent patterns observed across the codebase
|
||||
- **Architecture Observations**: Document architectural patterns evident in the code
|
||||
- **Implementation Conventions**: Identify naming and structural conventions
|
||||
- **Anti-patterns to Avoid**: Note any areas where the codebase deviates from best practices` : ""}
|
||||
|
||||
### ${SCAN_DEPTH == "Comprehensive" ? "7" : "6"}. Output Format
|
||||
|
||||
Create exemplars.md with:
|
||||
1. Introduction explaining the purpose of the document
|
||||
2. Table of contents with links to categories
|
||||
3. Organized sections based on ${CATEGORIZATION}
|
||||
4. Up to ${MAX_EXAMPLES_PER_CATEGORY} exemplars per category
|
||||
5. Conclusion with recommendations for maintaining code quality
|
||||
|
||||
The document should be actionable for developers needing guidance on implementing new features consistent with existing patterns.
|
||||
|
||||
Important: Only include actual files from the codebase. Verify all file paths exist. Do not include placeholder or hypothetical examples.
|
||||
"
|
||||
|
||||
## Expected Output
|
||||
Upon running this prompt, GitHub Copilot will scan your codebase and generate an exemplars.md file containing real references to high-quality code examples in your repository, organized according to your selected parameters.
|
||||
293
prompts/copilot-instructions-blueprint-generator.prompt.md
Normal file
293
prompts/copilot-instructions-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,293 @@
|
||||
---
|
||||
description: 'Technology-agnostic blueprint generator for creating comprehensive copilot-instructions.md files that guide GitHub Copilot to produce code consistent with project standards, architecture patterns, and exact technology versions by analyzing existing codebase patterns and avoiding assumptions.'
|
||||
---
|
||||
|
||||
# Copilot Instructions Blueprint Generator
|
||||
|
||||
## Configuration Variables
|
||||
${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|TypeScript|React|Angular|Python|Multiple|Other"} <!-- Primary technology -->
|
||||
${ARCHITECTURE_STYLE="Layered|Microservices|Monolithic|Domain-Driven|Event-Driven|Serverless|Mixed"} <!-- Architectural approach -->
|
||||
${CODE_QUALITY_FOCUS="Maintainability|Performance|Security|Accessibility|Testability|All"} <!-- Quality priorities -->
|
||||
${DOCUMENTATION_LEVEL="Minimal|Standard|Comprehensive"} <!-- Documentation requirements -->
|
||||
${TESTING_REQUIREMENTS="Unit|Integration|E2E|TDD|BDD|All"} <!-- Testing approach -->
|
||||
${VERSIONING="Semantic|CalVer|Custom"} <!-- Versioning approach -->
|
||||
|
||||
## Generated Prompt
|
||||
|
||||
"Generate a comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code consistent with our project's standards, architecture, and technology versions. The instructions must be strictly based on actual code patterns in our codebase and avoid making any assumptions. Follow this approach:
|
||||
|
||||
### 1. Core Instruction Structure
|
||||
|
||||
```markdown
|
||||
# GitHub Copilot Instructions
|
||||
|
||||
## Priority Guidelines
|
||||
|
||||
When generating code for this repository:
|
||||
|
||||
1. **Version Compatibility**: Always detect and respect the exact versions of languages, frameworks, and libraries used in this project
|
||||
2. **Context Files**: Prioritize patterns and standards defined in the .github/copilot directory
|
||||
3. **Codebase Patterns**: When context files don't provide specific guidance, scan the codebase for established patterns
|
||||
4. **Architectural Consistency**: Maintain our ${ARCHITECTURE_STYLE} architectural style and established boundaries
|
||||
5. **Code Quality**: Prioritize ${CODE_QUALITY_FOCUS == "All" ? "maintainability, performance, security, accessibility, and testability" : CODE_QUALITY_FOCUS} in all generated code
|
||||
|
||||
## Technology Version Detection
|
||||
|
||||
Before generating code, scan the codebase to identify:
|
||||
|
||||
1. **Language Versions**: Detect the exact versions of programming languages in use
|
||||
- Examine project files, configuration files, and package managers
|
||||
- Look for language-specific version indicators (e.g., <LangVersion> in .NET projects)
|
||||
- Never use language features beyond the detected version
|
||||
|
||||
2. **Framework Versions**: Identify the exact versions of all frameworks
|
||||
- Check package.json, .csproj, pom.xml, requirements.txt, etc.
|
||||
- Respect version constraints when generating code
|
||||
- Never suggest features not available in the detected framework versions
|
||||
|
||||
3. **Library Versions**: Note the exact versions of key libraries and dependencies
|
||||
- Generate code compatible with these specific versions
|
||||
- Never use APIs or features not available in the detected versions
|
||||
|
||||
## Context Files
|
||||
|
||||
Prioritize the following files in .github/copilot directory (if they exist):
|
||||
|
||||
- **architecture.md**: System architecture guidelines
|
||||
- **tech-stack.md**: Technology versions and framework details
|
||||
- **coding-standards.md**: Code style and formatting standards
|
||||
- **folder-structure.md**: Project organization guidelines
|
||||
- **exemplars.md**: Exemplary code patterns to follow
|
||||
|
||||
## Codebase Scanning Instructions
|
||||
|
||||
When context files don't provide specific guidance:
|
||||
|
||||
1. Identify similar files to the one being modified or created
|
||||
2. Analyze patterns for:
|
||||
- Naming conventions
|
||||
- Code organization
|
||||
- Error handling
|
||||
- Logging approaches
|
||||
- Documentation style
|
||||
- Testing patterns
|
||||
|
||||
3. Follow the most consistent patterns found in the codebase
|
||||
4. When conflicting patterns exist, prioritize patterns in newer files or files with higher test coverage
|
||||
5. Never introduce patterns not found in the existing codebase
|
||||
|
||||
## Code Quality Standards
|
||||
|
||||
${CODE_QUALITY_FOCUS.includes("Maintainability") || CODE_QUALITY_FOCUS == "All" ? `### Maintainability
|
||||
- Write self-documenting code with clear naming
|
||||
- Follow the naming and organization conventions evident in the codebase
|
||||
- Follow established patterns for consistency
|
||||
- Keep functions focused on single responsibilities
|
||||
- Limit function complexity and length to match existing patterns` : ""}
|
||||
|
||||
${CODE_QUALITY_FOCUS.includes("Performance") || CODE_QUALITY_FOCUS == "All" ? `### Performance
|
||||
- Follow existing patterns for memory and resource management
|
||||
- Match existing patterns for handling computationally expensive operations
|
||||
- Follow established patterns for asynchronous operations
|
||||
- Apply caching consistently with existing patterns
|
||||
- Optimize according to patterns evident in the codebase` : ""}
|
||||
|
||||
${CODE_QUALITY_FOCUS.includes("Security") || CODE_QUALITY_FOCUS == "All" ? `### Security
|
||||
- Follow existing patterns for input validation
|
||||
- Apply the same sanitization techniques used in the codebase
|
||||
- Use parameterized queries matching existing patterns
|
||||
- Follow established authentication and authorization patterns
|
||||
- Handle sensitive data according to existing patterns` : ""}
|
||||
|
||||
${CODE_QUALITY_FOCUS.includes("Accessibility") || CODE_QUALITY_FOCUS == "All" ? `### Accessibility
|
||||
- Follow existing accessibility patterns in the codebase
|
||||
- Match ARIA attribute usage with existing components
|
||||
- Maintain keyboard navigation support consistent with existing code
|
||||
- Follow established patterns for color and contrast
|
||||
- Apply text alternative patterns consistent with the codebase` : ""}
|
||||
|
||||
${CODE_QUALITY_FOCUS.includes("Testability") || CODE_QUALITY_FOCUS == "All" ? `### Testability
|
||||
- Follow established patterns for testable code
|
||||
- Match dependency injection approaches used in the codebase
|
||||
- Apply the same patterns for managing dependencies
|
||||
- Follow established mocking and test double patterns
|
||||
- Match the testing style used in existing tests` : ""}
|
||||
|
||||
## Documentation Requirements
|
||||
|
||||
${DOCUMENTATION_LEVEL == "Minimal" ?
|
||||
`- Match the level and style of comments found in existing code
|
||||
- Document according to patterns observed in the codebase
|
||||
- Follow existing patterns for documenting non-obvious behavior
|
||||
- Use the same format for parameter descriptions as existing code` : ""}
|
||||
|
||||
${DOCUMENTATION_LEVEL == "Standard" ?
|
||||
`- Follow the exact documentation format found in the codebase
|
||||
- Match the XML/JSDoc style and completeness of existing comments
|
||||
- Document parameters, returns, and exceptions in the same style
|
||||
- Follow existing patterns for usage examples
|
||||
- Match class-level documentation style and content` : ""}
|
||||
|
||||
${DOCUMENTATION_LEVEL == "Comprehensive" ?
|
||||
`- Follow the most detailed documentation patterns found in the codebase
|
||||
- Match the style and completeness of the best-documented code
|
||||
- Document exactly as the most thoroughly documented files do
|
||||
- Follow existing patterns for linking documentation
|
||||
- Match the level of detail in explanations of design decisions` : ""}
|
||||
|
||||
## Testing Approach
|
||||
|
||||
${TESTING_REQUIREMENTS.includes("Unit") || TESTING_REQUIREMENTS == "All" ?
|
||||
`### Unit Testing
|
||||
- Match the exact structure and style of existing unit tests
|
||||
- Follow the same naming conventions for test classes and methods
|
||||
- Use the same assertion patterns found in existing tests
|
||||
- Apply the same mocking approach used in the codebase
|
||||
- Follow existing patterns for test isolation` : ""}
|
||||
|
||||
${TESTING_REQUIREMENTS.includes("Integration") || TESTING_REQUIREMENTS == "All" ?
|
||||
`### Integration Testing
|
||||
- Follow the same integration test patterns found in the codebase
|
||||
- Match existing patterns for test data setup and teardown
|
||||
- Use the same approach for testing component interactions
|
||||
- Follow existing patterns for verifying system behavior` : ""}
|
||||
|
||||
${TESTING_REQUIREMENTS.includes("E2E") || TESTING_REQUIREMENTS == "All" ?
|
||||
`### End-to-End Testing
|
||||
- Match the existing E2E test structure and patterns
|
||||
- Follow established patterns for UI testing
|
||||
- Apply the same approach for verifying user journeys` : ""}
|
||||
|
||||
${TESTING_REQUIREMENTS.includes("TDD") || TESTING_REQUIREMENTS == "All" ?
|
||||
`### Test-Driven Development
|
||||
- Follow TDD patterns evident in the codebase
|
||||
- Match the progression of test cases seen in existing code
|
||||
- Apply the same refactoring patterns after tests pass` : ""}
|
||||
|
||||
${TESTING_REQUIREMENTS.includes("BDD") || TESTING_REQUIREMENTS == "All" ?
|
||||
`### Behavior-Driven Development
|
||||
- Match the existing Given-When-Then structure in tests
|
||||
- Follow the same patterns for behavior descriptions
|
||||
- Apply the same level of business focus in test cases` : ""}
|
||||
|
||||
## Technology-Specific Guidelines
|
||||
|
||||
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### .NET Guidelines
|
||||
- Detect and strictly adhere to the specific .NET version in use
|
||||
- Use only C# language features compatible with the detected version
|
||||
- Follow LINQ usage patterns exactly as they appear in the codebase
|
||||
- Match async/await usage patterns from existing code
|
||||
- Apply the same dependency injection approach used in the codebase
|
||||
- Use the same collection types and patterns found in existing code` : ""}
|
||||
|
||||
${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Java Guidelines
|
||||
- Detect and adhere to the specific Java version in use
|
||||
- Follow the exact same design patterns found in the codebase
|
||||
- Match exception handling patterns from existing code
|
||||
- Use the same collection types and approaches found in the codebase
|
||||
- Apply the dependency injection patterns evident in existing code` : ""}
|
||||
|
||||
${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "TypeScript" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### JavaScript/TypeScript Guidelines
|
||||
- Detect and adhere to the specific ECMAScript/TypeScript version in use
|
||||
- Follow the same module import/export patterns found in the codebase
|
||||
- Match TypeScript type definitions with existing patterns
|
||||
- Use the same async patterns (promises, async/await) as existing code
|
||||
- Follow error handling patterns from similar files` : ""}
|
||||
|
||||
${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### React Guidelines
|
||||
- Detect and adhere to the specific React version in use
|
||||
- Match component structure patterns from existing components
|
||||
- Follow the same hooks and lifecycle patterns found in the codebase
|
||||
- Apply the same state management approach used in existing components
|
||||
- Match prop typing and validation patterns from existing code` : ""}
|
||||
|
||||
${PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Angular Guidelines
|
||||
- Detect and adhere to the specific Angular version in use
|
||||
- Follow the same component and module patterns found in the codebase
|
||||
- Match decorator usage exactly as seen in existing code
|
||||
- Apply the same RxJS patterns found in the codebase
|
||||
- Follow existing patterns for component communication` : ""}
|
||||
|
||||
${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" || PROJECT_TYPE == "Multiple" ? `### Python Guidelines
|
||||
- Detect and adhere to the specific Python version in use
|
||||
- Follow the same import organization found in existing modules
|
||||
- Match type hinting approaches if used in the codebase
|
||||
- Apply the same error handling patterns found in existing code
|
||||
- Follow the same module organization patterns` : ""}
|
||||
|
||||
## Version Control Guidelines
|
||||
|
||||
${VERSIONING == "Semantic" ?
|
||||
`- Follow Semantic Versioning patterns as applied in the codebase
|
||||
- Match existing patterns for documenting breaking changes
|
||||
- Follow the same approach for deprecation notices` : ""}
|
||||
|
||||
${VERSIONING == "CalVer" ?
|
||||
`- Follow Calendar Versioning patterns as applied in the codebase
|
||||
- Match existing patterns for documenting changes
|
||||
- Follow the same approach for highlighting significant changes` : ""}
|
||||
|
||||
${VERSIONING == "Custom" ?
|
||||
`- Match the exact versioning pattern observed in the codebase
|
||||
- Follow the same changelog format used in existing documentation
|
||||
- Apply the same tagging conventions used in the project` : ""}
|
||||
|
||||
## General Best Practices
|
||||
|
||||
- Follow naming conventions exactly as they appear in existing code
|
||||
- Match code organization patterns from similar files
|
||||
- Apply error handling consistent with existing patterns
|
||||
- Follow the same approach to testing as seen in the codebase
|
||||
- Match logging patterns from existing code
|
||||
- Use the same approach to configuration as seen in the codebase
|
||||
|
||||
## Project-Specific Guidance
|
||||
|
||||
- Scan the codebase thoroughly before generating any code
|
||||
- Respect existing architectural boundaries without exception
|
||||
- Match the style and patterns of surrounding code
|
||||
- When in doubt, prioritize consistency with existing code over external best practices
|
||||
```
|
||||
|
||||
### 2. Codebase Analysis Instructions
|
||||
|
||||
To create the copilot-instructions.md file, first analyze the codebase to:
|
||||
|
||||
1. **Identify Exact Technology Versions**:
|
||||
- ${PROJECT_TYPE == "Auto-detect" ? "Detect all programming languages, frameworks, and libraries by scanning file extensions and configuration files" : `Focus on ${PROJECT_TYPE} technologies`}
|
||||
- Extract precise version information from project files, package.json, .csproj, etc.
|
||||
- Document version constraints and compatibility requirements
|
||||
|
||||
2. **Understand Architecture**:
|
||||
- Analyze folder structure and module organization
|
||||
- Identify clear layer boundaries and component relationships
|
||||
- Document communication patterns between components
|
||||
|
||||
3. **Document Code Patterns**:
|
||||
- Catalog naming conventions for different code elements
|
||||
- Note documentation styles and completeness
|
||||
- Document error handling patterns
|
||||
- Map testing approaches and coverage
|
||||
|
||||
4. **Note Quality Standards**:
|
||||
- Identify performance optimization techniques actually used
|
||||
- Document security practices implemented in the code
|
||||
- Note accessibility features present (if applicable)
|
||||
- Document code quality patterns evident in the codebase
|
||||
|
||||
### 3. Implementation Notes
|
||||
|
||||
The final copilot-instructions.md should:
|
||||
- Be placed in the .github/copilot directory
|
||||
- Reference only patterns and standards that exist in the codebase
|
||||
- Include explicit version compatibility requirements
|
||||
- Avoid prescribing any practices not evident in the code
|
||||
- Provide concrete examples from the codebase
|
||||
- Be comprehensive yet concise enough for Copilot to effectively use
|
||||
|
||||
Important: Only include guidance based on patterns actually observed in the codebase. Explicitly instruct Copilot to prioritize consistency with existing code over external best practices or newer language features.
|
||||
"
|
||||
|
||||
## Expected Output
|
||||
|
||||
A comprehensive copilot-instructions.md file that will guide GitHub Copilot to produce code that is perfectly compatible with your existing technology versions and follows your established patterns and architecture.
|
||||
276
prompts/create-github-action-workflow-specification.prompt.md
Normal file
276
prompts/create-github-action-workflow-specification.prompt.md
Normal file
@ -0,0 +1,276 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create a formal specification for an existing GitHub Actions CI/CD workflow, optimized for AI consumption and workflow maintenance.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runInTerminal2', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'microsoft.docs.mcp', 'github', 'Microsoft Docs']
|
||||
---
|
||||
# Create GitHub Actions Workflow Specification
|
||||
|
||||
Create a comprehensive specification for the GitHub Actions workflow: `${input:WorkflowFile}`.
|
||||
|
||||
This specification serves as a specification for the workflow's behavior, requirements, and constraints. It must be implementation-agnostic, focusing on **what** the workflow accomplishes rather than **how** it's implemented.
|
||||
|
||||
## AI-Optimized Requirements
|
||||
|
||||
- **Token Efficiency**: Use concise language without sacrificing clarity
|
||||
- **Structured Data**: Leverage tables, lists, and diagrams for dense information
|
||||
- **Semantic Clarity**: Use precise terminology consistently throughout
|
||||
- **Implementation Abstraction**: Avoid specific syntax, commands, or tool versions
|
||||
- **Maintainability**: Design for easy updates as workflow evolves
|
||||
|
||||
## Specification Template
|
||||
|
||||
Save as: `/spec/spec-process-cicd-[workflow-name].md`
|
||||
|
||||
```md
|
||||
---
|
||||
title: CI/CD Workflow Specification - [Workflow Name]
|
||||
version: 1.0
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [YYYY-MM-DD]
|
||||
owner: DevOps Team
|
||||
tags: [process, cicd, github-actions, automation, [domain-specific-tags]]
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
**Purpose**: [One sentence describing workflow's primary goal]
|
||||
**Trigger Events**: [List trigger conditions]
|
||||
**Target Environments**: [Environment scope]
|
||||
|
||||
## Execution Flow Diagram
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Trigger Event] --> B[Job 1]
|
||||
B --> C[Job 2]
|
||||
C --> D[Job 3]
|
||||
D --> E[End]
|
||||
|
||||
B --> F[Parallel Job]
|
||||
F --> D
|
||||
|
||||
style A fill:#e1f5fe
|
||||
style E fill:#e8f5e8
|
||||
```
|
||||
|
||||
## Jobs & Dependencies
|
||||
|
||||
| Job Name | Purpose | Dependencies | Execution Context |
|
||||
|----------|---------|--------------|-------------------|
|
||||
| job-1 | [Purpose] | [Prerequisites] | [Runner/Environment] |
|
||||
| job-2 | [Purpose] | job-1 | [Runner/Environment] |
|
||||
|
||||
## Requirements Matrix
|
||||
|
||||
### Functional Requirements
|
||||
| ID | Requirement | Priority | Acceptance Criteria |
|
||||
|----|-------------|----------|-------------------|
|
||||
| REQ-001 | [Requirement] | High | [Testable criteria] |
|
||||
| REQ-002 | [Requirement] | Medium | [Testable criteria] |
|
||||
|
||||
### Security Requirements
|
||||
| ID | Requirement | Implementation Constraint |
|
||||
|----|-------------|---------------------------|
|
||||
| SEC-001 | [Security requirement] | [Constraint description] |
|
||||
|
||||
### Performance Requirements
|
||||
| ID | Metric | Target | Measurement Method |
|
||||
|----|-------|--------|-------------------|
|
||||
| PERF-001 | [Metric] | [Target value] | [How measured] |
|
||||
|
||||
## Input/Output Contracts
|
||||
|
||||
### Inputs
|
||||
|
||||
```yaml
|
||||
# Environment Variables
|
||||
ENV_VAR_1: string # Purpose: [description]
|
||||
ENV_VAR_2: secret # Purpose: [description]
|
||||
|
||||
# Repository Triggers
|
||||
paths: [list of path filters]
|
||||
branches: [list of branch patterns]
|
||||
```
|
||||
|
||||
### Outputs
|
||||
|
||||
```yaml
|
||||
# Job Outputs
|
||||
job_1_output: string # Description: [purpose]
|
||||
build_artifact: file # Description: [content type]
|
||||
```
|
||||
|
||||
### Secrets & Variables
|
||||
|
||||
| Type | Name | Purpose | Scope |
|
||||
|------|------|---------|-------|
|
||||
| Secret | SECRET_1 | [Purpose] | Workflow |
|
||||
| Variable | VAR_1 | [Purpose] | Repository |
|
||||
|
||||
## Execution Constraints
|
||||
|
||||
### Runtime Constraints
|
||||
|
||||
- **Timeout**: [Maximum execution time]
|
||||
- **Concurrency**: [Parallel execution limits]
|
||||
- **Resource Limits**: [Memory/CPU constraints]
|
||||
|
||||
### Environmental Constraints
|
||||
|
||||
- **Runner Requirements**: [OS/hardware needs]
|
||||
- **Network Access**: [External connectivity needs]
|
||||
- **Permissions**: [Required access levels]
|
||||
|
||||
## Error Handling Strategy
|
||||
|
||||
| Error Type | Response | Recovery Action |
|
||||
|------------|----------|-----------------|
|
||||
| Build Failure | [Response] | [Recovery steps] |
|
||||
| Test Failure | [Response] | [Recovery steps] |
|
||||
| Deployment Failure | [Response] | [Recovery steps] |
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Gate Definitions
|
||||
|
||||
| Gate | Criteria | Bypass Conditions |
|
||||
|------|----------|-------------------|
|
||||
| Code Quality | [Standards] | [When allowed] |
|
||||
| Security Scan | [Thresholds] | [When allowed] |
|
||||
| Test Coverage | [Percentage] | [When allowed] |
|
||||
|
||||
## Monitoring & Observability
|
||||
|
||||
### Key Metrics
|
||||
|
||||
- **Success Rate**: [Target percentage]
|
||||
- **Execution Time**: [Target duration]
|
||||
- **Resource Usage**: [Monitoring approach]
|
||||
|
||||
### Alerting
|
||||
|
||||
| Condition | Severity | Notification Target |
|
||||
|-----------|----------|-------------------|
|
||||
| [Condition] | [Level] | [Who/Where] |
|
||||
|
||||
## Integration Points
|
||||
|
||||
### External Systems
|
||||
|
||||
| System | Integration Type | Data Exchange | SLA Requirements |
|
||||
|--------|------------------|---------------|------------------|
|
||||
| [System] | [Type] | [Data format] | [Requirements] |
|
||||
|
||||
### Dependent Workflows
|
||||
|
||||
| Workflow | Relationship | Trigger Mechanism |
|
||||
|----------|--------------|-------------------|
|
||||
| [Workflow] | [Type] | [How triggered] |
|
||||
|
||||
## Compliance & Governance
|
||||
|
||||
### Audit Requirements
|
||||
|
||||
- **Execution Logs**: [Retention policy]
|
||||
- **Approval Gates**: [Required approvals]
|
||||
- **Change Control**: [Update process]
|
||||
|
||||
### Security Controls
|
||||
|
||||
- **Access Control**: [Permission model]
|
||||
- **Secret Management**: [Rotation policy]
|
||||
- **Vulnerability Scanning**: [Scan frequency]
|
||||
|
||||
## Edge Cases & Exceptions
|
||||
|
||||
### Scenario Matrix
|
||||
|
||||
| Scenario | Expected Behavior | Validation Method |
|
||||
|----------|-------------------|-------------------|
|
||||
| [Edge case] | [Behavior] | [How to verify] |
|
||||
|
||||
## Validation Criteria
|
||||
|
||||
### Workflow Validation
|
||||
|
||||
- **VLD-001**: [Validation rule]
|
||||
- **VLD-002**: [Validation rule]
|
||||
|
||||
### Performance Benchmarks
|
||||
|
||||
- **PERF-001**: [Benchmark criteria]
|
||||
- **PERF-002**: [Benchmark criteria]
|
||||
|
||||
## Change Management
|
||||
|
||||
### Update Process
|
||||
|
||||
1. **Specification Update**: Modify this document first
|
||||
2. **Review & Approval**: [Approval process]
|
||||
3. **Implementation**: Apply changes to workflow
|
||||
4. **Testing**: [Validation approach]
|
||||
5. **Deployment**: [Release process]
|
||||
|
||||
### Version History
|
||||
|
||||
| Version | Date | Changes | Author |
|
||||
|---------|------|---------|--------|
|
||||
| 1.0 | [Date] | Initial specification | [Author] |
|
||||
|
||||
## Related Specifications
|
||||
|
||||
- [Link to related workflow specs]
|
||||
- [Link to infrastructure specs]
|
||||
- [Link to deployment specs]
|
||||
|
||||
```
|
||||
|
||||
## Analysis Instructions
|
||||
|
||||
When analyzing the workflow file:
|
||||
|
||||
1. **Extract Core Purpose**: Identify the primary business objective
|
||||
2. **Map Job Flow**: Create dependency graph showing execution order
|
||||
3. **Identify Contracts**: Document inputs, outputs, and interfaces
|
||||
4. **Capture Constraints**: Extract timeouts, permissions, and limits
|
||||
5. **Define Quality Gates**: Identify validation and approval points
|
||||
6. **Document Error Paths**: Map failure scenarios and recovery
|
||||
7. **Abstract Implementation**: Focus on behavior, not syntax
|
||||
|
||||
## Mermaid Diagram Guidelines
|
||||
|
||||
### Flow Types
|
||||
- **Sequential**: `A --> B --> C`
|
||||
- **Parallel**: `A --> B & A --> C; B --> D & C --> D`
|
||||
- **Conditional**: `A --> B{Decision}; B -->|Yes| C; B -->|No| D`
|
||||
|
||||
### Styling
|
||||
```mermaid
|
||||
style TriggerNode fill:#e1f5fe
|
||||
style SuccessNode fill:#e8f5e8
|
||||
style FailureNode fill:#ffebee
|
||||
style ProcessNode fill:#f3e5f5
|
||||
```
|
||||
|
||||
### Complex Workflows
|
||||
For workflows with 5+ jobs, use subgraphs:
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Build Phase"
|
||||
A[Lint] --> B[Test] --> C[Build]
|
||||
end
|
||||
subgraph "Deploy Phase"
|
||||
D[Staging] --> E[Production]
|
||||
end
|
||||
C --> D
|
||||
```
|
||||
|
||||
## Token Optimization Strategies
|
||||
|
||||
1. **Use Tables**: Dense information in structured format
|
||||
2. **Abbreviate Consistently**: Define once, use throughout
|
||||
3. **Bullet Points**: Avoid prose paragraphs
|
||||
4. **Code Blocks**: Structured data over narrative
|
||||
5. **Cross-Reference**: Link instead of repeat information
|
||||
|
||||
Focus on creating a specification that serves as both documentation and a template for workflow updates.
|
||||
@ -6,9 +6,11 @@ tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo',
|
||||
# Create Implementation Plan
|
||||
|
||||
## Primary Directive
|
||||
|
||||
Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
|
||||
|
||||
## Execution Context
|
||||
|
||||
This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
|
||||
|
||||
## Core Requirements
|
||||
@ -19,6 +21,7 @@ This prompt is designed for AI-to-AI communication and automated processing. All
|
||||
- Ensure complete self-containment with no external dependencies for understanding
|
||||
|
||||
## Plan Structure Requirements
|
||||
|
||||
Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
|
||||
|
||||
## Phase Architecture
|
||||
@ -47,6 +50,7 @@ Plans must consist of discrete, atomic phases containing executable tasks. Each
|
||||
- File must be valid Markdown with proper front matter structure
|
||||
|
||||
## Mandatory Template Structure
|
||||
|
||||
All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
|
||||
|
||||
## Template Validation Rules
|
||||
@ -57,6 +61,10 @@ All implementation plans must strictly adhere to the following template. Each se
|
||||
- Tables must include all required columns
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
## Status
|
||||
|
||||
The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Implementation Plan's Goal]
|
||||
@ -64,11 +72,14 @@ version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
404
prompts/folder-structure-blueprint-generator.prompt.md
Normal file
404
prompts/folder-structure-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,404 @@
|
||||
---
|
||||
description: 'Comprehensive technology-agnostic prompt for analyzing and documenting project folder structures. Auto-detects project types (.NET, Java, React, Angular, Python, Node.js, Flutter), generates detailed blueprints with visualization options, naming conventions, file placement patterns, and extension templates for maintaining consistent code organization across diverse technology stacks.'
|
||||
---
|
||||
|
||||
# Project Folder Structure Blueprint Generator
|
||||
|
||||
## Configuration Variables
|
||||
|
||||
${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"}
|
||||
<!-- Select primary technology -->
|
||||
|
||||
${INCLUDES_MICROSERVICES="Auto-detect|true|false"}
|
||||
<!-- Is this a microservices architecture? -->
|
||||
|
||||
${INCLUDES_FRONTEND="Auto-detect|true|false"}
|
||||
<!-- Does project include frontend components? -->
|
||||
|
||||
${IS_MONOREPO="Auto-detect|true|false"}
|
||||
<!-- Is this a monorepo with multiple projects? -->
|
||||
|
||||
${VISUALIZATION_STYLE="ASCII|Markdown List|Table"}
|
||||
<!-- How to visualize the structure -->
|
||||
|
||||
${DEPTH_LEVEL=1-5}
|
||||
<!-- How many levels of folders to document in detail -->
|
||||
|
||||
${INCLUDE_FILE_COUNTS=true|false}
|
||||
<!-- Include file count statistics -->
|
||||
|
||||
${INCLUDE_GENERATED_FOLDERS=true|false}
|
||||
<!-- Include auto-generated folders -->
|
||||
|
||||
${INCLUDE_FILE_PATTERNS=true|false}
|
||||
<!-- Document file naming/location patterns -->
|
||||
|
||||
${INCLUDE_TEMPLATES=true|false}
|
||||
<!-- Include file/folder templates for new features -->
|
||||
|
||||
## Generated Prompt
|
||||
|
||||
"Analyze the project's folder structure and create a comprehensive 'Project_Folders_Structure_Blueprint.md' document that serves as a definitive guide for maintaining consistent code organization. Use the following approach:
|
||||
|
||||
### Initial Auto-detection Phase
|
||||
|
||||
${PROJECT_TYPE == "Auto-detect" ?
|
||||
"Begin by scanning the folder structure for key files that identify the project type:
|
||||
- Look for solution/project files (.sln, .csproj, .fsproj, .vbproj) to identify .NET projects
|
||||
- Check for build files (pom.xml, build.gradle, settings.gradle) for Java projects
|
||||
- Identify package.json with dependencies for JavaScript/TypeScript projects
|
||||
- Look for specific framework files (angular.json, react-scripts entries, next.config.js)
|
||||
- Check for Python project identifiers (requirements.txt, setup.py, pyproject.toml)
|
||||
- Examine mobile app identifiers (pubspec.yaml, android/ios folders)
|
||||
- Note all technology signatures found and their versions" :
|
||||
"Focus analysis on ${PROJECT_TYPE} project structure"}
|
||||
|
||||
${IS_MONOREPO == "Auto-detect" ?
|
||||
"Determine if this is a monorepo by looking for:
|
||||
- Multiple distinct projects with their own configuration files
|
||||
- Workspace configuration files (lerna.json, nx.json, turborepo.json, etc.)
|
||||
- Cross-project references and shared dependency patterns
|
||||
- Root-level orchestration scripts and configuration" : ""}
|
||||
|
||||
${INCLUDES_MICROSERVICES == "Auto-detect" ?
|
||||
"Check for microservices architecture indicators:
|
||||
- Multiple service directories with similar/repeated structures
|
||||
- Service-specific Dockerfiles or deployment configurations
|
||||
- Inter-service communication patterns (APIs, message brokers)
|
||||
- Service registry or discovery configuration
|
||||
- API gateway configuration files
|
||||
- Shared libraries or utilities across services" : ""}
|
||||
|
||||
${INCLUDES_FRONTEND == "Auto-detect" ?
|
||||
"Identify frontend components by looking for:
|
||||
- Web asset directories (wwwroot, public, dist, static)
|
||||
- UI framework files (components, modules, pages)
|
||||
- Frontend build configuration (webpack, vite, rollup, etc.)
|
||||
- Style sheet organization (CSS, SCSS, styled-components)
|
||||
- Static asset organization (images, fonts, icons)" : ""}
|
||||
|
||||
### 1. Structural Overview
|
||||
|
||||
Provide a high-level overview of the ${PROJECT_TYPE == "Auto-detect" ? "detected project type(s)" : PROJECT_TYPE} project's organization principles and folder structure:
|
||||
|
||||
- Document the overall architectural approach reflected in the folder structure
|
||||
- Identify the main organizational principles (by feature, by layer, by domain, etc.)
|
||||
- Note any structural patterns that repeat throughout the codebase
|
||||
- Document the rationale behind the structure where it can be inferred
|
||||
|
||||
${IS_MONOREPO == "Auto-detect" ?
|
||||
"If detected as a monorepo, explain how the monorepo is organized and the relationship between projects." :
|
||||
IS_MONOREPO ? "Explain how the monorepo is organized and the relationship between projects." : ""}
|
||||
|
||||
${INCLUDES_MICROSERVICES == "Auto-detect" ?
|
||||
"If microservices are detected, describe how they are structured and organized." :
|
||||
INCLUDES_MICROSERVICES ? "Describe how the microservices are structured and organized." : ""}
|
||||
|
||||
### 2. Directory Visualization
|
||||
|
||||
${VISUALIZATION_STYLE == "ASCII" ?
|
||||
"Create an ASCII tree representation of the folder hierarchy to depth level ${DEPTH_LEVEL}." : ""}
|
||||
|
||||
${VISUALIZATION_STYLE == "Markdown List" ?
|
||||
"Use nested markdown lists to represent the folder hierarchy to depth level ${DEPTH_LEVEL}." : ""}
|
||||
|
||||
${VISUALIZATION_STYLE == "Table" ?
|
||||
"Create a table with columns for Path, Purpose, Content Types, and Conventions." : ""}
|
||||
|
||||
${INCLUDE_GENERATED_FOLDERS ?
|
||||
"Include all folders including generated ones." :
|
||||
"Exclude auto-generated folders like bin/, obj/, node_modules/, etc."}
|
||||
|
||||
### 3. Key Directory Analysis
|
||||
|
||||
Document each significant directory's purpose, contents, and patterns:
|
||||
|
||||
${PROJECT_TYPE == "Auto-detect" ?
|
||||
"For each detected technology, analyze directory structures based on observed usage patterns:" : ""}
|
||||
|
||||
${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### .NET Project Structure (if detected)
|
||||
|
||||
- **Solution Organization**:
|
||||
- How projects are grouped and related
|
||||
- Solution folder organization patterns
|
||||
- Multi-targeting project patterns
|
||||
|
||||
- **Project Organization**:
|
||||
- Internal folder structure patterns
|
||||
- Source code organization approach
|
||||
- Resource organization
|
||||
- Project dependencies and references
|
||||
|
||||
- **Domain/Feature Organization**:
|
||||
- How business domains or features are separated
|
||||
- Domain boundary enforcement patterns
|
||||
|
||||
- **Layer Organization**:
|
||||
- Separation of concerns (Controllers, Services, Repositories, etc.)
|
||||
- Layer interaction and dependency patterns
|
||||
|
||||
- **Configuration Management**:
|
||||
- Configuration file locations and purposes
|
||||
- Environment-specific configurations
|
||||
- Secret management approach
|
||||
|
||||
- **Test Project Organization**:
|
||||
- Test project structure and naming
|
||||
- Test categories and organization
|
||||
- Test data and mock locations" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### UI Project Structure (if detected)
|
||||
|
||||
- **Component Organization**:
|
||||
- Component folder structure patterns
|
||||
- Grouping strategies (by feature, type, etc.)
|
||||
- Shared vs. feature-specific components
|
||||
|
||||
- **State Management**:
|
||||
- State-related file organization
|
||||
- Store structure for global state
|
||||
- Local state management patterns
|
||||
|
||||
- **Routing Organization**:
|
||||
- Route definition locations
|
||||
- Page/view component organization
|
||||
- Route parameter handling
|
||||
|
||||
- **API Integration**:
|
||||
- API client organization
|
||||
- Service layer structure
|
||||
- Data fetching patterns
|
||||
|
||||
- **Asset Management**:
|
||||
- Static resource organization
|
||||
- Image/media file structure
|
||||
- Font and icon organization
|
||||
|
||||
- **Style Organization**:
|
||||
- CSS/SCSS file structure
|
||||
- Theme organization
|
||||
- Style module patterns" : ""}
|
||||
|
||||
### 4. File Placement Patterns
|
||||
|
||||
${INCLUDE_FILE_PATTERNS ?
|
||||
"Document the patterns that determine where different types of files should be placed:
|
||||
|
||||
- **Configuration Files**:
|
||||
- Locations for different types of configuration
|
||||
- Environment-specific configuration patterns
|
||||
|
||||
- **Model/Entity Definitions**:
|
||||
- Where domain models are defined
|
||||
- Data transfer object (DTO) locations
|
||||
- Schema definition locations
|
||||
|
||||
- **Business Logic**:
|
||||
- Service implementation locations
|
||||
- Business rule organization
|
||||
- Utility and helper function placement
|
||||
|
||||
- **Interface Definitions**:
|
||||
- Where interfaces and abstractions are defined
|
||||
- How interfaces are grouped and organized
|
||||
|
||||
- **Test Files**:
|
||||
- Unit test location patterns
|
||||
- Integration test placement
|
||||
- Test utility and mock locations
|
||||
|
||||
- **Documentation Files**:
|
||||
- API documentation placement
|
||||
- Internal documentation organization
|
||||
- README file distribution" :
|
||||
"Document where key file types are located in the project."}
|
||||
|
||||
### 5. Naming and Organization Conventions
|
||||
Document the naming and organizational conventions observed across the project:
|
||||
|
||||
- **File Naming Patterns**:
|
||||
- Case conventions (PascalCase, camelCase, kebab-case)
|
||||
- Prefix and suffix patterns
|
||||
- Type indicators in filenames
|
||||
|
||||
- **Folder Naming Patterns**:
|
||||
- Naming conventions for different folder types
|
||||
- Hierarchical naming patterns
|
||||
- Grouping and categorization conventions
|
||||
|
||||
- **Namespace/Module Patterns**:
|
||||
- How namespaces/modules map to folder structure
|
||||
- Import/using statement organization
|
||||
- Internal vs. public API separation
|
||||
|
||||
- **Organizational Patterns**:
|
||||
- Code co-location strategies
|
||||
- Feature encapsulation approaches
|
||||
- Cross-cutting concern organization
|
||||
|
||||
### 6. Navigation and Development Workflow
|
||||
Provide guidance for navigating and working with the codebase structure:
|
||||
|
||||
- **Entry Points**:
|
||||
- Main application entry points
|
||||
- Key configuration starting points
|
||||
- Initial files for understanding the project
|
||||
|
||||
- **Common Development Tasks**:
|
||||
- Where to add new features
|
||||
- How to extend existing functionality
|
||||
- Where to place new tests
|
||||
- Configuration modification locations
|
||||
|
||||
- **Dependency Patterns**:
|
||||
- How dependencies flow between folders
|
||||
- Import/reference patterns
|
||||
- Dependency injection registration locations
|
||||
|
||||
${INCLUDE_FILE_COUNTS ?
|
||||
"- **Content Statistics**:
|
||||
- Files per directory analysis
|
||||
- Code distribution metrics
|
||||
- Complexity concentration areas" : ""}
|
||||
|
||||
### 7. Build and Output Organization
|
||||
Document the build process and output organization:
|
||||
|
||||
- **Build Configuration**:
|
||||
- Build script locations and purposes
|
||||
- Build pipeline organization
|
||||
- Build task definitions
|
||||
|
||||
- **Output Structure**:
|
||||
- Compiled/built output locations
|
||||
- Output organization patterns
|
||||
- Distribution package structure
|
||||
|
||||
- **Environment-Specific Builds**:
|
||||
- Development vs. production differences
|
||||
- Environment configuration strategies
|
||||
- Build variant organization
|
||||
|
||||
### 8. Technology-Specific Organization
|
||||
|
||||
${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### .NET-Specific Structure Patterns (if detected)
|
||||
|
||||
- **Project File Organization**:
|
||||
- Project file structure and patterns
|
||||
- Target framework configuration
|
||||
- Property group organization
|
||||
- Item group patterns
|
||||
|
||||
- **Assembly Organization**:
|
||||
- Assembly naming patterns
|
||||
- Multi-assembly architecture
|
||||
- Assembly reference patterns
|
||||
|
||||
- **Resource Organization**:
|
||||
- Embedded resource patterns
|
||||
- Localization file structure
|
||||
- Static web asset organization
|
||||
|
||||
- **Package Management**:
|
||||
- NuGet configuration locations
|
||||
- Package reference organization
|
||||
- Package version management" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### Java-Specific Structure Patterns (if detected)
|
||||
|
||||
- **Package Hierarchy**:
|
||||
- Package naming and nesting conventions
|
||||
- Domain vs. technical packages
|
||||
- Visibility and access patterns
|
||||
|
||||
- **Build Tool Organization**:
|
||||
- Maven/Gradle structure patterns
|
||||
- Module organization
|
||||
- Plugin configuration patterns
|
||||
|
||||
- **Resource Organization**:
|
||||
- Resource folder structures
|
||||
- Environment-specific resources
|
||||
- Properties file organization" : ""}
|
||||
|
||||
${(PROJECT_TYPE == "Node.js" || PROJECT_TYPE == "Auto-detect") ?
|
||||
"#### Node.js-Specific Structure Patterns (if detected)
|
||||
|
||||
- **Module Organization**:
|
||||
- CommonJS vs. ESM organization
|
||||
- Internal module patterns
|
||||
- Third-party dependency management
|
||||
|
||||
- **Script Organization**:
|
||||
- npm/yarn script definition patterns
|
||||
- Utility script locations
|
||||
- Development tool scripts
|
||||
|
||||
- **Configuration Management**:
|
||||
- Configuration file locations
|
||||
- Environment variable management
|
||||
- Secret management approaches" : ""}
|
||||
|
||||
### 9. Extension and Evolution
|
||||
Document how the project structure is designed to be extended:
|
||||
|
||||
- **Extension Points**:
|
||||
- How to add new modules/features while maintaining conventions
|
||||
- Plugin/extension folder patterns
|
||||
- Customization directory structures
|
||||
|
||||
- **Scalability Patterns**:
|
||||
- How the structure scales for larger features
|
||||
- Approach for breaking down large modules
|
||||
- Code splitting strategies
|
||||
|
||||
- **Refactoring Patterns**:
|
||||
- Common refactoring approaches observed
|
||||
- How structural changes are managed
|
||||
- Incremental reorganization patterns
|
||||
|
||||
${INCLUDE_TEMPLATES ?
|
||||
"### 10. Structure Templates
|
||||
|
||||
Provide templates for creating new components that follow project conventions:
|
||||
|
||||
- **New Feature Template**:
|
||||
- Folder structure for adding a complete feature
|
||||
- Required file types and their locations
|
||||
- Naming patterns to follow
|
||||
|
||||
- **New Component Template**:
|
||||
- Directory structure for a typical component
|
||||
- Essential files to include
|
||||
- Integration points with existing structure
|
||||
|
||||
- **New Service Template**:
|
||||
- Structure for adding a new service
|
||||
- Interface and implementation placement
|
||||
- Configuration and registration patterns
|
||||
|
||||
- **New Test Structure**:
|
||||
- Folder structure for test projects/files
|
||||
- Test file organization templates
|
||||
- Test resource organization" : ""}
|
||||
|
||||
### ${INCLUDE_TEMPLATES ? "11" : "10"}. Structure Enforcement
|
||||
|
||||
Document how the project structure is maintained and enforced:
|
||||
|
||||
- **Structure Validation**:
|
||||
- Tools/scripts that enforce structure
|
||||
- Build checks for structural compliance
|
||||
- Linting rules related to structure
|
||||
|
||||
- **Documentation Practices**:
|
||||
- How structural changes are documented
|
||||
- Where architectural decisions are recorded
|
||||
- Structure evolution history
|
||||
|
||||
Include a section at the end about maintaining this blueprint and when it was last updated.
|
||||
"
|
||||
214
prompts/postgresql-code-review.prompt.md
Normal file
214
prompts/postgresql-code-review.prompt.md
Normal file
@ -0,0 +1,214 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'PostgreSQL-specific code review assistant focusing on PostgreSQL best practices, anti-patterns, and unique quality standards. Covers JSONB operations, array usage, custom types, schema design, function optimization, and PostgreSQL-exclusive security features like Row Level Security (RLS).'
|
||||
tested_with: 'GitHub Copilot Chat (GPT-4o) - Validated July 20, 2025'
|
||||
---
|
||||
|
||||
# PostgreSQL Code Review Assistant
|
||||
|
||||
Expert PostgreSQL code review for ${selection} (or entire project if no selection). Focus on PostgreSQL-specific best practices, anti-patterns, and quality standards that are unique to PostgreSQL.
|
||||
|
||||
## 🎯 PostgreSQL-Specific Review Areas
|
||||
|
||||
### JSONB Best Practices
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient JSONB usage
|
||||
SELECT * FROM orders WHERE data->>'status' = 'shipped'; -- No index support
|
||||
|
||||
-- ✅ GOOD: Indexable JSONB queries
|
||||
CREATE INDEX idx_orders_status ON orders USING gin((data->'status'));
|
||||
SELECT * FROM orders WHERE data @> '{"status": "shipped"}';
|
||||
|
||||
-- ❌ BAD: Deep nesting without consideration
|
||||
UPDATE orders SET data = data || '{"shipping":{"tracking":{"number":"123"}}}';
|
||||
|
||||
-- ✅ GOOD: Structured JSONB with validation
|
||||
ALTER TABLE orders ADD CONSTRAINT valid_status
|
||||
CHECK (data->>'status' IN ('pending', 'shipped', 'delivered'));
|
||||
```
|
||||
|
||||
### Array Operations Review
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient array operations
|
||||
SELECT * FROM products WHERE 'electronics' = ANY(categories); -- No index
|
||||
|
||||
-- ✅ GOOD: GIN indexed array queries
|
||||
CREATE INDEX idx_products_categories ON products USING gin(categories);
|
||||
SELECT * FROM products WHERE categories @> ARRAY['electronics'];
|
||||
|
||||
-- ❌ BAD: Array concatenation in loops
|
||||
-- This would be inefficient in a function/procedure
|
||||
|
||||
-- ✅ GOOD: Bulk array operations
|
||||
UPDATE products SET categories = categories || ARRAY['new_category']
|
||||
WHERE id IN (SELECT id FROM products WHERE condition);
|
||||
```
|
||||
|
||||
### PostgreSQL Schema Design Review
|
||||
```sql
|
||||
-- ❌ BAD: Not using PostgreSQL features
|
||||
CREATE TABLE users (
|
||||
id INTEGER,
|
||||
email VARCHAR(255),
|
||||
created_at TIMESTAMP
|
||||
);
|
||||
|
||||
-- ✅ GOOD: PostgreSQL-optimized schema
|
||||
CREATE TABLE users (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
email CITEXT UNIQUE NOT NULL, -- Case-insensitive email
|
||||
created_at TIMESTAMPTZ DEFAULT NOW(),
|
||||
metadata JSONB DEFAULT '{}',
|
||||
CONSTRAINT valid_email CHECK (email ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')
|
||||
);
|
||||
|
||||
-- Add JSONB GIN index for metadata queries
|
||||
CREATE INDEX idx_users_metadata ON users USING gin(metadata);
|
||||
```
|
||||
|
||||
### Custom Types and Domains
|
||||
```sql
|
||||
-- ❌ BAD: Using generic types for specific data
|
||||
CREATE TABLE transactions (
|
||||
amount DECIMAL(10,2),
|
||||
currency VARCHAR(3),
|
||||
status VARCHAR(20)
|
||||
);
|
||||
|
||||
-- ✅ GOOD: PostgreSQL custom types
|
||||
CREATE TYPE currency_code AS ENUM ('USD', 'EUR', 'GBP', 'JPY');
|
||||
CREATE TYPE transaction_status AS ENUM ('pending', 'completed', 'failed', 'cancelled');
|
||||
CREATE DOMAIN positive_amount AS DECIMAL(10,2) CHECK (VALUE > 0);
|
||||
|
||||
CREATE TABLE transactions (
|
||||
amount positive_amount NOT NULL,
|
||||
currency currency_code NOT NULL,
|
||||
status transaction_status DEFAULT 'pending'
|
||||
);
|
||||
```
|
||||
|
||||
## 🔍 PostgreSQL-Specific Anti-Patterns
|
||||
|
||||
### Performance Anti-Patterns
|
||||
- **Avoiding PostgreSQL-specific indexes**: Not using GIN/GiST for appropriate data types
|
||||
- **Misusing JSONB**: Treating JSONB like a simple string field
|
||||
- **Ignoring array operators**: Using inefficient array operations
|
||||
- **Poor partition key selection**: Not leveraging PostgreSQL partitioning effectively
|
||||
|
||||
### Schema Design Issues
|
||||
- **Not using ENUM types**: Using VARCHAR for limited value sets
|
||||
- **Ignoring constraints**: Missing CHECK constraints for data validation
|
||||
- **Wrong data types**: Using VARCHAR instead of TEXT or CITEXT
|
||||
- **Missing JSONB structure**: Unstructured JSONB without validation
|
||||
|
||||
### Function and Trigger Issues
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient trigger function
|
||||
CREATE OR REPLACE FUNCTION update_modified_time()
|
||||
RETURNS TRIGGER AS $$
|
||||
BEGIN
|
||||
NEW.updated_at = NOW(); -- Should use TIMESTAMPTZ
|
||||
RETURN NEW;
|
||||
END;
|
||||
$$ LANGUAGE plpgsql;
|
||||
|
||||
-- ✅ GOOD: Optimized trigger function
|
||||
CREATE OR REPLACE FUNCTION update_modified_time()
|
||||
RETURNS TRIGGER AS $$
|
||||
BEGIN
|
||||
NEW.updated_at = CURRENT_TIMESTAMP;
|
||||
RETURN NEW;
|
||||
END;
|
||||
$$ LANGUAGE plpgsql;
|
||||
|
||||
-- Set trigger to fire only when needed
|
||||
CREATE TRIGGER update_modified_time_trigger
|
||||
BEFORE UPDATE ON table_name
|
||||
FOR EACH ROW
|
||||
WHEN (OLD.* IS DISTINCT FROM NEW.*)
|
||||
EXECUTE FUNCTION update_modified_time();
|
||||
```
|
||||
|
||||
## 📊 PostgreSQL Extension Usage Review
|
||||
|
||||
### Extension Best Practices
|
||||
```sql
|
||||
-- ✅ Check if extension exists before creating
|
||||
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
|
||||
CREATE EXTENSION IF NOT EXISTS "pgcrypto";
|
||||
CREATE EXTENSION IF NOT EXISTS "pg_trgm";
|
||||
|
||||
-- ✅ Use extensions appropriately
|
||||
-- UUID generation
|
||||
SELECT uuid_generate_v4();
|
||||
|
||||
-- Password hashing
|
||||
SELECT crypt('password', gen_salt('bf'));
|
||||
|
||||
-- Fuzzy text matching
|
||||
SELECT word_similarity('postgres', 'postgre');
|
||||
```
|
||||
|
||||
## 🛡️ PostgreSQL Security Review
|
||||
|
||||
### Row Level Security (RLS)
|
||||
```sql
|
||||
-- ✅ GOOD: Implementing RLS
|
||||
ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;
|
||||
|
||||
CREATE POLICY user_data_policy ON sensitive_data
|
||||
FOR ALL TO application_role
|
||||
USING (user_id = current_setting('app.current_user_id')::INTEGER);
|
||||
```
|
||||
|
||||
### Privilege Management
|
||||
```sql
|
||||
-- ❌ BAD: Overly broad permissions
|
||||
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;
|
||||
|
||||
-- ✅ GOOD: Granular permissions
|
||||
GRANT SELECT, INSERT, UPDATE ON specific_table TO app_user;
|
||||
GRANT USAGE ON SEQUENCE specific_table_id_seq TO app_user;
|
||||
```
|
||||
|
||||
## 🎯 PostgreSQL Code Quality Checklist
|
||||
|
||||
### Schema Design
|
||||
- [ ] Using appropriate PostgreSQL data types (CITEXT, JSONB, arrays)
|
||||
- [ ] Leveraging ENUM types for constrained values
|
||||
- [ ] Implementing proper CHECK constraints
|
||||
- [ ] Using TIMESTAMPTZ instead of TIMESTAMP
|
||||
- [ ] Defining custom domains for reusable constraints
|
||||
|
||||
### Performance Considerations
|
||||
- [ ] Appropriate index types (GIN for JSONB/arrays, GiST for ranges)
|
||||
- [ ] JSONB queries using containment operators (@>, ?)
|
||||
- [ ] Array operations using PostgreSQL-specific operators
|
||||
- [ ] Proper use of window functions and CTEs
|
||||
- [ ] Efficient use of PostgreSQL-specific functions
|
||||
|
||||
### PostgreSQL Features Utilization
|
||||
- [ ] Using extensions where appropriate
|
||||
- [ ] Implementing stored procedures in PL/pgSQL when beneficial
|
||||
- [ ] Leveraging PostgreSQL's advanced SQL features
|
||||
- [ ] Using PostgreSQL-specific optimization techniques
|
||||
- [ ] Implementing proper error handling in functions
|
||||
|
||||
### Security and Compliance
|
||||
- [ ] Row Level Security (RLS) implementation where needed
|
||||
- [ ] Proper role and privilege management
|
||||
- [ ] Using PostgreSQL's built-in encryption functions
|
||||
- [ ] Implementing audit trails with PostgreSQL features
|
||||
|
||||
## 📝 PostgreSQL-Specific Review Guidelines
|
||||
|
||||
1. **Data Type Optimization**: Ensure PostgreSQL-specific types are used appropriately
|
||||
2. **Index Strategy**: Review index types and ensure PostgreSQL-specific indexes are utilized
|
||||
3. **JSONB Structure**: Validate JSONB schema design and query patterns
|
||||
4. **Function Quality**: Review PL/pgSQL functions for efficiency and best practices
|
||||
5. **Extension Usage**: Verify appropriate use of PostgreSQL extensions
|
||||
6. **Performance Features**: Check utilization of PostgreSQL's advanced features
|
||||
7. **Security Implementation**: Review PostgreSQL-specific security features
|
||||
|
||||
Focus on PostgreSQL's unique capabilities and ensure the code leverages what makes PostgreSQL special rather than treating it as a generic SQL database.
|
||||
406
prompts/postgresql-optimization.prompt.md
Normal file
406
prompts/postgresql-optimization.prompt.md
Normal file
@ -0,0 +1,406 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'PostgreSQL-specific development assistant focusing on unique PostgreSQL features, advanced data types, and PostgreSQL-exclusive capabilities. Covers JSONB operations, array types, custom types, range/geometric types, full-text search, window functions, and PostgreSQL extensions ecosystem.'
|
||||
tested_with: 'GitHub Copilot Chat (GPT-4o) - Validated July 20, 2025'
|
||||
---
|
||||
|
||||
# PostgreSQL Development Assistant
|
||||
|
||||
Expert PostgreSQL guidance for ${selection} (or entire project if no selection). Focus on PostgreSQL-specific features, optimization patterns, and advanced capabilities.
|
||||
|
||||
## <20> PostgreSQL-Specific Features
|
||||
|
||||
### JSONB Operations
|
||||
```sql
|
||||
-- Advanced JSONB queries
|
||||
CREATE TABLE events (
|
||||
id SERIAL PRIMARY KEY,
|
||||
data JSONB NOT NULL,
|
||||
created_at TIMESTAMPTZ DEFAULT NOW()
|
||||
);
|
||||
|
||||
-- GIN index for JSONB performance
|
||||
CREATE INDEX idx_events_data_gin ON events USING gin(data);
|
||||
|
||||
-- JSONB containment and path queries
|
||||
SELECT * FROM events
|
||||
WHERE data @> '{"type": "login"}'
|
||||
AND data #>> '{user,role}' = 'admin';
|
||||
|
||||
-- JSONB aggregation
|
||||
SELECT jsonb_agg(data) FROM events WHERE data ? 'user_id';
|
||||
```
|
||||
|
||||
### Array Operations
|
||||
```sql
|
||||
-- PostgreSQL arrays
|
||||
CREATE TABLE posts (
|
||||
id SERIAL PRIMARY KEY,
|
||||
tags TEXT[],
|
||||
categories INTEGER[]
|
||||
);
|
||||
|
||||
-- Array queries and operations
|
||||
SELECT * FROM posts WHERE 'postgresql' = ANY(tags);
|
||||
SELECT * FROM posts WHERE tags && ARRAY['database', 'sql'];
|
||||
SELECT * FROM posts WHERE array_length(tags, 1) > 3;
|
||||
|
||||
-- Array aggregation
|
||||
SELECT array_agg(DISTINCT category) FROM posts, unnest(categories) as category;
|
||||
```
|
||||
|
||||
### Window Functions & Analytics
|
||||
```sql
|
||||
-- Advanced window functions
|
||||
SELECT
|
||||
product_id,
|
||||
sale_date,
|
||||
amount,
|
||||
-- Running totals
|
||||
SUM(amount) OVER (PARTITION BY product_id ORDER BY sale_date) as running_total,
|
||||
-- Moving averages
|
||||
AVG(amount) OVER (PARTITION BY product_id ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) as moving_avg,
|
||||
-- Rankings
|
||||
DENSE_RANK() OVER (PARTITION BY EXTRACT(month FROM sale_date) ORDER BY amount DESC) as monthly_rank,
|
||||
-- Lag/Lead for comparisons
|
||||
LAG(amount, 1) OVER (PARTITION BY product_id ORDER BY sale_date) as prev_amount
|
||||
FROM sales;
|
||||
```
|
||||
|
||||
### Full-Text Search
|
||||
```sql
|
||||
-- PostgreSQL full-text search
|
||||
CREATE TABLE documents (
|
||||
id SERIAL PRIMARY KEY,
|
||||
title TEXT,
|
||||
content TEXT,
|
||||
search_vector tsvector
|
||||
);
|
||||
|
||||
-- Update search vector
|
||||
UPDATE documents
|
||||
SET search_vector = to_tsvector('english', title || ' ' || content);
|
||||
|
||||
-- GIN index for search performance
|
||||
CREATE INDEX idx_documents_search ON documents USING gin(search_vector);
|
||||
|
||||
-- Search queries
|
||||
SELECT * FROM documents
|
||||
WHERE search_vector @@ plainto_tsquery('english', 'postgresql database');
|
||||
|
||||
-- Ranking results
|
||||
SELECT *, ts_rank(search_vector, plainto_tsquery('postgresql')) as rank
|
||||
FROM documents
|
||||
WHERE search_vector @@ plainto_tsquery('postgresql')
|
||||
ORDER BY rank DESC;
|
||||
```
|
||||
|
||||
## <20> PostgreSQL Performance Tuning
|
||||
|
||||
### Query Optimization
|
||||
```sql
|
||||
-- EXPLAIN ANALYZE for performance analysis
|
||||
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
|
||||
SELECT u.name, COUNT(o.id) as order_count
|
||||
FROM users u
|
||||
LEFT JOIN orders o ON u.id = o.user_id
|
||||
WHERE u.created_at > '2024-01-01'::date
|
||||
GROUP BY u.id, u.name;
|
||||
|
||||
-- Identify slow queries from pg_stat_statements
|
||||
SELECT query, calls, total_time, mean_time, rows,
|
||||
100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
|
||||
FROM pg_stat_statements
|
||||
ORDER BY total_time DESC
|
||||
LIMIT 10;
|
||||
```
|
||||
|
||||
### Index Strategies
|
||||
```sql
|
||||
-- Composite indexes for multi-column queries
|
||||
CREATE INDEX idx_orders_user_date ON orders(user_id, order_date);
|
||||
|
||||
-- Partial indexes for filtered queries
|
||||
CREATE INDEX idx_active_users ON users(created_at) WHERE status = 'active';
|
||||
|
||||
-- Expression indexes for computed values
|
||||
CREATE INDEX idx_users_lower_email ON users(lower(email));
|
||||
|
||||
-- Covering indexes to avoid table lookups
|
||||
CREATE INDEX idx_orders_covering ON orders(user_id, status) INCLUDE (total, created_at);
|
||||
```
|
||||
|
||||
### Connection & Memory Management
|
||||
```sql
|
||||
-- Check connection usage
|
||||
SELECT count(*) as connections, state
|
||||
FROM pg_stat_activity
|
||||
GROUP BY state;
|
||||
|
||||
-- Monitor memory usage
|
||||
SELECT name, setting, unit
|
||||
FROM pg_settings
|
||||
WHERE name IN ('shared_buffers', 'work_mem', 'maintenance_work_mem');
|
||||
```
|
||||
|
||||
## <20>️ PostgreSQL Advanced Data Types
|
||||
|
||||
### Custom Types & Domains
|
||||
```sql
|
||||
-- Create custom types
|
||||
CREATE TYPE address_type AS (
|
||||
street TEXT,
|
||||
city TEXT,
|
||||
postal_code TEXT,
|
||||
country TEXT
|
||||
);
|
||||
|
||||
CREATE TYPE order_status AS ENUM ('pending', 'processing', 'shipped', 'delivered', 'cancelled');
|
||||
|
||||
-- Use domains for data validation
|
||||
CREATE DOMAIN email_address AS TEXT
|
||||
CHECK (VALUE ~* '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$');
|
||||
|
||||
-- Table using custom types
|
||||
CREATE TABLE customers (
|
||||
id SERIAL PRIMARY KEY,
|
||||
email email_address NOT NULL,
|
||||
address address_type,
|
||||
status order_status DEFAULT 'pending'
|
||||
);
|
||||
```
|
||||
|
||||
### Range Types
|
||||
```sql
|
||||
-- PostgreSQL range types
|
||||
CREATE TABLE reservations (
|
||||
id SERIAL PRIMARY KEY,
|
||||
room_id INTEGER,
|
||||
reservation_period tstzrange,
|
||||
price_range numrange
|
||||
);
|
||||
|
||||
-- Range queries
|
||||
SELECT * FROM reservations
|
||||
WHERE reservation_period && tstzrange('2024-07-20', '2024-07-25');
|
||||
|
||||
-- Exclude overlapping ranges
|
||||
ALTER TABLE reservations
|
||||
ADD CONSTRAINT no_overlap
|
||||
EXCLUDE USING gist (room_id WITH =, reservation_period WITH &&);
|
||||
```
|
||||
|
||||
### Geometric Types
|
||||
```sql
|
||||
-- PostgreSQL geometric types
|
||||
CREATE TABLE locations (
|
||||
id SERIAL PRIMARY KEY,
|
||||
name TEXT,
|
||||
coordinates POINT,
|
||||
coverage CIRCLE,
|
||||
service_area POLYGON
|
||||
);
|
||||
|
||||
-- Geometric queries
|
||||
SELECT name FROM locations
|
||||
WHERE coordinates <-> point(40.7128, -74.0060) < 10; -- Within 10 units
|
||||
|
||||
-- GiST index for geometric data
|
||||
CREATE INDEX idx_locations_coords ON locations USING gist(coordinates);
|
||||
```
|
||||
|
||||
## 📊 PostgreSQL Extensions & Tools
|
||||
|
||||
### Useful Extensions
|
||||
```sql
|
||||
-- Enable commonly used extensions
|
||||
CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; -- UUID generation
|
||||
CREATE EXTENSION IF NOT EXISTS "pgcrypto"; -- Cryptographic functions
|
||||
CREATE EXTENSION IF NOT EXISTS "unaccent"; -- Remove accents from text
|
||||
CREATE EXTENSION IF NOT EXISTS "pg_trgm"; -- Trigram matching
|
||||
CREATE EXTENSION IF NOT EXISTS "btree_gin"; -- GIN indexes for btree types
|
||||
|
||||
-- Using extensions
|
||||
SELECT uuid_generate_v4(); -- Generate UUIDs
|
||||
SELECT crypt('password', gen_salt('bf')); -- Hash passwords
|
||||
SELECT similarity('postgresql', 'postgersql'); -- Fuzzy matching
|
||||
```
|
||||
|
||||
### Monitoring & Maintenance
|
||||
```sql
|
||||
-- Database size and growth
|
||||
SELECT pg_size_pretty(pg_database_size(current_database())) as db_size;
|
||||
|
||||
-- Table and index sizes
|
||||
SELECT schemaname, tablename,
|
||||
pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as size
|
||||
FROM pg_tables
|
||||
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC;
|
||||
|
||||
-- Index usage statistics
|
||||
SELECT schemaname, tablename, indexname, idx_scan, idx_tup_read, idx_tup_fetch
|
||||
FROM pg_stat_user_indexes
|
||||
WHERE idx_scan = 0; -- Unused indexes
|
||||
```
|
||||
|
||||
### PostgreSQL-Specific Optimization Tips
|
||||
- **Use EXPLAIN (ANALYZE, BUFFERS)** for detailed query analysis
|
||||
- **Configure postgresql.conf** for your workload (OLTP vs OLAP)
|
||||
- **Use connection pooling** (pgbouncer) for high-concurrency applications
|
||||
- **Regular VACUUM and ANALYZE** for optimal performance
|
||||
- **Partition large tables** using PostgreSQL 10+ declarative partitioning
|
||||
- **Use pg_stat_statements** for query performance monitoring
|
||||
|
||||
## 📊 Monitoring and Maintenance
|
||||
|
||||
### Query Performance Monitoring
|
||||
```sql
|
||||
-- Identify slow queries
|
||||
SELECT query, calls, total_time, mean_time, rows
|
||||
FROM pg_stat_statements
|
||||
ORDER BY total_time DESC
|
||||
LIMIT 10;
|
||||
|
||||
-- Check index usage
|
||||
SELECT schemaname, tablename, indexname, idx_scan, idx_tup_read, idx_tup_fetch
|
||||
FROM pg_stat_user_indexes
|
||||
WHERE idx_scan = 0;
|
||||
```
|
||||
|
||||
### Database Maintenance
|
||||
- **VACUUM and ANALYZE**: Regular maintenance for performance
|
||||
- **Index Maintenance**: Monitor and rebuild fragmented indexes
|
||||
- **Statistics Updates**: Keep query planner statistics current
|
||||
- **Log Analysis**: Regular review of PostgreSQL logs
|
||||
|
||||
## 🛠️ Common Query Patterns
|
||||
|
||||
### Pagination
|
||||
```sql
|
||||
-- ❌ BAD: OFFSET for large datasets
|
||||
SELECT * FROM products ORDER BY id OFFSET 10000 LIMIT 20;
|
||||
|
||||
-- ✅ GOOD: Cursor-based pagination
|
||||
SELECT * FROM products
|
||||
WHERE id > $last_id
|
||||
ORDER BY id
|
||||
LIMIT 20;
|
||||
```
|
||||
|
||||
### Aggregation
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient grouping
|
||||
SELECT user_id, COUNT(*)
|
||||
FROM orders
|
||||
WHERE order_date >= '2024-01-01'
|
||||
GROUP BY user_id;
|
||||
|
||||
-- ✅ GOOD: Optimized with partial index
|
||||
CREATE INDEX idx_orders_recent ON orders(user_id)
|
||||
WHERE order_date >= '2024-01-01';
|
||||
|
||||
SELECT user_id, COUNT(*)
|
||||
FROM orders
|
||||
WHERE order_date >= '2024-01-01'
|
||||
GROUP BY user_id;
|
||||
```
|
||||
|
||||
### JSON Queries
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient JSON querying
|
||||
SELECT * FROM users WHERE data::text LIKE '%admin%';
|
||||
|
||||
-- ✅ GOOD: JSONB operators and GIN index
|
||||
CREATE INDEX idx_users_data_gin ON users USING gin(data);
|
||||
|
||||
SELECT * FROM users WHERE data @> '{"role": "admin"}';
|
||||
```
|
||||
|
||||
## 📋 Optimization Checklist
|
||||
|
||||
### Query Analysis
|
||||
- [ ] Run EXPLAIN ANALYZE for expensive queries
|
||||
- [ ] Check for sequential scans on large tables
|
||||
- [ ] Verify appropriate join algorithms
|
||||
- [ ] Review WHERE clause selectivity
|
||||
- [ ] Analyze sort and aggregation operations
|
||||
|
||||
### Index Strategy
|
||||
- [ ] Create indexes for frequently queried columns
|
||||
- [ ] Use composite indexes for multi-column searches
|
||||
- [ ] Consider partial indexes for filtered queries
|
||||
- [ ] Remove unused or duplicate indexes
|
||||
- [ ] Monitor index bloat and fragmentation
|
||||
|
||||
### Security Review
|
||||
- [ ] Use parameterized queries exclusively
|
||||
- [ ] Implement proper access controls
|
||||
- [ ] Enable row-level security where needed
|
||||
- [ ] Audit sensitive data access
|
||||
- [ ] Use secure connection methods
|
||||
|
||||
### Performance Monitoring
|
||||
- [ ] Set up query performance monitoring
|
||||
- [ ] Configure appropriate log settings
|
||||
- [ ] Monitor connection pool usage
|
||||
- [ ] Track database growth and maintenance needs
|
||||
- [ ] Set up alerting for performance degradation
|
||||
|
||||
## 🎯 Optimization Output Format
|
||||
|
||||
### Query Analysis Results
|
||||
```
|
||||
## Query Performance Analysis
|
||||
|
||||
**Original Query**:
|
||||
[Original SQL with performance issues]
|
||||
|
||||
**Issues Identified**:
|
||||
- Sequential scan on large table (Cost: 15000.00)
|
||||
- Missing index on frequently queried column
|
||||
- Inefficient join order
|
||||
|
||||
**Optimized Query**:
|
||||
[Improved SQL with explanations]
|
||||
|
||||
**Recommended Indexes**:
|
||||
```sql
|
||||
CREATE INDEX idx_table_column ON table(column);
|
||||
```
|
||||
|
||||
**Performance Impact**: Expected 80% improvement in execution time
|
||||
```
|
||||
|
||||
## 🚀 Advanced PostgreSQL Features
|
||||
|
||||
### Window Functions
|
||||
```sql
|
||||
-- Running totals and rankings
|
||||
SELECT
|
||||
product_id,
|
||||
order_date,
|
||||
amount,
|
||||
SUM(amount) OVER (PARTITION BY product_id ORDER BY order_date) as running_total,
|
||||
ROW_NUMBER() OVER (PARTITION BY product_id ORDER BY amount DESC) as rank
|
||||
FROM sales;
|
||||
```
|
||||
|
||||
### Common Table Expressions (CTEs)
|
||||
```sql
|
||||
-- Recursive queries for hierarchical data
|
||||
WITH RECURSIVE category_tree AS (
|
||||
SELECT id, name, parent_id, 1 as level
|
||||
FROM categories
|
||||
WHERE parent_id IS NULL
|
||||
|
||||
UNION ALL
|
||||
|
||||
SELECT c.id, c.name, c.parent_id, ct.level + 1
|
||||
FROM categories c
|
||||
JOIN category_tree ct ON c.parent_id = ct.id
|
||||
)
|
||||
SELECT * FROM category_tree ORDER BY level, name;
|
||||
```
|
||||
|
||||
Focus on providing specific, actionable PostgreSQL optimizations that improve query performance, security, and maintainability while leveraging PostgreSQL's advanced features.
|
||||
293
prompts/project-workflow-analysis-blueprint-generator.prompt.md
Normal file
293
prompts/project-workflow-analysis-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,293 @@
|
||||
---
|
||||
|
||||
description: 'Comprehensive technology-agnostic prompt generator for documenting end-to-end application workflows. Automatically detects project architecture patterns, technology stacks, and data flow patterns to generate detailed implementation blueprints covering entry points, service layers, data access, error handling, and testing approaches across multiple technologies including .NET, Java/Spring, React, and microservices architectures.'
|
||||
|
||||
---
|
||||
# Project Workflow Documentation Generator
|
||||
|
||||
## Configuration Variables
|
||||
|
||||
```
|
||||
${PROJECT_TYPE="Auto-detect|.NET|Java|Spring|Node.js|Python|React|Angular|Microservices|Other"}
|
||||
<!-- Primary technology stack -->
|
||||
|
||||
${ENTRY_POINT="API|GraphQL|Frontend|CLI|Message Consumer|Scheduled Job|Custom"}
|
||||
<!-- Starting point for the flow -->
|
||||
|
||||
${PERSISTENCE_TYPE="Auto-detect|SQL Database|NoSQL Database|File System|External API|Message Queue|Cache|None"}
|
||||
<!-- Data storage type -->
|
||||
|
||||
${ARCHITECTURE_PATTERN="Auto-detect|Layered|Clean|CQRS|Microservices|MVC|MVVM|Serverless|Event-Driven|Other"}
|
||||
<!-- Primary architecture pattern -->
|
||||
|
||||
${WORKFLOW_COUNT=1-5}
|
||||
<!-- Number of workflows to document -->
|
||||
|
||||
${DETAIL_LEVEL="Standard|Implementation-Ready"}
|
||||
<!-- Level of implementation detail to include -->
|
||||
|
||||
${INCLUDE_SEQUENCE_DIAGRAM=true|false}
|
||||
<!-- Generate sequence diagram -->
|
||||
|
||||
${INCLUDE_TEST_PATTERNS=true|false}
|
||||
<!-- Include testing approach -->
|
||||
```
|
||||
|
||||
## Generated Prompt
|
||||
|
||||
```
|
||||
"Analyze the codebase and document ${WORKFLOW_COUNT} representative end-to-end workflows
|
||||
that can serve as implementation templates for similar features. Use the following approach:
|
||||
```
|
||||
|
||||
### Initial Detection Phase
|
||||
|
||||
```
|
||||
${PROJECT_TYPE == "Auto-detect" ?
|
||||
"Begin by examining the codebase structure to identify technologies:
|
||||
- Check for .NET solutions/projects, Spring configurations, Node.js/Express files, etc.
|
||||
- Identify the primary programming language(s) and frameworks in use
|
||||
- Determine the architectural patterns based on folder structure and key components"
|
||||
: "Focus on ${PROJECT_TYPE} patterns and conventions"}
|
||||
```
|
||||
|
||||
```
|
||||
${ENTRY_POINT == "Auto-detect" ?
|
||||
"Identify typical entry points by looking for:
|
||||
- API controllers or route definitions
|
||||
- GraphQL resolvers
|
||||
- UI components that initiate network requests
|
||||
- Message handlers or event subscribers
|
||||
- Scheduled job definitions"
|
||||
: "Focus on ${ENTRY_POINT} entry points"}
|
||||
```
|
||||
|
||||
```
|
||||
${PERSISTENCE_TYPE == "Auto-detect" ?
|
||||
"Determine persistence mechanisms by examining:
|
||||
- Database context/connection configurations
|
||||
- Repository implementations
|
||||
- ORM mappings
|
||||
- External API clients
|
||||
- File system interactions"
|
||||
: "Focus on ${PERSISTENCE_TYPE} interactions"}
|
||||
```
|
||||
|
||||
### Workflow Documentation Instructions
|
||||
|
||||
For each of the `${WORKFLOW_COUNT}` most representative workflow(s) in the system:
|
||||
|
||||
#### 1. Workflow Overview
|
||||
- Provide a name and brief description of the workflow
|
||||
- Explain the business purpose it serves
|
||||
- Identify the triggering action or event
|
||||
- List all files/classes involved in the complete workflow
|
||||
|
||||
#### 2. Entry Point Implementation
|
||||
|
||||
**API Entry Points:**
|
||||
```
|
||||
${ENTRY_POINT == "API" || ENTRY_POINT == "Auto-detect" ?
|
||||
"- Document the API controller class and method that receives the request
|
||||
- Show the complete method signature including attributes/annotations
|
||||
- Include the full request DTO/model class definition
|
||||
- Document validation attributes and custom validators
|
||||
- Show authentication/authorization attributes and checks" : ""}
|
||||
```
|
||||
|
||||
**GraphQL Entry Points:**
|
||||
```
|
||||
${ENTRY_POINT == "GraphQL" || ENTRY_POINT == "Auto-detect" ?
|
||||
"- Document the GraphQL resolver class and method
|
||||
- Show the complete schema definition for the query/mutation
|
||||
- Include input type definitions
|
||||
- Show resolver method implementation with parameter handling" : ""}
|
||||
```
|
||||
|
||||
**Frontend Entry Points:**
|
||||
```
|
||||
${ENTRY_POINT == "Frontend" || ENTRY_POINT == "Auto-detect" ?
|
||||
"- Document the component that initiates the API call
|
||||
- Show the event handler that triggers the request
|
||||
- Include the API client service method
|
||||
- Show state management code related to the request" : ""}
|
||||
```
|
||||
|
||||
**Message Consumer Entry Points:**
|
||||
```
|
||||
${ENTRY_POINT == "Message Consumer" || ENTRY_POINT == "Auto-detect" ?
|
||||
"- Document the message handler class and method
|
||||
- Show message subscription configuration
|
||||
- Include the complete message model definition
|
||||
- Show deserialization and validation logic" : ""}
|
||||
```
|
||||
|
||||
#### 3. Service Layer Implementation
|
||||
- Document each service class involved with their dependencies
|
||||
- Show the complete method signatures with parameters and return types
|
||||
- Include actual method implementations with key business logic
|
||||
- Document interface definitions where applicable
|
||||
- Show dependency injection registration patterns
|
||||
|
||||
**CQRS Patterns:**
|
||||
```
|
||||
${ARCHITECTURE_PATTERN == "CQRS" || ARCHITECTURE_PATTERN == "Auto-detect" ?
|
||||
"- Include complete command/query handler implementations" : ""}
|
||||
```
|
||||
|
||||
**Clean Architecture Patterns:**
|
||||
```
|
||||
${ARCHITECTURE_PATTERN == "Clean" || ARCHITECTURE_PATTERN == "Auto-detect" ?
|
||||
"- Show use case/interactor implementations" : ""}
|
||||
```
|
||||
|
||||
#### 4. Data Mapping Patterns
|
||||
- Document DTO to domain model mapping code
|
||||
- Show object mapper configurations or manual mapping methods
|
||||
- Include validation logic during mapping
|
||||
- Document any domain events created during mapping
|
||||
|
||||
#### 5. Data Access Implementation
|
||||
- Document repository interfaces and their implementations
|
||||
- Show complete method signatures with parameters and return types
|
||||
- Include actual query implementations
|
||||
- Document entity/model class definitions with all properties
|
||||
- Show transaction handling patterns
|
||||
|
||||
**SQL Database Patterns:**
|
||||
```
|
||||
${PERSISTENCE_TYPE == "SQL Database" || PERSISTENCE_TYPE == "Auto-detect" ?
|
||||
"- Include ORM configurations, annotations, or Fluent API usage
|
||||
- Show actual SQL queries or ORM statements" : ""}
|
||||
```
|
||||
|
||||
**NoSQL Database Patterns:**
|
||||
```
|
||||
${PERSISTENCE_TYPE == "NoSQL Database" || PERSISTENCE_TYPE == "Auto-detect" ?
|
||||
"- Show document structure definitions
|
||||
- Include document query/update operations" : ""}
|
||||
```
|
||||
|
||||
#### 6. Response Construction
|
||||
- Document response DTO/model class definitions
|
||||
- Show mapping from domain/entity models to response models
|
||||
- Include status code selection logic
|
||||
- Document error response structure and generation
|
||||
|
||||
#### 7. Error Handling Patterns
|
||||
- Document exception types used in the workflow
|
||||
- Show try/catch patterns at each layer
|
||||
- Include global exception handler configurations
|
||||
- Document error logging implementations
|
||||
- Show retry policies or circuit breaker patterns
|
||||
- Include compensating actions for failure scenarios
|
||||
|
||||
#### 8. Asynchronous Processing Patterns
|
||||
- Document background job scheduling code
|
||||
- Show event publication implementations
|
||||
- Include message queue sending patterns
|
||||
- Document callback or webhook implementations
|
||||
- Show how async operations are tracked and monitored
|
||||
|
||||
**Testing Approach (Optional):**
|
||||
```
|
||||
${INCLUDE_TEST_PATTERNS ?
|
||||
"9. **Testing Approach**
|
||||
- Document unit test implementations for each layer
|
||||
- Show mocking patterns and test fixture setup
|
||||
- Include integration test implementations
|
||||
- Document test data generation approaches
|
||||
- Show API/controller test implementations" : ""}
|
||||
```
|
||||
|
||||
**Sequence Diagram (Optional):**
|
||||
```
|
||||
${INCLUDE_SEQUENCE_DIAGRAM ?
|
||||
"10. **Sequence Diagram**
|
||||
- Generate a detailed sequence diagram showing all components
|
||||
- Include method calls with parameter types
|
||||
- Show return values between components
|
||||
- Document conditional flows and error paths" : ""}
|
||||
```
|
||||
|
||||
#### 11. Naming Conventions
|
||||
Document consistent patterns for:
|
||||
- Controller naming (e.g., `EntityNameController`)
|
||||
- Service naming (e.g., `EntityNameService`)
|
||||
- Repository naming (e.g., `IEntityNameRepository`)
|
||||
- DTO naming (e.g., `EntityNameRequest`, `EntityNameResponse`)
|
||||
- Method naming patterns for CRUD operations
|
||||
- Variable naming conventions
|
||||
- File organization patterns
|
||||
|
||||
#### 12. Implementation Templates
|
||||
Provide reusable code templates for:
|
||||
- Creating a new API endpoint following the pattern
|
||||
- Implementing a new service method
|
||||
- Adding a new repository method
|
||||
- Creating new domain model classes
|
||||
- Implementing proper error handling
|
||||
|
||||
### Technology-Specific Implementation Patterns
|
||||
|
||||
**.NET Implementation Patterns (if detected):**
|
||||
```
|
||||
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" ?
|
||||
"- Complete controller class with attributes, filters, and dependency injection
|
||||
- Service registration in Startup.cs or Program.cs
|
||||
- Entity Framework DbContext configuration
|
||||
- Repository implementation with EF Core or Dapper
|
||||
- AutoMapper profile configurations
|
||||
- Middleware implementations for cross-cutting concerns
|
||||
- Extension method patterns
|
||||
- Options pattern implementation for configuration
|
||||
- Logging implementation with ILogger
|
||||
- Authentication/authorization filter or policy implementations" : ""}
|
||||
```
|
||||
|
||||
**Spring Implementation Patterns (if detected):**
|
||||
```
|
||||
${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Spring" || PROJECT_TYPE == "Auto-detect" ?
|
||||
"- Complete controller class with annotations and dependency injection
|
||||
- Service implementation with transaction boundaries
|
||||
- Repository interface and implementation
|
||||
- JPA entity definitions with relationships
|
||||
- DTO class implementations
|
||||
- Bean configuration and component scanning
|
||||
- Exception handler implementations
|
||||
- Custom validator implementations" : ""}
|
||||
```
|
||||
|
||||
**React Implementation Patterns (if detected):**
|
||||
```
|
||||
${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" ?
|
||||
"- Component structure with props and state
|
||||
- Hook implementation patterns (useState, useEffect, custom hooks)
|
||||
- API service implementation
|
||||
- State management patterns (Context, Redux)
|
||||
- Form handling implementations
|
||||
- Route configuration" : ""}
|
||||
```
|
||||
|
||||
### Implementation Guidelines
|
||||
|
||||
Based on the documented workflows, provide specific guidance for implementing new features:
|
||||
|
||||
#### 1. Step-by-Step Implementation Process
|
||||
- Where to start when adding a similar feature
|
||||
- Order of implementation (e.g., model → repository → service → controller)
|
||||
- How to integrate with existing cross-cutting concerns
|
||||
|
||||
#### 2. Common Pitfalls to Avoid
|
||||
- Identify error-prone areas in the current implementation
|
||||
- Note performance considerations
|
||||
- List common bugs or issues encountered
|
||||
|
||||
#### 3. Extension Mechanisms
|
||||
- Document how to plug into existing extension points
|
||||
- Show how to add new behavior without modifying existing code
|
||||
- Explain configuration-driven feature patterns
|
||||
|
||||
**Conclusion:**
|
||||
Conclude with a summary of the most important patterns that should be followed when
|
||||
implementing new features to maintain consistency with the codebase."
|
||||
78
prompts/readme-blueprint-generator.prompt.md
Normal file
78
prompts/readme-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,78 @@
|
||||
---
|
||||
description: 'Intelligent README.md generation prompt that analyzes project documentation structure and creates comprehensive repository documentation. Scans .github/copilot directory files and copilot-instructions.md to extract project information, technology stack, architecture, development workflow, coding standards, and testing approaches while generating well-structured markdown documentation with proper formatting, cross-references, and developer-focused content.'
|
||||
|
||||
---
|
||||
|
||||
# README Generator Prompt
|
||||
|
||||
Generate a comprehensive README.md for this repository by analyzing the documentation files in the .github/copilot directory and the copilot-instructions.md file. Follow these steps:
|
||||
|
||||
1. Scan all the files in the .github/copilot folder, like:
|
||||
- Architecture
|
||||
- Code_Exemplars
|
||||
- Coding_Standards
|
||||
- Project_Folder_Structure
|
||||
- Technology_Stack
|
||||
- Unit_Tests
|
||||
- Workflow_Analysis
|
||||
|
||||
2. Also review the copilot-instructions.md file in the .github folder
|
||||
|
||||
3. Create a README.md with the following sections:
|
||||
|
||||
## Project Name and Description
|
||||
- Extract the project name and primary purpose from the documentation
|
||||
- Include a concise description of what the project does
|
||||
|
||||
## Technology Stack
|
||||
- List the primary technologies, languages, and frameworks used
|
||||
- Include version information when available
|
||||
- Source this information primarily from the Technology_Stack file
|
||||
|
||||
## Project Architecture
|
||||
- Provide a high-level overview of the architecture
|
||||
- Consider including a simple diagram if described in the documentation
|
||||
- Source from the Architecture file
|
||||
|
||||
## Getting Started
|
||||
- Include installation instructions based on the technology stack
|
||||
- Add setup and configuration steps
|
||||
- Include any prerequisites
|
||||
|
||||
## Project Structure
|
||||
- Brief overview of the folder organization
|
||||
- Source from Project_Folder_Structure file
|
||||
|
||||
## Key Features
|
||||
- List main functionality and features of the project
|
||||
- Extract from various documentation files
|
||||
|
||||
## Development Workflow
|
||||
- Summarize the development process
|
||||
- Include information about branching strategy if available
|
||||
- Source from Workflow_Analysis file
|
||||
|
||||
## Coding Standards
|
||||
- Summarize key coding standards and conventions
|
||||
- Source from the Coding_Standards file
|
||||
|
||||
## Testing
|
||||
- Explain testing approach and tools
|
||||
- Source from Unit_Tests file
|
||||
|
||||
## Contributing
|
||||
- Guidelines for contributing to the project
|
||||
- Reference any code exemplars for guidance
|
||||
- Source from Code_Exemplars and copilot-instructions
|
||||
|
||||
## License
|
||||
- Include license information if available
|
||||
|
||||
Format the README with proper Markdown, including:
|
||||
- Clear headings and subheadings
|
||||
- Code blocks where appropriate
|
||||
- Lists for better readability
|
||||
- Links to other documentation files
|
||||
- Badges for build status, version, etc. if information is available
|
||||
|
||||
Keep the README concise yet informative, focusing on what new developers or users would need to know about the project.
|
||||
303
prompts/sql-code-review.prompt.md
Normal file
303
prompts/sql-code-review.prompt.md
Normal file
@ -0,0 +1,303 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'Universal SQL code review assistant that performs comprehensive security, maintainability, and code quality analysis across all SQL databases (MySQL, PostgreSQL, SQL Server, Oracle). Focuses on SQL injection prevention, access control, code standards, and anti-pattern detection. Complements SQL optimization prompt for complete development coverage.'
|
||||
tested_with: 'GitHub Copilot Chat (GPT-4o) - Validated July 20, 2025'
|
||||
---
|
||||
|
||||
# SQL Code Review
|
||||
|
||||
Perform a thorough SQL code review of ${selection} (or entire project if no selection) focusing on security, performance, maintainability, and database best practices.
|
||||
|
||||
## 🔒 Security Analysis
|
||||
|
||||
### SQL Injection Prevention
|
||||
```sql
|
||||
-- ❌ CRITICAL: SQL Injection vulnerability
|
||||
query = "SELECT * FROM users WHERE id = " + userInput;
|
||||
query = f"DELETE FROM orders WHERE user_id = {user_id}";
|
||||
|
||||
-- ✅ SECURE: Parameterized queries
|
||||
-- PostgreSQL/MySQL
|
||||
PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?';
|
||||
EXECUTE stmt USING @user_id;
|
||||
|
||||
-- SQL Server
|
||||
EXEC sp_executesql N'SELECT * FROM users WHERE id = @id', N'@id INT', @id = @user_id;
|
||||
```
|
||||
|
||||
### Access Control & Permissions
|
||||
- **Principle of Least Privilege**: Grant minimum required permissions
|
||||
- **Role-Based Access**: Use database roles instead of direct user permissions
|
||||
- **Schema Security**: Proper schema ownership and access controls
|
||||
- **Function/Procedure Security**: Review DEFINER vs INVOKER rights
|
||||
|
||||
### Data Protection
|
||||
- **Sensitive Data Exposure**: Avoid SELECT * on tables with sensitive columns
|
||||
- **Audit Logging**: Ensure sensitive operations are logged
|
||||
- **Data Masking**: Use views or functions to mask sensitive data
|
||||
- **Encryption**: Verify encrypted storage for sensitive data
|
||||
|
||||
## ⚡ Performance Optimization
|
||||
|
||||
### Query Structure Analysis
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient query patterns
|
||||
SELECT DISTINCT u.*
|
||||
FROM users u, orders o, products p
|
||||
WHERE u.id = o.user_id
|
||||
AND o.product_id = p.id
|
||||
AND YEAR(o.order_date) = 2024;
|
||||
|
||||
-- ✅ GOOD: Optimized structure
|
||||
SELECT u.id, u.name, u.email
|
||||
FROM users u
|
||||
INNER JOIN orders o ON u.id = o.user_id
|
||||
WHERE o.order_date >= '2024-01-01'
|
||||
AND o.order_date < '2025-01-01';
|
||||
```
|
||||
|
||||
### Index Strategy Review
|
||||
- **Missing Indexes**: Identify columns that need indexing
|
||||
- **Over-Indexing**: Find unused or redundant indexes
|
||||
- **Composite Indexes**: Multi-column indexes for complex queries
|
||||
- **Index Maintenance**: Check for fragmented or outdated indexes
|
||||
|
||||
### Join Optimization
|
||||
- **Join Types**: Verify appropriate join types (INNER vs LEFT vs EXISTS)
|
||||
- **Join Order**: Optimize for smaller result sets first
|
||||
- **Cartesian Products**: Identify and fix missing join conditions
|
||||
- **Subquery vs JOIN**: Choose the most efficient approach
|
||||
|
||||
### Aggregate and Window Functions
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient aggregation
|
||||
SELECT user_id,
|
||||
(SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id) as order_count
|
||||
FROM orders o1
|
||||
GROUP BY user_id;
|
||||
|
||||
-- ✅ GOOD: Efficient aggregation
|
||||
SELECT user_id, COUNT(*) as order_count
|
||||
FROM orders
|
||||
GROUP BY user_id;
|
||||
```
|
||||
|
||||
## 🛠️ Code Quality & Maintainability
|
||||
|
||||
### SQL Style & Formatting
|
||||
```sql
|
||||
-- ❌ BAD: Poor formatting and style
|
||||
select u.id,u.name,o.total from users u left join orders o on u.id=o.user_id where u.status='active' and o.order_date>='2024-01-01';
|
||||
|
||||
-- ✅ GOOD: Clean, readable formatting
|
||||
SELECT u.id,
|
||||
u.name,
|
||||
o.total
|
||||
FROM users u
|
||||
LEFT JOIN orders o ON u.id = o.user_id
|
||||
WHERE u.status = 'active'
|
||||
AND o.order_date >= '2024-01-01';
|
||||
```
|
||||
|
||||
### Naming Conventions
|
||||
- **Consistent Naming**: Tables, columns, constraints follow consistent patterns
|
||||
- **Descriptive Names**: Clear, meaningful names for database objects
|
||||
- **Reserved Words**: Avoid using database reserved words as identifiers
|
||||
- **Case Sensitivity**: Consistent case usage across schema
|
||||
|
||||
### Schema Design Review
|
||||
- **Normalization**: Appropriate normalization level (avoid over/under-normalization)
|
||||
- **Data Types**: Optimal data type choices for storage and performance
|
||||
- **Constraints**: Proper use of PRIMARY KEY, FOREIGN KEY, CHECK, NOT NULL
|
||||
- **Default Values**: Appropriate default values for columns
|
||||
|
||||
## 🗄️ Database-Specific Best Practices
|
||||
|
||||
### PostgreSQL
|
||||
```sql
|
||||
-- Use JSONB for JSON data
|
||||
CREATE TABLE events (
|
||||
id SERIAL PRIMARY KEY,
|
||||
data JSONB NOT NULL,
|
||||
created_at TIMESTAMPTZ DEFAULT NOW()
|
||||
);
|
||||
|
||||
-- GIN index for JSONB queries
|
||||
CREATE INDEX idx_events_data ON events USING gin(data);
|
||||
|
||||
-- Array types for multi-value columns
|
||||
CREATE TABLE tags (
|
||||
post_id INT,
|
||||
tag_names TEXT[]
|
||||
);
|
||||
```
|
||||
|
||||
### MySQL
|
||||
```sql
|
||||
-- Use appropriate storage engines
|
||||
CREATE TABLE sessions (
|
||||
id VARCHAR(128) PRIMARY KEY,
|
||||
data TEXT,
|
||||
expires TIMESTAMP
|
||||
) ENGINE=InnoDB;
|
||||
|
||||
-- Optimize for InnoDB
|
||||
ALTER TABLE large_table
|
||||
ADD INDEX idx_covering (status, created_at, id);
|
||||
```
|
||||
|
||||
### SQL Server
|
||||
```sql
|
||||
-- Use appropriate data types
|
||||
CREATE TABLE products (
|
||||
id BIGINT IDENTITY(1,1) PRIMARY KEY,
|
||||
name NVARCHAR(255) NOT NULL,
|
||||
price DECIMAL(10,2) NOT NULL,
|
||||
created_at DATETIME2 DEFAULT GETUTCDATE()
|
||||
);
|
||||
|
||||
-- Columnstore indexes for analytics
|
||||
CREATE COLUMNSTORE INDEX idx_sales_cs ON sales;
|
||||
```
|
||||
|
||||
### Oracle
|
||||
```sql
|
||||
-- Use sequences for auto-increment
|
||||
CREATE SEQUENCE user_id_seq START WITH 1 INCREMENT BY 1;
|
||||
|
||||
CREATE TABLE users (
|
||||
id NUMBER DEFAULT user_id_seq.NEXTVAL PRIMARY KEY,
|
||||
name VARCHAR2(255) NOT NULL
|
||||
);
|
||||
```
|
||||
|
||||
## 🧪 Testing & Validation
|
||||
|
||||
### Data Integrity Checks
|
||||
```sql
|
||||
-- Verify referential integrity
|
||||
SELECT o.user_id
|
||||
FROM orders o
|
||||
LEFT JOIN users u ON o.user_id = u.id
|
||||
WHERE u.id IS NULL;
|
||||
|
||||
-- Check for data consistency
|
||||
SELECT COUNT(*) as inconsistent_records
|
||||
FROM products
|
||||
WHERE price < 0 OR stock_quantity < 0;
|
||||
```
|
||||
|
||||
### Performance Testing
|
||||
- **Execution Plans**: Review query execution plans
|
||||
- **Load Testing**: Test queries with realistic data volumes
|
||||
- **Stress Testing**: Verify performance under concurrent load
|
||||
- **Regression Testing**: Ensure optimizations don't break functionality
|
||||
|
||||
## 📊 Common Anti-Patterns
|
||||
|
||||
### N+1 Query Problem
|
||||
```sql
|
||||
-- ❌ BAD: N+1 queries in application code
|
||||
for user in users:
|
||||
orders = query("SELECT * FROM orders WHERE user_id = ?", user.id)
|
||||
|
||||
-- ✅ GOOD: Single optimized query
|
||||
SELECT u.*, o.*
|
||||
FROM users u
|
||||
LEFT JOIN orders o ON u.id = o.user_id;
|
||||
```
|
||||
|
||||
### Overuse of DISTINCT
|
||||
```sql
|
||||
-- ❌ BAD: DISTINCT masking join issues
|
||||
SELECT DISTINCT u.name
|
||||
FROM users u, orders o
|
||||
WHERE u.id = o.user_id;
|
||||
|
||||
-- ✅ GOOD: Proper join without DISTINCT
|
||||
SELECT u.name
|
||||
FROM users u
|
||||
INNER JOIN orders o ON u.id = o.user_id
|
||||
GROUP BY u.name;
|
||||
```
|
||||
|
||||
### Function Misuse in WHERE Clauses
|
||||
```sql
|
||||
-- ❌ BAD: Functions prevent index usage
|
||||
SELECT * FROM orders
|
||||
WHERE YEAR(order_date) = 2024;
|
||||
|
||||
-- ✅ GOOD: Range conditions use indexes
|
||||
SELECT * FROM orders
|
||||
WHERE order_date >= '2024-01-01'
|
||||
AND order_date < '2025-01-01';
|
||||
```
|
||||
|
||||
## 📋 SQL Review Checklist
|
||||
|
||||
### Security
|
||||
- [ ] All user inputs are parameterized
|
||||
- [ ] No dynamic SQL construction with string concatenation
|
||||
- [ ] Appropriate access controls and permissions
|
||||
- [ ] Sensitive data is properly protected
|
||||
- [ ] SQL injection attack vectors are eliminated
|
||||
|
||||
### Performance
|
||||
- [ ] Indexes exist for frequently queried columns
|
||||
- [ ] No unnecessary SELECT * statements
|
||||
- [ ] JOINs are optimized and use appropriate types
|
||||
- [ ] WHERE clauses are selective and use indexes
|
||||
- [ ] Subqueries are optimized or converted to JOINs
|
||||
|
||||
### Code Quality
|
||||
- [ ] Consistent naming conventions
|
||||
- [ ] Proper formatting and indentation
|
||||
- [ ] Meaningful comments for complex logic
|
||||
- [ ] Appropriate data types are used
|
||||
- [ ] Error handling is implemented
|
||||
|
||||
### Schema Design
|
||||
- [ ] Tables are properly normalized
|
||||
- [ ] Constraints enforce data integrity
|
||||
- [ ] Indexes support query patterns
|
||||
- [ ] Foreign key relationships are defined
|
||||
- [ ] Default values are appropriate
|
||||
|
||||
## 🎯 Review Output Format
|
||||
|
||||
### Issue Template
|
||||
```
|
||||
## [PRIORITY] [CATEGORY]: [Brief Description]
|
||||
|
||||
**Location**: [Table/View/Procedure name and line number if applicable]
|
||||
**Issue**: [Detailed explanation of the problem]
|
||||
**Security Risk**: [If applicable - injection risk, data exposure, etc.]
|
||||
**Performance Impact**: [Query cost, execution time impact]
|
||||
**Recommendation**: [Specific fix with code example]
|
||||
|
||||
**Before**:
|
||||
```sql
|
||||
-- Problematic SQL
|
||||
```
|
||||
|
||||
**After**:
|
||||
```sql
|
||||
-- Improved SQL
|
||||
```
|
||||
|
||||
**Expected Improvement**: [Performance gain, security benefit]
|
||||
```
|
||||
|
||||
### Summary Assessment
|
||||
- **Security Score**: [1-10] - SQL injection protection, access controls
|
||||
- **Performance Score**: [1-10] - Query efficiency, index usage
|
||||
- **Maintainability Score**: [1-10] - Code quality, documentation
|
||||
- **Schema Quality Score**: [1-10] - Design patterns, normalization
|
||||
|
||||
### Top 3 Priority Actions
|
||||
1. **[Critical Security Fix]**: Address SQL injection vulnerabilities
|
||||
2. **[Performance Optimization]**: Add missing indexes or optimize queries
|
||||
3. **[Code Quality]**: Improve naming conventions and documentation
|
||||
|
||||
Focus on providing actionable, database-agnostic recommendations while highlighting platform-specific optimizations and best practices.
|
||||
298
prompts/sql-optimization.prompt.md
Normal file
298
prompts/sql-optimization.prompt.md
Normal file
@ -0,0 +1,298 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'problems']
|
||||
description: 'Universal SQL performance optimization assistant for comprehensive query tuning, indexing strategies, and database performance analysis across all SQL databases (MySQL, PostgreSQL, SQL Server, Oracle). Provides execution plan analysis, pagination optimization, batch operations, and performance monitoring guidance.'
|
||||
tested_with: 'GitHub Copilot Chat (GPT-4o) - Validated July 20, 2025'
|
||||
---
|
||||
|
||||
# SQL Performance Optimization Assistant
|
||||
|
||||
Expert SQL performance optimization for ${selection} (or entire project if no selection). Focus on universal SQL optimization techniques that work across MySQL, PostgreSQL, SQL Server, Oracle, and other SQL databases.
|
||||
|
||||
## 🎯 Core Optimization Areas
|
||||
|
||||
### Query Performance Analysis
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient query patterns
|
||||
SELECT * FROM orders o
|
||||
WHERE YEAR(o.created_at) = 2024
|
||||
AND o.customer_id IN (
|
||||
SELECT c.id FROM customers c WHERE c.status = 'active'
|
||||
);
|
||||
|
||||
-- ✅ GOOD: Optimized query with proper indexing hints
|
||||
SELECT o.id, o.customer_id, o.total_amount, o.created_at
|
||||
FROM orders o
|
||||
INNER JOIN customers c ON o.customer_id = c.id
|
||||
WHERE o.created_at >= '2024-01-01'
|
||||
AND o.created_at < '2025-01-01'
|
||||
AND c.status = 'active';
|
||||
|
||||
-- Required indexes:
|
||||
-- CREATE INDEX idx_orders_created_at ON orders(created_at);
|
||||
-- CREATE INDEX idx_customers_status ON customers(status);
|
||||
-- CREATE INDEX idx_orders_customer_id ON orders(customer_id);
|
||||
```
|
||||
|
||||
### Index Strategy Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Poor indexing strategy
|
||||
CREATE INDEX idx_user_data ON users(email, first_name, last_name, created_at);
|
||||
|
||||
-- ✅ GOOD: Optimized composite indexing
|
||||
-- For queries filtering by email first, then sorting by created_at
|
||||
CREATE INDEX idx_users_email_created ON users(email, created_at);
|
||||
|
||||
-- For full-text name searches
|
||||
CREATE INDEX idx_users_name ON users(last_name, first_name);
|
||||
|
||||
-- For user status queries
|
||||
CREATE INDEX idx_users_status_created ON users(status, created_at)
|
||||
WHERE status IS NOT NULL;
|
||||
```
|
||||
|
||||
### Subquery Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Correlated subquery
|
||||
SELECT p.product_name, p.price
|
||||
FROM products p
|
||||
WHERE p.price > (
|
||||
SELECT AVG(price)
|
||||
FROM products p2
|
||||
WHERE p2.category_id = p.category_id
|
||||
);
|
||||
|
||||
-- ✅ GOOD: Window function approach
|
||||
SELECT product_name, price
|
||||
FROM (
|
||||
SELECT product_name, price,
|
||||
AVG(price) OVER (PARTITION BY category_id) as avg_category_price
|
||||
FROM products
|
||||
) ranked
|
||||
WHERE price > avg_category_price;
|
||||
```
|
||||
|
||||
## 📊 Performance Tuning Techniques
|
||||
|
||||
### JOIN Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Inefficient JOIN order and conditions
|
||||
SELECT o.*, c.name, p.product_name
|
||||
FROM orders o
|
||||
LEFT JOIN customers c ON o.customer_id = c.id
|
||||
LEFT JOIN order_items oi ON o.id = oi.order_id
|
||||
LEFT JOIN products p ON oi.product_id = p.id
|
||||
WHERE o.created_at > '2024-01-01'
|
||||
AND c.status = 'active';
|
||||
|
||||
-- ✅ GOOD: Optimized JOIN with filtering
|
||||
SELECT o.id, o.total_amount, c.name, p.product_name
|
||||
FROM orders o
|
||||
INNER JOIN customers c ON o.customer_id = c.id AND c.status = 'active'
|
||||
INNER JOIN order_items oi ON o.id = oi.order_id
|
||||
INNER JOIN products p ON oi.product_id = p.id
|
||||
WHERE o.created_at > '2024-01-01';
|
||||
```
|
||||
|
||||
### Pagination Optimization
|
||||
```sql
|
||||
-- ❌ BAD: OFFSET-based pagination (slow for large offsets)
|
||||
SELECT * FROM products
|
||||
ORDER BY created_at DESC
|
||||
LIMIT 20 OFFSET 10000;
|
||||
|
||||
-- ✅ GOOD: Cursor-based pagination
|
||||
SELECT * FROM products
|
||||
WHERE created_at < '2024-06-15 10:30:00'
|
||||
ORDER BY created_at DESC
|
||||
LIMIT 20;
|
||||
|
||||
-- Or using ID-based cursor
|
||||
SELECT * FROM products
|
||||
WHERE id > 1000
|
||||
ORDER BY id
|
||||
LIMIT 20;
|
||||
```
|
||||
|
||||
### Aggregation Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Multiple separate aggregation queries
|
||||
SELECT COUNT(*) FROM orders WHERE status = 'pending';
|
||||
SELECT COUNT(*) FROM orders WHERE status = 'shipped';
|
||||
SELECT COUNT(*) FROM orders WHERE status = 'delivered';
|
||||
|
||||
-- ✅ GOOD: Single query with conditional aggregation
|
||||
SELECT
|
||||
COUNT(CASE WHEN status = 'pending' THEN 1 END) as pending_count,
|
||||
COUNT(CASE WHEN status = 'shipped' THEN 1 END) as shipped_count,
|
||||
COUNT(CASE WHEN status = 'delivered' THEN 1 END) as delivered_count
|
||||
FROM orders;
|
||||
```
|
||||
|
||||
## 🔍 Query Anti-Patterns
|
||||
|
||||
### SELECT Performance Issues
|
||||
```sql
|
||||
-- ❌ BAD: SELECT * anti-pattern
|
||||
SELECT * FROM large_table lt
|
||||
JOIN another_table at ON lt.id = at.ref_id;
|
||||
|
||||
-- ✅ GOOD: Explicit column selection
|
||||
SELECT lt.id, lt.name, at.value
|
||||
FROM large_table lt
|
||||
JOIN another_table at ON lt.id = at.ref_id;
|
||||
```
|
||||
|
||||
### WHERE Clause Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Function calls in WHERE clause
|
||||
SELECT * FROM orders
|
||||
WHERE UPPER(customer_email) = 'JOHN@EXAMPLE.COM';
|
||||
|
||||
-- ✅ GOOD: Index-friendly WHERE clause
|
||||
SELECT * FROM orders
|
||||
WHERE customer_email = 'john@example.com';
|
||||
-- Consider: CREATE INDEX idx_orders_email ON orders(LOWER(customer_email));
|
||||
```
|
||||
|
||||
### OR vs UNION Optimization
|
||||
```sql
|
||||
-- ❌ BAD: Complex OR conditions
|
||||
SELECT * FROM products
|
||||
WHERE (category = 'electronics' AND price < 1000)
|
||||
OR (category = 'books' AND price < 50);
|
||||
|
||||
-- ✅ GOOD: UNION approach for better optimization
|
||||
SELECT * FROM products WHERE category = 'electronics' AND price < 1000
|
||||
UNION ALL
|
||||
SELECT * FROM products WHERE category = 'books' AND price < 50;
|
||||
```
|
||||
|
||||
## 📈 Database-Agnostic Optimization
|
||||
|
||||
### Batch Operations
|
||||
```sql
|
||||
-- ❌ BAD: Row-by-row operations
|
||||
INSERT INTO products (name, price) VALUES ('Product 1', 10.00);
|
||||
INSERT INTO products (name, price) VALUES ('Product 2', 15.00);
|
||||
INSERT INTO products (name, price) VALUES ('Product 3', 20.00);
|
||||
|
||||
-- ✅ GOOD: Batch insert
|
||||
INSERT INTO products (name, price) VALUES
|
||||
('Product 1', 10.00),
|
||||
('Product 2', 15.00),
|
||||
('Product 3', 20.00);
|
||||
```
|
||||
|
||||
### Temporary Table Usage
|
||||
```sql
|
||||
-- ✅ GOOD: Using temporary tables for complex operations
|
||||
CREATE TEMPORARY TABLE temp_calculations AS
|
||||
SELECT customer_id,
|
||||
SUM(total_amount) as total_spent,
|
||||
COUNT(*) as order_count
|
||||
FROM orders
|
||||
WHERE created_at >= '2024-01-01'
|
||||
GROUP BY customer_id;
|
||||
|
||||
-- Use the temp table for further calculations
|
||||
SELECT c.name, tc.total_spent, tc.order_count
|
||||
FROM temp_calculations tc
|
||||
JOIN customers c ON tc.customer_id = c.id
|
||||
WHERE tc.total_spent > 1000;
|
||||
```
|
||||
|
||||
## 🛠️ Index Management
|
||||
|
||||
### Index Design Principles
|
||||
```sql
|
||||
-- ✅ GOOD: Covering index design
|
||||
CREATE INDEX idx_orders_covering
|
||||
ON orders(customer_id, created_at)
|
||||
INCLUDE (total_amount, status); -- SQL Server syntax
|
||||
-- Or: CREATE INDEX idx_orders_covering ON orders(customer_id, created_at, total_amount, status); -- Other databases
|
||||
```
|
||||
|
||||
### Partial Index Strategy
|
||||
```sql
|
||||
-- ✅ GOOD: Partial indexes for specific conditions
|
||||
CREATE INDEX idx_orders_active
|
||||
ON orders(created_at)
|
||||
WHERE status IN ('pending', 'processing');
|
||||
```
|
||||
|
||||
## 📊 Performance Monitoring Queries
|
||||
|
||||
### Query Performance Analysis
|
||||
```sql
|
||||
-- Generic approach to identify slow queries
|
||||
-- (Specific syntax varies by database)
|
||||
|
||||
-- For MySQL:
|
||||
SELECT query_time, lock_time, rows_sent, rows_examined, sql_text
|
||||
FROM mysql.slow_log
|
||||
ORDER BY query_time DESC;
|
||||
|
||||
-- For PostgreSQL:
|
||||
SELECT query, calls, total_time, mean_time
|
||||
FROM pg_stat_statements
|
||||
ORDER BY total_time DESC;
|
||||
|
||||
-- For SQL Server:
|
||||
SELECT
|
||||
qs.total_elapsed_time/qs.execution_count as avg_elapsed_time,
|
||||
qs.execution_count,
|
||||
SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
|
||||
((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text)
|
||||
ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) as query_text
|
||||
FROM sys.dm_exec_query_stats qs
|
||||
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
|
||||
ORDER BY avg_elapsed_time DESC;
|
||||
```
|
||||
|
||||
## 🎯 Universal Optimization Checklist
|
||||
|
||||
### Query Structure
|
||||
- [ ] Avoiding SELECT * in production queries
|
||||
- [ ] Using appropriate JOIN types (INNER vs LEFT/RIGHT)
|
||||
- [ ] Filtering early in WHERE clauses
|
||||
- [ ] Using EXISTS instead of IN for subqueries when appropriate
|
||||
- [ ] Avoiding functions in WHERE clauses that prevent index usage
|
||||
|
||||
### Index Strategy
|
||||
- [ ] Creating indexes on frequently queried columns
|
||||
- [ ] Using composite indexes in the right column order
|
||||
- [ ] Avoiding over-indexing (impacts INSERT/UPDATE performance)
|
||||
- [ ] Using covering indexes where beneficial
|
||||
- [ ] Creating partial indexes for specific query patterns
|
||||
|
||||
### Data Types and Schema
|
||||
- [ ] Using appropriate data types for storage efficiency
|
||||
- [ ] Normalizing appropriately (3NF for OLTP, denormalized for OLAP)
|
||||
- [ ] Using constraints to help query optimizer
|
||||
- [ ] Partitioning large tables when appropriate
|
||||
|
||||
### Query Patterns
|
||||
- [ ] Using LIMIT/TOP for result set control
|
||||
- [ ] Implementing efficient pagination strategies
|
||||
- [ ] Using batch operations for bulk data changes
|
||||
- [ ] Avoiding N+1 query problems
|
||||
- [ ] Using prepared statements for repeated queries
|
||||
|
||||
### Performance Testing
|
||||
- [ ] Testing queries with realistic data volumes
|
||||
- [ ] Analyzing query execution plans
|
||||
- [ ] Monitoring query performance over time
|
||||
- [ ] Setting up alerts for slow queries
|
||||
- [ ] Regular index usage analysis
|
||||
|
||||
## 📝 Optimization Methodology
|
||||
|
||||
1. **Identify**: Use database-specific tools to find slow queries
|
||||
2. **Analyze**: Examine execution plans and identify bottlenecks
|
||||
3. **Optimize**: Apply appropriate optimization techniques
|
||||
4. **Test**: Verify performance improvements
|
||||
5. **Monitor**: Continuously track performance metrics
|
||||
6. **Iterate**: Regular performance review and optimization
|
||||
|
||||
Focus on measurable performance improvements and always test optimizations with realistic data volumes and query patterns.
|
||||
241
prompts/technology-stack-blueprint-generator.prompt.md
Normal file
241
prompts/technology-stack-blueprint-generator.prompt.md
Normal file
@ -0,0 +1,241 @@
|
||||
---
|
||||
description: 'Comprehensive technology stack blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks, programming languages, and implementation patterns across multiple platforms (.NET, Java, JavaScript, React, Python). Generates configurable blueprints with version information, licensing details, usage patterns, coding conventions, and visual diagrams. Provides implementation-ready templates and maintains architectural consistency for guided development.'
|
||||
---
|
||||
|
||||
# Comprehensive Technology Stack Blueprint Generator
|
||||
|
||||
## Configuration Variables
|
||||
${PROJECT_TYPE="Auto-detect|.NET|Java|JavaScript|React.js|React Native|Angular|Python|Other"} <!-- Primary technology -->
|
||||
${DEPTH_LEVEL="Basic|Standard|Comprehensive|Implementation-Ready"} <!-- Analysis depth -->
|
||||
${INCLUDE_VERSIONS=true|false} <!-- Include version information -->
|
||||
${INCLUDE_LICENSES=true|false} <!-- Include license information -->
|
||||
${INCLUDE_DIAGRAMS=true|false} <!-- Generate architecture diagrams -->
|
||||
${INCLUDE_USAGE_PATTERNS=true|false} <!-- Include code usage patterns -->
|
||||
${INCLUDE_CONVENTIONS=true|false} <!-- Document coding conventions -->
|
||||
${OUTPUT_FORMAT="Markdown|JSON|YAML|HTML"} <!-- Select output format -->
|
||||
${CATEGORIZATION="Technology Type|Layer|Purpose"} <!-- Organization method -->
|
||||
|
||||
## Generated Prompt
|
||||
|
||||
"Analyze the codebase and generate a ${DEPTH_LEVEL} technology stack blueprint that thoroughly documents technologies and implementation patterns to facilitate consistent code generation. Use the following approach:
|
||||
|
||||
### 1. Technology Identification Phase
|
||||
- ${PROJECT_TYPE == "Auto-detect" ? "Scan the codebase for project files, configuration files, and dependencies to determine all technology stacks in use" : "Focus on ${PROJECT_TYPE} technologies"}
|
||||
- Identify all programming languages by examining file extensions and content
|
||||
- Analyze configuration files (package.json, .csproj, pom.xml, etc.) to extract dependencies
|
||||
- Examine build scripts and pipeline definitions for tooling information
|
||||
- ${INCLUDE_VERSIONS ? "Extract precise version information from package files and configuration" : "Skip version details"}
|
||||
- ${INCLUDE_LICENSES ? "Document license information for all dependencies" : ""}
|
||||
|
||||
### 2. Core Technologies Analysis
|
||||
|
||||
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" ? "#### .NET Stack Analysis (if detected)
|
||||
- Target frameworks and language versions (detect from project files)
|
||||
- All NuGet package references with versions and purpose comments
|
||||
- Project structure and organization patterns
|
||||
- Configuration approach (appsettings.json, IOptions, etc.)
|
||||
- Authentication mechanisms (Identity, JWT, etc.)
|
||||
- API design patterns (REST, GraphQL, minimal APIs, etc.)
|
||||
- Data access approaches (EF Core, Dapper, etc.)
|
||||
- Dependency injection patterns
|
||||
- Middleware pipeline components" : ""}
|
||||
|
||||
${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect" ? "#### Java Stack Analysis (if detected)
|
||||
- JDK version and core frameworks
|
||||
- All Maven/Gradle dependencies with versions and purpose
|
||||
- Package structure organization
|
||||
- Spring Boot usage and configurations
|
||||
- Annotation patterns
|
||||
- Dependency injection approach
|
||||
- Data access technologies (JPA, JDBC, etc.)
|
||||
- API design (Spring MVC, JAX-RS, etc.)" : ""}
|
||||
|
||||
${PROJECT_TYPE == "JavaScript" || PROJECT_TYPE == "Auto-detect" ? "#### JavaScript Stack Analysis (if detected)
|
||||
- ECMAScript version and transpiler settings
|
||||
- All npm dependencies categorized by purpose
|
||||
- Module system (ESM, CommonJS)
|
||||
- Build tooling (webpack, Vite, etc.) with configuration
|
||||
- TypeScript usage and configuration
|
||||
- Testing frameworks and patterns" : ""}
|
||||
|
||||
${PROJECT_TYPE == "React.js" || PROJECT_TYPE == "Auto-detect" ? "#### React Analysis (if detected)
|
||||
- React version and key patterns (hooks vs class components)
|
||||
- State management approach (Context, Redux, Zustand, etc.)
|
||||
- Component library usage (Material-UI, Chakra, etc.)
|
||||
- Routing implementation
|
||||
- Form handling strategies
|
||||
- API integration patterns
|
||||
- Testing approach for components" : ""}
|
||||
|
||||
${PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect" ? "#### Python Analysis (if detected)
|
||||
- Python version and key language features used
|
||||
- Package dependencies and virtual environment setup
|
||||
- Web framework details (Django, Flask, FastAPI)
|
||||
- ORM usage patterns
|
||||
- Project structure organization
|
||||
- API design patterns" : ""}
|
||||
|
||||
### 3. Implementation Patterns & Conventions
|
||||
${INCLUDE_CONVENTIONS ?
|
||||
"Document coding conventions and patterns for each technology area:
|
||||
|
||||
#### Naming Conventions
|
||||
- Class/type naming patterns
|
||||
- Method/function naming patterns
|
||||
- Variable naming conventions
|
||||
- File naming and organization conventions
|
||||
- Interface/abstract class patterns
|
||||
|
||||
#### Code Organization
|
||||
- File structure and organization
|
||||
- Folder hierarchy patterns
|
||||
- Component/module boundaries
|
||||
- Code separation and responsibility patterns
|
||||
|
||||
#### Common Patterns
|
||||
- Error handling approaches
|
||||
- Logging patterns
|
||||
- Configuration access
|
||||
- Authentication/authorization implementation
|
||||
- Validation strategies
|
||||
- Testing patterns" : ""}
|
||||
|
||||
### 4. Usage Examples
|
||||
${INCLUDE_USAGE_PATTERNS ?
|
||||
"Extract representative code examples showing standard implementation patterns:
|
||||
|
||||
#### API Implementation Examples
|
||||
- Standard controller/endpoint implementation
|
||||
- Request DTO pattern
|
||||
- Response formatting
|
||||
- Validation approach
|
||||
- Error handling
|
||||
|
||||
#### Data Access Examples
|
||||
- Repository pattern implementation
|
||||
- Entity/model definitions
|
||||
- Query patterns
|
||||
- Transaction handling
|
||||
|
||||
#### Service Layer Examples
|
||||
- Service class implementation
|
||||
- Business logic organization
|
||||
- Cross-cutting concerns integration
|
||||
- Dependency injection usage
|
||||
|
||||
#### UI Component Examples (if applicable)
|
||||
- Component structure
|
||||
- State management pattern
|
||||
- Event handling
|
||||
- API integration pattern" : ""}
|
||||
|
||||
### 5. Technology Stack Map
|
||||
${DEPTH_LEVEL == "Comprehensive" || DEPTH_LEVEL == "Implementation-Ready" ?
|
||||
"Create a comprehensive technology map including:
|
||||
|
||||
#### Core Framework Usage
|
||||
- Primary frameworks and their specific usage in the project
|
||||
- Framework-specific configurations and customizations
|
||||
- Extension points and customizations
|
||||
|
||||
#### Integration Points
|
||||
- How different technology components integrate
|
||||
- Authentication flow between components
|
||||
- Data flow between frontend and backend
|
||||
- Third-party service integration patterns
|
||||
|
||||
#### Development Tooling
|
||||
- IDE settings and conventions
|
||||
- Code analysis tools
|
||||
- Linters and formatters with configuration
|
||||
- Build and deployment pipeline
|
||||
- Testing frameworks and approaches
|
||||
|
||||
#### Infrastructure
|
||||
- Deployment environment details
|
||||
- Container technologies
|
||||
- Cloud services utilized
|
||||
- Monitoring and logging infrastructure" : ""}
|
||||
|
||||
### 6. Technology-Specific Implementation Details
|
||||
|
||||
${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" ?
|
||||
"#### .NET Implementation Details (if detected)
|
||||
- **Dependency Injection Pattern**:
|
||||
- Service registration approach (Scoped/Singleton/Transient patterns)
|
||||
- Configuration binding patterns
|
||||
|
||||
- **Controller Patterns**:
|
||||
- Base controller usage
|
||||
- Action result types and patterns
|
||||
- Route attribute conventions
|
||||
- Filter usage (authorization, validation, etc.)
|
||||
|
||||
- **Data Access Patterns**:
|
||||
- ORM configuration and usage
|
||||
- Entity configuration approach
|
||||
- Relationship definitions
|
||||
- Query patterns and optimization approaches
|
||||
|
||||
- **API Design Patterns** (if used):
|
||||
- Endpoint organization
|
||||
- Parameter binding approaches
|
||||
- Response type handling
|
||||
|
||||
- **Language Features Used**:
|
||||
- Detect specific language features from code
|
||||
- Identify common patterns and idioms
|
||||
- Note any specific version-dependent features" : ""}
|
||||
|
||||
${PROJECT_TYPE == "React.js" || PROJECT_TYPE == "Auto-detect" ?
|
||||
"#### React Implementation Details (if detected)
|
||||
- **Component Structure**:
|
||||
- Function vs class components
|
||||
- Props interface definitions
|
||||
- Component composition patterns
|
||||
|
||||
- **Hook Usage Patterns**:
|
||||
- Custom hook implementation style
|
||||
- useState patterns
|
||||
- useEffect cleanup approaches
|
||||
- Context usage patterns
|
||||
|
||||
- **State Management**:
|
||||
- Local vs global state decisions
|
||||
- State management library patterns
|
||||
- Store configuration
|
||||
- Selector patterns
|
||||
|
||||
- **Styling Approach**:
|
||||
- CSS methodology (CSS modules, styled-components, etc.)
|
||||
- Theme implementation
|
||||
- Responsive design patterns" : ""}
|
||||
|
||||
### 7. Blueprint for New Code Implementation
|
||||
${DEPTH_LEVEL == "Implementation-Ready" ?
|
||||
"Based on the analysis, provide a detailed blueprint for implementing new features:
|
||||
|
||||
- **File/Class Templates**: Standard structure for common component types
|
||||
- **Code Snippets**: Ready-to-use code patterns for common operations
|
||||
- **Implementation Checklist**: Standard steps for implementing features end-to-end
|
||||
- **Integration Points**: How to connect new code with existing systems
|
||||
- **Testing Requirements**: Standard test patterns for different component types
|
||||
- **Documentation Requirements**: Standard doc patterns for new features" : ""}
|
||||
|
||||
${INCLUDE_DIAGRAMS ?
|
||||
"### 8. Technology Relationship Diagrams
|
||||
- **Stack Diagram**: Visual representation of the complete technology stack
|
||||
- **Dependency Flow**: How different technologies interact
|
||||
- **Component Relationships**: How major components depend on each other
|
||||
- **Data Flow**: How data flows through the technology stack" : ""}
|
||||
|
||||
### ${INCLUDE_DIAGRAMS ? "9" : "8"}. Technology Decision Context
|
||||
- Document apparent reasons for technology choices
|
||||
- Note any legacy or deprecated technologies marked for replacement
|
||||
- Identify technology constraints and boundaries
|
||||
- Document technology upgrade paths and compatibility considerations
|
||||
|
||||
Format the output as ${OUTPUT_FORMAT} and categorize technologies by ${CATEGORIZATION}.
|
||||
|
||||
Save the output as 'Technology_Stack_Blueprint.${OUTPUT_FORMAT == "Markdown" ? "md" : OUTPUT_FORMAT.toLowerCase()}'
|
||||
"
|
||||
@ -61,6 +61,10 @@ All implementation plans must strictly adhere to the following template. Each se
|
||||
- Tables must include all required columns
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
## Status
|
||||
|
||||
The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section.
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Implementation Plan's Goal]
|
||||
@ -68,11 +72,14 @@ version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user