propagate-api-contract-changes

Trace backend API contract changes through every affected frontend layer.

1|Updated May 15, 2026
One-click install
npx skills add https://github.com/c2kaka/fancy-skills --skill propagate-api-contract-changes-c2kaka
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: propagate-api-contract-changes
Source: https://github.com/c2kaka/fancy-skills/tree/main/skills/propagate-api-contract-changes
Command: npx skills add https://github.com/c2kaka/fancy-skills --skill propagate-api-contract-changes-c2kaka

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Backend API, OpenAPI, or JSON Schema changes often leave stale types, mappers, form state, fixtures, and tests scattered across the frontend. This Skill systematically traces a contract change through the full frontend data flow so nothing is silently left behind. ## Core Features & Use Cases - Semantic Delta Modeling: Classifies each contract change as breaking, additive, or ambiguous across transport, request, response, and behavior dimensions. - Impact Matrix: Traces symbols, imports, and runtime data flow through clients, mappers, state, forms, UI, fixtures, and tests before any code is edited. - Compatibility Strategy & Verification: Selects atomic migration, dual-read/write, or versioned adapters, then verifies with static checks, boundary tests, and runtime evidence. - Use Case: When the backend renames a response field or changes an enum, use this Skill to update the generated client, boundary mapper, form hydration, UI labels, and tests, then confirm no stale consumers remain. ## Quick Start Use the propagate-api-contract-changes skill to apply this backend contract change across the frontend and verify every affected layer.

Frequently Asked Questions about propagate-api-contract-changes

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

FAQPage Schema
How do I sync frontend code with a changed backend API?▼

Model the semantic contract delta first, then trace impact through generated clients, transport, mappers, state, forms, UI, and tests. Implement from the boundary inward and verify with type checks, boundary tests, and runtime request/response inspection.

How to handle breaking API changes in a frontend application?▼

Classify each change as breaking, additive, or ambiguous, then choose an explicit compatibility strategy: atomic migration, temporary dual-read/dual-write, a versioned adapter, or hard failure. Document removal conditions for any temporary compatibility code.

Should I edit generated OpenAPI client files directly?▼

No. Generated clients and schemas should be regenerated from their source generator, not hand-edited. Hand edits are overwritten on regeneration and hide the true contract authority.

Can I use a sample API response to define the frontend schema?▼

No. A single sample payload does not define requiredness, nullability, or defaults. Prefer machine-readable sources like OpenAPI or JSON Schema, then versioned backend definitions, documentation, and captured real traffic.

Why does search-and-replace fail for API field renames?▼

A field rename often changes meaning, source, defaults, or lifecycle, not just text. Blind replacement misses runtime mapping, stale enum consumers, and persisted drafts, so the change must be traced through the actual data flow.