# Field Validation Errors

> Define or review field-level validation rules and the exact error messages a form/API should show, and generate the test cases that verify them. Always use this skill when asked to design validation rules, write error message copy, review whether validation is consistent, or test that a field correctly rejects bad input — even when phrased as "what should happen if a user enters X", "check our error messages for consistency", or "what validation does this field need". Distinct from test-data-generation (which produces sample values) and test-case-design (which covers a whole story) — use this one when the focus is specifically the validation rule and its error message.

- Skill: `santoshhundekar-qa/field-validation-errors` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add santoshhundekar-qa/field-validation-errors`
- Raw SKILL.md: https://api.skillmd.com/api/skills/santoshhundekar-qa/field-validation-errors/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: santoshhundekar-qa (https://skillmd.com/u/santoshhundekar-qa)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/santoshhundekar-qa/field-validation-errors

---


# Field Validation & Error Messages

Defines the validation rule, the exact user-facing error message, and the test cases that prove both are correct and consistent with the rest of the product.

## Process

1. **State the rule precisely** — type, required/optional, length/range, format (regex if relevant), allowed characters, uniqueness constraints, cross-field dependencies (e.g. "end date must be after start date").
2. **Write the error message to this standard**, unless the project has its own error-message style guide (check `references/message-style-guide.md` and defer to it if filled in):
   - States what's wrong, not just "invalid input"
   - Tells the user what to do, when possible ("Enter a date after the start date" not "Invalid date")
   - No technical jargon, stack traces, or internal field names exposed to the user
   - Consistent tone and punctuation with the rest of the product's error messages
   - Specific to the actual violated rule — a length error and a format error should read differently
3. **Check for consistency** — if the user is reviewing existing messages, flag cases where the same violation type is worded differently in different places (e.g. "Email is required" vs "Please enter an email" for the same rule elsewhere).
4. **Generate the verifying test cases** — one per distinct violation of the rule (missing, too short, too long, wrong format, duplicate/not-unique, cross-field violation), each checking both that the error triggers and that the exact expected message appears.

## Output format

```
Field: [field name]
Rule: [precise validation rule]
Error Message: "[exact user-facing text]"
Trigger Conditions: [what input(s) produce this exact message]
```

Followed by test cases in this project's standard test-case-design format (10-column Qase format — see the `test-case-design` skill) with `type = Negative` and `type = UI` as applicable, one row per violation condition.

See `references/examples.md` for a worked example across several validation types.

## What not to do
- Don't write a generic "Invalid input" message when the specific problem is knowable — specificity is the entire point of this skill.
- Don't expose internal details (field IDs, backend error codes, stack traces) in user-facing text.
- Don't assume a style guide — check `references/message-style-guide.md` first, and ask if it's empty and the project clearly has an existing tone to match.