Improve Copilot guidance for validation, PR feedback, and CI triage

Read .github/copilot-instructions.md and the related .github/instructions/build.instructions.md to understand the existing guidance and avoid duplicating it. Update the repository-wide instructions with the four requested workflow areas, then review the result against the issue's proposed rules and confirm the change remains documentation-only.

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Recent ASP.NET Core Copilot sessions repeatedly encountered the same avoidable friction even though the existing repository guidance already covers baseline reproduction, acceptance criteria, red/green testing, faithful behavioral boundaries, SDK activation, and MSBuild configuration matrices.

The recurring gaps were:

1. Required skills were bypassed when not installed locally. Multiple sessions were explicitly told to use explain-changes or introspect-session, but initially substituted a hand-written approximation. The user then had to clarify that the skills were available from javiercn/skills and require the skill-driven workflow.
2. Validation commands selected a wider dependency graph than the changed product required. Response Caching's Middleware wrapper expanded into unrelated native IIS/googletest prerequisites; a focused gRPC test traversed Blazor-generated assets, native IIS, and an uninitialized submodule; ProjectTemplates' normal area build did not produce its delayed test assembly, while hosted template tests required the full local package graph. In each case, the focused product boundary was valid but had to be discovered after unrelated failures.
3. PR feedback enumeration required corrective passes. Sessions needed additional GraphQL/REST queries to include submitted review bodies, suppressed/minimized comments, resolved/outdated inline threads, top-level comments, requested changes, and current-head checks. On #69231, actionable guidance was present in a review body's suppressed comments rather than only in standard inline-thread output.
4. Red Azure DevOps aggregates did not identify the actionable failure. On #69231, one run contained a pre-existing Kestrel assertion already fixed on newer main; the replacement run contained a different whole-batch timeout (exit 137, no failed assertion) whose exact target baseline passed in 8:14. Other recent gRPC, Identity, and Components.AI sessions likewise needed exact job/work-item attribution to separate unrelated Kestrel/file-lock failures from a genuinely PR-caused dependency-discovery failure.

Describe the solution you'd like

Add concise repository-wide rules to .github/copilot-instructions.md covering these four workflows.

1. Honor explicitly requested skills

Proposed guidance:

When the user explicitly requires a skill that is not installed in the current session, locate it in the available repository or user skill sources (including javiercn/skills when applicable), load or install it for the session, and follow its workflow. Do not silently replace a required skill with an unstructured approximation.

2. Select the smallest faithful validation graph

Proposed guidance under Running tests:

Inspect an area's build wrapper before running it. After activating the repository SDK, start with the exact test project or documented focused command when it faithfully exercises the changed surface, then broaden validation deliberately. Area wrappers can expand unrelated projects and require native submodules, generated assets, installers, or a full local package graph.

If validation is blocked by an unrelated prerequisite, name the exact prerequisite and distinguish that boundary from a product build or test failure. Do not claim the broader validation passed, and do not treat the missing prerequisite as evidence that the changed product is broken.

This should complement, not replace, the existing requirement to use area build scripts and the scoped MSBuild guidance in .github/instructions/build.instructions.md.

3. Enumerate every PR feedback surface

Proposed guidance:

Before declaring a PR feedback pass complete, inspect top-level conversation comments, submitted review bodies (including suppressed or minimized content), inline review threads including resolved or outdated threads, requested-changes state, and checks for the current head commit.

Evaluate feedback against the issue contract and current target branch rather than accepting it blindly. For feedback that is incorrect, obsolete, or out of scope, reply with concise evidence and do not broaden the change.

Reply inside each addressed inline review thread and resolve it only after the fix and reply are pushed. Record actionable feedback handled, feedback intentionally not adopted, the resulting head commit, validation, and any unresolved blockers.

4. Require evidence-based AzDO/Helix classification and bounded retries

Proposed guidance:

Resolve every red aggregate to the exact Azure DevOps build, timeline job, Helix job and work item, exit code, test-result presence, and relevant log evidence before changing code or rerunning CI. Treat Build Analysis classifications and historical rates as investigation leads, not proof.

Correlate each failure with the PR's changed files and build progression. When attribution is unclear, compare the exact target-parent commit used by the PR merge build with a target-branch build of the same job, batch, or test.

Use /azp run only after every current failure is accounted for as PR-caused, known, transient, or unrelated. Verify that replacement builds were queued and monitor them to a terminal state. Do not retry an immutable failed Helix monitor result, create an empty commit to rerun CI, or repeatedly retry the same unmatched failure.

Additional context

This proposal comes from reviewing repeated friction across multiple recent dotnet/aspnetcore implementation, PR-maintenance, and CI-investigation sessions, including merged PR #69231. It intentionally does not duplicate existing instructions for current-main reproduction, acceptance criteria, faithful validation boundaries, per-case red/green verification, repository SDK activation, public API review, or the configuration-matrix rules in .github/instructions/build.instructions.md.

The changes are documentation-only. Product-specific cache-accounting and middleware-state testing lessons may be better handled separately in a future scoped src/Middleware/AGENTS.md; they are not included here because the repeated repository-wide evidence is stronger for the four workflows above.