Add Copilot CLI skill definitions for azure-ai packages

[jpalvarezl]

Summary

Adds reusable Copilot CLI skill definitions under \sdk/ai/.skills/\ to provide domain-specific guidance for common Azure SDK for Java workflows.

Skills included

Skill	Purpose
\codegen\	TypeSpec code generation via tsp-client
\dup-classes\	Verify generated classes against \openai-java\ models
\github\	GitHub interactions via gh CLI
\release-notes\	Update CHANGELOG.md and README.md from a PR
\run-tests\	Run Maven tests with mode and secret support
\search-m2\	Search Maven local repo for classes/JARs
\test-proxy\	Push test-proxy recordings
\tsp-naming-collision\	Fix TypeSpec naming collisions in Java codegen
\tsp-type-override\	Override TypeSpec types with Java-native types

Notes

• Each skill is a markdown file (\SKILL.md) with structured instructions for Copilot CLI agents.
• No code changes — these are documentation/tooling files only.
• Reviewed for personal data leaks before committing.

[Copilot]

Pull request overview

Adds a set of reusable Copilot CLI skill definition markdown files under sdk/ai/.skills/ to provide domain-specific guidance for common Azure SDK for Java workflows (TypeSpec codegen/customization, testing, release notes, GitHub CLI usage, etc.).

Changes:

• Introduces multiple SKILL.md definitions for AI-related developer workflows (TypeSpec generation/customization, test execution, release note drafting).
• Adds skills for operational tooling (GitHub gh, test-proxy publishing, Maven local repo inspection, Key Vault work-resources secret management).
• Adds a skill for comparing generated models vs openai-java model shapes.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
sdk/ai/.skills/codegen/SKILL.md	Skill instructions for tsp-client update/sync/generate workflows.
sdk/ai/.skills/dup-classes/SKILL.md	Skill instructions for field-by-field model shape comparison vs openai-java.
sdk/ai/.skills/github/SKILL.md	Skill instructions for GitHub interactions via gh CLI.
sdk/ai/.skills/release-notes/SKILL.md	Skill instructions for drafting/updating CHANGELOG/README content from a PR.
sdk/ai/.skills/run-tests/SKILL.md	Skill instructions for running Maven tests (modes, secrets, troubleshooting).
sdk/ai/.skills/search-m2/SKILL.md	Skill instructions for locating classes/JARs in ~/.m2/repository.
sdk/ai/.skills/test-proxy/SKILL.md	Skill instructions for pushing test-proxy recordings/assets.
sdk/ai/.skills/tsp-naming-collision/SKILL.md	Skill instructions for resolving TypeSpec → Java codegen naming collisions (suffix 1).
sdk/ai/.skills/tsp-type-override/SKILL.md	Skill instructions for @@alternateType overrides and validation/testing guidance.
sdk/ai/.skills/wr-load/SKILL.md	Skill instructions for managing secrets via work-resources (wr-*) CLI.

[ronniegeraghty]

Hi @jpalvarezl,
Thanks for putting this together. Having reusable skills documented like this is a great direction.

One thing I wanted to flag is that some of these skills overlap with work we are doing as part of the Azure SDK Tools Agent effort. We are currently defining a shared set of skills that will be pushed across Azure SDK repos and designed to work with the tools agent. The goal is for those skills to be language-agnostic, while the agent itself handles the language-specific logic.

Because of that, we want to avoid having overlapping skills in individual repos that could potentially confuse coding agents. At first glance, the following look like they may overlap with the shared skills we are defining:

• codegen
• github
• release-notes
• run-tests
• test-proxy

@samvaity, can you look over the others as well and follow up if any additional ones overlap with our skills or MCP tools?

For context, here is the documentation for the tools agent:
https://aka.ms/azsdk/agent

And here is the current PR where we are defining the shared skills:
Azure/azure-sdk-tools#14285

It would probably be good for us to align on these before we land repo-specific versions so we do not end up with multiple competing skills for the same workflows.