์Šคํ‚ฌ pydantic-models-py
๐Ÿ“ฆ

pydantic-models-py

์•ˆ์ „

Build Pydantic Models with Multi-Model Pattern

Define consistent API schemas without manual boilerplate. This skill generates structured Pydantic models following established patterns for request validation, responses, and database integration.

์ง€์›: Claude Codex Code(CC)
๐Ÿฅ‰ 74 ๋ธŒ๋ก ์ฆˆ
1

์Šคํ‚ฌ ZIP ๋‹ค์šด๋กœ๋“œ

2

Claude์—์„œ ์—…๋กœ๋“œ

์„ค์ • โ†’ ๊ธฐ๋Šฅ โ†’ ์Šคํ‚ฌ โ†’ ์Šคํ‚ฌ ์—…๋กœ๋“œ๋กœ ์ด๋™

3

ํ† ๊ธ€์„ ์ผœ๊ณ  ์‚ฌ์šฉ ์‹œ์ž‘

ํ…Œ์ŠคํŠธํ•ด ๋ณด๊ธฐ

"pydantic-models-py" ์‚ฌ์šฉ ์ค‘์ž…๋‹ˆ๋‹ค. User entity with id, name, email, created_at fields

์˜ˆ์ƒ ๊ฒฐ๊ณผ:

Generated UserBase, UserCreate, UserUpdate, UserResponse, and UserInDB model classes with proper Field definitions, type annotations, and Config class for alias handling

"pydantic-models-py" ์‚ฌ์šฉ ์ค‘์ž…๋‹ˆ๋‹ค. Project model requiring camelCase API compatibility

์˜ˆ์ƒ ๊ฒฐ๊ณผ:

Models with Field aliases (workspaceId, createdAt) that accept both naming conventions while using Pythonic snake_case internally

๋ณด์•ˆ ๊ฐ์‚ฌ

์•ˆ์ „
v1 โ€ข 2/24/2026

All 21 static analysis findings are false positives. The scanner misidentified Markdown code block backticks as shell execution, and documentation references to HTTP/cryptography as actual code. SKILL.md is pure documentation with Python code examples for Pydantic model patterns. No executable code, network calls, or security risks detected.

1
์Šค์บ”๋œ ํŒŒ์ผ
64
๋ถ„์„๋œ ์ค„ ์ˆ˜
0
๋ฐœ๊ฒฌ ์‚ฌํ•ญ
1
์ด ๊ฐ์‚ฌ ์ˆ˜
๋ณด์•ˆ ๋ฌธ์ œ๋ฅผ ์ฐพ์ง€ ๋ชปํ–ˆ์Šต๋‹ˆ๋‹ค
๊ฐ์‚ฌ์ž: claude

ํ’ˆ์งˆ ์ ์ˆ˜

38
์•„ํ‚คํ…์ฒ˜
100
์œ ์ง€๋ณด์ˆ˜์„ฑ
87
์ฝ˜ํ…์ธ 
50
์ปค๋ฎค๋‹ˆํ‹ฐ
100
๋ณด์•ˆ
91
์‚ฌ์–‘ ์ค€์ˆ˜

๋งŒ๋“ค ์ˆ˜ ์žˆ๋Š” ๊ฒƒ

REST API Schema Definition

Define request/response models for FastAPI or Flask endpoints with consistent validation patterns.

Database Document Modeling

Create InDB model variants with doc_type fields for Cosmos DB or MongoDB document storage.

Frontend-Backend Contract Sync

Generate matching Python models and TypeScript types to ensure API contract consistency.

์ด ํ”„๋กฌํ”„ํŠธ๋ฅผ ์‚ฌ์šฉํ•ด ๋ณด์„ธ์š”

Basic Model Generation 
Create Pydantic models for a User entity with fields: id (string), name (string, required), email (string with email validation), created_at (datetime). Use the multi-model pattern with Base, Create, Update, and Response variants.
Model with CamelCase Aliases 
Generate Pydantic models for a Project entity. All fields should accept both snake_case and camelCase using Field aliases. Include workspace_id, project_name, and is_active fields.
Database Model with InDB Variant 
Create complete Pydantic models for a Document entity including InDB variant with doc_type field. Add min_length validation on name and optional description field for updates.
Complex Nested Model Pattern 
Build Pydantic models for an Order entity with nested line_items array. Each line item has product_id, quantity, and price. Create full multi-model pattern with validation constraints on all fields.

๋ชจ๋ฒ” ์‚ฌ๋ก€

  • Always separate Create and Update models - Create requires all fields, Update makes all fields optional for PATCH semantics
  • Use Field with explicit default=None for optional update fields to distinguish between null and unset values
  • Enable populate_by_name = True in Config class to accept both snake_case and camelCase from API clients

ํ”ผํ•˜๊ธฐ

  • Do not reuse the same model class for both request bodies and database documents - separation prevents data leakage
  • Avoid putting business logic in model classes - keep them as pure data schemas with validation only
  • Do not omit doc_type in InDB models when using Cosmos DB - queries will fail without proper type filtering

์ž์ฃผ ๋ฌป๋Š” ์งˆ๋ฌธ

What is the multi-model pattern and why use it?
The pattern creates separate model classes for different purposes: Base (shared fields), Create (required fields for POST), Update (optional fields for PATCH), Response (full output), and InDB (database document with metadata). This separation prevents accidental data exposure and enforces correct validation at each layer.
How do camelCase aliases work with Pydantic?
Use Field(alias='camelCaseName') on each field and set populate_by_name = True in the Config class. This allows the model to accept both naming conventions from API clients while using snake_case internally in Python code.
Why make all Update fields optional?
PATCH requests should only include fields being modified. Making all fields optional with default=None allows partial updates while distinguishing between 'field not provided' (None) and 'field set to null' (explicit null).
What is the doc_type field for?
In document databases like Cosmos DB, doc_type identifies the entity type within a shared collection. The InDB model adds this field automatically so queries can filter documents by type.
Do I need to create TypeScript types manually?
Yes, this skill guides you to create matching TypeScript interfaces. Consider tools like pydantic2ts or datamodel-code-generator for automatic TypeScript generation from Pydantic models.
Can I use this pattern with SQLAlchemy or other ORMs?
Yes, Pydantic models work alongside ORMs. Use Pydantic for request/response validation and serialization, and ORM models for database operations. Some ORMs like SQLAlchemy 2.0 have native Pydantic integration.

๊ฐœ๋ฐœ์ž ์„ธ๋ถ€ ์ •๋ณด

์ž‘์„ฑ์ž

sickn33

๋ผ์ด์„ ์Šค

MIT

๋ฆฌํฌ์ง€ํ† ๋ฆฌ

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/pydantic-models-py

์ฐธ์กฐ

main

ํŒŒ์ผ ๊ตฌ์กฐ

๐Ÿ“„ SKILL.md