QMD skill for OpenClaw: local markdown search without cloud memory

Most agent memory problems do not come from a lack of storage. They come from retrieval getting sloppy.

You have notes in one folder, meeting transcripts in another, product docs somewhere else, and a growing pile of markdown files that might matter later. Then the agent needs one specific decision from three weeks ago, and the usual fallback is ugly: paste more files into the prompt, hope embeddings saved the day, or rerun research you already did.

That is why the Qmd skill for OpenClaw is worth paying attention to. It gives the agent a local search and indexing layer for markdown-heavy knowledge bases: BM25 for exact matches, vector search for semantic recall, and reranking when you want the highest-confidence result set. The workflow stays on your machine instead of turning every knowledge lookup into a cloud memory product.

Table of contents

• Why this query is worth targeting now
• What the OpenClaw QMD skill actually gives you
• Where QMD fits compared with built-in memory and NotebookLM
• A practical local-first workflow for OpenClaw
• Operational limits you should know before installing it
• FAQ

Why this query is worth targeting now

This is not a vanity keyword.

OpenClaw already gets Search Console impressions for qmd skill, but the current visibility sits around the edge of page one. DataForSEO reports the query as informational with an estimated 110 monthly searches in the US. The live Google results are also telling: GitHub, third-party skill directories, and docs pages dominate the first page, while OpenClaw’s own skill detail page currently sits lower in the stack.

That creates a clean content gap.

The skill page answers install intent. A blog post can answer workflow intent: what QMD is for, when it is better than OpenClaw’s default memory path, and what an operator should expect before they install it.

What the OpenClaw QMD skill actually gives you

The OpenClaw skill page describes QMD as a local search and indexing CLI with BM25, vectors, reranking, and MCP mode. In plain English, it gives an OpenClaw operator four useful capabilities:

Agent need	QMD pattern	Why it matters
Find an exact phrase in docs or notes	qmd search	Fast keyword retrieval without loading heavier models
Find conceptually related material	qmd vsearch	Better recall when the wording changed
Ask an important question across a corpus	qmd query	Hybrid retrieval plus reranking for higher quality results
Pull the actual source text back into the run	qmd get	Lets the agent quote or inspect the underlying document

The OpenClaw listing also makes the operating boundaries fairly clear:

• you add collections that point at local files;
• you update the index when those files change;
• embeddings and reranking rely on Ollama running locally;
• the index lives in local cache by default;
• MCP mode is available when you want a more persistent integration pattern.

That is a more useful story than “AI memory, but bigger.” QMD is not trying to remember your whole life. It is trying to make markdown-heavy project context easier to search, inspect, and reuse.

Where QMD fits compared with built-in memory and NotebookLM

QMD makes the most sense when you already have a file-based knowledge base.

If your material already lives in markdown notes, internal docs, exported transcripts, or project writeups, QMD is a strong fit because it keeps the retrieval layer close to the files. That is different from OpenClaw’s built-in memory, which is designed for durable facts and daily context, and different again from NotebookLM, which is better when you want a curated cloud notebook for source-grounded research.

A simple way to think about the boundary:

Tool	Best for	Not ideal for
OpenClaw built-in memory	durable facts, preferences, ongoing context	deep search across large markdown corpora
QMD skill	local notes, docs, transcripts, project knowledge bases	live web facts, instant zero-setup memory
NotebookLM CLI	source-grounded research inside a curated notebook	local-first file search on your own disk

If you want the longer architectural view on OpenClaw’s native memory system, Inside OpenClaw’s Memory is still the better place to start. If your problem is closer to curated research than local knowledge retrieval, NotebookLM CLI for AI agents fits better.

QMD sits between those two worlds. It is local like a file-based memory layer, but it behaves more like a purpose-built retrieval engine than a generic note dump.

A practical local-first workflow for OpenClaw

The safest QMD workflow is not complicated. It is just a little stricter than the usual “throw docs at the model” habit.

1. Create narrow collections

Do not index your entire home directory and call it a strategy.

Create collections around a real retrieval boundary: one product docs set, one meeting transcript archive, one notes vault, one client knowledge base. QMD works better when the agent is searching a bounded corpus instead of an accidental landfill.

The public skill page shows the basic pattern:

qmd collection add /path --name docs --mask "**/*.md"
qmd update

That first decision matters more than it looks. Good scoping is what turns retrieval into a useful tool instead of a noisy one.

