Remix v2 Forms Code Review

Intent

this skill flags violations of Remix v2 form patterns in production code. use it when auditing form submission logic, mutation flows, upload handlers, and routing choices in a Remix v2 codebase. it assumes you have the canonical patterns doc (beagle-remix-v2:remix-v2-forms) available for reference and focuses solely on catching violations: manual fetch() calls instead of route actions, native <form> elements where <Form> is required, wrong useNavigation vs useFetcher choice, missing pending state derivation, unbounded upload handlers, unvalidated FormData, and multi-action route sprawl instead of the intent pattern.

Inputs

• codebase location (repo path or directory) containing Remix v2 route modules and components
• route file (e.g. routes/items.$id.jsx) with an action export and form component(s)
• component file (e.g. components/ItemForm.jsx) rendering <Form>, <fetcher.Form>, or fetch() calls
• upload handler context if the route calls unstable_createMemoryUploadHandler or parseMultipartFormData
• external reference docs: references/form-vs-fetcher.md, references/pending-state.md, references/uploads-validation.md, references/multi-action-routes.md
• import source verification: ability to trace Form, useFetcher, useNavigation, useSubmit to @remix-run/react (not native DOM or external HTTP libraries)

Procedure

1. scan for manual HTTP calls in the target component or route action. look for fetch(), axios, fetch-polyfill, or similar in POST/PATCH/PUT/DELETE paths. record file path, line number, and the actual call syntax.

2. identify all form elements in the component. for each form, verify the import: <Form> must come from @remix-run/react, not the native HTML namespace. if the form has method="post" (explicit or implicit) and the route has an action, flag any native <form> tag.

3. check <Form> vs useFetcher() choice against the rule: use <Form> + redirect() when the URL should change (create, delete-then-list). use <fetcher.Form> when the URL stays the same (row toggle, inline edit, bulk action). record the form's action prop or lack thereof, the expected route destination, and the presence/absence of a redirect in the action.

4. verify pending state derivation for each POST form. scan the component for useNavigation() or per-row fetcher.state reads. confirm pending state is NOT derived from useState flags or manually tracked booleans. if a form is POST and the component has no pending state logic, record this.

5. check per-row mutation isolation for lists or tables with per-row actions (edit, delete, toggle). confirm each row uses its own useFetcher() instance and wires pending to that fetcher's .state, not the global useNavigation(). flag any row using useNavigation() without an explicit formAction filter.

6. validate pending state reads. if the component reads useNavigation(), confirm it checks navigation.formAction to scope to the expected route or confirm the component has no other navigation surfaces (links, sibling forms). if the component uses fetcher.state, confirm it is scoped to a specific formAction or intent.

7. scan upload forms for encType="multipart/form-data". flag any form that accepts file input without this attribute. if the route calls unstable_createMemoryUploadHandler, confirm it has maxPartSize set and that the handler is bounded. record the handler call and the maxPartSize value or its absence.

8. review FormData parsing in the action. trace form.get(key), form.getAll(key), and any unvalidated casts like form.get('id') as string. flag casts without prior schema validation or type coercion. confirm values are validated before being passed to the database.

9. audit multi-action routes for intent-pattern compliance. if a single route handles multiple mutations (create, update, delete on the same resource), confirm the action reads an intent field from the form and branches on it. if separate routes exist for the same resource type, verify they are not collapsible. record the route path, the action function signature, and the intent field name or its absence.

10. verify method declarations for non-GET forms. if the form uses method="put", "patch", or "delete", confirm progressive enhancement is documented in scope. flag PUT/DELETE forms without a POST + intent fallback if the surface is public or mobile-friendly. record the method, the route path, and any PE documentation.

11. check submit button presence on multi-action forms. for forms with an intent field or multiple mutations, confirm there is at least one real <button type="submit"> (not a <Link> or click handler). this ensures progressive enhancement works when JS fails.

