Why use branded types instead of plain strings?

Branded types prevent logic errors where two different concepts (like a UserId and an OrderId) are both strings but should not be interchangeable in function arguments. It forces the developer to validate the string before using it as a specific type.

What is the 'Parse, Don't Validate' principle?

It is an architectural approach where you transform untrusted input into a richer, typed data structure that is guaranteed to be valid, rather than simply checking if data is valid and returning a boolean.

Where should validation happen according to this skill?

Validation should happen exclusively at the 'boundary'—the point where data enters your system from an untrusted source, such as an HTTP request, a CLI argument, or a database query result.

Does this skill support Express middleware?

Yes, it provides patterns for creating reusable Express middleware that validates request bodies against Zod schemas before passing control to the route handler.

Zod Validation Boundary

Name: Zod Validation Boundary
Author: jagreehal

byjagreehal

API Development

Enforces secure data validation at system boundaries using Zod schemas and branded types to ensure type-safe business logic.

About

This skill implements the 'Parse, Don't Validate' architectural pattern to harden applications against malformed data. By establishing a strict validation layer at system boundaries—such as HTTP endpoints, CLI inputs, or message queues—it ensures that external data is transformed into rich, trusted types before reaching core business logic. This approach eliminates redundant checks within internal functions, prevents 'primitive obsession' through the use of branded types, and provides a standardized way to handle schema and domain-level validation errors in TypeScript environments.

Key Features

Schema-based input validation using Zod for robust shape and format checking
Implementation of Branded Types to prevent accidental mixing of similar primitive types like IDs
Support for advanced patterns including type coercion, transforms, and partial updates
Standardized validation error formatting for consistent API error responses
0 GitHub stars
Clear separation between boundary schema validation and internal domain logic

Use Cases

Hardening Express or Fastify API endpoints against invalid request bodies and query parameters
Creating type-safe domain models where IDs and sensitive strings cannot be used interchangeably
Refactoring legacy codebases to move validation logic from business services to the entry layer

About

Key Features

Schema-based input validation using Zod for robust shape and format checking
Implementation of Branded Types to prevent accidental mixing of similar primitive types like IDs
Support for advanced patterns including type coercion, transforms, and partial updates
Standardized validation error formatting for consistent API error responses
0 GitHub stars
Clear separation between boundary schema validation and internal domain logic

Use Cases

Hardening Express or Fastify API endpoints against invalid request bodies and query parameters
Creating type-safe domain models where IDs and sensitive strings cannot be used interchangeably
Refactoring legacy codebases to move validation logic from business services to the entry layer