CtrlK
BlogDocsLog inGet started
Tessl Logo

azsdk-common-sdk-release

Check release readiness and trigger the release pipeline for Azure SDK packages. **UTILITY SKILL**. USE FOR: "release SDK", "trigger release", "check release readiness", "release pipeline", "publish package", "ship SDK". DO NOT USE FOR: SDK development, code generation, pipeline debugging, release plan creation. INVOKES: azure-sdk-mcp:azsdk_release_sdk.

66

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.github/skills/azsdk-common-sdk-release/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

The body is well-structured and actionable at the tool/parameter level, but it carries a redundant Triggers section, an incomplete invocation specification, and an internal contradiction about whether to run a readiness check before triggering. Progressive disclosure is appropriate for this simple single-file skill.

Suggestions

Remove the 'Triggers' section (or trim it to a one-line pointer) since the frontmatter description already contains the identical USE FOR / DO NOT USE FOR lists.

Show the full `azure-sdk-mcp:azsdk_release_sdk` invocation including `packageName`, `language`, and `branch` arguments alongside `checkReady`, so the call is copy-paste ready rather than just naming the boolean flag.

Resolve the contradiction between Rules ('run the readiness check before attempting to trigger release') and Step 2 ('proceed to trigger directly' unless the user asks) by choosing one gating policy and applying it consistently.

DimensionReasoningScore

Conciseness

The body is free of concept-explanation filler and assumes competence, but the 'Triggers' section (lines 15-19) duplicates the frontmatter's USE FOR / DO NOT USE FOR lists verbatim, so not every token earns its place.

2 / 3

Actionability

Steps name the exact tool and the `checkReady` parameter value, but never show the full invocation with `packageName`, `language`, and `branch` arguments, leaving the call form incomplete rather than copy-paste ready.

2 / 3

Workflow Clarity

Steps are clearly sequenced with a failure feedback loop, but the Rules ('run the readiness check before attempting to trigger release') contradict Step 2 ('proceed to trigger the release directly' unless the user asks), muddying the validation gate.

2 / 3

Progressive Disclosure

A short (~38 line), self-contained single-file skill with well-organized sections and no need for external references, which the rubric explicitly allows to score 3 for skills under 50 lines.

3 / 3

Total

9

/

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 strong across all dimensions: concrete actions, natural trigger terms, explicit use/don't-use guidance, and clear distinctiveness. Minor verbosity from the all-caps labels does not undermine any dimension.

DimensionReasoningScore

Specificity

It lists multiple concrete actions ('Check release readiness and trigger the release pipeline for Azure SDK packages'), matching the multiple-specific-actions anchor rather than vague language.

3 / 3

Completeness

It explicitly answers what it does and when to use it via a USE FOR clause with explicit triggers, and adds a DO NOT USE FOR clause, satisfying the what-and-when anchor.

3 / 3

Trigger Term Quality

The USE FOR clause gives natural phrases a user would say ('release SDK', 'trigger release', 'publish package', 'ship SDK') with good coverage of phrasing variations.

3 / 3

Distinctiveness Conflict Risk

It carves a clear niche (Azure SDK release pipeline) and the DO NOT USE FOR clause excludes adjacent tasks (SDK development, code generation, pipeline debugging, release plan creation), making conflict unlikely.

3 / 3

Total

12

/

12

Passed

Validation

100%

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

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
Azure/azure-sdk-for-net
Reviewed

Table of Contents

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.