my-vault/06_Metadata/WORKFLOWS.md

Obsidian Vault Workflows - Detailed Reference

Generated: January 07, 2026 Purpose: Comprehensive guide for vault management Organization: PARA Method Status: Reference Documentation

This is a detailed reference. For core rules, see .claude/project-instructions.md Relationship: README.md is the entry point, QUICK_REFERENCE.md is the quick reference, and this document is the detailed workflow guide.

---

Table of Contents

1. Command Policy
2. Output Templates
3. PARA Method Explained
4. Naming Conventions
5. Inbox Management
6. Attachments Management
7. Web Content Workflow
8. Writing Style Guidelines
9. Git Workflow
10. Daily Workflows
11. Available Commands
12. Best Practices
13. Troubleshooting
14. Memvid Workflows

---

Command Policy

• Manual commands in documentation use simple, copy-safe commands only
• Avoid pipes, grep, find, or other complex shell constructs in manual steps
• Complex operations belong in pnpm scripts
• If pnpm is unavailable, use npm run <script> as a fallback

---

Output Templates

Standard Note Format

---
created: YYYY-MM-DD
modified: YYYY-MM-DD
tags: [tag1, tag2, tag3]
status: draft|active|complete|archived
type: note|project|area|resource
---

# Title

## Summary
[2-3 sentence overview]

## Content
[Main content with clear heading hierarchy]

## Related Notes
- [[Related Note 1]]
- [[Related Note 2]]

## References
- [Source 1](URL)

Change Plan Template

Use this when proposing bulk operations (moves, merges, deletions):

**Change Summary**: [One sentence describing the goal]

**Affected Files**:
- Source: `path/to/source.md`
- Target: `path/to/target.md`
- Links affected: ~X places

**Steps**:
1. Step one with specific command
2. Step two with verification
3. Step three with link updates

**Rollback**:
[Exact steps to undo if something goes wrong]

**Verification**:
- [ ] All files moved successfully
- [ ] Links updated and tested
- [ ] No broken references

Working Mode Descriptions

Quick Organization: Structure raw content into readable format (headings, lists, tables, code blocks)

Archive & Organize: Analyze content, suggest PARA placement, recommend tags and frontmatter

Knowledge Distillation: Extract insights, separate evidence from conclusions, establish connections

Search & Answer: Respond based on vault content, cite specific locations, quote sources

---

PARA Method Explained

Projects (01_Projects/)

Definition: Time-bound initiatives with clear completion criteria

Characteristics:

• Has a specific end goal
• Has a deadline or completion state
• Contains discrete tasks and deliverables
• Will eventually move to Archive

Examples:

• Writing a research paper
• Planning a presentation
• Learning a specific skill
• Organizing an event

Structure:

01_Projects/[ProjectName]/
├── README.md              # Project overview, goals, timeline
├── Research/              # Background materials
├── Drafts/                # Work in progress
├── References/            # Supporting documents
└── Output/                # Final deliverables

Areas (02_Areas/)

Definition: Ongoing responsibilities without end dates

Characteristics:

• Continuous maintenance required
• Standards to uphold
• No completion date
• Generates multiple projects over time

Examples:

• Health & Fitness
• Professional Development
• Finances
• Relationships
• Home Management

Structure:

02_Areas/[AreaName]/
├── Overview.md            # Area definition and standards
├── Projects.md            # Related project links
└── Resources.md           # Helpful references

Resources (03_Resources/)

Definition: Topics of interest for reference and learning

Characteristics:

• Not tied to current projects
• Reference material
• Long-term knowledge building
• Curated information

Examples:

• Programming languages
• Historical topics
• Philosophical concepts
• Technical documentation
• Book notes

Structure:

03_Resources/[TopicName]/
├── Index.md               # Topic overview
├── Notes/                 # Individual concept notes
└── References/            # Source materials

Archive (04_Archive/)

Definition: Completed projects and inactive items

When to Archive:

• Projects: When objectives are met
• Areas: When no longer relevant
• Resources: When superseded or outdated

Structure:

04_Archive/
├── Projects/              # Completed projects
├── Areas/                 # Inactive areas
└── Resources/             # Outdated resources

---

Naming Conventions

Daily Notes

YYYY-MM-DD - [Topic or Activity]
Example: 2026-01-05 - Meeting Notes

