Form Cro

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.codex/skills/a11y-audit

.codex/skills/ab-test-setup

.codex/skills/account-executive

.codex/skills/ad-creative

.codex/skills/aeo

Audit 0.4.1 · source sha 6e3fcbdbb5cf · 19 Oct 2026Report an issue or request a re-scan

• Publisherborghei GitHub userOwner of the repository this skill is read from
• Source folderborghei/Claude-Skills/business-growth/form-croThe exact folder we audited
• LicenceNOASSERTIONAs the repository states it
• Commit pinned for this verdict6e3fcbdbb5cfA new audit runs when the source changes
• Repository statusNot archivedLast push 12 days ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Form optimization for lead capture, contact, demo request, application, and checkout forms. Covers field-cost analysis, multi-step form design, validation UX, mobile optimization, and A/B testing frameworks.

---
name: form-cro
description: >
  Form optimization for lead capture, contact, demo request, application, and
  checkout forms. Covers field-cost analysis, multi-step form design, validation
  UX, mobile optimization, and A/B testing frameworks.
license: MIT + Commons Clause
metadata:
  version: 1.0.0
  author: borghei
  category: business-growth
  updated: 2026-03-31
  tags: [cro, forms, lead-capture, conversion-optimization, ux]
---
# Form CRO

Production-grade form optimization framework covering field-cost analysis, layout engineering, multi-step form architecture, validation UX patterns, mobile-specific optimization, and structured A/B test design. Applicable to lead capture, contact, demo request, application, survey, and checkout forms. For signup/registration flows, use signup-flow-cro.

---

## Table of Contents

- [Initial Assessment](#initial-assessment)
- [Field-Cost Analysis Framework](#field-cost-analysis-framework)
- [Multi-Step vs Single-Step Decision](#multi-step-vs-single-step-decision)
- [Field Design Patterns](#field-design-patterns)
- [Validation UX](#validation-ux)
- [CTA and Submit Button Optimization](#cta-and-submit-button-optimization)
- [Mobile Form Optimization](#mobile-form-optimization)
- [Trust and Context Elements](#trust-and-context-elements)
- [Form Type Playbooks](#form-type-playbooks)
- [A/B Test Framework](#ab-test-framework)
- [Metrics and Measurement](#metrics-and-measurement)
- [Output Artifacts](#output-artifacts)
- [Related Skills](#related-skills)

---

## Clarify First

Before optimizing the form, confirm these inputs. If any is unknown or vague, ASK — do not assume:

- [ ] **Form type** — lead capture, contact, demo, application, or checkout (sets the optimal field count and playbook)
- [ ] **Current fields + which are used in follow-up** — reveals which fields to cut or enrich (the core of field-cost analysis)
- [ ] **Current completion rate + where users abandon** — baseline and the specific friction point to target
- [ ] **Compliance requirements** — GDPR/HIPAA fields that cannot be removed (constrains the field reduction)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the audit.

## Initial Assessment

### Required Context

| Question | Why It Matters |
|----------|---------------|
| What type of form? (lead capture, contact, demo, application, checkout) | Different types have different optimal field counts |
| How many fields currently? | Establishes baseline friction level |
| What is the current completion rate? | Benchmark for improvement |
| Where do users abandon? (if field-level analytics exist) | Identifies the specific friction point |
| Mobile vs desktop split? | Mobile forms need separate optimization |
| What happens with submitted data? | Determines which fields are truly necessary |
| Which fields are actually used in follow-up? | Often reveals 30-50% of fields are never used |
| Any compliance requirements? (GDPR, HIPAA) | Constrains what can be removed |

---

## Field-Cost Analysis Framework

Every field has a cost measured in abandonment. The question is not "what data would be nice to have" but "what data is worth the conversion loss."

### Field Cost Matrix

| Field Type | Estimated Abandonment Cost | Justification Threshold |
|-----------|---------------------------|------------------------|
| Email | Baseline (near zero for gated content) | Always justified for lead forms |
| First name | +2-3% drop | Justified if personalization drives follow-up |
| Last name | +2-3% drop | Rarely justified for first touch |
| Phone number | +5-10% drop | Only if sales will call within 24 hours |
| Company name | +3-5% drop | Justified for B2B qualification |
| Company size | +3-5% drop | Justified only if routing decisions depend on it |
| Job title | +3-5% drop | Can often be enriched post-submission |
| Industry | +2-3% drop | Can often be enriched post-submission |
| Message/textarea | +5-8% drop | Justified for contact forms, not for lead capture |
| Budget | +8-12% drop | Only justified for high-intent demo/sales forms |
| Custom question | +3-5% per question | Must directly affect lead routing or qualification |

### The Enrichment Test

Before including any field, ask: **Can this be enriched after submission?**

| Field | Enrichable? | Method | Keep in Form? |
|-------|------------|--------|---------------|
| Company name | Yes (from email domain) | Clearbit, Apollo, manual lookup | Remove |
| Company size | Yes (from company name) | Enrichment API | Remove |
| Industry | Yes (from company name) | Enrichment API | Remove |
| Job title | Partially (from LinkedIn) | Manual enrichment | Remove unless critical for routing |
| Phone number | No | Must be provided | Keep only if sales calls immediately |
| Budget | No | Must be stated | Keep only for high-intent forms |

### Recommended Field Sets by Form Type

| Form Type | Minimum Fields | Optimal Fields | Maximum Fields |
|-----------|---------------|----------------|----------------|
| Newsletter signup | Email | Email | Email + First name |
| Content download | Email | Email + First name | Email + Name + Company |
| Contact form | Email + Message | Email + Name + Message | Email + Name + Subject + Message |
| Demo request | Email + Company | Email + Name + Company + Role | + Phone + Use case + Team size |
| Application form | Varies by requirement | -- | All required fields (justified individually) |

---

## Multi-Step vs Single-Step Decision

### Decision Criteria

| Factor | Single-Step | Multi-Step |
|--------|------------|------------|
| Total fields | < 5 fields | > 5 fields |
| Field complexity | Simple text inputs | Mix of dropdowns, checkboxes, conditional fields |
| User motivation | Low-commitment (newsletter, content) | High-commitment (demo, application) |
| Qualification need | No routing needed | Different paths based on answers |
| Mobile proportion | < 30% mobile | >

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/borghei/Claude-Skills
git -C Claude-Skills checkout 6e3fcbdbb5cf

Works in

1. 2026-10-19
   !CAUTION B 89 / 100

   first audit · source 6e3fcbdbb5cf

Questions about Form Cro

• github.com/borghei/Claude-Skills/tree/main/business-growth/form- — the audited source at commit 6e3fcbdbb5cf and every finding aboveObserved · 19 Oct 2026

Spotted something wrong? Report a correction · Methodology