typespec-cross-layer

Map TypeSpec types to Postgres DDL, Kotlin data classes, and TypeScript types.

1|Updated Mar 15, 2026
One-click install
npx skills add https://github.com/hafley66/claude-research --skill typespec-cross-layer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: typespec-cross-layer
Source: https://github.com/hafley66/claude-research/tree/main/skills/typespec-cross-layer
Command: npx skills add https://github.com/hafley66/claude-research --skill typespec-cross-layer

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Cross-layer type mapping across storage and application layers for TypeSpec types, enabling safe defaults and predictable behavior.

Core Features & Use Cases

  • Default type mapping from TypeSpec to Postgres, Kotlin, and TS
  • Override decorators for non-default mappings
  • Patch semantics with optional and nullable fields
  • Separate input/output types per HTTP method
  • Session context injection support
  • Emitters for Postgres DDL, Kotlin data classes, TS types, and bespoke systems

Quick Start

Define your TypeSpec model and run the appropriate emitters to generate Postgres DDL, Kotlin data classes, TS types, and bespoke outputs.

Frequently Asked Questions about typespec-cross-layer

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

FAQPage Schema
How do I map TypeSpec models to Postgres, Kotlin, and TypeScript simultaneously?

TypeSpec cross-layer mapping applies default inferences and override decorators to emit Postgres DDL, Kotlin data classes, and TypeScript types from a single model definition. You define your TypeSpec model and run the appropriate emitters to generate multi-target outputs.

Can I customize default type mappings from TypeSpec to specific database or language targets?

Yes, TypeSpec type mapping supports override decorators for non-default mappings. Default inferences handle standard conversions to Postgres, Kotlin, and TypeScript, while explicit overrides allow granular control when default behavior does not match target system requirements.

How do you handle PATCH semantics with optional and nullable fields in TypeSpec APIs?

Patch semantics in TypeSpec cross-layer mapping treat fields as optional and nullable to support partial updates. The system separates input and output types per HTTP method, ensuring patch operations correctly distinguish between omitted fields and explicit null values.

Does TypeSpec type mapping support separate input and output types for different HTTP methods?

Yes, the mapping generates separate input and output types per HTTP method. This separation ensures that request bodies and response payloads have distinct type structures, supporting session context injection where needed for bespoke systems.

What's the best way to generate Postgres DDL from TypeSpec definitions?

TypeSpec cross-layer emitters produce Postgres DDL directly from your TypeSpec models using default type inferences. For non-standard column types or constraints, apply override decorators before running the DDL emitter to ensure accurate schema generation.

When should I use explicit overrides instead of default TypeSpec type inferences?

Use explicit TypeSpec override decorators when target systems require non-default type mappings, such as bespoke storage formats or language-specific types that default inferences cannot predict. Default mappings cover standard Postgres, Kotlin, and TypeScript conversions safely.