Name: azsdk-common-generate-sdk-locally
Rating: 75.2 (1 reviews)
Author: Azure

azsdk-common-generate-sdk-locally

Generate, build, and test Azure SDKs locally from TypeSpec with automatic customization. WHEN: "generate SDK locally", "build SDK", "run SDK tests", "run CI checks", "validate package", "run checks", "update changelog", "fix SDK build errors", "fix breaking changes", "resolve SDK generation errors", "customize TypeSpec", "rename SDK client", "rename SDK model", "hide operation from SDK", "fix analyzer errors", "resolve customization drift", "create subclient", "update metadata", "update version". DO NOT USE FOR: publishing to package registries, CI pipeline configuration, API design review. INVOKES: azsdk_verify_setup, azsdk_package_generate_code, azsdk_package_build_code, azsdk_package_run_check, azsdk_package_run_tests, azsdk_customized_code_update, azsdk_package_update_changelog_content, azsdk_package_update_metadata, azsdk_package_update_version.

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is well-structured and highly actionable, with a clear validated workflow and clean progressive disclosure to real reference files. Its only weakness is moderate redundancy where the Triggers, Prerequisites, and Troubleshooting sections repeat information already present in the frontmatter and Rules.

Suggestions

Remove the Triggers section (or trim it to the USE FOR / DO NOT USE FOR summary) since the full WHEN list already lives in the frontmatter description, avoiding duplicate token spend.

Consolidate the "without MCP use tsp-client / npx tsp-client" guidance — currently stated in Rules, the MCP Tools Prerequisites line, and Troubleshooting — into a single canonical mention.

Trim Troubleshooting bullets that merely restate Rules/Guardrails (e.g. the customize-tool retry guidance and the all-languages redirect) and keep only genuinely new diagnostics.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient (tool tables, numbered steps, guardrails) but repeats material: the Triggers section restates the frontmatter WHEN list, the "without MCP use tsp-client/npx" guidance appears three times, and Troubleshooting reiterates Rules — tightening these would remove padding without losing clarity.	2 / 3
Actionability	Guidance is concrete and executable: a numbered 11-step workflow, an MCP tools table with exact tool IDs, guardrails naming the precise tool to call, and worked example prompts.	3 / 3
Workflow Clarity	The sequence is explicit with validation checkpoints — step 6→7 forms a build-fails/customize feedback loop, commit checkpoints gate progression, and validate (check+tests) precedes metadata updates with error-recovery guidance.	3 / 3
Progressive Disclosure	The body is a concise overview that links one level deep to real reference files (sdk-repos.md, detailed-workflow.md, customization-workflow.md, all present in references/), signaled inline and in a footer navigation row.	3 / 3
	Total	11 / 12 Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is a strong, third-person skill card that clearly states capabilities, provides an exhaustive set of natural trigger phrases, and bounds its scope with DO NOT USE FOR and INVOKES sections. It leaves little ambiguity about when to use it.

Dimension	Reasoning	Score
Specificity	The description lists multiple concrete actions — "Generate, build, and test Azure SDKs locally from TypeSpec with automatic customization" — covering the full end-to-end workflow rather than vague language.	3 / 3
Completeness	It explicitly answers both what (generate/build/test/customize Azure SDKs from TypeSpec) and when (explicit WHEN triggers), plus a DO NOT USE FOR boundary and INVOKES tool list.	3 / 3
Trigger Term Quality	An extensive WHEN list of natural phrases users would actually say ("generate SDK locally", "build SDK", "fix SDK build errors", "rename SDK client") gives strong coverage of common variations.	3 / 3
Distinctiveness Conflict Risk	The niche is precise (local Azure SDK generation from TypeSpec) with explicit DO NOT USE FOR exclusions and named MCP tools, making it unlikely to trigger for the wrong skill.	3 / 3
	Total	12 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Azure/azure-rest-api-specs
Path: .github/skills/azsdk-common-generate-sdk-locally/SKILL.md
Commit: b0960d6

Reviewed: about 2 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.