| name | para-skill |
| description | PARA method knowledge management for Obsidian vaults. Use this skill whenever the user wants to organize notes using PARA (Projects, Areas, Resources, Archive), classify a note into a PARA category, route a note to the right vault folder, normalize frontmatter fields, run a PARA hygiene review, suggest archiving, audit vault structure, or process new knowledge inputs into an existing PARA-based vault. Also trigger when the user mentions inbox processing, vault cleanup, note classification, PARA review, or asks "where does this note belong?". Works with existing Obsidian skills (obsidian-markdown, obsidian-cli) — never replaces them.
|
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"
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:
- Read the note content, title, existing frontmatter, tags, and current file path
- Collect signals — look for project indicators (deadlines, tasks, goals), area indicators (ongoing, recurring), resource indicators (reference, no action pressure), archive indicators (done, cancelled, historical)
- Check conventions — respect existing
para_type frontmatter; existing folder placement is a strong signal
- Classify with a confidence level:
high, medium, or low
- Plan frontmatter additions — only add fields from the schema, never overwrite non-PARA fields
- Propose routing — suggest the target path
- Assess risk — only act directly when confidence is high AND the user has given explicit permission or the mode is
balanced/aggressive
- 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:
- No mass moves without explicit user authorization — always ask first
- No deletion — archive means move, never delete
- No overwriting non-PARA frontmatter fields — only add/update defined PARA fields
- Low confidence → needs_review — never force a classification when unsure
- Dry-run by default — show what would happen before doing it
- Preserve wikilinks — never rename files in ways that break
[[links]]
- Log every structural change — use the change log format below
- 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
status: active
review_date: 2026-03-21
confidence: high
needs_review: false
archived: false
archive_date:
source: manual
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:
- What you classified/found (with
para_type and confidence)
- Why — at least 2 supporting signals
- What you propose to change (as a clear list)
- What you're uncertain about (if anything)
- 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.
