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.

69

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

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.

This is a strong, well-structured overview skill: progressive disclosure is exemplary with real, organized reference files and explicit plane-segregation guidance, and the reconciliation workflow is concrete with canonical tokens and a failure checkpoint. The main weakness is conciseness -- several sections over-explain process and normative-strength meta-rules that could live in references.

Suggestions

Move the lengthy 'Normative strength and documented rationale' worked examples and step-by-step tests into a dedicated reference file, keeping only the severity-tag table and the one-line two-step test summary in SKILL.md.

Tighten the 'Design Principles' and 'Maintenance & Upstream Alignment' sections to bullet essentials; the expert-persona and upstream-precedence prose restates what the 'Authoritative External Sources' list already conveys.

Convert the reconciliation flow into a numbered step list ending with the explicit 'if any surface is unfetchable, follow the failure path' validation checkpoint so the sequence and gate are visually unambiguous.

DimensionReasoningScore

Conciseness

The body is well-organized but runs long; sections like 'Normative strength and documented rationale' with worked examples, the enumerated 'Design Principles', and the maintenance prose restate meta-concepts about guideline strength and process that a competent reviewer largely already knows, and could be trimmed or pushed to a reference.

3 / 5

Actionability

It provides concrete, actionable artifacts -- canonical reconciliation tokens (SKIP-COVERED, REPLY-LINE-SHIFT, etc.), a precedence-ordered source list with URLs, a severity mapping table, and exact file references -- though the bulk of executable rule content lives in the reference files rather than inline.

4 / 5

Workflow Clarity

The ARM cross-session reconciliation section lays out a clear ordered process (inventory -> match by semantic identity -> choose canonical token -> handle incomplete fetch by following failure path) with an explicit error-recovery checkpoint for unfetchable surfaces; minor gaps are that the validation gate is described narratively rather than as a step list.

4 / 5

Progressive Disclosure

Structure is exemplary: the SKILL.md is an overview that groups 29 reference files into Cross-cutting / ARM / Data-plane tables with one-level-deep links, all of which resolve to real files, and includes explicit 'do not load the other plane' navigation guidance plus an anti-inheritance callout.

5 / 5

Total

16

/

20

Passed

Description

100%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.

The description is exemplary: it states concrete review actions, gives a natural-language USE FOR / DO NOT USE FOR trigger pair, and explicitly disambiguates from a sibling authoring skill. It reads in third person and avoids vague fluff.

DimensionReasoningScore

Specificity

Lists multiple concrete actions across the review domain -- 'reviewing API specs for naming, security, property design, resource lifecycle, error design, and versioning compliance' -- plus explicit exclusions, matching the comprehensive-coverage anchor.

5 / 5

Completeness

Explicitly answers both 'what' (cross-cutting review rules for OpenAPI/TypeSpec) and 'when' via a capitalized 'USE FOR: ... DO NOT USE FOR: ...' clause with concrete trigger and exclusion phrases.

5 / 5

Trigger Term Quality

Covers the natural vocabulary users would say -- 'API specs', 'OpenAPI (Swagger)', 'TypeSpec', 'reviewing ... PRs', 'naming, security' -- plus file-format synonyms (.json/.tsp implied by format names), giving comprehensive natural-term coverage.

5 / 5

Distinctiveness Conflict Risk

The clear niche (Azure REST API spec review rules) plus an explicit 'DO NOT USE FOR: authoring TypeSpec files (use azure-typespec-author), SDK generation, or releasing packages' minimizes conflict with adjacent skills.

5 / 5

Total

20

/

20

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 11 suspicious

Warning

Total

15

/

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.