Autonom & dauerhaft zusammenarbeiten

Sobald ein KI-Werkzeug angebunden ist (Ein KI-Werkzeug anbinden), kannst du die Zusammenarbeit verstetigen: Mit dem mitgelieferten Worker-Skill arbeitet dein Agent deinen Datenordner eigenständig ab — auf Zuruf oder dauerhaft im Hintergrund, sodass ihr beinahe in Echtzeit zusammenarbeitet.

Eine gemeinsame Aufgabenbasis für dich und deine Agenten

TandemLoop ist beides: dein persönliches System, um dein Leben und deine Projekte zu managen — und eine geteilte Aufgabenbasis, auf der du mit unterschiedlichsten KI-Agenten zusammenarbeitest. Weil alles als schlichte Dateien im Datenordner liegt, ist dieser Datenordner die gemeinsame Wahrheit: Du planst und entscheidest, ein oder mehrere Agenten lesen denselben Stand, schlagen vor und erledigen Zugewiesenes. Kein Agent ist fest eingebaut, keiner ist exklusiv — du kannst Werkzeuge wechseln oder kombinieren, und alle arbeiten am selben Bestand weiter.

Der Worker-Skill

Der Worker-Skill ist eine kompakte Anleitung, die du deinem KI-Werkzeug gibst. Sie beschreibt einen wiederkehrenden Arbeitszyklus:

• zuerst deine Antworten auf seine Rückgaben einsammeln und umsetzen,
• verfügbare, ihm zugewiesene Aufgaben (assigned_to: ai) finden und nach Priorität abarbeiten,
• offene Proposals (falls aktiviert) auf neues Feedback von dir prüfen und überarbeiten,
• Ergebnisse zur Prüfung zurückgeben oder mit einer Rückfrage an dich zurückgeben.

Er hält sich strikt an den Arbeitsvertrag aus AGENTS.md: Ohne Proposals legt er Neues an und ändert Bestehendes direkt — nachvollziehbar im Verlauf deiner Aufgaben —, löscht aber nur auf deinen Auftrag und erledigt oder verwirft deine Aufgaben nicht eigenmächtig; mit Proposals schlägt er alles Strukturelle als Proposal vor — du behältst die Kontrolle.

Zurück vom Agenten

Gibst du Aufgaben an den Agenten ab, bekommst du sie auch zurück: Hat er etwas vorbereitet, gibt er die Aufgabe zur Prüfung zurück; braucht er eine Entscheidung, Information oder Zulieferung, stellt er eine Rückfrage. Jede Rückgabe trägt eine Notiz des Agenten — was er getan hat, wo das Ergebnis liegt und was du tun sollst bzw. seine Frage.

Wo du Rückgaben siehst:

• In der Seitenleiste unter der Inbox steht Zurück vom Agenten mit der Anzahl offener Rückgaben, darunter — sobald es welche gibt — getrennt Zur Prüfung, Rückfrage und Beim Agenten. Auf dem iPhone ist es der Tab Zurück.
• Überall, wo die Aufgabe erscheint — in Projekten, Views, Board, Tabelle, Kalender —, trägt sie ein eigenes Symbol: eine Sprechblase mit Haken (zur Prüfung) bzw. mit Fragezeichen (Rückfrage). Ein Klick darauf zeigt die Notiz formatiert mit klickbaren Links, samt der Reaktionen.
• In den Details der Aufgabe steht die Rückgabe ganz oben.

So reagierst du — direkt in der Liste, im Fenster am Symbol, in den Details oder im Kontextmenü:

Jede Reaktion lässt sich über den Hinweis unten mit Rückgängig zurücknehmen. Jede Reaktion landet samt Kommentar bzw. Antwort im Verlauf der Aufgabe; so bleibt das Hin und Her nachvollziehbar — wer wann was gesagt hat. Beim nächsten Durchlauf erkennt der Agent deine Reaktion eindeutig und kümmert sich zuerst um Nacharbeiten und Antworten. In Views kannst du nach dem Status Zur Prüfung bzw. Rückfrage filtern, nach @is_handback und nach deiner Reaktion; im Board erscheinen beide als eigene Spalten neben Aktiv.

