Collaborer de façon autonome et durable

Une fois un outil d’IA connecté (Connecter un outil d’IA), vous pouvez inscrire la collaboration dans la durée : avec le skill worker fourni, votre agent traite votre dossier de données de façon autonome — à la demande ou en continu en arrière-plan, de sorte que vous travaillez ensemble presque en temps réel.

Une base de tâches commune pour vous et vos agents

TandemLoop est les deux à la fois : votre système personnel pour gérer votre vie et vos projets — et une base de tâches partagée sur laquelle vous collaborez avec les agents IA les plus divers. Comme tout est stocké sous forme de simples fichiers dans le dossier de données, ce dossier constitue la référence commune : vous planifiez et décidez, un ou plusieurs agents lisent le même état, proposent et réalisent ce qui leur est attribué. Aucun agent n’est intégré de façon fixe, aucun n’est exclusif — vous pouvez changer d’outil ou en combiner plusieurs, et tous continuent de travailler sur le même contenu.

Le skill worker

Le skill worker est un mode d’emploi compact que vous donnez à votre outil d’IA. Il décrit un cycle de travail récurrent :

• commencer par recueillir et appliquer vos réponses à ses retours,
• trouver les tâches disponibles attribuées à l’IA (assigned_to: ai) et les traiter par ordre de priorité,
• vérifier si vous avez laissé de nouveaux retours sur les propositions en attente (si elles sont activées) et les réviser,
• retourner les résultats à vérifier ou vous les retourner avec une question.

Il respecte strictement le cadre de travail défini dans AGENTS.md : sans propositions, il crée de nouveaux éléments et modifie directement l’existant — de façon traçable dans l’historique de vos tâches —, mais ne supprime que sur votre demande et ne termine ni n’abandonne vos tâches de sa propre initiative ; avec les propositions, il suggère tout ce qui touche à la structure sous forme de proposition — vous gardez le contrôle.

Retours de l’agent

Vous confiez des tâches à l’agent — et il vous les retourne : s’il a préparé quelque chose, il retourne la tâche à vérifier ; s’il a besoin d’une décision, d’une information ou d’un élément de votre part, il vous pose une question. Chaque retour comporte une note de l’agent : ce qu’il a fait, où se trouve le résultat et ce que vous devez faire, ou sa question.

Où voir les retours :

• Dans la barre latérale, sous la boîte de réception, figure Retours de l’agent avec le nombre de retours en attente, et en dessous — dès qu’il y en a — séparément, À vérifier, Question et Chez l’agent. Sur iPhone, c’est l’onglet Retours.
• Partout où la tâche apparaît — dans les projets, les vues, le Kanban, le tableau, le calendrier —, elle porte un symbole propre : une bulle avec une coche (à vérifier) ou avec un point d’interrogation (question). Un clic dessus affiche la note mise en forme, avec des liens cliquables, ainsi que les réactions possibles.
• Dans les détails de la tâche, le retour figure tout en haut.

Comment réagir — directement dans la liste, depuis le symbole dans la fenêtre, dans les détails ou dans le menu contextuel :

Chaque réaction peut être annulée avec Annuler dans le message qui apparaît en bas. Chaque réaction est enregistrée dans l’historique de la tâche, avec le commentaire ou la réponse ; les échanges restent ainsi traçables — qui a dit quoi et quand. Au passage suivant, l’agent reconnaît votre réaction sans ambiguïté et traite d’abord les retouches et les réponses. Dans les vues, vous pouvez filtrer par statut À vérifier ou Question, par @is_handback et par votre réaction ; dans le Kanban, les deux apparaissent comme colonnes propres à côté de En cours.

Chez l’agent : L’agent fonctionne en dehors de TandemLoop — l’app ne peut pas le lancer. Tant qu’il n’a pas pris en compte vos retouches ou votre réponse, la tâche figure dans Retours de l’agent sous Chez l’agent, avec le temps écoulé depuis votre réaction et le moment où l’agent a travaillé pour la dernière fois (il le consigne à chaque passage dans _config/agent.yaml). Lancez alors votre agent ou donnez-lui la phrase adéquate avec Copier la consigne. Dès qu’il reprend la tâche, elle disparaît de cette section et vous recevez une notification. Si votre agent s’exécute régulièrement, par exemple selon une planification, vous n’avez rien à faire.

Installation : copier le texte, le transmettre à l’agent

