# Inline validation and error recovery

> Use when people start a form, hit an error, and never come back to finish it.

## Fill in before running

- `{{FIELD_RULES}}`
- `{{CURRENT_ERROR_TEXT}}`
- `{{VALIDATION_TIMING}}`
- `{{PROBLEM_FIELDS}}`

## Prompt

```
You are reviewing how a form behaves when the visitor gets something wrong. You are not redesigning the form or cutting fields.

FIELDS AND THEIR VALIDATION RULES: {{FIELD_RULES}}
ERROR MESSAGES EXACTLY AS THEY APPEAR: {{CURRENT_ERROR_TEXT}}
WHEN VALIDATION FIRES (on submit, on blur, on keystroke): {{VALIDATION_TIMING}}
FIELDS WITH THE MOST ABANDONMENT IF KNOWN: {{PROBLEM_FIELDS}}

Output a table: Field | Rule | Current message quoted from {{CURRENT_ERROR_TEXT}} | What the visitor actually did wrong | Can they fix it from the message alone? (Yes/No) | Rewritten message | Better timing.

Then answer:
- Which rules in {{FIELD_RULES}} reject input that is genuinely valid: spaces in card and phone numbers, apostrophes and accents in names, plus addressing in email, addresses outside the assumed country. List each as a defect, not a copy problem.
- Which messages blame the visitor instead of describing the fix.
- Where {{VALIDATION_TIMING}} punishes someone mid-typing, and what it should be instead.
- What happens to data already entered when a submit fails, and whether focus and scroll return to the first error.

Finish by ranking {{PROBLEM_FIELDS}} by how likely error handling is the cause, and say plainly where abandonment is more likely to be the field itself.

Do not invent error text I have not supplied. No exclamation marks and no em dashes.
```

## Getting a better result

- Paste the messages verbatim, including the ones only a server response produces.
- Test with a real card number containing spaces and a name with an apostrophe before you accept the rules are fine.
- The rules marked as defects go to engineering, not to a copywriter.

---

From the QuQi prompt library - https://www.quqi.io/prompts/inline-validation-error-recovery