Init

Das Skill verwandelt den Ordner, in dem die Sitzung gestartet wurde, in einen PARA-Vault, der mit diesem Plugin verbunden ist, und hält ihn in diesem Zustand: Ein zweiter Durchlauf ergänzt fehlende Elemente und migriert ein älteres Schema. Es ist das einzige Skill, das die Konfiguration des Vaults schreibt, und das einzige, das ohne sie läuft.

Was es schreibt

Alles unten stehende und nichts anderes. REPO_ROOT, PARA_DIR, PARA_ROOT wie in paths.md definiert.

Was	Wo	Wie
die PARA-Ordner	`PARA_ROOT/` + `Projects`, `Areas`, `Resources`, `Archive`, `Inbox`, `Templates`	werden erstellt, wenn sie fehlen
die Notizvorlagen	`PARA_ROOT/Templates/`	werden aus dem Plugin bereitgestellt, nur wenn sie fehlen („Templates“)
das ID-Journal	`PARA_ROOT/Archive/.removed-ids`	nur seine Kopfzeile, nur wenn es fehlt (`project-id.md` „Das Journal“)
Vault-Konfiguration	`REPO_ROOT/.claude/para/vault.md`, `areas.md`; `adapter.md` nur wenn `TASKS` `mcp` ist	aus `config.example/`; wird nie überschrieben
der Plugin-Block	`REPO_ROOT/CLAUDE.md`	zwischen den Markern nur („CLAUDE.md“)
die Berechtigungen der Skills	`REPO_ROOT/.claude/settings.json`	zusammengeführt, nie ersetzt („Settings“)
Obsidian-Einstellungen	`REPO_ROOT/.obsidian/app.json`, `templates.json`	zusammengeführt („Obsidian“)
die Notizen und Ordner des Benutzers (nur B)	von ihrem aktuellen Ort in die PARA-Ordner	verschoben, nie bearbeitet – nur die Verschiebungen, die der genehmigte Plan auflistet („Szenario B“)
Projektübersichten (nur B)	`PARA_ROOT/Projects/PROJ-xxxx <titel>/`	neu, für einen Ordner, den der Benutzer ein Projekt genannt hat („Szenario B“)
das Paar-Schlüsselwort in Übersichten (nur C)	`PARA_ROOT/Projects/`, `PARA_ROOT/Archive/`	der eine Frontmatter-Schlüssel umbenannt, sonst nichts (`scenario-c.md`)
die Planungsdatei des Vaults (nur C)	`REPO_ROOT/.claude/local/planning.md`	neu, aus dem alten Tooling übernommen (`scenario-c.md`)
das alte eingebettete Tooling (nur C)	`REPO_ROOT/.claude/`, `CLAUDE.md`, die Dokumente der alten Vorlage	in den macOS-Papierkorb, Stufe 2 (`scenario-c.md`)

Basisschicht

Vor dem Handeln lesen, jede als ../../para/<datei>.md relativ zum Basisverzeichnis dieses Skills (und ../../config.example/, ../../lang/, ../../templates/ auf die gleiche Weise):

../../para/paths.md – immer: die beiden Wurzeln, „Sprache“, der Adapter für TASKS. Alles, was init schreibt, muss damit übereinstimmen.
../../para/tasks.md – die Operationen, „Paarung“, „Backend fehlt“
../../para/adapters/mcp-generic.md – wenn TASKS mcp ist; der Adapter für jeden anderen Wert wird von paths.md benannt
../../para/note-format.md – das Frontmatter-Schema, dem die Vorlagen entsprechen müssen
../../para/migrations.md – das aktuelle SCHEMA des Plugins und wie eine Migration abläuft
../../para/claude-md-block.md – der Block für CLAUDE.md
../../para/confirm.md – die Stufen; der Plan unten zeigt, wie init sie erfüllt
../../para/project-id.md – „Das Journal“: die Kopfzeile des ID-Journals (Schritt 5.1)
../../config.example/vault.md, areas.md, adapter.md – die Form der Konfiguration
nur Szenario B: ../../para/move.md (wie eine Verschiebung Links behält), project-id.md (Ausstellen einer ID), ../../para/thresholds.md (die Bereichs-Verfallsschwelle und „Die Grenze von mtime“), paths.md „IGNORE“
../../lang/<LANG>.md sobald LANG bekannt ist: die init.*-Zeichenfolgen
nur Szenario C und Cs Überreste bei einem erneuten Durchlauf: scenario-c.md im Basisverzeichnis dieses Skills – alles über das alte Layout; auch ../../para/move.md (der Papierkorb)