Meeting Notes

Meeting - [Topic] - YYYY-MM-DD
Example: Meeting - Project Planning - 2026-01-05

Ideas

Idea - [Brief Description]
Example: Idea - Automated Daily Review Process

Resources

Resource - [Topic] - [Source]
Example: Resource - PARA Method - Forte Labs

Clippings (Auto-generated)

[Domain]_[Timestamp].md
Example: anthropic.com_1736095200.md

Movement Best Practices

ALWAYS:

• Use mv command (not cp) to avoid duplicates
• Verify destination folder exists before moving
• Update internal links after moving files
• Add YAML frontmatter when organizing
• Commit changes after significant reorganization

NEVER:

• Move files with number prefixes (00-06) from root
• Delete files without reviewing content
• Create deep folder hierarchies (max 3 levels)
• Leave broken links after reorganization

---

Inbox Management

Core Principles

• Inbox is temporary, not permanent storage
• Process weekly using: Capture → Process → Organize
• Maintain fewer than 20 unprocessed items
• Everything in inbox should be recent (< 1 week old)

What Stays in Inbox Permanently

• Files with number prefixes: 00-, 01-, etc.
• Core configuration files
• Active daily notes (last 7 days)
• Current weekly summaries (last 3 months)

Processing Workflow

Step 1: Review

git status                  # See what's new
ls 00_Inbox/               # List inbox contents

Step 2: Decide

For each item, ask:

• Is this actionable? → Create task or project
• Is this reference? → Move to Resources
• Is this project-related? → Move to Projects
• Is this outdated? → Delete or archive
• Needs more work? → Tag #needs-processing

Step 3: Organize

# Move to appropriate location
mv "00_Inbox/filename.md" "01_Projects/ProjectName/"

# Verify
ls "01_Projects/ProjectName/"

Step 4: Commit

git add .
git commit -m "Organize inbox: processed weekly items"
git push

Inbox Clippings Folder

• Firecrawl automatically saves web content here
• Process within 1 week
• Move to appropriate PARA location
• Delete duplicates or low-value content

---

Attachments Management

Organization Rules

Storage Location:

• All non-text files: 05_Attachments/
• Unprocessed: 05_Attachments/
• Processed: 05_Attachments/Organized/

Naming Convention:

[RelatedNote]_[Description].[ext]

Examples:
ProjectProposal_Diagram.png
Research_StatisticsTable.pdf
Meeting2026-01-05_Whiteboard.jpg

Supported File Types:

• Images: PNG, JPG, GIF, SVG
• Documents: PDF, DOCX
• Data: CSV, XLSX, JSON
• Media: MP3, MP4 (use sparingly)

Processing Workflow

Step 1: List Unprocessed

ls 05_Attachments/

Step 2: Review Each File

• Is it referenced in notes? Keep and rename
• Is it orphaned? Delete or add reference
• Is it project-related? Keep with clear name

Step 3: Rename and Move

mv "05_Attachments/screenshot.png" "05_Attachments/Organized/ProjectName_Feature.png"

Step 4: Update Links Update any markdown references:

Before: ![](../05_Attachments/screenshot.png)
After: ![](../05_Attachments/Organized/ProjectName_Feature.png)

---

Web Content Workflow

Built-in Tools (Preferred Method)

WebSearch Tool:

• Use for: General web searches, current information
• Output: Search results with sources
• Action: Copy relevant content into notes manually

WebFetch Tool:

• Use for: Specific URLs, documentation pages
• Output: Page content in markdown format
• Action: Save to appropriate PARA location

Best Practices:

1. Use WebSearch/WebFetch within Claude Code
2. Review content before saving
3. Add frontmatter and context
4. Save to appropriate folder (not Inbox unless processing later)
5. Include source URL in frontmatter

Firecrawl Scripts (Batch Processing)

Single URL:

pnpm firecrawl:scrape <url> <output-filename>
# Saves to: 00_Inbox/Clippings/

Batch URLs:

pnpm firecrawl:batch <url1> <url2> <url3>
# Saves to: 00_Inbox/Clippings/

Auto-generated Frontmatter:

---
source_url: https://example.com/article
scraped_date: YYYY-MM-DD
tags: [clipping, needs-processing]
---

Processing Clippings:

