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

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

50%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is well-organized and free of unnecessary concept explanations, but it offers only moderately actionable guidance, lacks explicit validation checkpoints, and points to a resources file that is absent from the bundle.

Suggestions

Add concrete, executable examples — a sample mock-server run command, a minimal fixture JSON shape, and a route/scenario snippet — to make the Instructions copy-paste ready.

Sequence the Instructions as an explicit numbered workflow with a validation checkpoint (e.g., verify the mock satisfies the contract before documenting how to run it).

Either create `resources/implementation-playbook.md` with the promised code samples, checklists, and templates, or remove the reference to it; a dangling reference breaks progressive disclosure.

Dimension	Reasoning	Score
Conciseness	The body is lean and avoids explaining concepts Claude already knows, but the opening paragraph and the 'Context' section repeat the description and each other ('create mock APIs for development, testing, or demonstration purposes... realistic mocks that accurately simulate production API behavior').	2 / 3
Actionability	Instructions give concrete, specific guidance ('Clarify the API contract, auth flows, error shapes, and latency expectations'; 'Provide deterministic fixtures with optional randomness toggles') but provide no executable examples, fixture formats, or run commands.	2 / 3
Workflow Clarity	The Instructions imply a sequence (clarify contract -> define routes -> provide fixtures -> document running) but there are no explicit numbered steps or validation checkpoints; only a soft 'Stop and ask for clarification' guard in Limitations.	2 / 3
Progressive Disclosure	The SKILL.md is a clean overview that defers detail to a one-level-deep reference, but the referenced `resources/implementation-playbook.md` does not exist in the bundle, so navigation to the detailed material is broken.	2 / 3
	Total	8 / 12 Passed

Description

40%

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 clearly conveys the API-mocking niche and what the skill produces, but it is written in second person and omits a 'Use when...' trigger clause, capping completeness and specificity. Adding explicit trigger phrasing and third-person voice would materially improve it.

Suggestions

Rewrite in third person and add an explicit 'Use when...' clause (e.g., 'Use when the user needs mock APIs, fake or stub services, or demo backends for frontend or integration testing') to raise specificity and completeness.

Add common trigger variations users would naturally say — 'mock server', 'fake API', 'stub API', 'test fixtures' — to improve trigger term coverage.

Sharpen the action list with concrete verbs (e.g., 'Generate mock routes, fixtures, and scenario state machines; document how to run and switch scenarios') rather than abstract outcomes like 'enable parallel development'.

Dimension	Reasoning	Score
Specificity	Names the API-mocking domain and a few actions ('Design mocks that simulate real API behavior and enable parallel development'), but uses second-person voice ('You are an API mocking expert', 'Design mocks'), which per the rubric reduces the specificity score by one; a base level of 2 becomes 1.	1 / 3
Completeness	Clearly states what the skill does but contains no 'Use when...' trigger guidance, so per the rubric completeness is capped at 2.	2 / 3
Trigger Term Quality	Includes relevant natural terms ('API mocking', 'mock services', 'mocks', 'development, testing, and demos') but omits common variations users would say such as 'fake/stub API', 'mock server', or 'fixtures'.	2 / 3
Distinctiveness Conflict Risk	The 'API mocking / mock services' niche is fairly specific but, without explicit triggers, could still overlap with general API-testing or test-fixture skills.	2 / 3
	Total	7 / 12 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
Commit: 9fc5f98

Reviewed: about 17 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.