verify-type-parity

Validate strict type matching between frontend TypeScript interfaces and backend Kotlin DTOs.

Updated May 29, 2026

Search Tags:#typescript #frontend #backend #type checking #kotlin #dto #api contract

Ready to run

npx skills add https://github.com/peppone-choi/opensamguk --skill verify-type-parity

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: verify-type-parity
Source: https://github.com/peppone-choi/opensamguk/tree/main/.claude/skills/verify-type-parity
Command: npx skills add https://github.com/peppone-choi/opensamguk --skill verify-type-parity

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill prevents bugs and integration issues by ensuring that the TypeScript types used in the frontend precisely match the Kotlin Data Transfer Objects (DTOs) and Entities defined in the backend.

Core Features & Use Cases

Detects Loose Types: Identifies the use of any, unknown, Record<string, any>, and Record<string, unknown> in API contracts, promoting stricter typing.
Checks Inline Types: Ensures API response/request types are defined in shared type files rather than inline within API client code.
Validates DTO Location: Verifies that backend data class definitions are appropriately placed in DTO packages, not scattered within controllers.
Identifies Missing Types: Flags backend DTOs that lack corresponding frontend TypeScript interfaces.
Verifies Field Matching: Compares fields between frontend types and backend DTOs/Entities for discrepancies.
Use Case: After adding a new field to a backend User DTO, run this Skill to confirm that the corresponding User interface in the frontend has also been updated correctly, preventing runtime errors.

Quick Start

Run the verify-type-parity skill to check for any discrepancies between frontend TypeScript types and backend Kotlin DTOs.

Frequently Asked Questions about verify-type-parity

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

FAQPage Schema

How do I ensure type consistency between frontend TypeScript and backend Kotlin DTOs?▼

Type consistency between frontend TypeScript and backend Kotlin DTOs is ensured by validating strict type matching across API contracts to detect field mismatches, missing type definitions, and incorrect DTO placement. This prevents integration bugs and runtime errors.

Why does my API contract type checking fail when using loose types in TypeScript?▼

API contract type checking fails with loose types because using `any`, `unknown`, or `Record<string, any>` in TypeScript interfaces bypasses strict type safety. Detecting and replacing these loose types enforces stricter typing and prevents unpredictable runtime behavior.

What is the best way to check for missing TypeScript interfaces for backend Kotlin DTOs?▼

The best way to check for missing TypeScript interfaces for backend Kotlin DTOs is to verify field matching across API contracts. This process identifies backend DTOs that lack corresponding frontend type definitions and flags them before deployment.

Can I validate that backend data class definitions are placed in DTO packages instead of controllers?▼

Yes, you can validate backend data class placement by checking that Kotlin DTOs are appropriately located within DTO packages. This ensures type definitions are not scattered inside controllers, maintaining clean architecture and consistent API contracts.

How do I detect inline type definitions in my API client code?▼

You detect inline type definitions in API client code by checking that API response and request types are defined in shared type files rather than inline. This promotes reusability and ensures API contract consistency across the full stack.