Using Cursor with Obsidian
Configuration and Rules I'm using to power my Cursor + Obsidian use cases
After Exploring the intersection of AI and PKM's, I wanted to take some time to talk in more detail about using Cursor with Obsidian.
Let's start with two key facts that are key to unlocking a lot of creative use cases:
- Obsidian files are plain, markdown formatted text saved into a folder on your computer
- Cursor can open folders and reason about all of the contents within them
Therefore, I can open my Obsidian vault folder in Cursor and use it to:
- Find and discover content
- Create summaries across that content
- Edit, refactor, or update notes
This has really been a game changer for me as a supplemental feature for managing my vault.
One particular "super power" of Cursor is its support for Rules Files
Rules files help refine and customize its behavior and save you time so you don't have to constantly remind the AI model of preferences or important choices.
(Copilot now has a similar concept as well with Instruction files)
Below I've documented some configuration I've done to customize my Cursor PKM setup. This is not complete nor finished, but I'm sharing in its early stage to help provide inspiration.
Ignore file
Cursor supports a .cursorignore file so you can exclude some contexts from ever being consumed by Cursor AI. Here's what mine looks like for my Obsidian folder:
# Obsidian-related
.obsidian/
.trash/
# System files
.DS_Store
.env
.env.*
# Your note directories (uncomment what you want to ignore)
#000 inbox/
#002 attachments/
#004 meta/
#010 projects/
#020 areas/
#030 resources/
#040 archives/
# Git related
.git/
050 gitignore/
Rules
Generating Rules
Have cursor generate rules based on your existing templates:
Cursor can either look at all of your templates at once (as shown in example below) or you can have it generate a rule file per template.
A rule file per template is helpful if you plan to have more detailed rules for some templates.
/Generate Cursor Rules look at my templates in @templates folder and update @templates.mdc with appropriate rules.
Have cursor modify existing rules to match the current vault:
In this case, I copied one of my rules files from my work vault over to my personal vault.
/Generate Cursor Rules please update @metabind.mdc to reflect the properties used in this vault. This rules file was copy/pasted from a different vault. The current vault does use the Metabind plugin, and these rules are generally correct, its just the examples and exact properties that are incorrect. @templates is a good place to discover the metabind properties supported by this vault.
Example Rules Files
These are the current rules I'm using. The structure and content is mostly the same across both my Personal and Work vaults with only small tweaks here and there.
settings.mdc
I think of these as my "Global rules" because I have them configured in Cursor to Always Apply no matter the task.
- Inform Cursor about PARA
- Nudge Cursor towards some of my markdown style preferences
- Instruct Cursor to add
#ai/*tags AND to update the Log section of notes anytime it modifies one of my notes
# Project Settings and Preferences
This is a personal knowledge management vault created with Obsidian. It follows the PARA knowledge management structure. These notes are directly related to the author's hobbies and personal life. Before taking any action, always check if there are any relevant rules that should be followed.
## Markdown Standards
- Use 4 spaces for indentation
- Use Obsidian-style markdown. When in doubt, fall back to Github-style markdown.
- Use wiki-style links: [[file-name]]
- Validate internal links between notes
- Dates should be formatted as: [[YYYY-MM-DD]]
- Prefer ordered lists over un-ordered lists
- Do not apply **bold** to Markdown Headings
## File Organization
- Follow PARA method (Projects, Areas, Resources, Archives)
## Note Structure
- Most notes contain a Log section where timeline information can be captured
- When you create a new file, always add the tag `ai/created` to the metadata
- When you edit a file, always add the tag `ai/edited` to the metadata unless the tag `ai/created` is already present
- Instructions for handling the Log section can be found in @log_section_rules.mdc
- The most up to date standards, specifications, and templates can be found in the `004 meta/` folder
## Tools
- These notes are primarily used and maintained with Obsidian
- All choices should favor a smooth Obsidian workflow
- @obsidian plugins.md documents current plugins in use providing additional capabilities
log_section_rules.mdc
When Cursor modifies one of my notes I want to keep track of that in the dedicated Log section most notes have. These instructions tell it how to do that.
---
description: This is helpful when editing or inspecting the Log section in a note file.
globs:
alwaysApply: false
---
# Log Section Rules
The specification for the Log Section in a Note can be found [Log Sections.md](mdc:004 meta/Note Specification/Log Sections.md).
## ⚠️ CRITICAL: Log Entry Format Rules
When you create or edit a file:
- Always add a Log section entry documenting in a single sentence your task or the change you made. Use robot emoji as a prefix.
### ❌ NEVER DO THIS: Modify existing log entries
\```markdown
# WRONG - Don't append to or modify existing entries:
- [[2025-05-23]]
- **Project Created** - 🤖 Comprehensive project file created from meeting notes
# WRONG - Don't replace existing entries:
- [[2025-05-23]]
- 🤖 Comprehensive project file created from meeting notes
\```
### ✅ ALWAYS DO THIS: Add new list items
\```markdown
# CORRECT - Add a new list item under the date:
- [[2025-05-23]]
- **Project Created**
- 🤖 Comprehensive project file created from meeting notes
# CORRECT - For multiple AI tasks on same date:
- [[2025-05-23]]
- **Project Created**
- 🤖 Comprehensive project file created from meeting notes
- 🤖 Updated project relationships and cross-references
\```
### Log Entry Workflow
When adding AI log entries:
1. **Find the date section** - Look for `- [[YYYY-MM-DD]]`
2. **Add NEW list item** - Create a new `- 🤖 [description]` line
3. **Use proper indentation** - Match existing indentation (usually 1 tab)
4. **Never modify existing entries** - Only add new ones
### Example Log Structure
\```markdown
# 🕐 log
- [[2025-05-22]]
- **Meeting Notes Added**
- Project requirements clarified
- [[2025-05-23]]
- **Project Created**
- 🤖 Comprehensive project file created from meeting notes
- 🤖 Fixed cross-references between related projects
\```
metabind.mdc
I noticed Cursor had trouble with understanding and updating the inline properties provided by the Metabind plugin so I asked it to generate some rules based on my correcting its various mistakes. After creating these rules, it no longer made mistakes when updating these properties.
---
description: This is helpful when working on a note that uses the metabind plugin, syntax, or frontmatter.
globs:
alwaysApply: false
---
# MetaBind Plugin Rules
MetaBind provides inline UI elements that are directly bound to file properties in Obsidian frontmatter.
## ⚠️ CRITICAL RULE: Never Modify INPUT Syntax
**❌ NEVER DO THIS:** Replace INPUT elements with hardcoded values
\```markdown
// WRONG - Don't replace the INPUT syntax:
**Lifecycle:** Unread
**Publish Date:** [[2024-03-21]]
\```
**✅ ALWAYS DO THIS:** Keep INPUT syntax intact, update frontmatter instead
\```markdown
// CORRECT - Keep the INPUT syntax exactly as is:
**Lifecycle:** `INPUT[source_material_lifecycle_template][:source_material_lifecycle]`
**Publish Date:** `INPUT[date:blog_post_publish_date]`
// Update the frontmatter properties instead:
---
source_material_lifecycle: unread
blog_post_publish_date: 2024-03-21
---
\```
## Two Separate Concerns
### 1. INPUT Elements (UI Layer) - NEVER MODIFY
These are the interactive UI elements that appear in the note body. They must remain exactly as written:
- `INPUT[source_material_lifecycle_template][:source_material_lifecycle]`
- `INPUT[project_lifecycle_template][:project_lifecycle]`
- `INPUT[blog_post_lifecycle_template][:blog_post_lifecycle]`
- `INPUT[date:blog_post_publish_date]`
- `INPUT[text:blog_post_publish_url]`
### 2. Frontmatter Properties (Data Layer) - UPDATE THESE
These are the YAML properties that store the actual values:
\```yaml
---
source_material_lifecycle: unread
project_lifecycle: active
blog_post_lifecycle: draft
blog_post_publish_date: 2024-03-21
blog_post_publish_url: https://example.com/post
---
\```
## Required Frontmatter Properties by Note Type
### Blog Posts
\```yaml
---
note_type: blog_post
blog_post_lifecycle: draft # Options depend on lifecycle template
blog_post_publish_url: "" # URL where post is published
blog_post_publish_date: "" # Publication date
---
\```
### Projects
\```yaml
---
note_type: project
project_lifecycle: active # Options depend on lifecycle template
---
\```
### Source Materials (Books, Articles)
\```yaml
---
note_type: source_material
source_material_lifecycle: unread # Options depend on lifecycle template
---
\```
## MetaBind INPUT Syntax Patterns (DO NOT MODIFY)
### Lifecycle Templates
\```markdown
**Lifecycle:** `INPUT[source_material_lifecycle_template][:source_material_lifecycle]`
**Lifecycle:** `INPUT[project_lifecycle_template][:project_lifecycle]`
**Lifecycle:** `INPUT[blog_post_lifecycle_template][:blog_post_lifecycle]`
\```
### Date Inputs
\```markdown
**Publish Date:** `INPUT[date:blog_post_publish_date]`
\```
### Text Inputs
\```markdown
**Publish Url:** `INPUT[text:blog_post_publish_url]`
\```
## Standard Note Headers (PRESERVE EXACTLY)
### Blog Post Header
\```markdown
# 📰 [Post Title]
**Lifecycle:** `INPUT[blog_post_lifecycle_template][:blog_post_lifecycle]`| **Publish Url:** `INPUT[text:blog_post_publish_url]`| **Publish Date:** `INPUT[date:blog_post_publish_date]` | **Categories:** #blog_post
\```
### Project Header
\```markdown
# 📦 [Project Name] Project
**Lifecycle:** `INPUT[project_lifecycle_template][:project_lifecycle]` #project/name
\```
### Source Material Header
\```markdown
# 📘 [Title]
**Lifecycle:** `INPUT[source_material_lifecycle_template][:source_material_lifecycle]` #book/title
\```
## Editing Workflow
When updating notes:
### ✅ DO Update:
1. **Frontmatter properties** with actual values
2. **Note content** below the header
3. **Tags and metadata**
### ❌ DON'T Touch:
1. **INPUT syntax** in the header (the `INPUT[...]` parts)
2. **MetaBind element structure**
3. **Property binding syntax** (the `:property_name` parts)
### Example Correct Edit:
\```yaml
# Update frontmatter:
---
source_material_lifecycle: in_progress # ✅ Update this
---
# Keep header exactly as is:
**Lifecycle:** \`INPUT[source_material_lifecycle_template][:source_material_lifecycle]\` # ❌ Never modify this line
\```
## MetaBind Syntax Rules
### General Format
- All INPUT elements use backticks: `` `INPUT[type:property_name]` ``
- Property names must match frontmatter properties exactly
- Lifecycle templates use the format: `INPUT[template_name][:property_name]`
- Simple inputs use the format: `INPUT[type:property_name]`
### Input Types Reference
| Input Type | Syntax | Use Case |
| -------------------- | -------------------------------------- | --------------------- |
| `lifecycle_template` | `INPUT[template_name][:property_name]` | Note status/lifecycle |
| `date` | `INPUT[date:property_name]` | Dates |
| `text` | `INPUT[text:property_name]` | Simple text input |
## Template Integration
The following templates contain canonical MetaBind INPUT syntax:
- [blog_post_template.md](mdc:004 meta/templates/blog_post_template.md)
- [project_template.md](mdc:004 meta/templates/project_template.md)
- [book_template.md](mdc:004 meta/templates/book_template.md)
- [wallabag_import_template.md](mdc:004 meta/templates/wallabag_import_template.md)
## Troubleshooting
### If MetaBind Elements Stop Working:
- Check that frontmatter property names match exactly
- Verify INPUT syntax hasn't been modified
- Ensure backticks around INPUT elements are intact
- Confirm property values match expected format
templates.mdc
These are the rules Cursor generated after inspecting my note templates.
---
description: This is helpful when working with templates or creating new files.
globs:
alwaysApply: false
---
# Template Rules
This workspace uses Obsidian templates with Templater plugin syntax for creating various types of notes. Templates are stored in [004 meta/templates/](mdc:004 meta/templates).
## Available Templates
### Project Template
- File: [project_template.md](mdc:004 meta/templates/project_template.md)
- Creates project notes in `010 projects/`
- Features:
- Auto-generated project tag based on name
- Todo section
- Notes section
- Log section with creation date
- Project lifecycle status field
### Blog Post Template
- File: [blog_post_template.md](mdc:004 meta/templates/blog_post_template.md)
- Creates blog post drafts in `020 areas/Blog/Posts/Draft/`
- Features:
- Blog post lifecycle status
- Publish URL field
- Publish date field
- Categories field
### Person Template
- File: [person_template.md](mdc:004 meta/templates/person_template.md)
- Creates person notes in `030 resources/People/`
- Features:
- Contact information fields (birthday, address, phone, email)
- Todo section
- Notes section
- Log section
- Relationships section (family, friends, pets)
- Life events section with dataview query
- Gifts tracking with dataview query
- Reminders section
### Book Template
- File: [book_template.md](mdc:004 meta/templates/book_template.md)
- Creates book notes in `030 resources/`
- Features:
- Auto-generated book tag based on title
- Source material lifecycle status
- Metadata callout (author, ISBN, pages, publication, ownership)
- Notes section
- Log section with creation date
### Wallabag Import Template
- File: [wallabag_import_template.md](mdc:004 meta/templates/wallabag_import_template.md)
- Creates source material notes from Wallabag articles
- Features:
- Source and Wallabag link metadata
- Publication and import date tracking
- Source material lifecycle status
- Article content import
## Template Conventions
1. All templates use YAML frontmatter with appropriate metadata
2. Common frontmatter fields:
- `note_type` - Identifies the type of note
- `tags` - Categorization tags
- `aliases` - Alternative names for the note
3. Common sections:
- Todo (✅)
- Notes (📓)
- Log (🕐)
4. Templates use Templater syntax:
- `<%* %>` for JavaScript code blocks
- `<% %>` for variable insertion
- `tp.file.*` for file operations
- `tp.system.prompt()` for user input
5. File organization:
- Projects go to `010 projects/`
- Blog posts go to `020 areas/Blog/Posts/Draft/`
- People go to `030 resources/People/`
- Books and other resources go to `030 resources/`