Two files, one repository
dotnet/efcore ships 2 formats across 2 indexed files. The question worth asking is whether the second one says anything the first does not.
| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 1 | 6 | 0% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 0 | 0 | 4 | 0% |
What each file covers
Sections
0 shared · 1 only in A · 6 only in B- − `eng/common`
- + Entity Framework Core - GitHub Copilot Instructions
- + Code Style
- + Environment Setup
- + Dependency and Version Management
- + Implementation Guidelines
- + Agent Skills
Commands
neither file has anySection tags
0 shared · 0 only in A · 4 only in B- + setup
- + code-style
- + deployment
- + agent-behaviour
Line diff
dotnet/efcore · eng/common/AGENTS.md
@@ −1 @@
1# `eng/common`
2
3Files under `eng/common` come from [Arcade](https://github.com/dotnet/arcade).
4Edits in `eng/common` will be overwritten by automation unless the changes are made directly in the Arcade repository.
5For more information, see the [Arcade documentation](https://github.com/dotnet/arcade/tree/main/Documentation).
6
dotnet/efcore · .github/copilot-instructions.md
@@ +1 @@
1# Entity Framework Core - GitHub Copilot Instructions
2
3This document provides guidance for working with code in the Entity Framework Core project.
4
5If you are not sure, do not guess, just tell that you don't know or ask clarifying questions.
6Don't just copy code that follows the same pattern in a different context.
7Don't rely just on names to guess its function, evaluate the code based on the implementation and usage.
8
9## Code Style
10
11- Follow the [.NET coding guidelines](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md) unless explicitly overridden below
12- Use the rules defined in the .editorconfig file in the root of the repository for any ambiguous cases
13- Write code that is clean, maintainable, and easy to understand
14- Favor readability over brevity, but keep methods focused and concise
15- **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. Use `Check.DebugAssert` instead of a comment if possible.
16
17## Environment Setup
18- **ALWAYS** run `restore.cmd` (Windows) or `. ./restore.sh` (Linux/Mac) first to restore dependencies
19- **ALWAYS** run `. .\activate.ps1` (PowerShell) or `. ./activate.sh` (Bash) to set up the development environment with correct SDK versions before building or running the tests
20
21## Dependency and Version Management
22
23- **NEVER** hardcode package versions in `.csproj` files
24- Use `eng/Versions.props` and `Directory.Packages.props` for NuGet package version management
25
26## Implementation Guidelines
27
28- Write code that is secure by default. Avoid exposing potentially private or sensitive data
29- 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
30- After implementing a fix, review the surrounding code for similar patterns that might need the same change
31- Be mindful of performance implications, especially for database operations
32- Avoid breaking public APIs. If you need to break a public API, add a new API instead and mark the old one as obsolete. Use `ObsoleteAttribute` with the message pointing to the new API
33- If a public API is changed, run EFCore.ApiBaseline.Tests
34- All types should be public by default, but types in `.Internal` namespaces or annotated with `[EntityFrameworkInternal]` require a specific XML doc comment on ALL members.
35- **ALL** user-facing error messages must use string resources from the `.resx` (and the generated `.Designer.cs`) file corresponding to the project
36- Call `ConfigureAwait(false)` on awaited asynchronous calls to avoid deadlocks
37
38## Agent Skills
39
40Skill files in `.agents/skills/` provide domain-specific knowledge so that agents don't need repetitive instructions from the user. Keep skills updated: when you discover non-obvious patterns, key files, or recurring review feedback during a session, distill the insight into the relevant `SKILL.md`. Additions must be concise, broadly useful, and stable — avoid task-specific details, speculation, and statements that contradict existing content. Remove or correct stale information rather than appending conflicting rules.
41
@@ −1 +1 @@
1−# `eng/common`
1+# Entity Framework Core - GitHub Copilot Instructions
22
3−Files under `eng/common` come from [Arcade](https://github.com/dotnet/arcade).
4−Edits in `eng/common` will be overwritten by automation unless the changes are made directly in the Arcade repository.
5−For more information, see the [Arcade documentation](https://github.com/dotnet/arcade/tree/main/Documentation).
3+This document provides guidance for working with code in the Entity Framework Core project.
4+
5+If you are not sure, do not guess, just tell that you don't know or ask clarifying questions.
6+Don't just copy code that follows the same pattern in a different context.
7+Don't rely just on names to guess its function, evaluate the code based on the implementation and usage.
8+
9+## Code Style
10+
11+- Follow the [.NET coding guidelines](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/coding-style.md) unless explicitly overridden below
12+- Use the rules defined in the .editorconfig file in the root of the repository for any ambiguous cases
13+- Write code that is clean, maintainable, and easy to understand
14+- Favor readability over brevity, but keep methods focused and concise
15+- **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. Use `Check.DebugAssert` instead of a comment if possible.
16+
17+## Environment Setup
18+- **ALWAYS** run `restore.cmd` (Windows) or `. ./restore.sh` (Linux/Mac) first to restore dependencies
19+- **ALWAYS** run `. .\activate.ps1` (PowerShell) or `. ./activate.sh` (Bash) to set up the development environment with correct SDK versions before building or running the tests
20+
21+## Dependency and Version Management
22+
23+- **NEVER** hardcode package versions in `.csproj` files
24+- Use `eng/Versions.props` and `Directory.Packages.props` for NuGet package version management
25+
26+## Implementation Guidelines
27+
28+- Write code that is secure by default. Avoid exposing potentially private or sensitive data
29+- 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
30+- After implementing a fix, review the surrounding code for similar patterns that might need the same change
31+- Be mindful of performance implications, especially for database operations
32+- Avoid breaking public APIs. If you need to break a public API, add a new API instead and mark the old one as obsolete. Use `ObsoleteAttribute` with the message pointing to the new API
33+- If a public API is changed, run EFCore.ApiBaseline.Tests
34+- All types should be public by default, but types in `.Internal` namespaces or annotated with `[EntityFrameworkInternal]` require a specific XML doc comment on ALL members.
35+- **ALL** user-facing error messages must use string resources from the `.resx` (and the generated `.Designer.cs`) file corresponding to the project
36+- Call `ConfigureAwait(false)` on awaited asynchronous calls to avoid deadlocks
37+
38+## Agent Skills
39+
40+Skill files in `.agents/skills/` provide domain-specific knowledge so that agents don't need repetitive instructions from the user. Keep skills updated: when you discover non-obvious patterns, key files, or recurring review feedback during a session, distill the insight into the relevant `SKILL.md`. Additions must be concise, broadly useful, and stable — avoid task-specific details, speculation, and statements that contradict existing content. Remove or correct stale information rather than appending conflicting rules.
641