12. validate optimistic UI logic if the component reads fetcher.formData or navigation.formData. confirm it reads directly from the form submission object, not from a mirrored useState state. flag any component that shadows formData into state and then renders from the state copy.

Decision Points

if the form is GET and the route has no action (it only has a loader), then the form is a search/filter surface and triggers the loader with URL params. do not apply POST form rules (intent, redirect, encType, pending state) to GET forms.

if the form is POST but the component has no useNavigation() or fetcher.state read, then flag missing pending state only if the component is interactive (has disabled buttons, spinners, or loading text that should change during submission). internal tools or static forms do not require pending state.

if the component reads useNavigation() without a formAction filter but the page has no other navigation surfaces (no sidebar links, no sibling forms), then the global useNavigation() is safe and does not need filtering. flag only when false positives are unavoidable (e.g. link navigation and form submission on the same page).

if a route has separate actions for create, update, and delete (e.g. routes/items.new.jsx, routes/items.$id.jsx, routes/items.$id.delete.jsx), this is legitimate route design. do not flag as "missing intent pattern" unless the mutations operate on the same resource with compatible auth and the surface would benefit from consolidation (e.g. an admin panel with one form for all three operations).

if the form uses navigate={false}, it is equivalent to <fetcher.Form> without holding a fetcher ref. do not flag this as a primitive choice error.

if the action returns json({ ok: true }) after a create or update, flag this only if the surface is a dedicated creation page (e.g. /items/new) and should redirect on success. same-page edit forms (edit-in-line, modal overlays) legitimately return JSON and stay on the same URL.

if unstable_createMemoryUploadHandler is called with maxPartSize set to a large value (e.g. 500MB), verify the upload surface is intended for admin uploads or internal tools. user-facing uploads should have lower bounds (5-50MB) and may need a disk or stream handler instead.

if FormData parsing uses form.get(key) as string without prior validation, flag this as a coercion without schema. if the code calls schema.parse(form.get(key)) or uses parseFormData, do not flag.

Output Contract

report each violation with:

• file path (e.g. routes/items.$id.jsx or components/ItemForm.jsx)
• line range or verbatim quote (e.g. lines 45-50 or the exact fetch(...) call)
• issue type (e.g. "manual fetch() instead of route action", "native <form> instead of <Form>", "missing pending state", "unbounded upload handler")
• rule reference (e.g. "violates form-vs-fetcher.md" or "missing encType on file upload form")
• remediation (brief rewrite suggestion or pointer to canonical pattern)
• severity (critical for missing action/security, high for wrong primitive, medium for missing pending, low for style)

findings are formatted as a list of structured objects or a markdown table, depending on the review output format. each finding includes a brief justification (one line) stating why the context-sensitive rule applies and the issue is not a false positive.

Outcome Signal

the skill succeeds when:

• every manual fetch() call in POST/PATCH/PUT/DELETE paths is identified and flagged with the route it should have used instead
• every native <form> with method="post" on a route with an action is flagged and marked for replacement with <Form>
• every useFetcher used for navigation (with expectation that URL changes) is flagged as wrong primitive choice
• every <Form> for row or in-page mutations (where URL should not change) is flagged as wrong primitive choice
• every POST form without useNavigation() or fetcher.state reads is flagged for missing pending state
• every file-upload form without encType="multipart/form-data" is flagged
• every unbounded unstable_createMemoryUploadHandler call (without maxPartSize) on a user-facing upload is flagged
• every FormData parse without prior validation or schema is flagged
• every multi-action route without an intent field is flagged (if intent pattern is in scope)
• every PUT/DELETE form without progressive enhancement documentation is flagged (if PE is in scope)
• no valid patterns are incorrectly flagged (e.g. GET forms, <Form> without action, multiple useFetcher instances, navigate={false}, aliased imports)
• the hard gates (location evidence, exemption check, form-method check, protocol completion) are all passed before findings are submitted

user knows the review succeeded when a markdown report or JSON listing is produced with clear, actionable findings. each finding cites a specific line or quote, states the rule violated, and suggests a canonical fix.