How do I install the API Versioning skill?

Run npx skillmds@latest add diegosouzapw/api-versioning-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the API Versioning skill do?

Design and manage API versioning strategies for backward-compatible evolution It is listed under Integrations & APIs on SkillMD.

Is API Versioning safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with API Versioning?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is API Versioning free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published API Versioning?

diegosouzapw (@diegosouzapw) published this skill. Their other Agent Skills are listed on their SkillMD profile.

API Versioning by diegosouzapw — Agent Skill

Name: API Versioning
Rating: 4.2 (5 reviews)
Author: diegosouzapw

File contents

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.

---name: api-versioning-2description: Design and manage API versioning strategies for backward-compatible evolution--- # 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 1. Analyze proposed change for breaking vs. non-breaking 2. If breaking: determine versioning strategy (URL path, header, content negotiation) 3. Assess consumer impact using consumer registry 4. Draft migration guide for affected consumers 5. Configure Sunset and Warning headers on deprecated endpoints 6. Set deprecation timeline (minimum 3 months) 7. 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.

Frequently asked questions

API Versioning