TypeSpec review: use the .NET code-review skill's C# naming rules instead of a restated copy #47839

Summary

Azure/azure-sdk-for-net#62615, merged Oct 30, makes the code-review skill the review standard for every .NET SDK PR. That includes its C# naming rules: Naming — Review-Only and the H2 naming checks.

This repo restates those rules in the azure-typespec-sdk-naming skill:

• .github/skills/azure-typespec-sdk-naming/references/csharp-naming.md (member names)
• .github/skills/azure-typespec-sdk-naming/references/csharp-model-naming.md (model names)

The TypeSpec review doesn't use them either. typespec-review.instructions.md is applied to .tsp files by Copilot code review and the ARM API Review workflow. Its rules cover REST naming; its only check on SDK names is @@clientName casing (§2.8). C# naming problems introduced in a spec PR therefore surface only when the generated .NET PR is reviewed, which is the late rework loop Azure/azure-sdk-tools#17269 is meant to remove.

Make the TypeSpec review check C#-visible names against the .NET rules, and make the skill link to those rules instead of restating them.

Why

• The copy disagrees with the .NET review. Spec-time guidance can produce names the .NET review then flags:

  • DateTimeOffset: the skill accepts At ("do not churn ... CreatedAt", L24); the .NET review requires On, with At only under sdk/ai (L299).
  • *Options models: the skill renames them to *Config (L28); the .NET review expands config to configuration (L386) and defaults payload models to Content, Result, or no suffix (L328).

  The At allowance and the extra boolean prefixes (L23) came from the azure-sdk-mgmt-pr-review skill (L93-L94) that Add repository-wide Azure SDK code review skill azure-sdk-for-net#62615 deleted.

• Its source links are broken. Both files cite .github/skills/azure-sdk-mgmt-pr-review/SKILL.md on main (csharp-naming.md L5, csharp-model-naming.md L5), which now returns 404. Their "Additional context" links pin repository-rules.md to 8ce543a7, a pre-merge PR commit.

• No sync keeps the copies aligned. Since the rename from azsdk-common-typespec-naming (Rename naming skill to azure-typespec-sdk-naming #47778, Rename naming skill to azure-typespec-sdk-naming azure-sdk-tools#17445), the skill falls outside the azsdk-common-* sync. This repo and azure-sdk-tools now maintain separate copies, which already differ: Reference C# emitter naming conversions in naming skill #47556 exists only here.

• The review and the skill disagree on casing. §2.8 requires camelCase @@clientName values for properties (L222-L224), but the skill's own example is @@clientName(WidgetProperties.enabled, "IsEnabled", "csharp") (L29).

Proposal

1. Link, don't restate. Replace the rule tables in both C# references with links to the canonical sections on azure-sdk-for-net main, not a SHA. Keep only TypeSpec-specific guidance: target and profile selection, language-scoped @@clientName, wire-name preservation, emitter defaults (Reference C# emitter naming conversions in naming skill #47556), emitter-synthesized types, shipped-API compatibility, and apply/validate.
2. Reconcile before deleting. Diff each restated rule against the canonical ones. Move rules that exist only here into azure-sdk-for-net, or drop them on purpose. Fix conflicts in azure-sdk-for-net, including its own Mgmt-Naming-Conventions.md, where Options → Config (L62) and Data/Info for *Operation (L87) originate. The canonical rules need a fix too: they suggest *Data for a non-Operation<T> *Operation model (L265) while reserving *Data for the ARM resource trio (L376).
3. Use the skill in the TypeSpec review. In §2.8, when a PR adds or changes C#-visible names (C#-scoped @@clientName overrides, or new public models, properties, or operations in a project that emits C#), apply azure-typespec-sdk-naming in read-only review mode. Copilot code review already loads a skill this way. Align the §2.8 casing rule with the skill.
4. Keep one TypeSpec-side copy. Make the same change to the azure-sdk-tools copy ([C# Naming] Consume C# naming rules from azure-sdk-for-net instead of restating them azure-sdk-tools#17371), or delete one of the copies.

Open question

Confirm that Copilot code review and the ARM API Review workflow can fetch cross-repo rules at review time; the #47625 prototype already fetches and pins the canonical .NET skill. If they can't, generate the copy from azure-sdk-for-net with a drift check instead of maintaining it by hand.

Acceptance criteria

• azure-typespec-sdk-naming defines no C# naming rules of its own; its C# profiles link to the azure-sdk-for-net code-review skill on main.
• No links to azure-sdk-mgmt-pr-review or pinned PR-branch SHAs remain.
• typespec-review.instructions.md routes C#-visible naming changes to azure-typespec-sdk-naming in review mode, and its @@clientName casing rule agrees with the skill.
• Evals cover the divergences above (CreatedAt, an *Options payload model), and the existing naming evals still pass (azure-typespec-author 007001–007014, azure-typespec-sdk-naming/evals).

Related

• [C# Naming] Consume C# naming rules from azure-sdk-for-net instead of restating them azure-sdk-tools#17371: the same de-duplication for the azure-sdk-tools copy
• Integrate shared SDK naming guidance into TypeSpec assessment azure-sdk-tools#17297: TypeSpec assessment naming integration, which should use the same source
• [Epic] C# ARM SDK readiness before spec merge azure-sdk-tools#17269: epic for C# ARM SDK readiness before spec merge

🤖 m-nash-copilot