Beim Agenten: Der Agent läuft außerhalb von TandemLoop — die App kann ihn nicht starten. Bis er deine Nacharbeit oder Antwort aufnimmt, steht die Aufgabe in Zurück vom Agenten unter Beim Agenten, mit der Zeit seit deiner Reaktion und dem Zeitpunkt, zu dem der Agent zuletzt gearbeitet hat (den vermerkt er bei jedem Durchlauf in _config/agent.yaml). Starte deinen Agenten dann oder gib ihm über Auftrag kopieren den passenden Satz. Sobald er die Aufgabe aufnimmt, verschwindet sie dort, und du bekommst eine Mitteilung. Läuft dein Agent regelmäßig, etwa über einen Zeitplan, musst du nichts tun.

Installation: Text kopieren, Agent übergeben

Du installierst den Skill, indem du seinen Text deinem Werkzeug übergibst — kein Download, keine Konfigurationsdatei.

1. Werkzeug auf den Datenordner richten (siehe Ein KI-Werkzeug anbinden).
2. Skill-Text kopieren — vollständig aus dem Abschnitt Der Skill-Text zum Kopieren am Ende dieses Kapitels.
3. Dem Werkzeug übergeben. Füge den Text in dein KI-Werkzeug ein. Die erste Zeile des Textes weist das Werkzeug an, daraus einen wiederverwendbaren Skill namens tandem-worker zu machen — du musst also nichts weiter erklären.
4. Aufrufen. Danach startest du einen Durchlauf mit /tandem-worker (oder der entsprechenden Aufruf-Form deines Werkzeugs).

Dauerbetrieb: beinahe in Echtzeit mitlaufen

Statt jeden Durchlauf von Hand zu starten, kannst du den Skill wiederholt ausführen lassen. Je kürzer das Intervall, desto näher fühlt sich die Zusammenarbeit an Echtzeit an: Du legst eine Aufgabe an oder schreibst Feedback in ein Proposal, und kurz darauf reagiert dein Agent. Der genaue Weg hängt vom Werkzeug ab:

Die genaue Syntax und Verfügbarkeit dieser Loop-Mechanismen gehören zum jeweiligen Werkzeug, nicht zu TandemLoop — sieh im Zweifel in dessen Dokumentation nach.

Verschiedene Agenten anbinden

Der Weg ist für jedes agentische Werkzeug derselbe: Zugriff auf den Datenordner geben, auf AGENTS.md hinweisen, den Worker-Skill übergeben. Zwei Beispiele über die im vorigen Kapitel genannten hinaus:

• OpenClaw — ein quelloffener persönlicher Agent, der lokale Dateien liest und schreibt, ein eigenes Skill-System mitbringt und Aufgaben per Cron zeitgesteuert ausführt. Du richtest ihn auf deinen Datenordner und gibst ihm den Worker-Skill.
• Hermes Agent — ein quelloffener, dauerhaft laufender Agent mit lokalem Dateizugriff und eigenem Skill-Konzept. Er kann den Datenordner rund um die Uhr betreuen.

Weil alle denselben Datenordner und denselben Arbeitsvertrag (AGENTS.md) nutzen, kannst du Agenten mischen oder wechseln — solange jeweils nur einer gleichzeitig schreibt, bleibt eure gemeinsame Aufgabenbasis konsistent.

Der Skill-Text zum Kopieren

Kopiere den folgenden Text vollständig und übergib ihn deinem KI-Werkzeug. (Identisch mit der mitgelieferten Vorlagedatei docs/agent-skills/tandem-worker.md.)

# /tandem-worker – Autonomer Arbeitszyklus für TandemLoop

> **An das KI-Werkzeug, das diesen Text erhält:** Mach aus dem Folgenden einen
> wiederverwendbaren Skill (bzw. eine gespeicherte Anweisung / einen Slash-Befehl) mit
> dem Namen `tandem-worker`. Führe ihn aus, wann immer ich `/tandem-worker` sage –
> einmalig oder periodisch in einer Schleife. Voraussetzung: Du hast Lese- und
> Schreibzugriff auf meinen TandemLoop-Vault-Ordner.

