自律的かつ継続的に共同作業する

AIツールを接続したら（AIツールを接続する）、共同作業を定着させることができます。付属のワーカースキルを使うと、エージェントがデータフォルダの作業を自律的にこなします。必要なときだけ実行することも、バックグラウンドで継続的に動かすこともでき、ほぼリアルタイムで共同作業できます。

自分とエージェントのための共通のタスク基盤

TandemLoopは、生活やプロジェクトを管理するための個人用のシステムであると同時に、さまざまなAIエージェントと共同作業するための共有のタスク基盤でもあります。すべてがデータフォルダ内のシンプルなファイルとして保存されるため、このデータフォルダが共通の正となる情報になります。自分が計画して判断し、1つまたは複数のエージェントが同じ状態を読み取り、提案し、割り当てられた作業をこなします。組み込みのエージェントはなく、特定のエージェントに限定されることもありません。ツールを切り替えたり組み合わせたりしても、すべて同じデータで作業を続けられます。

ワーカースキル

ワーカースキルは、AIツールに渡す簡潔な手順書です。次のような作業サイクルの繰り返しを記述しています。

• まず、エージェントの返却に対する自分の対応を集めて反映する
• エージェントに割り当てられた着手可能なタスク（assigned_to: ai）を見つけ、優先度順に処理する
• 未処理の提案（有効な場合）に新しいフィードバックがないかを確認し、修正する
• 結果をレビュー待ちとして返却するか、質問を付けて返却する

スキルはAGENTS.mdの作業の取り決めに厳密に従います。提案を使わない場合は、新しい項目を作成し、既存の項目を直接変更します。変更内容は自分のタスクの履歴でたどれます。削除は依頼された場合にのみ行い、自分のタスクを勝手に完了にしたり中止にしたりはしません。提案を使う場合は、構造に関わる変更をすべて提案として示します。主導権は自分にあります。

エージェントからの返却

エージェントにタスクを任せると、タスクは返却されて戻ってきます。何かを用意できたときは、エージェントはタスクをレビュー待ちとして返却します。判断や情報、資料が必要なときは、質問を付けて返却します。どの返却にもエージェントのメモが付いています。メモには、エージェントが行ったこと、成果物の場所、自分がすべきこと、または質問が書かれています。

返却を確認できる場所：

• サイドバーのインボックスの下に、未対応の返却の件数とともにエージェントからの返却が表示され、該当するものがあると、その下にレビュー待ち、質問、エージェント待ちが分かれて表示されます。iPhoneでは返却タブです。
• プロジェクト、ビュー、ボード、表、カレンダーなど、タスクが表示されるすべての場所で、タスクに専用のアイコンが付きます。チェックマーク付きの吹き出し（レビュー待ち）と、疑問符付きの吹き出し（質問）です。クリックすると、リンクをクリックできる整形済みのメモが、対応の操作とともに表示されます。
• タスクの詳細では、返却がいちばん上に表示されます。

対応の方法（リストで直接、ウインドウのアイコンから、詳細で、またはコンテキストメニューで）：

どの対応も、下に表示される通知の取り消すで元に戻せます。どの対応も、コメントや回答と一緒にタスクの履歴に残るため、誰がいつ何を伝えたか、やり取りをあとからたどれます。エージェントは次の実行時に自分の対応を確実に認識し、手直しと回答を優先して処理します。ビューでは、ステータスレビュー待ちまたは質問、@is_handback、自分の対応で絞り込めます。ボードでは、どちらもアクティブの横に専用の列として表示されます。

エージェント待ち： エージェントはTandemLoopの外で動作するため、Appからエージェントを起動することはできません。エージェントが手直しや回答に取りかかるまで、タスクはエージェントからの返却のエージェント待ちに表示されます。あわせて、対応してからの経過時間と、エージェントが最後に作業した時刻も表示されます（エージェントは実行のたびに_config/agent.yamlに記録します）。必要に応じてエージェントを起動するか、依頼文をコピーで適切な依頼文を渡します。エージェントがタスクに取りかかると、タスクはそこから消え、通知が届きます。スケジュールなどでエージェントを定期的に実行している場合は、何もする必要はありません。

インストール：テキストをコピーしてエージェントに渡す

スキルは、そのテキストをツールに渡すだけでインストールできます。ダウンロードも設定ファイルも必要ありません。

1. ツールにデータフォルダを指定します（AIツールを接続するを参照）。
2. スキルのテキストをコピーします。 この章の最後にあるコピー用のスキルのテキストから、すべてコピーします。
3. ツールに渡します。 テキストをAIツールに貼り付けます。テキストの1行目で、これをtandem-workerという名前の再利用可能なスキルにするようツールに指示しています。そのため、ほかに説明は必要ありません。
4. 呼び出します。 その後は/tandem-worker（またはツールに応じた呼び出し方法）で実行します。

継続運用：ほぼリアルタイムで並走する

毎回手動で実行する代わりに、スキルを繰り返し実行させることができます。間隔が短いほど、共同作業はリアルタイムに近くなります。タスクを作成したり提案にフィードバックを書いたりすると、すぐにエージェントが応答します。具体的な方法はツールによって異なります。

これらのループ機能の正確な構文と利用可否は、TandemLoopではなく各ツールによって決まります。不明な点はツールのドキュメントを確認してください。

さまざまなエージェントを接続する

手順はどのエージェント型ツールでも同じです。データフォルダへのアクセスを許可し、AGENTS.mdを案内して、ワーカースキルを渡します。前の章で挙げたもの以外の例を2つ紹介します。

• OpenClaw：ローカルのファイルを読み書きでき、独自のスキル機能を持ち、Cronでタスクを定時実行できるオープンソースの個人用エージェントです。データフォルダを指定してワーカースキルを渡します。
• Hermes Agent：ローカルのファイルにアクセスでき、独自のスキルの概念を持つ、常時動作するオープンソースのエージェントです。データフォルダを24時間体制で管理できます。

すべてのエージェントが同じデータフォルダと同じ作業の取り決め（AGENTS.md）を使うため、エージェントを組み合わせたり切り替えたりできます。同時に書き込むのが常に1つだけであれば、共通のタスク基盤の整合性は保たれます。

コピー用のスキルのテキスト

次のテキストをすべてコピーし、AIツールに渡してください（付属のテンプレートファイル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**