api-breaking-change-detector — скилл для GitHub Copilot
Сверяет контроллеры и DTO на C# с клиентами на TypeScript или JavaScript прямо по исходному коду. Находит несовпадения контрактов API перед коммитом или релизом.
npx skills add github/awesome-copilot --skill api-breaking-change-detectorЧто делает api-breaking-change-detector
Скилл ищет расхождения между бэкендом на C# Web API и фронтендом на TypeScript или JavaScript. Он читает код контроллеров, типы DTO и глобальные настройки JSON в Program.cs или Startup.cs. Анализ учитывает атрибуты [JsonPropertyName], [JsonIgnore], модификатор required из C# 11 и аннотации вроде [Required].
Для проверки скилл нормализует пути HTTP-запросов у клиентов на Fetch, Axios или NSwag. Затем контракт сверяется в обоих направлениях: новые обязательные поля в запросах, удалённые свойства в ответах, сдвиги типов или появление кодов ошибок вроде 409, которые клиент не обрабатывает. Если клиент отправляет лишние данные или читает удалённое свойство, инструмент отметит это в отчёте.
Он не правит файлы сам. Скилл работает только как статический аудитор и выдаёт отчёт о найденных расхождениях. Он не предназначен для генерации кода по спецификациям OpenAPI или сравнения двух JSON-схем. Ставить его стоит командам с монорепозиториями или общим доступом к коду бэкенда и фронтенда, когда нужно поймать поломку до деплоя.
Какие задачи решает
- найти удалённые свойства DTO в ответах C# до сбоя клиентского приложения
- проверить соответствие HTTP-клиентов на TypeScript изменившимся маршрутам бэкенда
- выявить непереданные обязательные поля перед мержем изменений в контроллерах
- обнаружить несоответствия между регистрами свойств и правилами сериализации JSON
Примеры запросов агенту
- Проверь изменения в UsersController и связанных DTO на совместимость с фронтендом на React.
- Проверь, сломает ли этот коммит в C# API клиентские вызовы в папке frontend/src.
- Сверь контракты эндпоинта /api/orders между бэкендом и TypeScript-клиентом.
Как установить api-breaking-change-detector
1Через Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill api-breaking-change-detector2GitHub CLI
gh skill install github/awesome-copilot api-breaking-change-detector3Вручную: положить файлы
.github/skills/api-breaking-change-detector/SKILL.md1Через Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill api-breaking-change-detector -a claude-code2Вручную: положить файлы
~/.claude/skills/api-breaking-change-detector/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/api-breaking-change-detector/
Вручную: положить файлы
.agents/skills/api-breaking-change-detector/SKILL.mdДля всех проектов — ~/.agents/skills/
Вручную: положить файлы
.cursor/skills/api-breaking-change-detector/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
Командой платформы
gemini skills install https://github.com/github/awesome-copilot --path skills/api-breaking-change-detectorВручную: положить файлы
.devin/skills/api-breaking-change-detector/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Claude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
Из того же набора554
Весь набор →Похожие
Вопросы о api-breaking-change-detector
Как установить api-breaking-change-detector в GitHub Copilot?
Выполните команду gh skill install github/awesome-copilot api-breaking-change-detector или запустите установку через npx skills add github/awesome-copilot --skill api-breaking-change-detector.
Что делает api-breaking-change-detector?
Скилл сопоставляет контроллеры C# с клиентскими вызовами на TypeScript или JavaScript и формирует отчёт о несовместимых или устаревших полях.
Нужен ли скиллу отдельный файл OpenAPI?
Нет, инструмент анализирует исходный код напрямую, сверяя атрибуты маршрутов, C# DTO и настройки сериализации в Program.cs.
Исходный текст
SKILL.md · MIT
---
name: api-breaking-change-detector
description: "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 backend no longer reads. Works directly against source code, not exported OpenAPI spec files. Use when the user asks to check for breaking API changes, verify frontend/backend contract sync, or audit a DTO/controller change against its TypeScript/JS consumers before merging. Not for generating new API code from a spec (see openapi-to-application-code) or scaffolding new endpoints (see aspnet-minimal-api-openapi)."
---
# 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`).
2. **Backend → Client Breaks** — Grouped by endpoint: what changed, match method used (Auto-generated / Normalized Route Match), exact impact on the client, and severity (Compilation Error vs. Silent Runtime Failure).
3. **Client → Backend Drift** — Stale fields sent or expected, explicitly distinguishing harmless dead fields from silently broken client UI logic.
4. **No Consumer Found** — Unmatched backend DTOs/endpoints requiring manual confirmation.
5. **Match Confidence Summary** — Breakdown of findings derived from auto-generated clients vs. normalized hand-written routes vs. unmatched routes.
## Guidelines
- **URL Normalization**: Always strip query parameters (`?status=active`) and normalize path parameters (`${id}` / `:id` / `{id}`) before comparing routes.
- **Naming Policies**: Never assume a C# property name matches a TypeScript/JS property verbatim without checking for `[JsonPropertyName("...")]` or global `JsonNamingPolicy.CamelCase` settings.
- **Modern C# Nuances**: Check for C# 11 `required` keyword and `#nullable enable` annotations (`string?` vs `string`) when assessing required properties.
- **Framework Agnostic**: Apply contract matching across any TypeScript or JavaScript client (Fetch, Axios, Angular, React, Vue, Svelte, Node.js).
- **Never Fabricate**: If no matching client service or DTO is found, report "No consumer located via static search" — never guess a pairing based purely on loose class names.
- **Reporting Only**: Do not modify code; output a scannable, actionable audit report.
© github · MIT · github/awesome-copilot