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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
1---2name: shelf-find3description: Search the user's saved tool library before recommending or choosing any tool, library, service, vendor, or technique. USE THIS AGGRESSIVELY — the user rarely asks for it by name. Trigger on "what should I use for", "do I have anything saved about", "I need a tool that", "how do I approach", "any recommendations for", "is there something that does", "what's good for", "which library", "how should I build" — AND on any moment where the user is evaluating, comparing, or picking a tool/service/approach for a task, even with zero mention of saved links, notes, or a library. If the user is about to pick something, check here first. Under-triggering is the main failure mode; when in doubt, run it.4license: MIT5---67# shelf-find89Read-only search of the user's saved tool library.1011**This skill must never write anything.** No notes, no index, no inbox, no12config file. Read only.1314## Step 0 — find the library1516Read `~/.tool-library-path` (in the user's home directory). It holds one line:17the library folder. Call it `<LIB>`. Notes live in `<LIB>/notes/`.1819**If the file is missing**, the library was never set up. Say so, and tell the20user to run `shelf-save` to set it up. Do not create it here and do not guess a21path.2223## Run24251. **Restate the need in one line** — including constraints you inferred from26 the surrounding conversation, not just the literal question. Stage, budget,27 existing stack, language, self-host vs SaaS. Say what you inferred so the28 user can correct a wrong assumption before it skews the ranking.292. **Map to 2–3 likely categories** from: `dev-tool` `ai-agent` `marketing`30 `design` `data` `fundraising` `ops` `research` `reading` `other`.31 This is a starting set the user is free to edit; if they change it, the same32 list in `shelf-save` must match, or notes land under a category recall never33 looks for. The list guides the search — it doesn't limit what you may find.343. **Search the notes by content.** Plain text search, not vectors — the corpus35 is a few hundred small files. Use whatever search your harness gives you36 (`Grep` in Claude Code, `grep -r` in a shell, file search elsewhere).37 - by category: lines matching `^category: dev-tool`38 - by tag: lines matching `tags:.*email`39 - **the high-signal move** — dump every line matching `^problem_solved:`40 across all notes and scan them. Those lines are written as problems, which41 is the shape of the question. Usually the fastest path, and cheaper than42 guessing keywords.43 - Search **several phrasings**. The note was written months ago in different44 words than today's problem: literal term (`websocket`), problem shape45 (`realtime`, `push`, `subscription`), adjacent tech.464. **Read the top ~10 candidates in full.** Never report on search hits alone —47 a filename or tag match tells you nothing about whether the thing fits.485. **Return 3–5 ranked picks.** Each one:49 - Tool name + URL50 - **One line: why this fits *this specific situation*.** Not a description of51 the product — a connection to the constraints from step 1. If you can't52 write that line without being generic, the note doesn't belong in the list.53 - Pricing + maturity54 - One honest caveat556. **Close with the single strongest pick** and a one-sentence reason.5657## Guardrails — non-negotiable5859- **Nothing genuinely matches → say "Nothing in your library covers this."**60 Then offer a fresh web search as a clearly-labelled separate step the user61 opts into. Do not stretch a weak match to fill out the list. A library the62 user stops trusting is worse than no library — one bad recommendation costs63 more than ten honest misses.64- Fewer real hits beat more maybes. Two is a fine answer.65- **Flag `confidence: low` notes explicitly as unverified** — that note was66 built from a search result, not the actual page.67- **Never recommend something not in the library while implying it was saved.**68 If you add outside knowledge, label it clearly as not-from-the-library.69- Library is thin or empty → say that. "Nothing saved yet" and "nothing70 relevant" are different answers and the user needs to know which one they got.
Ranveersingh1113