CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

Quality

82%

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

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

The body is a well-organized shared-rules hub with genuinely actionable decision procedures (canonical reconciliation tokens, a two-step rationale test with worked examples) and excellent one-level reference navigation grouped by plane. Its weaknesses are verbosity in the persona/maintenance sections and detail (normative-strength worked examples, reconciliation mechanics) inlined in SKILL.md that would be better split into reference files.

Suggestions

Move the "Normative strength and documented rationale" worked examples and the reconciliation action-token detail into dedicated reference files, keeping only the severity mapping table and the token precedence summary inline in SKILL.md.

Trim the "Design Principles" section to the calibration-by-consumer guidance and cut the motivational persona prose (e.g., the "broken SDK, security hole… millions of Azure customers" framing) that adds tokens without changing reviewer behavior.

Verify that every references/*.md path linked in the reference tables actually exists in the published bundle — none of the referenced files are present alongside this SKILL.md, so the navigation cannot be exercised as written.

DimensionReasoningScore

Conciseness

The reconciliation and normative-strength sections are dense, non-obvious policy that earns their tokens, but the "Design Principles" persona narrative ("meticulous, skeptical… Missing a violation means a broken SDK, a security hole, or an inconsistency that millions of Azure customers will encounter"), the maintainer-facing "Maintenance & Upstream Alignment" prose, and rhetorical framing around the worked examples could be tightened. Mostly efficient with some unnecessary explanation, rather than several padded sections.

3 / 5

Actionability

Concrete, executable decision procedures: literal uppercase action tokens (SKIP-COVERED, REPLY-LINE-SHIFT, RESOLVE-AND-REPOST, CLARIFY-CONFLICT, POST-NEW) with an explicit precedence order and a fetch-failure path, an ordered two-step rationale test with pass/fail worked examples, and a severity mapping table. Not fully self-contained because the concrete review-execution detail is deferred to instruction/reference files that are not part of this body.

4 / 5

Workflow Clarity

The ARM cross-session reconciliation is a clearly sequenced procedure with checkpoints: inventory all paginated threads/comments/review bodies, match by semantic finding identity, apply the token precedence, and follow the explicit failure path when a surface cannot be fetched. The document overall is a rules compendium rather than one end-to-end workflow with full validation feedback loops, which keeps it below the top anchor.

4 / 5

Progressive Disclosure

Well-signaled, one-level-deep reference navigation: tables grouped by plane (cross-cutting, ARM-only, data-plane-only) with rule IDs, plus explicit anti-inheritance warnings about which files a reviewer must not load. However, the ~100-line "Normative strength and documented rationale" section and the ~45-line reconciliation detail are inline content that belongs in reference files, and the referenced references/*.md paths are not present in this bundle, so the links cannot be verified.

4 / 5

Total

15

/

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 description: concrete capabilities, explicit USE FOR / DO NOT USE FOR triggers, third-person voice, and active disambiguation from the sibling authoring skill. The only gap is modest trigger-term coverage (no file extensions), which keeps trigger quality just below the top anchor.

DimensionReasoningScore

Specificity

Lists multiple concrete review capabilities — "reviewing API specs for naming, security, property design, resource lifecycle, error design, and versioning compliance" — plus what the bundle contains ("cross-cutting review guidelines plus plane-specific references") in third-person voice. Coverage of the review domain is comprehensive, including explicit negative scope, so it exceeds the "minor gaps" level.

5 / 5

Completeness

Explicitly answers both what ("Shared Azure REST API review rules for OpenAPI (Swagger) and TypeSpec specifications") and when ("USE FOR: reviewing API specs for naming, security, property design, resource lifecycle, error design, and versioning compliance") with concrete trigger phrases, plus a DO NOT USE clause. The "when" is explicit and specific, not merely present.

5 / 5

Trigger Term Quality

Natural terms users would say are well covered: "Azure REST API review", "OpenAPI (Swagger)", "TypeSpec", "ARM", "data-plane", "API specs", with the OpenAPI/Swagger synonym pair included. It falls short of the top anchor because file extensions (.json, .tsp) and a few common phrasings (e.g., "spec PR review") are absent.

4 / 5

Distinctiveness Conflict Risk

Clear niche (Azure REST API spec review) with actively disambiguated boundaries: "DO NOT USE FOR: authoring TypeSpec files (use azure-typespec-author), SDK generation, or releasing packages" names the nearest sibling skill directly. Minimal conflict risk.

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.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 30 missing, 8 suspicious

Warning

referenced_paths_exist

Referenced path issues: 30 missing

Warning

Total

14

/

16

Passed

Repository

Azure/azure-rest-api-specs

Path

.github/skills/azure-api-review/SKILL.md

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.