Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Thanks @hoyosjs. Your comments motivated a more critical review on my part. Your call-outs and the additional review made the skill quite a bit better.

🤖 Copilot Code Review — PR #126384

Holistic Assessment

Motivation: This PR adds a new Copilot skill definition to guide an AI agent through the process of updating OS version references in Helix queue pipeline files. This is well-justified — OS version updates are a recurring, mechanical task that touches multiple files with specific naming conventions, and encoding the procedure as a skill ensures consistency and reduces manual effort.

Approach: A single, comprehensive SKILL.md file with a clear step-by-step process (verify image → check EOL → scan references → apply changes → validate → trigger CI → check release branches → cross-reference supported-os → create PR). The document has been through 19+ rounds of iterative refinement and all technical claims have been verified against the actual pipeline files.

Summary: ✅ LGTM. This is a thorough, well-structured skill document. All queue format patterns, naming conventions, _internal counterparts, isExtraPlatformsBuild guards, and Alpine edge casing inconsistencies were verified as accurate against the actual pipeline files. The few suggestions below are minor improvements, not blockers.

Detailed Findings

✅ Technical Accuracy — Verified against pipeline files

All core technical claims were cross-checked against the actual source files:

• Queue format pattern (<QueueName>)<HostQueue>@mcr.microsoft.com/dotnet-buildtools/prereqs:<image-tag> matches entries in helix-platforms.yml ✓
• _internal counterparts (e.g., helix_linux_x64_oldest_internal) exist and correctly drop .Open ✓
• All naming convention patterns (Alpine, CentOS Stream, Debian, Fedora, openSUSE, Ubuntu) match actual entries ✓
• isExtraPlatformsBuild guard correctly identified for Debian, Fedora, openSUSE ✓
• Alpine edge casing inconsistency between files (Alpine.edge vs Alpine.Edge) is real ✓
• ARM64 host queue variations (Ubuntu.2204.ArmArch.Open vs AzureLinux.3.Arm64.Open) are accurately described ✓
• Referenced files (docs/project/os-onboarding.md, all pipeline files, lifecycle.md) all exist ✓

✅ Conventions — Consistent with sibling skills

• Frontmatter uses the standard name + description format with > folded block scalar ✓
• No trailing whitespace, file ends with newline per .editorconfig ✓
• AI-generated content disclosure note is present ✓
• Reference section at the end with relevant links ✓

✅ Structure & Completeness — Well-organized workflow

The 9-step process covers the full lifecycle: verification → research → scanning → editing → validation → CI → release branches → cross-referencing → PR creation. The "When NOT to use" section clearly scopes boundaries. The audit mode section provides a separate workflow for coverage auditing.

💡 Scope Clarity — Consider stating "Linux-focused" earlier (flagged by GPT-5.2)

The title and intro say "OS version references" broadly. The Linux-only scope is only clarified later in "When NOT to use" (line 33: "Updating Windows or macOS Helix queues…"). Consider adding a brief "(primarily Linux distros)" qualifier in the opening line to prevent an agent from attempting Windows/macOS queue updates before reaching the exclusion section.

💡 Alpine musl_arm64 Dual-Table Appearance — Minor clarity improvement (flagged by Sonnet 4.5, GPT-5.2 in different forms)

Alpine (versioned) linux_musl_arm64 appears in both the extra-platforms table (line 193) and the default pipeline table (line 204). The explanatory note (line 206) correctly resolves this, but the dual listing may momentarily confuse an agent parsing the tables. Consider annotating the first table entry with an asterisk (e.g., Alpine (versioned)* | linux_musl_arm64) with a footnote, or simply removing it from the first table since coreclr provides default coverage anyway.

💡 Search Strategy — Consider searching by old version tokens too (flagged by GPT-5.2)

Step 3 (line 120) suggests grep -rn -i "<distro>" to find all references. In practice, also searching for the specific old version tokens (e.g., Fedora.43, fedora-43, ubuntu-22.04) would catch version-specific references more reliably, especially in files where the distro name is embedded in longer strings. This is a nice-to-have addendum.

💡 Shallow Clone Detection — Helpful agent hint (flagged by Sonnet 4.5)

Line 231 mentions shallow clones may not have release branches visible and provides a git fetch workaround. Adding git rev-parse --is-shallow-repository as a detection step before the workaround would help an agent know when to apply it.

Generated by Code Review for issue #126384 · ◷