Replit Agent prompt to add a search feature
Search is easy to demo and hard to get right, so this prompt spells out the failure points: debounce races, unescaped wildcards, and full-table scans. Replit Agent adds a search endpoint and a keyboard-friendly dropdown to your existing app, then verifies matches against seeded rows before you touch it.
Last updated
Retrofit search into the existing codebase: users need to find {{resource}} records stored in {{database}} by name or description.
Backend: GET /api/search?q= returning up to 20 matches with the matched field named in each result. Matching is case-insensitive: prefix match on the name field plus substring match on description. Escape % and _ in user input so wildcards cannot be injected. If {{database}} is Postgres, use ILIKE backed by a trigram index (or tsvector if you argue it fits better), never load the whole table into application memory. Queries under two characters return an empty result without touching the database.
Frontend: a search input in the header, debounced at 300ms. A dropdown shows the top matches with arrow-key navigation, enter to open, escape to close. Submitting jumps to a full results page at /search?q= with the same matching rules.
Race handling: tag each request with an incrementing id and discard responses that arrive out of order, so fast typing never renders stale results. Abort the in-flight request when a newer one starts.
States: no matches shows the query echoed back with a suggestion to broaden it. A failed search request shows a retry link in the dropdown, not a silent empty list.
Verify: seed rows where a term appears only in the name, only in the description, and not at all. Run all three searches plus one containing %, paste the JSON responses, and confirm keyboard navigation works in the webview. If you added an index, paste the query plan for one search to show it is being used.Customize it
Runs in your browser. Nothing you type here is sent anywhere.
Retrofit search into the existing codebase: users need to find users records stored in PostgreSQL by name or description. Backend: GET /api/search?q= returning up to 20 matches with the matched field named in each result. Matching is case-insensitive: prefix match on the name field plus substring match on description. Escape % and _ in user input so wildcards cannot be injected. If PostgreSQL is Postgres, use ILIKE backed by a trigram index (or tsvector if you argue it fits better), never load the whole table into application memory. Queries under two characters return an empty result without touching the database. Frontend: a search input in the header, debounced at 300ms. A dropdown shows the top matches with arrow-key navigation, enter to open, escape to close. Submitting jumps to a full results page at /search?q= with the same matching rules. Race handling: tag each request with an incrementing id and discard responses that arrive out of order, so fast typing never renders stale results. Abort the in-flight request when a newer one starts. States: no matches shows the query echoed back with a suggestion to broaden it. A failed search request shows a retry link in the dropdown, not a silent empty list. Verify: seed rows where a term appears only in the name, only in the description, and not at all. Run all three searches plus one containing %, paste the JSON responses, and confirm keyboard navigation works in the webview. If you added an index, paste the query plan for one search to show it is being used.
Same task in other tools
Questions about this prompt
My table is tiny. Do I need the index instruction?
Under a few thousand rows, plain ILIKE is fine and the rest of the prompt still applies. Keep the line anyway if the table will grow, or drop it for a prototype; adding the index later is a single migration.
I still see stale results flash while typing fast.
That is the response race the prompt targets. Check that the agent implemented the incrementing request id comparison or aborts on newer input; if it skipped that paragraph, quote it back and ask for exactly that mechanism.
Can I extend this to search several record types at once?
Yes. Have the endpoint query each table, tag every result with a type field, and group the dropdown into sections. Request it after single-type search passes verification, so ranking problems stay easy to isolate per table.