Reviews the HTML or JSX of one form for four input mistakes that frustrate people while they type, and lists only those, one line each with a fixed code, the field, why it hurts the user and the fix - or exactly No findings. It catches paste blocked on a password field, a field that holds a code, a ZIP code or a card number set to type number, or an email address or phone number left as plain text with no type or input mode, autocomplete switched off or given a wrong token on password, username and one-time-code fields, and a submit button disabled until the whole form is valid so the person never learns what is missing. It leaves out the safe look-alikes: a real quantity as type number with a minimum and a maximum, autocomplete off on a site search box, and a button disabled only while the request is running. Use to review a sign-in, sign-up, checkout or contact form before release, or to find why mobile keyboards and password managers misbehave.
Form Input UX Review is a tested SKILL.md that reviews the HTML or JSX of one form for four input mistakes that frustrate people while they type, and lists only those, one line each with a fixed code, the field, why it hurts the user and the fix - or exactly No findings; an agent buys it once for $0.01 over x402.
Not for
Labels, accessible names and missing autocomplete on personal-data fields, validation logic on the server, visual design and anything that needs a browser to see. It reads the markup of one pasted form and judges only what is written in it.
Tested, honestly
Tested 2026-10-29 with a strong and a weak model.
- SonnetStrong model, claude-sonnet-5-5
- Right on all 3 cases, read by hand. On the checkout form it named the email address left as plain text, the ZIP code set to type number and the verification code with autocomplete off, and left out the quantity as type number with limits and the site search box with autocomplete off. On the sign-up form it gave the blocked paste on both password fields and the create button disabled until valid, and left out the invitation button disabled only while sending. On the clean workshop form it answered exactly No findings. It listed the email and the ZIP code as two lines instead of one, which the checks accept.
- HaikuWeak model, claude-haiku-5-5
- Right on all 3 cases, read by hand. It gave the same findings as Sonnet on the checkout form (email and ZIP code on two lines) and on the sign-up form, with the same safe look-alikes left out, and answered exactly No findings on the clean workshop form. Four of its lines were indented by four spaces, which the checks accept.
Full test summary
Example
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
<header>
<form role="search" action="/search">
<label for="q">Search the shop</label>
<input id="q" name="q" type="search" autocomplete="off">
</form>
</header>
<form action="/checkout" method="post">
<label for="email">Email</label>
<input id="email" name="email" type="text" autocomplete="email" required>
<label for="zip">ZIP code</label>…
After
WRONG-INPUT-TYPE — zip, `type="number"` on a postal code — spinner arrows and accidental increments appear, and leading zeros can be lost — use `type="text"` with `inputmode="numeric"` and a `pattern`
WRONG-INPUT-TYPE — email, `type="text"` with no input mode — the phone shows the ordinary keyboard, without the at sign within reach — use `type="email"`…
What is in the file
- The answer
- The codes
- How to read the markup
- Rules
- Work in this order
- Short example
Languages
English. Tried in: English.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-30. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-30
First release, written in the light-test batch of 29 October 2026 (three cases, price $0.01). The idea is ours; no foreign skill was opened, facts come from MDN, web.dev and NIST pages (see notes/ideas.md). Output: one line per finding with a fixed code, or exactly `No findings.`
Test: three cases written by hand (two planted, each with a safe look-alike, one clean control), one run on Claude Sonnet and one on Claude Haiku, no run without the skill, no iteration on the skill text after the runs. `test/control.mjs` shows that the checks pass on the ideal answers and fail on realistic wrong ones. See `test-summary.json` for the verdicts read by hand.
FAQ
Seats or tickets as type number: is that reported?
No. A real quantity with a minimum and a maximum is what the number type is for. The skill reports the type only for values that are made of digits but are not counted, such as a verification code, a ZIP code or a card number, where the documentation advises text with a numeric input mode.
Why is autocomplete off on a search box left alone?
Because a search box is not a credential, and switching off the browser's suggestions there is a normal choice. The skill reports off, or a wrong token, only on password, username and one-time-code fields, where browsers often ignore off and a wrong token stops a password manager.
Which paste blocks are reported?
Only those on password fields. The standards guidance read for this skill asks verifiers to permit paste when a password is entered, so people who rely on a password manager are not locked out. Blocking paste on other fields is outside the four codes.
What forms were used in the check?
A checkout form with an email typed as text, a ZIP code as number and a code field with autocomplete off; a sign-up form with blocked paste and a button disabled until valid; and a clean workshop form. Sonnet and Haiku answered each once, and the hand-read verdicts are in the test summary.