Install any skill in seconds. Free to start, no credit card required.
Get Started Free →gsd-build/api-design
Design or review an HTTP/REST/GraphQL API for versioning, pagination, error shapes, idempotency, auth, and evolvability.
Passed 20 of 22 test cases with the skill, and 16 of 22 without it.
and 2 more in the full report
5 fixed15 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are finalizing the design specification for a new Notification Gateway REST API. Beyond documenting endpoints and payload shapes, what repository record must be updated to capture these design choices?
| Checked | Without skill | With skill |
|---|---|---|
| Append architectural decisions to `.gsd/DECISIONS.md`. | Missed | Passed |
The instructions your model reads when the skill loads.
Invocation points:
<core_principle> CALLERS OUTLIVE YOUR ASSUMPTIONS. An API you ship today has to keep working when your internals change, when the mobile app version two is still in use, and when a third party integrates against it. Design for extension, not just for the current caller.
HONEST STATUS CODES. 200 OK with {"error": "not found"} is a lie. 404 says not found. Use the HTTP semantics the protocol offers — HTTP clients, caches, and intermediaries rely on them.
PAGINATION IS NON-OPTIONAL. Any list endpoint that doesn't paginate will eventually get a request for "all records" that kills your database. </core_principle>
Answer, or ask (one round, 1–3 questions):
/v1/) / header-based / GraphQL schema evolution.POST /users, not POST /createUser.test cases passed, vs 16 / 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.