CtrlK
BlogDocsLog inGet started
Tessl Logo

azure-api-review

Shared Azure REST API review rules for OpenAPI (Swagger) and TypeSpec specifications. Contains cross-cutting review guidelines plus plane-specific references used by the ARM and data-plane API reviewers, code review agents, and CI workflows. USE FOR: reviewing API specs for naming, security, property design, resource lifecycle, error design, and versioning compliance. DO NOT USE FOR: authoring TypeSpec files (use azure-typespec-author), SDK generation, or releasing packages.

67

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

The risk profile of this skill

SKILL.md
Quality
Evals
Security

Quality

Content

71%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-architected instruction-only hub skill: excellent reference organization and concrete, rule-ID-anchored guidance with decision procedures and validation paths. The main weakness is length — some shared-rule sections and worked examples could be tightened or moved to references to improve token efficiency.

Suggestions

Move the full 'ARM cross-session reconciliation' token definitions and precedence detail into a dedicated reference file, keeping only the precedence summary and the incomplete-fetch failure rule inline in SKILL.md.

Tighten the 'Normative strength and documented rationale' worked examples to short illustrative snippets; the current multi-paragraph argumentation adds tokens without proportional new guidance.

Condense the Design Principles list (e.g., the 'Expert persona' paragraph) to the operative calibration rule, since the surrounding philosophy is inferable from the rules themselves.

DimensionReasoningScore

Conciseness

The body is dense with substantive domain guidance rather than padding about known concepts, but sections like the full worked-example argumentation and the literal reconciliation-token definitions are lengthy material that could be tightened or moved to reference files, fitting the 'mostly efficient but could be tightened' anchor.

3 / 5

Actionability

Guidance is concrete and specific — explicit rule IDs, a normative-strength-to-severity table, a two-step exception test with outcomes, and literal uppercase reconciliation tokens with a precedence order — but the actual execution mechanics (fetching threads, posting) are deferred to the referenced instruction and reference files, leaving minor gaps.

4 / 5

Workflow Clarity

Sequenced procedures are present with checkpoints: the two-step test ('Both steps must pass...') and the reconciliation flow with an explicit failure path ('If any discussion surface cannot be fetched completely, reconciliation is incomplete... do not silently treat all candidates as POST-NEW'), though it is several parallel procedures rather than one end-to-end numbered workflow with feedback loops.

4 / 5

Progressive Disclosure

The body is an overview plus shared cross-cutting rules, delegating per-area detail to ~20 one-level-deep reference files organized in tables grouped by plane with rule areas and key rule IDs, plus an explicit 'Anti-inheritance' navigation guard — a clear overview with well-signaled one-level references and easy navigation.

5 / 5

Total

16

/

20

Passed

Description

92%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, well-structured description that states what the skill contains, when to use it, and where the boundaries are against sibling skills. Third-person voice is used throughout. The only minor gap is the absence of file-extension trigger terms.

DimensionReasoningScore

Specificity

The description names the domain (OpenAPI/Swagger and TypeSpec Azure REST API specs) and lists six concrete review actions — 'naming, security, property design, resource lifecycle, error design, and versioning compliance' — giving comprehensive coverage rather than a single generic verb.

5 / 5

Completeness

It explicitly answers both 'what' ('Shared Azure REST API review rules... Contains cross-cutting review guidelines plus plane-specific references') and 'when' via the explicit 'USE FOR:' clause, plus a 'DO NOT USE FOR' boundary — the strongest anchor form.

5 / 5

Trigger Term Quality

It surfaces natural vocabulary a user would say ('reviewing API specs', 'OpenAPI (Swagger)', 'TypeSpec', 'ARM', 'data-plane') with synonyms, but omits file-extension triggers like .json or .tsp, so it sits just below the comprehensive-anchor.

4 / 5

Distinctiveness Conflict Risk

A clear niche (Azure REST API spec review) with explicit disambiguation against the sibling azure-typespec-author skill via 'DO NOT USE FOR: authoring TypeSpec files (use azure-typespec-author), SDK generation, or releasing packages', minimizing wrong-skill triggering.

5 / 5

Total

19

/

20

Passed

Validation

87%

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

Validation14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 29 missing, 11 suspicious

Warning

referenced_paths_exist

Referenced path issues: 29 missing

Warning

Total

14

/

16

Passed

Repository
Azure/azure-rest-api-specs
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.