qbarev/para-plugin

Projekte

Projekte sind Vorhaben mit einem definierten Ziel und einem Endzustand – im Gegensatz zu Bereichen (Areas), die fortlaufend sind. Ein Projekt ist ein Ordner im Vault, gepaart mit einem Projekt im Aufgaben-Backend: Der Ordner enthält die Bedeutung des Projekts, das Backend seine Aufgaben (tasks.md). Jeder Aufgabenaufruf ist eine Operation aus tasks.md, ausgeführt gemäß dem Adapter für TASKS.

Basis-Schicht

Vor dem Handeln lesen, jeweils als ../../para/<datei>.md relativ zum Basisverzeichnis dieses Skills – diese enthalten die gemeinsamen Regeln, sie nicht aus dem Gedächtnis wiederholen:

• ../../para/paths.md – immer, einschließlich »Sprache«: die folgenden Zeichenketten stammen aus lang/<LANG>.md
• ../../para/tasks.md – immer: die Operationen, die Paarung, was eine Aufgabe ist
• ../../para/find-target.md – für overview und task
• ../../para/note-format.md – für create; für jeden Unterbefehl, »Legacy-Felder«
• ../../para/project-id.md – für create
• ../../para/dod.md – für create (Schreiben des Abschnitts project.dod) und overview
• ../../para/thresholds.md – für list und overview: Projekt-Reihenfolge, Veralterung, Horizonte, Aufgabenzählungen, Ausgabegröße
• ../../para/confirm.md – create und task schreiben (Stufe 1); list und overview schreiben nichts
• ../../para/move.md – für create, vor dem Schreiben eines Ordners, der kollidieren könnte

Unterbefehle

Das erste Wort von $ARGUMENTS wählt den Unterbefehl: list, create, overview, task. Wenn es keiner davon ist, ermitteln, welcher aufgrund des Wortlauts gemeint ist, und sagen, welchen du gewählt hast. Leeres $ARGUMENTS → list ausführen, dann fragen, was zu tun ist.

Jeder Unterbefehl begegnet Projekten, die älter sind als das Aufgaben-Backend: status, Tasks/ (note-format.md sagt, wann das Legacy ist), kein tasks_ref-Feld. Lesen wie note-format.md »Legacy-Felder« es sagt – berichten, niemals umschreiben.

---

create <beschreibung> – ein Projekt starten

Eingabe: was das Projekt ist, sein Ziel, Frist, erste Schritte. Leer → fragen, was das Projekt ist und sein Ziel.

1. Templates/Project.md von der Festplatte lesen, wortwörtlich.

2. Einen Titel ableiten gemäß note-format.md. Er wird auf drei Arten verwendet: als title und die H1 ohne den ID-Präfix, und – mit dem Präfix – als der Ordnername und der Übersichts-Dateiname. short vorschlagen gemäß note-format.md.

3. Die ID ausstellen gemäß project-id.md.

4. Die Ordnerstruktur erstellen unter Projects/:

   PROJ-xxxx <titel>/
   ├── PROJ-xxxx <titel>.md      ← Übersicht, von Templates/Project.md
   ├── Notes/
   ├── Resources/
   └── Results/
   

   Alle drei Unterordner, auch wenn leer. Kein Tasks/ (unter TASKS = files erstellt der Adapter ihn mit der ersten Aufgabe).

5. Das Frontmatter ausfüllen gemäß der Projekt-Zeile in note-format.md. created ist heute. deadline nur, wenn die Beschreibung eine angibt. tasks_ref bleibt leer bis Schritt 7 (unter pairing: none wird das Feld weggelassen).