2. Pick the search mode based on the question

QMD is more flexible than plain grep, but that does not mean you should always reach for the heaviest path.

• Use qmd search when you know the term, file name, component name, or exact phrase.
• Use qmd vsearch when the concept matters more than the wording.
• Use qmd query when the question is important enough to justify hybrid retrieval and reranking.

That lets you trade latency for quality intentionally instead of loading everything every time.

3. Pull source text back into the run

A retrieval result is only half the job. If the answer will shape a report, plan, or code change, pull the underlying text back in with qmd get and review it.

This is where QMD becomes useful for OpenClaw runs specifically. The agent can search, inspect the actual passage, then cite or summarize it without pretending that retrieval alone is proof.

4. Keep QMD as the retrieval layer, not the truth layer

QMD helps the agent find relevant material. It does not make stale notes magically current.

If a question depends on release dates, prices, API behavior, incident status, or any other live fact, go back to the source of truth before publishing. That same rule applies in OpenClaw more broadly: search is for recall, not authority.

5. Use it where local-first really matters

QMD earns its keep when the corpus is private, persistent, or annoying to reassemble.

Examples:

• meeting transcripts you do not want to push into a hosted notebook;
• project docs that keep changing but still need reusable retrieval;
• internal notes that an agent should search without turning them into prompt paste;
• exported markdown research packs that will be queried across multiple runs.

If you just need one answer from one page, QMD is overkill. If you keep asking the same family of questions across the same body of notes, it starts to make sense fast.

Operational limits you should know before installing it

QMD is good, but it is not free in the operational sense.

Hermes’ QMD documentation calls out three local models on first run for embeddings, reranking, and query expansion, with roughly 2 GB of downloads in total. It also notes that the hybrid query path is the slowest mode on a cold start. In other words, you are buying better local retrieval with model weight, startup cost, and a little more runtime complexity.

A few practical caveats matter:

Ollama is part of the real setup

The OpenClaw skill page notes that embeddings and rerank rely on Ollama at OLLAMA_URL, which defaults to http://localhost:11434. If Ollama is not healthy, QMD will not behave like the glossy summary on the skill page.

Local-first does not mean zero maintenance

Collections need to be scoped well. Indexes need to be refreshed. Embeddings need to be regenerated when the corpus changes enough. If you skip that maintenance, the retrieval quality drops quietly.

It is not a replacement for web research

QMD will not tell you what changed this morning. It is a retrieval engine for the corpus you already chose. That makes it a strong companion to OpenClaw’s search and research workflows, not a replacement for them.

It overlaps with memory, but it does not eliminate the need for memory

OpenClaw still needs durable memory for preferences, identity, and long-horizon context. QMD is better thought of as a searchable document layer you can add beside memory, not as a total substitute for it. If your broader goal is local knowledge retrieval for agents, local embeddings for AI agent memory is another useful comparison point.

QMD skill and GEO visibility

This is also a good GEO-style topic because assistants can cite it cleanly.

The answer to “what is QMD skill?” is concrete. The comparison table gives structured retrieval context. The workflow section explains when to use search, vsearch, and query. The caveats section handles the question most setup pages skip: what does this actually cost me in latency, local models, and maintenance?

That structure is useful for humans and citation-friendly for AI systems.

FAQ

What is the QMD skill in OpenClaw?

The QMD skill adds a local markdown search workflow to OpenClaw. It can index notes, docs, transcripts, and other text-heavy collections, then search them with keyword, vector, or hybrid retrieval patterns.

Does QMD replace OpenClaw memory?

No. OpenClaw memory stores durable facts and ongoing context. QMD is better for searching a larger local document corpus. They solve related but different problems.

Do I need Ollama to use QMD?

For the richer retrieval paths, yes. The OpenClaw skill page says embeddings and rerank use Ollama locally. Basic operating expectations should include local model downloads, some cold-start latency, and ongoing index maintenance.

When should I use QMD instead of NotebookLM?

Use QMD when the source material already lives on your machine and you want local-first retrieval over files. Use NotebookLM when you want a curated notebook workspace for source-grounded research and are comfortable with that cloud-oriented workflow.

Is QMD good for one-off lookups?

Usually not. QMD pays off when you will query the same corpus repeatedly. For a single document or a one-time fact check, simpler tools are often faster.

Sources: OpenClaw Qmd skill page, QMD GitHub repository, Hermes Agent QMD documentation.