Master REST and GraphQL API design principles to build intuitive, scalable, and maintainable APIs that delight developers and stand the test of time.
42
28%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/antigravity-api-design-principles/SKILL.mdQuality
Discovery
22%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description reads more like a marketing tagline or course title than a functional skill description. It lacks concrete actions, explicit trigger conditions, and uses aspirational fluff ('delight developers', 'stand the test of time') instead of specifying what the skill actually does. The mention of REST and GraphQL provides some keyword value but is insufficient to make this a useful skill selector.
Suggestions
Replace aspirational language with concrete actions, e.g., 'Designs REST endpoints, defines GraphQL schemas, structures request/response payloads, applies versioning strategies, and generates OpenAPI/Swagger specifications.'
Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks about API design, REST endpoints, GraphQL schemas, HTTP methods, API versioning, or OpenAPI specs.'
Remove marketing fluff like 'delight developers' and 'stand the test of time' — these add no selection value and reduce clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, aspirational language like 'intuitive, scalable, and maintainable' and 'delight developers' without listing any concrete actions. There are no specific capabilities such as 'design endpoints', 'define schemas', 'generate OpenAPI specs', etc. | 1 / 3 |
Completeness | The description vaguely addresses 'what' (API design principles) but provides no 'when' clause or explicit trigger guidance. There is no 'Use when...' or equivalent, which per the rubric should cap completeness at 2, and the 'what' itself is too vague to merit even a 2. | 1 / 3 |
Trigger Term Quality | It includes some relevant keywords like 'REST', 'GraphQL', and 'API design' that users might naturally say. However, it misses common variations like 'endpoints', 'routes', 'schema', 'OpenAPI', 'swagger', 'HTTP methods', or 'API documentation'. | 2 / 3 |
Distinctiveness Conflict Risk | Mentioning both REST and GraphQL provides some specificity, but the broad framing around 'API design principles' could overlap with skills related to backend development, web services, or general software architecture. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a thin wrapper that defers all substantive content to an external playbook file. The body provides only vague, abstract instructions with no concrete examples, code snippets, API design patterns, or specific guidance. While the structure is reasonable and concise, the lack of actionable content in the skill itself makes it minimally useful without the referenced resource.
Suggestions
Add concrete, actionable content directly in the SKILL.md — e.g., example REST resource naming conventions, a sample endpoint design, or a GraphQL schema snippet that demonstrates key principles.
Include at least one worked example showing input (requirements) → output (API design) to make the skill self-contained enough to be useful.
Expand the 4-step workflow with specific sub-steps, validation criteria, and concrete outputs expected at each stage (e.g., 'Step 1 output: a consumer matrix listing each client, their primary use cases, and latency/payload constraints').
Remove or significantly trim the 'Use this skill when' / 'Do not use this skill when' sections, which consume tokens without adding actionable guidance.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Use this skill when' and 'Do not use this skill when' sections add moderate bloat without providing actionable value to Claude. The core instructions are lean (4 steps), but the surrounding context is padding that Claude doesn't need. | 2 / 3 |
Actionability | The instructions are extremely vague — 'Define consumers, use cases, and constraints' and 'Choose API style and model resources or types' are abstract directions with no concrete examples, code snippets, schemas, or specific guidance. Everything actionable is deferred to an external file. | 1 / 3 |
Workflow Clarity | There is a 4-step sequence that provides a logical ordering, but it lacks any validation checkpoints, feedback loops, or concrete details about what each step produces. Step 4 mentions 'validate with examples' but doesn't specify how. | 2 / 3 |
Progressive Disclosure | The skill references an external playbook file which is good progressive disclosure, but the SKILL.md itself contains almost no substantive content — it's essentially just a pointer. The overview should contain enough actionable content to be useful on its own before deferring to the external resource. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
636b862
Table of Contents
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.