6. Den Textkörper ausfüllen:

   • der Abschnitt project.goal – das Ziel / der gewünschte Endzustand. Erforderlich.
   • der Abschnitt project.value – was der Nutzer gewinnt, messbar oder eindeutig (note-format.md, »Drei Abschnitte über das Ergebnis«). Erforderlich. Wenn entweder dieser oder project.goal aus der Eingabe nicht klar hervorgeht, beide in einer Frage erfragen (confirm.md, Stufe 1.5) vor dem Schreiben.
   • der Abschnitt project.problem – was das Projekt ausgelöst hat.
   • der Abschnitt project.expected_result – die konkreten Artefakte und wo sie abgelegt werden.
   • der Abschnitt project.scope – nur die vom Nutzer genannten Elemente. Normalerweise leer: die Recherche-Aufgabe füllt ihn (tasks.md »Die Recherche-Aufgabe«).
   • der Abschnitt project.dod – Kontrollkästchen gemäß dod.md. Wenn die Beschreibung keine echten Prüfungen ableiten lässt, fragen – wie bei einem fehlenden project.goal.
   • der Abschnitt common.links – Wikilinks zu klar verwandten Notizen, sonst das Template's -.

7. Das Pendant erstellen gemäß tasks.md »Paarung«: project.create mit dem Titel und der ID. Unter pairing: separate die zurückgegebene ref in tasks_ref: schreiben; wenn der Aufruf fehlschlägt, dies mitteilen: der Ordner bleibt, ungepaart, und /projects task wird später anbieten, ihn zu paaren. Unter pairing: none gibt es kein Pendant und kein tasks_ref: das Schreiben überspringen.

8. Erste Aufgaben im neuen Projekt, ohne Daten:

   • die Recherche-Aufgabe gemäß tasks.md »Die Recherche-Aufgabe«, immer, es sei denn, der Nutzer hat den vollständigen Umfang bereits genannt – dann stattdessen in den project.scope-Abschnitt schreiben;
   • Schritte, die der Nutzer explizit genannt hat, hinzugefügt mit task.add und formuliert gemäß »Was eine Aufgabe ist«. Ein Schritt, der nicht als Aktion formuliert werden kann, ist eine Frage für die Recherche, keine Aufgabe.

   Niemals Schritte erfinden, die der Nutzer nicht genannt hat.

9. Berichten: den Pfad des Ordners, ID, Titel, short (mit dem Angebot ihn zu ändern), Frist, Ziel, die Wertzeile, den Namen des Backend-Projekts und die erstellten Aufgaben.

Wenn die Eingabe eine fortlaufende Verantwortung ohne Ende beschreibt, ist dies kein Projekt – dies mitteilen und /areas create stattdessen anbieten. Wenn es eine Idee ist, die der Nutzer nicht entschieden hat anzunehmen, mitteilen, dass es noch kein Projekt ist (tasks.md »Paarung«) und danbieten, es im Posteingang zu belassen (inbox.name).

---

task <projekt> <aufgabe> – eine Aufgabe hinzufügen

1. Das Projekt finden gemäß find-target.md, Operation »Aufgabe zu einem Projekt hinzufügen«. Das Ziel kann auch ein Bereichsprojekt aus AREA_TASK_PROJECTS in areas.md sein – nach Namen abgleichen.
2. Auflösen, wohin es geht: ein Bereichsprojekt → area; andernfalls die tasks_ref der Übersicht → project_ref (unter pairing: none ist der Projektordner die ref und dieser Schritt ist lediglich das Projekt).
   • pairing: separate und kein tasks_ref in der Übersicht → die task.unpaired-Zeichenkette ausgeben und anbieten, das Pendant zu erstellen (Schritt 7 von create). Bei Bestätigung das Pendant erstellen, dann fortfahren. Niemals die Aufgabe stattdessen in den Vault schreiben.
3. Die Aufgabe formulieren gemäß tasks.md »Was eine Aufgabe ist«. Wenn die Formulierung des Nutzers bereits passt, behalten; andernfalls die umformulierte Version in der Ankündigung vorschlagen. Wenn es keine Aktion sein kann, nach dem nächsten Schritt fragen (Stufe 1.5).
4. task.add mit project_ref oder area (unter TASKS = files ist ein vergebener Basisname ein Konflikt: note-format.md »Namenskonflikte«, nachfragen, kein stiller Suffix): den Text, eine Beschreibung für alles Längere, duration nur, falls angegeben. Die Datumsregel ist tasks.md »Felder«.
5. Berichten: die Aufgabe und das Projekt.

