CtrlK
BlogDocsLog inGet started
Tessl Logo

701-technologies-openapi

Use when you need framework-agnostic OpenAPI 3.x guidance — spec structure, metadata and versioning, paths and operations, reusable schemas, security schemes, examples, documentation quality, contract validation (e.g. Spectral), breaking-change awareness, and handoffs to codegen — without choosing Spring Boot, Quarkus, or Micronaut. This should trigger for requests such as Review an OpenAPI; Improve an OpenAPI; Improve API contract; Improve API schema design. Part of Plinth Toolkit

61

Quality

71%

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 ./skills/701-technologies-openapi/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.

Well-structured overview with excellent progressive disclosure to a single real reference, but the workflow is high-level and abstract with generic validation, and some build-tooling constraints add noise unrelated to OpenAPI guidance.

Suggestions

Make workflow steps concrete and actionable: name a specific validation step such as 'lint with Spectral: `spectral lint openapi.yaml`' and a fix-and-retry loop instead of 'Execute appropriate checks'.

Move or trim the repo build constraints ('./mvnw compile', 'mvn clean verify') that are about maintaining this skill rather than about producing OpenAPI contracts, so they do not consume the user-facing token budget.

Add one short inline example (e.g. a minimal reusable schema snippet or a path/operation skeleton) so the body gives executable guidance rather than only deferring to the reference.

DimensionReasoningScore

Conciseness

The body avoids explaining concepts Claude already knows and is mostly lean, but it carries build-tooling constraints ('./mvnw compile', 'mvn clean verify') that are about maintaining this skill repo rather than user-facing OpenAPI work, and the 'When to use' list duplicates triggers already in the description.

2 / 3

Actionability

The workflow steps are abstract ('Implement or refactor artifacts following the reference patterns and project conventions', 'Execute appropriate checks') and the concrete OpenAPI guidance is deferred entirely to the reference file; only the build commands and reference path are concrete, which is incomplete rather than copy-paste ready.

2 / 3

Workflow Clarity

Four numbered steps give a clear sequence and there is a VERIFY constraint plus EDGE CASE handling, but the validation checkpoint in step 4 ('Execute appropriate checks and summarize') is generic rather than a concrete validate-fix-retry loop, so it sits at the 'sequence present but checkpoints implicit' level.

2 / 3

Progressive Disclosure

The body is a concise overview pointing to a single one-level-deep reference (references/701-technologies-openapi.md, verified present), clearly signaled in both the Workflow and a dedicated Reference section, matching the well-signaled one-level-deep reference anchor.

3 / 3

Total

9

/

12

Passed

Description

85%

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, specific description that clearly states capabilities and triggers with a well-defined niche. Its main gap is trigger-term breadth: common phrasings like Swagger, validate, document, and REST/design are absent.

Suggestions

Broaden trigger terms to include common user phrasings such as 'Swagger', 'validate an OpenAPI spec', 'document an API', 'design a REST API', and 'API spec'.

Consider leading with a short third-person action clause (e.g. 'Reviews and improves OpenAPI 3.x contracts') before the 'Use when' trigger to strengthen the what-statement voice.

DimensionReasoningScore

Specificity

The description enumerates many concrete capability areas ('spec structure, metadata and versioning, paths and operations, reusable schemas, security schemes, examples, documentation quality, contract validation (e.g. Spectral), breaking-change awareness, and handoffs to codegen'), matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

It explicitly answers both what (the enumerated capability areas) and when ('Use when you need framework-agnostic OpenAPI 3.x guidance' and 'This should trigger for requests such as'), matching the explicit-trigger anchor for 3.

3 / 3

Trigger Term Quality

It gives natural triggers ('Review an OpenAPI; Improve an OpenAPI; Improve API contract; Improve API schema design') but misses common variations users would say such as 'Swagger', 'validate', 'document an API', 'REST API', or 'design an API', so it is not the comprehensive coverage of a 3.

2 / 3

Distinctiveness Conflict Risk

The 'framework-agnostic' framing and the explicit exclusion 'without choosing Spring Boot, Quarkus, or Micronaut' carve a clear niche unlikely to fire for framework-specific skills.

3 / 3

Total

11

/

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
jabrena/cursor-rules-java
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.