Dein Tracker ist ein Ordner in deinem Repository.

pm speichert Aufgaben, Entscheidungen und ihre vollständige Historie als einfache Dateien unter .agents/pm/. Deine Agents lesen sie im kompakten TOON-Format, arbeiten auf getrennten Branches und mergen ihre Änderungen mit pms eigenen Merge-Treibern.

npm install -g @unbrained/pm-cli

Zum Schnellstart

pm-t05d8d · Issueclosed

Allow self-isolating linked package tests without inherited PM_PATH

priority: 1 · risk: –

test_runs: 1 (last: passed)

comments: 6

resolution: Added explicit pm_context_mode=none across parser, SDK types, CLI/MCP contracts, help, completion, execution preflight, and docs; non-PM commands run only in isolated or snapshot workspaces, with PM_GLOBAL_PATH still sandboxed.

.agents/pm/issues/pm-t05d8d.toon · 8,6 kB · 21 weitere Felder in der Datei

25 Einträge in .agents/pm/history/pm-t05d8d.jsonl

Das ist die echte Karte von pm-t05d8d aus pms eigenem Tracker, behoben in pm 2026.9.28. 8,6 kB als TOON, 9,4 kB als JSON: 2.214 und 2.290 Tokens (o200k_base).

Viele Agents, viele Branches, ein Tracker

Wenn zwei Agents den Tracker auf verschiedenen Branches ändern, übergibt git beide Seiten an pms Merge-Treiber. Die führen sie Feld für Feld zusammen statt Zeile für Zeile.

mainagent-a · feat/searchclaim pm-a1f3close pm-a1f3agent-b · fix/mergeclaim pm-b7k2close pm-b7k2agent-c · docs/sdkclaim pm-c9q4close pm-c9q4
Eine Datei pro Eintrag
Jeder Eintrag ist eine eigene Datei unter .agents/pm/. Eine Aufgabe, die auf einem Branch entsteht, berührt nie eine Datei, die ein anderer Branch geändert hat.
Eine Historie, die nur wächst
Jede Änderung wird mit einer Hash-Kette an die Historie des Eintrags angehängt, sodass die Einträge beider Branches den Merge überstehen.
Merge-Treiber, die beides verstehen
pm init registriert die Treiber beim Start. pm merge install repariert sie in einem frischen Klon.

Was dein Agent zuerst liest

pm context --limit 10 gibt einem Agent den Stand des Projekts in einem Aufruf: was in Arbeit ist, was blockiert ist und was als Nächstes dran ist. Das hier ist pms eigener Tracker.

$ pm context --limit 10
summary:
  returned_focus:
    active_items: 18
    in_progress: 0
    open: 18
    blocked: 10
  blocked_fallback_used: false
  high_level: 10
  low_level: 4
  agenda_events: 2
  scope: "matching_items"
  active_items: 221
  open: 221
  in_progress: 0
  blocked: 60
  total_items: 2826
  closed: 2532
  canceled: 14
high_level:
  - id: "pm-doxj"
    title: "pm-cli post-v0.1 roadmap & living backlog"
    type: "Milestone"
    status: "open"
    priority: 0
    tags:
      - "backlog"
      - "context-management"
      - "living-map"
      - "pm-cli"
      - "post-v0.1"
      - "roadmap"
    updated_at: "2026-09-12T20:05:01.648Z"
Erzeugt 29.09.2026, 13:20 UTC von pm 2026.9.28. 8,2 kB als TOON, 11,8 kB als JSON.

Der Ablauf, dem jeder Agent folgt

Fünf Befehle, in dieser Reihenfolge, für jedes Stück Arbeit.

  1. Orientieren

    Sehen, was in Arbeit ist, was blockiert ist und was als Nächstes kommt.

    pm context --limit 10
  2. Übernehmen

    Einen Eintrag übernehmen, damit kein anderer Agent damit anfängt.

    pm claim <id>
  3. Nachweise verknüpfen

    Die geänderten Dateien und den Befehl, der sie testet, anhängen.

    pm files <id> --add src/x.ts
    pm test <id> --add command="npm test"
  4. Prüfen

    Die verknüpften Tests ausführen. Das Ergebnis wird am Eintrag gespeichert.

    pm test <id> --run
  5. Schließen

    Den Eintrag mit dem Nachweis schließen und dann die Übernahme freigeben.

    pm close <id> "<evidence>"
    pm release <id>

Pakete

Integrationen und Workflows fügst du einem Projekt mit pm install hinzu.

Alle 34 Pakete ansehen

Oder gehostet nutzen

Derselbe Tracker, in Echtzeit mit deinem Team geteilt: im Browser, in ChatGPT oder in jedem MCP-Client.