SKILL_DIR unten ist das Basisverzeichnis dieses Skills, wie es das Harness meldet.

Regeln für den gesamten Durchlauf

REPO_ROOT ist das Arbeitsverzeichnis der Sitzung, als absoluter Pfad (pwd). Dies ist der eine Ort, an dem das Plugin eine Wurzel aus dem Arbeitsverzeichnis übernimmt: init schreibt sie für jedes andere Skill auf. Der Plan sagt, welcher Ordner es ist, sodass eine Sitzung, die am falschen Ort gestartet wurde, erkannt wird, bevor etwas geschrieben wird.
Bevor das „Ja“ zum Plan kommt, wird nichts geschrieben. Untersuchen, Fragen und Testen des Aufgaben-Backends sind schreibgeschützt.
vault.md wird zuletzt geschrieben. Es markiert, dass ein Vault eingerichtet ist; ein unterbrochener Durchlauf hinterlässt kein vault.md und der nächste Durchlauf beginnt von vorne, wobei die bereits erledigte Arbeit gefunden wird.
Jeder Schritt ist idempotent: Erstellen, wenn es fehlt, zusammenführen, wenn es vorhanden ist, nie überschreiben. Ein zweimaliges Ausführen von init hintereinander ändert beim zweiten Mal nichts.
Jeden Pfad in Anführungszeichen setzen (paths.md „Regeln“). REPO_ROOT kann Leerzeichen enthalten.
Sprache. Bis LANG gewählt ist, in der Sprache des Benutzers sprechen (Englisch, wenn es nichts gibt, an dem man sich orientieren kann – ein bloßes /para:init). Von da an ist alles in LANG gemäß paths.md „Sprache“, einschließlich der verbleibenden Fragen; die Überschriften des Plans und des Berichts sind die init.*-Zeichenfolgen.

Vorab gegebene Antworten

$ARGUMENTS kann bereits Antworten enthalten: die Sprache, PARA_DIR („der Standard“ bedeutet der Vorgeschlagene), das Aufgaben-Backend, das Areas-Modell, in Szenario B die Sortierantworten (pro Ordner oder Wurzelnotiz und für die doppelten Namen), die Snapshot-Antwort und eine Genehmigung des Plans. Jede gegebene Antwort nehmen und nicht erneut fragen; nur das fehlende fragen. Eine Antwort, die keine gültige Wahl ist, wird erneut gefragt, unter Angabe des Grundes.

Eine vorab gegebene Genehmigung bedeutet: den Plan anzeigen, dann ohne Warten anwenden – aber nur, solange jede Zeile des Plans etwas hinzufügt (einen Ordner, eine Datei, einen Schlüssel, einen Eintrag). Eine Zeile, die etwas bereits Vorhandenes ändert oder ersetzt (ein abweichender Obsidian-Wert, ein anderer CLAUDE.md-Block, eine Vorlage in einer Migration, REPO_ROOT in einem vorhandenen vault.md) ist Stufe 2 (confirm.md): der Plan wird angezeigt und init wartet selbst dann auf ein „Ja“.

Szenario Bs Verschiebungen sind von zwei Arten, und dies ist die eine Aussage darüber, wie eine vorherige Genehmigung sie abdeckt. Eine Verschiebung, die der Benutzer in seinen eigenen Antworten entschieden hat (B3 oder die Sortierantworten in $ARGUMENTS), ändert, wo eine Notiz ist, nie, was sie sagt, und confirm.md ordnet Verschiebungen in Stufe 1 ein: das „Ja“ des Plans, zu diesem Zeitpunkt oder vorab gegeben, deckt sie ab. Eine Verschiebung, die allein durch die Regeln entschieden wird (B2: nach Archive/ oder Resources/), ist inits eigenes Urteil über die Notizen des Benutzers: sie benötigt ein Live-„Ja“ zu dem Plan, der sie zeigt, auch wenn eine Genehmigung vorab gegeben wurde. In jedem Fall wird der Snapshot vor den Verschiebungen angeboten (Schritt 4). Eine vorab beantwortete Sortierfrage wird nicht gestellt; eine unbeantwortete wird gestellt, und vor ihrer Antwort wird nichts angewendet, Genehmigung oder nicht.

