pydantic-python

Write, validate, and migrate Pydantic v2 models with version-grounded serialization contracts.

Updated Aug 12, 2026
One-click install
npx skills add https://github.com/schattenspiegel/skill-foundry-skills --skill pydantic-python-schattenspiegel
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pydantic-python
Source: https://github.com/schattenspiegel/skill-foundry-skills/tree/main/skills/pydantic-python
Command: npx skills add https://github.com/schattenspiegel/skill-foundry-skills --skill pydantic-python-schattenspiegel

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pydantic, and includes scripts (resource) and references (resource) components.

What problem does it solve? Pydantic v2 code often fails silently through unintended coercion, alias mismatches, leaked subclass fields, or broken v1-to-v2 migrations. This Skill guides writing, reviewing, debugging, and testing Pydantic models so validation boundaries and serialized output are explicit, tested, and version-correct. ## Core Features & Use Cases - Boundary Design: Choose the right abstraction (BaseModel, TypeAdapter, RootModel) based on input source, strictness, extra-data policy, and output contract. - Validation & Serialization Guidance: Apply validators, serializers, discriminated unions, directional aliases, and strict-mode rules with canonical code patterns. - Version Grounding & Migration: Detect v1-shaped APIs (parse_obj, .dict(), @validator, orm_mode) and migrate them with behavior tests, plus an inspection script that reports installed Pydantic versions and API signatures. - Use Case: When an API endpoint accepts payment payloads, use this Skill to build a strict model with extra="forbid", a discriminated union for payment kinds, tested aliases, and JSON-mode serialization that cannot leak internal fields. ## Quick Start Ask the AI to review or write a Pydantic model for your payload, specifying the input source, strictness needs, and expected serialized output.

Frequently Asked Questions about pydantic-python

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

FAQPage Schema
How do I validate JSON data with Pydantic v2?▼

Use Model.model_validate_json(data) for JSON text or bytes, and Model.model_validate(value) for Python objects. For non-model types like list[Item] or unions, create a TypeAdapter once and reuse its validate_python or validate_json methods.

How do I migrate Pydantic v1 code to v2?▼

Map v1 patterns to v2 equivalents: parse_obj becomes model_validate, .dict() becomes model_dump, @validator becomes field_validator, and class Config becomes ConfigDict. Add behavior tests first, since optional fields, aliases, equality, and serialization semantics can change beyond simple renames.

When should I use TypeAdapter instead of BaseModel?▼

Use TypeAdapter when validating standalone types like list[Item], unions, TypedDict, or dataclasses without inventing a wrapper model. Use BaseModel for named domain objects with fields, and RootModel only for a true single-root public type needing model behavior.

Does Pydantic strict mode behave the same for JSON and Python input?▼

No, strict validation is representation-sensitive. Some types reject a Python string in strict Python mode but accept the JSON string in strict JSON mode, so you must test every input representation your application exposes.

How do I prevent subclass fields from leaking during serialization?▼

By default, a field annotated as a base model serializes only fields declared on that annotation, hiding subclass-only fields like secrets. Avoid serialize-as-any or polymorphic options unless the wire contract requires them, and add regression tests for sensitive fields.

When should I not use Pydantic for validation?▼

Skip runtime validation for trusted internal records where a dataclass or TypedDict suffices. Route settings, environment variables, and secrets-directory work to pydantic-settings instead, and never use model_construct to bypass validation on untrusted input.