dotnet-inspect

Use for daily chores in dotnet-inspect; establish release-candidate readiness, then inspect main CI, staging, performance, runtime-pin, security, dependency, and regression runs.

Use when a dotnet-inspect change needs expensive evidence outside normal PR CI, or when preparing release certification; coordinate Deep Inspect lanes (full slow tests, cross-platform certification, IL round-trip sweep, corpus sensors, package discovery, validity scans, and analysis census).

Find and share evidence instead of guessing about .NET packages, libraries, APIs, dependencies, source, performance, and version changes.

Compare .NET library versions for API breaks, implementation changes and static analysis shifts; follow exact API correspondence and history without treating comparisons as safe-upgrade verdicts.

Investigate .NET exception handling, unsafe operations, interop boundaries and pooled-resource ownership using exact Member and IL evidence; static findings do not establish overall safety.

Read .NET method and type implementations as authored-first source, decompiled C#, annotated source or IL; interpret reconstruction fidelity and locate exact code coordinates. Use --offline to prohibit network acquisition.

Inspect raw ECMA-335 metadata in a .NET assembly; discover tables and heaps, read decoded rows and handles, locate exact coordinates and project bounded machine-readable results.

Discover version-matched agent skills in restored NuGet dependencies or an exact package, select relevant guidance and load it without changing the repository; persist skills only when explicitly requested.

Find high-leverage .NET methods with allocation and repetition evidence, trace candidate costs through calls and IL, and select focused profiling or benchmark follow-ups rather than claiming measured wins.

Inspect packages from private or folder NuGet feeds using explicit sources, mapping and noninteractive authentication; preserve source authority and distinguish failures from package absence.

Review .NET projects, packages and libraries as a quick orientation or evidence-bounded deep dive; explain dependencies, structure, performance candidates and ownership concerns without treating metrics as verdicts.

Discover dotnet-inspect capabilities and query rules, select inspection sections, and shape answers with common formats, projections and limits; follow installed explanation for deeper contracts.

Trace .NET package and Type dependencies, implementors, subclasses, extensions, calls and callers; use scoped graph evidence to explain connections without claiming unverified coverage.

Check NuGet package and .NET library provenance, advisories, compatibility metadata and unsafe/interop declarations; investigate focused audit evidence while keeping observations distinct from trust verdicts.

Locate .NET source files and Member spans through Portable PDB and SourceLink data, then read checksum-matched content locally or remotely while preserving provenance and availability boundaries.

Use when shipping a new dotnet-inspect version; independently validate one immutable candidate, present concerns, and publish only after the operator decides.

Use when an agent opens, owns, or drives a pull request in this repository, and again for every CI, review, conflict, base-movement, merge, close, or check-in event. Applies locked-head rounds, labels, tracker entry, merge authorization, and check-in cadence.

Use before editing AGENTS.md — enforces the 120-line launch and Steward boundaries, protected operator templates, and focused-document ownership.

Use when authoring or validating dotnet-inspect workflow scenarios, including exact-build execution, performance gates, profiling, and network observation.