Claude/ChatGPT Prompt to Build Type-Safe Forms with Validation

What this prompt does

This prompt directs the model to build a type-safe form that ships, not pseudocode. It centers on one idea: a single schema that defines both your TypeScript types and your validation rules, so types and runtime checks can never drift apart. From there it asks for a typed onSubmit that receives parsed, validated values with no any, accessible inline errors, explicit UI states, and server-error mapping back onto individual fields.

The variables make the output concrete. [form_purpose] (for example, user signup) tells the model which fields and rules to model. [form_library] and [schema_library] decide the actual API used — React Hook Form plus Zod produces a resolver-based component, while a different pairing changes the wiring. [framework] sets the surrounding conventions, like whether it is a Next.js client component. Because the schema is declared inline at the top, the whole file reads as a single source of truth.

When to use it

• You are building a form (signup, settings, checkout) and want types and validation from one schema
• You keep hitting bugs where the form type and the validation rules disagree
• You need accessible errors wired with aria-invalid and aria-describedby, not just red text
• Server validation errors must land on the right fields instead of a generic banner
• You want explicit loading, success, and error states with a correctly disabled submit button
• You want a starter test covering one valid and one invalid submission

Example output

You get two files: the form component with the schema declared inline at the top, and a short test file. The component shows a typed submit handler, field-level errors wired for screen readers, disabled-while-invalid-or-pending submit logic, and server errors mapped per field. The test exercises one happy path and one validation failure, so you have a runnable starting point rather than a snippet.

Pro tips

• Describe [form_purpose] with its real fields and constraints ("signup: email, password min 12, accept terms") so the schema is accurate, not placeholder
• Match [form_library] and [schema_library] to what you actually use; mixing in an unfamiliar pair makes the model guess at the resolver API
• Insist on the server-error mapping in deliverable 5 — a single "something went wrong" banner is the fastest way to frustrate users who fixed one field
• Keep the accessibility wiring (aria-invalid, aria-describedby); it is the part most hand-written forms skip
• If you need async checks like unique-email, ask the model to extend the schema rather than bolting on a separate validation path
• Treat the generated test as a seed — add cases for your trickiest fields once the shape is in place
• Keep the submit button disabled while the form is invalid or pending; it stops double-submits and makes the pending state honest
• When the schema grows, ask the model to split it into smaller composable schemas rather than one sprawling object that is hard to reuse