Ein Durchlauf eines autonomen Arbeitszyklus für einen TandemLoop-Vault. Du sammelst
zuerst die Antworten des Menschen auf deine Rückgaben ein, scannst den Vault nach
zugewiesenen, verfügbaren Aufgaben, prüfst offene Proposals auf neues Feedback, arbeitest
Aufgaben ab und gibst Ergebnisse und Rückfragen an den Menschen zurück – stets im Rahmen
des Arbeitsvertrags aus `AGENTS.md`.

---

## Pflichtlektüre

Lies diese Dateien **einmalig pro Session** (nicht bei jedem Durchlauf). Sie sind die
verbindliche Quelle der Wahrheit; dieser Skill beschreibt nur den Ablauf.

| Datei | Liefert |
|-------|---------|
| `AGENTS.md` (Vault-Wurzel) | Arbeitsvertrag: erlaubte/verbotene Aktionen, Verzeichnisstruktur |
| `_system/docs/data-model.md` | Felder, Enums, Pflichtfelder pro Entity |
| `_system/docs/proposal-system.md` | Proposal-Format, alle Aktionstypen, Referenz-Regeln (nur bei aktivierten Proposals) |
| `_system/docs/update-rules.md` | Schreibrechte, Entscheidungsbaum |

---

## Grundprinzip

Tandem: Der Mensch gibt die Richtung vor, die KI liefert Kraft. Die Kontrolle bleibt
immer beim Menschen. Ob Proposals aktiviert sind, steht in `AGENTS.md`. Daraus folgen
drei Kanäle:

- **Direkt erlaubt:** Tasks mit `assigned_to: ai` inhaltlich pflegen (Titel, Body,
  `status`, Datumsfelder, `waiting_for`, `tags`, `delegation`, `repeat`, eigene
  Attribute). Ohne Proposals außerdem Neues überall anlegen, wo es hingehört, und
  Bestehendes ändern und verschieben (Tasks, Projekte, Milestones, Bereiche, Ordner,
  Views; Tags anlegen) – mit Log-Eintrag an jedem geänderten Task des Menschen. Mit
  Proposals nur neue Tasks in `_inbox/`. In beiden Fällen gelten die Ausnahmen aus
  `AGENTS.md` (Attribut-Definitionen, Themes, Erinnerungen auf Wunsch des Menschen).
- **Nur auf Auftrag bzw. als Proposal:** ohne Proposals Löschen, Tasks des Menschen
  erledigen oder verwerfen und Spezifikationen ändern – ohne Auftrag per Rückfrage
  (`needs-input`) an einem eigenen Task klären; mit Proposals alles außer dem Obigen
  **als Proposal** in `_proposals/`.
- **Kommunikation & Feedback:** über die **Rückgabe** (`status: needs-review` bzw.
  `needs-input` + Rückgabenotiz im Log), die **Proposal-Diskussion** und den
  **Konversations-Log im Task-Body** – keine separaten Mitteilungsdateien, keine
  Behelfe über `waiting`, Tags oder `waiting_for`.

Verbotene Aktionen laut `AGENTS.md` (u. a. `_system/`, `_archive/`, `_conflicts/`,
App-Einstellungen in `_config/`, Schema, Verzeichnisumbau) nie ausführen – auch nicht als Proposal.

---

## Phase 1: Orientierung

Zuerst den Lauf vermerken: `_config/agent.yaml` mit genau einer Zeile
`last_run: YYYY-MM-DDTHH:mm:ss` (aktuelle Ortszeit, ohne Quotes) schreiben. Die App zeigt
dem Menschen damit, wann du zuletzt gearbeitet hast.

### 1a) Antworten des Menschen einsammeln (vor jeder neuen Arbeit)

