api-testing-observability-api-mock

You are an API mocking expert specializing in realistic mock services for development, testing, and demos. Design mocks that simulate real API behavior and enable parallel development.

Quality

55%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/api-testing-observability-api-mock/SKILL.md

Quality

Content

53%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 well-structured with clear use/anti-use guidance and a sensible workflow, but it repeats the description twice, defers all executable detail to an external playbook that is absent, and omits validation checkpoints. Tightening the redundancy and adding verification steps would raise the lowest dimensions.

Suggestions

Remove the redundant restatement in the opening paragraph and the 'Context' section since the frontmatter description already conveys this, tightening conciseness.

Add explicit validation checkpoints to the workflow (e.g., verify generated mocks against the API contract; test each scenario before documenting), which is currently capped by implicit-only validation.

Either include the referenced 'resources/implementation-playbook.md' as a real bundle file or inline minimal runnable examples so the body is actionable without a dangling reference.

Dimension	Reasoning	Score
Conciseness	The opening paragraph near-duplicates the frontmatter description and the 'Context' section restates the same idea a third time, but no basic concepts are over-explained, fitting 'mostly efficient but could be tightened'.	3 / 5
Actionability	The Instructions give specific directives (clarify contract/auth/error shapes, define routes and state transitions, deterministic fixtures) but defer all executable detail — code, frameworks, commands — to an external file, leaving the body itself incomplete.	3 / 5
Workflow Clarity	A logical sequence is present (clarify → define routes/scenarios → fixtures → document running → open playbook), but there are no explicit validation checkpoints such as verifying the mock against the contract or testing scenarios.	3 / 5
Progressive Disclosure	Sections are well-organized and the single external reference is clearly signaled in two places and kept one level deep, but the referenced 'resources/implementation-playbook.md' does not exist on disk, a minor organization gap that keeps it below 5.	4 / 5
	Total	13 / 20 Passed

Description

56%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 names a clear niche and several natural trigger terms, but it is written in second person and lacks an explicit 'Use when...' trigger clause, capping both specificity and completeness. Adding a concrete trigger clause and converting to third-person voice would lift the weakest dimensions.

Suggestions

Add an explicit 'Use when...' clause with concrete triggers (e.g., 'Use when building mock APIs for frontend/integration testing, simulating partner APIs, or creating demo environments') to raise completeness above 3.

Rewrite in third person ('Designs realistic mock services...') instead of second person ('You are an API mocking expert') to recover the specificity penalty.

Include common synonyms users say ('stub', 'fake API', 'mock server') to push trigger-term coverage toward comprehensive.

Dimension	Reasoning	Score
Specificity	Names the API-mocking domain and a couple of actions ('Design mocks that simulate real API behavior and enable parallel development'), but the description is written in second person ('You are an API mocking expert'), which the rubric penalizes by reducing specificity by one from a base of 3.	2 / 5
Completeness	It clearly states the 'what' but offers only a weakly implied 'when' ('for development, testing, and demos') with no explicit 'Use when...' trigger clause, so completeness is capped at 3 per the rubric guidance.	3 / 5
Trigger Term Quality	Covers natural terms users would say — 'mock services', 'mocks', 'API', 'development', 'testing', 'demos' — with only common synonyms like 'stub' or 'fake API' missing, fitting the 'good coverage, a few terms missing' anchor.	4 / 5
Distinctiveness Conflict Risk	'API mocking' / 'mock services' is a clear niche with distinct triggers, with only minor overlap risk against general testing skills, matching the 'mostly distinct' anchor rather than the fully distinct 5.	4 / 5
	Total	13 / 20 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: sickn33/antigravity-awesome-skills
Path: skills/api-testing-observability-api-mock/SKILL.md
Commit: 1f67c44

Reviewed: about 11 hours ago

Table of Contents

Discovery Implementation Validation

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.