# Aie Web Forms

> Web Form Wiring

- Skill: `mrhinkle/aie-web-forms` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add mrhinkle/aie-web-forms`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrhinkle/aie-web-forms/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mrhinkle (https://skillmd.com/u/mrhinkle)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrhinkle/aie-web-forms

---


# Web Form Wiring

Turns a static form into a working one: submission goes somewhere, input is validated, spam is filtered, the form is accessible, and the user sees success or error feedback. Provider-agnostic — swap in whatever email/form/newsletter service the user already uses.

## Workflow

1. **Inventory the forms** — scan the HTML/JSX for `<form>` elements and fields. Identify each form's job (contact, inquiry/partnership, newsletter signup) and note missing `name`, `label`, or `required` attributes.
2. **Pick the delivery path** — confirm which provider the user wants. See `reference/providers.md` for common options and how each is wired. Three patterns cover almost everything:
   - **Server function + email API** (e.g., an email-sending API) — full control over validation and templates.
   - **Hosted form backend** (e.g., a form-to-email/webhook service) — set the form `action` to the provider endpoint; no server code.
   - **Embedded newsletter widget** (e.g., an email marketing platform) — drop in the provider's embed/iframe; the platform handles capture and consent.
3. **Wire the submission** — build the endpoint or point the form at the provider. See `reference/serverless-example.md` for a provider-agnostic server handler with validation, honeypot, and templated notifications.
4. **Add validation** — required-field and email/phone format checks on the client for fast feedback, re-validated on the server (client checks are a UX nicety, not security).
5. **Add spam protection** — a honeypot field (see below) at minimum; rate limiting on the endpoint for anything public.
6. **Make it accessible** — see `reference/accessibility.md`. Every input needs a real `<label>`; errors must be announced, not just colored.
7. **Add feedback states** — a loading state on the submit button, a success message, and an error message that tells the user what to do next.
8. **Document config** — list required environment variables in a `.env.example` and give host setup steps. Never commit real secrets.
9. **Test** — validation fires, honeypot rejects filled submissions, success and error paths both render, and a real submission is received end to end.

## Honeypot (minimum spam protection)

A hidden field bots fill and humans never see. Reject any submission where it's non-empty. Hide with CSS, not just `type="hidden"` (some bots skip hidden inputs), and mark it `aria-hidden` + `tabindex="-1"` so assistive tech and keyboard users skip it.

```html
<div style="position:absolute;left:-9999px" aria-hidden="true">
  <label>Leave this field empty
    <input type="text" name="company_website" tabindex="-1" autocomplete="off">
  </label>
</div>
```

```js
// server side
if (body.company_website) return respond(400, "Rejected");
```

## Validation essentials

- **Required**: reject empty required fields.
- **Email**: match a reasonable pattern (don't over-engineer the regex) and rely on the provider's bounce handling.
- **Phone**: optional, loose format check.
- Always re-check on the server — never trust the client.

## Output Format

When wiring: list the files created/changed, the env vars needed, the provider setup steps, and a test checklist.

When auditing existing forms, report findings by severity:
- **Critical** — form doesn't submit, submits nowhere, or ships a secret to the browser.
- **High** — no server-side validation, no spam protection, no error state shown to users.
- **Medium** — missing labels/accessible errors, no loading state, weak client validation.
- **Low** — copy/UX polish (button label, success wording).

## Reference

- `reference/providers.md` — common email, form-backend, and newsletter providers and how to wire each.
- `reference/serverless-example.md` — provider-agnostic server handler (validation + honeypot + templates + env vars).
- `reference/accessibility.md` — labels, error announcement, focus, and WCAG pointers.

## Standards

- MDN client-side form validation — https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation
- WCAG 2.2 (labels, errors, input purpose) — https://www.w3.org/WAI/WCAG22/quickref/
- OWASP input validation cheat sheet — https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html