mocking-apis
Generate mock API servers for testing and development with realistic response data. Use when creating mock APIs for development and testing. Trigger with phrases like "create mock API", "generate API mock", or "setup mock server".
71
66%
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 ./plugins/api-development/api-mock-server/skills/mocking-apis/SKILL.mdQuality
Discovery
89%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 is a solid description with explicit trigger guidance and a clear 'Use when' clause, making it strong on completeness and distinctiveness. Its main weakness is that the capability description is somewhat general—it could benefit from listing more specific actions beyond just 'generate mock API servers with realistic response data' to better convey the full range of what the skill does.
Suggestions
Add more specific concrete actions, e.g., 'Define endpoints with custom routes, configure HTTP status codes, generate realistic JSON/XML response payloads, simulate latency and error conditions.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (mock API servers) and a general action (generate mock servers with realistic response data), but doesn't list multiple specific concrete actions like defining endpoints, setting response codes, configuring latency, generating sample payloads, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (generate mock API servers with realistic response data for testing/development) and 'when' (explicit 'Use when' clause and 'Trigger with phrases' providing concrete trigger guidance). | 3 / 3 |
Trigger Term Quality | Includes good natural trigger terms: 'create mock API', 'generate API mock', 'setup mock server', plus 'testing', 'development', and 'mock API servers'. These cover common phrases a user would naturally say. | 3 / 3 |
Distinctiveness Conflict Risk | The focus on mock API servers is a clear niche. Terms like 'mock API', 'mock server', and 'API mock' are distinct and unlikely to conflict with general API development, testing frameworks, or other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is well-organized with good progressive disclosure and a clear output structure, but critically lacks actionable, executable content. The instructions read as a high-level design document rather than concrete guidance Claude can follow—no code snippets, no CLI commands, no configuration examples. The heavy reliance on referenced files for actual implementation means the SKILL.md itself provides little executable value.
Suggestions
Add concrete, executable code examples for at least the core steps—e.g., a minimal Prism startup command (`npx prism mock openapi.yaml -p 4010`), a sample Faker.js generator function, and a sample fixture JSON file.
Include validation checkpoints in the workflow, such as 'Verify mock server responds correctly: `curl http://localhost:4010/users` should return fixture data matching the schema' after the server launch step.
Replace the abstract example descriptions with concrete input/output pairs—show an actual OpenAPI snippet and the corresponding generated fixture or mock server configuration.
Trim the overview to remove restated information and reduce the prerequisites list to only what's essential (e.g., Claude already knows what Docker is and what Faker.js does).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured but includes some unnecessary verbosity, particularly in the overview section which restates what Claude would already understand. The examples section describes use cases at a high level rather than providing concrete code, adding length without proportional value. | 2 / 3 |
Actionability | Despite listing 8 steps, the instructions are entirely abstract and descriptive—there is no executable code, no concrete commands, no copy-paste ready snippets. Steps like 'Configure the mock server to match requests' and 'Add stateful behavior for CRUD operations' describe what to do without showing how. The actual implementation is deferred to a reference file. | 1 / 3 |
Workflow Clarity | The steps are sequenced logically and numbered, but there are no validation checkpoints or feedback loops. For a workflow that involves generating fixtures from specs and launching servers, there should be explicit verification steps (e.g., validate fixtures against schema, test that server responds correctly before proceeding). | 2 / 3 |
Progressive Disclosure | The skill effectively uses progressive disclosure with clear references to implementation.md, errors.md, and examples.md—all one level deep and well-signaled. The main file serves as an overview with output structure, error table, and examples, while deferring detailed content appropriately. | 3 / 3 |
Total | 8 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Commit
70e9fa4
- Reviewed
Table of Contents
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.