Planning with Files ist ein Agent-Skill von Ahmad Adi, der Plan, Erkenntnisse und Fortschritt einer Aufgabe in Projektdateien festhält. Nutze ihn, wenn eine Programmier- oder Rechercheaufgabe so lange dauert, dass in einer neuen Unterhaltung frühere Entscheidungen sonst erneut rekonstruiert werden müssten. Die Dateien liefern dem Agenten ein Protokoll, das er lesen und aktualisieren kann. Wie nützlich es ist, hängt davon ab, ob die Angaben stimmen.
Ein praktischer Einstieg sind drei Markdown-Dateien: task_plan.md, findings.md und progress.md. Gib jeder eine eigene Aufgabe. Der Plan hält fest, was noch zu tun ist, die Erkenntnisse erklären das Gelernte, und der Fortschritt dokumentiert den tatsächlichen Ablauf. Derselbe Absatz in allen drei Dateien erschwert die Wiederaufnahme.
Fiktives Planungsbeispiel für Apple; das zitierte Feedback und die Prozentwerte dienen der Veranschaulichung. Illustration in voller Größe öffnen.
Den vollständigen Skill-Ordner installieren
Die Thrive-Seite zum Planning with Files Skill nennt die geprüfte Originalquelle. Installiere den Skill in deinem Projekt:
npx usethrive add planning-with-files --agent claudeErsetze für Codex --agent claude durch --agent codex. Der Installer kopiert den vollständigen Skill-Ordner in der festgelegten Version einschließlich Vorlagen und Skripten. Eine vorhandene Installation bleibt unverändert. Prüfe deshalb die installierte Kopie, bevor du sie ersetzt.
Die Installation eines Skills und die Installation eines Host-Plugins sind unterschiedliche Vorgänge. Der Herausgeber bietet auch Integrationen für Lifecycle-Hooks und die Wiederaufnahme von Aufgaben an. Durch das Kopieren eines Ordners werden nicht automatisch alle Hooks auf Plugin-Ebene jeder Host-Anwendung registriert. Wenn du diese Integrationen nutzen möchtest, folge der Installationsdokumentation des Herausgebers für deinen tatsächlichen Agent und dein Betriebssystem.
Trenne den installierten Skill von den Planungsdateien des Projekts. Der installierte Ordner enthält wiederverwendbare Skripte und Vorlagen. Im Aufgabenverzeichnis liegen die Aufzeichnungen deiner aktuellen Arbeit. Der aktuelle Ablauf des Herausgebers kann ein Aufgabenverzeichnis auswählen. Nutze bei aktiviertem Modus die Initialisierung und die ausgegebene Aufgabenkennung, statt anzunehmen, dass jede Aufgabe in das Projektstammverzeichnis schreibt.
Jeder Datei einen klaren Zweck geben
Datei | Hier festhalten | Hier vermeiden |
|---|---|---|
| Ziel, Phasen, Abnahmekriterien und nächste Aktion | Ein Protokoll jedes einzelnen Tool-Aufrufs |
| Belege, Quellenlinks, Einschränkungen und Entscheidungsgründe | Eine unbelegte Schlussfolgerung, die als Tatsache dargestellt wird |
| Abgeschlossene Schritte, tatsächliche Testergebnisse und ungelöste Fehler | Geplante Prüfungen, die als abgeschlossen beschrieben werden |
Bei einer kurzen Änderung können diese Dateien mehr Arbeit verursachen, als sie sparen. Die Korrektur einer Überschrift braucht selten ein System zur Wiederaufnahme. Eine Migration, eine Untersuchung mit mehreren Quellen oder eine Funktion mit mehreren Abhängigkeiten eignet sich besser, weil die nächste Aktion auf früheren Belegen beruht.
Beispiel: Eine kleine Inhaltsmigration planen
Angenommen, du überträgst ein Newsletter-Archiv in ein CMS. Du musst Titel, Daten, Tags und Inhalte zuordnen, ohne private Entwürfe zu veröffentlichen. Beginne mit einem Plan, der das Ergebnis und die Prüfungen festlegt:
# Newsletter archive migration
## Objective
Import the approved public archive and preserve draft visibility.
## Phases
- [ ] Inventory source records and classify their visibility.
- [ ] Map source fields to the target content model.
- [ ] Import a small sample and check formatting.
- [ ] Import the approved remaining records.
- [ ] Verify counts, visibility, and representative links.
## Acceptance criteria
- Source and imported approved-record counts match.
- Draft records have no public snapshot.
- Sample links, headings, and publication dates are preserved.
## Next step
Inspect five representative source records before writing the mapper.Das Beispiel ist eine Planungsvorlage, keine Behauptung, dass eine Migration abgeschlossen wurde. Ersetze die Prüfungen durch jene, die dein Quell- und Zielsystem erfordern. Braucht eine Zuordnung eine Entscheidung des Redakteurs, halte diese Abhängigkeit fest, statt den Agenten raten zu lassen.
Erkläre in findings.md eine Zuordnungsentscheidung anhand von Belegen. Zum Beispiel ist „Der Export enthält published_at nur für veröffentlichte Einträge; bei Entwürfen den Wert leer lassen“ hilfreich, wenn du das im Export beobachtet hast. Halte die geprüfte Datei und die relevanten Felder fest. Schreibe diese Schlussfolgerung nicht allein deshalb auf, weil sie für ein CMS plausibel klingt.
Halte in progress.md das tatsächliche Ergebnis des Stichprobentests fest. „Fünf Datensätze importiert; ein eingebettetes Video benötigt eine separate Konvertierungsregel“ sagt der nächsten Sitzung, was noch offen ist. „Migration sieht gut aus“ reicht nicht aus, um sicher weiterzuarbeiten.
Nach einem Zurücksetzen des Kontexts weiterarbeiten
Lass den Agenten vor Änderungen die drei Dateien der ausgewählten Aufgabe lesen und die aktuelle Phase, offenen Entscheidungen und nächste Aktion nennen. Vergleiche diese Darstellung mit dem Repository und allen externen Systemen, die die Aufgabe nutzt. Ein Markdown-Kontrollkästchen kann veraltet sein. Der Agent sollte das betreffende Ergebnis prüfen, bevor er sich darauf verlässt.
Wenn laut Plan die Tests bestanden wurden, sollte das Fortschrittsprotokoll den Befehl und das Ergebnis nennen. Ist ein Deployment als abgeschlossen vermerkt, behalte die Deployment-Kennung oder URL bei. Speichere keine Geheimnisse in diesen Dateien, besonders wenn das Repository gemeinsam genutzt wird. Halte Namen von Zugangsdaten und Zugriffsanforderungen fest, statt Tokens zu kopieren.
Der Herausgeber liefert Tools zur Wiederaufnahme von Sitzungen mit ausdrücklichen Modi. Verwende den zur Aufgabe und Host-Anwendung passenden Modus. Zugriff auf ein Projektverzeichnis ist keine Erlaubnis, sachfremde lokale Gesprächsaufzeichnungen zu sammeln. Ein Projektplan reicht oft aus, um den nützlichen Aufgabenkontext wiederherzustellen.
Veraltete Pläne und konkurrierende Änderungen vermeiden
Aktualisiere den Plan nach einem Phasenwechsel und benenne den nächsten Schritt mit einem konkreten Verb: prüfen, vergleichen, umsetzen oder verifizieren. Bei einer vagen Anweisung wie „Entwicklung fortsetzen“ muss eine neue Sitzung die Entscheidung erst wieder rekonstruieren.
Wenn mehrere Agenten beitragen, bestimme einen Verantwortlichen für den gemeinsamen Plan. Andere Agenten können über ihre zugewiesenen Dateien oder Nachrichten berichten. So lässt sich eine abgeschlossene Aufgabe leichter mit einem neu entdeckten Fehler abgleichen. Wenn unabhängige Agenten dasselbe Statusdokument umschreiben, können sie versehentlich die Arbeit der anderen verdecken.
Prüfe vor dem Abschluss der Aufgabe die Abnahmekriterien anhand des Ergebnisses. Lass offene Punkte sichtbar. Planning with Files erleichtert das Weiterarbeiten eines Agenten über mehrere Sitzungen hinweg. Dass sein Abschlussskript einen Plan akzeptiert, beweist aber noch nicht die Richtigkeit der Arbeit.
Womit du beginnen kannst
Installiere den Skill für eine Aufgabe, von der du bereits erwartest, dass sie mehrere Sitzungen dauern wird. Beginne mit einem kurzen Ziel, wenigen Phasen und einer überprüfbaren nächsten Aktion. Öffne nach der ersten Sitzung die Dateien selbst und prüfe, ob jemand anderes damit weiterarbeiten könnte. Fehlende Entscheidungen oder vage Statusangaben zeigen dir, was du verbessern solltest, bevor die Aufgabe größer wird.
Für Arbeitsabläufe, bei denen auch Recherchenotizen entstehen, siehe den Obsidian Markdown Skill. Trenne Aufzeichnungen zur Projektdurchführung von persönlichen Referenznotizen, wenn sie unterschiedliche Verantwortliche oder Datenschutzanforderungen haben.
