Name: azsdk-common-generate-sdk-locally
Rating: 67.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

82%

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

70%Weight 40%Scale 1-5

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

A well-structured, actionable workflow with strong sequencing and validation, undermined by repetition across sections and by references to bundle files that are not actually present.

Suggestions

Remove the Triggers section and the redundant intro sentence since the same information is already in the frontmatter description, or keep only the body and trim the frontmatter to avoid duplication.

Add the missing references/sdk-repos.md, references/detailed-workflow.md, and references/customization-workflow.md files (or remove the links and inline the necessary detail) so progressive-disclosure navigation does not dead-end.

Collapse the Troubleshooting retry guidance into the Guardrails section to eliminate the repeated 'if customized_code_update fails, report and retry, do not edit manually' message.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient and avoids explaining concepts Claude already knows, but the Triggers section duplicates the frontmatter WHEN/USE FOR/DO NOT USE FOR content, the intro restates the description, and Troubleshooting repeats the Guardrails retry guidance — more than minor tightening is needed.	3 / 5
Actionability	Steps cite concrete MCP tool names (azsdk_package_generate_code, azsdk_customized_code_update) and config-file paths (tspconfig.yaml, tsp-location.yaml), giving mostly executable guidance with minor gaps where detail is deferred to reference files.	4 / 5
Workflow Clarity	The 11-step sequence is clearly ordered with explicit validation checkpoints (verify setup, build gate, run check + tests) and a feedback loop (customize on build failure before proceeding), plus commit checkpoints at steps 8 and 11.	5 / 5
Progressive Disclosure	Sections are well organized and references are signaled one level deep ([SDK repos], [customization workflow], [detailed workflow]), but the referenced files (references/sdk-repos.md, references/detailed-workflow.md, references/customization-workflow.md) do not exist in the bundle, so navigation leads to dead ends.	3 / 5
	Total	15 / 20 Passed

Description

95%Weight 40%Scale 1-5

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

A strong, third-person description that clearly states capabilities, enumerates comprehensive natural trigger phrases, and sets explicit use/boundary guidance. Voice is correctly third person and it avoids over-claiming.

Dimension	Reasoning	Score
Specificity	The prose names the domain and several concrete actions — "Generate, build, and test Azure SDKs locally from TypeSpec with automatic customization" — but the granular sub-capabilities (rename client, hide operation, create subclient) appear only in trigger phrases, leaving minor coverage gaps in the what-clause.	4 / 5
Completeness	It explicitly answers both what ("Generate, build, and test Azure SDKs locally from TypeSpec with automatic customization") and when (WHEN: ... concrete trigger phrases), plus a DO NOT USE FOR boundary clause.	5 / 5
Trigger Term Quality	The WHEN clause lists a comprehensive set of natural trigger phrases users would actually say ("generate SDK locally", "build SDK", "fix SDK build errors", "rename SDK client", "hide operation from SDK"), with broad synonym coverage.	5 / 5
Distinctiveness Conflict Risk	"Azure SDKs locally from TypeSpec" is a clear niche with distinct triggers, and the DO NOT USE FOR clause (publishing, CI pipeline config, API design review) sharply reduces conflict risk with adjacent skills.	5 / 5
	Total	19 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 8 missing	Warning
referenced_paths_exist	Referenced path issues: 8 missing	Warning

	Total	14 / 16 Passed

Repository: Azure/azure-sdk-for-net
Path: .github/skills/azsdk-common-generate-sdk-locally/SKILL.md
Commit: b82d2f2

Reviewed: 1 day 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.