TriageSAFE
EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
Overview
EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
1aecdbaaf9a2OBSERVED · 2026-10-07What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: triage
description: Use this skill to triage an incoming issue on the EF Core repo (bug report or feature request). Sets the issue type (bug/feature), assigns EF area labels, attempts to arrive at a minimal repro reproducing the bug, checks whether it represents a regression, finds possible duplicates, etc.
---
# EF Issue Triage
This skill covers triaging and reproducing incoming issues on the Entity Framework Core repository. To do so, read the issue in question (provided as input in the prompt), as well as any linked issues/code/resources, apply appropriate classifications and assignments, and for alleged bugs, try to arrive at a minimal repro. User-submitted bug reports frequently provide only fragmentary information and code snippets, forcing you to try to fill in the missing information in the effort to create a minimal repro; valuable information is frequently provided in free-form text, which you need to integrate into the repro as code.
## High-level steps
1. Read the issue in question and any linked issues/code/resources.
2. Assess whether the issue involves any sort of security concern. If it does, either because the reporting user claims so, or because you suspect there might be a security aspect that the reporting user hasn't mentioned, **exit immediately**. **Do not** continue processing or post anything on issues which may involve any sort of security aspect.
3. Determine whether the issue is a feature or bug, and set the GitHub issue type accordingly.
4. Determine what area of EF the issue relates to, and apply area labels to the GitHub issue accordingly (see below for more details).
5. Produce a minimal repro
1. If the issue was determined to be a feature request, skip the minimal repro in this step; continue with the remaining triage steps (duplicate search and final report).
2. If, on the other hand, the issue was determined to be a bug report, attempt to produce a minimal repro as a console program which confirms that the bug is genuine. See "Creating a minimal repro" below for instructions.
3. If you've managed to confirm a bug in your repro, test your repro on both the failing version and the previous working version. Provide clear feedback confirming or refuting the fact that the reported issue is a regression.
6. Try to find possible duplicate issues - opened or closed - in the EF Core repo (https://github.com/dotnet/efcore), and include the likely candidates in your final report.
7. Post your final report as a comment on the issue being triaged.
## Area labels
The EF repo contains a set of "area" labels that express which part of EF is affected. Area labels always start with an `area-` prefix. You can see the canonical list of area labels at https://github.com/dotnet/efcore/labels?q=area-, or fetch them using the GitHub CLI with `gh label list --search "area-" --repo dotnet/efcore`.
* If an issue affects only a specific provider, make sure to add the label corresponding to that provider (e.g. `area-sqlserver`, `area-cosmos`...). However, if an issue affects *all* providers, do not add provider labels.
* The same issue can have multiple labels when relevant. For example, a Cosmos query bug should have both `area-cosmos` and `area-query`.
## Creating a minimal repro
The minimal repro should be created as a completely separate console program, outside of the EF repo. Use the following as your starting point:
```csharp
using System;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.Logging;
await using var context = new TestContext();
await context.Database.EnsureDeletedAsync();
await context.Database.EnsureCreatedAsync();
public class TestContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
=> optionsBuilder
// Modify the following line to switch EF providers
.UseSqlServer(Environment.GetEnvironmentVariable("Test__SqlServer__DefaultConnection"))
.LogTo(Console.WriteLine, LogLevel.Information)
.EnableSensitiveDataLogging();
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
}
}
public class Blog
{
public int Id { get; set; }
public string Name { get; set; }
}
```
* Try to integrate the user's code into the minimal template, incorporating any textual instructions from the issue, or clues that you can glean.
* At the end of the process, the minimal repro should compile and execute, and reproduce the user's reported error.
* The program should use code that's as close as possible to the user-reported code, including type/property naming and things that seem irrelevant.
### Database providers used in the bug report and repro
* We're ideally looking for a repro using SQL Server (or, as a fallback, using SQLite), which are the built-in EF providers; these are easiest to investigate and reproduce. So reproducing on SQL Server should be your starting point.
* However, if the bug isn't immediately reproducible on SQL Server/SQLite, it may require a different database; check the issue report for the reported database, or try to infer from the textual description what database the user is using. Then, attempt to reproduce the bug on that database. If you've managed to repro a problem on a provider other than SQL Server, please attempt to port the repro back to SQL Server, as that's the easiest built-in provider to diagnose/debug on. When doing this, you need to see the same error/exception on SQL Server as on the non-SQL Server provider, otherwise that may be showing a different issue. This would also confirm whether the bug is specific to e.g. the PostgreSQL provider, or a general EF Core bug.
* Some databases (PostgreSQL, MySQL) should already be installed on the github runner image which you're running - but you may still need to bring them up. Others may require bringing in a testcontainer to run the repro against.
* Pay attention to theTrust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
1aecdbaaf9a2full audit observations/trust-audit/skill/dotnet__triage.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-07 | 1aecdbaaf9a2 | SAFE | B | 89 | first audit |
Questions
What does the Triage skill do?
EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
Is Triage safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Triage access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (1aecdbaaf9a2), read on 2026-10-07. The repository is watched, and a new audit runs when it changes — this is the first audit.