sxsphinxstack

Skills / Forms that work

Forms that work

Add a working contact or sign-up form to a static site. Free form backend, validation, spam basics, submissions landing somewhere known. Use when they say "add a contact form" or "collect sign-ups" on a site with no server.

Use this skill. Nothing to install.

Open in ChatGPT Open in Claude prefilled and ready; just hit send
for Gemini, Copilot, or Cursor: paste it, then say "use the forms that work skill"

Don't have an agent?  ·  Raw file: skills/forms-that-work.md

Watch the first two minutes

This is how a session goes, including the question that stops most people. Click through it.

(pastes the skill) I want a contact form on my site
Easy to add. One decision comes before any HTML: where should submissions land? Usually the answer is your own email inbox.
wait, my site is just HTML files. don't forms need a server?
Yours doesn't have one and won't need one. A free form backend receives the submission and forwards it to your email. Formspree's free tier is around 50 submissions a month; Web3Forms is free with just an access key. For a personal site, 50 a month is plenty.
what about spam bots filling it with junk
Two cheap defenses that are enough at this scale: the backend's own filtering stays on, and we add a honeypot, a hidden field humans never see and bots fill in. CAPTCHA waits until spam actually shows up, because it annoys real people too.
how many fields should I ask for
As few as you can defend. Name, email, message is usually the whole form; every field you drop removes friction and spam surface. Validation is the browser's job: required on mandatory fields, type="email" on the email one, no JavaScript needed.

Scripted example of a real session.

Don't forms need a server?

They need something to receive the submission, and that something can be someone else's server, free. A form backend gives you an endpoint URL; your plain HTML form posts to it; the submission lands in your inbox. Your site stays static, your host stays free, and the whole feature is a dozen lines of HTML. Pages where a working form is the whole point:

Order page for a home baker Commission page for your art Session booker for lessons

What you end up with

A form short enough to finish on a phone, wired so the browser does the nagging. This is the entire thing:

Example
<form action="https://forms.example/f/x8k2"  1
      method="POST">

  <label>Name
    <input name="name" required></label>     2
  <label>Email
    <input type="email" name="email"
           required></label>
  <label>Message
    <textarea name="message"
              required></textarea></label>

  <input type="text" name="_gotcha"
         class="hp-hidden">                   3

  <button>Send</button>                       4
</form>
  1. The action is the whole backend. The endpoint the backend gave you, and nothing else. Submissions forward to your address; the skill's rule is that they never route through anything the agent controls.
  2. Labels and browser validation. Every input wired to a label, which accessibility-pass would demand anyway, and required plus type="email" means empty or garbage input gets rejected before anything sends.
  3. The honeypot. Hidden from humans by CSS, irresistible to bots. The backend drops any submission where it is filled. Combined with the backend's own filtering, that is enough at this scale.
  4. After Send, something visible happens. A thanks message or redirect gets configured before the form ships, because nobody should stare at a blank page wondering whether it worked.

Questions people actually ask

Is the form backend free?

At personal-site volume, yes: Formspree's free tier is around 50 submissions a month, Web3Forms is free via an access key, and Netlify Forms includes around 100 a month if your site already deploys there. The skill has you check the current numbers on the provider's pricing page at setup, because tiers move.

Where do submissions actually go?

To your email address, set by you in the backend account you create yourself. That routing rule is explicit in the skill: the destination is yours, and submissions never pass through anything the agent controls.

Do I need JavaScript?

No. A plain HTML form with an action and method covers submission, and required plus type="email" covers validation. The browser handles the error messages in the visitor's own language, which JavaScript versions often get wrong.

What about spam?

The honeypot plus the backend's filtering handles a personal site's spam load. If junk still gets through months later, every backend on the list supports adding CAPTCHA then, when it has earned its annoyance.

What if I outgrow 50 submissions a month?

First, congratulations, because for a contact form that is a lot of real interest. The options at that point: the backend's paid tier, a second free backend for a second form, or if the form is becoming an actual product, build-web-app is the next skill up.

Where to go from here

Form live and tested from a phone? Keep building on the site:

Accessibility pass See who visits Grow it into an app
Curious? Read the full skill — the exact instructions your agent gets
---
name: forms-that-work
category: web
description: Add a working contact or sign-up form to a static site. Free form backend, validation, spam basics, submissions landing somewhere known. Use when they say "add a contact form" or "collect sign-ups" on a site with no server.
---

# forms-that-work

Add a form to a static site — no server, so a free form
backend receives the submissions and forwards them, usually to the
person's email. Decide together where submissions should land before
writing any HTML; everything else follows from that.

## Picking a backend

Compare a small set of current providers such as Formspree, Web3Forms,
or the site's existing host. Read each provider's official pricing,
submission limits, spam controls, retention policy, and data-handling
terms during setup; plans and limits change. Choose the smallest service
that routes submissions to an account the person controls without requiring
a payment card. Record the chosen plan and limit in the README.

## Building it

1. They create the backend account with their own email. The form's
   destination address is theirs — never route submissions through
   anything you control.
   Tell them what information the provider stores and for how long before
   collecting any personal data.
2. Write a plain HTML form: `action` pointing at the backend
   endpoint, `method="POST"`, and only the fields they actually need.
   Name, email, message is usually the whole form. Every field they
   drop is spam surface and friction removed.
3. Validation in HTML before any JS: `required` on mandatory fields,
   `type="email"` on email. The browser then does the nagging. A
   `<label>` wired to each input — accessibility-pass will demand
   this anyway.
4. Spam basics: add the backend's honeypot field (a hidden input
   bots fill and humans never see) and leave the backend's own
   filtering on. That is enough at this scale. If spam still gets
   through months later, the backends all support CAPTCHA — add it
   then, when it earns its annoyance.
5. Success and failure: configure the post-submit redirect or thanks
   message so a submitter knows it worked. Nobody should stare at a
   blank page wondering.

## Done

- A real test submission, sent from the live site on a phone,
  arrived where they expect submissions to live
- Empty and garbage input rejected by the browser before sending
- They know the free tier's monthly limit and what fills their inbox
  when someone writes
- The thanks state exists and they have seen it

If the form is the start of something interactive, build-web-app is
the next skill up.