How do I install the Field Validation Errors skill?

Run npx skillmds@latest add santoshhundekar-qa/field-validation-errors in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Field Validation Errors safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Field Validation Errors?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Field Validation Errors free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Field Validation Errors?

santoshhundekar-qa (@santoshhundekar-qa) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Field Validation Errors by santoshhundekar-qa

Name: Field Validation Errors
Rating: 4.666666666666667 (3 reviews)
Author: santoshhundekar-qa

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.

File contents

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

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").
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
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).
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.

---name: field-validation-errorsdescription: 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.---# Field Validation & Error MessagesDefines 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.## Process1. **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 differently3. **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.

Frequently asked questions