The product's own search — whether users can find what they are looking for: relevance, recall, forgiveness, and what happens on zero results.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge the product's built-in search as a user experiences it — can they find what they came for, is the best result first, and does the product help when nothing matches. This is the in-product find feature, not SEO.
Read-only pass. Run real queries against the product, read the search and indexing code; change nothing but the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
do the best matches rank first, or is ordering arbitrary
is everything findable that should be; fields or content missing from the index
typos, synonyms, partial matches, case and accent folding
a helpful path forward versus a blank dead end
responsiveness, as-you-type feedback, a loading state
useful facets to refine a broad query
multi-word queries, phrases, and intent, not just substring match
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Run a set of realistic queries.
Cite the query and result for every finding.
Rank by how often the query type is used and how badly it fails.
Create SEARCH.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:in-app-search.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-in-app-search:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=107 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/107.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: In-App Search Audit You are working inside this repo. Mission: judge the product's built-in search as a user experiences it — can they find what they came for, is the best result first, and does the product help when nothing matches. This is the in-product find feature, not SEO. Read-only pass. Run real queries against the product, read the search and indexing code; change nothing but the report file. ## Phase 1 — Search like a user - Run a set of realistic queries: exact, partial, misspelled, multi-word, and ones that should return nothing. - Note what comes back, in what order, and how fast. - Find what is indexed and what is silently unsearchable. ## Phase 2 — Audit through 7 lenses Cite the query and result for every finding. 1. **Relevance** — do the best matches rank first, or is ordering arbitrary 2. **Recall & coverage** — is everything findable that should be; fields or content missing from the index 3. **Forgiveness** — typos, synonyms, partial matches, case and accent folding 4. **Zero-result states** — a helpful path forward versus a blank dead end 5. **Speed & feedback** — responsiveness, as-you-type feedback, a loading state 6. **Filters & scoping** — useful facets to refine a broad query 7. **Query understanding** — multi-word queries, phrases, and intent, not just substring match ## Phase 3 — Curate - Rank by how often the query type is used and how badly it fails. - For each, name the fix — index a field, add synonyms, fix ranking, design the empty state. - Separate "wrong results" from "no results handling"; both lose the user. ## Phase 4 — Report Create `SEARCH.md` at repo root: 1. **Query runs** — the test queries, what they returned, and the verdict on each 2. **Findings** — each: lens · query · what failed · the fix 3. **Recall gaps** — the content that should be findable and is not 4. **Zero-result design** — what the product should offer when nothing matches Start the report with today's date. If `SEARCH.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Judge by real queries and their results, not by the search box's looks - A confident wrong result is worse than an honest empty state - No in-app search in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which search fixes to make first
reports/ directory exists at the repo root, write the report there instead of the root.The flagship. Understand the whole product, then surface prioritized opportunities across UI, UX, retention, engagement, community, and beauty.
How user signal re-enters the product — corrections captured or evaporating, thumbs nobody reads, and the complaint-to-fix path.
Every message the product sends out of the app — transactional email, push, in-app — for whether it is timely, wanted, clear, and controllable.
The whole arc of an account beyond signup — settings, export, plan changes, and deletion — and whether the product treats users with dignity, even leaving.