nuget-diff-analyzer
Skill14 starsChanged 3 months agoMITView on GitHub
Post-processes the repository-pinned dotnet-inspect@0.9.1 -- diff output into a categorised report (breaking / additive / newly-obsolete) with each finding cross-referenced to the MAF obsolete-API registry.
Files
nuget-diff-analyzer — structured NuGet version-diff reports
⚡ Prefer the MCP tool. The
maf-autopilotMCP server exposesMafDiffPackage(packageId, oldVersion, newVersion)— it targets the exactdotnet-inspect@0.9.1 -- diffformat, parses the markdown output into a structuredDiffParseResult(Breaking / Additive / NewlyObsolete lists), and cross-references each finding against the obsolete-API registry. The procedural walkthrough below is preserved for when you need to run the steps manually.
Why this exists
Raw dotnet-inspect diff output is markdown-pretty but unstructured — the LLM has to re-parse it on every call. The MCP tool does the parsing once and returns structured findings that downstream tools (best-practice reviewer, migration auditor) can consume directly.
Manual fallback workflow
# Step 1: emit the raw diff
dotnet-inspect diff \
--package Microsoft.Agents.AI@1.2.0..1.3.0 --source https://api.nuget.org/v3/index.json
# Step 2: read the output. It has the shape:
# # API Diff: <package>
# | Versions | **1.2.0** -> **1.3.0** |
# | Summary | N breaking, M additive across K types |
#
# ## Breaking Changes
# ### <Type>
# - Member '...' signature changed: `oldSig` -> `newSig`
# - Member '...' was removed
#
# ## Additive Changes
# ### <Type>
# - Type '...' was added
# - Member '...' was added
# Step 3: for each breaking change, look up the registry:
# MafApiSafety("<symbol-name>")
# or browse .github/skills/maf-obsolete-api-registry/registry.yamlOutput categories (what MafDiffPackage produces)
| Category | Origin in diff output | Action |
| Breaking | ## Breaking Changes section | Add to migration plan; high risk |
| Additive | ## Additive Changes section | Inform future patterns; not urgent |
| NewlyObsolete | Any entry whose body contains [Obsolete...] | Inspect; likely a deprecation flag |
Pin reminder
Use exact dotnet-inspect 0.9.1. Versions before 0.7.8 miss [Obsolete] at the overload level — see issue #316 — and 0.9.1 avoids the redirected-output corruption encountered by the release watcher. Install it with dotnet tool install --global dotnet-inspect --version 0.9.1 before running the direct invocation above.
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- cs0618-hunterSkill
- dotnet-inspectSkill
- maf-anti-pattern-scannerSkill
- maf-doctor-self-evolutionSkill
- maf-fan-out-validatorSkill
- maf-from-semantic-kernelSkill
- maf-issue-reporterSkill
- maf-migration-guideSkill
- maf-migration-plan-creatorSkill
- maf-migration-retrospectiveSkill
- maf-obsolete-api-registrySkill
- maf-release-watcherSkill
- maf-remediation-playbookSkill
- maf-workflow-smoke-testerSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

