Shelf find

shelf-find

Read-only search of the user's saved tool library.

This skill must never write anything. No notes, no index, no inbox, no config file. Read only.

Step 0 — find the library

Read ~/.tool-library-path (in the user's home directory). It holds one line: the library folder. Call it <LIB>. Notes live in <LIB>/notes/.

If the file is missing, the library was never set up. Say so, and tell the user to run shelf-save to set it up. Do not create it here and do not guess a path.

Run

1. Restate the need in one line — including constraints you inferred from the surrounding conversation, not just the literal question. Stage, budget, existing stack, language, self-host vs SaaS. Say what you inferred so the user can correct a wrong assumption before it skews the ranking.
2. Map to 2–3 likely categories from: dev-tool ai-agent marketing design data fundraising ops research reading other. This is a starting set the user is free to edit; if they change it, the same list in shelf-save must match, or notes land under a category recall never looks for. The list guides the search — it doesn't limit what you may find.
3. Search the notes by content. Plain text search, not vectors — the corpus is a few hundred small files. Use whatever search your harness gives you (Grep in Claude Code, grep -r in a shell, file search elsewhere).
   • by category: lines matching ^category: dev-tool
   • by tag: lines matching tags:.*email
   • the high-signal move — dump every line matching ^problem_solved: across all notes and scan them. Those lines are written as problems, which is the shape of the question. Usually the fastest path, and cheaper than guessing keywords.
   • Search several phrasings. The note was written months ago in different words than today's problem: literal term (websocket), problem shape (realtime, push, subscription), adjacent tech.
4. Read the top ~10 candidates in full. Never report on search hits alone — a filename or tag match tells you nothing about whether the thing fits.
5. Return 3–5 ranked picks. Each one:
   • Tool name + URL
   • One line: why this fits this specific situation. Not a description of the product — a connection to the constraints from step 1. If you can't write that line without being generic, the note doesn't belong in the list.
   • Pricing + maturity
   • One honest caveat
6. Close with the single strongest pick and a one-sentence reason.

Guardrails — non-negotiable

• Nothing genuinely matches → say "Nothing in your library covers this." Then offer a fresh web search as a clearly-labelled separate step the user opts into. Do not stretch a weak match to fill out the list. A library the user stops trusting is worse than no library — one bad recommendation costs more than ten honest misses.
• Fewer real hits beat more maybes. Two is a fine answer.
• Flag confidence: low notes explicitly as unverified — that note was built from a search result, not the actual page.
• Never recommend something not in the library while implying it was saved. If you add outside knowledge, label it clearly as not-from-the-library.
• Library is thin or empty → say that. "Nothing saved yet" and "nothing relevant" are different answers and the user needs to know which one they got.