shared-contracts

Create a new contract by defining a Zod schema, then use the provided CLI to generate the corresponding TypeScript interface and validation function.

Updated Mar 30, 2026
One-click install
npx skills add https://github.com/dtaborda/startup-saas-template --skill shared-contracts
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: shared-contracts
Source: https://github.com/dtaborda/startup-saas-template/tree/main/skills/shared-contracts
Command: npx skills add https://github.com/dtaborda/startup-saas-template --skill shared-contracts

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill ensures the monorepo never drifts into inconsistent DTOs or inline types by centralizing every shared Zod schema and inferred type in @template/contracts.

Core Features & Use Cases

  • Centralized schema conventions: Always define schemas in packages/contracts/src/, use Schema suffixes, and infer types to keep DTOs reliable.
  • Re-export discipline: Update index.ts so every package can import contracts via subpaths or the barrel without duplication.
  • Version-aware edits: Changing field names or required status triggers the contract-versioning workflow to prevent breaking clients.
  • Use Case: When adding a new API request shape, define it once, export it properly, and reuse the contract from ui and server packages.

Quick Start

Define a new Zod schema in packages/contracts, infer its type, add it to the relevant file, and update the barrel export so shared contracts stay synchronized.

Frequently Asked Questions about shared-contracts

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

FAQPage Schema
How do I share Zod schemas and DTOs across a monorepo without type drift?

To share Zod schemas across a monorepo without type drift, centralize every DTO and Zod schema definition in a single contracts package. This ensures all workspaces import consistent types and prevents inline definitions from causing structural inconsistencies.

What is the best way to enforce Zod schema conventions in a TypeScript monorepo?

Enforcing Zod schema conventions requires standardizing definitions within a central contracts directory. You must use specific schema suffixes, infer TypeScript types directly from the schemas, and maintain index re-exports to ensure reliable DTO usage across workspaces.

How do I add a new API request contract to a shared TypeScript monorepo package?

To add a new API request contract, define the Zod schema inside the shared contracts package, infer its TypeScript type, and update the barrel export. This synchronizes the new shared contract so both UI and server packages can reuse it.

When should I bump the version of shared data contracts in a monorepo?

You should bump the version of shared data contracts when modifying field names or changing required statuses within the Zod schemas. This triggers the contract-versioning workflow to prevent breaking existing clients that rely on those specific DTO structures.

Does shared Zod schema validation work for both UI and server workspaces?

Yes, shared Zod schema validation works for both UI and server workspaces by centralizing definitions in a contracts package. By updating the index barrel exports, every workspace can import the exact same validated DTOs without duplication.

Why do my monorepo packages have inconsistent API response types?

Monorepo packages have inconsistent API response types when inline types are used instead of centralized contracts. Defining Zod schemas once in a shared package and enforcing barrel re-exports ensures all workspaces consume the exact same inferred types.