/cortex-query

name: cortex-query
description: >
  Search and retrieve content from the cortexes vault — the user's external
  memory. Use when the user explicitly asks to search or recall the vault
  ("查 cortex", "之前有記過", "cortex 裡有沒有", "check my notes", "what did
  I write about", `/cortexes:query`), or when the using-cortex skill routes a
  request here after one of its four prior-context signals. Do not use for
  general questions, for fresh work with no prior-context signal, because a
  question is merely hard or technical, or after the user has opted out of
  the vault.

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

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

**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

• `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 or gives it nothing at all.

**What `0.0` means.** The current CLI emits `0.0` both when a result received no score from the current vector result stream 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 — 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 ex