Four React AI Skills: Review a Search Form Without Guesswork

Begin with observable behavior

The four skills in this guide are instruction files for an assistant, rather than plugins that automatically inspect a running browser. Give them a small component, its intended behavior and evidence of the issue. Our owned scenario is a catalog search form where typing a query requests matching items. The requirements are that the latest query owns the result, a keyboard user can operate the form, a narrow screen keeps controls usable and a failed request has an understandable outcome. These are properties to verify, not reasons to promise a flawless interface or describe generated advice as a senior engineer's approval.

Write the stale-response example first

Suppose the user searches for ca and then cat. The cat request returns a notebook result before the earlier ca request returns a lamp. The interface should continue showing the result for cat. That simple event order is more useful context than telling an agent that the component feels buggy. Record both requests and the order of resolution using an owned test fixture, without making a real network call. A test that resolves every request in submission order would miss the problem. The example demonstrates response ownership; it does not establish that a particular cancellation strategy is the right choice for every component.

Use component review to inspect state ownership

The React Component Reviewer can organize questions about effects, state and rendering. Ask it to identify which request is allowed to update the visible result and what happens after unmounting or changing the query. Do not accept a memoization change solely because a list of performance suggestions mentions it. First reproduce the stale response, then inspect the smallest correction and rerun the event-order fixture. An unnecessary memo can hide the reasoning without addressing the bug. Where performance is the actual concern, use measurements from the component rather than inferring a speed improvement from the presence of a React hook.

Check names and keyboard actions in the real markup

The Accessibility Audit Helper can guide inspection of labels, focus and status text. In the search example, the visible Search catalog label should identify the input, and a keyboard user should be able to reach the submit action and read the result state. A placeholder alone is not a durable field name. After an error, the user should still be able to edit the query and retry. Inspect the rendered controls and keyboard flow; an assistant's statement that it added accessibility attributes is not proof that those attributes describe the right elements or convey the current state.

Use narrow layouts to expose concrete constraints

The Responsive Layout Reviewer can help examine widths, wrapping and overflow. Test an empty result, a long item label and an error sentence at a narrow viewport, as well as an ordinary desktop state. A screenshot of three short labels is weak evidence that a component handles an unusually long name. Check whether the input, clear action and submit control remain visible without covering the result. Keep intentional scrolling inside the appropriate region instead of masking overflow globally. This guide does not require replacing a working split-panel layout or changing a product's accepted design to satisfy a generic style preference.

Review the form as a sequence of states

Use the Form UX Optimizer to trace empty, submitting, success, no-results and failure states. For an empty query, decide whether the correct action is showing all items or requesting a meaningful term; the interface should communicate that choice. For a failed request, preserve a useful explanation and a path to retry instead of silently showing an old result as current. If controls are disabled during submission, check whether that prevents required cancellation or correction. The right behavior follows the actual task, so record the decision rather than treating every checklist suggestion as a mandatory rewrite.

Keep automated evidence and human observations separate

A controlled component test can show that a later response is not overwritten, an input has an accessible name or a local error is displayed. A browser check can show whether a control is clipped or focus is visible. Neither alone establishes complete accessibility, usability or provider reliability. Keep the test input, expected state and actual observation beside each proposed fix. A passed fixture with synthetic results is not a live API test. If an assistant cannot run a browser or a particular device is unavailable, list that missing evidence explicitly rather than presenting a successful compilation as a completed interaction review.

Load instructions according to your assistant

Read the linked skill and the current loading instructions for the assistant you actually use. Adding a file to a repository does not prove that every editor or agent discovered it, and copying a path from an example can be insufficient. Confirm the selected skill is in scope, then provide only the relevant component and constraints. Keep project-specific architecture rules and owner instructions intact. Ask for an explanation and a diff before allowing a broad refactor. This workflow leaves deployment, credentials and communication with other people under your existing authorization rules rather than granting those capabilities merely because a review skill exists.

Retain sources and review the smallest useful change

The source instructions are mirrored from SimplyUtils' OpenAgentSkills repository, with attribution and licensing on each resource page. The search-form scenario and event-order exercise are original guidance here; upstream source files are not rewritten by this article. Keep applicable notices when sharing those files, and avoid representing generated suggestions as credentialed professional findings. Send only project material you may share with the assistant and remove secrets or customer records. Finish with the observed bug, proposed correction, passing owned fixture and remaining manual checks. That record is more informative than a declaration that a component is now production-ready.

Try the tools from this guide

• JSON Formatter - Format and inspect JSON locally; optionally load a URL or request an AI repair draft
• JSONPath Tester - Test JSONPath expressions against JSON data and see matching results instantly
• JSON to TypeScript Converter - Generate quoted-key types from all observed JSON array items.