/api-breaking

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select api-breaking from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv api-breaking, /just-vibe api-breaking and /jv:api-breaking in Claude. See shortcut setup and context examples.

What the agent does

1. Identify affected consumers, then diff the versions: field presence and types, enum values, validation, defaults, error/status behavior, pagination and timing guarantees.
2. Classify compatibility impact per consumer and propose rollout and deprecation steps.

Inputs

• old/new contracts or revisions, consumer expectations, and compatibility policy.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Backward compatibility across schemas, semantics, authentication, errors, and timing/order guarantees.

Writes

No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.

Mode

Inspect; old/new contracts or revisions, consumer expectations, and compatibility policy.

Prerequisites

Interface definitions, producer/consumer source, authentication model, versioning constraints, and isolated test endpoints. External API calls must respect environment, credentials, rate limits, and side-effect scope.

Expected output

• Change/consumer/impact matrix with examples, compatibility bridges or migration options, and unknown consumers.

How the work is checked

• Narrowed validation is recognized as potentially breaking; an additive field is evaluated against actual strict-client behavior.

When to stop or clarify

• Missing consumer information prevents universal compatibility claims. Do not equate schema compatibility with semantic compatibility.

Handling missing context

Infer

Read producer/consumer schemas, error contracts, auth conventions and known supported client versions.

Assume

Keep compatible response and pagination semantics where the brief does not request a breaking change.

Ask

Ask when contract sources disagree or an unknown consumer changes compatibility; do not require live credentials to write or test an isolated client.

Technical guidance

Evidence

Compare old/new payloads, enums, validation, errors, pagination and authentication using known consumers.

Method

Classify wire, semantic and operational compatibility separately; propose a migration when old clients cannot interpret the new result.

Pitfall

An additive enum value or new required permission can break clients even without deleting a field.

Check

Run old consumer fixtures against the proposed provider and identify a deployment sequence that preserves supported versions.

Situational decisions

When a syntactically additive change affects strict decoders or behavior: Classify its actual consumer impact and propose rollout/deprecation evidence.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring