Zod
Give your coding agent a prioritized Zod playbook so API inputs, env vars, and form payloads are validated at the boundary instead of patched later.
Overview
Zod is an agent skill most often used in Build (also Ship) that encodes 43 prioritized Zod validation rules for TypeScript agents defining and refactoring schemas at application boundaries.
Install
npx skills add https://github.com/pproenca/dot-skills --skill zodWhat is this skill?
- 43 prioritized rules across 8 categories from schema definition through bundle performance
- Incorrect vs correct examples per rule for automated refactors and codegen
- Critical emphasis on string validations, coercion for query/form strings, and avoiding optional-field abuse
- Coverage spans parsing errors, transforms, refinements, and performance-oriented patterns
- Structured for agents maintaining or generating TypeScript codebases (January 2026 guide v1.0.0)
- 43 rules across 8 categories
- Version 1.0.0 (January 2026 guide)
Adoption & trust: 3.3k installs on skills.sh; 157 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You rely on ad-hoc Zod snippets and your agent keeps missing coercion, string constraints, and optional-field traps that leak bad data into production code.
Who is it for?
Solo builders on TypeScript APIs or full-stack apps who want agent-guided Zod consistency before merge and during security-minded review.
Skip if: Teams that do not use Zod or TypeScript, or pure frontend-only work with no runtime validation layer.
When should I use this skill?
Maintaining, generating, or refactoring TypeScript code that uses Zod for schema validation and boundary parsing.
What do I get? / Deliverables
Your agent applies a single prioritized rule set—boundary validation, coercion, and safer optional usage—when generating or refactoring Zod schemas in TypeScript.
- Refactored or generated Zod schemas aligned to prioritized rules
- Consistent parse/safeParse and coercion patterns at boundaries
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Schema validation is where backend contracts are defined—canonical shelf is Build because most rules target TypeScript services and boundaries. Backend is the primary home for parse/safeParse, coercion, and API DTO schemas even when you also apply rules during Ship testing.
Where it fits
Define shared Zod env and webhook payload schemas before wiring routes.
Align test fixtures and parse expectations with the same rule catalog the agent uses in production code.
Audit new endpoints for string validation and coercion gaps against the critical-tier rules.
How it compares
Reference skill for schema discipline—not a runtime linter MCP; pair with your test runner rather than replacing it.
Common Questions / FAQ
Who is zod for?
Solo and indie builders using Claude Code, Cursor, or Codex on TypeScript backends, forms, and API contracts who want structured Zod guidance for their agent.
When should I use zod?
During Build when defining env, API, and form schemas; during Ship when reviewing parsing paths and test fixtures; whenever an agent is generating or refactoring validation code.
Is zod safe to install?
Treat it like any third-party skill: review the Security Audits panel on this Prism page and inspect the SKILL.md in your repo before granting broad agent permissions.
SKILL.md
READMESKILL.md - Zod
# Zod **Version 1.0.0** community January 2026 > **Note:** > This document is mainly for agents and LLMs to follow when maintaining, > generating, or refactoring codebases. Humans may also find it useful, > but guidance here is optimized for automation and consistency by AI-assisted workflows. --- ## Abstract Comprehensive schema validation guide for Zod in TypeScript applications, designed for AI agents and LLMs. Contains 43 rules across 8 categories, prioritized by impact from critical (schema definition, parsing) to incremental (performance, bundle optimization). Each rule includes detailed explanations, real-world examples comparing incorrect vs. correct implementations, and specific impact metrics to guide automated refactoring and code generation. --- ## Table of Contents 1. [Schema Definition](references/_sections.md#1-schema-definition) — **CRITICAL** - 1.1 [Apply String Validations at Schema Definition](references/schema-string-validations.md) — CRITICAL (Unvalidated strings allow SQL injection, XSS, and malformed data; validating at schema level catches issues at the boundary) - 1.2 [Avoid Overusing Optional Fields](references/schema-avoid-optional-abuse.md) — CRITICAL (Excessive optional fields create schemas that accept almost anything; forces null checks throughout codebase) - 1.3 [Use Coercion for Form and Query Data](references/schema-coercion-for-form-data.md) — CRITICAL (Form data and query params are always strings; without coercion, z.number() rejects "42" and z.boolean() rejects "true") - 1.4 [Use Enums for Fixed String Values](references/schema-use-enums.md) — CRITICAL (Plain strings accept any value including typos; enums restrict to valid values and enable autocomplete) - 1.5 [Use Primitive Schemas Correctly](references/schema-use-primitives-correctly.md) — CRITICAL (Incorrect primitive selection causes validation to pass on wrong types; using z.any() or z.unknown() loses all type safety) - 1.6 [Use z.unknown() Instead of z.any()](references/schema-use-unknown-not-any.md) — CRITICAL (z.any() bypasses TypeScript's type system entirely; z.unknown() forces type narrowing before use) 2. [Parsing & Validation](references/_sections.md#2-parsing-&-validation) — **CRITICAL** - 2.1 [Avoid Double Validation](references/parse-avoid-double-validation.md) — HIGH (Parsing the same data twice wastes CPU cycles; in hot paths this adds measurable latency) - 2.2 [Handle All Validation Issues Not Just First](references/parse-handle-all-issues.md) — CRITICAL (Showing only the first error forces users to fix-submit-fix repeatedly; collecting all errors improves UX dramatically) - 2.3 [Never Trust JSON.parse Output](references/parse-never-trust-json.md) — CRITICAL (JSON.parse returns any type; unvalidated JSON allows type confusion attacks and runtime crashes) - 2.4 [Use parseAsync for Async Refinements](references/parse-async-for-async-refinements.md) — CRITICAL (Using parse() with async refinements throws an error; async validation silently fails or crashes the application) - 2.5 [Use safeParse() for User Input](references/parse-use-safeparse.md) — CRITICAL (parse() throws exceptions on invalid data; unhandled exceptions crash servers and expose stack traces to users) - 2.6 [Validate at System Boundaries](references/parse-validate-early.md) — CRITICAL (Validating deep in business logic allows corrupt data to propagate; validating at boundaries catches issues before they spread) 3. [Type Inference](references/_sections.md#3-type-inference) — **HIGH** - 3.1 [Distinguish z.input from z.infer for Transforms](references/type-input-vs-output.md) — HIGH (Using wrong type with transforms causes TypeScript errors; z.input captures pre-transform shape, z.infer captures post-transform) - 3.2 [Enable TypeScript Strict Mode](references/type-enable-strict-mode.md) — HIGH (Without strict mode, Zod's type inference is unreliable; undefined and null slip through, defeating the purp