Get AI summaries of any video or article — Sign up free
My simple note-taking setup | Zettelkasten in Obsidian | Step-by-step guide thumbnail

My simple note-taking setup | Zettelkasten in Obsidian | Step-by-step guide

Artem Kirsanov·
5 min read

Based on Artem Kirsanov's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Keep Zettelkasten structure emergent by storing atomic ideas in one place and relying on links rather than prebuilt topic folders.

Briefing

A Zettelkasten workflow can stay genuinely simple by resisting elaborate tagging schemes and letting structure emerge from links. The core claim is that complexity—especially endless tinkering with tags and folder hierarchies—often distracts from the actual work: capturing ideas, writing them in one’s own words, and connecting them so patterns surface naturally.

The setup centers on Obsidian with a small, deliberate tool stack: four core folders, two main note templates, and just two community plugins. All “atomic idea” notes live in a single root folder, while attachments and templates sit in their own dedicated subfolders. The system’s philosophy is explicit: don’t pre-separate topics into folders; instead, create notes and link them, allowing relationships to form the organizing structure over time.

At the top level, the workflow uses four folders—Reference Notes, Files, Templates, and a main folder for Zettelkasten ideas (the atomic notes). Reference Notes store where ideas came from (books, lectures, sources), Files holds images and templates, and Templates contains reusable note templates. Obsidian’s vault concept is treated as a boundary: everything relevant lives inside one local folder, with Obsidian’s internal configuration kept in a hidden .obsidian directory.

The practical configuration is straightforward. Obsidian is set so new nodes and attachments default into the Zettelkasten idea folder and the Files folder. A hotkey is assigned for inserting templates, and two plugins are used repeatedly: Sliding Panes for viewing multiple notes side-by-side like paper cards, and Admonition for inserting visually distinct blocks inside notes. The “core” template is designed to paste the current date and time, set the note heading, and include a status/tags area. A second template creates “maps of content” (mock notes): these are organizational hubs that can remain empty or be used to capture summaries/diagrams.

The note-creation workflow emphasizes avoiding duplicates and accelerating recall. Using Obsidian’s “create/open by title” flow (rather than blindly creating new notes) helps detect existing notes and encourages elaboration. References are handled by linking to source notes—sometimes including timestamps for lectures—so the system can reuse those citations instead of rewriting metadata.

Links are treated as the system’s engine. Obsidian’s double-square-bracket linking allows linking to notes that don’t yet exist; these “ghost nodes” appear as darker links and later become real notes. As more atomic notes connect to recurring ghost nodes, graph view reveals hubs—clusters of ideas around a topic. Those hubs then justify creating an actual “map of content” file, turning emergent structure into a navigable dashboard.

Finally, the workflow is framed as iterative rather than fixed. If a system works differently, it should be adapted gradually; if it feels stuck, the recommendation is to start simple for months, then adjust one step at a time as the knowledge base grows. The payoff is a second brain that evolves with the ideas instead of being forced into a brittle, over-engineered taxonomy.

Cornell Notes

The workflow keeps Zettelkasten in Obsidian intentionally lean: four folders, two templates, and two plugins. Atomic idea notes are stored together, while references and attachments live in separate folders; topics are not pre-sorted into rigid structures. Links drive organization: double-square-bracket links can point to “ghost nodes” that later become real notes, and graph view reveals hubs where many ideas converge. Those hubs become “maps of content” (mock notes) created from a second template. The main benefit is avoiding complexity for its own sake—tag and structure tinkering can distract from writing, connecting, and discovering relationships.

Why does the system avoid heavy upfront tagging and folder hierarchies?

It treats structure as something that should emerge from interconnections rather than be imposed before ideas exist. Instead of creating folders to separate topics, atomic notes are placed in one main Zettelkasten folder and connected via links. The graph view then reveals recurring hubs—clusters of notes around ghost nodes that function like evolving tags—so organization grows out of actual usage instead of a preplanned taxonomy.

What are the four core folders, and what role does each play?

The setup uses four folders: (1) a main folder for atomic idea notes, (2) Reference Notes for where ideas came from (books, lectures, sources), (3) Files for attachments like images and templates, and (4) Templates for reusable note templates. This separation keeps the Zettelkasten idea space clean while still supporting citations and reusable formatting.

How do templates reduce friction without turning into another rabbit hole?

Templates are used in a minimal way. The “core” template is applied to most new atomic notes and automatically inserts the current date/time, sets the heading, and includes a status/tags area. A second template creates “maps of content” (mock notes) by switching status to a mock type and removing reference fields. The goal is speed and consistency, not feature exploration.

How do “ghost nodes” function as a bridge between tags and organization?

When a note is linked to via double square brackets but the target note doesn’t exist yet, Obsidian remembers that link. The missing target appears as a darker item and shows up in the link suggestions later. Over time, many atomic notes may link to the same ghost node, forming hubs in graph view—an emergent stand-in for tags that can later be converted into real “map of content” files.

What triggers the creation of a “map of content” note?

Hubs in graph view. When atomic idea nodes cluster around a ghost node repeatedly, it signals a recurring topic. At that point, the system creates an actual file for that hub using the “map of content” template, optionally leaving it empty or adding summaries/diagrams to serve as an organizational dashboard.

What is the practical purpose of the two plugins used in the setup?

Sliding Panes enables side-by-side navigation across multiple notes, mimicking paper cards and making it easier to compare or move between related ideas. Admonition lets the user insert rendered, visually distinct text blocks inside notes, supporting clearer structure within an atomic note without changing the overall system architecture.

Review Questions

  1. How does linking to non-existent notes help the system avoid rigid tagging while still producing organization?
  2. What observable signal in graph view indicates it’s time to create a “map of content” note?
  3. Why does the workflow recommend starting simple for months instead of redesigning the vault immediately?

Key Points

  1. 1

    Keep Zettelkasten structure emergent by storing atomic ideas in one place and relying on links rather than prebuilt topic folders.

  2. 2

    Use four core folders—ideas, reference notes, files, and templates—to separate concerns without adding complexity to the idea space.

  3. 3

    Rely on two templates: a core atomic idea template (date/time, heading, status/tags) and a map-of-content template (mock hub organization).

  4. 4

    Treat ghost nodes as provisional tags: link to notes that don’t exist yet, then convert hubs into real notes when they recur.

  5. 5

    Use graph view to detect hubs where many atomic notes converge; those hubs become dashboards for navigation.

  6. 6

    Limit plugin use to tools that support day-to-day capture and review (e.g., side-by-side reading and visual blocks).

  7. 7

    Iterate gradually: adjust the system one step at a time based on how the knowledge base grows, not based on other people’s setups.

Highlights

The system’s organizing principle is simple: don’t pre-structure topics—let links and graph clustering create structure.
Double-square-bracket links can point to “ghost nodes,” which later become real notes once a hub proves recurring.
Maps of content are created only when graph view shows hubs, turning emergent relationships into navigable dashboards.
Complex tagging and constant restructuring are framed as a common distraction from the real work: writing and connecting ideas.

Mentioned