Markdown Knowledge Base: Structure Notes Your AI Can Reuse

A Markdown knowledge base is a collection of plain-text files organized so people and assistants can find a useful answer, its source, and its limits. Start with one index, one subject per file, and a clear owner for each answer. Markdown supplies headings, lists, and links; the accuracy comes from how you maintain the notes.

Tools like fenbs complement those documents with the decisions and progress a new session needs. Keep the longer explanations in your files and the current work record beside them. The context engineering hub covers the broader practice of giving an assistant the right starting information.

How do you set up the first folder?

1. Choose one real project and one shared folder. Write down which people can read and edit it before adding sensitive information.
2. Create an index file that names the project, explains what the collection covers, and links to a few useful starting pages.
3. Make a separate file for each repeatable question, such as preparing a design review or checking a delivery. Use filenames that describe the answer.
4. Add an owner, status, review date, and source to each file. Leave unanswered questions visibly open.
5. Ask someone unfamiliar with the folder to complete a small task using only its contents. Fix the missing explanation before adding more pages.

For a hypothetical design studio, the first files might be an index, a design-review checklist, approved terminology, and a handoff guide. A shallow folder is enough while those pages remain easy to scan. Add subfolders when readers repeatedly need to distinguish different projects or kinds of work, rather than building an elaborate directory before anyone uses it.

Use the basic syntax in the CommonMark reference↗ (opens in a new tab): headings for sections, lists for steps, and links for references. Avoid decorative formatting that carries information only through appearance. A plain-text reader should still understand the instruction when the rendered preview is unavailable.

What should each note file contain?

Give each file a direct answer before the background. A reader opening the design-review note should immediately learn what to prepare and how to tell whether the review is ready. Include the reason only where it helps someone make a judgment or recognize an exception.

# Prepare a design review

Audience: Project designers
Owner: Design lead
Status: Current
Last checked: October 20, 2026

## Answer
Bring the agreed layout and a list of unresolved questions.

## Steps
1. Check the layout against the approved scope.
2. Mark decisions that still need a person.
3. Save the outcome beside the project.

## Source
Link to the approved scope and its relevant section.

## Limits
This note does not approve a change to the scope.

These labels are ordinary text, so you do not need a special file parser. Replace the sample content with something your team can verify. The owner should be a role or person who can resolve a disagreement about the answer, rather than whoever happened to type the first draft.

Write abbreviations out the first time and include the words colleagues actually search for. If the team calls a deliverable a review pack, use that phrase alongside the formal title. Clear language helps a person find the page and helps an assistant recognize why the page belongs in its answer.

How should files link to one another?

Use the index as a short route into the collection. Link from a procedure to the reference it needs, and link from the reference back to the practical task when helpful. Avoid making readers return to the index for every move. Link text should name the destination instead of saying click here.

For files kept together, relative links can preserve navigation when you move or copy the folder. GitHub’s formatting documentation↗ (opens in a new tab) explains relative paths and links to headings in its Markdown renderer. Test your own editor and publishing system because rendering behavior can differ.

Changing a filename or heading can break an incoming link. Search for the old name before renaming it, update the references, and check the rendered result. Keep one current explanation of a rule and link to it from other files; copying its wording into several procedures creates several places to correct later.

How do you keep sources and decisions distinct?

A source is evidence you consulted. A decision is a choice a person made using that evidence. Put the source title, link, relevant section, and date checked beside the factual statement. Label an interpretation as an interpretation, especially when the source does not directly answer the project’s question.

Suppose a supplier guide describes two export formats. Your note can explain both, while the project decision records which format the client approved. A later assistant needs that choice as well as the supplier’s instructions. A source link alone cannot tell it what the client agreed to receive.

Keep current choices and unresolved approvals in fenbs so the assistant can read them with the project’s working context. Keep the document link precise enough that a person can reopen the evidence without searching through an entire folder.

How do you check whether an assistant can use it?

Give the assistant a limited task and the files through a supported access method. Ask it to name the file and section behind each important answer, identify missing information, and describe what it would do next. Being able to read a file does not prove that the assistant selected the right version or understood an exception.

• Ask one question the files answer directly, then compare the response with the source.
• Ask about a known exception and check whether the assistant recognizes the boundary.
• Ask something deliberately absent. A useful response should expose the gap instead of inventing a policy.
• Repeat after a meaningful update to confirm the assistant is reading the current material.

An AI knowledge base concerns how outside knowledge reaches an AI system; a Markdown folder alone does not establish that connection. For shared editing and access choices, see internal knowledge base software, or the separate guide to a Confluence knowledge base.

How to do this with fenbs

1. Create a free account and add the project whose Markdown notes you want to make easier to reuse.
2. Write the ongoing instructions people have approved in Decisions and rules. Add a context note explaining which document answers which question.
3. Connect your supported assistant using the integration guide, then ask it to read the project context before consulting the relevant Markdown files.
4. Before stopping, save completed work, unchecked results, and the next step in Where we left off. Update a document separately when its explanation has changed.

fenbs is useful when documents need a shared decision and handoff record across assistants. It is not the right fit if your only need is a Markdown editor or a rendered documentation website.

When should you review or archive a file?

Review a page when its source changes, a procedure fails, or someone cannot answer a normal question using it. Set a review rhythm that matches how quickly the subject changes. Mark an obsolete page clearly and point readers to its replacement before removing it from the main index.

Preserve the evidence behind important past work, but make the current answer unmistakable. At the end of a session, save enough progress for a clean AI handoff. That separates enduring instructions in the files from the temporary details of where today’s work stopped.