type-safety

Enforce strict typing and centralized data contracts across a TypeScript and Python monorepo.

Updated Mar 25, 2026
One-click install
npx skills add https://github.com/Haslien/My-Claude-Skills --skill type-safety-haslien
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: type-safety
Source: https://github.com/Haslien/My-Claude-Skills/tree/main/.claude/skills/type-safety
Command: npx skills add https://github.com/Haslien/My-Claude-Skills --skill type-safety-haslien

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Enforce strict typing and centralize data contracts across the monorepo to prevent duplicate or conflicting schemas and to accelerate safe code changes.

Core Features & Use Cases

  • Centralized shared schemas under shared/schemas to ensure a single source of truth for data contracts across services.
  • Enforce rules to avoid unsafe typings such as as any, // @ts-ignore, and ensure proper placement of types with no cross-service leakage.
  • Provide clear guidance for TypeScript and Python ecosystems with Zod and Pydantic validators, including ESLint and Pyright configuration when needed.

Quick Start

Create or update type definitions and schemas following the centralized model; ensure all new primitives are placed in shared/schemas and that internal service types stay local.

Frequently Asked Questions about type-safety

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

FAQPage Schema
How do I enforce strict typing and centralized data contracts across a monorepo?

To enforce strict typing in a monorepo, place cross-service types under a shared/schemas directory to establish a single source of truth, preventing duplicate or conflicting schemas across services.

What is the best way to share type schemas between TypeScript and Python services?

The best way to share schemas between TypeScript and Python is using Zod for TypeScript validation and Pydantic for Python validation, centralizing these contracts in a shared directory.

Why should I avoid using 'as any' and '// @ts-ignore' when defining types?

You should avoid 'as any' and '// @ts-ignore' because they bypass type checking, which breaks type safety and risks introducing runtime errors from invalid data contracts.

How do I prevent type leakage between shared contracts and internal service types?

To prevent type leakage, keep cross-service data contracts centralized under shared/schemas and ensure service-internal types remain local to their specific service boundaries.

Do I need Zod and Pydantic to maintain type safety in a mixed-language monorepo?

Yes, you need Zod for TypeScript and Pydantic for Python to validate code and enforce strict typing, ensuring safe boundaries and preventing duplicated contracts across the monorepo.