Merge branch 'main' into feat/performance-optimization

.github/pull_request_template.md

@@ -1,11 +1,3 @@
----
-name: Pull Request
-about: Submit a contribution to the awesome-copilot repository
-title: ''
-labels: needs-review
-assignees: ''
----
-
 ## Pull Request Checklist
 
 - [ ] I have read and followed the [CONTRIBUTING.md](../CONTRIBUTING.md) guidelines.

README.md

@@ -32,6 +32,7 @@ Team and project-specific instructions to enhance GitHub Copilot's behavior for
 - [.NET MAUI](instructions/dotnet-maui.instructions.md) - .NET MAUI component and application patterns
 - [Genaiscript](instructions/genaiscript.instructions.md) - AI-powered script generation guidelines
 - [Generate Modern Terraform Code For Azure](instructions/generate-modern-terraform-code-for-azure.instructions.md) - Guidelines for generating modern Terraform code for Azure
+- [Go Development Instructions](instructions/go.instructions.md) - Instructions for writing Go code following idiomatic Go practices and community standards
 - [Guidance for Localization](instructions/localization.instructions.md) - Guidelines for localizing markdown documents
 - [Markdown](instructions/markdown.instructions.md) - Documentation and content creation standards
 - [Next.js + Tailwind Development Instructions](instructions/nextjs-tailwind.instructions.md) - Next.js + Tailwind development standards and instructions
@@ -59,6 +60,7 @@ Ready-to-use prompt templates for specific development scenarios and tasks, defi
 - [Multi Stage Dockerfile](prompts/multi-stage-dockerfile.prompt.md) - Create optimized multi-stage Dockerfiles for any language or framework
 - [My Issues](prompts/my-issues.prompt.md) - List my issues in the current repository
 - [My Pull Requests](prompts/my-pull-requests.prompt.md) - List my pull requests in the current repository
+- [Next Intl Add Language](prompts/next-intl-add-language.prompt.md) - Add new language to a Next.js + next-intl application
 
 > 💡 **Usage**: Use `/prompt-name` in VS Code chat, run `Chat: Run Prompt` command, or hit the run button while you have a prompt open.
 
@@ -70,6 +72,7 @@ Custom chat modes define specific behaviors and tools for GitHub Copilot Chat, e
 - [Debug Mode Instructions](chatmodes/debug.chatmode.md) - Debug your application to find and fix a bug
 - [Planning mode instructions](chatmodes/planner.chatmode.md) - Generate an implementation plan for new features or refactoring existing code.
 - [PostgreSQL Database Administrator](chatmodes/postgresql-dba.chatmode.md) - Work with PostgreSQL databases using the PostgreSQL extension.
