validation

name	validation
description	Use when creating, updating, reviewing, or debugging input validation, schemas, request validation, form validation, query validation, data sanitization, or validation errors.

Validation

Use this skill for safe and consistent validation of external input.

Rules

• Follow the project’s existing validation pattern.
• Do not add a new validation library unless already used or explicitly requested.
• Validate all external input before business logic.
• Server-side validation is mandatory; client-side validation is only for UX.
• Validate body, query, params, headers, files, and form data when relevant.
• Pass only validated data to services or use-cases.
• Strip or reject unknown fields according to project convention.
• Do not trust client-provided IDs, roles, ownership, prices, permissions, status, or tenant scope.
• Return validation errors using the existing project error format.
• Preserve existing response, error, logging, and test patterns.
• Avoid unrelated refactors.

Inspect First

Before changing validation code, check existing patterns for:

• validation library
• schema location
• request middleware
• error format
• field error format
• DTO/type generation
• form validation
• sanitization rules
• test style

Implementation Checklist

• Identify every external input source.
• Reuse existing schemas or create one in the project’s schema location.
• Validate required fields.
• Validate types, formats, ranges, lengths, and enums.
• Validate nested objects and arrays.
• Validate query params and route params.
• Normalize safe values where the project does this.
• Strip or reject unknown fields.
• Return structured field errors when supported.
• Add or update relevant tests.

Security Rules

• Never trust client validation alone.
• Prevent injection by using safe query builders or parameterized queries.
• Validate sort fields and filter fields with allowlists.
• Validate file metadata and upload constraints separately.
• Sanitize only when appropriate; do not mutate meaning unexpectedly.
• Escape on output where the UI/rendering layer requires it.
• Do not leak internal validation or parsing errors to users.

Error Rules

• Invalid input should fail before business logic runs.
• Keep validation messages safe and useful.
• Include field-level errors when the project supports them.
• Do not expose stack traces or raw parser errors.
• Keep response format consistent across endpoints/forms.

Tests

Cover relevant paths:

• valid input
• missing required fields
• invalid types
• invalid formats
• invalid enum values
• boundary min/max values
• unknown fields
• invalid query params
• invalid route params
• nested validation errors
• malicious or injection-like input