I add NetFx breaking-change guidance skill

[w3lld1]

Fixes #14770

Proposed changes

• I add the proposed netfx-breaking-change-guidance repository skill.
• I document how to identify, validate, and describe behavior changes from .NET Framework.
• I include the current Collection Editor change as a live example with migration guidance.

Customer Impact

• I give maintainers and contributors a consistent checklist for writing actionable release notes and migration guidance.
• I distinguish open proposals from merged or shipped behavior to reduce misleading compatibility documentation.

Regression?

• No. I only add repository guidance under .github/skills.

Risk

• I limit the change to the exact skill text proposed in the issue, so the risk is low.

Test methodology

• I verified that the checked-in file exactly matches the proposed SKILL.md block in Create Skill for NetFx breaking changes #14770.
• I parsed the YAML frontmatter and confirmed the expected skill name.
• I rechecked the linked issue, implementation PR, label inventory, and passing CI evidence.
• I ran git diff --check.

Test environment

• Debian Linux; documentation-only change.

Microsoft Reviewers: Open in CodeFlow

[KlausLoeffelmann]

While I VERY MUCH like the idea of having a "breaking changes" skill, I think the content of this particular one (or this one scenario it covers, rather) is too niche.

And I very much assume, this is probably meant as a starting point, but that introduces another issue, which we need to prevent, FWIW.

For the scenario itself: I'm also not entirely sure which collection editor is being referred to. Is it the collection editor that Visual Studio shows at design time for the out-of-process designer (as opposed to the in-process designer)? If so, I would rather see this issue covered by a dedicated skill that focuses on Control Designer breaking changes when migrating Control Designer [Dialog-based] Type Editors from .NET Framework to .NET.

If it's the Collection Editor we show at runtime, however, that's an extremely niche scenario. We need to set a high bar and be very mindful about what information we bring into the context window as generally relevant and important. FWIW, I don't think a regression of the runtime Collection Editor clears that bar.

But - that's details. I think this topic is important enough to address it; we just need to figure out that the approach still works, when we got 100 issues we want to be taken into account. And one skill file would definitely not do that.

That's why I think we should consider two complementary approaches to handling breaking changes. This is an extremely important area that deserves high priority:

a) Skills. A concise, high-level skill whose purpose is to highlight the major categories of breaking changes, covering only the highest-risk and most commonly encountered issues, while referencing more specialized skills for the details.

b) Analyzers. We can't fill the context window with countless implementation details. Instead, analyzers could surface "Copilot Warnings" that flag potential issues for the agent to review and verify.

Happy to discuss more!

[KlausLoeffelmann]

The "Use this skill" paragraph should be moved into the front matter description field, but it shouldn't instruct the model to "use this skill explicitly." The description is the metadata that the harness agent uses to determine whether the skill should be loaded into the context window.

[w3lld1]

Thanks for the review. I moved the task-selection wording into the frontmatter description and removed the redundant “Use this skill” paragraph in f8743d8.

The tracked example is the design-time Collection Editor used by WinForms designers, not an application runtime editor. I agree that a growing catalog should not become one monolithic skill; I kept the current content scoped while the high-level skill plus specialized guidance/analyzer direction is discussed.

Validation: parsed the YAML frontmatter and ran git diff HEAD^ --check.