--- 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): ```yaml 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: ```markdown ## 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: ```yaml 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`.