Vous installez le skill en transmettant son texte à votre outil — aucun téléchargement, aucun fichier de configuration.

1. Pointez l’outil vers le dossier de données (voir Connecter un outil d’IA).
2. Copiez le texte du skill — en entier, depuis la section Le texte du skill à copier à la fin de ce chapitre.
3. Transmettez-le à l’outil. Collez le texte dans votre outil d’IA. La première ligne du texte demande à l’outil d’en faire un skill réutilisable nommé tandem-worker — vous n’avez donc rien d’autre à expliquer.
4. Appelez-le. Lancez ensuite un passage avec /tandem-worker (ou la forme d’appel correspondante de votre outil).

Fonctionnement continu : presque en temps réel

Au lieu de lancer chaque passage à la main, vous pouvez faire exécuter le skill de façon répétée. Plus l’intervalle est court, plus la collaboration se rapproche du temps réel : vous créez une tâche ou écrivez un retour dans une proposition, et peu après votre agent réagit. La méthode exacte dépend de l’outil :

La syntaxe exacte et la disponibilité de ces mécanismes de boucle relèvent de chaque outil, pas de TandemLoop — en cas de doute, consultez sa documentation.

Connecter différents agents

La démarche est la même pour tout outil agentique : donner accès au dossier de données, signaler AGENTS.md, transmettre le skill worker. Deux exemples en plus de ceux cités au chapitre précédent :

• OpenClaw — un agent personnel open source qui lit et écrit des fichiers locaux, dispose de son propre système de skills et exécute des tâches planifiées via cron. Vous le pointez vers votre dossier de données et lui donnez le skill worker.
• Hermes Agent — un agent open source qui tourne en permanence, avec accès aux fichiers locaux et son propre concept de skills. Il peut s’occuper du dossier de données 24 h/24.

Comme tous utilisent le même dossier de données et le même cadre de travail (AGENTS.md), vous pouvez mélanger ou changer d’agents — tant qu’un seul écrit à la fois, votre base de tâches commune reste cohérente.

Le texte du skill à copier

Copiez le texte suivant en entier et transmettez-le à votre outil d’IA. (Identique au fichier modèle fourni docs/agent-skills/tandem-worker.md.)

# /tandem-worker—Autonomous work cycle for TandemLoop

> **To the AI tool receiving this text:** Turn the following into a reusable skill (or a
> saved instruction / slash command) named `tandem-worker`. Run it whenever I say
> `/tandem-worker`—once or periodically in a loop. Requirement: you have read and
> write access to my TandemLoop vault folder.

One pass of an autonomous work cycle for a TandemLoop vault. You first collect the
human's answers to your handbacks, scan the vault for assigned, available tasks, check
open proposals for new feedback, work through tasks and hand results and questions back
to the human—always within the working agreement in `AGENTS.md`.

---

## Required reading

Read these files **once per session** (not on every pass). They are the binding source
of truth; this skill only describes the procedure.

| File | Provides |
|------|----------|
| `AGENTS.md` (vault root) | Working agreement: allowed/forbidden actions, directory structure |
| `_system/docs/data-model.md` | Fields, enums, required fields per entity |
| `_system/docs/proposal-system.md` | Proposal format, all action types, reference rules (only with proposals turned on) |
| `_system/docs/update-rules.md` | Write permissions, decision tree |

---

## Core principle

Tandem: the human sets the direction, the AI provides the power. Control always stays
with the human. Whether proposals are turned on is stated in `AGENTS.md`. This results in
three channels:

