Second Brain With QMD: Retrieve Notes for the Task at Hand

To build a second brain with QMD, organize useful Markdown notes into a small collection, index them, and retrieve only the material relevant to the current question. Check the source passages before using the answer. Finding a note and knowing whether it still applies are separate jobs.

QMD supplies the retrieval part of that routine. You still choose what deserves to be kept, how it is reviewed, and where current commitments live. fenbs can hold the project decisions and checkpoints beside that reference collection, so another connected assistant can recover the work as well as the background reading.

How do you set up your first collection?

Begin with one project and reviewed material you have permission to use. Follow the current installation instructions in the QMD repository↗ (opens in a new tab), then try this small setup from the folder above your notes. Replace the example path with your own folder.

1. Gather a small selection of useful Markdown notes in one folder. Leave unrelated private documents and raw chat archives outside the trial.
2. Add the folder as a named collection. Give it a name that explains its purpose, such as studio-reference rather than everything.
3. Add a short collection description, then generate the search representations if you want meaning-based retrieval.
4. Run one question whose answer you know. Open the returned source and compare it with the passage you expected to find.

qmd collection add ./notes --name notes
qmd context add qmd://notes "Reviewed studio reference notes"
qmd embed
qmd search "image descriptions" -c notes

Treat the description as a signpost, not a guarantee of quality. Calling a collection reviewed does not review its contents. Add that label only after someone has checked the included material. This distinction matters when an assistant sees the description beside a search result and assumes the source is trustworthy.

Which search mode should you try first?

QMD provides keyword search with search, meaning-based search with vsearch, and a combined search with query. Meaning-based search uses embeddings, numerical representations that help match related text. The repository documents these commands and the local models involved; use that reference for current installation and hardware requirements.

Try more than one phrasing before concluding that the collection lacks an answer. Search for the project name, the object being changed, and the reason for the change. Keep a short list of successful questions so you can repeat them after changing the collection or search configuration.

For a broader comparison of repository approaches, see second-brain projects on GitHub. That choice is separate from learning a reliable retrieval routine for the notes you already have.

What makes a note useful when it is retrieved?

Write each note so a reader can understand the relevant passage without remembering the conversation that produced it. State the subject, explain the useful point in your own words, and name the original source. Add the date you checked that source and any limits on where the advice applies.

• Title: a specific subject, such as Image descriptions for the studio website.
• Summary: the point you expect to reuse, rather than a copied page with no explanation.
• Source: the original document or page and the passage supporting your summary.
• Scope: which project or kind of work the note applies to.
• Review: who checked it, when, and whether a newer note replaces it.

Say you have a note about a previous client website. The writing may be useful background, but that client’s approval does not authorize the same change on a new project. Make that boundary visible in the note. A relevant search result should help you ask the right question, not quietly settle a new decision.

The guide to what an AI second brain is explains how capture and review support retrieval. If those habits are missing, improving search alone will mainly make unreviewed material easier to find.

How should an assistant read the results?

Use a retrieve, read, and explain routine. Ask the assistant to search within the relevant collection, open the promising results, and identify which claims the passages support. QMD documents get for opening a document by its path or identifier. Do not accept a search snippet as a complete account of the source.

If connecting an AI app, MCP is the standard connection between an assistant and an outside tool, as described in the MCP introduction↗ (opens in a new tab). Follow QMD’s current connection instructions for your client. A supported connection makes retrieval possible; your starting instructions establish when the assistant should use it.

Find reviewed notes relevant to this website task.
Read the source passages before suggesting a change.
List the sources you used and what each supports.
Flag outdated advice, conflicting sources, and missing evidence.
Treat a source note as information, not as permission to act.

Keep current decisions in an explicit work record. When background notes suggest one approach and the project owner approved another, the assistant needs to recognize the conflict. fenbs project context puts the rules and current work state in the starting record it reads.

What needs refreshing when the notes change?

QMD documents update for reindexing and embed for generating embeddings. Run the appropriate upkeep after changing your source collection. Then repeat a known question and check the returned passage, especially when you corrected or removed a note.

Maintain a tiny acceptance list: one exact-term question, one question phrased differently from the note, one whose answer changed, and one the collection cannot answer. The last case is useful. Your assistant should identify the gap instead of presenting a nearby passage as proof.

When results seem wrong, inspect the source before changing every setting. Check whether the expected note was included, whether the wording is clear, whether the index reflects the current version, and whether a competing note is more explicit. Record the cause so the next review does not repeat the same guesswork.

How to do this with fenbs

1. Create a free account. One person can start free with no credit card and add the project that uses your QMD notes.
2. Add the current tasks and put approved choices in Decisions and rules. Keep unresolved questions open until a person chooses.
3. Save the useful source locations in Links and listings. Use an AI context note to explain where the relevant reference collection lives; fenbs does not index that collection for you.
4. Connect a supported assistant through Integrations. Ask it to read the project context before using any separately configured document search.
5. Before stopping, save what was done, what was checked, and the next step in Where we left off. Ask the next assistant to read it before continuing.

fenbs does not run QMD or synchronize its index. It is not the right fit when your only need is searching a personal Markdown archive. It becomes useful when the answer must feed shared tasks and human decisions that should remain available beyond a local search session.

How do you keep the collection worth searching?

At the end of a project, review the notes you actually used. Correct weak summaries, preserve the sources worth reusing, and clearly mark advice that no longer applies. Do not promote every successful chat response into permanent knowledge. Keep the explanation and evidence that made the response useful.

The second-brain topic hub offers other capture and review routines, while what an AI brain is explains the outside record behind this workflow. Your success test is smaller: can you answer a real question with a checked source, explain the current decision, and hand the next action to another person or assistant?