PARA Obsidian Skill

What this skill does

This skill provides PARA-method decision logic for Obsidian vaults. It decides where notes belong, when to archive, and how to keep the vault healthy — while leaving file creation, markdown formatting, and Obsidian syntax to the installed base skills.

PARA is an organizational framework by Tiago Forte that structures information by action relevance, not topic:

• Projects — concrete initiatives with a goal and an endpoint
• Areas — ongoing responsibilities with no fixed end date
• Resources — reference knowledge for potential future use
• Archive — completed, paused, or inactive content

Read

references/classification-rules.md

for detailed classification heuristics.

---

Vault Configuration

Default paths for this vault (override in conversation if different):

paths:
  inbox: "0_Inbox"          # created on demand if missing
  projects: "1_Projects"
  areas: "2_Areas"
  resources: "3_Resources"
  archive: "4_Archives"

Default mode: cautious — suggest first, act only when confident or explicitly asked.

---

Core Workflow

For every PARA-related task, follow this sequence:

1. Read the note content, title, existing frontmatter, tags, and current file path
2. Collect signals — look for project indicators (deadlines, tasks, goals), area indicators (ongoing, recurring), resource indicators (reference, no action pressure), archive indicators (done, cancelled, historical)
3. Check conventions — respect existing

   para_type

   frontmatter; existing folder placement is a strong signal
4. Classify with a confidence level:

   high

   ,

   medium

   , or

   low

5. Plan frontmatter additions — only add fields from the schema, never overwrite non-PARA fields
6. Propose routing — suggest the target path
7. Assess risk — only act directly when confidence is high AND the user has given explicit permission or the mode is

   balanced

   /

   aggressive

8. Log changes when writing anything

When in doubt: set

needs_review: true

, place in Inbox, and explain why.

See

references/classification-rules.md

for the full decision tree.

---

Available Actions

capture

— Process new content

Accept raw text, meeting notes, ideas, or document descriptions. Classify them, propose or create a note in the right location, and set frontmatter.

Example trigger: "Capture this: Vorbereitung Workshop Führungsteam April" Output: PARA classification + proposed path + frontmatter draft

classify

— Classify an existing note

Read a note and determine its PARA type. Return classification, confidence level, and reasoning.

Example trigger: "Welcher PARA-Typ ist diese Notiz?" or "Klassifiziere 2_Areas/Weiterbildung/..." Output:

para_type

,

confidence

, explanation, suggested changes

route

— Determine or apply target location

Calculate the correct target folder for a note. In cautious mode: suggest only. With explicit permission: move the file.

Example trigger: "Wo gehört diese Notiz hin?" or "Route diese Notiz korrekt ein" Output: Current path → suggested path, reasoning, conflict check

normalize

— Fix frontmatter

Add missing PARA frontmatter fields to a note without touching non-PARA fields. Never remove existing fields.

Example trigger: "Normalisiere das Frontmatter dieser Notiz" or "Füge PARA-Metadaten hinzu" Output: Updated frontmatter block (show diff before applying)

review

— PARA hygiene report

Scan a folder or the whole vault for hygiene issues. See

references/review-playbook.md

for what to check.

Example trigger: "Mach einen PARA-Review" or "Zeig mir, was im Vault aufgeräumt werden sollte" Output: Structured report (projects without next steps, stale areas, inbox backlog, archiving candidates)

archive

— Archive a note defensively

Move a note to the Archive folder with

archived: true

,

archive_date

, and updated

status

. Never delete. Preserve all wikilinks.

Example trigger: "Archiviere dieses Projekt" or "Das Projekt ist abgeschlossen" Output: Confirmation of move + frontmatter changes (dry-run by default)

audit

— Full vault consistency audit

Scan all notes for PARA inconsistencies: missing frontmatter, wrong folder placement, orphaned notes, stale reviews. Produces a prioritized action list.

Example trigger: "Mach einen vollständigen Vault-Audit" or "Was stimmt in meinem Vault nicht?" Output: Audit report with actionable items

suggest

— Recommendation without changes

Give a PARA recommendation with full reasoning, but make no changes to any file.

Example trigger: "Was würdest Du mit dieser Notiz machen?" or "Vorschlag für diese Datei" Output: Recommendation + reasoning (read-only)

---

Safety Rules

These rules are non-negotiable regardless of mode:

1. No mass moves without explicit user authorization — always ask first
2. No deletion — archive means move, never delete
3. No overwriting non-PARA frontmatter fields — only add/update defined PARA fields
4. Low confidence → needs_review — never force a classification when unsure
5. Dry-run by default — show what would happen before doing it
6. Preserve wikilinks — never rename files in ways that break

   [[links]]

7. Log every structural change — use the change log format below
8. No reclassification from a single weak signal — require 2+ supporting indicators

Change Log Format

When making structural changes, append to a

PARA-Changelog.md

in the vault root:

## 2026-03-14
- Classified `Meeting Notes Team Alpha` → project (confidence: medium)
- Suggested move to `1_Projects/team-alpha/` (not yet applied, needs_review: true)
- Normalized frontmatter in `2_Areas/Weiterbildung/KI-Kurs.md`

---

Frontmatter Schema

Read

references/frontmatter-schema.md

for the full field definitions.

Quick reference — only write these fields:

para_type: project        # project | area | resource | archive
status: active            # active | on-hold | done | archived | reference | needs_review
review_date: 2026-03-21
confidence: high          # high | medium | low
needs_review: false
archived: false
archive_date:             # only when archiving
source: manual            # manual | meeting | import | daily-note | web

Never touch: titles, body content, existing tags not prefixed with

para/

, wikilinks, non-PARA frontmatter fields.

---

Cooperation with Other Skills

This skill handles: classification logic, routing decisions, PARA frontmatter, review reports

Leave to obsidian-markdown / obsidian-cli: file creation, markdown syntax, wikilink formatting, template application, dataview queries

When creating a new note as part of

capture

or

route

, delegate file creation to the obsidian-markdown or obsidian-cli skill if available. Only use direct file writes as fallback.

Read

references/compatibility-notes.md

for conflict avoidance rules.

---

Response Format

Always communicate:

1. What you classified/found (with

   para_type

   and

   confidence

   )
2. Why — at least 2 supporting signals
3. What you propose to change (as a clear list)
4. What you're uncertain about (if anything)
5. What you'll do next — or ask for permission before acting

For reviews and audits, use the structured report format in

references/review-playbook.md

.