Litestar dto openapi

Skill litestar-org/litestar-skills/skills/litestar-dto-openapi

Auto-activate for MsgspecDTO, DTOConfig, litestar.dto, OpenAPIConfig, response DTOs, schema_extra, RequestEncodingType, or /schema. Not for persistence models alone.From its SKILL.md

Install

npx -y skills add litestar-org/litestar-skills --skill litestar-dto-openapi

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.5 KB, as published. Nobody here has run it

Litestar DTO and OpenAPI

Use this skill for DTO selection, msgspec-first schemas, request/response typing, and OpenAPI shape.

Code Style Rules

Prefer msgspec DTOs in Litestar apps unless the project is already Pydantic-led.
Keep persistence models separate from API DTOs.
Use camelCase wire names while Python stays snake_case.
Exclude server-owned fields from write DTOs.
Treat nullability and requiredness separately: T | None permits null; only a default value makes a field optional.

Quick Reference

DTO patterns: dto.md
Pair with litestar-data-services when mapping service results.
Pair with msgspec for deeper Struct modeling.

Workflow

Identify input, output, and persistence shapes separately.
Choose msgspec DTOs or match the existing Pydantic stack.
Configure excludes, partial updates, rename behavior, and media type.
Check the generated OpenAPI schema.

</workflow> <guardrails>

Guardrails

Do not leak internal persistence-only fields into write DTOs.
Do not switch an existing Pydantic-heavy project to msgspec opportunistically.
Do not rely on untyped dict payloads when request shape is known.
Do not treat OpenAPI as documentation only; it is the contract.

</guardrails> <validation>

Validation Checkpoint

Request and response DTOs are explicit.
Wire names match the API convention.
Server-owned fields are excluded from writes.
/schema output matches the intended contract.
Nullable fields without defaults remain in the OpenAPI required array.

</validation> <example>

Example

from litestar.dto import DTOConfig, MsgspecDTO


class UserWriteDTO(MsgspecDTO[UserWrite]):
    config = DTOConfig(exclude={"id", "created_at"})

</example>

References Index

dto.md

Official References

https://docs.litestar.dev/ - Litestar documentation
https://docs.litestar.dev/latest/reference/ - Litestar API reference
https://github.com/litestar-org/litestar/tree/v2.24.0 - Audited Litestar 2.24.0 source

Shared Styleguide Baseline

What ships with it: 1 file

5.1 KB alongside SKILL.md

references/

dto.md5.1 KB

Gives 0 of the 12 instructions most api reference skills give

Counted across 159 of the 198 authors here whose files we hold, read 2026-09-06

Document all possible error responsesin 14 of 159, across 7 files
Create OpenAPI 3.0 compliant specificationsin 13 of 159, across 7 files
Use $ref for reusable componentsin 12 of 159, across 6 files
Include example requests and responsesin 11 of 159, across 5 files
Group endpoints logically with tagsin 11 of 159, across 5 files
Document all endpoints with descriptions and examplesin 10 of 159, across 4 files
Define request and response schemas accuratelyin 9 of 159, across 3 files
Include authentication and security schemesin 8 of 159, across 2 files
Provide clear examples for all operationsin 8 of 159, across 2 files
Use descriptive summaries and descriptionsin 8 of 159, across 2 files
Use clear operation IDsin 8 of 159, across 2 files
Include parameter types and descriptionsin 7 of 159, across 5 files

Said here and by no other author read

Prefer msgspec DTOs unless the project is Pydantic-led
Keep persistence models separate from API DTOs
Use camelCase wire names while Python stays snake_case
Exclude server-owned fields from write DTOs
Treat nullability and requiredness separately
Identify input, output, and persistence shapes separately

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.