Name: jbvc/api-testing-observability-api-mock
Rating: 34.4 (1 reviews)
Author: jbvc

jbvc/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

43%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Advisory

Suggest reviewing before use

Quality

Content

35%

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

This skill content reads more like a high-level role description than an actionable skill. It lacks any concrete code examples, specific tool recommendations, or executable commands that would enable Claude to immediately create mock APIs. The workflow is loosely sequenced but missing validation steps and the content relies heavily on an external playbook without providing enough substance in the main file.

Suggestions

Add at least one concrete, executable code example showing a basic mock server setup (e.g., using msw, json-server, or Express) to dramatically improve actionability.

Include a specific validation step in the workflow, such as verifying mock responses against an OpenAPI spec or running a contract test.

Remove the 'Context' section which restates the description, and trim 'Use this skill when' / 'Do not use this skill when' to reduce verbosity.

Provide a brief summary of what's in `resources/implementation-playbook.md` (e.g., list the templates/checklists available) so Claude knows when and why to open it.

Dimension	Reasoning	Score
Conciseness	The skill includes some unnecessary sections like 'Use this skill when' / 'Do not use this skill when' which are somewhat verbose and explain things Claude could infer. The 'Context' section restates the description. However, it's not egregiously padded.	2 / 3
Actionability	The skill provides no concrete code, commands, or executable examples. Instructions are abstract directives like 'Clarify the API contract' and 'Define mock routes' without any specific implementation, tool usage, or copy-paste ready guidance.	1 / 3
Workflow Clarity	The instructions section provides a rough sequence of steps (clarify contract → define routes → provide fixtures → document), but lacks explicit validation checkpoints, error recovery steps, or concrete verification of mock correctness.	2 / 3
Progressive Disclosure	There is a reference to `resources/implementation-playbook.md` for detailed implementation, which is good one-level-deep disclosure. However, the main file itself lacks a quick-start or concrete overview, and the reference is mentioned twice (in instructions and resources) without clear signaling of what's inside.	2 / 3
	Total	7 / 12 Passed

Description

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 as a persona prompt ('You are an expert') rather than a functional skill description, which is a fundamental framing issue. It lacks concrete actions, explicit trigger conditions, and uses vague language about what the skill actually does. The API mocking domain provides some natural distinctiveness, but the description needs significant improvement in specificity and completeness.

Suggestions

Replace the persona framing ('You are an expert') with third-person capability statements listing concrete actions, e.g., 'Generates mock API endpoints, creates response fixtures, simulates error scenarios and latency, and produces OpenAPI-compatible stub servers.'

Add an explicit 'Use when...' clause with natural trigger terms, e.g., 'Use when the user asks about mocking APIs, creating stub endpoints, fake servers, test doubles, API simulation, or needs mock data for development/testing.'

Include specific file formats, tools, or technologies to improve distinctiveness, e.g., 'Supports WireMock, MSW, Prism, and generates mock configurations from OpenAPI/Swagger specs.'

Dimension	Reasoning	Score
Specificity	The description uses vague language like 'design mocks that simulate real API behavior' and 'enable parallel development' without listing concrete actions. No specific operations (e.g., 'generate mock endpoints', 'create response fixtures', 'simulate error codes') are mentioned.	1 / 3
Completeness	The 'what' is vaguely described (design mocks) and there is no explicit 'when' clause or trigger guidance. The description reads more like a persona definition ('You are an expert') than a skill description, and lacks any 'Use when...' guidance.	1 / 3
Trigger Term Quality	Includes some relevant terms like 'API mocking', 'mock services', 'development', 'testing', and 'demos', but misses common user phrases like 'stub API', 'fake endpoint', 'mock server', 'test doubles', or specific tool names users might mention.	2 / 3
Distinctiveness Conflict Risk	The focus on 'API mocking' provides some distinctiveness, but the broad mention of 'development, testing, and demos' could overlap with general testing skills, API development skills, or demo preparation skills.	2 / 3
	Total	6 / 12 Passed

Validation

100%

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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Reviewed

3 months ago

Table of Contents

Discovery Implementation Validation