Cortex Query — Search the Vault

Search the cortexes Obsidian vault using semantic search.

When to Run This Skill

Run it in exactly two cases:

1. The user explicitly asks. "查 cortex", "之前有記過嗎", "cortex 裡有沒有", "check my notes", "what did I write about X", or the /cortexes:query command. An explicit request is always sufficient on its own.
2. using-cortex routes the request here after one of its four concrete signals fired (explicit request, reference to prior work, a topic the SessionStart hook actually listed, or resuming a previous session). That skill owns the decision; this one owns the search.

Do not run it

• For general questions, or for fresh work with no prior-context signal.
• Because a question is difficult, technical, open-ended, or touches infrastructure or internal tooling. Difficulty is not a signal.
• When the user picked option 4 ("直接開始工作") from the SessionStart menu, skipped the menu, or said "don't check cortex" — that opt-out holds for the rest of the session until the user explicitly asks (case 1).
• When the conversation, the current repo, or the current turn already supplies the answer.

An unprompted search costs the user tokens and latency, and unrelated notes pollute the answer. When no case applies, answer directly and do not mention the vault.

Resolve Vault Path

Read ~/.cortex/config.json and take vault_path. If the file is missing or has no usable vault_path, tell the user to run /cortexes:genesis first.

Do not read CORTEX_VAULT_PATH here. Only the SessionStart injection script and the takeoff.sh helper honour it; the write side — the SessionEnd recorder, evolve, distill, broadcast — resolves the vault from config.json alone, and the BM25/vector indexes live at a single fixed ~/.cortex/ location regardless. Honouring it on the read side would split reads and writes across two vaults while both shared one index. config.json is the one source of truth until a real multi-vault design lands.

Search Strategy (Layered)

Layer 1: Vector Search (primary)

Use cortex-vec for semantic search:

cortex-vec search "<query>" --n 5

cortex-vec is installed as a CLI tool (from PyPI via uv tool install cortex-vec or pip — see the README's Quick Start; /cortexes:genesis offers the install when it is missing).

Context-aware filtering: If the current session is inside a git repo, detect the repo name and add --repo filter as default scope:

cortex-vec search "<query>" --repo <detected-repo> --n 5

--repo narrows the Projects/ partition only; cross-repo Notes/ always appear in results regardless of the filter, and a page listing several repos passes a filter naming any of them. Scoping therefore hides other repos' Projects/ pages, never the shared notes. All three retrieval streams (vector, BM25, wikilink graph) honour the filter.

The user can override this by saying "search all" or "search across everything".

Additional filters: Apply when the user specifies:

• --type note|project — filter by content type
• --category Nginx|Linux|... — filter by category

Reading the output: stdout holds only hits, one JSON line each; stderr lines prefixed cortex-vec: explain them. A line ending results are BM25-only (or vector-only) means recall is degraded: tell the user alongside the results. Exit 3 means the vault or index is not set up: relay the error's parenthesised fix to the user and stop searching.

Interpreting score:

score is the vector cosine similarity only — how close the query is to that page's embedding. It is not overall hybrid confidence: it says nothing about the BM25 or graph streams that also produced this result set, and it is not what ordered the list.

So read the number only as a band of semantic overlap, never as a verdict on relevance:

• > 0.80 — strong semantic overlap with the embedding
• 0.60–0.80 — moderate semantic overlap
• non-zero < 0.60 — little semantic overlap on the embedding, which is not by itself a verdict on whether the page answers the question. This band now means a measured low overlap even for a keyword or wikilink hit, not an unmeasured one
• 0.0 — ambiguous in the current CLI output; see below

Relevance follows the returned order, not the number. The list comes back already fused across every active stream, and reranked when --rerank is on, so its order is the retrieval system's own verdict. Judge each hit from that position plus the fields the CLI actually returns — title, category, tags, summary — and from exact lexical evidence where you have it. Layer 1 returns no excerpt; matched text comes from the Layer 2 grep supplement.

Never demote a high-ranked BM25 or graph result solely because its cosine is low or zero. Fusion routinely places such a hit above a higher-cosine one on purpose, and an exact match on an identifier, command or error string is usually the strongest evidence available even when the embedding scores it low. The number is comparable across hits — a hit that arrived through the keyword or wikilink stream is backfilled with its real cosine from the collection, so it is scored on the same scale as a vector hit — but a comparable number is still only the semantic band, not the verdict.

What 0.0 means. The backfill needs a live vector stream, so it does not remove the ambiguity, it narrows it. The CLI emits 0.0 when the vector stream is unavailable (no OPENAI_API_KEY, or vector retrieval switched off — the score is then missing for every non-vector hit), when the backfill query itself failed, and when an actual cosine is zero or rounds to zero at four decimal places. The implication runs one way only: a result with no vector score always prints 0.0, but a printed 0.0 does not tell you which of those produced it.

So 0.0 establishes none of the following: whether the document took part in the vector result stream, whether it exists in the vector index at all, or which retrieval mode produced the result set. Treat the vector evidence as unavailable or indeterminate, and rely on the returned order and the result fields instead.

Do not infer BM25-only mode from 0.0 alone. Say retrieval ran without a vector stream only when you know that independently — stderr carried the results are BM25-only line, the user has established that OPENAI_API_KEY is unset, or cortex-vec status reports no embedded entries. Otherwise present the results without asserting a mode.

Layer 2: Exact Match (supplement)

If Layer 1 returns no relevant results, if cortex-vec is unavailable, or if the user is searching for an exact string (command, config path, error message), search the text directly. Judge "no relevant results" from the returned hits and their order — never from the score column alone.

grep -ri "<query>" <vault_path>/Notes/ <vault_path>/Projects/

Use grep through Bash rather than the Grep tool: the vault normally lives outside the session's working directory, and the file tools are confined to the workspace, so the Grep tool cannot reach it. /cortexes:query pre-approves exactly this grep (and nothing else beyond cortex-vec and repo detection) for that reason.

If the grep is refused because the vault is outside the working directory, do not report the search as failed. Say precisely that: Layer 1 is unavailable and the fallback cannot reach the vault, and the fix is either to install cortex-vec (Layer 1 takes no path argument, so it is unaffected by the workspace boundary) or to add the vault to the session with /add-dir <vault_path>. Never imply the vault has no matching content when the search never ran.

Show matching files with brief excerpts.

Layer 3: Raw Search (archive, on request)

Only when the user specifically asks about recent sessions or raw data:

grep -ri "<query>" <vault_path>/Raw/

Show matches with date and repo context.

Response Format

Present results to the user:

Found N results for "<query>":

1. [score] Title (Type, Category/Repo)
   → one-line summary

2. [score] Title (Type, Category/Repo)
   → one-line summary

• Use wikilink format when referencing notes: [[note-name]]
• If multiple matches, list them and ask which one to read
• If user wants details → read the full file