1. Review content quality
2. Add relevant tags and notes
3. Move to appropriate PARA location
4. Delete low-value clippings

---

Writing Style Guidelines

Structure Standards

Internal Linking:

• Use [[WikiLinks]] for all internal references
• Link liberally (better too many than too few)
• Create bidirectional links when relevant
• Use descriptive link text

Markdown Formatting:

• Headings: Use # hierarchy (H1 for title, H2 for sections)
• Lists: Use - for unordered, 1. for ordered
• Code: Use backticks for inline, triple backticks for blocks
• Emphasis: **bold** for important, *italic* for subtle

YAML Frontmatter:

• Always include: created, modified, tags
• Optional: status, type, project, area
• Keep tags specific and consistent
• Update modified date when editing

Content Style Preferences

Direct Communication:

• Lead with the main point
• Avoid unnecessary preambles
• Be specific and concrete
• Use active voice

Avoid:

• Clichéd transitions ("In today's world...")
• Filler phrases ("It's worth noting that...")
• Unnecessary qualifiers ("I think maybe...")
• Overused business jargon

Prefer:

• Clear, confident statements
• Specific examples over generalizations
• Simple sentences over complex
• Technical precision when needed

---

Git Workflow

Critical Rule

ALWAYS start sessions with git pull to sync latest changes from remote repository.

Daily Workflow

Morning (Session Start):

cd D:\tmp\vault\my-vault
git pull
git status                  # Check for any conflicts

During Work:

git status                  # Periodically check changes

Evening (Session End):

git status                  # Review all changes
git add .                   # Stage all changes
git commit -m "vault backup: YYYY-MM-DD HH:MM:SS"
git push                    # Sync to remote

Commit Message Guidelines

Format:

[type]: [brief description]

Examples:
vault backup: 2026-01-05 20:30:15
Add: Project planning notes for Q1 initiatives
Update: Weekly review template with new sections
Organize: Moved inbox items to appropriate folders
Archive: Completed research project

When to Commit:

• After organizing inbox
• After creating new notes
• After significant edits
• Before ending session
• After weekly review

Common Git Commands

git status                  # Check current state
git pull                    # Sync from remote
git add .                   # Stage all changes
git commit -m "message"     # Commit with message
git push                    # Sync to remote
git log --oneline -10       # View recent commits

Handling Conflicts

If git pull shows conflicts:

1. Review conflicted files
2. Resolve conflicts manually
3. Stage resolved files: git add .
4. Commit: git commit -m "Resolve merge conflicts"
5. Push: git push

---

Daily Workflows

Morning Routine (5 minutes)

# 1. Sync changes
git pull

# 2. Check inbox
ls 00_Inbox/

# 3. Review today's focus
# Create or open: YYYY-MM-DD - Daily Notes.md

Daily Note Template:

---
created: YYYY-MM-DD
type: daily
tags: [daily, journal]
---

# YYYY-MM-DD - Daily Notes

## Focus for Today
- [ ] Primary task 1
- [ ] Primary task 2
- [ ] Primary task 3

## Capture
[Quick notes throughout the day]

## Reflections
[End of day thoughts]

Evening Routine (5 minutes)

# 1. Process quick inbox items
ls 00_Inbox/

# 2. Update project notes
# Review and update active projects

# 3. Commit changes
git status
git add .
git commit -m "vault backup: YYYY-MM-DD HH:MM:SS"
git push

Weekly Review (30-45 minutes)

See WEEKLY_REVIEW.md for complete checklist.

Quick Overview:

1. Process entire inbox (target: zero items)
2. Review all active projects
3. Update area notes
4. Archive completed items
5. Clean up attachments
6. Plan next week

---

Available Commands

Attachment Management

pnpm attachments:list          # List unprocessed attachments
pnpm attachments:organized     # Count organized files
pnpm attachments:orphans       # Find unreferenced files
pnpm attachments:update-links  # Update links after moving

Web Content

pnpm firecrawl:scrape <url> <output>    # Scrape single URL
pnpm firecrawl:batch <url1> <url2>      # Scrape multiple URLs

Git Operations

git pull                       # Sync from remote
git status                     # Check modifications
git add .                      # Stage all changes
git commit -m "message"        # Commit with message
git push                       # Sync to remote

Folder Navigation

