If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dotnet/efcore shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 14 active contributors
• Distributed ownership (top contributor 34% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dotnet/efcore repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet/efcore.

What it runs against: a local clone of dotnet/efcore — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dotnet/efcore | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet/efcore. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet/efcore.git
#   cd efcore
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dotnet/efcore and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet/efcore(\\.git)?\\b" \\
  && ok "origin remote is dotnet/efcore" \\
  || miss "origin remote is not dotnet/efcore (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f ".github/CONTRIBUTING.md" \\
  && ok ".github/CONTRIBUTING.md" \\
  || miss "missing critical file: .github/CONTRIBUTING.md"
test -f "azure-pipelines.yml" \\
  && ok "azure-pipelines.yml" \\
  || miss "missing critical file: azure-pipelines.yml"
test -f "NuGet.config" \\
  && ok "NuGet.config" \\
  || miss "missing critical file: NuGet.config"
test -f ".agents/skills/testing/SKILL.md" \\
  && ok ".agents/skills/testing/SKILL.md" \\
  || miss "missing critical file: .agents/skills/testing/SKILL.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dotnet/efcore"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Entity Framework Core is a modern object-relational mapper (ORM) for .NET that translates LINQ queries into SQL and manages change tracking, database updates, and schema migrations. It supports SQL Server, PostgreSQL, MySQL, SQLite, Azure Cosmos DB, and other databases through pluggable providers. The core value is eliminating boilerplate SQL and hand-mapping while maintaining type safety and lazy-loading capabilities. Monorepo structure: src/EFCore/ contains the core ORM engine; src/EFCore.Relational/ handles SQL provider abstractions; provider-specific code lives in src/EFCore.SqlServer/, src/EFCore.Sqlite/, src/EFCore.Cosmos/; src/EFCore.Tools/ provides the migrations CLI; .agents/skills/ contains AI agent prompts for specific subsystems (change-tracking, query-pipeline, migrations, model-building).

.NET developers building data-driven applications who need to abstract over relational databases without writing raw SQL. This includes enterprise backend developers, microservice architects, and teams using .NET 6+ who want LINQ-based querying with automatic change tracking and migrations.

Highly mature and production-ready. The repo shows active development with continuous Azure DevOps CI/CD (build definition 17), comprehensive test coverage across multiple database providers, and is officially maintained by Microsoft under the .NET Foundation. Daily builds are published to NuGet alongside stable releases, indicating long-term commitment and community trust.

Low risk for stability, but high complexity risk for contributors. The codebase is large (81.7 MB C# code) with multiple provider implementations (SQL Server, Cosmos, SQLite, PostgreSQL via external providers), intricate LINQ translation layers, and deep ORM semantics. Breaking changes can cascade across dependent projects; this requires careful testing across all provider implementations before merging.

The .agents/skills/ directory structure suggests active development on AI-assisted tooling for EF Core subsystems. Recent focus areas indicated by skill files include change-tracking optimization, CI analysis automation, query-pipeline improvements, and custom scaffolding. The presence of servicing-pr and ci-analysis skills indicates ongoing DevOps and release management enhancements.

git clone https://github.com/dotnet/efcore.git
cd efcore
dotnet build
dotnet test --filter TargetFrameworkMoniker=net6.0

You'll need .NET 6.0 SDK or later. Build uses standard MSBuild (no npm/yarn). See docs/DailyBuilds.md for daily NuGet feed setup.

Daily commands:

dotnet build src/EFCore.sln
dotnet test src/EFCore/test/EFCore.Tests/EFCore.Tests.csproj --framework net6.0
# To test a specific provider:
dotnet test src/EFCore.SqlServer/test/EFCore.SqlServer.FunctionalTests/EFCore.SqlServer.FunctionalTests.csproj

No separate dev server; this is a library. Tests must connect to actual database instances (SQL Server, PostgreSQL, SQLite).

• Directory.Build.props — Central project configuration and NuGet package versions that all EF Core projects depend on; critical for build consistency across the monorepo.
• .github/CONTRIBUTING.md — Defines contribution guidelines, testing requirements, and code review expectations that every contributor must follow.
• azure-pipelines.yml — Main CI/CD pipeline orchestration for the entire EF Core project; defines build, test, and publish steps.
• NuGet.config — Package feed configuration that controls which NuGet sources are used; essential for resolving dependencies correctly.
• .agents/skills/testing/SKILL.md — Documents the testing framework and patterns expected in this codebase; foundational for adding or modifying tests.
• .github/CODEOWNERS — Defines code ownership and review responsibilities by file path; determines who must review PRs in each area.
• README.md — High-level project overview and scope; essential baseline for understanding the EF Core mission and architecture.

Add a new database provider

1. Create a new solution filter file (e.g., EFCore.MyProvider.slnf) that includes the core EF Core projects plus your provider-specific projects (EFCore.slnx (reference for structure))
2. Update Directory.Build.props with provider-specific properties and add new project references (Directory.Build.props)
3. Add a new SKILL.md documenting the provider's architecture and extension points (.agents/skills/[your-provider]/SKILL.md)
4. Create benchmarks for your provider in the benchmark directory following the existing pattern (benchmark/EFCore.Benchmarks/[YourProvider]/ProviderBenchmarks.cs)
5. Add CI/CD workflow file for provider-specific testing if needed (.github/workflows/[your-provider]-tests.yml)
6. Update CODEOWNERS to assign code review responsibility for your provider files (.github/CODEOWNERS)

Improve change tracking or query pipeline

1. Read the domain expertise guide to understand the current architecture (.agents/skills/change-tracking/SKILL.md or .agents/skills/query-pipeline/SKILL.md)
2. Create a benchmark demonstrating the current behavior and measuring improvements (benchmark/EFCore.Benchmarks/ChangeTracker/DbSetOperationTests.cs or benchmark/EFCore.Benchmarks/[NewBenchmark].cs)
3. Implement changes in the respective core project following existing code patterns ([EF Core core project files—consult SKILL.md])
4. Add or update unit tests in the test project suite ([Test project directory—see CONTRIBUTING.md])
5. Verify no perf regressions by running benchmark suite locally before submitting PR (benchmark/EFCore.Benchmarks/EFCoreBenchmarkRunner.cs)

Add a new feature or fix a bug

1. Review contribution guidelines and development workflow (.github/CONTRIBUTING.md)
2. Set up local development environment using dev container (.devcontainer/devcontainer.json)
3. Locate the relevant agent skill guide for the area you're working on (change-tracking, migrations, scaffolding, etc.) (.agents/skills/[relevant-area]/SKILL.md)
4. Write tests following EF Core testing patterns and conventions (.agents/skills/testing/SKILL.md)
5. Ensure your code follows .editorconfig style rules and runs through CI pipeline (.editorconfig and azure-pipelines.yml)
6. Update API baselines if public API surfaces changed (.github/workflows/api-review-baselines.yml)

Debug or fix a CI pipeline failure

1. Review CI analysis skill for investigation techniques and artifact interpretation (.agents/skills/ci-analysis/SKILL.md)
2. Check the relevant CI workflow definition to understand the failure context (.github/workflows/Build.yml or azure-pipelines.yml)
3. Review build progression and binlog analysis references if needed (.agents/skills/ci-analysis/references/build-progression-analysis.md)
4. Update Directory.Build.props or azure-pipelines.yml if infrastructure or dependencies changed (Directory.Build.props or azure-pipelines.yml)

• C# / .NET / MSBuild — EF Core is a .NET ORM; must target CLR/.NET ecosystem; MSBuild is standard build system for .NET projects.
• Azure Pipelines & GitHub Actions — Enterprise CI/CD required for multi-platform testing (Windows, Linux, macOS); parallelization for complex matrix of provider/test combinations.
• BenchmarkDotNet — Rigorous, reproducible performance measurement essential for ORM—every query optimization decision must

Test database requirement: Functional tests require running SQL Server (localdb or container), PostgreSQL, MySQL, and SQLite instances; CI uses Azure DevOps Helix agents (see .agents/skills/ci-analysis/references/helix-artifacts.md). LINQ complexity: Expression tree translation has subtle edge cases across providers (e.g., GroupBy translation differs between SQL Server and SQLite); always test against all target providers. Change tracking overhead: Proxy creation and state tracking incur runtime cost; profiling tools are essential for performance-sensitive paths. Breaking changes risk: API changes in DbContext or IQueryable affect both internal tests and external NuGet packages; changes require extensive compatibility testing documented in src/EFCore.Design/ and scaffolding.

• LINQ Expression Trees — Core mechanism by which EF Core translates C# LINQ queries into SQL; understanding visitor patterns and expression compilation is essential for query pipeline debugging and optimization
• Change Tracking & Unit of Work Pattern — EF Core's DbContext implements unit-of-work with change tracking to batch database operations; understanding state transitions (Added/Modified/Deleted/Unchanged) is critical for SaveChanges correctness and performance
• Provider Adapter Pattern — EF Core abstracts database-specific behavior through IDatabase, IQueryProvider, and ISqlGenerationHelper interfaces; contributing to multiple providers requires understanding this abstraction layer
• Shadow Properties & Metadata Mapping — EF Core supports properties not directly on entity classes (shadow properties) and foreign keys inferred from conventions; the metadata layer in src/EFCore/Metadata/ drives model validation and change detection
• Query Pipeline Stages — EF Core translates queries through multiple stages (normalization, parameter optimization, SQL generation); understanding QueryTranslationContext and ExpressionVisitor chains is essential for debugging complex LINQ failures
• Schema Migrations & Diff Generation — The migration system in src/EFCore.Relational/Migrations/ tracks model changes and generates idempotent SQL; understanding MigrationBuilder and provider-specific DDL is critical for data evolution features
• Lazy Loading & Proxy Generation — EF Core can generate runtime proxies for navigation properties to enable transparent lazy loading; understanding Castle.Core integration and proxy interception affects performance and behavior in change tracking

• dotnet/efcore-sql-server — Official SQL Server provider for EF Core; pulled as a separate repo to support independent versioning and faster hotfixes for Microsoft's primary database target
• dotnet/efcore-cosmos — Official Azure Cosmos DB provider; specialized ORM adapter demonstrating how to implement non-relational query translation and consistency models
• npgsql/efcore.pg — Community-maintained PostgreSQL provider with advanced features (JSON support, ranges, enum types); reference implementation for third-party provider development
• dotnet/AspNetCore — Tight integration with ASP.NET Core dependency injection and middleware; many web applications use EF Core as the data layer through AddDbContext extension methods
• dotnet/roslyn — EF Core's code generation (scaffolding, migrations) uses Roslyn analyzers and source generators; understanding Roslyn APIs is essential for tooling contributions

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create comprehensive skill documentation index and cross-references

The .agents/skills directory contains 14 specialized skills (change-tracking, query-pipeline, migrations, etc.) but lacks a central index or navigation document. A new contributor could create a SKILLS_INDEX.md that maps each skill to its purpose, prerequisites, and relationships. This would improve discoverability and help contributors understand which skill to apply to different EF Core tasks.

• [ ] Create .agents/SKILLS_INDEX.md with table of all skills and their purposes
• [ ] Add cross-reference links in each SKILL.md to related skills
• [ ] Document skill prerequisites and dependencies (e.g., which skills build on model-building)
• [ ] Add examples showing when to use each skill in typical EF Core contribution workflows

Expand ci-analysis skill with missing database provider scenarios

The ci-analysis skill has references for SQL tracking and Helix artifacts, but the .agents/skills/ci-analysis/references directory lacks guides for analyzing failures specific to EF Core's multiple providers (SQLite, Cosmos, SqlServer, PostgreSQL, etc.). Adding provider-specific CI debugging guides would help contributors troubleshoot provider-related test failures.

• [ ] Create .agents/skills/ci-analysis/references/provider-specific-failures.md documenting common failure patterns per provider
• [ ] Add .agents/skills/ci-analysis/references/sqlite-specific-ci.md since Microsoft.Data.Sqlite is a first-class project
• [ ] Document cosmos-provider specific CI considerations in .agents/skills/ci-analysis/references/cosmos-ci-analysis.md
• [ ] Link these new guides from the main ci-analysis SKILL.md

Create testing patterns documentation for provider-specific tests

The .agents/skills/testing/SKILL.md exists but the repository structure shows multiple providers (SQLite, Cosmos) without dedicated testing guidance. A new contributor could create provider-specific testing patterns documentation that explains how to write tests that work across EF Core's different database providers and how to skip provider-incompatible tests.

• [ ] Create .agents/skills/testing/references/provider-specific-testing.md with patterns for multi-provider test compatibility
• [ ] Document how to use traits/attributes to mark tests for specific providers (SQLite-only, Cosmos-incompatible, etc.)
• [ ] Add examples of test fixtures for each major provider in .agents/skills/testing/references/
• [ ] Reference this guide from both testing SKILL.md and the provider-specific skills (sqlite-adonet, cosmos-provider)

• Add missing XML docs to query pipeline classes: Many files in src/EFCore.Relational/Query/ lack comprehensive documentation. Add /// comments explaining expression visitor patterns and SQL generation stages for new contributors.
• Expand CI analysis automation: The .agents/skills/ci-analysis/ directory has references like binlog-comparison.md and build-progression-analysis.md but the PowerShell scripts (Get-CIStatus.ps1) lack detailed inline comments. Document each section of the Helix/Azure DevOps integration for future maintainers.
• Write provider-specific change tracking tests: The .agents/skills/change-tracking/SKILL.md exists but lacks concrete test examples for edge cases (e.g., detecting changes in shadow properties across Cosmos vs. relational providers). Create a test matrix showing expected behavior per provider.

The dotnet/efcore repository demonstrates reasonable security practices with dependency management (Dependabot, Guardian baselines) and organized skill-based documentation. However, key risks include potential SQL injection vulnerabilities in the query pipeline (medium severity), opaque dependency versions, and DevContainer/CI-CD configuration exposure. The codebase would benefit from explicit security policies, regular dependency audits, parameterized query enforcement in all SQL-generating code, and enhanced CI/CD secret management. The presence of security documentation and organized code structure suggests a mature security posture, but specific implementation details require code-level review.

• Medium · Potential SQL Injection Risks in Query Pipeline — .agents/skills/query-pipeline/SKILL.md, Query pipeline components. EF Core's query pipeline processes LINQ to SQL translations. While the codebase includes query pipeline skills (.agents/skills/query-pipeline), there is a risk of SQL injection if raw SQL queries are improperly sanitized or if user input is directly interpolated into SQL strings without parameterization. Fix: Ensure all raw SQL queries use parameterized queries (e.g., SqlParameter in .NET). Review SQL generation logic to prevent user input from being directly concatenated into SQL strings. Implement input validation and use parameterized queries exclusively.
• Medium · Dependency Management and Supply Chain Risk — Directory.Packages.props, .github/dependabot.yml. The repository uses dependency management files (Directory.Packages.props, .github/dependabot.yml) but the specific dependency versions and security baselines are not visible in the provided context. Outdated or vulnerable dependencies could introduce security risks. Fix: Regularly audit NuGet dependencies using tools like 'dotnet list package --vulnerable' or Snyk. Enable and monitor Dependabot alerts. Keep dependencies up-to-date and review security advisories regularly. Maintain a security baseline in .config/guardian/.gdnbaselines.
• Medium · DevContainer Configuration Exposure — .devcontainer/devcontainer.json, .devcontainer/docker-compose.yml. The .devcontainer/docker-compose.yml and devcontainer.json files may contain environment variables or service configurations that could expose sensitive settings if not properly secured or if default credentials are used. Fix: Ensure DevContainer configurations do not include hardcoded credentials or sensitive environment variables. Use secret management tools for local development. Document required secrets separately and ensure they are not committed to version control.
• Low · Missing Security Policy Documentation — .github/SECURITY.md. While .github/SECURITY.md exists, there is limited visibility into its content. The repository should have clear security policies for vulnerability reporting and disclosure. Fix: Ensure SECURITY.md includes responsible disclosure guidelines, vulnerability reporting process, security contact information, and expected response times. Reference OWASP and industry best practices.
• Low · Azure DevOps Pipeline Configuration Review — .azuredevops/dependabot.yml, .github/workflows/Build.yml. CI/CD workflows in .azuredevops and .github/workflows may contain security misconfigurations such as excessive permissions, exposed secrets in logs, or insecure artifact handling. Fix: Review all workflow files for: (1) Principle of least privilege in permissions, (2) Secrets management (use GitHub Secrets), (3) Artifact signing and verification, (4) Disable logging of sensitive data, (5) Use OIDC for Azure authentication instead of service principals with stored secrets.
• Low · Code Review and Ownership Clarity — .github/CODEOWNERS. The CODEOWNERS file exists but visibility into its content is limited. Unclear ownership can lead to security review gaps. Fix: Ensure CODEOWNERS clearly defines security-critical components (query pipeline, migrations, model building) and requires experienced reviewers. Consider creating a security team for sensitive areas.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.