LLM Best Practices

Obsidian Workflow

4 min read

View markdown source

Overview

Obsidian is the authoring surface for a markdown-first knowledge base. The rules below cover the vault layout that ships well to a static site, the note types worth distinguishing, the link grammar to use, and the plugins to install. Most of these decisions are picked so the same vault can publish through Quartz without a transform step. See quartz for the publishing side.

Prefer MOCs over deep folders

A Map of Content (MOC) is an index note that links its leaves. Use MOCs to navigate; use folders only as a coarse filing aid.

  • One index.md per top-level domain (frontend/, backend/, ops/). It lists the pages in that domain inline.
  • Avoid folders nested more than two deep. Linking is the navigation, not the file tree.
  • A note can be reached from multiple MOCs through wikilinks. A folder cannot. MOCs win for cross-domain topics.

Separate daily notes from atomic notes

Daily notes are scratch. Atomic notes are durable. Do not blur them.

  • Daily notes live in daily/YYYY-MM-DD.md. Use them for meetings, half-formed thoughts, and TODOs.
  • Atomic notes live under a domain folder with a kebab-case slug (backend/postgres.md). Each note covers one idea and links to its neighbors.
  • Promote a daily-note idea to an atomic note when it gets cited twice. Two references is the threshold; one is just a thought.

Use wikilinks for every internal link. Reserve markdown links for external URLs.

  • [[note]] resolves by slug. Use this when the slug is globally unique.
  • [[folder/note]] resolves by path. Use this when two notes share a slug ([[seo/technical]] and [[frontend/technical]], for example).
  • [[note|display text]] overrides the rendered text. Use sparingly; it hides the destination on hover.
  • Backlinks update automatically when a note is renamed if you rename through Obsidian. Always rename inside the app, never on the filesystem.

Frontmatter on every note

Every published note opens with YAML frontmatter. Stub notes get the same schema.

---
title: "Postgres: Best Practices"
slug: "postgres"
category: "backend"
tags: ["backend", "postgres", "database"]
status: "stable"
last_updated: 2026-05-14
summary: "One sentence routing hint."
related: ["[[backend/prisma]]", "[[backend/sqlite]]"]
---

The frontmatter is what makes a vault publish-ready. Quartz, Astro Content Collections, and most static site generators read it directly.

Plugins worth installing

A small set covers most authoring needs. Add more only when a concrete need appears.

  • Templater. Insert a frontmatter block on note creation. Bind it to a hotkey for new atomic notes.
  • Dataview. Query the vault by frontmatter. Useful for MOC pages that list “every note with status: draft.”
  • Tag Wrangler. Rename and merge tags across the vault without touching files by hand.
  • Obsidian Git (optional). Commit and push the vault on a schedule. Skip if the vault is already a git repo you manage with the CLI.

Avoid plugins that rewrite file content on save (auto-linters, AI-rewrite plugins). They produce diffs you did not author.

Obsidian-to-Quartz roundtrips on the same files

Quartz reads the same markdown Obsidian writes. No conversion step.

  • Same wikilinks. Quartz resolves [[note]] and [[folder/note]] exactly as Obsidian does.
  • Same frontmatter. Quartz uses title, tags, and date fields directly.
  • Same folder layout. Quartz treats the vault root as the content root.

The implication: the vault is the source. Edit in Obsidian, commit with git, push to deploy. No copy step, no export.

Ignore patterns

Some vault content should never publish.

.obsidian/          # Workspace, plugins, hotkeys.
.trash/             # Obsidian's soft delete.
private/            # Anything personal or in-progress that should not ship.
daily/              # Optional; daily notes rarely belong on a public site.

Configure these in Quartz’s ignorePatterns (see quartz) and in .gitignore when they should not even reach the remote.

Graph View

Backlinks