api-compatibility

Aligns backend handlers, frontend clients, and schemas when API contracts change.

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/vovanostm-public/multica --skill api-compatibility-vovanostm-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-compatibility
Source: https://github.com/vovanostm-public/multica/tree/main/workflow-bundles/multica-specops-v5/codex_skills/.agents/skills/api-compatibility
Command: npx skills add https://github.com/vovanostm-public/multica --skill api-compatibility-vovanostm-public

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When backend responses, endpoint contracts, or database schemas change, frontend consumers and type definitions often drift out of sync, causing runtime errors and broken UI states. This Skill keeps backend handlers, generated DB types, frontend API clients, and Zod/TS schemas aligned through a structured compatibility procedure. ## Core Features & Use Cases - Contract Change Planning: Identifies endpoints and consumers, then defines request/response shapes and error semantics before implementation. - Cross-Layer Synchronization: Updates backend types, handlers, and stores alongside frontend API clients, schemas, and hooks in one coordinated pass. - Compatibility Testing: Adds tests for malformed or missing fields and enforces decision rules for nullable fields, breaking changes, and error contracts. - Use Case: A backend adds a nullable field to an endpoint response. The Skill ensures the frontend schema handles absent/null values, regenerates SQL types via make sqlc, and produces typed compatibility notes with evidence. ## Quick Start Use the api-compatibility skill to plan and apply the contract changes for the updated endpoint, keeping the backend handler, frontend client, and schemas in sync.

Frequently Asked Questions about api-compatibility

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep frontend and backend API types in sync?▼

Define the request/response shape and error semantics first, then update backend types and handlers together with the frontend API client, Zod/TS schemas, and hooks in one pass. Add compatibility tests for malformed or missing fields to catch drift early.

How to handle a breaking API change in a full-stack app?▼

A breaking change requires a versioning or compatibility plan plus a migration path. Document the contract change, update all consumers, and produce typed compatibility notes recording evidence, assumptions, and blockers.

What should the frontend do when the backend adds a nullable field?▼

The frontend schema must handle both absent and null values for the new field. Update the Zod/TS schema to mark it optional or nullable and verify UI components render correctly when the field is missing.

When should I regenerate SQL types after a schema migration?▼

Regenerate types whenever generated SQL types change, using make sqlc, then update the adapters that consume them. This keeps database-layer types consistent with backend handlers and downstream API responses.

What are the limits of this API compatibility workflow?▼

It operates only within the assigned stage and worktree, does not perform unrelated stages, and cannot execute privileged actions directly. It also requires prior evidence gathering and will not repeat context collection done by earlier stages.