Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mohitagw15856/api-versioning-strategy
Write an API versioning strategy document for a service or API platform.
Passed 19 of 23 test cases with the skill, and 16 of 23 without it.
and 4 more in the full report
5 fixed14 passed either way2 still failing2 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.
At T-7 days before an API version sunset, what traffic threshold triggers direct manual escalation to the client team's engineering manager?
| Checked | Without skill | With skill |
|---|---|---|
| Sets the direct escalation threshold at traffic exceeding 100 requests per day | Missed | Passed |
The instructions your model reads when the skill loads.
Produce a complete API versioning strategy document that gives a service team durable, consistent rules for evolving their API without breaking consumers. This document covers the versioning scheme selection (with rationale), lifecycle policy from introduction through sunset, a precise breaking-change classification, and all the communication artifacts a team needs when deprecating a version. Engineers should be able to hand this document to a new team member or external consumer and have them understand exactly what to expect.
Ask for these if not already provided:
/v1/), request header, query parameter, or none; if none, document starts freshIf any input is missing, ask before producing the document. For GraphQL, note that the versioning approach differs substantially (schema evolution over versioning) and tailor the scheme section accordingly.
Owner: [Team Name] API Type: [REST / GraphQL / gRPC] Document Version: 1.0 Last Reviewed: [Date] Next Review: [Date + 6 months]
| Scheme | Example | Pros | Cons | Verdict |
|---|---|---|---|---|
| URL Path | /v2/orders | Visible in logs and bookmarks; trivial to route | Violates strict REST resource identity; clutters URL space | Recommended for public-facing REST APIs |
Accept Header | Accept: application/vnd.[service].v2+json | Keeps URLs clean; proper content negotiation | Harder to test in browser; less visible in logs | Recommended for internal APIs with controlled clients |
| Query Parameter | /orders?version=2 | Easy to retrofit without URL restructuring | Often missed in client code; cache-key complications | Acceptable only for read-heavy APIs already in production |
| GraphQL Schema Evolution | Field deprecation + @deprecated directive | No versioning needed for additive changes | Requires disciplined schema design | Recommended for GraphQL APIs |
test cases passed, vs 16 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.