para-skill

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"          # 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.