pydantic-models-py
マルチモデルパターンによる Pydantic モデルの構築
手動のボイラープレートなしで、一貫性のある API スキーマを定義します。このスキルは、リクエスト検証、レスポンス、およびデータベース統合のための確立されたパターンに従って、構造化された Pydantic モデルを生成します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「pydantic-models-py」を使用しています。 id、name、email、created_at フィールドを持つ User エンティティ
期待される結果:
適切な Field 定義、型注釈、およびエイリアス処理用の Config クラスを持つ UserBase、UserCreate、UserUpdate、UserResponse、UserInDB モデルクラスを生成
「pydantic-models-py」を使用しています。 camelCase API 互換性が必要な Project モデル
期待される結果:
Field エイリアス（workspaceId、createdAt）を持つモデル。Python 内部では snake_case を使用しつつ、両方の命名規則を受け付け
セキュリティ監査
安全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.
品質スコア
作れるもの
REST API スキーマ定義
一貫性のある検証パターンを持つ FastAPI または Flask エンドポイントのリクエスト/レスポンスモデルを定義します。
データベースドキュメントモデリング
Cosmos DB または MongoDB ドキュメントストレージ用に、doc_type フィールドを含む InDB モデルバリエーションを作成します。
フロントエンド - バックエンド契約同期
API 契約の一貫性を確保するために、一致する Python モデルと TypeScript 型を生成します。
これらのプロンプトを試す
User エンティティの Pydantic モデルを作成してください。フィールド：id (文字列)、name (文字列、必須)、email (メール検証付き文字列)、created_at (日時)。Base、Create、Update、Response のバリエーションを持つマルチモデルパターンを使用してください。
Project エンティティの Pydantic モデルを生成してください。全フィールドは Field エイリアスを使用して snake_case と camelCase の両方を受け付けるようにしてください。workspace_id、project_name、is_active フィールドを含めてください。
doc_type フィールドを持つ InDB バリアントを含む Document エンティティの完全な Pydantic モデルを作成してください。name に min_length 検証を追加し、更新用のオプション description フィールドを含めてください。
line_items 配列を含む Order エンティティの Pydantic モデルを構築してください。各ラインアイテムは product_id、quantity、price を持ちます。すべてのフィールドに検証制約を持つ完全なマルチモデルパターンを作成してください。
ベストプラクティス
- Create モデルと Update モデルを常に分離する - Create は全フィールド必須、Update は PATCH セマンティクスのため全フィールドをオプションにする
- オプションの更新フィールドには明示的に default=None を使用した Field を使用し、null と未設定値を区別する
- Config クラスで populate_by_name = True を有効にして、API クライアントから snake_case と camelCase の両方を受け付ける
回避
- リクエストボディとデータベースドキュメントに同じモデルクラスを再利用しない - データリークを防ぐためには分離が必要
- ビジネスロジックをモデルクラスに含めない - 検証のみを行う純粋なデータスキーマとして保つ
- Cosmos DB 使用時に InDB モデルで doc_type を省略しない - 適切な型フィルタリングがないとクエリが失敗する