---

overview <projekt> – der Stand des Projekts

Schreibgeschützt. Schreibt nichts – weder in den Vault noch ins Backend. Wenn die Zusammenfassung etwas offenbart, das es zu beheben lohnt, dies sagen und den Nutzer entscheiden lassen.

1. Das Projekt finden gemäß find-target.md, Operation »Bericht erstatten über«. Ohne Argument die Projekte auflisten und nachfragen.

2. Die Übersichtsnotiz lesen: Frontmatter und die Abschnitte project.goal, project.value, project.expected_result, project.dod, common.links. Ein leeres Feld wird als leer gemeldet, niemals durch Rückschlüsse ausgefüllt.

3. Die Aufgaben lesen (task.list, offen): ihre Daten und Dauern. Die Anzahlen berechnen gemäß thresholds.md »Aufgabenzählungen«. Unter pairing: separate, kein Pendant → überspringen, und die task.unpaired-Zeichenkette ausgeben.

4. Notes/ lesen (und Results/, falls etwas darin ist) vollständig, bis zum Limit in thresholds.md – hier liegen tatsächlich Entscheidungen und Risiken.

5. Legacy. Wenn die Übersicht status / priority / value / estimate trägt oder der Ordner ein altes Tasks/ hat (note-format.md), eine Zeile hinzufügen, die overview.legacy-Zeichenkette mit {fields}, z.B. status, Tasks/ (3 Dateien) (die Ordneranzahl ist die overview.legacy_tasks-Zeichenkette), nur benennen, was vorhanden ist. Aufgaben-Notizen nicht auf Fortschritt prüfen; die Migration entscheidet, was überlebt.

6. Signale – nur die melden, die zutreffen:

   • die deadline des Projekts liegt in der Vergangenheit oder innerhalb des Horizonts in thresholds.md;
   • überfällige Aufgaben – um wie viele Tage angeben;
   • nichts eingeplant, während die Frist innerhalb des Horizonts liegt;
   • datierte Aufgaben ohne Dauer;
   • länger als der Projektschwellwert in thresholds.md keine Aktivität, gemessen wie dort angegeben (project.activity bei Paarung, ansonsten mtime, gemäß thresholds.md);
   • lose Wikilinks im Abschnitt common.links;
   • alle Akzeptanzkriterien abgehakt, während das Projekt noch in Projects/ ist – abgeschlossen und nicht geschlossen.

7. Im Chat ausgeben, in SPRACHE. Die Bezeichnungen sind Zeichenketten aus lang/<SPRACHE>.md, benannt in der Vorlage unten nach Schlüssel in geschweiften Klammern; hier mit den englischen Zeichenketten:

   ## PROJ-0001 · Project A
   
   **{overview.area}** Area A · **{overview.deadline}** 2026-10-31 — 14 Tage
   **{overview.tasks}** {count.scheduled} 3 · {count.overdue} 1 · {count.backlog} 6
   **{overview.acceptance}** ☑☐☐ 1/3
   
   ### {overview.essence}
   <Das Ziel, 1–2 Sätze.>
   <Das erwartete Ergebnis – eine Zeile.>
   <Der Wert – eine Zeile.>
   
   ### {overview.scheduled}
   - **Dem Lieferanten eine E-Mail schreiben** — Di 10-21, 30 Min
   - **Das Formular ausfüllen** — um 2 Tage überfällig, 1 h
   
   ### {overview.backlog}
   - Einen Termin vereinbaren
   - …und 3 weitere
   
   ### {overview.digest}
   - <Eine wichtige Entscheidung oder Schlussfolgerung aus Notes/ – in eigenen Worten.>
   
   ### {overview.signals}
   - Frist in 14 Tagen, nichts eingeplant
   

   Die geschweiften Klammern sind Schlüssel, kein wörtlicher Text: die Zeichenkette ausgeben, für die jeder Schlüssel steht. Daten sind das common.date-Format (2026-10-31; 10-31 in der Kurzform common.date_short, verwendet mit einem Wochentag aus common.weekdays in einer Aufgabenzeile); die Tage bis zur Frist sind common.days; Einheitenkürzel sind common.unit.*; eine überfällige Aufgabe trägt die task.overdue_by-Zeichenkette; der Backlog-Rest ist die overview.backlog_more-Zeichenkette ({n} = nicht angezeigte Aufgaben). Der overview.backlog-Abschnitt zeigt die ältesten undatierten Aufgaben bis zum Limit in thresholds.md. Jeden Abschnitt oder jedes Feld weglassen, das leer wäre. Ein leeres Results/ ist ein normaler Zustand.