Schritt 1 – Prüfen

Nur lesen. Herausfinden, was der Ordner ist, und das Szenario benennen.

REPO_ROOT=$(pwd)
ls -A "$REPO_ROOT"
ls "$REPO_ROOT/.claude" "$REPO_ROOT/.claude/para" "$REPO_ROOT/.claude/skills" 2>/dev/null
# das alte eingebettete Layout (Szenario C): sein Konfigurationsordner oder seine Basisschicht
ls -d "$REPO_ROOT/.claude/para/local" "$REPO_ROOT/.claude/para/paths.md" 2>/dev/null   # altes Layout
# Skill-Ordner, die wie die alten eingebetteten Skills benannt sind: gemeldet, niemals C für sich allein
for s in inbox projects areas resources archive remove vault-lint; do
  [ -f "$REPO_ROOT/.claude/skills/$s/SKILL.md" ] && echo "altes Skill: $s"; done
# Notizen: jede .md, die nicht unter einem Punkt-Eintrag von REPO_ROOT liegt, außer den eigenen Dateien des Repositorys
# und Vorlagen (Punkt-Einträge werden relativ zu REPO_ROOT entfernt, sodass ein Vault, der selbst unter einem
# Punkt-Verzeichnis liegt, immer noch gesehen wird)
find "$REPO_ROOT" -mindepth 1 -name '.*' -prune -o -name "*.md" -not -path "*/Templates/*" \
  ! -path "$REPO_ROOT/CLAUDE.md" ! -path "$REPO_ROOT/README.md" ! -path "$REPO_ROOT/CHANGELOG.md" -print | head -50
# ein Vault über diesem Ordner: init wurde in einem Unterordner gestartet
d=$(dirname "$REPO_ROOT")
while [ "$d" != "/" ] && [ "$d" != "$HOME" ]; do
  { [ -e "$d/.claude/para/vault.md" ] || [ -d "$d/.obsidian" ]; } && echo "Vault über: $d"
  d=$(dirname "$d")
done

Vor allem anderen anhalten, wenn:

REPO_ROOT $HOME oder / ist – kein Vault; dies mitteilen.
ein Vault darüber gefunden wurde – „führe /para:init von <diesem Ordner> aus“ sagen und anhalten; niemals einen Vault innerhalb eines anderen einrichten.

Dann entscheiden, in dieser Reihenfolge, und mitteilen, was gefunden wurde und welcher Fall vorliegt:

Einrichten – .claude/para/vault.md existiert → „Erneuter Durchlauf und Migration“ unten.
Szenario C – das alte eingebettete Tooling, erkannt an seiner alten Basisschicht oder Konfiguration nur (die altes Layout-Zeile oben): sein Konfigurationsordner local/ oder seine Basisschicht-Datei paths.md innerhalb von .claude/para/. → „Szenario C“. Ein Skill-Ordner, der wie eines der alten Skills benannt ist (die altes Skill:-Zeilen) ohne eines von beiden ist nicht C: gehe nach den Regeln unten zu B oder A weiter. Mitteilen, welcher Ordner gefunden wurde und dass init ihn in Ruhe lässt; der Plan nennt ihn unter „nicht erledigt“ erneut. Ein .claude/para/, das nur die Konfigurationsdateien dieses Plugins enthält (areas.md, adapter.md) und kein vault.md, ist nicht C: es ist ein erster Durchlauf von init, der vor vault.md unterbrochen oder abgelehnt wurde. Gehe wie bei einem ersten Durchlauf zu B oder A unten weiter, als ob es nicht da wäre, außer dass diese Dateien die Konfiguration des Vaults sind – niemals überschrieben – und eine Frage, die sie bereits beantworten (Frage 4 für areas.md), nicht erneut gestellt wird. Der Durchlauf ergänzt den Rest.
Szenario B – Notizen wurden gefunden (das find oben hat etwas ausgegeben). → „Szenario B“.
Szenario A – ansonsten: ein leerer Ordner oder einer, der nur Nicht-Notiz-Dateien enthält (ein .obsidian/ eines neuen Obsidian-Vaults, eine CLAUDE.md). → Schritt 2.

Schritt 2 – Fragen

