/query-memory
Recall what is already known — your own prior reasoning, the swarm's shared findings (including dead ends and verifier feedback), and the verified facts — before doing new work. Use when prior conclusions, examples, dead branches, verification outcomes, or verified results may
$ npx -y skills add frenzymath/Danus --skill query-memory --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/query-memory
Context preview
The summary Claude sees to decide when to auto-load this skill.
Recall what is already known — your own prior reasoning, the swarm's shared findings (including dead ends and verifier feedback), and the verified facts — before doing new work. Use when prior conclusions, examples, dead branches, verification outcomes, or verified results may
SKILL.md
query-memory.SKILL.mdname: query-memory
description: Recall what is already known — your own prior reasoning, the swarm's shared findings (including dead ends and verifier feedback), and the verified facts — before doing new work. Use when prior conclusions, examples, dead branches, verification outcomes, or verified results may inform the current question, claim, subgoal, or branch decision.
Query Memory
Before spending effort, check what already exists. There are three places to look, in the three-memory model:
1. **Your own local memory** (private): read/grep `local_memory/notes.jsonl` and `events.jsonl` for your prior reasoning and what you already tried. 2. **Global memory** (shared findings): `gm_search(query, kinds=...)` over the swarm's findings. Especially useful kinds:
- `dead_end` / `obstacle` — paths that already died (skip them);
- `verification` — outcomes of others' `fact_submit` (learn from rejections);
- `conclusion` / `example` / `counterexample` / `plan` — others' results to build on.
You can also read the `global_memory/<kind>.jsonl` files directly. 3. **Fact graph** (verified truth): `fact_search(query)` (BM25 over the verified facts) to find results you can cite or that show your subgoal is already proved — it returns `{fact_id, statement}`; read the full proof from `fact_graph/facts/<fact_id>.md` on a relevant hit, and `fact_graph/glossary.json` to reuse the project's symbol definitions. A proof may build **only** on facts (cite a `fact_id`).
Procedure
1. Obey the current prompt's restrictions first. If it forbids a direction, file, or search, that overrides default recall. If it recommends specific results or directions, raise their priority. 2. Start with the cheapest relevant source: your own local memory for your context; `gm_search` for the swarm's findings; the fact graph for verified building blocks. 3. Prefer a narrow, targeted query (specific `kinds`, a sharp query string) over reading everything. 4. **Workspace boundary:** stay inside your own working directory and the shared project stores. Do not scan parent directories, other workers' private `local_memory/`, or other projects.
Retrieval priority
- A relevant **verified fact** (fact graph) is the strongest hit — you can build
on it directly by citing its `fact_id`.
- A sibling's **`dead_end`/`obstacle`** saves you from re-walking a dead path.
- A sibling's **`verification`** rejection tells you why a similar claim failed.
- A `conclusion`/`example`/`counterexample` is awareness — useful, but **never a
brick** (only facts are). Re-verify anything you intend to build on.
Output
Note what you recalled and how you used it in your local memory (`events`). Do not re-publish others' findings; just use them.
Tools
- `gm_search` (recall shared findings; BM25 over global memory)
- `fact_search` (recall verified facts; BM25 over the fact graph — novelty + citation lookup)
- local memory is read directly (no tool — read/grep the files); read a fact's full
proof from its `fact_graph/facts/<fact_id>.md` once `fact_search` surfaces it
Read more
name: query-memory description: Recall what is already known — your own prior reasoning, the swarm's shared findings (including dead ends and verifier feedback), and the verified facts — before doing new work. Use when prior conclusions, examples, dead branches, verification outcomes, or verified results may inform the current question, claim, subgoal, or branch decision.
Query Memory
Before spending effort, check what already exists. There are three places to look, in the three-memory model:
1. **Your own local memory** (private): read/grep `local_memory/notes.jsonl` and `events.jsonl` for your prior reasoning and what you already tried. 2. **Global memory** (shared findings): `gm_search(query, kinds=...)` over the swarm's findings. Especially useful kinds:
- `dead_end` / `obstacle` — paths that already died (skip them);
- `verification` — outcomes of others' `fact_submit` (learn from rejections);
- `conclusion` / `example` / `counterexample` / `plan` — others' results to build on.
You can also read the `global_memory/<kind>.jsonl` files directly. 3. **Fact graph** (verified truth): `fact_search(query)` (BM25 over the verified facts) to find results you can cite or that show your subgoal is already proved — it returns `{fact_id, statement}`; read the full proof from `fact_graph/facts/<fact_id>.md` on a relevant hit, and `fact_graph/glossary.json` to reuse the project's symbol definitions. A proof may build **only** on facts (cite a `fact_id`).
Procedure
1. Obey the current prompt's restrictions first. If it forbids a direction, file, or search, that overrides default recall. If it recommends specific results or directions, raise their priority. 2. Start with the cheapest relevant source: your own local memory for your context; `gm_search` for the swarm's findings; the fact graph for verified building blocks. 3. Prefer a narrow, targeted query (specific `kinds`, a sharp query string) over reading everything. 4. **Workspace boundary:** stay inside your own working directory and the shared project stores. Do not scan parent directories, other workers' private `local_memory/`, or other projects.
Retrieval priority
- A relevant **verified fact** (fact graph) is the strongest hit — you can build
on it directly by citing its `fact_id`.
- A sibling's **`dead_end`/`obstacle`** saves you from re-walking a dead path.
- A sibling's **`verification`** rejection tells you why a similar claim failed.
- A `conclusion`/`example`/`counterexample` is awareness — useful, but **never a
brick** (only facts are). Re-verify anything you intend to build on.
Output
Note what you recalled and how you used it in your local memory (`events`). Do not re-publish others' findings; just use them.
Tools
- `gm_search` (recall shared findings; BM25 over global memory)
- `fact_search` (recall verified facts; BM25 over the fact graph — novelty + citation lookup)
- local memory is read directly (no tool — read/grep the files); read a fact's full
proof from its `fact_graph/facts/<fact_id>.md` once `fact_search` surfaces it
Danus orchestrates mathematical reasoning agents with fact-graph memory. A main agent (Claude Code) steers a swarm of autonomous codex workers that prove; a cold-start verifier is the sole authority on correctness: a result becomes real only once it passes.
Other skills on danus.
- /consult
Consult a strong reasoning model for strategy — feed it the current elaboration, take its reply as the next master_guidance, and dispatch workers from it. This is the main agent's high-intelligence step (workers prove; the consult decomposes and steers). Runs over the gpt_pro
Open skill - /elaboration
Write a high-signal-to-noise mathematical progress synthesis of a project from the shared stores (global memory + fact graph), following a fixed verdict→routes→interfaces→dangers→bridges template and a strict honesty discipline. Use it each strategic cycle, right before the
Open skill - /human-summary
Write a human-readable mathematical progress report (compiled PDF) on a project for the operator / the mathematician who posed the problem. This is NOT `elaboration` (dense input for the strategy consult) and NOT the dashboard. Render from the fact graph's verified
Open skill - /initialize
First-run setup interview for a Danus deployment. Run it on the FIRST session, whenever runtime/.danus-initialized is absent or OPERATOR.md is still the blank template, or when the operator asks to set up / initialize / onboard / re-configure. It greets the operator, explains
Open skill - /write-paper
Turn a project's verified fact graph into a publishable LaTeX paper in a configurable house style — a standalone amsart .tex with a real bibliography, compiled to PDF. Use when a project's target theorem is established and the operator wants the paper, or asks to
Open skill - /check-referenced-statements
Validate externally referenced theorems by querying arXiv theorem search first and Codex's built-in web search second. Use when a markdown proof cites statements from external papers.
Open skill

