react-hook-form-audit

Files (8)

• SKILL.md
• actions-boundary.md · references/
• adapters-and-accessibility.md · references/
• checks.md · references/
• field-arrays.md · references/
• server-data-and-lifecycle.md · references/
• version-8.md · references/
• wizards-and-conditionals.md · references/

SKILL.md (first lines)

# 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

Choose scope from the request before inventorying files. For a targeted bug or change review,
include the requested or changed forms and follow their components, schemas, defaults, serializers,
mutations, and tests. Inventory every RHF form only for an explicit repository-wide audit. Read
project guidance and detect the installed RHF, React, resolver, schema, UI-library, data-fetching,
and framework versions.

Completion: the scope is explicit, and every included form 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 bundled mirror of the build skill's canonical
branch reference when the audited form uses that branch:

- `references/server-data-and-lifecycle.md`
- `references/adapters-and-accessibility.md`
- `references/wizards-and-conditionals.md`
- `references/field-arrays.md`
- `references/version-8.md`
- `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:

```text
[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.

From kriscard/Skills, MIT.

More from kriscard/Skills