Eine nach der anderen, in dieser Reihenfolge, jede überspringen, die vorab beantwortet wurde. Jede Frage zeigt ihre Wahlmöglichkeiten und, wo vorhanden, die Voreinstellung.

Sprache (LANG). Die Wahlmöglichkeiten sind die Sprachen, die das Plugin liefert: ein Code mit sowohl lang/<code>.md als auch templates/<code>/ (paths.md „Sprache“):
```
for f in "$SKILL_DIR"/../../lang/*.md; do l=$(basename "$f" .md)
  [ -d "$SKILL_DIR/../../templates/$l" ] && echo "$l"; done
```
PARA-Ordner (PARA_DIR). Standard pro Szenario: A – PARA, ein Unterordner, damit das Tooling und die Notizen getrennt bleiben; B – ., damit die PARA-Ordner neben den eigenen Ordnern des Benutzers liegen, außer wie „Szenario B“ sagt. . setzt die PARA-Ordner direkt in REPO_ROOT. Gültig: . oder ein Ordnername – kein /, nicht mit . beginnend, keiner der PARA-Ordnernamen selbst.
Aufgaben-Backend (TASKS). Die Wahlmöglichkeiten sind todoist, files oder mcp; das erste wird empfohlen. In einem Satz mitteilen, was jedes bedeutet: Posteingang und Projekte einer App; Aufgabennotizen im Vault, keine App; jede andere Aufgaben-App, die über MCP verbunden ist. Dann testen – „Testen des Backends“ unten. Ein Wert, dessen Test fehlgeschlagen ist, wird nie aufgezeichnet.

Areas-Modell (areas.md). Eine Frage: Sind Areas gruppiert – none oder die Namen der Gruppen (z. B. Arbeit, Zuhause)? Alles andere wird abgeleitet und im Plan angezeigt, wo der Benutzer es ändern kann:

Schlüssel	Gruppiert	`none`
`GROUPING`	der Feldname, `sphere`, es sei denn, der Benutzer hat einen benannt (der Schlüssel der Startvorlagen)	`none`
`GROUPS`	die angegebenen Namen	leer
`PLACEMENT`	`Areas/<GRUPPE>/<titel>.md`	`Areas/<titel>.md`
`REVIEW_GROUPING`	ein Block pro Gruppe, Gruppen ohne etwas zu melden weggelassen	eine flache Liste
`PLACEMENT_CHECK`	Das `GROUPING`-Feld einer Notiz muss den Namen des übergeordneten Ordners nennen, unter dem sie liegt	`none`
`AREA_TASK_PROJECTS`	die `GROUPS`-Namen	ein Name: die `areas.review.heading`-Zeichenfolge

Testen des Backends

Der Test ist inbox.list, ausgeführt gemäß dem Adapter für den gewählten Wert (paths.md). Er ist schreibgeschützt; ein leerer Posteingang ist ein Erfolg. Nur die Anzahl ausgeben, niemals die Erfassungen.

files – nichts zu testen: der Adapter ist die Festplatte, und „Backend fehlt“ kann nicht vorkommen (tasks.md).
mcp – jetzt die Schritte 1–6 von adapters/mcp-generic.md ausführen. Schritt 1, der keine Werkzeuge findet, ist ein fehlgeschlagener Test. Schritt 6 ist der Test, wenn der Benutzer zustimmt und die App einen Posteingang hat; andernfalls sagt der Plan, dass die Zuordnung unbestätigt ist. Die Schritte 7–8 gehören zum Plan und zu „Schritt 5“ unten.
Jeder andere Wert – inbox.list gemäß seinem Adapter ausführen. Wenn die Werkzeuge des Adapters nicht in dieser Sitzung sind oder der Aufruf fehlschlägt: dies in einem Satz mitteilen (tasks.md „Backend fehlt“), den Wert nicht aufzeichnen, und stattdessen files anbieten – oder die App verbinden und /para:init erneut ausführen. Niemals einen TASKS-Wert schreiben, dessen Test nicht erfolgreich war, und niemals einen Wert aufzeichnen, während versprochen wird, später zu wechseln.

Schritt 3 – Der Plan