cd D:\tmp\vault\my-vault       # Vault root
ls 00_Inbox/                   # List inbox
ls 01_Projects/                # List projects

---

Best Practices

Organization Principles

Keep It Shallow:

• Maximum 3 levels of folders
• Create subfolders only with 7+ related notes
• Use linking over deep nesting
• Flat is better than nested

Maintain Clarity:

• Include README.md in major folders
• Use consistent naming conventions
• Tag consistently and specifically
• Update frontmatter regularly

Regular Maintenance:

• Weekly inbox processing (non-negotiable)
• Monthly project reviews
• Quarterly archive cleanup
• Daily git commits

Content Creation Principles

Capture First, Organize Later:

• Don't let organization block capture
• Inbox is for quick entry
• Process in batches, not individually
• Speed over perfection initially

One Idea Per Note:

• Atomic notes are more reusable
• Easier to link and discover
• Better for future reorganization
• Clear single purpose

Link Generously:

• Create connections between ideas
• Build bidirectional links
• Use consistent link syntax
• Review links when moving files

Tag Consistently:

• Use specific tags over generic
• Maintain tag vocabulary list
• Tag for retrieval, not categorization
• Review tags during weekly review

Maintenance Schedule

Daily:

• Morning: git pull, check inbox
• Evening: Commit changes, git push

Weekly:

• Process entire inbox
• Review active projects
• Update area notes
• Clean attachments folder

Monthly:

• Review all projects for completion
• Archive inactive items
• Consolidate resources
• Update documentation

Quarterly:

• Deep archive review
• Prune old resources
• Update folder structure if needed
• Review and refine workflows

---

Troubleshooting

Common Issues

Inbox Overflow:

• Schedule immediate processing session
• Delete obvious low-value items first
• Process in batches by type
• Set calendar reminder for weekly review

Broken Links:

• Use attachment update script
• Manually verify critical links
• Commit after fixing links
• Document link structure

Git Conflicts:

• Always start with git pull
• Resolve conflicts immediately
• Don't force push
• Backup before major changes

Lost Files:

• Check git history: git log --all --full-history -- <path>
• Look in Archive folders
• Search by content: use Obsidian search
• Check recent commits for moves

---

Templates

Project README Template

---
created: YYYY-MM-DD
status: active
tags: [project]
deadline: YYYY-MM-DD
---

# Project Name

## Goal
[One sentence goal]

## Context
[Why this project matters]

## Deliverables
- [ ] Deliverable 1
- [ ] Deliverable 2

## Timeline
- Start: YYYY-MM-DD
- End: YYYY-MM-DD

## Resources
- [[Related Resource 1]]
- [[Related Resource 2]]

## Notes
[Project-specific notes]

Area Overview Template

---
created: YYYY-MM-DD
status: active
tags: [area]
type: area
---

# Area Name

## Purpose
[Why this area matters]

## Standards
[What success looks like]

## Active Projects
- [[Project 1]]
- [[Project 2]]

## Resources
- [[Resource 1]]
- [[Resource 2]]

## Review Schedule
[How often to review this area]

Resource Index Template

---
created: YYYY-MM-DD
tags: [resource, topic-name]
type: resource
---

# Topic Name - Index

## Overview
[Brief introduction to this topic]

## Key Concepts
- [[Concept 1]]
- [[Concept 2]]
- [[Concept 3]]

## Related Topics
- [[Related Topic 1]]
- [[Related Topic 2]]

## Sources
- [Source 1](URL)
- [Source 2](URL)

---

Memvid Workflows

Overview

Memvid is a semantic memory system that provides persistent context across Claude Code sessions. It uses vector embeddings to enable intelligent search and retrieval of previous decisions, preferences, and project context.

Core Concepts

Memory File (.mv2):

• Single portable file containing all data, embeddings, and indices
• Default location: .claude/memory/memvid.mv2
• Project-specific files: .claude/memory/[project-name].mv2

Semantic Search:

• Uses natural language queries
• Returns contextually relevant results
• No need for exact keyword matching

Tagging:

• Organize content with key-value tags
• Enable fast filtering and categorization
• Combine with semantic search for precision

Initial Setup

Check Server Status:

# Verify Memvid is running
# Check server version and features

Create Memory File (if not exists):