---

list – die Projekte

Schreibgeschützt. Eine Zeile pro Projekt – der Index, keine Zusammenfassung: niemals Notes/ öffnen.

1. Die Ordner direkt unter Projects/ auflisten. Archivierte Projekte werden nicht aufgelistet – das ist /archive list.

2. Das Frontmatter der Übersicht lesen: id, title, area, deadline und unter pairing: separate tasks_ref. Ein Ordner ohne Frontmatter ist vor der Konvention – nach Ordnername mit der common.no_metadata-Zeichenkette ausgeben.

3. Die Aufgaben jedes Projekts mit einer ref lesen (task.list mit project_ref, offen), gezählt gemäß thresholds.md »Aufgabenzählungen«.

4. Ordnen gemäß thresholds.md »Projekt-Reihenfolge«.

5. Ausgeben, in SPRACHE, mit den list.*-, count.*- und task.unpaired-Zeichenketten – die Zeile ist kurz, daher ist die Backlog-Anzahl count.backlog_short (Kopfzeile list.header, Frist list.until mit dem Datum in common.date_short und, innerhalb des Horizonts von thresholds.md, (14 d) dahinter: die verbleibenden Tage und common.unit.day); hier mit den englischen Zeichenketten:

   **Projekte (4)**
   1. PROJ-0008 Project A — Area A · bis 10-31 (14 d) · eingeplant 2 · Backlog 3
   2. PROJ-0020 Project B — bis 10-31 (14 d) · eingeplant 0 · Backlog 3
   3. PROJ-0009 Project C — Area B · bis 02-28 · kein Pendant im Aufgabenmanager · altes Format
   4. PROJ-0027 Project D — Backlog leer
   Kein Pendant im Vault: „Project E“
   

   • Eine abgelaufene Frist: die list.deadline_passed-Zeichenkette.
   • Die list.legacy-Zeichenkette, wenn Legacy-Felder vorhanden sind oder ein altes Tasks/ existiert.
   • Ein Projekt mit leerem Backlog: die list.backlog_empty-Zeichenkette.
   • Die letzte Zeile (list.orphans) nennt Backend-Projekte, auf die keine Übersicht zeigt, gefunden als tasks.md »Anmerkungen zur Tabelle«, project.list, sagt. Weglassen, wenn leer oder wenn der Adapter project.list nicht unterstützt.
   • Jedes leere Feld weglassen, anstatt einen Platzhalter zu drucken. Ein leeres Projects/ ist eine gültige Antwort: es klar sagen.

Archivierte und vor der Konvention liegende Projekte

Projekte in Archive/ können älter sein als die Konventionen: kein Frontmatter, kein PROJ-xxxx- Präfix, keine Unterordner. Den Abschnitt project.goal aus der Notiz lesen, den Aufgabenabschnitt und overview.acceptance überspringen und klar sagen, dass es archiviert und im alten Format ist.

Hinweise

• Berechnen, nicht schätzen: Tageszählungen, Aufgabenzählungen und Überfälligkeitsspannen stammen vom Backend, den Dateien und dem heutigen Systemdatum. Wenn etwas nicht berechnet werden kann, weil ein Feld leer ist, sagen, dass es leer ist, anstatt zu raten.
• Eine Zusammenfassung berichtet über den Zustand; sie bewertet den Nutzer nicht. „um 5 Tage überfällig“, nicht „du hast das Projekt aufgegeben“.
• Alles in SPRACHE, Aufgaben eingeschlossen.