Eine Liste von allem, was erstellt, zusammengeführt oder geändert wird, mit der Überschrift der init.plan.heading-Zeichenfolge. Es ist ein Vorschlag, den der Benutzer bearbeitet, keine Ankündigung: Eine Bearbeitung erstellt einen neuen Plan, der erneut angezeigt wird. Er endet mit der init.plan.approve-Zeichenfolge, und nichts wird vor einem „Ja“ angewendet (oder der vorab gegebenen Genehmigung, innerhalb der Grenzen, die „Vorab gegebene Antworten“ setzt).

Der Plan nennt in dieser Reihenfolge:

REPO_ROOT (dieser Ordner) und PARA_ROOT.
Die zu erstellenden Ordner und das ID-Journal, wenn es fehlt.
Die zu kopierenden Vorlagen, jede mit den Änderungen, die „Templates“ daran vornimmt. In Szenario B hier: die Verschiebungen, die Projekte, IGNORE, die zurückgehaltenen Duplikate und die Links, die brechen werden („Szenario B“, „Der B-Teil des Plans“).
Die Konfiguration: jeder Schlüssel von vault.md und areas.md mit seinem Wert; für mcp die Adaptertabelle (mcp-generic.md Schritt 7 – das „Ja“ des Plans ist das „Ja“ dieser Tabelle).
CLAUDE.md, .claude/settings.json, .obsidian/app.json, .obsidian/templates.json: was zu jeder hinzugefügt wird. Jeder vorhandene Wert, der sich ändern würde, ist eine eigene Zeile, die den alten und den neuen Wert zeigt.
Das Testergebnis: Das Backend hat geantwortet (mit der Posteingangsanzahl) oder files.
Was nicht erledigt wird und warum (eine bereits vorhandene Vorlage, ein beibehaltener Wert).

Schritt 4 – Snapshot (nur B und C)

Bevor ein Plan angewendet wird, der einen vorhandenen Vault berührt, eine ZIP-Kopie daneben anbieten – immer gefragt, Ablehnung akzeptiert, eine vorab gegebene Antwort genommen. Sie wird in derselben Nachricht wie die Genehmigung des Plans gefragt (die init.snapshot-Zeichenfolge), sodass der Benutzer einmal antwortet:

zip_path="$(dirname "$REPO_ROOT")/$(basename "$REPO_ROOT")-backup-$(date +%Y-%m-%d).zip"
ditto -c -k --keepParent "$REPO_ROOT" "$zip_path"

Szenario A hat nichts zu speichern und überspringt dies.

Schritt 5 – Anwenden

Nach dem „Ja“ des Plans: Jede Zeile des Plans in der Reihenfolge des Plans ausführen, gemäß ihrem Schreibbefehl (Erstellen, Zusammenführen, Verschieben gemäß ../../para/move.md). vault.md zuletzt schreiben. Bei einem Fehler: melden, anhalten, init nicht erneut ausführen – der Plan wurde nicht vollständig angewendet, und der nächste Durchlauf beginnt bei Schritt 1.

Schritt 6 – Bericht

Eine Zusammenfassung dessen, was getan wurde, mit der Überschrift der init.report.heading-Zeichenfolge. Jede Zeile des Plans wiederholen und mit ✓ (erledigt) oder ✗ (fehlgeschlagen) markieren.

Szenario B (Notizen vorhanden)

B1 – Vorhandene Ordner erkennen

# Jeden Ordner in REPO_ROOT auf oberster Ebene (kein Punkt-Eintrag, kein Templates/) als mögliches Projekt,
# Bereich oder Ressource prüfen
for dir in "$REPO_ROOT"/*/; do
  d=$(basename "$dir")
  # ... (Logik zur Klassifizierung)
done

B2 – Verschiebungen und Projekte vorschlagen

Basierend auf der Klassifizierung werden die Ordner und Notizen innerhalb der PARA-Struktur platziert. Dies wird im Plan detailliert dargestellt.

B3 – Benutzereingaben zu Sortierung und Duplikaten

Der Benutzer wird gefragt, wie mit doppelten Namen umzugehen ist und ob Notizen pro Ordner oder als flache Liste sortiert werden sollen.

Szenario C (Altes Tooling vorhanden)

Siehe scenario-c.md in diesem Skill-Verzeichnis für die vollständige Migrationslogik.

Sprachen und Vorlagen

Siehe ../../lang/ und ../../templates/ für unterstützte Sprachen und deren Vorlagen.

qbarev/para-plugin

Was ist para-plugin?

In Ihrer bevorzugten KI fragen

Dokumentation