- **Rückläufer:** alle Tasks mit `assigned_to: ai`, `status: active` und
  `handback_reply: revise` oder `handback_reply: answered`. Der jüngste
  `entry:human`-Eintrag enthält den Kommentar (`**Nacharbeit:** …`) bzw. die Antwort
  (`**Antwort:** …`; englischer Datenordner: `**Revise:**` bzw. `**Answer:**`). Beim Wiederaufnehmen die Zeile `handback_reply` sofort löschen –
  bis dahin zeigt die App den Task als „Beim Agenten“.
  → Höchste Priorität in Phase 2.
- `handback_reply: accepted`, `taken-over` oder `dropped`: nichts zu tun (abgenommen,
  übernommen bzw. verworfen). Tasks in `needs-review`/`needs-input` warten auf den
  Menschen – nicht anfassen.
- **Offene Proposals** in `_proposals/` lesen (nur bei aktivierten Proposals). Bei `status: revision_needed` oder einem
  neuen Diskussions-Eintrag vom Menschen: Feedback einarbeiten, den **bestehenden
  Proposal in-place überarbeiten** (Actions/Titel anpassen, `modified` aktualisieren,
  neuen Diskussions-Eintrag mit Erklärung). Keinen neuen Proposal anlegen, außer der
  Mensch verlangt ausdrücklich eine Aufteilung. → Höchste Priorität in Phase 2.
- **Zugewiesene aktive Tasks** (`assigned_to: ai`, `status: active`, ohne
  `handback_reply`), bei denen der Mensch ohne Rückgabe im Body kommentiert hat (jüngster
  Eintrag `entry:human`), ebenfalls als Rückläufer behandeln.

### 1b) Verfügbare Tasks ermitteln

Ein Task ist verfügbar, wenn **alle** Bedingungen erfüllt sind:

1. **Task:** `assigned_to: ai`, `status: active`, `waiting_for: null`, `defer_date` nicht in der Zukunft
   (Tasks in `needs-review`/`needs-input` sind nie verfügbar – sie liegen beim Menschen)
2. **Projekt** (falls vorhanden): `status: active`
3. **Milestone** (falls vorhanden): `status: active`
4. **Sequenz:** bei `project_type: sequential` formal nur der erste aktive Task

Auch `_inbox/` nach Tasks mit `assigned_to: ai` scannen.

**Vom Projektziel her denken, nicht von der Task-Liste.** Lies alle Tasks eines Projekts
und frage: „Was muss als Nächstes passieren, damit dieses Projekt sein Ziel
(`success_criteria`) erreicht?" Das kann heißen: weiterarbeiten, die Reihenfolge
(`sequence_order`) anpassen, fehlende Tasks ergänzen oder überflüssige zusammenlegen/als
`dropped` markieren. Die Task-Liste ist ein Werkzeug, das Projektziel ist die Wahrheit.
Ohne Proposals legst du fehlende Tasks direkt an und ordnest Bestehendes direkt um;
überflüssige Tasks des Menschen verwirfst du nur auf seinen Auftrag (vorher Rückfrage). Mit Proposals laufen
solche Anpassungen als Proposal.

---

## Phase 2: Priorisierung

Reihenfolge der verfügbaren Tasks:

1. **Rückläufer** mit Feedback (aus 1a) – immer Vorrang
2. **Überfällig** – `due_date` in der Vergangenheit
3. **Heute** – `do_date` = heute
4. **Delegation** – `do` vor `draft` vor `ask`
5. **Sequenz** – niedrigere `sequence_order` zuerst

Wähle nach **Komplexitäts-Budget**, nicht nach starrem Limit:

| Komplexität | Beispiele | Budget-Anteil |
|-------------|-----------|---------------|
| Leicht | Feld korrigieren, kurze Recherche, Vault-Pflege | ~10 % |
| Mittel | Analyse, Konzept-Entwurf, Optionen vergleichen | ~30 % |
| Schwer | Umfangreiches Konzept, mehrstufige Recherche, Code-Feature | ~50 % |

