Awesome-omni-skill API Versioning
Design and manage API versioning strategies for backward-compatible evolution
install
source · Clone the upstream repo
git clone https://github.com/diegosouzapw/awesome-omni-skill
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/backend/api-versioning-cdalsoniii" ~/.claude/skills/diegosouzapw-awesome-omni-skill-api-versioning && rm -rf "$T"
manifest:
skills/backend/api-versioning-cdalsoniii/SKILL.mdsource content
API Versioning Skill
Design and manage API versioning strategies for backward-compatible evolution.
Trigger Conditions
- Breaking API change is proposed
- New API endpoint is created
- User invokes with "version API" or "API deprecation plan"
Input Contract
- Required: Current API spec and proposed change
- Required: Consumer list (who calls this endpoint)
- Optional: Sunset timeline, migration support level
Output Contract
- Versioning recommendation (strategy + implementation)
- Breaking change analysis with consumer impact
- Migration guide for consumers
- Deprecation timeline with Sunset headers
Tool Permissions
- Read: API specs, route definitions, consumer registry
- Write: API specs, migration guides, deprecation notices
- Search: Codebase for endpoint usage
Execution Steps
- Analyze proposed change for breaking vs. non-breaking
- If breaking: determine versioning strategy (URL path, header, content negotiation)
- Assess consumer impact using consumer registry
- Draft migration guide for affected consumers
- Configure Sunset and Warning headers on deprecated endpoints
- Set deprecation timeline (minimum 3 months)
- Create monitoring for deprecated endpoint usage
Success Criteria
- Breaking changes identified and versioned correctly
- All affected consumers notified with migration guide
- Sunset headers configured on deprecated endpoints
- Monitoring in place to track deprecated endpoint usage
Escalation Rules
- Escalate if >10 consumers are affected by breaking change
- Escalate if deprecation timeline conflicts with consumer contracts
- Escalate if no versioning strategy exists yet
Example Invocations
Input: "We need to change the /users response from {name: string} to {first_name: string, last_name: string}"
Output: Breaking change: field removal (name) + field addition (first_name, last_name). Strategy: v2 endpoint at /api/v2/users. v1 maintained with computed 'name' field for 6 months. Migration guide: update client SDK, map first_name+last_name. Sunset header on v1: 2026-08-01. Monitor v1 usage weekly.