# Create new memory file at default location
# File: .claude/memory/memvid.mv2
# Description: Vault management context and preferences

Verify Creation:

# Check memory file info
# Should show 0 entries initially

Daily Workflows

1. Session Start - Query Context

Start every work session by retrieving relevant context:

# Search for general preferences
Query: "user preferences for organizing vault"

# Search for project-specific context
Query: "decisions about [project-name] structure"

# Search for recent changes
Query: "recent workflow updates"

Best Practice: Query first, work second. Always check memory before making decisions.

2. During Work - Capture Decisions

Document important decisions as you work:

What to Capture:

• Architectural decisions ("Why did we structure folders this way?")
• User preferences ("User prefers flat structure over deep nesting")
• Project constraints ("Project deadline: 2026-03-15")
• Code patterns ("Use wikilinks for all internal references")
• Tool choices ("Use mv not cp to avoid duplicates")

Example Captures:

# After organizing files
Content: "User prefers to keep inbox items under 20 files. Process weekly, not daily. Move files using mv command to avoid duplicates."
Tags: {"type": "preference", "topic": "inbox-management"}

# After making architectural decision
Content: "Decided to use PARA method for vault organization. Projects (time-bound), Areas (ongoing), Resources (reference), Archive (completed). Maximum 3 levels of nesting."
Tags: {"type": "decision", "topic": "structure", "date": "2026-01-07"}

# After learning constraint
Content: "Never move numbered folders (00-06) from vault root. These are core structure folders and must remain at top level."
Tags: {"type": "constraint", "topic": "folder-structure"}

3. After Changes - Commit to Memory

Always commit after adding content:

# Commit changes to persist them
# This ensures data is saved to disk

Important: Uncommitted changes may be lost. Commit after each add or batch of adds.

Common Use Cases

Use Case 1: Learning User Preferences

# Initial conversation about preferences
User: "I prefer concise writing without filler phrases"

# Store preference
Add text: "User writing preferences: Direct, concise communication. Avoid clichéd transitions like 'In today's world'. Avoid filler phrases like 'It's worth noting'. Use active voice and specific examples."
Tags: {"type": "preference", "topic": "writing-style"}
Commit: Yes

# Future sessions - retrieve preference
Search: "user writing preferences"
Result: [Returns stored preference for consistent communication]

Use Case 2: Project Context

# Starting new project
Add text: "Project: Weekly Review Automation. Goal: Create automated system to process inbox and generate weekly summaries. Tech stack: Node.js, Obsidian API. Deadline: 2026-02-01."
Tags: {"type": "project", "project": "weekly-review-automation", "status": "active"}
Commit: Yes

# Mid-project decision
Add text: "Weekly Review Automation: Decided to use Dataview plugin instead of custom scripts. Easier to maintain, better Obsidian integration."
Tags: {"type": "decision", "project": "weekly-review-automation"}
Commit: Yes

# Later session - retrieve context
Search: "weekly review automation project"
Result: [Returns project goals and decisions]

Use Case 3: Troubleshooting Patterns

# After solving a problem
Add text: "Git conflict resolution: When seeing merge conflicts after git pull, resolve manually in affected files, then git add . && git commit -m 'Resolve merge conflicts' && git push. Never force push."
Tags: {"type": "pattern", "topic": "git-workflow"}
Commit: Yes

# Future similar problem
Search: "how to resolve git conflicts"
Result: [Returns established pattern]

Use Case 4: Vault Organization Rules

# Document organizational decision
Add text: "Attachment naming convention: [RelatedNote]_[Description].[ext]. Example: ProjectProposal_Diagram.png. Store in 05_Attachments/Organized/ after processing."
Tags: {"type": "pattern", "topic": "attachments"}
Commit: Yes

# Later when organizing attachments
Search: "attachment naming convention"
Result: [Returns established pattern]

Advanced Features

Tag-Based Search:

# Find all decisions
Search by tag: key="type", value="decision"

# Find project-specific items
Search by tag: key="project", value="weekly-review-automation"

# Find all preferences
Search by tag: key="type", value="preference"

Export Search Results:

# Export for documentation
Query: "all organizational decisions"
Format: markdown
Top K: 20

# Creates formatted markdown with search results

List Recent Additions:

# View last 20 entries
Limit: 20

# Quick overview of recent context

Memory Info:

# Get memory statistics
# Shows: entries count, file size, creation date, last modified

Best Practices

DO:

• ✓ Query memory at start of every session
• ✓ Store decisions immediately after making them
• ✓ Use descriptive tags for easy retrieval
• ✓ Commit after adding content
• ✓ Store "why" not just "what" (reasoning behind decisions)
• ✓ Use natural language in queries
• ✓ Tag with both type and topic
• ✓ Review memory periodically to refresh context

DON'T:

• ✗ Store sensitive data (passwords, API keys, tokens)
• ✗ Store temporary data (errors, logs, debug output)
• ✗ Store file contents (use references instead)
• ✗ Forget to commit changes
• ✗ Use vague tags like "misc" or "other"
• ✗ Store data that changes frequently
• ✗ Duplicate information already in vault files

Tagging Guidelines

Standard Tag Structure:

type:[category]     - Primary classification
topic:[subject]     - Specific subject area
project:[name]      - Project association
date:[YYYY-MM-DD]   - When decision made
status:[state]      - Current state

Recommended Tags:

• type:preference - User preferences and settings

• type:decision - Architectural and design decisions

• type:constraint - Project limitations and requirements

• type:pattern - Established patterns and conventions

• type:context - Background information and rationale

• topic:structure - Organizational structure decisions

• topic:workflow - Process and workflow definitions

• topic:writing - Writing style and standards

• topic:git - Version control practices

• topic:attachments - File management patterns

Maintenance

Weekly Review:

# List recent additions
Limit: 50

# Review for:
- Outdated information
- Duplicate entries
- Missing tags
- Unclear descriptions

Monthly Cleanup:

• Search for outdated project references
• Archive completed project context
• Update changed preferences
• Consolidate similar entries

Quality Checks:

• Are tags consistent and descriptive?
• Do searches return relevant results?
• Is context clear without vault access?
• Are decisions documented with reasoning?

Troubleshooting

Issue: Search returns no results

• Check memory file exists: memvid_info
• Verify content was committed
• Try broader search terms
• Check tag filters

Issue: Too many irrelevant results

• Use more specific queries
• Add tag filters to narrow scope
• Increase specificity in stored content
• Use combined semantic + tag search

Issue: Forgetting to use memory

• Add "check memory" to session start checklist
• Set reminder in daily notes template
• Review recent memory additions weekly

Issue: Memory file too large

• Archive old project-specific memories
• Create separate memory files per major project
• Remove duplicate or outdated entries

Examples

Complete Session Example:

# === SESSION START ===

# 1. Query for context
Search: "inbox processing preferences"
Result: "User prefers weekly processing, keep under 20 items..."

Search: "PARA organizational structure"
Result: "PARA method: Projects, Areas, Resources, Archive..."

# 2. Work on task
# [Process inbox items, move files, organize notes]

# 3. Document new learnings
Add text: "User prefers to tag web clippings with both 'clipping' and specific topic tags for easier retrieval. Example: tags=[clipping, ai, research]"
Tags: {"type": "preference", "topic": "tagging"}
Commit: Yes

Add text: "Discovered user has separate organization for daily notes. Keep in 00_Inbox/ for last 7 days, then move to Archive. Format: YYYY-MM-DD.md"
Tags: {"type": "pattern", "topic": "daily-notes"}
Commit: Yes

# 4. Verify storage
Info: [Shows 2 new entries added]

# === SESSION END ===

Integration with Other Workflows

With Git Workflow:

# Store git conventions
Content: "Git commit message format: 'vault backup: YYYY-MM-DD HH:MM:SS' for routine backups. Use descriptive messages for specific changes."
Tags: {"type": "pattern", "topic": "git"}

With PARA Organization:

# Store PARA decisions
Content: "Project threshold: Create project folder when 3+ related files exist. Use Projects for time-bound work, Areas for ongoing responsibilities."
Tags: {"type": "decision", "topic": "para-method"}

With Daily Notes:

# Store daily routine preferences
Content: "Daily notes template: Focus section at top, Capture section for quick notes, Reflections at bottom. Review previous day's notes each morning."
Tags: {"type": "preference", "topic": "daily-workflow"}

---

Last Updated: January 07, 2026 Maintained By: Vault Owner Version: 2.0 (Consolidated from CLAUDE.md)