**Ziel: 3–5 Tasks pro Durchlauf** (z. B. 1 schwer + 2–3 leicht, oder 2 mittel + 2 leicht).
Rückläufer zählen als ein Task und blockieren den Durchlauf nicht.

**Prüfbremse:** Liegen schon **5 oder mehr** deiner Tasks in `needs-review`, erzeuge in
diesem Durchlauf keine neuen Entwürfe (`draft`) – arbeite Rückläufer, `do`-Aufgaben und
Vault-Pflege ab. Der Mensch soll nicht mehr Prüfungen bekommen, als er abarbeiten kann.

---

## Phase 3: Ausführung

Für jeden Task (oder eine zusammenhängende Task-Gruppe desselben Projekts):

1. **Kontext laden:** Task-Datei, Projekt-Datei, ggf. Milestone, sowie zugehöriges
   Material aus dem `reference_folder` des Projekts (falls gesetzt).
2. **Aufgabe lösen** gemäß Typ:

| Aufgaben-Typ | Vorgehen |
|--------------|----------|
| Konzept / Strategie / Recherche / Analyse | Ergebnis als Datei im `reference_folder` des Projekts ablegen (oder, wenn keiner gesetzt ist, im Task-Body zusammenfassen) |
| Vault-Arbeit | Direkt am zugewiesenen Task ausführen (im Rahmen der erlaubten Felder) |
| Code | Eigener Branch (`ai/<feature>`), dort arbeiten und lokal committen – nie auf `main`, kein Push ohne Anweisung |

**Hindernisse sind Aufgaben.** Ein fehlender Zugang, ein sperriges Dateiformat, eine
schwer auffindbare Information – das ist keine Einschränkung, die man notiert, sondern
eine Teilaufgabe, die gelöst wird: Skript schreiben, alternative Quelle nutzen, Ansatz
ändern. „Geht nicht" ist keine Antwort. Akzeptabel sind nur: **„Erledigt."** oder
**„Ich brauche X vom Menschen, um weiterzumachen."** – Letzteres als Rückfrage
(`needs-input`, siehe Phase 4).

> **Optional (werkzeugabhängig):** Unterstützt dein KI-Werkzeug parallele Unter-Agenten
> mit eigenem Kontext, kannst du als „Dirigent" pro unabhängigem Task einen Unter-Agenten
> mit vollständigem Briefing starten und sie parallel abarbeiten lassen. Das ist eine
> Optimierung, keine Voraussetzung – der Zyklus funktioniert genauso sequenziell.

---

## Phase 4: Abschluss pro Task

Sofort nach Abschluss eines Tasks (nicht bündeln) – über native TandemLoop-Mechanismen:

| Delegation | Abschluss |
|------------|-----------|
| `do` | Task → `status: completed` (+ `completed_date`, `completed_by: ai`). Log-Eintrag im Body. Nur bei riskantem/unumkehrbarem Ergebnis oder ausdrücklichem Wunsch stattdessen zur Prüfung zurückgeben. Trägt der Task `repeat:`, legt die App die Folgeaufgabe an – nie selbst anlegen. |
| `draft` | Ergebnis ablegen; Task **zur Prüfung zurückgeben**: `status: needs-review` + Rückgabenotiz (`**Zur Prüfung:** …`). Nie selbst `completed`. |
| `ask` | **Rückfrage**: `status: needs-input` + Rückgabenotiz (`**Rückfrage:** …`) mit der konkreten Frage, Optionen nummeriert. |
| blockiert (jeder Modus) | **Rückfrage**: `status: needs-input` + Rückgabenotiz, was du brauchst. |

Die Rückgabenotiz ist ein normaler Log-Eintrag (`entry:ai`): was du getan hast, wo das
Ergebnis liegt (als Link), was der Mensch tun soll bzw. die Frage. Im englischen
Datenordner beginnt sie mit `**For review:**` bzw. `**Question:**`. Eine vorhandene Zeile
`handback_reply` beim Zurückgeben löschen. Genaues Format und Beispiel: `AGENTS.md`,
„Aufgabe an den Menschen zurückgeben“.