+- [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.
 - [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
 
 > 💡 **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.

chatmodes/prd.chatmode.md

@@ -0,0 +1,201 @@
+---
+
+description: '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.'
+tools: ['codebase', 'editFiles', 'fetch', 'findTestFiles', 'list_issues', 'githubRepo', 'search', 'add_issue_comment', 'create_issue', 'update_issue', 'get_issue', 'search_issues']
+---
+
+# Create PRD Chat Mode
+
+You are a senior product manager responsible for creating detailed and actionable Product Requirements Documents (PRDs) for software development teams.
+
+Your task is to create a clear, structured, and comprehensive PRD for the project or feature requested by the user.
+
+You will create a file named `prd.md` in the location provided by the user. If the user doesn't specify a location, suggest a default (e.g., the project's root directory) and ask the user to confirm or provide an alternative.
+
+Your output should ONLY be the complete PRD in Markdown format unless explicitly confirmed by the user to create GitHub issues from the documented requirements.
+
+## Instructions for Creating the PRD
+
+1. **Ask clarifying questions**: Before creating the PRD, ask questions to better understand the user's needs.
+   * Identify missing information (e.g., target audience, key features, constraints).
+   * Ask 3-5 questions to reduce ambiguity.
+   * Use a bulleted list for readability.
+   * Phrase questions conversationally (e.g., "To help me create the best PRD, could you clarify...").
+
+2. **Analyze Codebase**: Review the existing codebase to understand the current architecture, identify potential integration points, and assess technical constraints.
+
+3. **Overview**: Begin with a brief explanation of the project's purpose and scope.
+
+4. **Headings**:
+
+   * Use title case for the main document title only (e.g., PRD: {project\_title}).
+   * All other headings should use sentence case.
+
+5. **Structure**: Organize the PRD according to the provided outline (`prd_outline`). Add relevant subheadings as needed.
+
+6. **Detail Level**:
+
+   * Use clear, precise, and concise language.
+   * Include specific details and metrics whenever applicable.
+   * Ensure consistency and clarity throughout the document.
+
+7. **User Stories and Acceptance Criteria**:
+
+   * List ALL user interactions, covering primary, alternative, and edge cases.
+   * Assign a unique requirement ID (e.g., GH-001) to each user story.
+   * Include a user story addressing authentication/security if applicable.
+   * Ensure each user story is testable.
+
+8. **Final Checklist**: Before finalizing, ensure:
+
+   * Every user story is testable.
+   * Acceptance criteria are clear and specific.
+   * All necessary functionality is covered by user stories.
+   * Authentication and authorization requirements are clearly defined, if relevant.
+
+9. **Formatting Guidelines**:
+
+   * Consistent formatting and numbering.
+   * No dividers or horizontal rules.
+   * Format strictly in valid Markdown, free of disclaimers or footers.
+   * Fix any grammatical errors from the user's input and ensure correct casing of names.
+   * Refer to the project conversationally (e.g., "the project," "this feature").
+
+10. **Confirmation and Issue Creation**: After presenting the PRD, ask for the user's approval. Once approved, ask if they would like to create GitHub issues for the user stories. If they agree, create the issues and reply with a list of links to the created issues.
+
+---
+
+# PRD Outline
+
+## PRD: {project\_title}
+
+## 1. Product overview
+
+### 1.1 Document title and version
+
+* PRD: {project\_title}
+* Version: {version\_number}
+
+### 1.2 Product summary
+
+* Brief overview (2-3 short paragraphs).
+
+## 2. Goals
+
+### 2.1 Business goals
+
+* Bullet list.
+
+### 2.2 User goals
+
+* Bullet list.
+
+### 2.3 Non-goals
+
+* Bullet list.
+
+## 3. User personas
+
+### 3.1 Key user types
+
+* Bullet list.
+
+### 3.2 Basic persona details
+
+* **{persona\_name}**: {description}
+
+### 3.3 Role-based access
+
+* **{role\_name}**: {permissions/description}
+
+## 4. Functional requirements
+
+* **{feature\_name}** (Priority: {priority\_level})
+
+  * Specific requirements for the feature.
+
+## 5. User experience
+
+### 5.1 Entry points & first-time user flow
+
+* Bullet list.
+
+### 5.2 Core experience
+
+* **{step\_name}**: {description}
+
+  * How this ensures a positive experience.
+
+### 5.3 Advanced features & edge cases
+
+* Bullet list.
+
+### 5.4 UI/UX highlights
+
+* Bullet list.
+
+## 6. Narrative
+
+Concise paragraph describing the user's journey and benefits.
+
+## 7. Success metrics
+
+### 7.1 User-centric metrics
+
+* Bullet list.
+
+### 7.2 Business metrics
+
+* Bullet list.
+
+### 7.3 Technical metrics
+
+* Bullet list.
+
+## 8. Technical considerations
+
+### 8.1 Integration points
+
+* Bullet list.
+
+### 8.2 Data storage & privacy
+
+* Bullet list.
+
+### 8.3 Scalability & performance
+
+* Bullet list.
+
+### 8.4 Potential challenges
+
+* Bullet list.
+
+## 9. Milestones & sequencing
+
+### 9.1 Project estimate
+
+* {Size}: {time\_estimate}
+
+### 9.2 Team size & composition
+
+* {Team size}: {roles involved}
+
+### 9.3 Suggested phases
+
+* **{Phase number}**: {description} ({time\_estimate})
+
+  * Key deliverables.
+
+## 10. User stories
+
+### 10.{x}. {User story title}
+
+* **ID**: {user\_story\_id}
+* **Description**: {user\_story\_description}
+* **Acceptance criteria**:
+
+  * Bullet list of criteria.
+
+---
+
+After generating the PRD, I will ask if you want to proceed with creating GitHub issues for the user stories. If you agree, I will create them and provide you with the links.

instructions/go.instructions.md

@@ -0,0 +1,292 @@
+---
+description: 'Instructions for writing Go code following idiomatic Go practices and community standards'
+applyTo: '**/*.go,**/go.mod,**/go.sum'
+---
+
+# Go Development Instructions
+
+Follow idiomatic Go practices and community standards when writing Go code. These instructions are based on [Effective Go](https://go.dev/doc/effective_go), [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments), and [Google's Go Style Guide](https://google.github.io/styleguide/go/).
+
+## General Instructions
+
+- Write simple, clear, and idiomatic Go code
+- Favor clarity and simplicity over cleverness
+- Follow the principle of least surprise
+- Keep the happy path left-aligned (minimize indentation)
+- Return early to reduce nesting
+- Make the zero value useful
+- Document exported types, functions, methods, and packages
+- Use Go modules for dependency management
+
+## Naming Conventions
+
+### Packages
+
+- Use lowercase, single-word package names
+- Avoid underscores, hyphens, or mixedCaps
+- Choose names that describe what the package provides, not what it contains
+- Avoid generic names like `util`, `common`, or `base`
+- Package names should be singular, not plural
+
+### Variables and Functions
+
+- Use mixedCaps or MixedCaps (camelCase) rather than underscores
+- Keep names short but descriptive
+- Use single-letter variables only for very short scopes (like loop indices)
+- Exported names start with a capital letter
+- Unexported names start with a lowercase letter
+- Avoid stuttering (e.g., avoid `http.HTTPServer`, prefer `http.Server`)
+
+### Interfaces
+
+- Name interfaces with -er suffix when possible (e.g., `Reader`, `Writer`, `Formatter`)
+- Single-method interfaces should be named after the method (e.g., `Read` → `Reader`)
+- Keep interfaces small and focused
+
+### Constants
+
+- Use MixedCaps for exported constants
+- Use mixedCaps for unexported constants
+- Group related constants using `const` blocks
+- Consider using typed constants for better type safety
+
+## Code Style and Formatting
+
+### Formatting
+
+- Always use `gofmt` to format code
+- Use `goimports` to manage imports automatically
+- Keep line length reasonable (no hard limit, but consider readability)
+- Add blank lines to separate logical groups of code
+
+### Comments
+
+- Write comments in complete sentences
+- Start sentences with the name of the thing being described
+- Package comments should start with "Package [name]"
+- Use line comments (`//`) for most comments
+- Use block comments (`/* */`) sparingly, mainly for package documentation
+- Document why, not what, unless the what is complex
+
+### Error Handling
+
+- Check errors immediately after the function call
+- Don't ignore errors using `_` unless you have a good reason (document why)
+- Wrap errors with context using `fmt.Errorf` with `%w` verb
+- Create custom error types when you need to check for specific errors
+- Place error returns as the last return value
+- Name error variables `err`
+- Keep error messages lowercase and don't end with punctuation
+
+## Architecture and Project Structure
+
+### Package Organization
+
+- Follow standard Go project layout conventions
+- Keep `main` packages in `cmd/` directory
+- Put reusable packages in `pkg/` or `internal/`
+- Use `internal/` for packages that shouldn't be imported by external projects
+- Group related functionality into packages
+- Avoid circular dependencies
+
+### Dependency Management
+
+- Use Go modules (`go.mod` and `go.sum`)
+- Keep dependencies minimal
+- Regularly update dependencies for security patches
+- Use `go mod tidy` to clean up unused dependencies
+- Vendor dependencies only when necessary
+
+## Type Safety and Language Features
+
+### Type Definitions
+
+- Define types to add meaning and type safety
+- Use struct tags for JSON, XML, database mappings
+- Prefer explicit type conversions
+- Use type assertions carefully and check the second return value
+
+### Pointers vs Values
+
+- Use pointers for large structs or when you need to modify the receiver
+- Use values for small structs and when immutability is desired
+- Be consistent within a type's method set
+- Consider the zero value when choosing pointer vs value receivers
+
+### Interfaces and Composition
+
+- Accept interfaces, return concrete types
+- Keep interfaces small (1-3 methods is ideal)
+- Use embedding for composition
+- Define interfaces close to where they're used, not where they're implemented
+- Don't export interfaces unless necessary
+
+## Concurrency
+
+### Goroutines
+
+- Don't create goroutines in libraries; let the caller control concurrency
+- Always know how a goroutine will exit
+- Use `sync.WaitGroup` or channels to wait for goroutines
+- Avoid goroutine leaks by ensuring cleanup
+
+### Channels
+
+- Use channels to communicate between goroutines
+- Don't communicate by sharing memory; share memory by communicating
+- Close channels from the sender side, not the receiver
+- Use buffered channels when you know the capacity
+- Use `select` for non-blocking operations
+
+### Synchronization
+
+- Use `sync.Mutex` for protecting shared state
+- Keep critical sections small
+- Use `sync.RWMutex` when you have many readers
+- Prefer channels over mutexes when possible
+- Use `sync.Once` for one-time initialization
+
+## Error Handling Patterns
+
+### Creating Errors
+
+- Use `errors.New` for simple static errors
+- Use `fmt.Errorf` for dynamic errors
+- Create custom error types for domain-specific errors
+- Export error variables for sentinel errors
+- Use `errors.Is` and `errors.As` for error checking
+
+### Error Propagation
+
+- Add context when propagating errors up the stack
+- Don't log and return errors (choose one)
+- Handle errors at the appropriate level
+- Consider using structured errors for better debugging
+
+## API Design
+
+### HTTP Handlers
+
+- Use `http.HandlerFunc` for simple handlers
+- Implement `http.Handler` for handlers that need state
+- Use middleware for cross-cutting concerns
+- Set appropriate status codes and headers
+- Handle errors gracefully and return appropriate error responses
+
+### JSON APIs
+
+- Use struct tags to control JSON marshaling
+- Validate input data
+- Use pointers for optional fields
+- Consider using `json.RawMessage` for delayed parsing
+- Handle JSON errors appropriately
+
+## Performance Optimization
+
+### Memory Management
+
+- Minimize allocations in hot paths
+- Reuse objects when possible (consider `sync.Pool`)
+- Use value receivers for small structs
+- Preallocate slices when size is known
+- Avoid unnecessary string conversions
+
+### Profiling
+
+- Use built-in profiling tools (`pprof`)
+- Benchmark critical code paths
+- Profile before optimizing
+- Focus on algorithmic improvements first
+- Consider using `testing.B` for benchmarks
+
+## Testing
+
+### Test Organization
+
+- Keep tests in the same package (white-box testing)
+- Use `_test` package suffix for black-box testing
+- Name test files with `_test.go` suffix
+- Place test files next to the code they test
+
+### Writing Tests
+
+- Use table-driven tests for multiple test cases
+- Name tests descriptively using `Test_functionName_scenario`
+- Use subtests with `t.Run` for better organization
+- Test both success and error cases
+- Use `testify` or similar libraries sparingly
+
+### Test Helpers
+
+- Mark helper functions with `t.Helper()`
+- Create test fixtures for complex setup
+- Use `testing.TB` interface for functions used in tests and benchmarks
+- Clean up resources using `t.Cleanup()`
+
+## Security Best Practices
+
+### Input Validation
+
+- Validate all external input
+- Use strong typing to prevent invalid states
+- Sanitize data before using in SQL queries
+- Be careful with file paths from user input
+- Validate and escape data for different contexts (HTML, SQL, shell)
+
+### Cryptography
+
+- Use standard library crypto packages
+- Don't implement your own cryptography
+- Use crypto/rand for random number generation
+- Store passwords using bcrypt or similar
+- Use TLS for network communication
+
+## Documentation
+
+### Code Documentation
+
+- Document all exported symbols
+- Start documentation with the symbol name
+- Use examples in documentation when helpful
+- Keep documentation close to code
+- Update documentation when code changes
+
+### README and Documentation Files
+
+- Include clear setup instructions
+- Document dependencies and requirements
+- Provide usage examples
+- Document configuration options
+- Include troubleshooting section
+
+## Tools and Development Workflow
+
+### Essential Tools
+
+- `go fmt`: Format code
+- `go vet`: Find suspicious constructs
+- `golint` or `golangci-lint`: Additional linting
+- `go test`: Run tests
+- `go mod`: Manage dependencies
+- `go generate`: Code generation
+
+### Development Practices
+
+- Run tests before committing
+- Use pre-commit hooks for formatting and linting
+- Keep commits focused and atomic
+- Write meaningful commit messages
+- Review diffs before committing
+
+## Common Pitfalls to Avoid
+
+- Not checking errors
+- Ignoring race conditions
+- Creating goroutine leaks
+- Not using defer for cleanup
+- Modifying maps concurrently
+- Not understanding nil interfaces vs nil pointers
+- Forgetting to close resources (files, connections)
+- Using global variables unnecessarily
+- Over-using empty interfaces (`interface{}`)
+- Not considering the zero value of types

prompts/next-intl-add-language.prompt.md

@@ -0,0 +1,20 @@
+---
+mode: 'agent'
+tools: ['changes','codebase', 'editFiles', 'findTestFiles', 'search', 'writeTest']
+description: 'Add new language to a Next.js + next-intl application'
+---
+
+This is a guide to add a new language to a Next.js project using next-intl for internationalization,
+
+- For i18n, the application uses next-intl.
+- All translations are in the directory `./messages`.
+- The UI component is `src/components/language-toggle.tsx`.
+- Routing and middleware configuration are handled in:
+  - `src/i18n/routing.ts`
+  - `src/middleware.ts`
+
+When adding a new language:
+
+- Translate all the content of `en.json` to the new language. The goal is to have all the JSON entries in the new language for a complete translation.
+- Add the path in `routing.ts` and `middleware.ts`.
+- Add the language to `language-toggle.tsx`.