Skip to content
Skillpedia
APIs & servers (backend)40k · #4994

api-breaking-change-detector

Detects breaking changes between C# APIs and their JavaScript/TypeScript consumers. It ensures the backend and frontend stay compatible, preventing errors.

What it does

This agent compares your 'backend' code (where data is created and managed) with your 'frontend' code (the part users see and interact with) to find problems before they cause errors.

When to use it

  • ✓When you change something in your 'backend' and want to know if it will break the 'frontend'.
  • ✓When you want to make sure the 'frontend' and 'backend' are 'speaking the same language'.
  • ✓Before releasing a new version of your program, to check if everything still works together.

Example of what to ask your AI

“Check if my C# controller changes will break the frontend.”

Want more? Open the sections below.

How to use

The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.

Skill link

https://github.com/github/awesome-copilot/blob/main/skills/api-breaking-change-detector/SKILL.md

Ready-to-paste message

Use this skill to help me: https://github.com/github/awesome-copilot/blob/main/skills/api-breaking-change-detector/SKILL.md Read the SKILL.md file at that link and follow its instructions for my task.
How it works

It analyzes how data is sent and received in the 'backend' and looks for corresponding uses in the 'frontend' code. If it finds differences, it warns you.

Installation

Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.

In the terminal (Claude Code, Codex, Cursor), in your project folder:

npx skills add github/awesome-copilot --skill api-breaking-change-detector

Or download just the file:

curl -L https://raw.githubusercontent.com/github/awesome-copilot/main/skills/api-breaking-change-detector/SKILL.md -o SKILL.md
Technical content (original SKILL.md)

Original text by the author, straight from GitHub.

API Breaking Change Detector

You are cross-referencing a C# Web API's actual contract (controllers, DTOs, route definitions) against its TypeScript/JavaScript consumers to find contract drift — in both directions — before it reaches production.

When to use this

Trigger when the user asks to:

  • Check whether a DTO/controller change will break frontend or client applications
  • Verify the client and backend API contract are still in sync
  • Audit a specific endpoint, or the whole API surface, for breaking changes before a release

Do not use this for:

  • Generating new API code from an OpenAPI spec (see openapi-to-application-code)
  • Scaffolding new endpoints with OpenAPI docs (see aspnet-minimal-api-openapi)
  • Comparing two OpenAPI spec files directly — this skill reads source code, not exported specs

Process

  1. Discover Global JSON & Naming Policies:

    • Check Program.cs or Startup.cs for active JSON options (e.g. JsonNamingPolicy.CamelCase, PropertyNamingPolicy, or Newtonsoft CamelCasePropertyNamesContractResolver).
    • Default to camelCase for TypeScript/JavaScript field mapping if global camelCase is configured, unless overridden by an explicit [JsonPropertyName("...")] attribute on the C# property.
    • Ignore C# properties annotated with [JsonIgnore].
  2. Identify the C# contract surface. For each Controller action in scope:

    • Route: Base [Route("...")] + action [HttpGet("...")] / [HttpPost("...")]. Normalize route parameters (e.g. {id:int} or {id:guid} $\rightarrow$ {id}).
    • Request DTO: Extract property names, types, and requirement rules:
      • Required if: annotated with [Required], [BindRequired], has the C# 11 required modifier (public required string X), or is a non-nullable value type (int, Guid, bool) without a default value.
      • Optional if: nullable (string?, int?), or has a default initializer.
    • Response DTO: Property names, types, and nullability.
    • Explicit Status Codes: [ProducesResponseType(statusCode)] attributes and explicit StatusCode(...) return paths.
  3. Find the matching TypeScript/JavaScript consumer (with Normalized URL Matching):

    • Auto-generated client match (high confidence): look for generated client files (NSwag/OpenAPI Generator output) and match by generated method/interface name directly.
    • Hand-written service/client match (medium confidence):
      • Search TypeScript/JavaScript files for HTTP client calls (fetch, axios, Angular HttpClient, ky, etc.) whose normalized URL pattern matches the controller's route.
      • Normalize template strings and concatenations (e.g., ${this.apiUrl}/users/${id} or baseUrl + '/users/' + userId $\rightarrow$ /users/{id}).
      • Match normalized routes against C# routes regardless of variable naming in TypeScript/JS.
    • No match found: report as "no client consumer located" rather than guessing — do not assume an endpoint is unused just because a match wasn't found statically.
    • Label every finding with which of these three methods was used to locate it.
  4. Compare backend → frontend/client (breaks the client):

    • A DTO property renamed or removed that the TypeScript/JS interface or object model still expects
    • A new required request field the client never sends
    • A response status code the client doesn't handle (e.g. controller now returns 409 Conflict, but client error handler only handles 400/500)
    • A response field's type changed (e.g. long $\rightarrow$ string, or non-nullable $\rightarrow$ nullable) in a way the client type assumes differently
  5. Compare frontend/client → backend (stale/dead client code vs. silent bugs):

    • Harmless dead field: Client sends a payload property the backend ignores without error.
    • Silently broken bug (High Severity): Client logic reads a response property that the backend no longer returns (resulting in undefined at runtime and potential application failures).
  6. Produce the report (see Output Format). This skill does not modify code.

Output Format

  1. Scope Audited — Controllers, DTOs, and TypeScript/JavaScript files audited, along with detected JSON naming policies (e.g. camelCase enabled via Program.cs).

…

FAQ

What are 'breaking changes'?

These are changes that break the communication between the 'backend' and 'frontend', causing the program to stop working correctly.

What is an API 'contract'?

It's the agreement on how the 'backend' and 'frontend' will exchange information. It defines what data is expected and what will be sent.

Can it find errors in any type of 'frontend'?

Yes, it looks for communication patterns in various popular 'frontend' languages and libraries like JavaScript and TypeScript.

Details

Original description by the author

Cross-references C# Web API controllers/DTOs against their TypeScript/JavaScript consumers (React, Angular, Vue, Svelte, Node.js, or hand-written/auto-generated HTTP clients like Fetch, Axios, NSwag) to catch contract drift in both directions: backend changes that break client applications (renamed/removed JSON keys, new required parameters, status code shifts) and frontend code sending fields the

repo: github/awesome-copilot

Popularity

GitHub stars
40k
Ranking position
#4994
License
MIT
Updated
10/15/2026

Is this skill useful?

0

Sign in to vote.

Comments

  • …

More skills from this repository

Similar skills