Does the skill trigger on its own based on task content?

No. It is only used when explicitly invoked by the user, for example through the /major-version-mode command. It does not trigger autonomously based on task content.

Are breaking changes allowed?

Yes. The task is part of the next AI SDK major release, so breaking changes are acceptable. The skill still encourages minimizing disruption for third party consumers through deprecated aliases and migration logic.

major-version-mode

SkillCloud & infra

This skill gives an AI agent the context it needs to work on the next AI SDK major release, where breaking changes are allowed. It tells the agent how to handle renamed exports, modified message types, and provider spec changes, and it updates docs and the migration guide afterward. It is only used when the user explicitly invokes it, such as through a slash command, and it does not trigger on its own from task content.

Connect your AI Use it in a pipeline

Then ask your AI: use the major-version-mode skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.

No other account needed.

Have the AI SDK repository checked out and available to the agent.

What your AI can do with it

Adds deprecated aliases for renamed or changed exports where feasible
Keeps old message shapes in consumer-facing Zod schemas with deprecation notes
Leaves older versioned provider spec interfaces untouched
Asks the user before making a clean break instead of a deprecation
Updates documentation in content/docs after implementing changes
Adds a section to the latest migration guide when consumers must migrate

Getting started

Have the AI SDK repository checked out and available to the agent.
Make sure the agent can read and edit the packages and content/docs directories.
Invoke the skill explicitly, for example with the /major-version-mode command.
Describe the breaking change you want made in the next major release.
Answer the agent's questions when it asks which spec version to use or whether a clean break is acceptable.

What this skill tells your AI

The instructions your AI receives, as published by vercel/ai in skills/major-version-mode/SKILL.md and read by Ahel’s review.

Context

This task is part of the next AI SDK major release. Breaking changes are acceptable.

Breaking Change Guidelines

While breaking changes are acceptable, it is still encouraged to minimize unnecessary disruption for 3P consumers of the AI SDK. Providing deprecated aliases and automated migration logic can help ease the transition.

Renamed/changed exports

If renaming or modifying an exported function or type, provide a deprecated alias as a package-level export where feasible:

/** @deprecated Use `newFunctionName` instead. */
export { newFunctionName as oldFunctionName } from './new-module';

Only do this if it doesn't introduce meaningful technical debt. If it does, skip the alias — but check with the user first before making a clean break.

Modified message types (e.g. in `@ai-sdk/provider-utils`)

If modifying model message shapes (e.g. content part types in packages/provider-utils/src/types/content-part.ts):

Deprecate in @ai-sdk/provider-utils rather than removing immediately, if feasible. Mark deprecated types/members with a @deprecated JSDoc comment and a TODO note to remove in the following major version.
Keep deprecated equivalents in packages/ai/src/prompt/content-part.ts — this file is the consumer-facing layer and should retain the old shapes in the Zod schemas so existing consumer code continues to compile with a deprecation warning. Include a similar note about deprecation and removal in the following major version.
If clean deprecation isn't feasible without meaningful technical debt, a hard removal may be preferred — but check with the user first.

Provider spec changes (`@ai-sdk/provider`)

The provider package defines the spec that provider implementers code against. It should generally not be modified outside of major versions, so keeping the spec clean and consistent is critical.

Breaking changes without maintaining temporary backward compatibility measures are more acceptable here than elsewhere, because the audience is smaller — far fewer developers implement their own providers than build features on top of the AI SDK.

Rules:

Only modify the latest spec version. Older versioned spec interfaces must remain completely untouched.
Deprecated aliases are not required — a clean break is preferred to preserve spec clarity.
The current spec version is not the same as the current AI SDK major version number. If it's unclear which spec version to operate on, ask the user before proceeding.

Documentation

After implementing changes, update relevant documentation in content/docs/.

If the change requires consumers to update their code or migrate stored data, add a section to the latest migration guide:

Find the migration guide with the highest version number in content/docs/08-migration-guides/
Add a concise section explaining what changed and how to migrate

Signals

GitHub stars: 27k
Forks: 5k
Last commit: Oct 2026

Others that do the same job

major-version-mode
Skill · akarachen

Questions

Does the skill trigger on its own based on task content?: No. It is only used when explicitly invoked by the user, for example through the /major-version-mode command. It does not trigger autonomously based on task content.
Are breaking changes allowed?: Yes. The task is part of the next AI SDK major release, so breaking changes are acceptable. The skill still encourages minimizing disruption for third party consumers through deprecated aliases and migration logic.

Advanced

Item type: skill
Key: major-version-mode-vercel
Source: github.com/vercel/ai

github.com/vercel/ai