Home/Catalog/Growth
Growth — does it grow?
Brief 109

Forms & Validation Audit

Every form in the product — whether it asks the least, validates kindly, and recovers gracefully, or leaks users at the moment they try to give you something.

FORMS.md4 phases7 lenses~2.6k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: judge every form that stands between a user and what they want — signup, checkout, settings, creation — and find where field count, harsh validation, or lost input make people give up.

Read-only pass. Fill out the forms, read their validation code; change nothing but the report file.

What it looks for

7 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Field economy

every field justified; the ones to cut, defer, or infer

2

Inline validation

errors shown at the right moment (on blur or submit, not every keystroke), near the field

3

Error recovery

input preserved on failure; clear, specific messages; nothing retyped

4

Input ergonomics

right input types, autofill, sensible defaults, formatting help

5

Progress & length

long forms broken into steps with progress; save-and-resume where it matters

6

Accessibility

labels tied to inputs, focus management, errors announced

7

Submission feedback

disabled while submitting, success confirmation, no double-submit

The deliverable

What lands in your repo

One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.

FORMS.md
1
Form scores
each significant form: field count, validation quality, recovery
2
Findings
each: form · field · the friction · the fix
3
Cuts
the fields to remove, defer, or infer, highest-leverage first
4
Priority
the fixes on the highest-traffic forms, ordered by drop-off risk
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Fill them out

Complete the product's important forms, including making mistakes on purpose.

2
Phase 2

Audit through 7 lenses

Cite the form and field for every finding.

3
Phase 3

Curate

Rank by drop-off risk.

4
Phase 4

Report

Create FORMS.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:forms-validation.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-forms-validation:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=109 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/109.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,646 characters)
# Goal: Forms & Validation Audit

You are working inside this repo. Mission: judge every form that stands between a user and what they want — signup, checkout, settings, creation — and find where field count, harsh validation, or lost input make people give up.

Read-only pass. Fill out the forms, read their validation code; change nothing but the report file.

## Phase 1 — Fill them out
- Complete the product's important forms, including making mistakes on purpose.
- Note every field, when errors appear, and what happens to your input on failure.
- Count the fields that are required versus the ones that could be optional, deferred, or inferred.

## Phase 2 — Audit through 7 lenses
Cite the form and field for every finding.
1. **Field economy** — every field justified; the ones to cut, defer, or infer
2. **Inline validation** — errors shown at the right moment (on blur or submit, not every keystroke), near the field
3. **Error recovery** — input preserved on failure; clear, specific messages; nothing retyped
4. **Input ergonomics** — right input types, autofill, sensible defaults, formatting help
5. **Progress & length** — long forms broken into steps with progress; save-and-resume where it matters
6. **Accessibility** — labels tied to inputs, focus management, errors announced
7. **Submission feedback** — disabled while submitting, success confirmation, no double-submit

## Phase 3 — Curate
- Rank by drop-off risk: friction on the signup or checkout form outranks a rarely used settings field.
- For each, name the fix — cut a field, fix the validation timing, preserve input.
- The best fix is often a shorter form; look to remove before you look to polish.

## Phase 4 — Report
Create `FORMS.md` at repo root:
1. **Form scores** — each significant form: field count, validation quality, recovery
2. **Findings** — each: form · field · the friction · the fix
3. **Cuts** — the fields to remove, defer, or infer, highest-leverage first
4. **Priority** — the fixes on the highest-traffic forms, ordered by drop-off risk

Start the report with today's date. If `FORMS.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- The shortest form that does the job wins; cut before you polish
- Never make a user retype what an error threw away
- No forms in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
- If a `reports/` directory exists at the repo root, write the report there instead of the root.
- Before asking, present the top findings as a ranked list in plain words
- Report only — end by asking which form fixes to make first

House rules for this Goal Prompt

  • The shortest form that does the job wins; cut before you polish
  • Never make a user retype what an error threw away
  • No forms in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding.
  • If a reports/ directory exists at the repo root, write the report there instead of the root.
  • Before asking, present the top findings as a ranked list in plain words
  • Report only — end by asking which form fixes to make first
Keep exploring

More Growth briefs