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.
45
45%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
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 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 |
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 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 |
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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents