Update Copilot instructions (#37636)

Co-authored-by: AndriySvyryd <6539701+AndriySvyryd@users.noreply.github.com>

Author: Copilot

.github/copilot-instructions.md

@@ -12,7 +12,7 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
 - Use the rules defined in the .editorconfig file in the root of the repository for any ambiguous cases
 - Write code that is clean, maintainable, and easy to understand
 - Favor readability over brevity, but keep methods focused and concise
-- Only add comments rarely to explain why a non-intuitive solution was used. The code should be self-explanatory otherwise
+- **Prefer minimal comments** - The code should be self-explanatory. Add comments sparingly and only to explain *why* a non-intuitive solution was necessary, not *what* the code does. Comments are appropriate for complex logic, public APIs, or domain-specific implementations where context would otherwise be unclear
 - Add license header to all files:
 ```
     // Licensed to the .NET Foundation under one or more agreements.
@@ -48,8 +48,9 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
 - Use `var` for local variables
 - Use expression-bodied members where appropriate
 - Prefer using collection expressions when possible
-- Use `is` pattern matching instead of `as` and null checks
+- Use `is` pattern matching instead of `as` followed by null checks (e.g., `if (obj is SomeType typed)` instead of `var typed = obj as SomeType; if (typed != null)`)
 - Prefer `switch` expressions over `switch` statements when appropriate
+- Prefer pattern matching with `when` clauses in switch expressions for conditional logic
 - Prefer field-backed property declarations using field contextual keyword instead of an explicit field.
 - Prefer range and index from end operators for indexer access
 - The projects use implicit namespaces, so do not add `using` directives for namespaces that are already imported by the project
@@ -89,6 +90,8 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
 - Create both unit tests and functional tests where appropriate
 - Fix `SQL` and `C#` baselines for tests when necessary by setting the `EF_TEST_REWRITE_BASELINES` env var to `1`
 - Run tests with project rebuilding enabled (don't use `--no-build`) to ensure code changes are picked up
+- When testing cross-platform code (e.g., file paths, path separators), verify the fix works on both Windows and Linux/macOS
+- When testing `dotnet-ef` tool changes, create a test project and manually run the affected commands to verify behavior
 
 #### Environment Setup
 - **ALWAYS** run `restore.cmd` (Windows) or `. ./restore.sh` (Linux/Mac) first to restore dependencies
@@ -110,6 +113,13 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
 - **ALL** user-facing error messages must use string resources from the `.resx` (and the generated `.Designer.cs`) file corresponding to the project
 - Avoid catching exceptions without rethrowing them
 
+## Dependency and Version Management
+
+- **NEVER** hardcode package versions in `.csproj` files
+- Check `eng/Versions.props` for existing version properties (e.g., `$(SQLitePCLRawVersion)`) before adding or updating package references
+- Use `Directory.Packages.props` for NuGet package version management with Central Package Management (CPM)
+- Packages listed in `eng/Version.Details.xml` are managed by Maestro dependency flow and should not be updated manually or by Dependabot
+
 ## Asynchronous Programming
 
 - Provide both synchronous and asynchronous versions of methods where appropriate
@@ -129,6 +139,7 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
 
 - Write code that is secure by default. Avoid exposing potentially private or sensitive data
 - Make code NativeAOT compatible when possible. This means avoiding dynamic code generation, reflection, and other features that are not compatible with NativeAOT. If not possible, mark the code with an appropriate annotation or throw an exception
+- After implementing a fix, review the surrounding code for similar patterns that might need the same change
 
 ### Entity Framework Core Specific guidelines
 
@@ -153,6 +164,32 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
 - .github/: GitHub-specific files, workflows, and Copilot instructions
 - .config/: AzDo pipelines configuration files
 
+## Pull Request Guidelines
+
+- **ALWAYS** target the `main` branch for new PRs unless explicitly instructed otherwise
+- For servicing PRs (fixes targeting release branches), use the following PR description template:
+```
+Fixes #{issue_number}
+
+**Description**
+{Brief description of the issue and fix}
+
+**Customer impact**
+{How does the reported issue affect customers? Are there workarounds?}
+
+**How found**
+{Was it customer reported or found during verification? How many customers are affected?}
+
+**Regression**
+{Is it a regression from a released version? Which one?}
+
+**Testing**
+{How the changes were tested}
+
+**Risk**
+{Low/Medium/High, with justification}
+```
+
 ## Overview of Entity Framework Core
 
 Entity Framework Core (EF Core) is an object-database mapper for .NET. Below is a concise summary of its core architecture and concepts: