Initial setup of repo with prompts and instructions

instructions/angular.md

@@ -0,0 +1,104 @@
+---
+description: |
+  Angular-specific coding standards and best practices
+---
+
+# Angular Development Instructions
+
+Instructions for generating high-quality Angular applications with TypeScript, using Angular Signals for state management, adhering to Angular best practices as outlined at https://angular.dev.
+
+## Project Context
+- Latest Angular version (use standalone components by default)
+- TypeScript for type safety
+- Angular CLI for project setup and scaffolding
+- Follow Angular Style Guide (https://angular.dev/style-guide)
+- Use Angular Material or other modern UI libraries for consistent styling (if specified)
+
+## Development Standards
+
+### Architecture
+- Use standalone components unless modules are explicitly required
+- Organize code by feature modules or domains for scalability
+- Implement lazy loading for feature modules to optimize performance
+- Use Angular's built-in dependency injection system effectively
+- Structure components with a clear separation of concerns (smart vs. presentational components)
+
+### TypeScript
+- Enable strict mode in `tsconfig.json` for type safety
+- Define clear interfaces and types for components, services, and models
+- Use type guards and union types for robust type checking
+- Implement proper error handling with RxJS operators (e.g., `catchError`)
+- Use typed forms (e.g., `FormGroup`, `FormControl`) for reactive forms
+
+### Component Design
+- Follow Angular's component lifecycle hooks best practices
+- Use `@Input()` and `@Output()` for component communication
+- Leverage Angular's change detection strategy (default or `OnPush` for performance)
+- Keep templates clean and logic in component classes or services
+- Use Angular directives and pipes for reusable functionality
+
+### Styling
+- Use Angular's component-level CSS encapsulation (default: ViewEncapsulation.Emulated)
+- Prefer SCSS for styling with consistent theming
+- Implement responsive design using CSS Grid, Flexbox, or Angular CDK Layout utilities
+- Follow Angular Material's theming guidelines if used
+- Maintain accessibility (a11y) with ARIA attributes and semantic HTML
+
+### State Management
+- Use Angular Signals for reactive state management in components and services
+- Leverage `signal()`, `computed()`, and `effect()` for reactive state updates
+- Use writable signals for mutable state and computed signals for derived state
+- Handle loading and error states with signals and proper UI feedback
+- Use Angular's `AsyncPipe` to handle observables in templates when combining signals with RxJS
+
+### Data Fetching
+- Use Angular's `HttpClient` for API calls with proper typing
+- Implement RxJS operators for data transformation and error handling
+- Use Angular's `inject()` function for dependency injection in standalone components
+- Implement caching strategies (e.g., `shareReplay` for observables)
+- Store API response data in signals for reactive updates
+- Handle API errors with global interceptors for consistent error handling
+
+### Security
+- Sanitize user inputs using Angular's built-in sanitization
+- Implement route guards for authentication and authorization
+- Use Angular's `HttpInterceptor` for CSRF protection and API authentication headers
+- Validate form inputs with Angular's reactive forms and custom validators
+- Follow Angular's security best practices (e.g., avoid direct DOM manipulation)
+
+### Performance
+- Enable production builds with `ng build --prod` for optimization
+- Use lazy loading for routes to reduce initial bundle size
+- Optimize change detection with `OnPush` strategy and signals for fine-grained reactivity
+- Use trackBy in `ngFor` loops to improve rendering performance
+- Implement server-side rendering (SSR) or static site generation (SSG) with Angular Universal (if specified)
+
+### Testing
+- Write unit tests for components, services, and pipes using Jasmine and Karma
+- Use Angular's `TestBed` for component testing with mocked dependencies
+- Test signal-based state updates using Angular's testing utilities
+- Write end-to-end tests with Cypress or Playwright (if specified)
+- Mock HTTP requests using `HttpClientTestingModule`
+- Ensure high test coverage for critical functionality
+
+## Implementation Process
+1. Plan project structure and feature modules
+2. Define TypeScript interfaces and models
+3. Scaffold components, services, and pipes using Angular CLI
+4. Implement data services and API integrations with signal-based state
+5. Build reusable components with clear inputs and outputs
+6. Add reactive forms and validation
+7. Apply styling with SCSS and responsive design
+8. Implement lazy-loaded routes and guards
+9. Add error handling and loading states using signals
+10. Write unit and end-to-end tests
+11. Optimize performance and bundle size
+
+## Additional Guidelines
+- Follow Angular's naming conventions (e.g., `feature.component.ts`, `feature.service.ts`)
+- Use Angular CLI commands for generating boilerplate code
+- Document components and services with clear JSDoc comments
+- Ensure accessibility compliance (WCAG 2.1) where applicable
+- Use Angular's built-in i18n for internationalization (if specified)
+- Keep code DRY by creating reusable utilities and shared modules
+- Use signals consistently for state management to ensure reactive updates

instructions/aspnet-rest-apis.md

@@ -0,0 +1,109 @@
+---
+description: Guidelines for building REST APIs with ASP.NET
+---
+
+# ASP.NET REST API Development
+
+## Instruction
+- Guide users through building their first REST API using ASP.NET Core 9.
+- Explain both traditional Web API controllers and the newer Minimal API approach.
+- Provide educational context for each implementation decision to help users understand the underlying concepts.
+- Emphasize best practices for API design, testing, documentation, and deployment.
+- Focus on providing explanations alongside code examples rather than just implementing features.
+
+## API Design Fundamentals
+
+- Explain REST architectural principles and how they apply to ASP.NET Core APIs.
+- Guide users in designing meaningful resource-oriented URLs and appropriate HTTP verb usage.
+- Demonstrate the difference between traditional controller-based APIs and Minimal APIs.
+- Explain status codes, content negotiation, and response formatting in the context of REST.
+- Help users understand when to choose Controllers vs. Minimal APIs based on project requirements.
+
+## Project Setup and Structure
+
+- Guide users through creating a new ASP.NET Core 9 Web API project with the appropriate templates.
+- Explain the purpose of each generated file and folder to build understanding of the project structure.
+- Demonstrate how to organize code using feature folders or domain-driven design principles.
+- Show proper separation of concerns with models, services, and data access layers.
+- Explain the Program.cs and configuration system in ASP.NET Core 9 including environment-specific settings.
+
+## Building Controller-Based APIs
+
+- Guide the creation of RESTful controllers with proper resource naming and HTTP verb implementation.
+- Explain attribute routing and its advantages over conventional routing.
+- Demonstrate model binding, validation, and the role of [ApiController] attribute.
+- Show how dependency injection works within controllers.
+- Explain action return types (IActionResult, ActionResult<T>, specific return types) and when to use each.
+
+## Implementing Minimal APIs
+
+- Guide users through implementing the same endpoints using the Minimal API syntax.
+- Explain the endpoint routing system and how to organize route groups.
+- Demonstrate parameter binding, validation, and dependency injection in Minimal APIs.
+- Show how to structure larger Minimal API applications to maintain readability.
+- Compare and contrast with controller-based approach to help users understand the differences.
+
+## Data Access Patterns
+
+- Guide the implementation of a data access layer using Entity Framework Core.
+- Explain different options (SQL Server, SQLite, In-Memory) for development and production.
+- Demonstrate repository pattern implementation and when it's beneficial.
+- Show how to implement database migrations and data seeding.
+- Explain efficient query patterns to avoid common performance issues.
+
+## Authentication and Authorization
+
+- Guide users through implementing authentication using JWT Bearer tokens.
+- Explain OAuth 2.0 and OpenID Connect concepts as they relate to ASP.NET Core.
+- Show how to implement role-based and policy-based authorization.
+- Demonstrate integration with Microsoft Entra ID (formerly Azure AD).
+- Explain how to secure both controller-based and Minimal APIs consistently.
+
+## Validation and Error Handling
+
+- Guide the implementation of model validation using data annotations and FluentValidation.
+- Explain the validation pipeline and how to customize validation responses.
+- Demonstrate a global exception handling strategy using middleware.
+- Show how to create consistent error responses across the API.
+- Explain problem details (RFC 7807) implementation for standardized error responses.
+
+## API Versioning and Documentation
+
+- Guide users through implementing and explaining API versioning strategies.
+- Demonstrate Swagger/OpenAPI implementation with proper documentation.
+- Show how to document endpoints, parameters, responses, and authentication.
+- Explain versioning in both controller-based and Minimal APIs.
+- Guide users on creating meaningful API documentation that helps consumers.
+
+## Logging and Monitoring
+
+- Guide the implementation of structured logging using Serilog or other providers.
+- Explain the logging levels and when to use each.
+- Demonstrate integration with Application Insights for telemetry collection.
+- Show how to implement custom telemetry and correlation IDs for request tracking.
+- Explain how to monitor API performance, errors, and usage patterns.
+
+## Testing REST APIs
+
+- Guide users through creating unit tests for controllers, Minimal API endpoints, and services.
+- Explain integration testing approaches for API endpoints.
+- Demonstrate how to mock dependencies for effective testing.
+- Show how to test authentication and authorization logic.
+- Explain test-driven development principles as applied to API development.
+
+## Performance Optimization
+
+- Guide users on implementing caching strategies (in-memory, distributed, response caching).
+- Explain asynchronous programming patterns and why they matter for API performance.
+- Demonstrate pagination, filtering, and sorting for large data sets.
+- Show how to implement compression and other performance optimizations.
+- Explain how to measure and benchmark API performance.
+
+## Deployment and DevOps
+
+- Guide users through containerizing their API using .NET's built-in container support (`dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer`).
+- Explain the differences between manual Dockerfile creation and .NET's container publishing features.
+- Explain CI/CD pipelines for ASP.NET Core applications.
+- Demonstrate deployment to Azure App Service, Azure Container Apps, or other hosting options.
+- Show how to implement health checks and readiness probes.
+- Explain environment-specific configurations for different deployment stages.

instructions/azure-functions-typescript.md

@@ -0,0 +1,13 @@
+---
+description: TypeScript patterns for Azure Functions
+---
+
+## Guidance for Code Generation
+- Generate modern TypeScript code for Node.js
+- Use `async/await` for asynchronous code
+- Whenever possible, use Node.js v20 built-in modules instead of external packages
+- Always use Node.js async functions, like `node:fs/promises` instead of `fs` to avoid blocking the event loop
+- Ask before adding any extra dependencies to the project
+- The API is built using Azure Functions using `@azure/functions@4` package.
+- Each endpoint should have its own function file, and use the following naming convention: `src/functions/<resource-name>-<http-verb>.ts`
+- When making changes to the API, make sure to update the OpenAPI schema (if it exists) and `README.md` file accordingly.

instructions/bicep-code-best-practices.md

@@ -0,0 +1,54 @@
+---
+description: Infrastructure as Code with Bicep
+applyTo: "**/*.bicep"
+---
+
+## Naming Conventions
+
+-   When writing Bicep code, use lowerCamelCase for all names (variables, parameters, resources)
+-   Use resource type descriptive symbolic names (e.g., 'storageAccount' not 'storageAccountName')
+-   Avoid using 'name' in a symbolic name as it represents the resource, not the resource's name
+-   Avoid distinguishing variables and parameters by the use of suffixes
+
+## Structure and Declaration
+
+-   Always declare parameters at the top of files with @description decorators
+-   Use latest stable API versions for all resources
+-   Use descriptive @description decorators for all parameters
+-   Specify minimum and maximum character length for naming parameters
+
+## Parameters
+
+-   Set default values that are safe for test environments (use low-cost pricing tiers)
+-   Use @allowed decorator sparingly to avoid blocking valid deployments
+-   Use parameters for settings that change between deployments
+
+## Variables
+
+-   Variables automatically infer type from the resolved value
+-   Use variables to contain complex expressions instead of embedding them directly in resource properties
+
+## Resource References
+
+-   Use symbolic names for resource references instead of reference() or resourceId() functions
+-   Create resource dependencies through symbolic names (resourceA.id) not explicit dependsOn
+-   For accessing properties from other resources, use the 'existing' keyword instead of passing values through outputs
+
+## Resource Names
+
+-   Use template expressions with uniqueString() to create meaningful and unique resource names
+-   Add prefixes to uniqueString() results since some resources don't allow names starting with numbers
+
+## Child Resources
+
+-   Avoid excessive nesting of child resources
+-   Use parent property or nesting instead of constructing resource names for child resources
+
+## Security
+
+-   Never include secrets or keys in outputs
+-   Use resource properties directly in outputs (e.g., storageAccount.properties.primaryEndpoints)
+
+## Documentation
+
+-   Include helpful // comments within your Bicep files to improve readability

instructions/blazor.md

@@ -0,0 +1,77 @@
+---
+description: Blazor component and application patterns
+appliesTo: "**/*.razor, **/*.cs"
+---
+
+## Blazor Code Style and Structure
+
+- Write idiomatic and efficient Blazor and C# code.
+- Follow .NET and Blazor conventions.
+- Use Razor Components appropriately for component-based UI development.
+- Prefer inline functions for smaller components but separate complex logic into code-behind or service classes.
+- Async/await should be used where applicable to ensure non-blocking UI operations.
+
+## Naming Conventions
+
+- Follow PascalCase for component names, method names, and public members.
+- Use camelCase for private fields and local variables.
+- Prefix interface names with "I" (e.g., IUserService).
+
+## Blazor and .NET Specific Guidelines
+
+- Utilize Blazor's built-in features for component lifecycle (e.g., OnInitializedAsync, OnParametersSetAsync).
+- Use data binding effectively with @bind.
+- Leverage Dependency Injection for services in Blazor.
+- Structure Blazor components and services following Separation of Concerns.
+- Use C# 10+ features like record types, pattern matching, and global usings.
+
+## Error Handling and Validation
+
+- Implement proper error handling for Blazor pages and API calls.
+- Use logging for error tracking in the backend and consider capturing UI-level errors in Blazor with tools like ErrorBoundary.
+- Implement validation using FluentValidation or DataAnnotations in forms.
+
+## Blazor API and Performance Optimization
+
+- Utilize Blazor server-side or WebAssembly optimally based on the project requirements.
+- Use asynchronous methods (async/await) for API calls or UI actions that could block the main thread.
+- Optimize Razor components by reducing unnecessary renders and using StateHasChanged() efficiently.
+- Minimize the component render tree by avoiding re-renders unless necessary, using ShouldRender() where appropriate.
+- Use EventCallbacks for handling user interactions efficiently, passing only minimal data when triggering events.
+
+## Caching Strategies
+
+- Implement in-memory caching for frequently used data, especially for Blazor Server apps. Use IMemoryCache for lightweight caching solutions.
+- For Blazor WebAssembly, utilize localStorage or sessionStorage to cache application state between user sessions.
+- Consider Distributed Cache strategies (like Redis or SQL Server Cache) for larger applications that need shared state across multiple users or clients.
+- Cache API calls by storing responses to avoid redundant calls when data is unlikely to change, thus improving the user experience.
+
+## State Management Libraries
+
+- Use Blazor's built-in Cascading Parameters and EventCallbacks for basic state sharing across components.
+- Implement advanced state management solutions using libraries like Fluxor or BlazorState when the application grows in complexity.
+- For client-side state persistence in Blazor WebAssembly, consider using Blazored.LocalStorage or Blazored.SessionStorage to maintain state between page reloads.
+- For server-side Blazor, use Scoped Services and the StateContainer pattern to manage state within user sessions while minimizing re-renders.
+
+## API Design and Integration
+
+- Use HttpClient or other appropriate services to communicate with external APIs or your own backend.
+- Implement error handling for API calls using try-catch and provide proper user feedback in the UI.
+
+## Testing and Debugging in Visual Studio
+
+- All unit testing and integration testing should be done in Visual Studio Enterprise.
+- Test Blazor components and services using xUnit, NUnit, or MSTest.
+- Use Moq or NSubstitute for mocking dependencies during tests.
+- Debug Blazor UI issues using browser developer tools and Visual Studio's debugging tools for backend and server-side issues.
+- For performance profiling and optimization, rely on Visual Studio's diagnostics tools.
+
+## Security and Authentication
+
+- Implement Authentication and Authorization in the Blazor app where necessary using ASP.NET Identity or JWT tokens for API authentication.
+- Use HTTPS for all web communication and ensure proper CORS policies are implemented.
+
+## API Documentation and Swagger
+
+- Use Swagger/OpenAPI for API documentation for your backend API services.
+- Ensure XML documentation for models and API methods for enhancing Swagger documentation.

instructions/cmake-vcpkg.md

@@ -0,0 +1,9 @@
+---
+description: C++ project configuration and package management
+---
+
+This project uses vcpkg in manifest mode. Please keep this in mind when giving vcpkg suggestions. Do not provide suggestions like vcpkg install library, as they will not work as expected.
+Prefer setting cache variables and other types of things through CMakePresets.json if possible.
+Give information about any CMake Policies that might affect CMake variables that are suggested or mentioned.
+This project needs to be cross-platform and cross-compiler for MSVC, Clang, and GCC.
+When providing OpenCV samples that use the file system to read files, please always use absolute file paths rather than file names, or relative file paths. For example, use `video.open("C:/project/file.mp4")`, not `video.open("file.mp4")`.

instructions/genaiscript.md

@@ -0,0 +1,22 @@
+---
+applyTo: "**/*.genai.*"
+description: AI-powered script generation guidelines
+---
+
+## Role
+
+You are an expert at the GenAIScript programming language (https://microsoft.github.io/genaiscript). Your task is to generate GenAIScript script
+or answer questions about GenAIScript.
+
+## Reference
+
+- [GenAIScript docs](../../.genaiscript/docs/llms-full.txt)
+- [GenAIScript ambient type definitions](../../.genaiscript/genaiscript.d.ts)
+
+## Guidance for Code Generation
+
+- you always generate TypeScript code using ESM models for Node.JS.
+- you prefer using APIs from GenAIScript 'genaiscript.d.ts' rather node.js. Avoid node.js imports.
+- you keep the code simple, avoid exception handlers or error checking.
+- you add TODOs where you are unsure so that the user can review them
+- you use the global types in genaiscript.d.ts are already loaded in the global context, no need to import them.

instructions/generate-modern-terraform-code-for-azure.md

@@ -0,0 +1,82 @@
+---
+description: Guidelines for generating modern Terraform code for Azure
+applyTo: "**/*.tf"
+---
+
+## 1. Use Latest Terraform and Providers
+Always target the latest stable Terraform version and Azure providers. In code, specify the required Terraform and provider versions to enforce this. Keep provider versions updated to get new features and fixes.
+
+## 2. Organize Code Cleanly
+Structure Terraform configurations with logical file separation:
+
+- Use `main.tf` for resources
+- Use `variables.tf` for inputs
+- Use `outputs.tf` for outputs
+- Follow consistent naming conventions and formatting (`terraform fmt`)
+
+This makes the code easy to navigate and maintain.
+
+## 3. Encapsulate in Modules
+
+Use Terraform modules to group reusable infrastructure components. For any resource set that will be used in multiple contexts:
+
+- Create a module with its own variables/outputs
+- Reference it rather than duplicating code
+- This promotes reuse and consistency
+
+## 4. Leverage Variables and Outputs
+
+- **Parameterize** all configurable values using variables with types and descriptions
+- **Provide default values** where appropriate for optional variables
+- **Use outputs** to expose key resource attributes for other modules or user reference
+- **Mark sensitive values** accordingly to protect secrets
+
+## 5. Provider Selection (AzureRM vs AzAPI)
+
+- **Use `azurerm` provider** for most scenarios – it offers high stability and covers the majority of Azure services
+- **Use `azapi` provider** only for cases where you need:
+  - The very latest Azure features
+  - A resource not yet supported in `azurerm`
+- **Document the choice** in code comments
+- Both providers can be used together if needed, but prefer `azurerm` when in doubt
+
+## 6. Minimal Dependencies
+
+- **Do not introduce** additional providers or modules beyond the project's scope without confirmation
+- If a special provider (e.g., `random`, `tls`) or external module is needed:
+  - Add a comment to explain
+  - Ensure the user approves it
+- Keep the infrastructure stack lean and avoid unnecessary complexity
+
+## 7. Ensure Idempotency
+
+- Write configurations that can be applied repeatedly with the same outcome
+- **Avoid non-idempotent actions**:
+  - Scripts that run on every apply
+  - Resources that might conflict if created twice
+- **Test by doing multiple `terraform apply` runs** and ensure the second run results in zero changes
+- Use resource lifecycle settings or conditional expressions to handle drift or external changes gracefully
+
+## 8. State Management
+
+- **Use a remote backend** (like Azure Storage with state locking) to store Terraform state securely
+- Enable team collaboration
+- **Never commit state files** to source control
+- This prevents conflicts and keeps the infrastructure state consistent
+
+## 9. Document and Diagram
+
+- **Maintain up-to-date documentation**
+- **Update README.md** with any new variables, outputs, or usage instructions whenever the code changes
+- Consider using tools like `terraform-docs` for automation
+- **Update architecture diagrams** to reflect infrastructure changes after each significant update
+- Well-documented code and diagrams ensure the whole team understands the infrastructure
+
+## 10. Validate and Test Changes
+
+- **Run `terraform validate`** and review the `terraform plan` output before applying changes
+- Catch errors or unintended modifications early
+- **Consider implementing automated checks**:
+  - CI pipeline
+  - Pre-commit hooks
+  - Enforce formatting, linting, and basic validation

instructions/markdown.md

@@ -0,0 +1,52 @@
+---
+description: Documentation and content creation standards
+applyTo: "**/*.md"
+---
+
+## Markdown Content Rules
+
+The following markdown content rules are enforced in the validators:
+
+1. **Headings**: Use appropriate heading levels (H2, H3, etc.) to structure your content. Do not use an H1 heading, as this will be generated based on the title.
+2. **Lists**: Use bullet points or numbered lists for lists. Ensure proper indentation and spacing.
+3. **Code Blocks**: Use fenced code blocks for code snippets. Specify the language for syntax highlighting.
+4. **Links**: Use proper markdown syntax for links. Ensure that links are valid and accessible.
+5. **Images**: Use proper markdown syntax for images. Include alt text for accessibility.
+6. **Tables**: Use markdown tables for tabular data. Ensure proper formatting and alignment.
+7. **Line Length**: Limit line length to 400 characters for readability.
+8. **Whitespace**: Use appropriate whitespace to separate sections and improve readability.
+9. **Front Matter**: Include YAML front matter at the beginning of the file with required metadata fields.
+
+## Formatting and Structure
+
+Follow these guidelines for formatting and structuring your markdown content:
+
+- **Headings**: Use `##` for H2 and `###` for H3. Ensure that headings are used in a hierarchical manner. Recommend restructuring if content includes H4, and more strongly recommend for H5.
+- **Lists**: Use `-` for bullet points and `1.` for numbered lists. Indent nested lists with two spaces.
+- **Code Blocks**: Use triple backticks (`) to create fenced code blocks. Specify the language after the opening backticks for syntax highlighting (e.g., `csharp).
+- **Links**: Use `[link text](URL)` for links. Ensure that the link text is descriptive and the URL is valid.
+- **Images**: Use `![alt text](image URL)` for images. Include a brief description of the image in the alt text.
+- **Tables**: Use `|` to create tables. Ensure that columns are properly aligned and headers are included.
+- **Line Length**: Break lines at 80 characters to improve readability. Use soft line breaks for long paragraphs.
+- **Whitespace**: Use blank lines to separate sections and improve readability. Avoid excessive whitespace.
+
+## Validation Requirements
+
+Ensure compliance with the following validation requirements:
+
+- **Front Matter**: Include the following fields in the YAML front matter:
+
+  - `post_title`: The title of the post.
+  - `author1`: The primary author of the post.
+  - `post_slug`: The URL slug for the post.
+  - `microsoft_alias`: The Microsoft alias of the author.
+  - `featured_image`: The URL of the featured image.
+  - `categories`: The categories for the post. These categories must be from the list in /categories.txt.
+  - `tags`: The tags for the post.
+  - `ai_note`: Indicate if AI was used in the creation of the post.
+  - `summary`: A brief summary of the post. Recommend a summary based on the content when possible.
+  - `post_date`: The publication date of the post.
+
+- **Content Rules**: Ensure that the content follows the markdown content rules specified above.
+- **Formatting**: Ensure that the content is properly formatted and structured according to the guidelines.
+- **Validation**: Run the validation tools to check for compliance with the rules and guidelines.

instructions/nextjs-tailwind.md

@@ -0,0 +1,71 @@
+---
+description: Next.js + Tailwind development standards and instructions
+---
+
+# Next.js + Tailwind Development Instructions
+
+Instructions for high-quality Next.js applications with Tailwind CSS styling and TypeScript.
+
+## Project Context
+
+- Latest Next.js (App Router)
+- TypeScript for type safety
+- Tailwind CSS for styling
+
+## Development Standards
+
+### Architecture
+- App Router with server and client components
+- Group routes by feature/domain
+- Implement proper error boundaries
+- Use React Server Components by default
+- Leverage static optimization where possible
+
+### TypeScript
+- Strict mode enabled
+- Clear type definitions
+- Proper error handling with type guards
+- Zod for runtime type validation
+
+### Styling
+- Tailwind CSS with consistent color palette
+- Responsive design patterns
+- Dark mode support
+- Follow container queries best practices
+- Maintain semantic HTML structure
+
+### State Management
+- React Server Components for server state
+- React hooks for client state
+- Proper loading and error states
+- Optimistic updates where appropriate
+
+### Data Fetching
+- Server Components for direct database queries
+- React Suspense for loading states
+- Proper error handling and retry logic
+- Cache invalidation strategies
+
+### Security
+- Input validation and sanitization
+- Proper authentication checks
+- CSRF protection
+- Rate limiting implementation
+- Secure API route handling
+
+### Performance
+- Image optimization with next/image
+- Font optimization with next/font
+- Route prefetching
+- Proper code splitting
+- Bundle size optimization
+
+## Implementation Process
+1. Plan component hierarchy
+2. Define types and interfaces
+3. Implement server-side logic
+4. Build client components
+5. Add proper error handling
+6. Implement responsive styling
+7. Add loading states
+8. Write tests

instructions/python.md

@@ -0,0 +1,55 @@
+---
+description: Python coding conventions and guidelines
+---
+
+# Python Coding Conventions
+
+## Python Instructions
+
+- Write clear and concise comments for each function.
+- Ensure functions have descriptive names and include type hints.
+- Provide docstrings following PEP 257 conventions.
+- Use the `typing` module for type annotations (e.g., `List[str]`, `Dict[str, int]`).
+- Break down complex functions into smaller, more manageable functions.
+
+## General Instructions
+
+- Always prioritize readability and clarity.
+- For algorithm-related code, include explanations of the approach used.
+- Write code with good maintainability practices, including comments on why certain design decisions were made.
+- Handle edge cases and write clear exception handling.
+- For libraries or external dependencies, mention their usage and purpose in comments.
+- Use consistent naming conventions and follow language-specific best practices.
+- Write concise, efficient, and idiomatic code that is also easily understandable.
+
+## Code Style and Formatting
+
+- Follow the **PEP 8** style guide for Python.
+- Maintain proper indentation (use 4 spaces for each level of indentation).
+- Ensure lines do not exceed 79 characters.
+- Place function and class docstrings immediately after the `def` or `class` keyword.
+- Use blank lines to separate functions, classes, and code blocks where appropriate.
+
+## Edge Cases and Testing
+
+- Always include test cases for critical paths of the application.
+- Account for common edge cases like empty inputs, invalid data types, and large datasets.
+- Include comments for edge cases and the expected behavior in those cases.
+- Write unit tests for functions and document them with docstrings explaining the test cases.
+
+## Example of Proper Documentation
+
+```python
+def calculate_area(radius: float) -> float:
+    """
+    Calculate the area of a circle given the radius.
+    
+    Parameters:
+    radius (float): The radius of the circle.
+    
+    Returns:
+    float: The area of the circle, calculated as π * radius^2.
+    """
+    import math
+    return math.pi * radius ** 2
+```