React Hook Form Audit

React Hook Form Audit

Audit evidence, not syntax in isolation. A pattern becomes a finding only when its consequence is visible from the code, installed version, or verified runtime behavior.

Process

1. Establish scope and versions

Read project guidance and detect installed RHF, React, resolver, schema, UI-library, data-fetching, and framework versions. Inventory every file that imports RHF directly and follow its form components, schemas, defaults, serializers, mutations, and tests.

Completion: every form in scope has an entry point and its supporting files accounted for.

2. Reconstruct each form contract

For each form, identify:

• form and payload types;
• create/edit and server-data ownership model;
• default-values and dirty baseline;
• native versus controlled adapters;
• validation and error paths;
• conditional, wizard, and field-array behavior;
• submission, success, failure, and reset lifecycle.

Completion: each submitted value can be traced from initialization through serialization.

3. Run the checks

Read references/checks.md completely. Load the build skill's branch reference when the audited form uses that branch:

• ../react-hook-form/references/server-data-and-lifecycle.md
• ../react-hook-form/references/adapters-and-accessibility.md
• ../react-hook-form/references/wizards-and-conditionals.md
• ../react-hook-form/references/field-arrays.md
• ../react-hook-form/references/version-8.md
• ../react-hook-form/references/actions-boundary.md

Completion: every applicable check and branch rule was evaluated against every in-scope form.

4. Validate findings

Use source and types to distinguish a defect from a heuristic smell. Run the project's TypeScript typecheck; do not modify source to make it pass. Tests are optional—run focused existing tests when they can prove or disprove a suspected behavior. Prefer silence over speculative findings.

Completion: each reported finding has a concrete consequence, file and line, smallest safe direction, and confidence; unrelated typecheck failures are separated.

5. Report

Order findings by user impact:

• Critical: data loss, invalid submission, inaccessible completion, or broken production flow.
• High: likely correctness/reliability failure in a common path.
• Medium: demonstrated performance, maintainability, or UX cost.
• Low: verified local issue with limited impact.

Use:

[Severity] Short title
File: path:line
Evidence: what the code does and the scenario that exposes it
Impact: concrete user or engineering consequence
Direction: smallest safe correction
Confidence: high | medium

Then list forms reviewed, typecheck command/result, tests run or skipped, and residual risks. If no findings survive validation, say so directly.

Hard boundaries

• Remain read-only; report files are allowed only when the user requests one.
• Do not label watch, Controller, useFormContext, missing defaults, onChange, or useActionState as defects without contextual evidence.
• Do not claim performance impact without identifying the subscription and rerender boundary or measuring it when measurement is feasible.
• Do not infer App Router client-boundary requirements in Pages Router or non-Next projects.