Add technology-agnostic blueprint generators for comprehensive project documentation (#113)
* add 7 technology-agnostic blueprint generators for project documentation that helps GitHub Copilot to generate instructions that respect project-specific conventions - Add architecture-blueprint-generator for documenting system design patterns - Add code-exemplars-blueprint-generator for identifying quality code standards - Add copilot-instructions-blueprint-generator for creating AI guidance files - Add folder-structure-blueprint-generator for documenting project organization - Add project-workflow-blueprint-generator for end-to-end process documentation - Add readme-blueprint-generator for comprehensive repository documentation - Add technology-stack-blueprint-generator for tech stack analysis * Update README.md * Update architecture-blueprint-generator.prompt.md Fixed : The description field in the front matter should be wrapped in single quotes, not double quotes, according to the coding guidelines. * Update folder-structure-blueprint-generator.prompt.md Fixed : The description field in the front matter should be wrapped in single quotes, not double quotes, according to the coding guidelines. * Update project-workflow-analysis-blueprint-generator.prompt.md Fixed : The description field in the front matter should be wrapped in single quotes, not double quotes, according to the coding guidelines. * Update readme-blueprint-generator.prompt.md Fixed : The description field in the front matter should be wrapped in single quotes, not double quotes, according to the coding guidelines. * update readme and fixed copilot suggestions --------- Co-authored-by: Ajay Singh <ajay.singh@compunnel.com>
This commit is contained in:
zooav
GitHub
parent
2587ec19de
commit
d4a0af0c7b
@ -81,10 +81,13 @@ 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) |
|
||||
@ -106,6 +109,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) |
|
||||
@ -116,6 +120,10 @@ 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) |
|
||||
|
||||
| [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) |
|
||||
|
||||
| [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) |
|
||||
| [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) |
|
||||
@ -123,6 +131,7 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [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) |
|
||||
|
||||
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.
|
||||
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.
|
||||
"
|
||||
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.
|
||||
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()}'
|
||||
"
|
||||
Loading…
x
Reference in New Issue
Block a user