Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →zzafergok/api-design-skill
Master REST and GraphQL API design principles to build intuitive, scalable, and maintainable APIs.
Passed 21 of 22 test cases with the skill, and 17 of 22 without it.
and 4 more in the full report
4 fixed17 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
Design a RESTful URL endpoint path to retrieve the list of orders belonging to a specific candidate user identified by ID `user_99`.
| Checked | Without skill | With skill |
|---|---|---|
| The nested resource path follows the pattern /api/users/user_99/orders or /api/users/{id}/orders. | Missed | Passed |
The instructions your model reads when the skill loads.
Design the public contract from consumer needs and domain behavior before choosing route names or framework code.
Identify consumers, trust boundaries, operations, data ownership, consistency needs, latency and availability targets, expected scale, compatibility horizon, and whether synchronous request-response is appropriate.
Inspect existing conventions for naming, authentication, errors, pagination, idempotency, versioning, observability, and documentation. Consistency with a sound existing API is usually more valuable than introducing a second style.
Define filtering, sorting, pagination, maximum page size, and consistency semantics. Prefer cursor pagination when collections change during traversal or offsets become costly.
For mutations, specify idempotency, concurrency control, duplicate handling, validation, partial success, and retry safety. Use idempotency keys for externally retried operations where duplicate effects are harmful.
Prefer additive change when it preserves meaning. For breaking changes, inventory consumers, provide a migration path, run old and new contracts in parallel when justified, observe adoption, and define removal criteria. Version only when the compatibility problem requires it.
Provide or update an inspectable contract such as OpenAPI, GraphQL schema, protobuf, or event schema when appropriate. Test authorization, validation, compatibility, rate limits, pagination boundaries, duplicate requests, timeouts, and malformed consumers. Include examples that match the real contract rather than illustrative fields that cannot be executed.
test cases passed, vs 17 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.