Eliminate Redundant Restores

A no-op restore still evaluates every project and checks restore state, so each extra restore in a multi-step build costs seconds to tens of seconds in a large repo. The cure is easy to get wrong: --no-restore on a step that no earlier restore actually covered turns a slow build into a failed one. This skill finds which invocations restore, proves which are already covered, and changes only those.

When to Use

• A pipeline or script runs several dotnet/msbuild steps and the log shows restore output in more than one of them
• A restore step exists, yet later steps still print Determining projects to restore...
• A repository Directory.Build.rsp or the active MSBuild installation's MSBuild.rsp contains -restore
• Someone asks where --no-restore or -restore:false can safely be added
• NETSDK1004 or NETSDK1047 appeared after --no-restore was added

When Not to Use

• The first restore is slow (feed latency, missing package cache): that is caching, not redundancy
• There is only one restore across all invocations: nothing to deduplicate
• Restore errors about versions, lock files or auditing: fix the restore itself
• Unranked "why is my build slow": start with build-perf-baseline, then build-perf-diagnostics