Storing Is Only Half the Job — Why I Added Search and Built a Query Skill
If the wiki has the answer, shouldn’t it be able to find it when asked?
Second Brain Series — Using It, Part 1
Collection was working.
Hermes was receiving Discord messages and piping them into the second wiki. CLI automation was running on top of that. Ideas thrown from my phone landed in the wiki. Session logs dropped into raw every evening. The intake side felt solved.
But retrieval wasn’t working.
“Where did I put this week’s plan?” — it was in the wiki somewhere, but Hermes couldn’t find it. “How did I set up that deployment again?” — I had to dig through files manually. The Discord channel had become a solid input, but there was no output. The archive existed, but there was no way back in. Half a second brain.
Getting the Chat to Search the Wiki
I plugged in Tavily. It’s a web search API built for agents — and it had a free monthly quota, so I figured I’d give it a shot. Drop an API key into .env and Hermes gains access to a search tool. Simple enough.
After that, Hermes could read the wiki and answer from it. The mechanism was straightforward: when a search request came in, it would read wiki/index.md first, find relevant pages, and drill down from there. The wiki’s summary-plus-index structure meant no embeddings or vector search were needed. If the index is well-maintained, the LLM can navigate it directly.
“A Chat That Also Collects Itself” — Complete
Once search was in, the channel changed character.
Before, it was one-directional — throw something in, it gets stored, end of story. Now I could ask questions. Throw something in and it stacks up. Ask something and it retrieves what’s been stacked.
“A chat that collects itself” — input and output sharing the same door. One Discord channel became both the intake point and the retrieval point for the knowledge base.
That’s when second started feeling like an actual second brain. The shift from “I have to go look” to “I can just ask” made a real difference in how it felt to use it.
But Only From Inside second
Almost satisfying.
The problem showed up whenever I was working in a different project workspace and needed something from second. Mid-myWiki session: “where did I decide on this deployment approach?” — it’s in second. Mid-trading_mvp session: “there was a KIS API regulation note somewhere” — it’s in second. Slowloop branding work: “what direction did we land on before?” — it’s in second.
But those sessions didn’t know about second.
Claude Code can’t see outside its current working directory by default. To reference the second wiki from a different project session, you could set additionalDirectories or pass --add-dir as a flag. I looked into it — there’s even a CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD environment variable from a certain version onward. But all of it required per-session setup.
Having to re-explain the wiki path every time you want to use it is just another explanation tax. The whole point of the wiki is to reduce re-explaining context — and here it was, requiring re-explanation to access.
The query Skill — One Word, Any Workspace
It was June 10th, 2026. I was in the middle of slowloop branding work.
I wanted to pull something from second. That’s when the idea came up: if we make second-querying into a skill, any project session can run /query "what I'm looking for" once and pull relevant content from the wiki. It’s a globally installed skill, so it works from any session without additionalDirectories. Hardcode the second wiki’s SSOT path inside the skill, and if the path ever changes, that’s the only place to update.
“Yeah just make it — /query should search from the second project”
That one sentence created ~/.claude/commands/query.md. A global command, ready in any project session from that point on.
I tested it immediately.
/query pull the blog draft listIt worked. From a myWiki session, from a trading_mvp session, from anywhere — second was accessible. Direct absolute path access, no configuration needed.
That became the pattern going forward. Something comes up in a project session — /query KIS API regulations, /query deployment playbook, /query slowloop lab requirements. Switch workspaces as much as you want; the wiki follows.
From Archive to Second Brain
When people build a second brain, they focus on collection. How do I capture more, more automatically?
But the real difference is on the retrieval side.
If the collection pipeline is one half, “how do I pull this out from wherever I’m working right now” is the other half. A wiki without search is just a warehouse. Without the query skill, second is just a place I have to actively open. The wiki only becomes part of how you work when you can ask it something from right where you are.
Both halves have to be there for it to be a second brain rather than an archive.
If you’ve built the collection, the next question is: how do you get it back out from wherever you’re working?