Obsidian Prompt Library: Reusable Prompts in Markdown

Build an Obsidian prompt library by saving one reusable prompt per note, with its purpose, required inputs, a worked example, and a review record. Start with a small folder and one consistent note template so you can find a useful instruction and understand when to use it.

Obsidian suits personal drafting and experiments; fenbs gives approved project prompts a shared home that connected assistants can read. Keep the distinction clear: an interesting draft in your notes should not quietly become an instruction your teammates rely on. The wider AI prompts guides cover related ways to write and reuse instructions.

How do you set up the first prompt folder?

Obsidian stores notes as Markdown plain text files in a vault, which is a folder on your device. That makes a prompt collection readable outside Obsidian too; its storage guide↗ (opens in a new tab) explains how those files are organized.

1. Create a Prompts folder in your existing vault. Keep it close to the project notes that explain your work.
2. Add a Prompt index note. List the few prompts you already use, grouped by the job they help you finish.
3. Create a Templates folder for the blank prompt-note structure. Keep this separate from finished prompt notes.
4. Name notes by outcome, such as Summarize interview findings or Review a client proposal. Avoid names like Great prompt 3.

Resist building a deep folder tree before you have useful notes. A researcher with six prompts does not need separate folders for every assistant, project, and writing style. For storage choices beyond this particular setup, see how to build a prompt library.

What should each prompt note contain?

Give each note two parts: the text you send to the assistant and the guidance you keep for yourself. Mark that boundary so you do not accidentally paste an old result or a reviewer's comment as an instruction. Include enough context that someone opening the note later can use it without remembering the original conversation.

# Summarize interview findings

Purpose: Turn interview notes into reviewable findings.
Inputs: Anonymized notes and the research question.
Status: Draft
Owner: Research lead

## Prompt to copy
Using only the notes below, list the recurring needs.
Separate direct observations from your interpretations.
For each finding, name the supporting note.
If evidence is missing, say so.

Research question: [INSERT QUESTION]
Notes: [INSERT ANONYMIZED NOTES]

## Example and review
Sample input: Three fictional interview notes.
Expected: Findings linked to evidence; no invented quotes.
Result: Not tested.
Next review: After the first research session.

The square-bracket placeholders above are instructions to replace text yourself. They are not an automatic Obsidian form. Keep reusable wording separate from client information, and use fictional inputs when an example does not need real records. Our prompt engineering guide explains how clearer inputs and output requirements improve the instruction itself.

How do you reuse the structure with Templates?

Obsidian's built-in Templates plugin↗ (opens in a new tab) inserts a saved text snippet into the active note. Enable it under Core plugins, set its template folder location to your Templates folder, and save your blank prompt structure there. In a new note, run the Templates: Insert template command and select that structure.

Keep the template neutral: headings for purpose, inputs, prompt, example, and review are enough. Fill those sections for the actual job rather than carrying sample instructions into every new note. The plugin inserts text; you still need to replace placeholders and choose what to send to an assistant.

Once wording is approved for a project, save that approved instruction in fenbs Skills and prompts so connected assistants can list and read it through the shared work record.

How do you find the right prompt later?

Use a few consistent Obsidian properties↗ (opens in a new tab), which store structured information about a note. Useful choices are purpose, status, owner, and reviewed. Keep each property simple: a short text value or a date is easier to maintain than a paragraph hidden above the prompt.

• Draft means the wording is still being explored.
• Reviewed means a named person checked it against the example in the note.
• Retired means it should stay available for reference but should not be reused for new work.

Those labels are your convention, not an approval system supplied by the note. Add internal links↗ (opens in a new tab) between the prompt, its project notes, and related examples; Obsidian supports both Markdown links and its double-bracket note links. Your index can then point readers to the purpose instead of making them guess a filename.

Before copying a prompt, compare its purpose with today's task. A note designed to summarize interviews may be a poor fit for evaluating a survey. If two notes appear interchangeable, explain the difference in their opening lines or keep one current version rather than making the next reader investigate both.

Separate a reusable task prompt from a broad instruction about how an assistant should behave. The system prompt examples can help you recognize that difference without turning every saved note into a permanent rule.

How do you check a prompt before reusing it?

Run the prompt on a small example before calling it reviewed. Save the exact input, the assistant used, the resulting output, and the check you performed. A result that reads smoothly may still omit an important detail or invent support that was absent from the notes.

For the interview example, check whether every finding points to supplied evidence and whether observations stay separate from interpretation. Then try incomplete notes. A useful instruction should admit the gap rather than manufacture a convincing quote. Record a specific failure, such as an unsupported finding, instead of writing only that the response was poor.

Change one part of the wording and repeat the same example so you can compare the result. Keep a short review note explaining what improved and what remains uncertain. Repeat this check when you change assistants or use the prompt for a substantially different job.

How do you share approved instructions with teammates?

Choose one current home for the approved wording. You can keep exploration and examples in Obsidian, then manually add the approved project prompt to fenbs. Leave a note explaining where that current version lives so nobody mistakes a personal experiment for the team's instruction.

When someone proposes a change, record why it matters and ask the responsible person to choose whether to adopt it. In fenbs, roles govern what members can do, and History records changes by people and assistants. Supported assistants connect through the guides on Integrations.

How to do this with fenbs

1. Create a free account and add the project that will use the prompt.
2. Add the reviewed wording to Skills and prompts. Include its purpose and required inputs so another assistant can use it correctly.
3. Connect a supported AI app and ask it to list and read the relevant prompt before trying a small example.
4. Review the output yourself. Record any agreed ongoing instruction in Decisions and rules, and save remaining work before the session ends.

fenbs does not sync your Obsidian vault. If your whole collection is personal and you are comfortable copying text yourself, the note setup may be all you need. Add a shared work record when teammates or different assistants need the same approved instructions.