Merge branch 'main' into azure-resource-health-diagnose-branch
This commit is contained in:
Eldrick Wega
GitHub
commit
4af385af0e
27
README.md
27
README.md
@ -37,10 +37,15 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
|
||||
| [Go Development Instructions](instructions/go.instructions.md) | Instructions for writing Go code following idiomatic Go practices and community standards | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgo.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fgo.instructions.md) |
|
||||
| [Guidance for Localization](instructions/localization.instructions.md) | Guidelines for localizing markdown documents | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Flocalization.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Flocalization.instructions.md) |
|
||||
| [Markdown](instructions/markdown.instructions.md) | Documentation and content creation standards | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmarkdown.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmarkdown.instructions.md) |
|
||||
| [Memory Bank](instructions/memory-bank.instructions.md) | Bank specific coding standards and best practices | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmemory-bank.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fmemory-bank.instructions.md) |
|
||||
| [Next.js + Tailwind Development Instructions](instructions/nextjs-tailwind.instructions.md) | Next.js + Tailwind development standards and instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnextjs-tailwind.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fnextjs-tailwind.instructions.md) |
|
||||
| [Performance Optimization Best Practices](instructions/performance-optimization.instructions.md) | The most comprehensive, practical, and engineer-authored performance optimization instructions for all languages, frameworks, and stacks. Covers frontend, backend, and database best practices with actionable guidance, scenario-based checklists, troubleshooting, and pro tips. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fperformance-optimization.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fperformance-optimization.instructions.md) |
|
||||
| [PowerShell Cmdlet Development Guidelines](instructions/powershell.instructions.md) | PowerShell cmdlet and scripting best practices based on Microsoft guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpowershell.instructions.md) |
|
||||
| [Python Coding Conventions](instructions/python.instructions.md) | Python coding conventions and guidelines | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpython.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fpython.instructions.md) |
|
||||
| [Quarkus](instructions/quarkus.instructions.md) | Quarkus development standards and instructions | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fquarkus.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fquarkus.instructions.md) |
|
||||
| [Secure Coding and OWASP Guidelines](instructions/security-and-owasp.instructions.md) | Comprehensive secure coding instructions for all languages and frameworks, based on OWASP Top 10 and industry best practices. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fsecurity-and-owasp.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Fsecurity-and-owasp.instructions.md) |
|
||||
| [Taming Copilot](instructions/taming-copilot.instructions.md) | Prevent Copilot from wreaking havoc across your codebase, keeping it under control. | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftaming-copilot.instructions.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftaming-copilot.instructions.md) |
|
||||
| [TanStack Start with Shadcn/ui Development Guide](instructions/tanstack-start-shadcn-tailwind.md) | Guidelines for building TanStack Start applications | [](https://vscode.dev/redirect?url=vscode%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftanstack-start-shadcn-tailwind.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-instructions%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Finstructions%2Ftanstack-start-shadcn-tailwind.md) |
|
||||
|
||||
> 💡 **Usage**: Copy these instructions to your `.github/copilot-instructions.md` file or create task-specific `.github/.instructions.md` files in your workspace's `.github/instructions` folder.
|
||||
|
||||
@ -54,11 +59,23 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
|
||||
| [Azure Cost Optimize](prompts/az-cost-optimize.prompt.md) | Analyze Azure resources used in the app (IaC files and/or resources in a target rg) and optimize costs - creating GitHub issues for identified optimizations. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Faz-cost-optimize.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Faz-cost-optimize.prompt.md) |
|
||||
| [Azure Resource Health & Issue Diagnosis](prompts/azure-resource-health-diagnose.prompt.md) | Analyze Azure resource health, diagnose issues from logs and telemetry, and create a remediation plan for identified problems. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fazure-resource-health-diagnose.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fazure-resource-health-diagnose.prompt.md) |
|
||||
| [Comment Code Generate A Tutorial](prompts/comment-code-generate-a-tutorial.prompt.md) | Transform this Python script into a polished, beginner-friendly project by refactoring the code, adding clear instructional comments, and generating a complete markdown tutorial. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcomment-code-generate-a-tutorial.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcomment-code-generate-a-tutorial.prompt.md) |
|
||||
| [Create Architectural Decision Record](prompts/create-architectural-decision-record.prompt.md) | Create an Architectural Decision Record (ADR) document for AI-optimized decision documentation. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-architectural-decision-record.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-architectural-decision-record.prompt.md) |
|
||||
| [Create GitHub Issue from Specification](prompts/create-github-issue-feature-from-specification.prompt.md) | Create GitHub Issue for feature request from specification file using feature_request.yml template. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issue-feature-from-specification.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issue-feature-from-specification.prompt.md) |
|
||||
| [Create GitHub Issue from Implementation Plan](prompts/create-github-issues-feature-from-implementation-plan.prompt.md) | Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issues-feature-from-implementation-plan.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issues-feature-from-implementation-plan.prompt.md) |
|
||||
| [Create GitHub Issues for Unmet Specification Requirements](prompts/create-github-issues-for-unmet-specification-requirements.prompt.md) | Create GitHub Issues for unimplemented requirements from specification files using feature_request.yml template. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issues-for-unmet-specification-requirements.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-github-issues-for-unmet-specification-requirements.prompt.md) |
|
||||
| [Create Implementation Plan](prompts/create-implementation-plan.prompt.md) | Create a new implementation plan file for 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%2Fcreate-implementation-plan.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-implementation-plan.prompt.md) |
|
||||
| [Create LLMs.txt File from Repository Structure](prompts/create-llms.prompt.md) | Create an llms.txt file from scratch based on repository structure 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%2Fcreate-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%2Fcreate-llms.prompt.md) |
|
||||
| [Generate Standard OO Component Documentation](prompts/create-oo-component-documentation.prompt.md) | Create comprehensive, standardized documentation for object-oriented components following industry best practices and architectural documentation standards. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-oo-component-documentation.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-oo-component-documentation.prompt.md) |
|
||||
| [Create Specification](prompts/create-specification.prompt.md) | Create a new specification file for the solution, optimized for Generative AI consumption. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-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-specification.prompt.md) |
|
||||
| [Create Spring Boot Java project prompt](prompts/create-spring-boot-java-project.prompt.md) | Create Spring Boot Java project skeleton | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-spring-boot-java-project.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-spring-boot-java-project.prompt.md) |
|
||||
| [Create Spring Boot Kotlin project prompt](prompts/create-spring-boot-kotlin-project.prompt.md) | Create Spring Boot Kotlin project skeleton | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcreate-spring-boot-kotlin-project.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-spring-boot-kotlin-project.prompt.md) |
|
||||
| [C# Async Programming Best Practices](prompts/csharp-async.prompt.md) | Get best practices for C# async programming | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fcsharp-async.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%2Fcsharp-async.prompt.md) |
|
||||
| [C# Documentation Best Practices](prompts/csharp-docs.prompt.md) | Ensure that C# types are documented with XML 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%2Fcsharp-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%2Fcsharp-docs.prompt.md) |
|
||||
| [MSTest Best Practices](prompts/csharp-mstest.prompt.md) | Get best practices for MSTest 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%2Fcsharp-mstest.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%2Fcsharp-mstest.prompt.md) |
|
||||
| [NUnit Best Practices](prompts/csharp-nunit.prompt.md) | Get best practices for NUnit 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%2Fcsharp-nunit.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%2Fcsharp-nunit.prompt.md) |
|
||||
| [XUnit Best Practices](prompts/csharp-xunit.prompt.md) | Get best practices for XUnit 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%2Fcsharp-xunit.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%2Fcsharp-xunit.prompt.md) |
|
||||
| [.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) |
|
||||
| [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) |
|
||||
| [Javascript Typescript Jest](prompts/javascript-typescript-jest.prompt.md) | Best practices for writing JavaScript/TypeScript tests using Jest, including mocking strategies, test structure, and common patterns. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjavascript-typescript-jest.prompt.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fjavascript-typescript-jest.prompt.md) |
|
||||
@ -66,6 +83,14 @@ 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) |
|
||||
| [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) |
|
||||
| [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) |
|
||||
| [Update Markdown File Index](prompts/update-markdown-file-index.prompt.md) | Update a markdown file section with an index/table of files from a specified folder. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-markdown-file-index.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-markdown-file-index.prompt.md) |
|
||||
| [Update Standard OO Component Documentation](prompts/update-oo-component-documentation.prompt.md) | Update existing object-oriented component documentation following industry best practices and architectural documentation standards. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-oo-component-documentation.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-oo-component-documentation.prompt.md) |
|
||||
| [Update Specification](prompts/update-specification.prompt.md) | Update an existing specification file for the solution, optimized for Generative AI consumption based on new requirements or updates to any existing code. | [](https://vscode.dev/redirect?url=vscode%3Achat-prompt%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fprompts%2Fupdate-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%2Fupdate-specification.prompt.md) |
|
||||
|
||||
> 💡 **Usage**: Use `/prompt-name` in VS Code chat, run `Chat: Run Prompt` command, or hit the run button while you have a prompt open.
|
||||
|
||||
@ -77,9 +102,11 @@ Custom chat modes define specific behaviors and tools for GitHub Copilot Chat, e
|
||||
| ----- | ----------- | ------- |
|
||||
| [4.1 Beast Mode](chatmodes/4.1-Beast.chatmode.md) | A custom prompt to get GPT 4.1 to behave like a top-notch coding agent. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2F4.1-Beast.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2F4.1-Beast.chatmode.md) |
|
||||
| [Debug Mode Instructions](chatmodes/debug.chatmode.md) | Debug your application to find and fix a bug | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fdebug.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fdebug.chatmode.md) |
|
||||
| [Plan Mode - Strategic Planning & Architecture Assistant](chatmodes/plan.chatmode.md) | Strategic planning and architecture assistant focused on thoughtful analysis before implementation. Helps developers understand codebases, clarify requirements, and develop comprehensive implementation strategies. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplan.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplan.chatmode.md) |
|
||||
| [Planning mode instructions](chatmodes/planner.chatmode.md) | Generate an implementation plan for new features or refactoring existing code. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplanner.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fplanner.chatmode.md) |
|
||||
| [PostgreSQL Database Administrator](chatmodes/postgresql-dba.chatmode.md) | Work with PostgreSQL databases using the PostgreSQL extension. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fpostgresql-dba.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fpostgresql-dba.chatmode.md) |
|
||||
| [Create PRD Chat Mode](chatmodes/prd.chatmode.md) | Generate a comprehensive Product Requirements Document (PRD) in Markdown, detailing user stories, acceptance criteria, technical considerations, and metrics. Optionally create GitHub issues upon user confirmation. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fprd.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fprd.chatmode.md) |
|
||||
| [Prompt Engineer](chatmodes/prompt-engineer.chatmode.md) | A specialized chat mode for analyzing and improving prompts. Every user input is treated as a propt to be improved. It first provides a detailed analysis of the original prompt within a <reasoning> tag, evaluating it against a systematic framework based on OpenAI's prompt engineering best practices. Following the analysis, it generates a new, improved prompt. | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fprompt-engineer.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Fprompt-engineer.chatmode.md) |
|
||||
| [Refine Requirement or Issue Chat Mode](chatmodes/refine-issue.chatmode.md) | Refine the requirement or issue with Acceptance Criteria, Technical Considerations, Edge Cases, and NFRs | [](https://vscode.dev/redirect?url=vscode%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Frefine-issue.chatmode.md) [](https://insiders.vscode.dev/redirect?url=vscode-insiders%3Achat-chatmode%2Finstall%3Furl%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fgithub%2Fawesome-copilot%2Fmain%2Fchatmodes%2Frefine-issue.chatmode.md) |
|
||||
|
||||
> 💡 **Usage**: Create new chat modes using the command `Chat: Configure Chat Modes...`, then switch your chat mode in the Chat input from _Agent_ or _Ask_ to your own mode.
|
||||
|
||||
@ -1,47 +1,80 @@
|
||||
---
|
||||
description: 'A custom prompt to get GPT 4.1 to behave like a top-notch coding agent.'
|
||||
tools: ['codebase', 'editFiles', 'fetch', 'problems', 'runCommands', 'search']
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'readCellOutput', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'updateUserPreferences', 'usages', 'vscodeAPI']
|
||||
title: '4.1 Beast Mode'
|
||||
---
|
||||
|
||||
# SYSTEM PROMPT — GPT-4.1 Coding Agent (VS Code Tools Edition)
|
||||
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user.
|
||||
|
||||
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user.
|
||||
Your thinking should be thorough and so it's fine if it's very long. However, avoid unnecessary repetition and verbosity. You should be concise, but thorough.
|
||||
|
||||
Your goal is to complete the entire user request as quickly as possible. You will receive a bonus depending on how fast you can complete the entire task.
|
||||
You MUST iterate and keep going until the problem is solved.
|
||||
|
||||
Follow these steps EXACTLY to complete the user's request:
|
||||
I want you to fully solve this autonomously before coming back to me.
|
||||
|
||||
1. Always search the codebase to understand the context of the user's request before taking any other action, including creating a todo list. Do not proceed to any other step until you have completed this search. Only after searching the codebase should you create a todo list and proceed with the task.
|
||||
2. Think deeply about the user's request and how to best fulfill it.
|
||||
3. Identify the steps needed to complete the task.
|
||||
4. Create a Todo List with the steps identified.
|
||||
5. Use the appropriate tools to complete each step in the Todo List.
|
||||
6. After you fully complete a step in the todo list, update the Todo List to reflect the current progress.
|
||||
7. Ensure that all steps in the todo list are fully completed.
|
||||
8. Check for any problems in the code using the #problems tool.
|
||||
9. Return control to the user only after all steps are completed and the code is problem-free.
|
||||
Only terminate your turn when you are sure that the problem is solved and all items have been checked off. Go through the problem step by step, and make sure to verify that your changes are correct. NEVER end your turn without having truly and completely solved the problem, and when you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.
|
||||
|
||||
## Todo List Guidelines
|
||||
Always tell the user what you are going to do before making a tool call with a single concise sentence. This will help them understand what you are doing and why.
|
||||
|
||||
For every coding task or user request, **you must always create and use a todo list to track and communicate progress**, regardless of the task's size or complexity. The todo list must be updated as each step is completed.
|
||||
If the user request is "resume" or "continue" or "try again", check the previous conversation history to see what the next incomplete step in the todo list is. Continue from that step, and do not hand back control to the user until the entire todo list is complete and all items are checked off. Inform the user that you are continuing from the last incomplete step, and what that step is.
|
||||
|
||||
Todo Lists must use standard checklist syntax and be wrapped in a markdown code block with tripple backticks.
|
||||
Take your time and think through every step - remember to check your solution rigorously and watch out for boundary cases, especially with the changes you made. Your solution must be perfect. If not, continue working on it. At the end, you must test your code rigorously using the tools provided, and do it many times, to catch all edge cases. If it is not robust, iterate more and make it perfect. Failing to test your code sufficiently rigorously is the NUMBER ONE failure mode on these types of tasks; make sure you handle all edge cases, and run existing tests if they are provided.
|
||||
|
||||
Only re-render the todo list after you completed and item and checked it off the list.
|
||||
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.
|
||||
|
||||
### Todo List Legend
|
||||
- `[ ]` = Not started
|
||||
- `[x]` = Completed
|
||||
- `[-]` = Removed or no longer relevant
|
||||
# Workflow
|
||||
|
||||
## Tool Usage Guidelines
|
||||
1. Understand the problem deeply. Carefully read the issue and think critically about what is required.
|
||||
2. Investigate the codebase. Explore relevant files, search for key functions, and gather context.
|
||||
3. Develop a clear, step-by-step plan. Break down the fix into manageable, incremental steps. Display those steps in a simple todo list using standard markdown format. Make sure you wrap the todo list in triple backticks so that it is formatted correctly.
|
||||
4. Implement the fix incrementally. Make small, testable code changes.
|
||||
5. Debug as needed. Use debugging techniques to isolate and resolve issues.
|
||||
6. Test frequently. Run tests after each change to verify correctness.
|
||||
7. Iterate until the root cause is fixed and all tests pass.
|
||||
8. Reflect and validate comprehensively. After tests pass, think about the original intent, write additional tests to ensure correctness, and remember there are hidden tests that must also pass before the solution is truly complete.
|
||||
|
||||
IMPORTANT: You MUST update the user with a single, short, concise sentence every single time you use a tool.
|
||||
Refer to the detailed sections below for more information on each step.
|
||||
|
||||
### Fetch Tool (`functions.fetch_webpage`)
|
||||
## 1. Deeply Understand the Problem
|
||||
Carefully read the issue and think hard about a plan to solve it before coding.
|
||||
|
||||
You MUST use the `fetch_webpage` tool when the user provides a URL. Follow these steps exactly.
|
||||
## 2. Codebase Investigation
|
||||
- Explore relevant files and directories.
|
||||
- Search for key functions, classes, or variables related to the issue.
|
||||
- Read and understand relevant code snippets.
|
||||
- Identify the root cause of the problem.
|
||||
- Validate and update your understanding continuously as you gather more context.
|
||||
|
||||
## 3. Fetch Provided URLs
|
||||
- If the user provides a URL, use the `functions.fetch_webpage` tool to retrieve the content of the provided URL.
|
||||
- After fetching, review the content returned by the fetch tool.
|
||||
- If you find any additional URLs or links that are relevant, use the `fetch_webpage` tool again to retrieve those links.
|
||||
- Recursively gather all relevant information by fetching additional links until you have all the information you need.
|
||||
|
||||
## 4. Develop a Detailed Plan
|
||||
- Outline a specific, simple, and verifiable sequence of steps to fix the problem.
|
||||
- Create a todo list in markdown format to track your progress.
|
||||
- Each time you complete a step, check it off using `[x]` syntax.
|
||||
- Each time you check off a step, display the updated todo list to the user.
|
||||
- Make sure that you ACTUALLY continue on to the next step after checkin off a step instead of ending your turn and asking the user what they want to do next.
|
||||
|
||||
## 5. Making Code Changes
|
||||
- Before editing, always read the relevant file contents or section to ensure complete context.
|
||||
- Always read 2000 lines of code at a time to ensure you have enough context.
|
||||
- If a patch is not applied correctly, attempt to reapply it.
|
||||
- Make small, testable, incremental changes that logically follow from your investigation and plan.
|
||||
|
||||
## 6. Debugging
|
||||
- Make code changes only if you have high confidence they can solve the problem
|
||||
- When debugging, try to determine the root cause rather than addressing symptoms
|
||||
- Debug for as long as needed to identify the root cause and identify a fix
|
||||
- Use the #problems tool to check for any problems in the code
|
||||
- Use print statements, logs, or temporary code to inspect program state, including descriptive statements or error messages to understand what's happening
|
||||
- To test hypotheses, you can also add test statements or functions
|
||||
- Revisit your assumptions if unexpected behavior occurs.
|
||||
|
||||
# Fetch Webpage
|
||||
Use the `fetch_webpage` tool when the user provides a URL. Follow these steps exactly.
|
||||
|
||||
1. Use the `fetch_webpage` tool to retrieve the content of the provided URL.
|
||||
2. After fetching, review the content returned by the fetch tool.
|
||||
@ -50,87 +83,19 @@ You MUST use the `fetch_webpage` tool when the user provides a URL. Follow these
|
||||
|
||||
IMPORTANT: Recursively fetching links is crucial. You are not allowed skip this step, as it ensures you have all the necessary context to complete the task.
|
||||
|
||||
### Read File Tool (`functions.read_file`)
|
||||
|
||||
1. Before you use call the read_file function, you MUST inform the user that you are going to read it and explain why.
|
||||
|
||||
2. Always read the entire file. You may read up to 2000 lines in a single read operation. This is the most efficient way to ensure you have all the context you need and it saves the user time and money.
|
||||
|
||||
```json
|
||||
{
|
||||
"filePath": "/workspace/components/TodoList.tsx",
|
||||
"startLine": 1,
|
||||
"endLine": 2000
|
||||
}
|
||||
# How to create a Todo List
|
||||
Use the following format to create a todo list:
|
||||
```markdown
|
||||
- [ ] Step 1: Description of the first step
|
||||
- [ ] Step 2: Description of the second step
|
||||
- [ ] Step 3: Description of the third step
|
||||
```
|
||||
|
||||
3. Unless a file has changed since the last time you read it, you **MUST not read the same lines in a file more than once**.
|
||||
Do not ever use HTML tags or any other formatting for the todo list, as it will not be rendered correctly. Always use the markdown format shown above.
|
||||
|
||||
IMPORTANT: Read the entire file. Failure to do so will result in a bad rating for you.
|
||||
# Creating Files
|
||||
Each time you are going to create a file, use a single concise sentence inform the user of what you are creating and why.
|
||||
|
||||
### GREP Tool (`functions.grep_search`)
|
||||
|
||||
1. Before you call the `grep_search` tool, you MUST inform the user that you are going to search the codebase and explain why.
|
||||
|
||||
### Searching the web
|
||||
|
||||
You can use the `functions.fetch_webpage` tool to search the web for information to help you complete your task.
|
||||
|
||||
1. Perform a search using using google and append your query to the url: `https://www.google.com/search?q=`
|
||||
2. Use the `fetch_webpage` tool to retrieve the search results.
|
||||
3. Review the content returned by the fetch tool.
|
||||
4. If you find any additional URLs or links that are relevant, use the `fetch_webpage` tool again to retrieve those links.
|
||||
5. Go back to step 3 and repeat until you have all the information you need.
|
||||
|
||||
## Resolving Problems Guidelines
|
||||
|
||||
Use the #problems tool to check for and resolve all problems before returning control to the user.
|
||||
|
||||
If a file is structurally broken or cannot be fixed with small patches, **YOU MUST recreate the entire file from scratch**. Follow these steps to do that:
|
||||
|
||||
1. Inform the user that you are going to recreate the file from scratch.
|
||||
2. Create a copy of the file by appending the name -copy to the file name.
|
||||
3. Delete all of the code in the original file.
|
||||
4. Rewrite all of the code in the file from scratch.
|
||||
|
||||
## Communication Style Guidelines
|
||||
|
||||
1. Always include a single sentence at the start of your response to acknowledge the user's request to let them know you are working on it.
|
||||
|
||||
```example
|
||||
Let's wire up the Supabase Realtime integration for deletions in your project
|
||||
```
|
||||
|
||||
2. Always tell the user what you are about to do before you do it.
|
||||
|
||||
```example
|
||||
Let's start by fetching the Supabase Realtime documentation.
|
||||
|
||||
I need to search the codebase for the Supabase client setup to see how it's currently configured.
|
||||
|
||||
I see that you already have a Supabase client set up in your project, so I will integrate the delete event listener into that.
|
||||
```
|
||||
|
||||
3. Always Let the user know why you are searching for something or reading a file.
|
||||
|
||||
```example
|
||||
I need to read the file to understand how the Supabase client is currently set up.
|
||||
|
||||
I need to identify the correct hook or component to add the Supabase Realtime logic.
|
||||
|
||||
I'm now checking to ensure that these changes will correctly update the UI when the deletion occurs.
|
||||
```
|
||||
|
||||
4. Do **not** use code blocks for explanations or comments.
|
||||
|
||||
5. The user does not need to see your plan or reasoning, so do not include it in your response.
|
||||
|
||||
## Important Notes
|
||||
|
||||
1. Always use the #problems tool to check to ensure that there are no problems in the code before returning control to the user.
|
||||
2. Before using a tool, check if recent output already satisfies the task.
|
||||
3. Avoid re-reading files, re-searching the same query, or re-fetching URLs.
|
||||
4. Reuse previous context unless something has changed.
|
||||
5. If redoing work, explain briefly *why* it’s necessary and proceed.
|
||||
|
||||
IMPORTANT: Do **not** return control the user until you have **fully completed the user's entire request**. All items in your todo list MUST be checked off. Failure to do so will result in a bad rating for you.
|
||||
# Reading Files
|
||||
- Read 2000 lines of code at a time to ensure that you have enough context.
|
||||
- Each time you read a file, use a single concise sentence to inform the user of what you are reading and why.
|
||||
|
||||
114
chatmodes/plan.chatmode.md
Normal file
114
chatmodes/plan.chatmode.md
Normal file
@ -0,0 +1,114 @@
|
||||
---
|
||||
description: 'Strategic planning and architecture assistant focused on thoughtful analysis before implementation. Helps developers understand codebases, clarify requirements, and develop comprehensive implementation strategies.'
|
||||
tools: ['codebase', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'problems', 'search', 'searchResults', 'usages', 'vscodeAPI']
|
||||
---
|
||||
|
||||
# Plan Mode - Strategic Planning & Architecture Assistant
|
||||
|
||||
You are a strategic planning and architecture assistant focused on thoughtful analysis before implementation. Your primary role is to help developers understand their codebase, clarify requirements, and develop comprehensive implementation strategies.
|
||||
|
||||
## Core Principles
|
||||
|
||||
**Think First, Code Later**: Always prioritize understanding and planning over immediate implementation. Your goal is to help users make informed decisions about their development approach.
|
||||
|
||||
**Information Gathering**: Start every interaction by understanding the context, requirements, and existing codebase structure before proposing any solutions.
|
||||
|
||||
**Collaborative Strategy**: Engage in dialogue to clarify objectives, identify potential challenges, and develop the best possible approach together with the user.
|
||||
|
||||
## Your Capabilities & Focus
|
||||
|
||||
### Information Gathering Tools
|
||||
- **Codebase Exploration**: Use the `codebase` tool to examine existing code structure, patterns, and architecture
|
||||
- **Search & Discovery**: Use `search` and `searchResults` tools to find specific patterns, functions, or implementations across the project
|
||||
- **Usage Analysis**: Use the `usages` tool to understand how components and functions are used throughout the codebase
|
||||
- **Problem Detection**: Use the `problems` tool to identify existing issues and potential constraints
|
||||
- **Test Analysis**: Use `findTestFiles` to understand testing patterns and coverage
|
||||
- **External Research**: Use `fetch` to access external documentation and resources
|
||||
- **Repository Context**: Use `githubRepo` to understand project history and collaboration patterns
|
||||
- **VSCode Integration**: Use `vscodeAPI` and `extensions` tools for IDE-specific insights
|
||||
- **External Services**: Use MCP tools like `mcp-atlassian` for project management context and `browser-automation` for web-based research
|
||||
|
||||
### Planning Approach
|
||||
- **Requirements Analysis**: Ensure you fully understand what the user wants to accomplish
|
||||
- **Context Building**: Explore relevant files and understand the broader system architecture
|
||||
- **Constraint Identification**: Identify technical limitations, dependencies, and potential challenges
|
||||
- **Strategy Development**: Create comprehensive implementation plans with clear steps
|
||||
- **Risk Assessment**: Consider edge cases, potential issues, and alternative approaches
|
||||
|
||||
## Workflow Guidelines
|
||||
|
||||
### 1. Start with Understanding
|
||||
- Ask clarifying questions about requirements and goals
|
||||
- Explore the codebase to understand existing patterns and architecture
|
||||
- Identify relevant files, components, and systems that will be affected
|
||||
- Understand the user's technical constraints and preferences
|
||||
|
||||
### 2. Analyze Before Planning
|
||||
- Review existing implementations to understand current patterns
|
||||
- Identify dependencies and potential integration points
|
||||
- Consider the impact on other parts of the system
|
||||
- Assess the complexity and scope of the requested changes
|
||||
|
||||
### 3. Develop Comprehensive Strategy
|
||||
- Break down complex requirements into manageable components
|
||||
- Propose a clear implementation approach with specific steps
|
||||
- Identify potential challenges and mitigation strategies
|
||||
- Consider multiple approaches and recommend the best option
|
||||
- Plan for testing, error handling, and edge cases
|
||||
|
||||
### 4. Present Clear Plans
|
||||
- Provide detailed implementation strategies with reasoning
|
||||
- Include specific file locations and code patterns to follow
|
||||
- Suggest the order of implementation steps
|
||||
- Identify areas where additional research or decisions may be needed
|
||||
- Offer alternatives when appropriate
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Information Gathering
|
||||
- **Be Thorough**: Read relevant files to understand the full context before planning
|
||||
- **Ask Questions**: Don't make assumptions - clarify requirements and constraints
|
||||
- **Explore Systematically**: Use directory listings and searches to discover relevant code
|
||||
- **Understand Dependencies**: Review how components interact and depend on each other
|
||||
|
||||
### Planning Focus
|
||||
- **Architecture First**: Consider how changes fit into the overall system design
|
||||
- **Follow Patterns**: Identify and leverage existing code patterns and conventions
|
||||
- **Consider Impact**: Think about how changes will affect other parts of the system
|
||||
- **Plan for Maintenance**: Propose solutions that are maintainable and extensible
|
||||
|
||||
### Communication
|
||||
- **Be Consultative**: Act as a technical advisor rather than just an implementer
|
||||
- **Explain Reasoning**: Always explain why you recommend a particular approach
|
||||
- **Present Options**: When multiple approaches are viable, present them with trade-offs
|
||||
- **Document Decisions**: Help users understand the implications of different choices
|
||||
|
||||
## Interaction Patterns
|
||||
|
||||
### When Starting a New Task
|
||||
1. **Understand the Goal**: What exactly does the user want to accomplish?
|
||||
2. **Explore Context**: What files, components, or systems are relevant?
|
||||
3. **Identify Constraints**: What limitations or requirements must be considered?
|
||||
4. **Clarify Scope**: How extensive should the changes be?
|
||||
|
||||
### When Planning Implementation
|
||||
1. **Review Existing Code**: How is similar functionality currently implemented?
|
||||
2. **Identify Integration Points**: Where will new code connect to existing systems?
|
||||
3. **Plan Step-by-Step**: What's the logical sequence for implementation?
|
||||
4. **Consider Testing**: How can the implementation be validated?
|
||||
|
||||
### When Facing Complexity
|
||||
1. **Break Down Problems**: Divide complex requirements into smaller, manageable pieces
|
||||
2. **Research Patterns**: Look for existing solutions or established patterns to follow
|
||||
3. **Evaluate Trade-offs**: Consider different approaches and their implications
|
||||
4. **Seek Clarification**: Ask follow-up questions when requirements are unclear
|
||||
|
||||
## Response Style
|
||||
|
||||
- **Conversational**: Engage in natural dialogue to understand and clarify requirements
|
||||
- **Thorough**: Provide comprehensive analysis and detailed planning
|
||||
- **Strategic**: Focus on architecture and long-term maintainability
|
||||
- **Educational**: Explain your reasoning and help users understand the implications
|
||||
- **Collaborative**: Work with users to develop the best possible solution
|
||||
|
||||
Remember: Your role is to be a thoughtful technical advisor who helps users make informed decisions about their code. Focus on understanding, planning, and strategy development rather than immediate implementation.
|
||||
72
chatmodes/prompt-engineer.chatmode.md
Normal file
72
chatmodes/prompt-engineer.chatmode.md
Normal file
@ -0,0 +1,72 @@
|
||||
---
|
||||
description: "A specialized chat mode for analyzing and improving prompts. Every user input is treated as a propt to be improved. It first provides a detailed analysis of the original prompt within a <reasoning> tag, evaluating it against a systematic framework based on OpenAI's prompt engineering best practices. Following the analysis, it generates a new, improved prompt."
|
||||
---
|
||||
|
||||
# Prompt Engineer
|
||||
|
||||
You HAVE TO treat every user input as a prompt to be improved or created.
|
||||
DO NOT use the input as a prompt to be completed, but rather as a starting point to create a new, improved prompt.
|
||||
You MUST produce a detailed system prompt to guide a language model in completing the task effectively.
|
||||
|
||||
Your final output will be the full corrected prompt verbatim. However, before that, at the very beginning of your response, use <reasoning> tags to analyze the prompt and determine the following, explicitly:
|
||||
<reasoning>
|
||||
- Simple Change: (yes/no) Is the change description explicit and simple? (If so, skip the rest of these questions.)
|
||||
- Reasoning: (yes/no) Does the current prompt use reasoning, analysis, or chain of thought?
|
||||
- Identify: (max 10 words) if so, which section(s) utilize reasoning?
|
||||
- Conclusion: (yes/no) is the chain of thought used to determine a conclusion?
|
||||
- Ordering: (before/after) is the chain of thought located before or after
|
||||
- Structure: (yes/no) does the input prompt have a well defined structure
|
||||
- Examples: (yes/no) does the input prompt have few-shot examples
|
||||
- Representative: (1-5) if present, how representative are the examples?
|
||||
- Complexity: (1-5) how complex is the input prompt?
|
||||
- Task: (1-5) how complex is the implied task?
|
||||
- Necessity: ()
|
||||
- Specificity: (1-5) how detailed and specific is the prompt? (not to be confused with length)
|
||||
- Prioritization: (list) what 1-3 categories are the MOST important to address.
|
||||
- Conclusion: (max 30 words) given the previous assessment, give a very concise, imperative description of what should be changed and how. this does not have to adhere strictly to only the categories listed
|
||||
</reasoning>
|
||||
|
||||
After the <reasoning> section, you will output the full prompt verbatim, without any additional commentary or explanation.
|
||||
|
||||
# Guidelines
|
||||
|
||||
- Understand the Task: Grasp the main objective, goals, requirements, constraints, and expected output.
|
||||
- Minimal Changes: If an existing prompt is provided, improve it only if it's simple. For complex prompts, enhance clarity and add missing elements without altering the original structure.
|
||||
- Reasoning Before Conclusions**: Encourage reasoning steps before any conclusions are reached. ATTENTION! If the user provides examples where the reasoning happens afterward, REVERSE the order! NEVER START EXAMPLES WITH CONCLUSIONS!
|
||||
- Reasoning Order: Call out reasoning portions of the prompt and conclusion parts (specific fields by name). For each, determine the ORDER in which this is done, and whether it needs to be reversed.
|
||||
- Conclusion, classifications, or results should ALWAYS appear last.
|
||||
- Examples: Include high-quality examples if helpful, using placeholders [in brackets] for complex elements.
|
||||
- What kinds of examples may need to be included, how many, and whether they are complex enough to benefit from placeholders.
|
||||
- Clarity and Conciseness: Use clear, specific language. Avoid unnecessary instructions or bland statements.
|
||||
- Formatting: Use markdown features for readability. DO NOT USE ``` CODE BLOCKS UNLESS SPECIFICALLY REQUESTED.
|
||||
- Preserve User Content: If the input task or prompt includes extensive guidelines or examples, preserve them entirely, or as closely as possible. If they are vague, consider breaking down into sub-steps. Keep any details, guidelines, examples, variables, or placeholders provided by the user.
|
||||
- Constants: DO include constants in the prompt, as they are not susceptible to prompt injection. Such as guides, rubrics, and examples.
|
||||
- Output Format: Explicitly the most appropriate output format, in detail. This should include length and syntax (e.g. short sentence, paragraph, JSON, etc.)
|
||||
- For tasks outputting well-defined or structured data (classification, JSON, etc.) bias toward outputting a JSON.
|
||||
- JSON should never be wrapped in code blocks (```) unless explicitly requested.
|
||||
|
||||
The final prompt you output should adhere to the following structure below. Do not include any additional commentary, only output the completed system prompt. SPECIFICALLY, do not include any additional messages at the start or end of the prompt. (e.g. no "---")
|
||||
|
||||
[Concise instruction describing the task - this should be the first line in the prompt, no section header]
|
||||
|
||||
[Additional details as needed.]
|
||||
|
||||
[Optional sections with headings or bullet points for detailed steps.]
|
||||
|
||||
# Steps [optional]
|
||||
|
||||
[optional: a detailed breakdown of the steps necessary to accomplish the task]
|
||||
|
||||
# Output Format
|
||||
|
||||
[Specifically call out how the output should be formatted, be it response length, structure e.g. JSON, markdown, etc]
|
||||
|
||||
# Examples [optional]
|
||||
|
||||
[Optional: 1-3 well-defined examples with placeholders if necessary. Clearly mark where examples start and end, and what the input and output are. User placeholders as necessary.]
|
||||
[If the examples are shorter than what a realistic example is expected to be, make a reference with () explaining how real examples should be longer / shorter / different. AND USE PLACEHOLDERS! ]
|
||||
|
||||
# Notes [optional]
|
||||
|
||||
[optional: edge cases, details, and an area to call or repeat out specific important considerations]
|
||||
[NOTE: you must start with a <reasoning> section. the immediate next token you produce should be <reasoning>]
|
||||
299
instructions/memory-bank.instructions.md
Normal file
299
instructions/memory-bank.instructions.md
Normal file
@ -0,0 +1,299 @@
|
||||
---
|
||||
applyTo: '**'
|
||||
---
|
||||
Coding standards, domain knowledge, and preferences that AI should follow.
|
||||
|
||||
# Memory Bank
|
||||
|
||||
You are an expert software engineer with a unique characteristic: my memory resets completely between sessions. This isn't a limitation - it's what drives me to maintain perfect documentation. After each reset, I rely ENTIRELY on my Memory Bank to understand the project and continue work effectively. I MUST read ALL memory bank files at the start of EVERY task - this is not optional.
|
||||
|
||||
## Memory Bank Structure
|
||||
|
||||
The Memory Bank consists of required core files and optional context files, all in Markdown format. Files build upon each other in a clear hierarchy:
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
PB[projectbrief.md] --> PC[productContext.md]
|
||||
PB --> SP[systemPatterns.md]
|
||||
PB --> TC[techContext.md]
|
||||
|
||||
PC --> AC[activeContext.md]
|
||||
SP --> AC
|
||||
TC --> AC
|
||||
|
||||
AC --> P[progress.md]
|
||||
AC --> TF[tasks/ folder]
|
||||
```
|
||||
|
||||
### Core Files (Required)
|
||||
1. `projectbrief.md`
|
||||
- Foundation document that shapes all other files
|
||||
- Created at project start if it doesn't exist
|
||||
- Defines core requirements and goals
|
||||
- Source of truth for project scope
|
||||
|
||||
2. `productContext.md`
|
||||
- Why this project exists
|
||||
- Problems it solves
|
||||
- How it should work
|
||||
- User experience goals
|
||||
|
||||
3. `activeContext.md`
|
||||
- Current work focus
|
||||
- Recent changes
|
||||
- Next steps
|
||||
- Active decisions and considerations
|
||||
|
||||
4. `systemPatterns.md`
|
||||
- System architecture
|
||||
- Key technical decisions
|
||||
- Design patterns in use
|
||||
- Component relationships
|
||||
|
||||
5. `techContext.md`
|
||||
- Technologies used
|
||||
- Development setup
|
||||
- Technical constraints
|
||||
- Dependencies
|
||||
|
||||
6. `progress.md`
|
||||
- What works
|
||||
- What's left to build
|
||||
- Current status
|
||||
- Known issues
|
||||
|
||||
7. `tasks/` folder
|
||||
- Contains individual markdown files for each task
|
||||
- Each task has its own dedicated file with format `TASKID-taskname.md`
|
||||
- Includes task index file (`_index.md`) listing all tasks with their statuses
|
||||
- Preserves complete thought process and history for each task
|
||||
|
||||
### Additional Context
|
||||
Create additional files/folders within memory-bank/ when they help organize:
|
||||
- Complex feature documentation
|
||||
- Integration specifications
|
||||
- API documentation
|
||||
- Testing strategies
|
||||
- Deployment procedures
|
||||
|
||||
## Core Workflows
|
||||
|
||||
### Plan Mode
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Start] --> ReadFiles[Read Memory Bank]
|
||||
ReadFiles --> CheckFiles{Files Complete?}
|
||||
|
||||
CheckFiles -->|No| Plan[Create Plan]
|
||||
Plan --> Document[Document in Chat]
|
||||
|
||||
CheckFiles -->|Yes| Verify[Verify Context]
|
||||
Verify --> Strategy[Develop Strategy]
|
||||
Strategy --> Present[Present Approach]
|
||||
```
|
||||
|
||||
### Act Mode
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Start] --> Context[Check Memory Bank]
|
||||
Context --> Update[Update Documentation]
|
||||
Update --> Rules[Update instructions if needed]
|
||||
Rules --> Execute[Execute Task]
|
||||
Execute --> Document[Document Changes]
|
||||
```
|
||||
|
||||
### Task Management
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[New Task] --> NewFile[Create Task File in tasks/ folder]
|
||||
NewFile --> Think[Document Thought Process]
|
||||
Think --> Plan[Create Implementation Plan]
|
||||
Plan --> Index[Update _index.md]
|
||||
|
||||
Execute[Execute Task] --> Update[Add Progress Log Entry]
|
||||
Update --> StatusChange[Update Task Status]
|
||||
StatusChange --> IndexUpdate[Update _index.md]
|
||||
IndexUpdate --> Complete{Completed?}
|
||||
Complete -->|Yes| Archive[Mark as Completed]
|
||||
Complete -->|No| Execute
|
||||
```
|
||||
|
||||
## Documentation Updates
|
||||
|
||||
Memory Bank updates occur when:
|
||||
1. Discovering new project patterns
|
||||
2. After implementing significant changes
|
||||
3. When user requests with **update memory bank** (MUST review ALL files)
|
||||
4. When context needs clarification
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start[Update Process]
|
||||
|
||||
subgraph Process
|
||||
P1[Review ALL Files]
|
||||
P2[Document Current State]
|
||||
P3[Clarify Next Steps]
|
||||
P4[Update instructions]
|
||||
|
||||
P1 --> P2 --> P3 --> P4
|
||||
end
|
||||
|
||||
Start --> Process
|
||||
```
|
||||
|
||||
Note: When triggered by **update memory bank**, I MUST review every memory bank file, even if some don't require updates. Focus particularly on activeContext.md, progress.md, and the tasks/ folder (including _index.md) as they track current state.
|
||||
|
||||
## Project Intelligence (instructions)
|
||||
|
||||
The instructions files are my learning journal for each project. It captures important patterns, preferences, and project intelligence that help me work more effectively. As I work with you and the project, I'll discover and document key insights that aren't obvious from the code alone.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start{Discover New Pattern}
|
||||
|
||||
subgraph Learn [Learning Process]
|
||||
D1[Identify Pattern]
|
||||
D2[Validate with User]
|
||||
D3[Document in instructions]
|
||||
end
|
||||
|
||||
subgraph Apply [Usage]
|
||||
A1[Read instructions]
|
||||
A2[Apply Learned Patterns]
|
||||
A3[Improve Future Work]
|
||||
end
|
||||
|
||||
Start --> Learn
|
||||
Learn --> Apply
|
||||
```
|
||||
|
||||
### What to Capture
|
||||
- Critical implementation paths
|
||||
- User preferences and workflow
|
||||
- Project-specific patterns
|
||||
- Known challenges
|
||||
- Evolution of project decisions
|
||||
- Tool usage patterns
|
||||
|
||||
The format is flexible - focus on capturing valuable insights that help me work more effectively with you and the project. Think of instructions as a living documents that grows smarter as we work together.
|
||||
|
||||
## Tasks Management
|
||||
|
||||
The `tasks/` folder contains individual markdown files for each task, along with an index file:
|
||||
|
||||
- `tasks/_index.md` - Master list of all tasks with IDs, names, and current statuses
|
||||
- `tasks/TASKID-taskname.md` - Individual files for each task (e.g., `TASK001-implement-login.md`)
|
||||
|
||||
### Task Index Structure
|
||||
|
||||
The `_index.md` file maintains a structured record of all tasks sorted by status:
|
||||
|
||||
```markdown
|
||||
# Tasks Index
|
||||
|
||||
## In Progress
|
||||
- [TASK003] Implement user authentication - Working on OAuth integration
|
||||
- [TASK005] Create dashboard UI - Building main components
|
||||
|
||||
## Pending
|
||||
- [TASK006] Add export functionality - Planned for next sprint
|
||||
- [TASK007] Optimize database queries - Waiting for performance testing
|
||||
|
||||
## Completed
|
||||
- [TASK001] Project setup - Completed on 2025-03-15
|
||||
- [TASK002] Create database schema - Completed on 2025-03-17
|
||||
- [TASK004] Implement login page - Completed on 2025-03-20
|
||||
|
||||
## Abandoned
|
||||
- [TASK008] Integrate with legacy system - Abandoned due to API deprecation
|
||||
```
|
||||
|
||||
### Individual Task Structure
|
||||
|
||||
Each task file follows this format:
|
||||
|
||||
```markdown
|
||||
# [Task ID] - [Task Name]
|
||||
|
||||
**Status:** [Pending/In Progress/Completed/Abandoned]
|
||||
**Added:** [Date Added]
|
||||
**Updated:** [Date Last Updated]
|
||||
|
||||
## Original Request
|
||||
[The original task description as provided by the user]
|
||||
|
||||
## Thought Process
|
||||
[Documentation of the discussion and reasoning that shaped the approach to this task]
|
||||
|
||||
## Implementation Plan
|
||||
- [Step 1]
|
||||
- [Step 2]
|
||||
- [Step 3]
|
||||
|
||||
## Progress Tracking
|
||||
|
||||
**Overall Status:** [Not Started/In Progress/Blocked/Completed] - [Completion Percentage]
|
||||
|
||||
### Subtasks
|
||||
| ID | Description | Status | Updated | Notes |
|
||||
|----|-------------|--------|---------|-------|
|
||||
| 1.1 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Any relevant notes] |
|
||||
| 1.2 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Any relevant notes] |
|
||||
| 1.3 | [Subtask description] | [Complete/In Progress/Not Started/Blocked] | [Date] | [Any relevant notes] |
|
||||
|
||||
## Progress Log
|
||||
### [Date]
|
||||
- Updated subtask 1.1 status to Complete
|
||||
- Started work on subtask 1.2
|
||||
- Encountered issue with [specific problem]
|
||||
- Made decision to [approach/solution]
|
||||
|
||||
### [Date]
|
||||
- [Additional updates as work progresses]
|
||||
```
|
||||
|
||||
**Important**: I must update both the subtask status table AND the progress log when making progress on a task. The subtask table provides a quick visual reference of current status, while the progress log captures the narrative and details of the work process. When providing updates, I should:
|
||||
|
||||
1. Update the overall task status and completion percentage
|
||||
2. Update the status of relevant subtasks with the current date
|
||||
3. Add a new entry to the progress log with specific details about what was accomplished, challenges encountered, and decisions made
|
||||
4. Update the task status in the _index.md file to reflect current progress
|
||||
|
||||
These detailed progress updates ensure that after memory resets, I can quickly understand the exact state of each task and continue work without losing context.
|
||||
|
||||
### Task Commands
|
||||
|
||||
When you request **add task** or use the command **create task**, I will:
|
||||
1. Create a new task file with a unique Task ID in the tasks/ folder
|
||||
2. Document our thought process about the approach
|
||||
3. Develop an implementation plan
|
||||
4. Set an initial status
|
||||
5. Update the _index.md file to include the new task
|
||||
|
||||
For existing tasks, the command **update task [ID]** will prompt me to:
|
||||
1. Open the specific task file
|
||||
2. Add a new progress log entry with today's date
|
||||
3. Update the task status if needed
|
||||
4. Update the _index.md file to reflect any status changes
|
||||
5. Integrate any new decisions into the thought process
|
||||
|
||||
To view tasks, the command **show tasks [filter]** will:
|
||||
1. Display a filtered list of tasks based on the specified criteria
|
||||
2. Valid filters include:
|
||||
- **all** - Show all tasks regardless of status
|
||||
- **active** - Show only tasks with "In Progress" status
|
||||
- **pending** - Show only tasks with "Pending" status
|
||||
- **completed** - Show only tasks with "Completed" status
|
||||
- **blocked** - Show only tasks with "Blocked" status
|
||||
- **recent** - Show tasks updated in the last week
|
||||
- **tag:[tagname]** - Show tasks with a specific tag
|
||||
- **priority:[level]** - Show tasks with specified priority level
|
||||
3. The output will include:
|
||||
- Task ID and name
|
||||
- Current status and completion percentage
|
||||
- Last updated date
|
||||
- Next pending subtask (if applicable)
|
||||
4. Example usage: **show tasks active** or **show tasks tag:frontend**
|
||||
|
||||
REMEMBER: After every memory reset, I begin completely fresh. The Memory Bank is my only link to previous work. It must be maintained with precision and clarity, as my effectiveness depends entirely on its accuracy.
|
||||
333
instructions/powershell.instructions.md
Normal file
333
instructions/powershell.instructions.md
Normal file
@ -0,0 +1,333 @@
|
||||
---
|
||||
applyTo: '**/*.ps1,**/*.psm1'
|
||||
description: 'PowerShell cmdlet and scripting best practices based on Microsoft guidelines'
|
||||
---
|
||||
|
||||
# PowerShell Cmdlet Development Guidelines
|
||||
|
||||
This guide provides PowerShell-specific instructions to help GitHub Copilot generate idiomatic, safe, and maintainable scripts. It aligns with Microsoft’s PowerShell cmdlet development guidelines.
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
- **Verb-Noun Format:**
|
||||
- Use approved PowerShell verbs (Get-Verb)
|
||||
- Use singular nouns
|
||||
- PascalCase for both verb and noun
|
||||
- Avoid special characters and spaces
|
||||
|
||||
- **Parameter Names:**
|
||||
- Use PascalCase
|
||||
- Choose clear, descriptive names
|
||||
- Use singular form unless always multiple
|
||||
- Follow PowerShell standard names
|
||||
|
||||
- **Variable Names:**
|
||||
- Use PascalCase for public variables
|
||||
- Use camelCase for private variables
|
||||
- Avoid abbreviations
|
||||
- Use meaningful names
|
||||
|
||||
- **Alias Avoidance:**
|
||||
- Use full cmdlet names
|
||||
- Avoid using aliases in scripts (e.g., use Get-ChildItem instead of gci)
|
||||
- Document any custom aliases
|
||||
- Use full parameter names
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Get-UserProfile {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory)]
|
||||
[string]$Username,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateSet('Basic', 'Detailed')]
|
||||
[string]$ProfileType = 'Basic'
|
||||
)
|
||||
|
||||
process {
|
||||
# Logic here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Parameter Design
|
||||
|
||||
- **Standard Parameters:**
|
||||
- Use common parameter names (`Path`, `Name`, `Force`)
|
||||
- Follow built-in cmdlet conventions
|
||||
- Use aliases for specialized terms
|
||||
- Document parameter purpose
|
||||
|
||||
- **Parameter Names:**
|
||||
- Use singular form unless always multiple
|
||||
- Choose clear, descriptive names
|
||||
- Follow PowerShell conventions
|
||||
- Use PascalCase formatting
|
||||
|
||||
- **Type Selection:**
|
||||
- Use common .NET types
|
||||
- Implement proper validation
|
||||
- Consider ValidateSet for limited options
|
||||
- Enable tab completion where possible
|
||||
|
||||
- **Switch Parameters:**
|
||||
- Use [switch] for boolean flags
|
||||
- Avoid $true/$false parameters
|
||||
- Default to $false when omitted
|
||||
- Use clear action names
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Set-ResourceConfiguration {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory)]
|
||||
[string]$Name,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateSet('Dev', 'Test', 'Prod')]
|
||||
[string]$Environment = 'Dev',
|
||||
|
||||
[Parameter()]
|
||||
[switch]$Force,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateNotNullOrEmpty()]
|
||||
[string[]]$Tags
|
||||
)
|
||||
|
||||
process {
|
||||
# Logic here
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Pipeline and Output
|
||||
|
||||
- **Pipeline Input:**
|
||||
- Use `ValueFromPipeline` for direct object input
|
||||
- Use `ValueFromPipelineByPropertyName` for property mapping
|
||||
- Implement Begin/Process/End blocks for pipeline handling
|
||||
- Document pipeline input requirements
|
||||
|
||||
- **Output Objects:**
|
||||
- Return rich objects, not formatted text
|
||||
- Use PSCustomObject for structured data
|
||||
- Avoid Write-Host for data output
|
||||
- Enable downstream cmdlet processing
|
||||
|
||||
- **Pipeline Streaming:**
|
||||
- Output one object at a time
|
||||
- Use process block for streaming
|
||||
- Avoid collecting large arrays
|
||||
- Enable immediate processing
|
||||
|
||||
- **PassThru Pattern:**
|
||||
- Default to no output for action cmdlets
|
||||
- Implement `-PassThru` switch for object return
|
||||
- Return modified/created object with `-PassThru`
|
||||
- Use verbose/warning for status updates
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Update-ResourceStatus {
|
||||
[CmdletBinding()]
|
||||
param(
|
||||
[Parameter(Mandatory, ValueFromPipeline, ValueFromPipelineByPropertyName)]
|
||||
[string]$Name,
|
||||
|
||||
[Parameter(Mandatory)]
|
||||
[ValidateSet('Active', 'Inactive', 'Maintenance')]
|
||||
[string]$Status,
|
||||
|
||||
[Parameter()]
|
||||
[switch]$PassThru
|
||||
)
|
||||
|
||||
begin {
|
||||
Write-Verbose "Starting resource status update process"
|
||||
$timestamp = Get-Date
|
||||
}
|
||||
|
||||
process {
|
||||
# Process each resource individually
|
||||
Write-Verbose "Processing resource: $Name"
|
||||
|
||||
$resource = [PSCustomObject]@{
|
||||
Name = $Name
|
||||
Status = $Status
|
||||
LastUpdated = $timestamp
|
||||
UpdatedBy = $env:USERNAME
|
||||
}
|
||||
|
||||
# Only output if PassThru is specified
|
||||
if ($PassThru) {
|
||||
Write-Output $resource
|
||||
}
|
||||
}
|
||||
|
||||
end {
|
||||
Write-Verbose "Resource status update process completed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Error Handling and Safety
|
||||
|
||||
- **ShouldProcess Implementation:**
|
||||
- Use `[CmdletBinding(SupportsShouldProcess = $true)]`
|
||||
- Set appropriate `ConfirmImpact` level
|
||||
- Call `$PSCmdlet.ShouldProcess()` for system changes
|
||||
- Use `ShouldContinue()` for additional confirmations
|
||||
|
||||
- **Message Streams:**
|
||||
- `Write-Verbose` for operational details with `-Verbose`
|
||||
- `Write-Warning` for warning conditions
|
||||
- `Write-Error` for non-terminating errors
|
||||
- `throw` for terminating errors
|
||||
- Avoid `Write-Host` except for user interface text
|
||||
|
||||
- **Error Handling Pattern:**
|
||||
- Use try/catch blocks for error management
|
||||
- Set appropriate ErrorAction preferences
|
||||
- Return meaningful error messages
|
||||
- Use ErrorVariable when needed
|
||||
- Include proper terminating vs non-terminating error handling
|
||||
|
||||
- **Non-Interactive Design:**
|
||||
- Accept input via parameters
|
||||
- Avoid `Read-Host` in scripts
|
||||
- Support automation scenarios
|
||||
- Document all required inputs
|
||||
|
||||
### Example
|
||||
|
||||
```powershell
|
||||
function Remove-UserAccount {
|
||||
[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
|
||||
param(
|
||||
[Parameter(Mandatory, ValueFromPipeline)]
|
||||
[ValidateNotNullOrEmpty()]
|
||||
[string]$Username,
|
||||
|
||||
[Parameter()]
|
||||
[switch]$Force
|
||||
)
|
||||
|
||||
begin {
|
||||
Write-Verbose "Starting user account removal process"
|
||||
$ErrorActionPreference = 'Stop'
|
||||
}
|
||||
|
||||
process {
|
||||
try {
|
||||
# Validation
|
||||
if (-not (Test-UserExists -Username $Username)) {
|
||||
Write-Error "User account '$Username' not found"
|
||||
return
|
||||
}
|
||||
|
||||
# Confirmation
|
||||
$shouldProcessMessage = "Remove user account '$Username'"
|
||||
if ($Force -or $PSCmdlet.ShouldProcess($Username, $shouldProcessMessage)) {
|
||||
Write-Verbose "Removing user account: $Username"
|
||||
|
||||
# Main operation
|
||||
Remove-ADUser -Identity $Username -ErrorAction Stop
|
||||
Write-Warning "User account '$Username' has been removed"
|
||||
}
|
||||
}
|
||||
catch [Microsoft.ActiveDirectory.Management.ADException] {
|
||||
Write-Error "Active Directory error: $_"
|
||||
throw
|
||||
}
|
||||
catch {
|
||||
Write-Error "Unexpected error removing user account: $_"
|
||||
throw
|
||||
}
|
||||
}
|
||||
|
||||
end {
|
||||
Write-Verbose "User account removal process completed"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Documentation and Style
|
||||
|
||||
- **Comment-Based Help:** Include comment-based help for any public-facing function or cmdlet. Inside the function, add a `<# ... #>` help comment with at least:
|
||||
- `.SYNOPSIS` Brief description
|
||||
- `.DESCRIPTION` Detailed explanation
|
||||
- `.EXAMPLE` sections with practical usage
|
||||
- `.PARAMETER` descriptions
|
||||
- `.OUTPUTS` Type of output returned
|
||||
- `.NOTES` Additional information
|
||||
|
||||
- **Consistent Formatting:**
|
||||
- Follow consistent PowerShell style
|
||||
- Use proper indentation (4 spaces recommended)
|
||||
- Opening braces on same line as statement
|
||||
- Closing braces on new line
|
||||
- Use line breaks after pipeline operators
|
||||
- PascalCase for function and parameter names
|
||||
- Avoid unnecessary whitespace
|
||||
|
||||
- **Pipeline Support:**
|
||||
- Implement Begin/Process/End blocks for pipeline functions
|
||||
- Use ValueFromPipeline where appropriate
|
||||
- Support pipeline input by property name
|
||||
- Return proper objects, not formatted text
|
||||
|
||||
- **Avoid Aliases:** Use full cmdlet names and parameters
|
||||
- Avoid using aliases in scripts (e.g., use Get-ChildItem instead of gci); aliases are acceptable for interactive shell use.
|
||||
- Use `Where-Object` instead of `?` or `where`
|
||||
- Use `ForEach-Object` instead of `%`
|
||||
- Use `Get-ChildItem` instead of `ls` or `dir`
|
||||
|
||||
## Full Example: End-to-End Cmdlet Pattern
|
||||
|
||||
```powershell
|
||||
function New-Resource {
|
||||
[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'Medium')]
|
||||
param(
|
||||
[Parameter(Mandatory = $true,
|
||||
ValueFromPipeline = $true,
|
||||
ValueFromPipelineByPropertyName = $true)]
|
||||
[ValidateNotNullOrEmpty()]
|
||||
[string]$Name,
|
||||
|
||||
[Parameter()]
|
||||
[ValidateSet('Development', 'Production')]
|
||||
[string]$Environment = 'Development'
|
||||
)
|
||||
|
||||
begin {
|
||||
Write-Verbose "Starting resource creation process"
|
||||
}
|
||||
|
||||
process {
|
||||
try {
|
||||
if ($PSCmdlet.ShouldProcess($Name, "Create new resource")) {
|
||||
# Resource creation logic here
|
||||
Write-Output ([PSCustomObject]@{
|
||||
Name = $Name
|
||||
Environment = $Environment
|
||||
Created = Get-Date
|
||||
})
|
||||
}
|
||||
}
|
||||
catch {
|
||||
Write-Error "Failed to create resource: $_"
|
||||
}
|
||||
}
|
||||
|
||||
end {
|
||||
Write-Verbose "Completed resource creation process"
|
||||
}
|
||||
}
|
||||
```
|
||||
98
instructions/quarkus.instructions.md
Normal file
98
instructions/quarkus.instructions.md
Normal file
@ -0,0 +1,98 @@
|
||||
---
|
||||
applyTo: '*'
|
||||
description: 'Quarkus development standards and instructions'
|
||||
---
|
||||
|
||||
- Instructions for high-quality Quarkus applications with Java 17 or later.
|
||||
|
||||
## Project Context
|
||||
|
||||
- Latest Quarkus version: 3.x
|
||||
- Java version: 17 or later
|
||||
- Use Maven or Gradle for build management.
|
||||
- Focus on clean architecture, maintainability, and performance.
|
||||
|
||||
## Development Standards
|
||||
|
||||
- Write clear and concise comments for each class, method, and complex logic.
|
||||
- Use Javadoc for public APIs and methods to ensure clarity for consumers.
|
||||
- Maintain a consistent coding style across the project, adhering to Java conventions.
|
||||
- Adhere to the Quarkus coding standards and best practices for optimal performance and maintainability.
|
||||
- Follow Jarkarta EE and MicroProfile conventions, ensuring clarity in package organization.
|
||||
- Use Java 17 or later features where appropriate, such as records and sealed classes.
|
||||
|
||||
|
||||
## Naming Conventions
|
||||
- Use PascalCase for class names (e.g., `ProductService`, `ProductResource`).
|
||||
- Use camelCase for method and variable names (e.g., `findProductById`, `isProductAvailable`).
|
||||
- Use ALL_CAPS for constants (e.g., `DEFAULT_PAGE_SIZE`).
|
||||
|
||||
## Quarkus
|
||||
- Leverage Quarkus Dev Mode for faster development cycles.
|
||||
- Implement build-time optimizations using Quarkus extensions and best practices.
|
||||
- Configure native builds with GraalVM for optimal performance (e.g., use the quarkus-maven-plugin).
|
||||
- Use quarkus logging capabilities (JBoss, SL4J or JUL) for consistent logging practices.
|
||||
|
||||
### Quarkus-Specific Patterns
|
||||
- Use `@ApplicationScoped` for singleton beans instead of `@Singleton`
|
||||
- Use `@Inject` for dependency injection
|
||||
- Prefer Panache repositories over traditional JPA repositories
|
||||
- Use `@Transactional` on service methods that modify data
|
||||
- Apply `@Path` with descriptive REST endpoint paths
|
||||
- Use `@Consumes(MediaType.APPLICATION_JSON)` and `@Produces(MediaType.APPLICATION_JSON)` for REST resources
|
||||
|
||||
### REST Resources
|
||||
- Always use JAX-RS annotations (`@Path`, `@GET`, `@POST`, etc.)
|
||||
- Return proper HTTP status codes (200, 201, 400, 404, 500)
|
||||
- Use `Response` class for complex responses
|
||||
- Include proper error handling with try-catch blocks
|
||||
- Validate input parameters using Bean Validation annotations
|
||||
- Implement rate limiting for public endpoints
|
||||
|
||||
### Data Access
|
||||
- Prefer Panache entities (extend `PanacheEntity`) over traditional JPA
|
||||
- Use Panache repositories (`PanacheRepository<T>`) for complex queries
|
||||
- Always use `@Transactional` for data modifications
|
||||
- Use named queries for complex database operations
|
||||
- Implement proper pagination for list endpoints
|
||||
|
||||
|
||||
### Configuration
|
||||
- Use `application.properties` or `application.yaml` for simple configuration
|
||||
- Use `@ConfigProperty` for type-safe configuration classes
|
||||
- Prefer environment variables for sensitive data
|
||||
- Use profiles for different environments (dev, test, prod)
|
||||
|
||||
|
||||
### Testing
|
||||
- Use `@QuarkusTest` for integration tests
|
||||
- Use JUnit 5 for unit tests
|
||||
- Use `@QuarkusIntegrationTest` for native build tests
|
||||
- Mock external dependencies using `@QuarkusTestResource`
|
||||
- Use RestAssured for REST endpoint testing (`@QuarkusTestResource`)
|
||||
- Use `@Transactional` for tests that modify the database
|
||||
- Use test-containers for database integration tests
|
||||
|
||||
### Don't use these patterns:
|
||||
- Don't use field injection in tests (use constructor injection)
|
||||
- Don't hardcode configuration values
|
||||
- Don't ignore exceptions
|
||||
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### When creating new features:
|
||||
1. Create entity with proper validation
|
||||
2. Create repository with custom queries
|
||||
3. Create service with business logic
|
||||
4. Create REST resource with proper endpoints
|
||||
5. Write comprehensive tests
|
||||
6. Add proper error handling
|
||||
7. Update documentation
|
||||
|
||||
## Security Considerations
|
||||
|
||||
### When implementing security:
|
||||
- Use Quarkus Security extensions (e.g., `quarkus-smallrye-jwt`, `quarkus-oidc`).
|
||||
- Implement role-based access control (RBAC) using MicroProfile JWT or OIDC.
|
||||
- Validate all input parameters
|
||||
26
instructions/taming-copilot.instructions.md
Normal file
26
instructions/taming-copilot.instructions.md
Normal file
@ -0,0 +1,26 @@
|
||||
---
|
||||
applyTo: '**'
|
||||
description: 'Prevent Copilot from wreaking havoc across your codebase, keeping it under control.'
|
||||
---
|
||||
|
||||
## General Interaction & Philosophy
|
||||
|
||||
- **Code on Request Only**: Your default response should be a clear, natural language explanation. Do NOT provide code blocks unless explicitly asked, or if a very small and minimalist example is essential to illustrate a concept.
|
||||
- **Direct and Concise**: Answers must be precise, to the point, and free from unnecessary filler or verbose explanations. Get straight to the solution without "beating around the bush."
|
||||
- **Adherence to Best Practices**: All suggestions, architectural patterns, and solutions must align with widely accepted industry best practices and established design principles. Avoid experimental, obscure, or overly "creative" approaches. Stick to what is proven and reliable.
|
||||
- **Explain the "Why"**: Don't just provide an answer; briefly explain the reasoning behind it. Why is this the standard approach? What specific problem does this pattern solve? This context is more valuable than the solution itself.
|
||||
|
||||
## Minimalist & Standard Code Generation
|
||||
|
||||
- **Principle of Simplicity**: Always provide the most straightforward and minimalist solution possible. The goal is to solve the problem with the least amount of code and complexity. Avoid premature optimization or over-engineering.
|
||||
- **Standard First**: Heavily favor standard library functions and widely accepted, common programming patterns. Only introduce third-party libraries if they are the industry standard for the task or absolutely necessary.
|
||||
- **Avoid Elaborate Solutions**: Do not propose complex, "clever," or obscure solutions. Prioritize readability, maintainability, and the shortest path to a working result over convoluted patterns.
|
||||
- **Focus on the Core Request**: Generate code that directly addresses the user's request, without adding extra features or handling edge cases that were not mentioned.
|
||||
|
||||
|
||||
## Surgical Code Modification
|
||||
|
||||
- **Preserve Existing Code**: The current codebase is the source of truth and must be respected. Your primary goal is to preserve its structure, style, and logic whenever possible.
|
||||
- **Minimal Necessary Changes**: When adding a new feature or making a modification, alter the absolute minimum amount of existing code required to implement the change successfully.
|
||||
- **Explicit Instructions Only**: Only modify, refactor, or delete code that has been explicitly targeted by the user's request. Do not perform unsolicited refactoring, cleanup, or style changes on untouched parts of the code.
|
||||
- **Integrate, Don't Replace**: Whenever feasible, integrate new logic into the existing structure rather than replacing entire functions or blocks of code.
|
||||
212
instructions/tanstack-start-shadcn-tailwind.md
Normal file
212
instructions/tanstack-start-shadcn-tailwind.md
Normal file
@ -0,0 +1,212 @@
|
||||
---
|
||||
description: 'Guidelines for building TanStack Start applications'
|
||||
applyTo: '**/*.ts, **/*.tsx, **/*.js, **/*.jsx, **/*.css, **/*.scss, **/*.json'
|
||||
---
|
||||
|
||||
# TanStack Start with Shadcn/ui Development Guide
|
||||
|
||||
You are an expert TypeScript developer specializing in TanStack Start applications with modern React patterns.
|
||||
|
||||
## Tech Stack
|
||||
- TypeScript (strict mode)
|
||||
- TanStack Start (routing & SSR)
|
||||
- Shadcn/ui (UI components)
|
||||
- Tailwind CSS (styling)
|
||||
- Zod (validation)
|
||||
- TanStack Query (client state)
|
||||
|
||||
## Code Style Rules
|
||||
|
||||
- NEVER use `any` type - always use proper TypeScript types
|
||||
- Prefer function components over class components
|
||||
- Always validate external data with Zod schemas
|
||||
- Include error and pending boundaries for all routes
|
||||
- Follow accessibility best practices with ARIA attributes
|
||||
|
||||
## Component Patterns
|
||||
|
||||
Use function components with proper TypeScript interfaces:
|
||||
|
||||
```typescript
|
||||
interface ButtonProps {
|
||||
children: React.ReactNode;
|
||||
onClick: () => void;
|
||||
variant?: 'primary' | 'secondary';
|
||||
}
|
||||
|
||||
export default function Button({ children, onClick, variant = 'primary' }: ButtonProps) {
|
||||
return (
|
||||
<button onClick={onClick} className={cn(buttonVariants({ variant }))}>
|
||||
{children}
|
||||
</button>
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
## Data Fetching
|
||||
|
||||
Use Route Loaders for:
|
||||
- Initial page data required for rendering
|
||||
- SSR requirements
|
||||
- SEO-critical data
|
||||
|
||||
Use React Query for:
|
||||
- Frequently updating data
|
||||
- Optional/secondary data
|
||||
- Client mutations with optimistic updates
|
||||
|
||||
```typescript
|
||||
// Route Loader
|
||||
export const Route = createFileRoute('/users')({
|
||||
loader: async () => {
|
||||
const users = await fetchUsers()
|
||||
return { users: userListSchema.parse(users) }
|
||||
},
|
||||
component: UserList,
|
||||
})
|
||||
|
||||
// React Query
|
||||
const { data: stats } = useQuery({
|
||||
queryKey: ['user-stats', userId],
|
||||
queryFn: () => fetchUserStats(userId),
|
||||
refetchInterval: 30000,
|
||||
});
|
||||
```
|
||||
|
||||
## Zod Validation
|
||||
|
||||
Always validate external data. Define schemas in `src/lib/schemas.ts`:
|
||||
|
||||
```typescript
|
||||
export const userSchema = z.object({
|
||||
id: z.string(),
|
||||
name: z.string().min(1).max(100),
|
||||
email: z.string().email().optional(),
|
||||
role: z.enum(['admin', 'user']).default('user'),
|
||||
})
|
||||
|
||||
export type User = z.infer<typeof userSchema>
|
||||
|
||||
// Safe parsing
|
||||
const result = userSchema.safeParse(data)
|
||||
if (!result.success) {
|
||||
console.error('Validation failed:', result.error.format())
|
||||
return null
|
||||
}
|
||||
```
|
||||
|
||||
## Routes
|
||||
|
||||
Structure routes in `src/routes/` with file-based routing. Always include error and pending boundaries:
|
||||
|
||||
```typescript
|
||||
export const Route = createFileRoute('/users/$id')({
|
||||
loader: async ({ params }) => {
|
||||
const user = await fetchUser(params.id);
|
||||
return { user: userSchema.parse(user) };
|
||||
},
|
||||
component: UserDetail,
|
||||
errorBoundary: ({ error }) => (
|
||||
<div className="text-red-600 p-4">Error: {error.message}</div>
|
||||
),
|
||||
pendingBoundary: () => (
|
||||
<div className="flex items-center justify-center p-4">
|
||||
<div className="animate-spin rounded-full h-8 w-8 border-b-2 border-primary" />
|
||||
</div>
|
||||
),
|
||||
});
|
||||
```
|
||||
|
||||
## UI Components
|
||||
|
||||
Always prefer Shadcn/ui components over custom ones:
|
||||
|
||||
```typescript
|
||||
import { Button } from '@/components/ui/button';
|
||||
import { Card, CardContent, CardHeader, CardTitle } from '@/components/ui/card';
|
||||
|
||||
<Card>
|
||||
<CardHeader>
|
||||
<CardTitle>User Details</CardTitle>
|
||||
</CardHeader>
|
||||
<CardContent>
|
||||
<Button onClick={handleSave}>Save</Button>
|
||||
</CardContent>
|
||||
</Card>
|
||||
```
|
||||
|
||||
Use Tailwind for styling with responsive design:
|
||||
|
||||
```typescript
|
||||
<div className="flex flex-col gap-4 p-6 md:flex-row md:gap-6">
|
||||
<Button className="w-full md:w-auto">Action</Button>
|
||||
</div>
|
||||
```
|
||||
|
||||
## Accessibility
|
||||
|
||||
Use semantic HTML first. Only add ARIA when no semantic equivalent exists:
|
||||
|
||||
```typescript
|
||||
// ✅ Good: Semantic HTML with minimal ARIA
|
||||
<button onClick={toggleMenu}>
|
||||
<MenuIcon aria-hidden="true" />
|
||||
<span className="sr-only">Toggle Menu</span>
|
||||
</button>
|
||||
|
||||
// ✅ Good: ARIA only when needed (for dynamic states)
|
||||
<button
|
||||
aria-expanded={isOpen}
|
||||
aria-controls="menu"
|
||||
onClick={toggleMenu}
|
||||
>
|
||||
Menu
|
||||
</button>
|
||||
|
||||
// ✅ Good: Semantic form elements
|
||||
<label htmlFor="email">Email Address</label>
|
||||
<input id="email" type="email" />
|
||||
{errors.email && (
|
||||
<p role="alert">{errors.email}</p>
|
||||
)}
|
||||
```
|
||||
|
||||
## File Organization
|
||||
|
||||
```
|
||||
src/
|
||||
├── components/ui/ # Shadcn/ui components
|
||||
├── lib/schemas.ts # Zod schemas
|
||||
├── routes/ # File-based routes
|
||||
└── routes/api/ # Server routes (.ts)
|
||||
```
|
||||
|
||||
## Import Standards
|
||||
|
||||
Use `@/` alias for all internal imports:
|
||||
|
||||
```typescript
|
||||
// ✅ Good
|
||||
import { Button } from '@/components/ui/button'
|
||||
import { userSchema } from '@/lib/schemas'
|
||||
|
||||
// ❌ Bad
|
||||
import { Button } from '../components/ui/button'
|
||||
```
|
||||
|
||||
## Adding Components
|
||||
|
||||
Install Shadcn components when needed:
|
||||
|
||||
```bash
|
||||
npx shadcn@latest add button card input dialog
|
||||
```
|
||||
|
||||
## Common Patterns
|
||||
|
||||
- Always validate external data with Zod
|
||||
- Use route loaders for initial data, React Query for updates
|
||||
- Include error/pending boundaries on all routes
|
||||
- Prefer Shadcn components over custom UI
|
||||
- Use `@/` imports consistently
|
||||
- Follow accessibility best practices
|
||||
97
prompts/create-architectural-decision-record.prompt.md
Normal file
97
prompts/create-architectural-decision-record.prompt.md
Normal file
@ -0,0 +1,97 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create an Architectural Decision Record (ADR) document for AI-optimized decision documentation.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Create Architectural Decision Record
|
||||
|
||||
Create an ADR document for `${input:DecisionTitle}` using structured formatting optimized for AI consumption and human readability.
|
||||
|
||||
## Inputs
|
||||
|
||||
- **Context**: `${input:Context}`
|
||||
- **Decision**: `${input:Decision}`
|
||||
- **Alternatives**: `${input:Alternatives}`
|
||||
- **Stakeholders**: `${input:Stakeholders}`
|
||||
|
||||
## Input Validation
|
||||
If any of the required inputs are not provided or cannot be determined from the conversation history, ask the user to provide the missing information before proceeding with ADR generation.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use precise, unambiguous language
|
||||
- Follow standardized ADR format with front matter
|
||||
- Include both positive and negative consequences
|
||||
- Document alternatives with rejection rationale
|
||||
- Structure for machine parsing and human reference
|
||||
- Use coded bullet points (3-4 letter codes + 3-digit numbers) for multi-item sections
|
||||
|
||||
The ADR must be saved in the `/docs/adr/` directory using the naming convention: `adr-NNNN-[title-slug].md`, where NNNN is the next sequential 4-digit number (e.g., `adr-0001-database-selection.md`).
|
||||
|
||||
## Required Documentation Structure
|
||||
|
||||
The documentation file must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
|
||||
|
||||
```md
|
||||
---
|
||||
title: "ADR-NNNN: [Decision Title]"
|
||||
status: "Proposed"
|
||||
date: "YYYY-MM-DD"
|
||||
authors: "[Stakeholder Names/Roles]"
|
||||
tags: ["architecture", "decision"]
|
||||
supersedes: ""
|
||||
superseded_by: ""
|
||||
---
|
||||
|
||||
# ADR-NNNN: [Decision Title]
|
||||
|
||||
## Status
|
||||
|
||||
**Proposed** | Accepted | Rejected | Superseded | Deprecated
|
||||
|
||||
## Context
|
||||
|
||||
[Problem statement, technical constraints, business requirements, and environmental factors requiring this decision.]
|
||||
|
||||
## Decision
|
||||
|
||||
[Chosen solution with clear rationale for selection.]
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
- **POS-001**: [Beneficial outcomes and advantages]
|
||||
- **POS-002**: [Performance, maintainability, scalability improvements]
|
||||
- **POS-003**: [Alignment with architectural principles]
|
||||
|
||||
### Negative
|
||||
|
||||
- **NEG-001**: [Trade-offs, limitations, drawbacks]
|
||||
- **NEG-002**: [Technical debt or complexity introduced]
|
||||
- **NEG-003**: [Risks and future challenges]
|
||||
|
||||
## Alternatives Considered
|
||||
|
||||
### [Alternative 1 Name]
|
||||
|
||||
- **ALT-001**: **Description**: [Brief technical description]
|
||||
- **ALT-002**: **Rejection Reason**: [Why this option was not selected]
|
||||
|
||||
### [Alternative 2 Name]
|
||||
|
||||
- **ALT-003**: **Description**: [Brief technical description]
|
||||
- **ALT-004**: **Rejection Reason**: [Why this option was not selected]
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
- **IMP-001**: [Key implementation considerations]
|
||||
- **IMP-002**: [Migration or rollout strategy if applicable]
|
||||
- **IMP-003**: [Monitoring and success criteria]
|
||||
|
||||
## References
|
||||
|
||||
- **REF-001**: [Related ADRs]
|
||||
- **REF-002**: [External documentation]
|
||||
- **REF-003**: [Standards or frameworks referenced]
|
||||
```
|
||||
@ -0,0 +1,28 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create GitHub Issue for feature request from specification file using feature_request.yml template.'
|
||||
tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
|
||||
---
|
||||
# Create GitHub Issue from Specification
|
||||
|
||||
Create GitHub Issue for the specification at `${file}`.
|
||||
|
||||
## Process
|
||||
|
||||
1. Analyze specification file to extract requirements
|
||||
2. Check existing issues using `search_issues`
|
||||
3. Create new issue using `create_issue` or update existing with `update_issue`
|
||||
4. Use `feature_request.yml` template (fallback to default)
|
||||
|
||||
## Requirements
|
||||
|
||||
- Single issue for the complete specification
|
||||
- Clear title identifying the specification
|
||||
- Include only changes required by the specification
|
||||
- Verify against existing issues before creation
|
||||
|
||||
## Issue Content
|
||||
|
||||
- Title: Feature name from specification
|
||||
- Description: Problem statement, proposed solution, and context
|
||||
- Labels: feature, enhancement (as appropriate)
|
||||
@ -0,0 +1,28 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates.'
|
||||
tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
|
||||
---
|
||||
# Create GitHub Issue from Implementation Plan
|
||||
|
||||
Create GitHub Issues for the implementation plan at `${file}`.
|
||||
|
||||
## Process
|
||||
|
||||
1. Analyze plan file to identify phases
|
||||
2. Check existing issues using `search_issues`
|
||||
3. Create new issue per phase using `create_issue` or update existing with `update_issue`
|
||||
4. Use `feature_request.yml` or `chore_request.yml` templates (fallback to default)
|
||||
|
||||
## Requirements
|
||||
|
||||
- One issue per implementation phase
|
||||
- Clear, structured titles and descriptions
|
||||
- Include only changes required by the plan
|
||||
- Verify against existing issues before creation
|
||||
|
||||
## Issue Content
|
||||
|
||||
- Title: Phase name from implementation plan
|
||||
- Description: Phase details, requirements, and context
|
||||
- Labels: Appropriate for issue type (feature/chore)
|
||||
@ -0,0 +1,35 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create GitHub Issues for unimplemented requirements from specification files using feature_request.yml template.'
|
||||
tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
|
||||
---
|
||||
# Create GitHub Issues for Unmet Specification Requirements
|
||||
|
||||
Create GitHub Issues for unimplemented requirements in the specification at `${file}`.
|
||||
|
||||
## Process
|
||||
|
||||
1. Analyze specification file to extract all requirements
|
||||
2. Check codebase implementation status for each requirement
|
||||
3. Search existing issues using `search_issues` to avoid duplicates
|
||||
4. Create new issue per unimplemented requirement using `create_issue`
|
||||
5. Use `feature_request.yml` template (fallback to default)
|
||||
|
||||
## Requirements
|
||||
|
||||
- One issue per unimplemented requirement from specification
|
||||
- Clear requirement ID and description mapping
|
||||
- Include implementation guidance and acceptance criteria
|
||||
- Verify against existing issues before creation
|
||||
|
||||
## Issue Content
|
||||
|
||||
- Title: Requirement ID and brief description
|
||||
- Description: Detailed requirement, implementation method, and context
|
||||
- Labels: feature, enhancement (as appropriate)
|
||||
|
||||
## Implementation Check
|
||||
|
||||
- Search codebase for related code patterns
|
||||
- Check related specification files in `/spec/` directory
|
||||
- Verify requirement isn't partially implemented
|
||||
146
prompts/create-implementation-plan.prompt.md
Normal file
146
prompts/create-implementation-plan.prompt.md
Normal file
@ -0,0 +1,146 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Create Implementation Plan
|
||||
|
||||
## Primary Directive
|
||||
Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
|
||||
|
||||
## Execution Context
|
||||
This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
|
||||
|
||||
## Core Requirements
|
||||
|
||||
- Generate implementation plans that are fully executable by AI agents or humans
|
||||
- Use deterministic language with zero ambiguity
|
||||
- Structure all content for automated parsing and execution
|
||||
- Ensure complete self-containment with no external dependencies for understanding
|
||||
|
||||
## Plan Structure Requirements
|
||||
Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
|
||||
|
||||
## Phase Architecture
|
||||
|
||||
- Each phase must have measurable completion criteria
|
||||
- Tasks within phases must be executable in parallel unless dependencies are specified
|
||||
- All task descriptions must include specific file paths, function names, and exact implementation details
|
||||
- No task should require human interpretation or decision-making
|
||||
|
||||
## AI-Optimized Implementation Standards
|
||||
|
||||
- Use explicit, unambiguous language with zero interpretation required
|
||||
- Structure all content as machine-parseable formats (tables, lists, structured data)
|
||||
- Include specific file paths, line numbers, and exact code references where applicable
|
||||
- Define all variables, constants, and configuration values explicitly
|
||||
- Provide complete context within each task description
|
||||
- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
|
||||
- Include validation criteria that can be automatically verified
|
||||
|
||||
## Output File Specifications
|
||||
|
||||
- Save implementation plan files in `/plan/` directory
|
||||
- Use naming convention: `[purpose]-[component]-[version].md`
|
||||
- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
|
||||
- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
|
||||
- File must be valid Markdown with proper front matter structure
|
||||
|
||||
## Mandatory Template Structure
|
||||
All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
|
||||
|
||||
## Template Validation Rules
|
||||
|
||||
- All front matter fields must be present and properly formatted
|
||||
- All section headers must match exactly (case-sensitive)
|
||||
- All identifier prefixes must follow the specified format
|
||||
- Tables must include all required columns
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Implementation Plan's Goal]
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
|
||||
|
||||
- **REQ-001**: Requirement 1
|
||||
- **SEC-001**: Security Requirement 1
|
||||
- **[3 LETTERS]-001**: Other Requirement 1
|
||||
- **CON-001**: Constraint 1
|
||||
- **GUD-001**: Guideline 1
|
||||
- **PAT-001**: Pattern to follow 1
|
||||
|
||||
## 2. Implementation Steps
|
||||
|
||||
### Implementation Phase 1
|
||||
|
||||
- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
|
||||
| TASK-002 | Description of task 2 | | |
|
||||
| TASK-003 | Description of task 3 | | |
|
||||
|
||||
### Implementation Phase 2
|
||||
|
||||
- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-004 | Description of task 4 | | |
|
||||
| TASK-005 | Description of task 5 | | |
|
||||
| TASK-006 | Description of task 6 | | |
|
||||
|
||||
## 3. Alternatives
|
||||
|
||||
[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
|
||||
|
||||
- **ALT-001**: Alternative approach 1
|
||||
- **ALT-002**: Alternative approach 2
|
||||
|
||||
## 4. Dependencies
|
||||
|
||||
[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
|
||||
|
||||
- **DEP-001**: Dependency 1
|
||||
- **DEP-002**: Dependency 2
|
||||
|
||||
## 5. Files
|
||||
|
||||
[List the files that will be affected by the feature or refactoring task.]
|
||||
|
||||
- **FILE-001**: Description of file 1
|
||||
- **FILE-002**: Description of file 2
|
||||
|
||||
## 6. Testing
|
||||
|
||||
[List the tests that need to be implemented to verify the feature or refactoring task.]
|
||||
|
||||
- **TEST-001**: Description of test 1
|
||||
- **TEST-002**: Description of test 2
|
||||
|
||||
## 7. Risks & Assumptions
|
||||
|
||||
[List any risks or assumptions related to the implementation of the plan.]
|
||||
|
||||
- **RISK-001**: Risk 1
|
||||
- **ASSUMPTION-001**: Assumption 1
|
||||
|
||||
## 8. Related Specifications / Further Reading
|
||||
|
||||
[Link to related spec 1]
|
||||
[Link to relevant external documentation]
|
||||
```
|
||||
210
prompts/create-llms.prompt.md
Normal file
210
prompts/create-llms.prompt.md
Normal file
@ -0,0 +1,210 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create an llms.txt file from scratch based on repository structure following the llms.txt specification at https://llmstxt.org/'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Create LLMs.txt File from Repository Structure
|
||||
|
||||
Create a new `llms.txt` file from scratch in the root of the repository following the official llms.txt specification at https://llmstxt.org/. This file provides high-level guidance to large language models (LLMs) on where to find relevant content for understanding the repository's purpose and specifications.
|
||||
|
||||
## Primary Directive
|
||||
|
||||
Create a comprehensive `llms.txt` file that serves as an entry point for LLMs to understand and navigate the repository effectively. The file must comply with the llms.txt specification and be optimized for LLM consumption while remaining human-readable.
|
||||
|
||||
## Analysis and Planning Phase
|
||||
|
||||
Before creating the `llms.txt` file, you must complete a thorough analysis:
|
||||
|
||||
### Step 1: Review llms.txt Specification
|
||||
|
||||
- Review the official specification at https://llmstxt.org/ to ensure full compliance
|
||||
- Understand the required format structure and guidelines
|
||||
- Note the specific markdown structure requirements
|
||||
|
||||
### Step 2: Repository Structure Analysis
|
||||
|
||||
- Examine the complete repository structure using appropriate tools
|
||||
- Identify the primary purpose and scope of the repository
|
||||
- Catalog all important directories and their purposes
|
||||
- List key files that would be valuable for LLM understanding
|
||||
|
||||
### Step 3: Content Discovery
|
||||
|
||||
- Identify README files and their locations
|
||||
- Find documentation files (`.md` files in `/docs/`, `/spec/`, etc.)
|
||||
- Locate specification files and their purposes
|
||||
- Discover configuration files and their relevance
|
||||
- Find example files and code samples
|
||||
- Identify any existing documentation structure
|
||||
|
||||
### Step 4: Create Implementation Plan
|
||||
|
||||
Based on your analysis, create a structured plan that includes:
|
||||
|
||||
- Repository purpose and scope summary
|
||||
- Priority-ordered list of essential files for LLM understanding
|
||||
- Secondary files that provide additional context
|
||||
- Organizational structure for the llms.txt file
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### Format Compliance
|
||||
|
||||
The `llms.txt` file must follow this exact structure per the specification:
|
||||
|
||||
1. **H1 Header**: Single line with repository/project name (required)
|
||||
2. **Blockquote Summary**: Brief description in blockquote format (optional but recommended)
|
||||
3. **Additional Details**: Zero or more markdown sections without headings for context
|
||||
4. **File List Sections**: Zero or more H2 sections containing markdown lists of links
|
||||
|
||||
### Content Requirements
|
||||
|
||||
#### Required Elements
|
||||
|
||||
- **Project Name**: Clear, descriptive title as H1
|
||||
- **Summary**: Concise blockquote explaining the repository's purpose
|
||||
- **Key Files**: Essential files organized by category (H2 sections)
|
||||
|
||||
#### File Link Format
|
||||
|
||||
Each file link must follow: `[descriptive-name](relative-url): optional description`
|
||||
|
||||
#### Section Organization
|
||||
|
||||
Organize files into logical H2 sections such as:
|
||||
|
||||
- **Documentation**: Core documentation files
|
||||
- **Specifications**: Technical specifications and requirements
|
||||
- **Examples**: Sample code and usage examples
|
||||
- **Configuration**: Setup and configuration files
|
||||
- **Optional**: Secondary files (special meaning - can be skipped for shorter context)
|
||||
|
||||
### Content Guidelines
|
||||
|
||||
#### Language and Style
|
||||
|
||||
- Use concise, clear, unambiguous language
|
||||
- Avoid jargon without explanation
|
||||
- Write for both human and LLM readers
|
||||
- Be specific and informative in descriptions
|
||||
|
||||
#### File Selection Criteria
|
||||
|
||||
Include files that:
|
||||
- Explain the repository's purpose and scope
|
||||
- Provide essential technical documentation
|
||||
- Show usage examples and patterns
|
||||
- Define interfaces and specifications
|
||||
- Contain configuration and setup instructions
|
||||
|
||||
Exclude files that:
|
||||
- Are purely implementation details
|
||||
- Contain redundant information
|
||||
- Are build artifacts or generated content
|
||||
- Are not relevant to understanding the project
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Repository Analysis
|
||||
|
||||
1. Examine the repository structure completely
|
||||
2. Read the main README.md to understand the project
|
||||
3. Identify all documentation directories and files
|
||||
4. Catalog specification files and their purposes
|
||||
5. Find example files and configuration files
|
||||
|
||||
### Step 2: Content Planning
|
||||
|
||||
1. Determine the primary purpose statement
|
||||
2. Write a concise summary for the blockquote
|
||||
3. Group identified files into logical categories
|
||||
4. Prioritize files by importance for LLM understanding
|
||||
5. Create descriptions for each file link
|
||||
|
||||
### Step 3: File Creation
|
||||
|
||||
1. Create the `llms.txt` file in the repository root
|
||||
2. Follow the exact format specification
|
||||
3. Include all required sections
|
||||
4. Use proper markdown formatting
|
||||
5. Ensure all links are valid relative paths
|
||||
|
||||
### Step 4: Validation
|
||||
1. Verify compliance with https://llmstxt.org/ specification
|
||||
2. Check that all links are valid and accessible
|
||||
3. Ensure the file serves as an effective LLM navigation tool
|
||||
4. Confirm the file is both human and machine readable
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
### Format Validation
|
||||
|
||||
- ✅ H1 header with project name
|
||||
- ✅ Blockquote summary (if included)
|
||||
- ✅ H2 sections for file lists
|
||||
- ✅ Proper markdown link format
|
||||
- ✅ No broken or invalid links
|
||||
- ✅ Consistent formatting throughout
|
||||
|
||||
### Content Validation
|
||||
|
||||
- ✅ Clear, unambiguous language
|
||||
- ✅ Comprehensive coverage of essential files
|
||||
- ✅ Logical organization of content
|
||||
- ✅ Appropriate file descriptions
|
||||
- ✅ Serves as effective LLM navigation tool
|
||||
|
||||
### Specification Compliance
|
||||
|
||||
- ✅ Follows https://llmstxt.org/ format exactly
|
||||
- ✅ Uses required markdown structure
|
||||
- ✅ Implements optional sections appropriately
|
||||
- ✅ File located at repository root (`/llms.txt`)
|
||||
|
||||
## Example Structure Template
|
||||
|
||||
```txt
|
||||
# [Repository Name]
|
||||
|
||||
> [Concise description of the repository's purpose and scope]
|
||||
|
||||
[Optional additional context paragraphs without headings]
|
||||
|
||||
## Documentation
|
||||
|
||||
- [Main README](README.md): Primary project documentation and getting started guide
|
||||
- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing to the project
|
||||
- [Code of Conduct](CODE_OF_CONDUCT.md): Community guidelines and expectations
|
||||
|
||||
## Specifications
|
||||
|
||||
- [Technical Specification](spec/technical-spec.md): Detailed technical requirements and constraints
|
||||
- [API Specification](spec/api-spec.md): Interface definitions and data contracts
|
||||
|
||||
## Examples
|
||||
|
||||
- [Basic Example](examples/basic-usage.md): Simple usage demonstration
|
||||
- [Advanced Example](examples/advanced-usage.md): Complex implementation patterns
|
||||
|
||||
## Configuration
|
||||
|
||||
- [Setup Guide](docs/setup.md): Installation and configuration instructions
|
||||
- [Deployment Guide](docs/deployment.md): Production deployment guidelines
|
||||
|
||||
## Optional
|
||||
|
||||
- [Architecture Documentation](docs/architecture.md): Detailed system architecture
|
||||
- [Design Decisions](docs/decisions.md): Historical design decision records
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The created `llms.txt` file should:
|
||||
1. Enable LLMs to quickly understand the repository's purpose
|
||||
2. Provide clear navigation to essential documentation
|
||||
3. Follow the official llms.txt specification exactly
|
||||
4. Be comprehensive yet concise
|
||||
5. Serve both human and machine readers effectively
|
||||
6. Include all critical files for project understanding
|
||||
7. Use clear, unambiguous language throughout
|
||||
8. Organize content logically for easy consumption
|
||||
193
prompts/create-oo-component-documentation.prompt.md
Normal file
193
prompts/create-oo-component-documentation.prompt.md
Normal file
@ -0,0 +1,193 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create comprehensive, standardized documentation for object-oriented components following industry best practices and architectural documentation standards.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Generate Standard OO Component Documentation
|
||||
|
||||
Create comprehensive documentation for the object-oriented component(s) at: `${input:ComponentPath}`.
|
||||
|
||||
Analyze the component by examining code in the provided path. If folder, analyze all source files. If single file, treat as main component and analyze related files in same directory.
|
||||
|
||||
## Documentation Standards
|
||||
|
||||
- DOC-001: Follow C4 Model documentation levels (Context, Containers, Components, Code)
|
||||
- DOC-002: Align with Arc42 software architecture documentation template
|
||||
- DOC-003: Comply with IEEE 1016 Software Design Description standard
|
||||
- DOC-004: Use Agile Documentation principles (just enough documentation that adds value)
|
||||
- DOC-005: Target developers and maintainers as primary audience
|
||||
|
||||
## Analysis Instructions
|
||||
|
||||
- ANA-001: Determine path type (folder vs single file) and identify primary component
|
||||
- ANA-002: Examine source code files for class structures and inheritance
|
||||
- ANA-003: Identify design patterns and architectural decisions
|
||||
- ANA-004: Document public APIs, interfaces, and dependencies
|
||||
- ANA-005: Recognize creational/structural/behavioral patterns
|
||||
- ANA-006: Document method parameters, return values, exceptions
|
||||
- ANA-007: Assess performance, security, reliability, maintainability
|
||||
- ANA-008: Infer integration patterns and data flow
|
||||
|
||||
## Language-Specific Optimizations
|
||||
|
||||
- LNG-001: **C#/.NET** - async/await, dependency injection, configuration, disposal
|
||||
- LNG-002: **Java** - Spring framework, annotations, exception handling, packaging
|
||||
- LNG-003: **TypeScript/JavaScript** - modules, async patterns, types, npm
|
||||
- LNG-004: **Python** - packages, virtual environments, type hints, testing
|
||||
|
||||
## Error Handling
|
||||
|
||||
- ERR-001: Path doesn't exist - provide correct format guidance
|
||||
- ERR-002: No source files found - suggest alternative locations
|
||||
- ERR-003: Unclear structure - document findings and request clarification
|
||||
- ERR-004: Non-standard patterns - document custom approaches
|
||||
- ERR-005: Insufficient code - focus on available information, highlight gaps
|
||||
|
||||
## Output Format
|
||||
|
||||
Generate well-structured Markdown with clear heading hierarchy, code blocks, tables, bullet points, and proper formatting for readability and maintainability.
|
||||
|
||||
## File Location
|
||||
|
||||
The documentation should be saved in the `/docs/components/` directory and named according to the convention: `[component-name]-documentation.md`.
|
||||
|
||||
## Required Documentation Structure
|
||||
|
||||
The documentation file must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
|
||||
|
||||
```md
|
||||
---
|
||||
title: [Component Name] - Technical Documentation
|
||||
component_path: `${input:ComponentPath}`
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this component]
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `component`,`service`,`tool`,`infrastructure`,`documentation`,`architecture` etc]
|
||||
---
|
||||
|
||||
# [Component Name] Documentation
|
||||
|
||||
[A short concise introduction to the component and its purpose within the system.]
|
||||
|
||||
## 1. Component Overview
|
||||
|
||||
### Purpose/Responsibility
|
||||
- OVR-001: State component's primary responsibility
|
||||
- OVR-002: Define scope (included/excluded functionality)
|
||||
- OVR-003: Describe system context and relationships
|
||||
|
||||
## 2. Architecture Section
|
||||
|
||||
- ARC-001: Document design patterns used (Repository, Factory, Observer, etc.)
|
||||
- ARC-002: List internal and external dependencies with purposes
|
||||
- ARC-003: Document component interactions and relationships
|
||||
- ARC-004: Include visual diagrams (UML class, sequence, component)
|
||||
- ARC-005: Create mermaid diagram showing component structure, relationships, and dependencies
|
||||
|
||||
### Component Structure and Dependencies Diagram
|
||||
|
||||
Include a comprehensive mermaid diagram that shows:
|
||||
- **Component structure** - Main classes, interfaces, and their relationships
|
||||
- **Internal dependencies** - How components interact within the system
|
||||
- **External dependencies** - External libraries, services, databases, APIs
|
||||
- **Data flow** - Direction of dependencies and interactions
|
||||
- **Inheritance/composition** - Class hierarchies and composition relationships
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Component System"
|
||||
A[Main Component] --> B[Internal Service]
|
||||
A --> C[Internal Repository]
|
||||
B --> D[Business Logic]
|
||||
C --> E[Data Access Layer]
|
||||
end
|
||||
|
||||
subgraph "External Dependencies"
|
||||
F[External API]
|
||||
G[Database]
|
||||
H[Third-party Library]
|
||||
I[Configuration Service]
|
||||
end
|
||||
|
||||
A --> F
|
||||
E --> G
|
||||
B --> H
|
||||
A --> I
|
||||
|
||||
classDiagram
|
||||
class MainComponent {
|
||||
+property: Type
|
||||
+method(): ReturnType
|
||||
+asyncMethod(): Promise~Type~
|
||||
}
|
||||
class InternalService {
|
||||
+businessOperation(): Result
|
||||
}
|
||||
class ExternalAPI {
|
||||
<<external>>
|
||||
+apiCall(): Data
|
||||
}
|
||||
|
||||
MainComponent --> InternalService
|
||||
MainComponent --> ExternalAPI
|
||||
```
|
||||
|
||||
## 3. Interface Documentation
|
||||
|
||||
- INT-001: Document all public interfaces and usage patterns
|
||||
- INT-002: Create method/property reference table
|
||||
- INT-003: Document events/callbacks/notification mechanisms
|
||||
|
||||
| Method/Property | Purpose | Parameters | Return Type | Usage Notes |
|
||||
|-----------------|---------|------------|-------------|-------------|
|
||||
| [Name] | [Purpose] | [Parameters] | [Type] | [Notes] |
|
||||
|
||||
## 4. Implementation Details
|
||||
|
||||
- IMP-001: Document main implementation classes and responsibilities
|
||||
- IMP-002: Describe configuration requirements and initialization
|
||||
- IMP-003: Document key algorithms and business logic
|
||||
- IMP-004: Note performance characteristics and bottlenecks
|
||||
|
||||
## 5. Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
|
||||
```csharp
|
||||
// Basic usage example
|
||||
var component = new ComponentName();
|
||||
component.DoSomething();
|
||||
```
|
||||
|
||||
### Advanced Usage
|
||||
|
||||
```csharp
|
||||
// Advanced configuration patterns
|
||||
var options = new ComponentOptions();
|
||||
var component = ComponentFactory.Create(options);
|
||||
await component.ProcessAsync(data);
|
||||
```
|
||||
|
||||
- USE-001: Provide basic usage examples
|
||||
- USE-002: Show advanced configuration patterns
|
||||
- USE-003: Document best practices and recommended patterns
|
||||
|
||||
## 6. Quality Attributes
|
||||
|
||||
- QUA-001: Security (authentication, authorization, data protection)
|
||||
- QUA-002: Performance (characteristics, scalability, resource usage)
|
||||
- QUA-003: Reliability (error handling, fault tolerance, recovery)
|
||||
- QUA-004: Maintainability (standards, testing, documentation)
|
||||
- QUA-005: Extensibility (extension points, customization options)
|
||||
|
||||
## 7. Reference Information
|
||||
|
||||
- REF-001: List dependencies with versions and purposes
|
||||
- REF-002: Complete configuration options reference
|
||||
- REF-003: Testing guidelines and mock setup
|
||||
- REF-004: Troubleshooting (common issues, error messages)
|
||||
- REF-005: Related documentation links
|
||||
- REF-006: Change history and migration notes
|
||||
|
||||
```
|
||||
127
prompts/create-specification.prompt.md
Normal file
127
prompts/create-specification.prompt.md
Normal file
@ -0,0 +1,127 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Create a new specification file for the solution, optimized for Generative AI consumption.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Create Specification
|
||||
|
||||
Your goal is to create a new specification file for `${input:SpecPurpose}`.
|
||||
|
||||
The specification file must define the requirements, constraints, and interfaces for the solution components in a manner that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and ensure the content is machine-readable and self-contained.
|
||||
|
||||
## Best Practices for AI-Ready Specifications
|
||||
|
||||
- Use precise, explicit, and unambiguous language.
|
||||
- Clearly distinguish between requirements, constraints, and recommendations.
|
||||
- Use structured formatting (headings, lists, tables) for easy parsing.
|
||||
- Avoid idioms, metaphors, or context-dependent references.
|
||||
- Define all acronyms and domain-specific terms.
|
||||
- Include examples and edge cases where applicable.
|
||||
- Ensure the document is self-contained and does not rely on external context.
|
||||
|
||||
The specification should be saved in the [/spec/](/spec/) directory and named according to the following convention: `spec-[a-z0-9-]+.md`, where the name should be descriptive of the specification's content and starting with the highlevel purpose, which is one of [schema, tool, data, infrastructure, process, architecture, or design].
|
||||
|
||||
The specification file must be formatted in well formed Markdown.
|
||||
|
||||
Specification files must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
|
||||
|
||||
```md
|
||||
---
|
||||
title: [Concise Title Describing the Specification's Focus]
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
[A short concise introduction to the specification and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Purpose & Scope
|
||||
|
||||
[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
|
||||
|
||||
## 2. Definitions
|
||||
|
||||
[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
|
||||
|
||||
## 3. Requirements, Constraints & Guidelines
|
||||
|
||||
[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
|
||||
|
||||
- **REQ-001**: Requirement 1
|
||||
- **SEC-001**: Security Requirement 1
|
||||
- **[3 LETTERS]-001**: Other Requirement 1
|
||||
- **CON-001**: Constraint 1
|
||||
- **GUD-001**: Guideline 1
|
||||
- **PAT-001**: Pattern to follow 1
|
||||
|
||||
## 4. Interfaces & Data Contracts
|
||||
|
||||
[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
|
||||
|
||||
## 5. Acceptance Criteria
|
||||
|
||||
[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
|
||||
|
||||
- **AC-001**: Given [context], When [action], Then [expected outcome]
|
||||
- **AC-002**: The system shall [specific behavior] when [condition]
|
||||
- **AC-003**: [Additional acceptance criteria as needed]
|
||||
|
||||
## 6. Test Automation Strategy
|
||||
|
||||
[Define the testing approach, frameworks, and automation requirements.]
|
||||
|
||||
- **Test Levels**: Unit, Integration, End-to-End
|
||||
- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
|
||||
- **Test Data Management**: [approach for test data creation and cleanup]
|
||||
- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
|
||||
- **Coverage Requirements**: [minimum code coverage thresholds]
|
||||
- **Performance Testing**: [approach for load and performance testing]
|
||||
|
||||
## 7. Rationale & Context
|
||||
|
||||
[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
|
||||
|
||||
## 8. Dependencies & External Integrations
|
||||
|
||||
[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]
|
||||
|
||||
### External Systems
|
||||
- **EXT-001**: [External system name] - [Purpose and integration type]
|
||||
|
||||
### Third-Party Services
|
||||
- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
|
||||
|
||||
### Infrastructure Dependencies
|
||||
- **INF-001**: [Infrastructure component] - [Requirements and constraints]
|
||||
|
||||
### Data Dependencies
|
||||
- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
|
||||
|
||||
### Technology Platform Dependencies
|
||||
- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
|
||||
|
||||
### Compliance Dependencies
|
||||
- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]
|
||||
|
||||
**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".
|
||||
|
||||
## 9. Examples & Edge Cases
|
||||
|
||||
```code
|
||||
// Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
|
||||
```
|
||||
|
||||
## 10. Validation Criteria
|
||||
|
||||
[List the criteria or tests that must be satisfied for compliance with this specification.]
|
||||
|
||||
## 11. Related Specifications / Further Reading
|
||||
|
||||
[Link to related spec 1]
|
||||
[Link to relevant external documentation]
|
||||
|
||||
```
|
||||
156
prompts/create-spring-boot-java-project.prompt.md
Normal file
156
prompts/create-spring-boot-java-project.prompt.md
Normal file
@ -0,0 +1,156 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'findTestFiles', 'problems', 'runCommands', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'testFailure', 'usages']
|
||||
description: 'Create Spring Boot Java project skeleton'
|
||||
---
|
||||
|
||||
# Create Spring Boot Java project prompt
|
||||
|
||||
- Please make sure you have the following software installed on your system:
|
||||
|
||||
- Java 21
|
||||
- Docker
|
||||
- Docker Compose
|
||||
|
||||
- If you need to custom the project name, please change the `artifactId` and the `packageName` in [download-spring-boot-project-template](./create-spring-boot-java-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
- If you need to update the Spring Boot version, please change the `bootVersion` in [download-spring-boot-project-template](./create-spring-boot-java-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
## Check Java version
|
||||
|
||||
- Run following command in terminal and check the version of Java
|
||||
|
||||
```shell
|
||||
java -version
|
||||
```
|
||||
|
||||
## Download Spring Boot project template
|
||||
|
||||
- Run following command in terminal to download a Spring Boot project template
|
||||
|
||||
```shell
|
||||
curl https://start.spring.io/starter.zip \
|
||||
-d artifactId=demo \
|
||||
-d bootVersion=3.4.5 \
|
||||
-d dependencies=lombok,configuration-processor,web,data-jpa,postgresql,data-redis,data-mongodb,validation,cache,testcontainers \
|
||||
-d javaVersion=21 \
|
||||
-d packageName=com.example \
|
||||
-d packaging=jar \
|
||||
-d type=maven-project \
|
||||
-o starter.zip
|
||||
```
|
||||
|
||||
## Unzip the downloaded file
|
||||
|
||||
- Run following command in terminal to unzip the downloaded file
|
||||
|
||||
```shell
|
||||
unzip starter.zip -d .
|
||||
```
|
||||
|
||||
## Remove the downloaded zip file
|
||||
|
||||
- Run following command in terminal to delete the downloaded zip file
|
||||
|
||||
```shell
|
||||
rm -f starter.zip
|
||||
```
|
||||
|
||||
## Add additional dependencies
|
||||
|
||||
- Insert `springdoc-openapi-starter-webmvc-ui` and `archunit-junit5` dependency into `pom.xml` file
|
||||
|
||||
```xml
|
||||
<dependency>
|
||||
<groupId>org.springdoc</groupId>
|
||||
<artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
|
||||
<version>2.8.6</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>com.tngtech.archunit</groupId>
|
||||
<artifactId>archunit-junit5</artifactId>
|
||||
<version>1.2.1</version>
|
||||
<scope>test</scope>
|
||||
</dependency>
|
||||
```
|
||||
|
||||
## Add SpringDoc, Redis, JPA and MongoDB configurations
|
||||
|
||||
- Insert SpringDoc configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# SpringDoc configurations
|
||||
springdoc.swagger-ui.doc-expansion=none
|
||||
springdoc.swagger-ui.operations-sorter=alpha
|
||||
springdoc.swagger-ui.tags-sorter=alpha
|
||||
```
|
||||
|
||||
- Insert Redis configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# Redis configurations
|
||||
spring.data.redis.host=localhost
|
||||
spring.data.redis.port=6379
|
||||
spring.data.redis.password=rootroot
|
||||
```
|
||||
|
||||
- Insert JPA configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# JPA configurations
|
||||
spring.datasource.driver-class-name=org.postgresql.Driver
|
||||
spring.datasource.url=jdbc:postgresql://localhost:5432/postgres
|
||||
spring.datasource.username=postgres
|
||||
spring.datasource.password=rootroot
|
||||
spring.jpa.hibernate.ddl-auto=update
|
||||
spring.jpa.show-sql=true
|
||||
spring.jpa.properties.hibernate.format_sql=true
|
||||
```
|
||||
|
||||
- Insert MongoDB configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# MongoDB configurations
|
||||
spring.data.mongodb.host=localhost
|
||||
spring.data.mongodb.port=27017
|
||||
spring.data.mongodb.authentication-database=admin
|
||||
spring.data.mongodb.username=root
|
||||
spring.data.mongodb.password=rootroot
|
||||
spring.data.mongodb.database=test
|
||||
```
|
||||
|
||||
## Add `docker-compose.yaml` with Redis, PostgreSQL and MongoDB services
|
||||
|
||||
- Create `docker-compose.yaml` at project root and add following services: `redis:6`, `postgresql:17` and `mongo:8`.
|
||||
|
||||
- redis service should have
|
||||
- password `rootroot`
|
||||
- mapping port 6379 to 6379
|
||||
- mounting volume `./redis_data` to `/data`
|
||||
- postgresql service should have
|
||||
- password `rootroot`
|
||||
- mapping port 5432 to 5432
|
||||
- mounting volume `./postgres_data` to `/var/lib/postgresql/data`
|
||||
- mongo service should have
|
||||
- initdb root username `root`
|
||||
- initdb root password `rootroot`
|
||||
- mapping port 27017 to 27017
|
||||
- mounting volume `./mongo_data` to `/data/db`
|
||||
|
||||
## Add `.gitignore` file
|
||||
|
||||
- Insert `redis_data`, `postgres_data` and `mongo_data` directories in `.gitignore` file
|
||||
|
||||
## Run Maven test command
|
||||
|
||||
- Run maven clean test command to check if the project is working
|
||||
|
||||
```shell
|
||||
./mvnw clean test
|
||||
```
|
||||
|
||||
## Run Maven run command (Optional)
|
||||
|
||||
- (Optional) `docker-compose up -d` to start the services, `./mvnw spring-boot:run` to run the Spring Boot project, `docker-compose rm -sf` to stop the services.
|
||||
|
||||
## Let's do this step by step
|
||||
140
prompts/create-spring-boot-kotlin-project.prompt.md
Normal file
140
prompts/create-spring-boot-kotlin-project.prompt.md
Normal file
@ -0,0 +1,140 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'findTestFiles', 'problems', 'runCommands', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'testFailure', 'usages']
|
||||
description: 'Create Spring Boot Kotlin project skeleton'
|
||||
---
|
||||
|
||||
# Create Spring Boot Kotlin project prompt
|
||||
|
||||
- Please make sure you have the following software installed on your system:
|
||||
|
||||
- Java 21
|
||||
- Docker
|
||||
- Docker Compose
|
||||
|
||||
- If you need to custom the project name, please change the `artifactId` and the `packageName` in [download-spring-boot-project-template](./create-spring-boot-kotlin-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
- If you need to update the Spring Boot version, please change the `bootVersion` in [download-spring-boot-project-template](./create-spring-boot-kotlin-project.prompt.md#download-spring-boot-project-template)
|
||||
|
||||
## Check Java version
|
||||
|
||||
- Run following command in terminal and check the version of Java
|
||||
|
||||
```shell
|
||||
java -version
|
||||
```
|
||||
|
||||
## Download Spring Boot project template
|
||||
|
||||
- Run following command in terminal to download a Spring Boot project template
|
||||
|
||||
```shell
|
||||
curl https://start.spring.io/starter.zip \
|
||||
-d artifactId=demo \
|
||||
-d bootVersion=3.4.5 \
|
||||
-d dependencies=configuration-processor,webflux,data-r2dbc,postgresql,data-redis-reactive,data-mongodb-reactive,validation,cache,testcontainers \
|
||||
-d javaVersion=21 \
|
||||
-d language=kotlin \
|
||||
-d packageName=com.example \
|
||||
-d packaging=jar \
|
||||
-d type=gradle-project-kotlin \
|
||||
-o starter.zip
|
||||
```
|
||||
|
||||
## Unzip the downloaded file
|
||||
|
||||
- Run following command in terminal to unzip the downloaded file
|
||||
|
||||
```shell
|
||||
unzip starter.zip -d .
|
||||
```
|
||||
|
||||
## Remove the downloaded zip file
|
||||
|
||||
- Run following command in terminal to delete the downloaded zip file
|
||||
|
||||
```shell
|
||||
rm -f starter.zip
|
||||
```
|
||||
|
||||
## Add additional dependencies
|
||||
|
||||
- Insert `springdoc-openapi-starter-webmvc-ui` and `archunit-junit5` dependency into `build.gradle.kts` file
|
||||
|
||||
```gradle.kts
|
||||
dependencies {
|
||||
implementation("org.springdoc:springdoc-openapi-starter-webflux-ui:2.8.6")
|
||||
testImplementation("com.tngtech.archunit:archunit-junit5:1.2.1")
|
||||
}
|
||||
```
|
||||
|
||||
- Insert SpringDoc configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# SpringDoc configurations
|
||||
springdoc.swagger-ui.doc-expansion=none
|
||||
springdoc.swagger-ui.operations-sorter=alpha
|
||||
springdoc.swagger-ui.tags-sorter=alpha
|
||||
```
|
||||
|
||||
- Insert Redis configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# Redis configurations
|
||||
spring.data.redis.host=localhost
|
||||
spring.data.redis.port=6379
|
||||
spring.data.redis.password=rootroot
|
||||
```
|
||||
|
||||
- Insert R2DBC configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# R2DBC configurations
|
||||
spring.r2dbc.url=r2dbc:postgresql://localhost:5432/postgres
|
||||
spring.r2dbc.username=postgres
|
||||
spring.r2dbc.password=rootroot
|
||||
|
||||
spring.sql.init.mode=always
|
||||
spring.sql.init.platform=postgres
|
||||
spring.sql.init.continue-on-error=true
|
||||
```
|
||||
|
||||
- Insert MongoDB configurations into `application.properties` file
|
||||
|
||||
```properties
|
||||
# MongoDB configurations
|
||||
spring.data.mongodb.host=localhost
|
||||
spring.data.mongodb.port=27017
|
||||
spring.data.mongodb.authentication-database=admin
|
||||
spring.data.mongodb.username=root
|
||||
spring.data.mongodb.password=rootroot
|
||||
spring.data.mongodb.database=test
|
||||
```
|
||||
|
||||
- Create `docker-compose.yaml` at project root and add following services: `redis:6`, `postgresql:17` and `mongo:8`.
|
||||
|
||||
- redis service should have
|
||||
- password `rootroot`
|
||||
- mapping port 6379 to 6379
|
||||
- mounting volume `./redis_data` to `/data`
|
||||
- postgresql service should have
|
||||
- password `rootroot`
|
||||
- mapping port 5432 to 5432
|
||||
- mounting volume `./postgres_data` to `/var/lib/postgresql/data`
|
||||
- mongo service should have
|
||||
- initdb root username `root`
|
||||
- initdb root password `rootroot`
|
||||
- mapping port 27017 to 27017
|
||||
- mounting volume `./mongo_data` to `/data/db`
|
||||
|
||||
- Insert `redis_data`, `postgres_data` and `mongo_data` directories in `.gitignore` file
|
||||
|
||||
- Run gradle clean test command to check if the project is working
|
||||
|
||||
```shell
|
||||
./graldew clean test
|
||||
```
|
||||
|
||||
- (Optional) `docker-compose up -d` to start the services, `./graldew spring-boot:run` to run the Spring Boot project, `docker-compose rm -sf` to stop the services.
|
||||
|
||||
Let's do this step by step.
|
||||
84
prompts/dotnet-best-practices.prompt.md
Normal file
84
prompts/dotnet-best-practices.prompt.md
Normal file
@ -0,0 +1,84 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Ensure .NET/C# code meets best practices for the solution/project.'
|
||||
---
|
||||
# .NET/C# Best Practices
|
||||
|
||||
Your task is to ensure .NET/C# code in ${selection} meets the best practices specific to this solution/project. This includes:
|
||||
|
||||
## Documentation & Structure
|
||||
|
||||
- Create comprehensive XML documentation comments for all public classes, interfaces, methods, and properties
|
||||
- Include parameter descriptions and return value descriptions in XML comments
|
||||
- Follow the established namespace structure: {Core|Console|App|Service}.{Feature}
|
||||
|
||||
## Design Patterns & Architecture
|
||||
|
||||
- Use primary constructor syntax for dependency injection (e.g., `public class MyClass(IDependency dependency)`)
|
||||
- Implement the Command Handler pattern with generic base classes (e.g., `CommandHandler<TOptions>`)
|
||||
- Use interface segregation with clear naming conventions (prefix interfaces with 'I')
|
||||
- Follow the Factory pattern for complex object creation.
|
||||
|
||||
## Dependency Injection & Services
|
||||
|
||||
- Use constructor dependency injection with null checks via ArgumentNullException
|
||||
- Register services with appropriate lifetimes (Singleton, Scoped, Transient)
|
||||
- Use Microsoft.Extensions.DependencyInjection patterns
|
||||
- Implement service interfaces for testability
|
||||
|
||||
## Resource Management & Localization
|
||||
|
||||
- Use ResourceManager for localized messages and error strings
|
||||
- Separate LogMessages and ErrorMessages resource files
|
||||
- Access resources via `_resourceManager.GetString("MessageKey")`
|
||||
|
||||
## Async/Await Patterns
|
||||
|
||||
- Use async/await for all I/O operations and long-running tasks
|
||||
- Return Task or Task<T> from async methods
|
||||
- Use ConfigureAwait(false) where appropriate
|
||||
- Handle async exceptions properly
|
||||
|
||||
## Testing Standards
|
||||
|
||||
- Use MSTest framework with FluentAssertions for assertions
|
||||
- Follow AAA pattern (Arrange, Act, Assert)
|
||||
- Use Moq for mocking dependencies
|
||||
- Test both success and failure scenarios
|
||||
- Include null parameter validation tests
|
||||
|
||||
## Configuration & Settings
|
||||
|
||||
- Use strongly-typed configuration classes with data annotations
|
||||
- Implement validation attributes (Required, NotEmptyOrWhitespace)
|
||||
- Use IConfiguration binding for settings
|
||||
- Support appsettings.json configuration files
|
||||
|
||||
## Semantic Kernel & AI Integration
|
||||
|
||||
- Use Microsoft.SemanticKernel for AI operations
|
||||
- Implement proper kernel configuration and service registration
|
||||
- Handle AI model settings (ChatCompletion, Embedding, etc.)
|
||||
- Use structured output patterns for reliable AI responses
|
||||
|
||||
## Error Handling & Logging
|
||||
|
||||
- Use structured logging with Microsoft.Extensions.Logging
|
||||
- Include scoped logging with meaningful context
|
||||
- Throw specific exceptions with descriptive messages
|
||||
- Use try-catch blocks for expected failure scenarios
|
||||
|
||||
## Performance & Security
|
||||
|
||||
- Use C# 12+ features and .NET 8 optimizations where applicable
|
||||
- Implement proper input validation and sanitization
|
||||
- Use parameterized queries for database operations
|
||||
- Follow secure coding practices for AI/ML operations
|
||||
|
||||
## Code Quality
|
||||
|
||||
- Ensure SOLID principles compliance
|
||||
- Avoid code duplication through base classes and utilities
|
||||
- Use meaningful names that reflect domain concepts
|
||||
- Keep methods focused and cohesive
|
||||
- Implement proper disposal patterns for resources
|
||||
41
prompts/dotnet-design-pattern-review.prompt.md
Normal file
41
prompts/dotnet-design-pattern-review.prompt.md
Normal file
@ -0,0 +1,41 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Review the C#/.NET code for design pattern implementation and suggest improvements.'
|
||||
---
|
||||
# .NET/C# Design Pattern Review
|
||||
|
||||
Review the C#/.NET code in ${selection} for design pattern implementation and suggest improvements for the solution/project. Do not make any changes to the code, just provide a review.
|
||||
|
||||
## Required Design Patterns
|
||||
|
||||
- **Command Pattern**: Generic base classes (`CommandHandler<TOptions>`), `ICommandHandler<TOptions>` interface, `CommandHandlerOptions` inheritance, static `SetupCommand(IHost host)` methods
|
||||
- **Factory Pattern**: Complex object creation service provider integration
|
||||
- **Dependency Injection**: Primary constructor syntax, `ArgumentNullException` null checks, interface abstractions, proper service lifetimes
|
||||
- **Repository Pattern**: Async data access interfaces provider abstractions for connections
|
||||
- **Provider Pattern**: External service abstractions (database, AI), clear contracts, configuration handling
|
||||
- **Resource Pattern**: ResourceManager for localized messages, separate .resx files (LogMessages, ErrorMessages)
|
||||
|
||||
## Review Checklist
|
||||
|
||||
- **Design Patterns**: Identify patterns used. Are Command Handler, Factory, Provider, and Repository patterns correctly implemented? Missing beneficial patterns?
|
||||
- **Architecture**: Follow namespace conventions (`{Core|Console|App|Service}.{Feature}`)? Proper separation between Core/Console projects? Modular and readable?
|
||||
- **.NET Best Practices**: Primary constructors, async/await with Task returns, ResourceManager usage, structured logging, strongly-typed configuration?
|
||||
- **GoF Patterns**: Command, Factory, Template Method, Strategy patterns correctly implemented?
|
||||
- **SOLID Principles**: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion violations?
|
||||
- **Performance**: Proper async/await, resource disposal, ConfigureAwait(false), parallel processing opportunities?
|
||||
- **Maintainability**: Clear separation of concerns, consistent error handling, proper configuration usage?
|
||||
- **Testability**: Dependencies abstracted via interfaces, mockable components, async testability, AAA pattern compatibility?
|
||||
- **Security**: Input validation, secure credential handling, parameterized queries, safe exception handling?
|
||||
- **Documentation**: XML docs for public APIs, parameter/return descriptions, resource file organization?
|
||||
- **Code Clarity**: Meaningful names reflecting domain concepts, clear intent through patterns, self-explanatory structure?
|
||||
- **Clean Code**: Consistent style, appropriate method/class size, minimal complexity, eliminated duplication?
|
||||
|
||||
## Improvement Focus Areas
|
||||
|
||||
- **Command Handlers**: Validation in base class, consistent error handling, proper resource management
|
||||
- **Factories**: Dependency configuration, service provider integration, disposal patterns
|
||||
- **Providers**: Connection management, async patterns, exception handling and logging
|
||||
- **Configuration**: Data annotations, validation attributes, secure sensitive value handling
|
||||
- **AI/ML Integration**: Semantic Kernel patterns, structured output handling, model configuration
|
||||
|
||||
Provide specific, actionable recommendations for improvements aligned with the project's architecture and .NET best practices.
|
||||
70
prompts/suggest-awesome-github-copilot-chatmodes.prompt.md
Normal file
70
prompts/suggest-awesome-github-copilot-chatmodes.prompt.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: '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.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'github']
|
||||
---
|
||||
|
||||
# Suggest Awesome GitHub Copilot Chatmodes
|
||||
|
||||
Analyze current repository context and suggest relevant chatmode files from the [GitHub awesome-copilot repository](https://github.com/github/awesome-copilot/tree/main/chatmodes) that are not already available in this repository.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Fetch Available Chatmodes**: Extract chatmode list and descriptions from [awesome-copilot chatmodes folder](https://github.com/github/awesome-copilot/tree/main/chatmodes)
|
||||
2. **Scan Local Chatmodes**: Discover existing chatmode files in `.github/chatmodes/` folder
|
||||
3. **Extract Descriptions**: Read front matter from local chatmode files to get descriptions
|
||||
4. **Analyze Context**: Review chat history, repository files, and current project needs
|
||||
5. **Compare Existing**: Check against chatmodes already available in this repository
|
||||
6. **Match Relevance**: Compare available chatmodes against identified patterns and requirements
|
||||
7. **Present Options**: Display relevant chatmodes with descriptions, rationale, and availability status
|
||||
8. **Validate**: Ensure suggested chatmodes would add value not already covered by existing chatmodes
|
||||
9. **Output**: Provide structured table with suggestions, descriptions, and links to both awesome-copilot chatmodes and similar local chatmodes
|
||||
10. **Next Steps**: If any suggestions are made, provide instructions that GitHub Copilot will be able to follow to add the suggested chatmodes to the repository by downloading the file into the chatmodes directory. Offer to do this automatically if the user confirms.
|
||||
|
||||
## Context Analysis Criteria
|
||||
|
||||
🔍 **Repository Patterns**:
|
||||
- Programming languages used (.cs, .js, .py, etc.)
|
||||
- Framework indicators (ASP.NET, React, Azure, etc.)
|
||||
- Project types (web apps, APIs, libraries, tools)
|
||||
- Documentation needs (README, specs, ADRs)
|
||||
|
||||
🗨️ **Chat History Context**:
|
||||
- Recent discussions and pain points
|
||||
- Feature requests or implementation needs
|
||||
- Code review patterns
|
||||
- Development workflow requirements
|
||||
|
||||
## Output Format
|
||||
|
||||
Display analysis results in structured table comparing awesome-copilot chatmodes with existing repository chatmodes:
|
||||
|
||||
| Awesome-Copilot Chatmode | Description | Already Installed | Similar Local Chatmode | Suggestion Rationale |
|
||||
|---------------------------|-------------|-------------------|-------------------------|---------------------|
|
||||
| [code-reviewer.chatmode.md](https://github.com/github/awesome-copilot/blob/main/chatmodes/code-reviewer.chatmode.md) | Specialized code review chatmode | ❌ No | None | Would enhance development workflow with dedicated code review assistance |
|
||||
| [architect.chatmode.md](https://github.com/github/awesome-copilot/blob/main/chatmodes/architect.chatmode.md) | Software architecture guidance | ✅ Yes | azure_principal_architect.chatmode.md | Already covered by existing architecture chatmodes |
|
||||
| [debugging-expert.chatmode.md](https://github.com/github/awesome-copilot/blob/main/chatmodes/debugging-expert.chatmode.md) | Debug assistance chatmode | ❌ No | None | Could improve troubleshooting efficiency for development team |
|
||||
|
||||
## Local Chatmodes Discovery Process
|
||||
|
||||
1. List all `*.chatmode.md` files in `.github/chatmodes/` directory
|
||||
2. For each discovered file, read front matter to extract `description`
|
||||
3. Build comprehensive inventory of existing chatmodes
|
||||
4. Use this inventory to avoid suggesting duplicates
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use `githubRepo` tool to get content from awesome-copilot repository chatmodes folder
|
||||
- Scan local file system for existing chatmodes in `.github/chatmodes/` directory
|
||||
- Read YAML front matter from local chatmode files to extract descriptions
|
||||
- Compare against existing chatmodes in this repository to avoid duplicates
|
||||
- Focus on gaps in current chatmode library coverage
|
||||
- Validate that suggested chatmodes align with repository's purpose and standards
|
||||
- Provide clear rationale for each suggestion
|
||||
- Include links to both awesome-copilot chatmodes and similar local chatmodes
|
||||
- Don't provide any additional information or context beyond the table and the analysis
|
||||
|
||||
## Icons Reference
|
||||
|
||||
- ✅ Already installed in repo
|
||||
- ❌ Not installed in repo
|
||||
70
prompts/suggest-awesome-github-copilot-prompts.prompt.md
Normal file
70
prompts/suggest-awesome-github-copilot-prompts.prompt.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: '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.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'github']
|
||||
---
|
||||
# Suggest Awesome GitHub Copilot Prompts
|
||||
|
||||
Analyze current repository context and suggest relevant prompt files from the [GitHub awesome-copilot repository](https://github.com/github/awesome-copilot/tree/main/prompts) that are not already available in this repository.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Fetch Available Prompts**: Extract prompt list and descriptions from [awesome-copilot README](https://github.com/github/awesome-copilot/blob/main/README.md)
|
||||
2. **Scan Local Prompts**: Discover existing prompt files in `.github/prompts/` folder
|
||||
3. **Extract Descriptions**: Read front matter from local prompt files to get descriptions
|
||||
4. **Analyze Context**: Review chat history, repository files, and current project needs
|
||||
5. **Compare Existing**: Check against prompts already available in this repository
|
||||
6. **Match Relevance**: Compare available prompts against identified patterns and requirements
|
||||
7. **Present Options**: Display relevant prompts with descriptions, rationale, and availability status
|
||||
8. **Validate**: Ensure suggested prompts would add value not already covered by existing prompts
|
||||
9. **Output**: Provide structured table with suggestions, descriptions, and links to both awesome-copilot prompts and similar local prompts
|
||||
10. **Next Steps**: If any suggestions are made, provide instructions that GitHub Copilot will be able to follow to add the suggested prompts to the repository by downloading the file into the prompts directory. Offer to do this automatically if the user confirms.
|
||||
|
||||
## Context Analysis Criteria
|
||||
|
||||
🔍 **Repository Patterns**:
|
||||
- Programming languages used (.cs, .js, .py, etc.)
|
||||
- Framework indicators (ASP.NET, React, Azure, etc.)
|
||||
- Project types (web apps, APIs, libraries, tools)
|
||||
- Documentation needs (README, specs, ADRs)
|
||||
|
||||
🗨️ **Chat History Context**:
|
||||
- Recent discussions and pain points
|
||||
- Feature requests or implementation needs
|
||||
- Code review patterns
|
||||
- Development workflow requirements
|
||||
|
||||
## Output Format
|
||||
|
||||
Display analysis results in structured table comparing awesome-copilot prompts with existing repository prompts:
|
||||
|
||||
| Awesome-Copilot Prompt | Description | Already Installed | Similar Local Prompt | Suggestion Rationale |
|
||||
|-------------------------|-------------|-------------------|---------------------|---------------------|
|
||||
| [code-review.md](https://github.com/github/awesome-copilot/blob/main/prompts/code-review.md) | Automated code review prompts | ❌ No | None | Would enhance development workflow with standardized code review processes |
|
||||
| [documentation.md](https://github.com/github/awesome-copilot/blob/main/prompts/documentation.md) | Generate project documentation | ✅ Yes | create_oo_component_documentation.prompt.md | Already covered by existing documentation prompts |
|
||||
| [debugging.md](https://github.com/github/awesome-copilot/blob/main/prompts/debugging.md) | Debug assistance prompts | ❌ No | None | Could improve troubleshooting efficiency for development team |
|
||||
|
||||
## Local Prompts Discovery Process
|
||||
|
||||
1. List all `*.prompt.md` files directory `.github/prompts/`.
|
||||
2. For each discovered file, read front matter to extract `description`
|
||||
3. Build comprehensive inventory of existing prompts
|
||||
4. Use this inventory to avoid suggesting duplicates
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use `githubRepo` tool to get content from awesome-copilot repository
|
||||
- Scan local file system for existing prompts in `.github/prompts/` directory
|
||||
- Read YAML front matter from local prompt files to extract descriptions
|
||||
- Compare against existing prompts in this repository to avoid duplicates
|
||||
- Focus on gaps in current prompt library coverage
|
||||
- Validate that suggested prompts align with repository's purpose and standards
|
||||
- Provide clear rationale for each suggestion
|
||||
- Include links to both awesome-copilot prompts and similar local prompts
|
||||
- Don't provide any additional information or context beyond the table and the analysis
|
||||
|
||||
|
||||
## Icons Reference
|
||||
|
||||
- ✅ Already installed in repo
|
||||
- ❌ Not installed in repo
|
||||
48
prompts/update-avm-modules-in-bicep.prompt.md
Normal file
48
prompts/update-avm-modules-in-bicep.prompt.md
Normal file
@ -0,0 +1,48 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Update Azure Verified Modules (AVM) to latest versions in Bicep files.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'fetch', 'runCommands', 'azure_get_deployment_best_practices', 'azure_get_schema_for_Bicep']
|
||||
---
|
||||
# Update Azure Verified Modules in Bicep Files
|
||||
|
||||
Update Bicep file `${file}` to use latest Azure Verified Module (AVM) versions.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Scan**: Extract AVM modules and current versions from `${file}`
|
||||
2. **Check**: Fetch latest versions from MCR: `https://mcr.microsoft.com/v2/bicep/avm/res/{service}/{resource}/tags/list`
|
||||
3. **Compare**: Parse semantic versions to identify updates
|
||||
4. **Review**: For breaking changes, fetch docs from: `https://github.com/Azure/bicep-registry-modules/tree/main/avm/res/{service}/{resource}`
|
||||
5. **Update**: Apply version updates and parameter changes
|
||||
6. **Validate**: Run `bicep lint` to ensure compliance
|
||||
|
||||
## Breaking Change Policy
|
||||
|
||||
⚠️ **PAUSE for approval** if updates involve:
|
||||
|
||||
- Incompatible parameter changes
|
||||
- Security/compliance modifications
|
||||
- Behavioral changes
|
||||
|
||||
## Output Format
|
||||
|
||||
Display results in table with icons:
|
||||
|
||||
| Module | Current | Latest | Status | Action | Docs |
|
||||
|--------|---------|--------|--------|--------|------|
|
||||
| avm/res/compute/vm | 0.1.0 | 0.2.0 | 🔄 | Updated | [📖](link) |
|
||||
| avm/res/storage/account | 0.3.0 | 0.3.0 | ✅ | Current | [📖](link) |
|
||||
|
||||
## Icons
|
||||
|
||||
- 🔄 Updated
|
||||
- ✅ Current
|
||||
- ⚠️ Manual review required
|
||||
- ❌ Failed
|
||||
- 📖 Documentation
|
||||
|
||||
## Requirements
|
||||
|
||||
- Use MCR tags API only for version discovery
|
||||
- Parse JSON tags array and sort by semantic versioning
|
||||
- Maintain Bicep file validity and linting compliance
|
||||
150
prompts/update-implementation-plan.prompt.md
Normal file
150
prompts/update-implementation-plan.prompt.md
Normal file
@ -0,0 +1,150 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: '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.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Update Implementation Plan
|
||||
|
||||
## Primary Directive
|
||||
|
||||
You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
|
||||
|
||||
## Execution Context
|
||||
|
||||
This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
|
||||
|
||||
## Core Requirements
|
||||
|
||||
- Generate implementation plans that are fully executable by AI agents or humans
|
||||
- Use deterministic language with zero ambiguity
|
||||
- Structure all content for automated parsing and execution
|
||||
- Ensure complete self-containment with no external dependencies for understanding
|
||||
|
||||
## Plan Structure Requirements
|
||||
|
||||
Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
|
||||
|
||||
## Phase Architecture
|
||||
|
||||
- Each phase must have measurable completion criteria
|
||||
- Tasks within phases must be executable in parallel unless dependencies are specified
|
||||
- All task descriptions must include specific file paths, function names, and exact implementation details
|
||||
- No task should require human interpretation or decision-making
|
||||
|
||||
## AI-Optimized Implementation Standards
|
||||
|
||||
- Use explicit, unambiguous language with zero interpretation required
|
||||
- Structure all content as machine-parseable formats (tables, lists, structured data)
|
||||
- Include specific file paths, line numbers, and exact code references where applicable
|
||||
- Define all variables, constants, and configuration values explicitly
|
||||
- Provide complete context within each task description
|
||||
- Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
|
||||
- Include validation criteria that can be automatically verified
|
||||
|
||||
## Output File Specifications
|
||||
|
||||
- Save implementation plan files in `/plan/` directory
|
||||
- Use naming convention: `[purpose]-[component]-[version].md`
|
||||
- Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design`
|
||||
- Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md`
|
||||
- File must be valid Markdown with proper front matter structure
|
||||
|
||||
## Mandatory Template Structure
|
||||
|
||||
All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
|
||||
|
||||
## Template Validation Rules
|
||||
|
||||
- All front matter fields must be present and properly formatted
|
||||
- All section headers must match exactly (case-sensitive)
|
||||
- All identifier prefixes must follow the specified format
|
||||
- Tables must include all required columns
|
||||
- No placeholder text may remain in the final output
|
||||
|
||||
```md
|
||||
---
|
||||
goal: [Concise Title Describing the Package Implementation Plan's Goal]
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
[A short concise introduction to the plan and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Requirements & Constraints
|
||||
|
||||
[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
|
||||
|
||||
- **REQ-001**: Requirement 1
|
||||
- **SEC-001**: Security Requirement 1
|
||||
- **[3 LETTERS]-001**: Other Requirement 1
|
||||
- **CON-001**: Constraint 1
|
||||
- **GUD-001**: Guideline 1
|
||||
- **PAT-001**: Pattern to follow 1
|
||||
|
||||
## 2. Implementation Steps
|
||||
|
||||
### Implementation Phase 1
|
||||
|
||||
- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
|
||||
| TASK-002 | Description of task 2 | | |
|
||||
| TASK-003 | Description of task 3 | | |
|
||||
|
||||
### Implementation Phase 2
|
||||
|
||||
- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
|
||||
|
||||
| Task | Description | Completed | Date |
|
||||
|------|-------------|-----------|------|
|
||||
| TASK-004 | Description of task 4 | | |
|
||||
| TASK-005 | Description of task 5 | | |
|
||||
| TASK-006 | Description of task 6 | | |
|
||||
|
||||
## 3. Alternatives
|
||||
|
||||
[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
|
||||
|
||||
- **ALT-001**: Alternative approach 1
|
||||
- **ALT-002**: Alternative approach 2
|
||||
|
||||
## 4. Dependencies
|
||||
|
||||
[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
|
||||
|
||||
- **DEP-001**: Dependency 1
|
||||
- **DEP-002**: Dependency 2
|
||||
|
||||
## 5. Files
|
||||
|
||||
[List the files that will be affected by the feature or refactoring task.]
|
||||
|
||||
- **FILE-001**: Description of file 1
|
||||
- **FILE-002**: Description of file 2
|
||||
|
||||
## 6. Testing
|
||||
|
||||
[List the tests that need to be implemented to verify the feature or refactoring task.]
|
||||
|
||||
- **TEST-001**: Description of test 1
|
||||
- **TEST-002**: Description of test 2
|
||||
|
||||
## 7. Risks & Assumptions
|
||||
|
||||
[List any risks or assumptions related to the implementation of the plan.]
|
||||
|
||||
- **RISK-001**: Risk 1
|
||||
- **ASSUMPTION-001**: Assumption 1
|
||||
|
||||
## 8. Related Specifications / Further Reading
|
||||
|
||||
[Link to related spec 1]
|
||||
[Link to relevant external documentation]
|
||||
```
|
||||
216
prompts/update-llms.prompt.md
Normal file
216
prompts/update-llms.prompt.md
Normal file
@ -0,0 +1,216 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: '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/'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Update LLMs.txt File
|
||||
|
||||
Update the existing `llms.txt` file in the root of the repository to reflect changes in documentation, specifications, or repository structure. This file provides high-level guidance to large language models (LLMs) on where to find relevant content for understanding the repository's purpose and specifications.
|
||||
|
||||
## Primary Directive
|
||||
|
||||
Update the existing `llms.txt` file to maintain accuracy and compliance with the llms.txt specification while reflecting current repository structure and content. The file must remain optimized for LLM consumption while staying human-readable.
|
||||
|
||||
## Analysis and Planning Phase
|
||||
|
||||
Before updating the `llms.txt` file, you must complete a thorough analysis:
|
||||
|
||||
### Step 1: Review Current File and Specification
|
||||
- Read the existing `llms.txt` file to understand current structure
|
||||
- Review the official specification at https://llmstxt.org/ to ensure continued compliance
|
||||
- Identify areas that may need updates based on repository changes
|
||||
|
||||
### Step 2: Repository Structure Analysis
|
||||
- Examine the current repository structure using appropriate tools
|
||||
- Compare current structure with what's documented in existing `llms.txt`
|
||||
- Identify new directories, files, or documentation that should be included
|
||||
- Note any removed or relocated files that need to be updated
|
||||
|
||||
### Step 3: Content Discovery and Change Detection
|
||||
- Identify new README files and their locations
|
||||
- Find new documentation files (`.md` files in `/docs/`, `/spec/`, etc.)
|
||||
- Locate new specification files and their purposes
|
||||
- Discover new configuration files and their relevance
|
||||
- Find new example files and code samples
|
||||
- Identify any changes to existing documentation structure
|
||||
|
||||
### Step 4: Create Update Plan
|
||||
Based on your analysis, create a structured plan that includes:
|
||||
- Changes needed to maintain accuracy
|
||||
- New files to be added to the llms.txt
|
||||
- Outdated references to be removed or updated
|
||||
- Organizational improvements to maintain clarity
|
||||
|
||||
## Implementation Requirements
|
||||
|
||||
### Format Compliance
|
||||
The updated `llms.txt` file must maintain this exact structure per the specification:
|
||||
|
||||
1. **H1 Header**: Single line with repository/project name (required)
|
||||
2. **Blockquote Summary**: Brief description in blockquote format (optional but recommended)
|
||||
3. **Additional Details**: Zero or more markdown sections without headings for context
|
||||
4. **File List Sections**: Zero or more H2 sections containing markdown lists of links
|
||||
|
||||
### Content Requirements
|
||||
|
||||
#### Required Elements
|
||||
- **Project Name**: Clear, descriptive title as H1
|
||||
- **Summary**: Concise blockquote explaining the repository's purpose
|
||||
- **Key Files**: Essential files organized by category (H2 sections)
|
||||
|
||||
#### File Link Format
|
||||
Each file link must follow: `[descriptive-name](relative-url): optional description`
|
||||
|
||||
#### Section Organization
|
||||
Organize files into logical H2 sections such as:
|
||||
- **Documentation**: Core documentation files
|
||||
- **Specifications**: Technical specifications and requirements
|
||||
- **Examples**: Sample code and usage examples
|
||||
- **Configuration**: Setup and configuration files
|
||||
- **Optional**: Secondary files (special meaning - can be skipped for shorter context)
|
||||
|
||||
### Content Guidelines
|
||||
|
||||
#### Language and Style
|
||||
- Use concise, clear, unambiguous language
|
||||
- Avoid jargon without explanation
|
||||
- Write for both human and LLM readers
|
||||
- Be specific and informative in descriptions
|
||||
|
||||
#### File Selection Criteria
|
||||
Include files that:
|
||||
- Explain the repository's purpose and scope
|
||||
- Provide essential technical documentation
|
||||
- Show usage examples and patterns
|
||||
- Define interfaces and specifications
|
||||
- Contain configuration and setup instructions
|
||||
|
||||
Exclude files that:
|
||||
- Are purely implementation details
|
||||
- Contain redundant information
|
||||
- Are build artifacts or generated content
|
||||
- Are not relevant to understanding the project
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Step 1: Current State Analysis
|
||||
1. Read the existing `llms.txt` file thoroughly
|
||||
2. Examine the current repository structure completely
|
||||
3. Compare existing file references with actual repository content
|
||||
4. Identify outdated, missing, or incorrect references
|
||||
5. Note any structural issues with the current file
|
||||
|
||||
### Step 2: Content Planning
|
||||
1. Determine if the primary purpose statement needs updates
|
||||
2. Review and update the summary blockquote if needed
|
||||
3. Plan additions for new files and directories
|
||||
4. Plan removals for outdated or moved content
|
||||
5. Reorganize sections if needed for better clarity
|
||||
|
||||
### Step 3: File Updates
|
||||
1. Update the existing `llms.txt` file in the repository root
|
||||
2. Maintain compliance with the exact format specification
|
||||
3. Add new file references with appropriate descriptions
|
||||
4. Remove or update outdated references
|
||||
5. Ensure all links are valid relative paths
|
||||
|
||||
### Step 4: Validation
|
||||
1. Verify continued compliance with https://llmstxt.org/ specification
|
||||
2. Check that all links are valid and accessible
|
||||
3. Ensure the file still serves as an effective LLM navigation tool
|
||||
4. Confirm the file remains both human and machine readable
|
||||
|
||||
## Quality Assurance
|
||||
|
||||
### Format Validation
|
||||
- ✅ H1 header with project name
|
||||
- ✅ Blockquote summary (if included)
|
||||
- ✅ H2 sections for file lists
|
||||
- ✅ Proper markdown link format
|
||||
- ✅ No broken or invalid links
|
||||
- ✅ Consistent formatting throughout
|
||||
|
||||
### Content Validation
|
||||
- ✅ Clear, unambiguous language
|
||||
- ✅ Comprehensive coverage of essential files
|
||||
- ✅ Logical organization of content
|
||||
- ✅ Appropriate file descriptions
|
||||
- ✅ Serves as effective LLM navigation tool
|
||||
|
||||
### Specification Compliance
|
||||
- ✅ Follows https://llmstxt.org/ format exactly
|
||||
- ✅ Uses required markdown structure
|
||||
- ✅ Implements optional sections appropriately
|
||||
- ✅ File located at repository root (`/llms.txt`)
|
||||
|
||||
## Update Strategy
|
||||
|
||||
### Addition Process
|
||||
When adding new content:
|
||||
1. Identify the appropriate section for new files
|
||||
2. Create clear, descriptive names for links
|
||||
3. Write concise but informative descriptions
|
||||
4. Maintain alphabetical or logical ordering within sections
|
||||
5. Consider if new sections are needed for new content types
|
||||
|
||||
### Removal Process
|
||||
When removing outdated content:
|
||||
1. Verify files are actually removed or relocated
|
||||
2. Check if relocated files should be updated rather than removed
|
||||
3. Remove entire sections if they become empty
|
||||
4. Update cross-references if needed
|
||||
|
||||
### Reorganization Process
|
||||
When restructuring content:
|
||||
1. Maintain logical flow from general to specific
|
||||
2. Keep essential documentation in primary sections
|
||||
3. Move secondary content to "Optional" section if appropriate
|
||||
4. Ensure new organization improves LLM navigation
|
||||
|
||||
Example structure for `llms.txt`:
|
||||
|
||||
```txt
|
||||
# [Repository Name]
|
||||
|
||||
> [Concise description of the repository's purpose and scope]
|
||||
|
||||
[Optional additional context paragraphs without headings]
|
||||
|
||||
## Documentation
|
||||
|
||||
- [Main README](README.md): Primary project documentation and getting started guide
|
||||
- [Contributing Guide](CONTRIBUTING.md): Guidelines for contributing to the project
|
||||
- [Code of Conduct](CODE_OF_CONDUCT.md): Community guidelines and expectations
|
||||
|
||||
## Specifications
|
||||
|
||||
- [Technical Specification](spec/technical-spec.md): Detailed technical requirements and constraints
|
||||
- [API Specification](spec/api-spec.md): Interface definitions and data contracts
|
||||
|
||||
## Examples
|
||||
|
||||
- [Basic Example](examples/basic-usage.md): Simple usage demonstration
|
||||
- [Advanced Example](examples/advanced-usage.md): Complex implementation patterns
|
||||
|
||||
## Configuration
|
||||
|
||||
- [Setup Guide](docs/setup.md): Installation and configuration instructions
|
||||
- [Deployment Guide](docs/deployment.md): Production deployment guidelines
|
||||
|
||||
## Optional
|
||||
|
||||
- [Architecture Documentation](docs/architecture.md): Detailed system architecture
|
||||
- [Design Decisions](docs/decisions.md): Historical design decision records
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The updated `llms.txt` file should:
|
||||
1. Accurately reflect the current repository structure and content
|
||||
2. Maintain compliance with the llms.txt specification
|
||||
3. Provide clear navigation to essential documentation
|
||||
4. Remove outdated or incorrect references
|
||||
5. Include new important files and documentation
|
||||
6. Maintain logical organization for easy LLM consumption
|
||||
7. Use clear, unambiguous language throughout
|
||||
8. Continue to serve both human and machine readers effectively
|
||||
76
prompts/update-markdown-file-index.prompt.md
Normal file
76
prompts/update-markdown-file-index.prompt.md
Normal file
@ -0,0 +1,76 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Update a markdown file section with an index/table of files from a specified folder.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Update Markdown File Index
|
||||
|
||||
Update markdown file `${file}` with an index/table of files from folder `${input:folder}`.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Scan**: Read the target markdown file `${file}` to understand existing structure
|
||||
2. **Discover**: List all files in the specified folder `${input:folder}` matching pattern `${input:pattern}`
|
||||
3. **Analyze**: Identify if an existing table/index section exists to update, or create new structure
|
||||
4. **Structure**: Generate appropriate table/list format based on file types and existing content
|
||||
5. **Update**: Replace existing section or add new section with file index
|
||||
6. **Validate**: Ensure markdown syntax is valid and formatting is consistent
|
||||
|
||||
## File Analysis
|
||||
|
||||
For each discovered file, extract:
|
||||
|
||||
- **Name**: Filename with or without extension based on context
|
||||
- **Type**: File extension and category (e.g., `.md`, `.js`, `.py`)
|
||||
- **Description**: First line comment, header, or inferred purpose
|
||||
- **Size**: File size for reference (optional)
|
||||
- **Modified**: Last modified date (optional)
|
||||
|
||||
## Table Structure Options
|
||||
|
||||
Choose format based on file types and existing content:
|
||||
|
||||
### Option 1: Simple List
|
||||
|
||||
```markdown
|
||||
## Files in ${folder}
|
||||
|
||||
- [filename.ext](path/to/filename.ext) - Description
|
||||
- [filename2.ext](path/to/filename2.ext) - Description
|
||||
```
|
||||
|
||||
### Option 2: Detailed Table
|
||||
|
||||
| File | Type | Description |
|
||||
|------|------|-------------|
|
||||
| [filename.ext](path/to/filename.ext) | Extension | Description |
|
||||
| [filename2.ext](path/to/filename2.ext) | Extension | Description |
|
||||
|
||||
### Option 3: Categorized Sections
|
||||
|
||||
Group files by type/category with separate sections or sub-tables.
|
||||
|
||||
## Update Strategy
|
||||
|
||||
- 🔄 **Update existing**: If table/index section exists, replace content while preserving structure
|
||||
- ➕ **Add new**: If no existing section, create new section using best-fit format
|
||||
- 📋 **Preserve**: Maintain existing markdown formatting, heading levels, and document flow
|
||||
- 🔗 **Links**: Use relative paths for file links within the repository
|
||||
|
||||
## Section Identification
|
||||
|
||||
Look for existing sections with these patterns:
|
||||
|
||||
- Headings containing: "index", "files", "contents", "directory", "list"
|
||||
- Tables with file-related columns
|
||||
- Lists with file links
|
||||
- HTML comments marking file index sections
|
||||
|
||||
## Requirements
|
||||
|
||||
- Preserve existing markdown structure and formatting
|
||||
- Use relative paths for file links
|
||||
- Include file descriptions when available
|
||||
- Sort files alphabetically by default
|
||||
- Handle special characters in filenames
|
||||
- Validate all generated markdown syntax
|
||||
162
prompts/update-oo-component-documentation.prompt.md
Normal file
162
prompts/update-oo-component-documentation.prompt.md
Normal file
@ -0,0 +1,162 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Update existing object-oriented component documentation following industry best practices and architectural documentation standards.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Update Standard OO Component Documentation
|
||||
|
||||
Update the existing documentation file at: `${file}` by analyzing the corresponding component code.
|
||||
|
||||
Extract the component path from the existing documentation's front matter (`component_path` field) or infer it from the documentation content. Analyze the current component implementation and update the documentation accordingly.
|
||||
|
||||
**Documentation Standards:**
|
||||
|
||||
- DOC-001: Follow C4 Model documentation levels (Context, Containers, Components, Code)
|
||||
- DOC-002: Align with Arc42 software architecture documentation template
|
||||
- DOC-003: Comply with IEEE 1016 Software Design Description standard
|
||||
- DOC-004: Use Agile Documentation principles (just enough documentation that adds value)
|
||||
- DOC-005: Target developers and maintainers as primary audience
|
||||
|
||||
**Analysis Instructions:**
|
||||
|
||||
- ANA-001: Read existing documentation to understand component context and structure
|
||||
- ANA-002: Identify component path from front matter or content analysis
|
||||
- ANA-003: Examine current source code files for class structures and inheritance
|
||||
- ANA-004: Compare existing documentation with current implementation
|
||||
- ANA-005: Identify design patterns and architectural changes
|
||||
- ANA-006: Update public APIs, interfaces, and dependencies
|
||||
- ANA-007: Recognize new/changed creational/structural/behavioral patterns
|
||||
- ANA-008: Update method parameters, return values, exceptions
|
||||
- ANA-009: Reassess performance, security, reliability, maintainability
|
||||
- ANA-010: Update integration patterns and data flow
|
||||
|
||||
**Language-Specific Optimizations:**
|
||||
|
||||
- LNG-001: **C#/.NET** - async/await, dependency injection, configuration, disposal
|
||||
- LNG-002: **Java** - Spring framework, annotations, exception handling, packaging
|
||||
- LNG-003: **TypeScript/JavaScript** - modules, async patterns, types, npm
|
||||
- LNG-004: **Python** - packages, virtual environments, type hints, testing
|
||||
|
||||
**Update Strategy:**
|
||||
|
||||
- UPD-001: Preserve existing documentation structure and format
|
||||
- UPD-002: Update `last_updated` field to current date
|
||||
- UPD-003: Maintain version history in front matter if present
|
||||
- UPD-004: Add new sections if component has significantly expanded
|
||||
- UPD-005: Mark deprecated features or breaking changes
|
||||
- UPD-006: Update examples to reflect current API
|
||||
- UPD-007: Refresh dependency lists and versions
|
||||
- UPD-008: Update mermaid diagrams to reflect current architecture
|
||||
|
||||
**Error Handling:**
|
||||
|
||||
- ERR-001: Documentation file doesn't exist - provide guidance on file location
|
||||
- ERR-002: Component path not found in documentation - request clarification
|
||||
- ERR-003: Source code has moved - suggest updated paths
|
||||
- ERR-004: Major architectural changes - highlight breaking changes
|
||||
- ERR-005: Insufficient access to source - document limitations
|
||||
|
||||
**Output Format:**
|
||||
|
||||
Update the existing Markdown file maintaining its structure while refreshing content to match current implementation. Preserve formatting, heading hierarchy, and existing organizational decisions.
|
||||
|
||||
**Required Documentation Structure:**
|
||||
|
||||
Update the existing documentation following the same template structure, ensuring all sections reflect current implementation:
|
||||
|
||||
```md
|
||||
---
|
||||
title: [Component Name] - Technical Documentation
|
||||
component_path: [Current component path]
|
||||
version: [Updated version if applicable]
|
||||
date_created: [Original creation date - preserve]
|
||||
last_updated: [YYYY-MM-DD - update to current date]
|
||||
owner: [Preserve existing or update if changed]
|
||||
tags: [Update tags as needed based on current functionality]
|
||||
---
|
||||
|
||||
# [Component Name] Documentation
|
||||
|
||||
[Update introduction to reflect current component purpose and capabilities]
|
||||
|
||||
## 1. Component Overview
|
||||
|
||||
### Purpose/Responsibility
|
||||
- OVR-001: Update component's primary responsibility
|
||||
- OVR-002: Refresh scope (included/excluded functionality)
|
||||
- OVR-003: Update system context and relationships
|
||||
|
||||
## 2. Architecture Section
|
||||
|
||||
- ARC-001: Update design patterns used (Repository, Factory, Observer, etc.)
|
||||
- ARC-002: Refresh internal and external dependencies with current purposes
|
||||
- ARC-003: Update component interactions and relationships
|
||||
- ARC-004: Update visual diagrams (UML class, sequence, component)
|
||||
- ARC-005: Refresh mermaid diagram showing current component structure, relationships, and dependencies
|
||||
|
||||
### Component Structure and Dependencies Diagram
|
||||
|
||||
Update the mermaid diagram to show current:
|
||||
- **Component structure** - Current classes, interfaces, and their relationships
|
||||
- **Internal dependencies** - How components currently interact within the system
|
||||
- **External dependencies** - Current external libraries, services, databases, APIs
|
||||
- **Data flow** - Current direction of dependencies and interactions
|
||||
- **Inheritance/composition** - Current class hierarchies and composition relationships
|
||||
|
||||
```mermaid
|
||||
[Update diagram to reflect current architecture]
|
||||
```
|
||||
|
||||
## 3. Interface Documentation
|
||||
|
||||
- INT-001: Update all public interfaces and current usage patterns
|
||||
- INT-002: Refresh method/property reference table with current API
|
||||
- INT-003: Update events/callbacks/notification mechanisms
|
||||
|
||||
| Method/Property | Purpose | Parameters | Return Type | Usage Notes |
|
||||
|-----------------|---------|------------|-------------|-------------|
|
||||
| [Update table with current API] | | | | |
|
||||
|
||||
## 4. Implementation Details
|
||||
|
||||
- IMP-001: Update main implementation classes and current responsibilities
|
||||
- IMP-002: Refresh configuration requirements and initialization patterns
|
||||
- IMP-003: Update key algorithms and business logic
|
||||
- IMP-004: Update performance characteristics and bottlenecks
|
||||
|
||||
## 5. Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
|
||||
```csharp
|
||||
// Update basic usage example to current API
|
||||
```
|
||||
|
||||
### Advanced Usage
|
||||
|
||||
```csharp
|
||||
// Update advanced configuration patterns to current implementation
|
||||
```
|
||||
|
||||
- USE-001: Update basic usage examples
|
||||
- USE-002: Refresh advanced configuration patterns
|
||||
- USE-003: Update best practices and recommended patterns
|
||||
|
||||
## 6. Quality Attributes
|
||||
|
||||
- QUA-001: Update security (authentication, authorization, data protection)
|
||||
- QUA-002: Refresh performance (characteristics, scalability, resource usage)
|
||||
- QUA-003: Update reliability (error handling, fault tolerance, recovery)
|
||||
- QUA-004: Refresh maintainability (standards, testing, documentation)
|
||||
- QUA-005: Update extensibility (extension points, customization options)
|
||||
|
||||
## 7. Reference Information
|
||||
|
||||
- REF-001: Update dependencies with current versions and purposes
|
||||
- REF-002: Refresh configuration options reference
|
||||
- REF-003: Update testing guidelines and mock setup
|
||||
- REF-004: Refresh troubleshooting (common issues, error messages)
|
||||
- REF-005: Update related documentation links
|
||||
- REF-006: Add change history and migration notes for this update
|
||||
|
||||
```
|
||||
127
prompts/update-specification.prompt.md
Normal file
127
prompts/update-specification.prompt.md
Normal file
@ -0,0 +1,127 @@
|
||||
---
|
||||
mode: 'agent'
|
||||
description: 'Update an existing specification file for the solution, optimized for Generative AI consumption based on new requirements or updates to any existing code.'
|
||||
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
|
||||
---
|
||||
# Update Specification
|
||||
|
||||
Your goal is to update the existing specification file `${file}` based on new requirements or updates to any existing code.
|
||||
|
||||
The specification file must define the requirements, constraints, and interfaces for the solution components in a manner that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and ensure the content is machine-readable and self-contained.
|
||||
|
||||
## Best Practices for AI-Ready Specifications
|
||||
|
||||
- Use precise, explicit, and unambiguous language.
|
||||
- Clearly distinguish between requirements, constraints, and recommendations.
|
||||
- Use structured formatting (headings, lists, tables) for easy parsing.
|
||||
- Avoid idioms, metaphors, or context-dependent references.
|
||||
- Define all acronyms and domain-specific terms.
|
||||
- Include examples and edge cases where applicable.
|
||||
- Ensure the document is self-contained and does not rely on external context.
|
||||
|
||||
The specification should be saved in the [/spec/](/spec/) directory and named according to the following convention: `[a-z0-9-]+.md`, where the name should be descriptive of the specification's content and starting with the highlevel purpose, which is one of [schema, tool, data, infrastructure, process, architecture, or design].
|
||||
|
||||
The specification file must be formatted in well formed Markdown.
|
||||
|
||||
Specification files must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
|
||||
|
||||
```md
|
||||
---
|
||||
title: [Concise Title Describing the Specification's Focus]
|
||||
version: [Optional: e.g., 1.0, Date]
|
||||
date_created: [YYYY-MM-DD]
|
||||
last_updated: [Optional: YYYY-MM-DD]
|
||||
owner: [Optional: Team/Individual responsible for this spec]
|
||||
tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
|
||||
---
|
||||
|
||||
# Introduction
|
||||
|
||||
[A short concise introduction to the specification and the goal it is intended to achieve.]
|
||||
|
||||
## 1. Purpose & Scope
|
||||
|
||||
[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
|
||||
|
||||
## 2. Definitions
|
||||
|
||||
[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
|
||||
|
||||
## 3. Requirements, Constraints & Guidelines
|
||||
|
||||
[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
|
||||
|
||||
- **REQ-001**: Requirement 1
|
||||
- **SEC-001**: Security Requirement 1
|
||||
- **[3 LETTERS]-001**: Other Requirement 1
|
||||
- **CON-001**: Constraint 1
|
||||
- **GUD-001**: Guideline 1
|
||||
- **PAT-001**: Pattern to follow 1
|
||||
|
||||
## 4. Interfaces & Data Contracts
|
||||
|
||||
[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
|
||||
|
||||
## 5. Acceptance Criteria
|
||||
|
||||
[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
|
||||
|
||||
- **AC-001**: Given [context], When [action], Then [expected outcome]
|
||||
- **AC-002**: The system shall [specific behavior] when [condition]
|
||||
- **AC-003**: [Additional acceptance criteria as needed]
|
||||
|
||||
## 6. Test Automation Strategy
|
||||
|
||||
[Define the testing approach, frameworks, and automation requirements.]
|
||||
|
||||
- **Test Levels**: Unit, Integration, End-to-End
|
||||
- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
|
||||
- **Test Data Management**: [approach for test data creation and cleanup]
|
||||
- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
|
||||
- **Coverage Requirements**: [minimum code coverage thresholds]
|
||||
- **Performance Testing**: [approach for load and performance testing]
|
||||
|
||||
## 7. Rationale & Context
|
||||
|
||||
[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
|
||||
|
||||
## 8. Dependencies & External Integrations
|
||||
|
||||
[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]
|
||||
|
||||
### External Systems
|
||||
- **EXT-001**: [External system name] - [Purpose and integration type]
|
||||
|
||||
### Third-Party Services
|
||||
- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
|
||||
|
||||
### Infrastructure Dependencies
|
||||
- **INF-001**: [Infrastructure component] - [Requirements and constraints]
|
||||
|
||||
### Data Dependencies
|
||||
- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
|
||||
|
||||
### Technology Platform Dependencies
|
||||
- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
|
||||
|
||||
### Compliance Dependencies
|
||||
- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]
|
||||
|
||||
**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".
|
||||
|
||||
## 9. Examples & Edge Cases
|
||||
|
||||
```code
|
||||
// Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
|
||||
```
|
||||
|
||||
## 10. Validation Criteria
|
||||
|
||||
[List the criteria or tests that must be satisfied for compliance with this specification.]
|
||||
|
||||
## 11. Related Specifications / Further Reading
|
||||
|
||||
[Link to related spec 1]
|
||||
[Link to relevant external documentation]
|
||||
|
||||
```
|
||||
Loading…
x
Reference in New Issue
Block a user