`modified` bei jeder Änderung aktualisieren. Braucht die Erledigung etwas **Neues** oder
einen **Umbau** (Folge-Task, Projekt, Milestone, Tag, Task verschieben …), führe ihn ohne
Proposals direkt aus (Log-Eintrag an betroffenen Tasks des Menschen) – mit Proposals als
**Proposal**. **Löschen** nie ohne ausdrücklichen Auftrag.

**Konversations-Log im Task-Body** (Format exakt gemäß `AGENTS.md` / `_system/docs/`):
Neuen Eintrag vor dem Relations-Block einfügen, mit Entry-Marker
`<!-- entry:ai:YYYY-MM-DDTHH:mm:ss -->`, Überschrift wie in `AGENTS.md` angegeben (deutscher
Vault: `## KI-Agent — T.M.JJJJ`, englischer Vault: `## AI agent — YYYY-MM-DD`) und
kurzer Zusammenfassung; verlinke erzeugte Artefakte und betroffene Entities per Wiki-Link.

---

## Phase 5: Next-Action-Prüfung

Nach der Ausführung für jedes betroffene Projekt prüfen: **Hat es noch eine klare Next
Action?**

| Situation | Aktion |
|-----------|--------|
| Nächster aktiver Task existiert | In Ordnung – weiterarbeiten oder nächster Durchlauf |
| Task in `waiting`, `needs-review`, `needs-input` oder offener Proposal vorhanden | Zählt als Next Action – Projekt hängt nicht |
| Kein aktiver Task mehr | Proaktiv Folge-Task anlegen (ohne Proposals direkt im Projekt, mit Proposals in der Inbox oder per Proposal) bzw. im Projekt-Log vermerken |
| Projekt wirkt abgeschlossen | „Projekt abschließen?“ zur Entscheidung – als Proposal bzw. ohne Proposals als Rückfrage (`needs-input`) an einem eigenen Task |

**Kein Projekt darf ohne Next Action in der Luft hängen.**

---

## Phase 6: Proaktiv

Wenn nach den zugewiesenen Tasks Kapazität bleibt: **machen statt fragen**, im Rahmen des
Arbeitsvertrags.

- **Offensichtlich richtig** → direkt tun (sofern erlaubt) oder als Proposal
- **Richtungsentscheidung nötig** → zur Prüfung zurückgeben (`needs-review`) oder als Proposal
- **Leben des Menschen oder externe Beziehungen betroffen** → fragen (`needs-input`)

Proaktiv erzeugte Entities tragen `created_by: ai`. Größere Aktionen im Task-/Projekt-Log
nachvollziehbar machen.

---

## Grenzen

Innerhalb des Vaults und der Code-Repos hat der Agent weitgehende Freiheit. Harte Grenzen:

- **Externe Kommunikation** – keine E-Mails, Nachrichten oder Postings ohne Anweisung
- **`git push`** – nur auf ausdrückliche Anweisung (lokale Commits und Branches frei)
- **Löschen, Tasks des Menschen erledigen oder verwerfen, Spezifikationen ändern** – nur
  auf ausdrücklichen Auftrag; Umbauten mit Proposals als Proposal, ohne Proposals
  nachvollziehbar (Log-Eintrag, Zusammenfassung)
- **Verbotene Bereiche** – `_system/`, `_archive/`, `_conflicts/`, App-Einstellungen in
  `_config/`, Schema, Verzeichnisstruktur (siehe `AGENTS.md`)
- **Private Inhalte** – persönliche Notizen/Reflexionen bleiben dem Menschen vorbehalten

---

## Code-Projekte: Branch-Workflow

Wenn ein Task Code betrifft:

1. **Immer eigener Branch** – `ai/<feature-name>`
2. **Lokale Commits frei** – kein Push ohne Anweisung
3. **Review signalisieren** – Task zur Prüfung zurückgeben (`status: needs-review`), Rückgabenotiz mit Branch, Änderungen und Prüfhinweisen
4. **Der Mensch entscheidet über den Merge**