All skills
vercel avatar

/major-version-mode

@e23d0b5 official
by vercelvercel/ai27k stars
5,232

Context for working on the next AI SDK major release. Only use when explicitly invoked by the user (e.g. via '/major-version-mode'). Do NOT trigger autonomously based on task content.

Use this Skill: https://skilld.dev/gh/vercel/ai/major-version-mode

This session only. Nothing lands on disk.

SKILL.md

≈51 tokens always: the name and description. ≈737 when used: this file.

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):

  1. 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.
  2. 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.
  3. 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

Source: SKILL.md on GitHub

No alerts4mo3 checks · Risk SAFE
  • Gen Agent Trust Hub4mo

    The skill is safe. It provides development guidelines for the next major release of the AI SDK, focusing on handling breaking changes and documentation updates without introducing security considerations.

  • Socket4mo

    No alerts

  • Snyk4mo

    Risk: LOW · No issues

Signed by skilld at e23d0b5. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 14 hours ago.

Activeupdated 5 months ago
metadata
{
  "internal": true
}
  • TypeScript
  • vercel-ai
  • major-version
  • breaking-changes
  • migration
  • deprecation
  • sdk

README badge

README badge for vercel/ai/major-version-mode

This skill provides context for working on the next major release of the Vercel AI SDK, with guidelines for managing breaking changes, deprecated aliases, and spec modifications. It's meant to be invoked explicitly (e.g. `/major-version-mode`) and includes rules for renaming exports, modifying message types, and updating provider specs while minimizing disruption to downstream consumers.

Generated from the current SKILL.md.

When should I use this skill?
Only when explicitly invoked by the user (e.g. via '/major-version-mode'). Do not trigger it based on task content alone.
Should I provide deprecated aliases for renamed exports?
Yes, where feasible — provide deprecated aliases as package-level exports to ease the transition. Skip them only if they introduce meaningful technical debt, and check with the user first before making a clean break.
How do I handle breaking changes to message types in @ai-sdk/provider-utils?
Mark deprecated types with @deprecated JSDoc comments in provider-utils and retain old shapes in the consumer-facing Zod schemas in packages/ai/src/prompt/content-part.ts so existing code continues to compile with a warning. Include a note about removal in the following major version.
Can I make breaking changes to the provider spec without backward compatibility measures?
Yes — clean breaks are preferred in the provider package because the audience is smaller (provider implementers, not SDK consumers). Only modify the latest spec version and never touch older versioned spec interfaces.
What documentation updates are required after implementing changes?
Update relevant docs in content/docs/ and add a migration section to the highest-numbered migration guide in content/docs/08-migration-guides/ explaining what changed and how to migrate.

Generated from the current SKILL.md. These answers refresh after source changes.