Generate breaking change documentation for merged dotnet/runtime PRs. USE FOR: creating breaking change docs, "document this breaking change", "write breaking change issue for PR #NNNNN", processing PRs labeled needs-breaking-change-doc-created. DO NOT USE FOR: general code review (use code-review skill), bug fixes, API proposals (use api-proposal skill).
Generate high-quality breaking change documentation for merged dotnet/runtime pull requests and file it as an issue in dotnet/docs.
When a PR in dotnet/runtime introduces a breaking change, the docs team needs a structured issue in dotnet/docs describing the change, its impact, and migration guidance. This skill automates that process:
.github/workflows/breaking-change-doc.md triggers when a PR labeled
needs-breaking-change-doc-created is merged (or the label is added to an
already-merged PR). It can also be run manually via workflow_dispatch with
an optional suppress_output flag for dry-run inspection. The compiled
workflow (.lock.yml) must be regenerated with gh aw compile after changes.| File | Purpose |
|---|---|
.github/workflows/breaking-change-doc.md | gh-aw workflow — triggers on PR merge/label |
.github/workflows/breaking-change-doc.lock.yml | Compiled workflow (generated by gh aw compile) |
.github/skills/breaking-change-doc/SKILL.md | This skill |
.github/skills/breaking-change-doc/Get-VersionInfo.ps1 | gh CLI-based .NET version detection |
.github/skills/breaking-change-doc/Build-IssueComment.ps1 | Builds PR comment with URL-encoded issue creation link |
The user provides one of:
#114929 or 114929)https://github.com/dotnet/runtime/pull/114929)Extract the PR number. The source repository is always dotnet/runtime.
Use GitHub tools to read comprehensive PR data. Collect all of the following:
area-* labels. If none exist, report an error asking the user to set one.Map the area-* label to the dotnet/docs feature area dropdown value:
area-* label pattern | Feature area |
|---|---|
area-System.Net.*, area-Networking | Networking |
area-System.Security.*, area-Cryptography | Cryptography |
area-System.Text.Json, area-Serialization | Serialization |
area-System.Xml.* | XML, XSLT |
area-Extensions-* | Extensions |
area-System.Globalization | Globalization |
area-System.Runtime.InteropServices*, area-Interop | Interop |
area-CodeGen-*, area-JIT | JIT |
area-System.Linq* | LINQ |
area-System.CodeDom, area-Analyzers | Code analysis |
area-Infrastructure-*, area-SDK | SDK |
area-System.Windows.Forms* | Windows Forms |
area-WPF | Windows Presentation Foundation (WPF) |
Most other area-System.* labels | Core .NET libraries |
If the mapping is unclear, use "Other (please put exact area in description textbox)" and include the actual area label in the description.
Run the helper script to determine the .NET version context:
pwsh .github/skills/breaking-change-doc/Get-VersionInfo.ps1 -PrNumber <number>
The script outputs JSON with:
LastTagBeforeMerge — the closest release tag before the merge commitFirstTagWithChange — the first tag that contains this commit (or "Not yet released")EstimatedVersion — human-readable version string like ".NET 11 Preview 3"MergeCommit — the merge commit SHAMergedAt — when the PR was mergedUse EstimatedVersion as the version for the breaking change issue.
If the script returns an error, fall back to reading the PR's base branch and recent tags manually to estimate the version.
Search for existing breaking change issues in dotnet/docs:
dotnet/docs issues for Breaking change <PR_NUMBER> with label breaking-change.Read the breaking change issue template from dotnet/docs at:
.github/ISSUE_TEMPLATE/02-breaking-change.yml
gh api repos/dotnet/docs/contents/.github/ISSUE_TEMPLATE/02-breaking-change.yml -H "Accept: application/vnd.github.raw"
This template defines the required sections and dropdown values. Use it as a structural reference only — do not output YAML.
Search dotnet/docs for 2-3 recent issues with the breaking-change label.
Read their bodies to understand the expected quality, tone, and level of detail.
Generate a complete breaking change issue. The output must be clean markdown formatted to work with the GitHub issue form template. Structure it as follows:
[Breaking change]: <concise description of the change>
Do not just repeat the PR title. Write a clear, user-facing summary.
Brief description of the breaking change. Include the PR link.
Use the EstimatedVersion from Step 2. Must match one of the template dropdown values
(e.g., ".NET 11 Preview 3"). If it doesn't match exactly, use
"Other (please put exact version in description textbox)" and state the version in the description.
Describe what happened before the change. Include a code example if applicable showing the old behavior.
Describe what happens now. Include a code example if applicable showing the new behavior. Highlight exceptions thrown, changed return values, or different default settings.
Categorize as one or more of:
Most changes are behavioral. Only mark binary/source incompatible when the change actually affects compilation or binary loading.
Explain why the change was made. Reference the motivation from the PR body and closing issues.
Provide specific, actionable guidance:
Use the mapping from Step 1.
List all affected APIs. For methods, specify whether it's all overloads or
specific ones. Use fully qualified names (e.g., System.IO.Compression.ZipArchiveEntry.Open()).
Create the output directory and write the full markdown content from Step 5
(everything except the title line) to
artifacts/docs/breakingChanges/issue-draft.md. This file is the primary
output and can be reviewed before taking any further action.
mkdir -p artifacts/docs/breakingChanges
Run the helper script to produce a PR comment with a URL-encoded issue link:
pwsh .github/skills/breaking-change-doc/Build-IssueComment.ps1 \
-IssueDraftPath artifacts/docs/breakingChanges/issue-draft.md \
-Title "<the [Breaking change]: ... title from Step 5>" \
-OutputPath artifacts/docs/breakingChanges/pr-comment.md
The script:
[Uri]::EscapeDataStringhttps://github.com/dotnet/docs/issues/new?... linkpr-comment.md containing the full draft, the link, and an email reminderWhen running interactively (not in dry-run mode), post the contents of
artifacts/docs/breakingChanges/pr-comment.md as a comment on the original
dotnet/runtime PR using GitHub tools.
When running in automated (gh-aw) mode, use the add_comment safe-output tool to post the comment.
When in dry-run mode or when the user has not explicitly asked to comment,
skip posting — the two files under artifacts/docs/breakingChanges/ are the
outputs for review.
The Build-IssueComment.ps1 script includes the standard AI disclosure note
in the generated comment. No additional action is needed.
The generated comment includes an email reminder. When running interactively, also remind the user:
Please email a link to this breaking change issue to .NET Breaking Change Notifications.
If the user asks for a draft or review before publishing, or if you are uncertain about any aspect of the documentation:
When the user has not explicitly asked to create the issue, default to draft mode.
If the user provides a GitHub search query or asks to process multiple PRs:
| Problem | Solution |
|---|---|
No area-* label on PR | Ask the user to add one, or ask which area applies |
| Version detection script fails | Read the PR's base branch and use git describe --tags --abbrev=0 manually |
| PR not yet merged | Breaking change docs are for merged PRs only — inform the user |
| Existing docs issue found | Report the existing issue URL and stop |
| Cannot determine affected APIs | Review the diff carefully; list the public types/methods in changed files |
| Workflow not triggering | Ensure gh aw compile was run and .lock.yml is committed |
| AI output needs review | Check technical accuracy of before/after behavior, API list completeness, and migration guidance |