Pydantic Multi-Model Architecture
Build consistent, reusable Pydantic data contracts with a structured multi-model pattern.
The skill only provides Pydantic model templates and does not invoke external services, handle credentials, upload data, or perform destructive actions; the baseline risk is therefore low. It does not specify user confirmation, sensitive-field handling, data flow, rollback, or dependency security, so 7 points are deducted.
The main document, template, and reference file are broadly coherent and cover the multi-model structure plus some validation guidance. The template uses class Config while the reference requires Pydantic v2 model_config, and there are no installation notes, skill-specific tests, abnormal-input coverage, or failure feedback; 13 points are deducted. Static review also caps this score below 10.
The audience, scenarios, model variants, and basic integration locations are reasonably clear. Non-fit ranges, trigger precision, project-structure variance, and version-compatibility boundaries are not defined, and Chinese-language guidance is absent; the core function does not depend on overseas network services. 7 points are deducted.
The skill includes a name, description, MIT license, author, version, quick start, template, and reference file, with generally clear information architecture. It lacks a changelog, explicit maintenance responsibility, and an update path, and its Pydantic v2 guidance conflicts with the examples; 6 points are deducted.
The template is a usable starting point for API and database models and covers the core Base, Create, Update, Response, and InDB task. It still requires substantial placeholder replacement and project-specific decisions for fields, aliases, persistence constraints, and serialization, with no skill-specific verified output; 9 points are deducted. Static review caps this dimension at 7.
The skill files, template, and capability checklist are auditable, and the repository provides general CI and test infrastructure. There is no committed skill-specific test suite, real execution result, or independently reproducible evidence, so 6 points are deducted. Static review caps this dimension at 5.
- The examples use class Config while the reference requires Pydantic v2 model_config; confirm the target Pydantic version and correct the configuration before adoption.
- The InDB model assumes doc_type and a Cosmos DB-oriented pattern; other databases or domains may require removing or redesigning it.
- The skill lacks complete examples for model_dump, model_validate, schema generation, and field/model validators, so the template should not be treated as a complete production solution.
What does this skill do, and when should you use it?
This Python skill from Microsoft's Agent Skills repository guides developers using Pydantic v2 to define API request, response, and database models. It uses five model variants: Base, Create, Update, Response, and InDB. It also covers snake_case-to-camelCase aliases, optional fields for PATCH updates, and a doc_type field for Cosmos DB queries. It fits Python applications that need consistent API contracts and validation structures, but it is not a complete FastAPI or database implementation.
It instructs an agent to copy the model template from assets/template.py and replace PascalCase and snake_case resource placeholders; define shared, creation, update, response, and database document models; configure camelCase field aliases with populate_by_name; make update fields optional; add doc_type to InDB models; place models under src/backend/app/models/; export them from __init__.py; and add corresponding TypeScript types.
- A Python backend developer is designing create, update, and response models for a new resource.
- A FastAPI project needs required creation fields and fully optional PATCH fields.
- A team needs Python snake_case fields to interoperate with camelCase client payloads.
- A Cosmos DB application needs document models distinguished by a doc_type field.
- A development team wants a consistent model structure across multiple resources.
What are this skill's strengths and limitations?
- Defines clear responsibilities for five model variants, supporting consistent API contracts.
- Covers camelCase aliases, optional PATCH fields, and database document typing.
- Provides a reusable template entry point and concrete integration locations.
- The README reports 12 test scenarios for this skill.
- The material focuses on patterns and examples rather than a complete runnable implementation.
- It specifies Pydantic v2 but does not document a more precise version range.
- It does not provide authentication, error handling, migrations, or database access code.
- TypeScript types are mentioned as an integration step but no generation or definition example is included.
How do you install this skill?
In an Agent Skills-compatible client, run npx skills add microsoft/skills and select this skill in the installation wizard. The README states that skills are installed into the selected agent's directory, such as .github/skills/ for GitHub Copilot. The source does not document a dedicated single-skill installation command or version-pinning method.
How do you use this skill?
Trigger the skill for work involving Pydantic v2 models, API request/response schemas, or database models. Example: Create Base, Create, Update, Response, and InDB Pydantic models for a Project resource with camelCase aliases. Provide the resource fields and project layout. The skill recommends placing models in src/backend/app/models/ and exporting them from src/backend/app/models/__init__.py.