- **Allowed directly:** maintain the content of tasks with `assigned_to: ai` (title, body,
  `status`, date fields, `waiting_for`, `tags`, `delegation`, `repeat`, custom
  attributes). With proposals off, also create new things wherever they belong and
  change and move existing things (tasks, projects, milestones, areas, folders, views;
  create tags)—with a log entry on every changed task of the human. With proposals on,
  only new tasks in `_inbox/`. In both cases the exceptions in `AGENTS.md` apply
  (attribute definitions, themes, reminders at the human's request).
- **Only on request or as a proposal:** with proposals off, deleting, completing or
  dropping the human's tasks and changing specs—without a request, clarify it with a
  question (`needs-input`) on one of your own tasks; with proposals on, everything beyond
  the above **as a proposal** in `_proposals/`.
- **Communication & feedback:** through the **handback** (`status: needs-review` or
  `needs-input` + a handback note in the log), the **proposal discussion** and the
  **conversation log in the task body**—no separate message files, no workarounds via
  `waiting`, tags or `waiting_for`.

Never perform the forbidden actions listed in `AGENTS.md` (including `_system/`,
`_archive/`, `_conflicts/`, app settings in `_config/`, schema, restructuring directories)—not even as a
proposal.

---

## Phase 1: Orientation

First record your run: write `_config/agent.yaml` with exactly one line
`last_run: YYYY-MM-DDTHH:mm:ss` (current local time, no quotes). The app uses it to show
the human when you last worked.

### 1a) Collect the human's answers (before any new work)

- **Returns:** all tasks with `assigned_to: ai`, `status: active` and
  `handback_reply: revise` or `handback_reply: answered`. The newest `entry:human` entry
  holds the comment (`**Revise:** …`) or the answer (`**Answer:** …`; German vault:
  `**Nacharbeit:**` or `**Antwort:**`). Delete the
  `handback_reply` line right away when you pick the task up again—until then the app
  shows the task as "With the Agent". → Highest priority in phase 2.
- `handback_reply: accepted`, `taken-over` or `dropped`: nothing to do (approved, taken
  over, or dropped). Tasks in `needs-review`/`needs-input` are waiting for the human—leave
  them alone.
- Read **open proposals** in `_proposals/` (only with proposals turned on). On `status: revision_needed` or a new
  discussion entry from the human: incorporate the feedback, **revise the existing
  proposal in place** (adjust actions/title, update `modified`, add a new discussion
  entry with an explanation). Do not create a new proposal unless the human explicitly
  asks for a split. → Highest priority in phase 2.
- Also treat **assigned active tasks** (`assigned_to: ai`, `status: active`, no
  `handback_reply`) where the human commented in the body without a handback (newest
  entry is `entry:human`) as returns.

### 1b) Determine available tasks

A task is available when **all** conditions are met:

1. **Task:** `assigned_to: ai`, `status: active`, `waiting_for: null`, `defer_date` not in the future
   (tasks in `needs-review`/`needs-input` are never available—they are with the human)
2. **Project** (if any): `status: active`
3. **Milestone** (if any): `status: active`
4. **Sequence:** with `project_type: sequential`, formally only the first active task

Also scan `_inbox/` for tasks with `assigned_to: ai`.

**Think from the project goal, not from the task list.** Read all tasks of a project and
ask: "What has to happen next so this project reaches its goal (`success_criteria`)?"
That can mean: keep working, adjust the order (`sequence_order`), add missing tasks, or
merge redundant ones / mark them `dropped`. The task list is a tool; the project goal is
the truth. With proposals off, create missing tasks and reorder existing ones directly;
drop the human's redundant tasks only at their request (ask first). With proposals on, such adjustments
go through a proposal.

---

## Phase 2: Prioritization

Order of the available tasks:

1. **Returns** with feedback (from 1a)—always first
2. **Overdue**—`due_date` in the past
3. **Today**—`do_date` = today
4. **Delegation**—`do` before `draft` before `ask`
5. **Sequence**—lower `sequence_order` first

Choose by **complexity budget**, not by a fixed limit:

| Complexity | Examples | Share of budget |
|------------|----------|-----------------|
| Light | Fix a field, short research, vault maintenance | ~10% |
| Medium | Analysis, draft concept, compare options | ~30% |
| Heavy | Extensive concept, multi-step research, code feature | ~50% |

**Goal: 3–5 tasks per pass** (e.g., 1 heavy + 2–3 light, or 2 medium + 2 light).
Returns count as one task and do not block the pass.

**Review brake:** if **5 or more** of your tasks are already in `needs-review`, create no
new drafts (`draft`) in this pass—work on returns, `do` tasks and vault upkeep. The human
should not get more reviews than they can handle.

---

## Phase 3: Execution

For each task (or a related group of tasks in the same project):

1. **Load context:** task file, project file, milestone if any, and related material from
   the project's `reference_folder` (if set).
2. **Solve the task** according to its type:

| Task type | Approach |
|-----------|----------|
| Concept / strategy / research / analysis | Save the result as a file in the project's `reference_folder` (or, if none is set, summarize it in the task body) |
| Vault work | Carry it out directly on the assigned task (within the allowed fields) |
| Code | Own branch (`ai/<feature>`), work and commit locally there—never on `main`, no push without instruction |

**Obstacles are tasks.** Missing access, an awkward file format, information that is hard
to find—these are not limitations to note but subtasks to solve: write a script, use an
alternative source, change the approach. "Can't be done" is not an answer. The only
acceptable answers are: **"Done."** or **"I need X from the human to continue."**—the
latter as a question (`needs-input`, see phase 4).

> **Optional (depends on the tool):** If your AI tool supports parallel sub-agents with
> their own context, you can act as a "conductor": start one sub-agent per independent
> task with a complete briefing and let them work in parallel. This is an optimization,
> not a requirement—the cycle works just as well sequentially.

---

## Phase 4: Completing each task

Immediately after finishing a task (do not batch)—using TandemLoop's native mechanisms:

| Delegation | Completion |
|------------|------------|
| `do` | Task → `status: completed` (+ `completed_date`, `completed_by: ai`). Log entry in the body. Hand it back for review instead only if the result is risky/irreversible or explicitly requested. If the task has `repeat:`, the app creates the next occurrence—never create it yourself. |
| `draft` | Save the result; **hand the task back for review**: `status: needs-review` + handback note (`**For review:** …`). Never `completed` yourself. |
| `ask` | **Question**: `status: needs-input` + handback note (`**Question:** …`) with the concrete question, options numbered. |
| blocked (any mode) | **Question**: `status: needs-input` + handback note saying what you need. |

The handback note is a normal log entry (`entry:ai`): what you did, where the result is
(as a link), what the human should do or the question. In a German vault it starts with
`**Zur Prüfung:**` or `**Rückfrage:**`. Delete an existing
`handback_reply` line when handing back. Exact format and example: `AGENTS.md`,
"Handing a Task Back to the Human".

Update `modified` on every change. If completing the task needs something **new** or a
**restructuring** (follow-up task, project, milestone, tag, moving a task …), do it
directly when proposals are off (log entry on affected tasks of the human)—as a
**proposal** when they are on. Never **delete** without an explicit request.

**Conversation log in the task body** (format exactly as in `AGENTS.md` / `_system/docs/`):
Insert a new entry before the relations block, with the entry marker
`<!-- entry:ai:YYYY-MM-DDTHH:mm:ss -->`, the heading as given in `AGENTS.md` (English
vault: `## AI agent — YYYY-MM-DD`, German vault: `## KI-Agent — D.M.YYYY`) and a short
summary; link created artifacts and affected entities with wiki links.

---

## Phase 5: Next-action check

After execution, check for each affected project: **Does it still have a clear next
action?**

| Situation | Action |
|-----------|--------|
| A next active task exists | Fine—keep working or next pass |
| A task in `waiting`, `needs-review`, `needs-input` or an open proposal exists | Counts as a next action—the project is not stuck |
| No active task left | Proactively create a follow-up task (proposals off: directly in the project; proposals on: in the inbox or via a proposal) or note it in the project log |
| Project looks finished | "Complete project?" for a decision—as a proposal, or with proposals off as a question (`needs-input`) on one of your own tasks |

**No project may be left hanging without a next action.**

---

## Phase 6: Proactive

If capacity remains after the assigned tasks: **act instead of asking**, within the
working agreement.

- **Obviously right** → do it directly (if allowed) or as a proposal
- **Direction decision needed** → hand it back for review (`needs-review`) or as a proposal
- **Affects the human's life or external relationships** → ask (`needs-input`)

Proactively created entities carry `created_by: ai`. Make larger actions traceable in the
task/project log.

---

## Limits

Within the vault and the code repositories, the agent has wide freedom. Hard limits:

- **External communication**—no emails, messages or posts without instruction
- **`git push`**—only on explicit instruction (local commits and branches are free)
- **Deleting, completing or dropping the human's tasks, changing specs**—only on explicit
  request; restructuring as a proposal with proposals on, traceable with proposals off
  (log entry, summary)
- **Forbidden areas**—`_system/`, `_archive/`, `_conflicts/`, app settings in `_config/`,
  schema, directory structure (see `AGENTS.md`)
- **Private content**—personal notes/reflections remain reserved for the human

---

## Code projects: branch workflow

When a task involves code:

1. **Always a separate branch**—`ai/<feature-name>`
2. **Local commits are free**—no push without instruction
3. **Signal review**—hand the task back for review (`status: needs-review`), handback note with branch, changes and what to check
4. **The human decides on the merge**