SeemSeam/plan-tree

Plan Tree

Verwenden Sie diesen Skill als Planungs-Workflow-Autorität für dauerhafte Projektausrichtung, Ausführungsbereitschaft, Fortschrittszustände und Markdown-Planungsbäume. Er bewahrt die Absicht des Benutzers, den vorhandenen Dokumentenstil, den Argumentationspfad und die Plan-to-Landing-Evidenz über Sitzungen und Agenten hinweg.

Erforderlicher Arbeitsmodus

Bestimmen Sie für jede Plan-Tree-Aufgabe den Arbeitsmodus, bevor Sie Änderungen vornehmen oder implementieren.

• Wenn der Modus unklar ist, standardmäßig klären oder bereitschaftsprüfung verwenden, nicht ausführungsbereit.
• Wenn ein vorhandener Plantree-Zustand verfügbar ist, den relevanten Einstiegspunkt und den aktuellen Planzustand überprüfen, bevor die Richtung geändert wird.
• Bevor eine Lösung reif genug für die Implementierung ist, im Planungs- und Klärungsmodus bleiben. Die Absicht des Benutzers in Ziele, Nicht-Ziele, Einschränkungen, Optionen, Abwägungen, Risiken, Abhängigkeiten, Abnahmekriterien, Verifikationspfad und Rollout- oder Rollback-Hinweise erweitern.
• Nicht mit einer formalen Implementierung in der Hauptprojektfläche beginnen, solange Kernambiguitäten bezüglich Umfang, Ansatz, betroffener Flächen, erwartetem Verhalten, Abnahmekriterien, Verifikationspfad oder Risiken bestehen.
• Ein kleiner isolierter Prototyp oder ein Beispiel ist nur erlaubt, wenn er eine Richtung validiert und klar vom Produktionspfad getrennt bleibt.
• Ein Plan ist nur dann implementierungsbereit, wenn die Ausführung sich nicht auf "Finde es beim Coden heraus" für Kernentscheidungen verlassen sollte.
• Nachdem die Implementierung abgeschlossen ist, den Plantree-Status, die gelandete Evidenz, Entscheidungen, offene Fragen und Übergabenotizen aktualisieren, sodass die Implementierungsprojekte zurück in einen dauerhaften Planzustand überführt werden.

Arbeitsmodi

Wählen Sie zu Beginn einer Aufgabe einen primären Modus, und wechseln Sie nur dann, wenn sich der Zustand ändert.

• klären: Absicht, Umfang, Einschränkungen, Erfolgskriterien oder Abwägungen sind unklar. Diskutieren, bei Bedarf gezielte Fragen stellen und dauerhafte Klärungsergebnisse in Plantree-Dateien festhalten, wenn nützlich. Keine Hauptimplementierungsdateien des Projekts bearbeiten.
• plan-formen: Die Richtung ist weitgehend bekannt, benötigt aber eine konkrete Lösungskarte. Roadmap-Elemente, Themen, Annahmen, Entscheidungen, Risiken, Abnahmekriterien und offene Fragen erstellen oder aktualisieren.
• bereitschaftsprüfung: Der Benutzer möchte implementieren oder fortfahren, aber die Bereitschaft ist unsicher. Bewerten, ob Umfang, Ansatz, betroffene Flächen, Abnahmekriterien, Verifikation und Risiken explizit genug sind. Wenn nicht, zu klären oder plan-formen zurückkehren.
• fortsetzen: Von vorheriger Arbeit fortfahren. Den Root-Einstiegspunkt, die relevante Basislinie, das Zielplan-README, den Implementierungsstatus und nur aktive verknüpfte Dateien lesen. Die aktuelle Phase, das aktive TODO, Blocker, das nächste Ziel und die letzte Verifikation zusammenfassen, bevor Änderungen vorgenommen werden.
• ausführungsbereit: Der Plan ist reif genug für die Implementierung. Projektdateien nur innerhalb des vereinbarten Umfangs ändern, dann den Plantree-Zustand und die Evidenz aktualisieren.
• status-aktualisierung: Roadmap-Status, Implementierungsstatus, "Zuletzt gelandet", "Nächstes Ziel", Blocker, Übergabe oder Plan-Registry nach Arbeit oder Überprüfung aktualisieren.
• archivieren: Überholte Details, alte Status-Snapshots, akzeptierte Evidenz oder referenzbezogenes Material aus aktiven Dateien verschieben, während die Abruflinks erhalten bleiben.
• normalisieren: Einen vorhandenen Planbaum oder überdimensionierte gemischte Quelldateien in kleinere Abrufeinheiten umorganisieren. Zuerst indexes/migration-map.md oder den nächstgelegenen nützlichen Index erstellen oder aktualisieren, dann das Quellmaterial nach Abrufrolle klassifizieren, kurze Kapseln und Detail-Shards für Leseraufgaben erstellen, akzeptierte Verifikation nach evidence/ verschieben und alte Status- oder Argumentationsverläufe nach history/ verschieben, ohne Quellmaterial zu löschen, es sei denn, es wurde ausdrücklich genehmigt.
• prüfen oder migrieren: Konsistenz, Abruffähigkeit, Drift, Legacy-Roots oder Migrationszuordnung überprüfen. Standardmäßig schreibgeschützt, es sei denn, der Benutzer bittet um Reparatur, Normalisierung oder Migration.

Dokumentationsaktionen wie idee, promoten, frage und entscheidung erfolgen innerhalb dieser Modi:

• idee: Einen Gedanken mit geringem Engagement zu ideas/inbox.md oder dem lokalen Äquivalent hinzufügen.
• promoten: Eine Idee in ein Roadmap-Element, ein Thema, eine offene Frage oder eine Entscheidung verschieben und die ursprüngliche Idee verlinken.
• frage: Eine ungelöste Frage hinzufügen, eingrenzen oder auflösen.
• entscheidung: Einen stabilen Entscheidungsdatensatz erstellen oder aktualisieren.

Kernworkflow

Für jede Plan-Tree-Aufgabe:

1. Den Arbeitsmodus und die erlaubte Schreibfläche auswählen: keine, nur Plantree, isolierter Prototyp oder Projektdateien plus Plantree-Update.
2. Die Plantree-Wurzel, die Zielplanwurzel und die Benutzerabsicht identifizieren.
3. Den Root-Index plus nur die relevanten Roadmap-, Status-, Themen-, Entscheidungs-, Frage-, Ideen-, Verlaufs- oder Basisliniendateien lesen.
4. Vorhandene Einstiegspunkte, registrierte Roots, Ordnernamen, Dokumentenstil und Autoritätsreihenfolge beibehalten, es sei denn, die Aufgabe besteht ausdrücklich darin, sie zu reorganisieren.
5. Aktive Roadmap-, Übergabe- und Themenkapseldateien klein halten; Details, Evidenz und Verlauf aus dem aktiven Zustand verschieben.
6. Indizes, Abruf-Header und Links aktualisieren, wenn dauerhafte Dateien hinzugefügt, verschoben, promoted, archiviert oder aufgeteilt werden.
7. Abschließende Prüfungen vor der Antwort durchführen.
8. Geänderte Dateien, ungelöste Fragen, den aktiven Modus und die nächste nützliche Wartungsaktion melden, wenn relevant.

Standard-Dateisystem

Verwenden Sie docs/plantree/ als standardmäßiges, projektübergreifendes Dateisystem für Plantree-verwaltetes Material. Es ist das Plantree-System-Root und die Registry, keine einzelne Planwurzel; der Name vermeidet Kollisionen mit anbietereigenen oder framework-eigenen plans/-Ordnern.

Standardform:

• docs/plantree/README.md: Registry, Autoritätsreihenfolge, Basislinien-Link, Tabelle der aktiven Pläne und Anleitung zum Lesen des Baums.
• docs/plantree/baseline/: Projektweiter Kontext wie Modulkarte, Laufzeitflüsse, Zustands-/Speichergrenzen, Test-/Release-Gates und Risiko-Hotspots.
• docs/plantree/plans/<NNN>-<plan-name>/: Spezifische Planwurzeln mit stabiler numerischer Ordnung, Roadmap/Status, Themen, Entscheidungen, offenen Fragen, Evidenz, Indizes und optionalem Verlauf, wenn das Projekt keine etablierte Namenskonvention hat.
• docs/plantree/ideas/inbox.md: Ideen-Posteingang mit geringem Engagement.

Ermittlungsreihenfolge:

1. Einen expliziten Benutzerpfad verwenden, wenn angegeben.
2. Sonst docs/plantree/ verwenden, wenn docs/plantree/README.md existiert.
3. Sonst einen anderen klar aktiven etablierten Baum für die aktuelle Aufgabe beibehalten; eine Migration nur bewerten, wenn der Benutzer bittet, ihn zu übernehmen, zu normalisieren oder zu migrieren.
4. Sonst docs/plantree/ starten, bevor ein Plan erstellt oder aktualisiert wird.

Neue spezifische Pläne standardmäßig in docs/plantree/plans/<NNN>-<plan-name>/, wenn keine lokale Konvention existiert, müssen in docs/plantree/README.md registriert werden und sollten auf die relevanten Basisliniendateien verlinken, anstatt globalen Kontext zu kopieren. Etablierte, nicht nummerierte oder anders organisierte Bäume beibehalten, es sei denn, der Benutzer genehmigt ausdrücklich eine Migration.

Erste Verwendung

Wenn eine Plan-Tree-Aufgabe in einem Projekt ohne docs/plantree/ aufgerufen wird, eine minimale Wurzel erstellen, es sei denn, der Benutzer bittet ausdrücklich darum, keine Dateien zu erstellen.

Start:

• Wurzel: docs/plantree/README.md
• Basislinie: baseline/README.md, module-map.md, runtime-flows.md, storage-and-state.md, test-and-release-gates.md, risk-hotspots.md
• Container: plans/, ideas/inbox.md

Startinhalt leichtgewichtig und evidenzbasiert halten. Wenn nicht genügend Code überprüft wurde, Unbekannt / Inventar erforderlich schreiben, anstatt Projekttatsachen zu erfinden. Bei alten oder unbekannten Projekten die Basislinie aufbauen oder aktualisieren, bevor ein detaillierter Plan erstellt wird.

Planmodell

Diese Rollen beim Erstellen oder Verwalten einer Planwurzel verwenden, die Namen an die lokale Konvention anpassen:

• README.md: Umfang, Autorität, Dateizuordnung, Lesepfad und aktive Registry, wenn es die Plantree-Wurzel ist. Für aktive Plantabellen ID | Plan | Betroffene Module | Status | Aktuelle Phase | Zuletzt gelandet | Nächstes Ziel bevorzugen, wenn leichte IDs verwendet werden.
• roadmap.md: Dauerhafter Zustand, gruppiert als Erledigt, In Bearbeitung, Als nächstes und Zurückgestellt, es sei denn, der Baum verwendet bereits ein anderes Modell.
• implementation-status.md: Kurze operative Übergabe nur für In Bearbeitung befindliche Pläne. Planungs- oder zurückgestellte Pläne benötigen diese Datei normalerweise nicht.
• open-questions.md: Nur ungelöste Fragen.
• topics/: Dauerhafter Kontext, Lösungspläne, Optionen, Einschränkungen, Abnahmekriterien, Implementierungshinweise, Repository-Hygienepläne und Risikoanalyse. Themenkapseln auf oberster Ebene kurz halten; große Themen in Themenordner mit Detail-Shards aufteilen.
• decisions/: Stabile Entscheidungen, indiziert, wenn die Menge wächst.
• evidence/: Aktuelle oder akzeptierte Verifikationsdatensätze, Überprüfungsergebnisse, Artefaktnotizen und Evidenzindizes, wenn diese unabhängig vom Verlauf abgerufen werden müssen.
• history/: Akzeptierte Checkpunkt-Protokolle, alte Überprüfungen, zurückgezogene Snapshots, Archiv-Only-Quellnotizen und überholte Details.
• indexes/: Optionale Abrufkarten wie Phasenkarten, Themenkarten, Autoritätskarten, Migrationskarten und Evidenzkarten, wenn lokale Indizes ein Navigationsproblem lösen.
• ideas/: Optionaler Ideenpool mit geringem Engagement, wenn Ideen auf Wurzelebene nicht spezifisch genug sind.

references/maintenance-patterns.md lesen, wenn Vorlagen erstellt, große Bäume verwaltet, Entscheidungs-/Status-/Übergabe-/Verlaufs-/Indexdateien verwaltet, Repository-Hygienepläne hinzugefügt werden oder die detaillierte Checkliste für die abschließende Prüfung benötigt wird.

Leichte IDs und Modulklassifikation

Wenn ein Projekt keine etablierte Plan-Namenskonvention hat, leichte IDs verwenden, um die Dateisystemdurchsuchung und dauerhafte Referenzen zu verbessern, ohne eine Aufgabendatenbank zu erstellen:

• Plan-IDs projektweit als P001, P002 usw. zuweisen. P001 auf eine flache Wurzel wie docs/plantree/plans/001-authentication/ abbilden.
• Festbreite dreistellige Dezimalzahlen verwenden. Die maximal beibehaltene Plannummer plus eins zuweisen; niemals eine ID wiederverwenden, Lücken durch Umnummerierung schließen oder Priorität, Status, Modul, Besitzer, Worker, Phase oder Datum kodieren.
• Den semantischen Slug stabil und in Kleinbuchstaben mit Bindestrichen halten. Ein Titel oder betroffenes Modul kann sich ändern, ohne die Plan-ID oder das Verzeichnis zu ändern.
• Solange die Plan-Registry klein ist, Identität und Lebenszyklusregistrierung in docs/plantree/README.md behalten. Nur in einen Index aufteilen, wenn dies die Abruffähigkeit verbessert; kein paralleles Zuordnungsbuch standardmäßig führen.
• Roadmap-Aufgaben-IDs wie T001 sind optional und Plan-lokal. Sie nur verwenden, wenn stabile dateiübergreifende Referenzen helfen. Wenn vorhanden, ist roadmap.md die alleinige aktive Autorität für Aufgabenidentität, Status und Reihenfolge; kein separates Aufgabenregister oder Aufgabenordner standardmäßig erstellen.
• Entscheidungsdateinamen können die Konvention 001-<decision>.md beibehalten. Offene Fragen können Q001 verwenden, wenn dauerhafte Referenzen helfen. Ideen bleiben bis zur Promotion unnummeriert.
• Code- oder Produktmodule als Plan-Metadaten wie Betroffene Module behandeln, unter Verwendung stabiler Schlüssel, die in baseline/module-map.md definiert sind. Planwurzeln standardmäßig flach halten; Modulindizes oder physische Modulverzeichnisse nur nach nachgewiesenem Navigationsbedarf und einer dokumentierten Entscheidung hinzufügen.
• Konsistenz gleicher Änderung anwenden: Die autoritative Datei und alle erforderlichen Einstiegspunktzusammenfassungen in einem Wartungsdurchgang aktualisieren, dann IDs, Pfade, Modulschlüssel, Roadmap-Eindeutigkeit, Statusbehauptungen und relative Links vor dem Abschluss überprüfen.
• Schreibgeschützte Drifterkennung gegenüber automatischer Reparatur bevorzugen. Keine Überwacher, automatische Umnummerierung, Zuordnungssperren oder Wiederherstellungsjournale hinzufügen, bis beobachtete Koordinationsfehler deren Kosten rechtfertigen.

Diese Standardeinstellungen sind progressiv. Einen ausgereiften Baum mit lokalen ID-, Issue-, Ticket- oder Ordnerkonventionen beibehalten, anstatt einen konkurrierenden Namensraum darüber zu legen.

Dynamischer Status und Evidenz

• Nur In Bearbeitung befindliche Pläne benötigen implementation-status.md; Planung-Pläne sollten die Bereitschaft in roadmap.md, Themen, offenen Fragen oder Entscheidungen ausdrücken.
• implementation-status.md operativ und kurz halten. Unter 100 Zeilen bevorzugen; wenn es wächst, alte Details archivieren oder indizieren.
• Aktives TODO auf höchstens fünf aktuelle Elemente begrenzen. Mehr Elemente bedeuten normalerweise, dass die Arbeit eine Roadmap-Phase, ein Thema oder eine Aufteilung benötigt.
• Wenn Roadmap-Aufgaben-IDs verwendet werden, diese IDs im Aktives TODO wiederverwenden, anstatt die Aufgabenidentität in einem zweiten Register neu zu formulieren.
• Konkrete Aktuelle Phase, Nächstes Ziel, Zuletzt gelandet, Aktives TODO, Blockiert durch und Zuletzt verifiziert oder Übergabenotizen einfügen, wenn zutreffend.
• Zuletzt gelandet sollte auf einen Commit, ein Artefakt, ein Testergebnis, einen akzeptierten Checkpunkt oder andere Evidenz mit einem Datum verweisen, wenn verfügbar.
• evidence/README.md, indexes/evidence-map.md oder das lokale Äquivalent für Phasen-/Paket-/Gate-Evidenz verwenden. history/evidence-index.md nur für überholte Evidenzarchive verwenden. Nicht jeden kleinen Schritt dort aufzeichnen.
• Aktive Roadmap-/Statusdateien sollten auf alte Evidenz verlinken, nicht wiederholte Protokolle, alte Automatisierungsausgaben, Überprüfungsaufgabendetails oder historische Erzählungen absorbieren.

Abfragemodell

Plantree ist ein System von Abfrageeinheiten, kein Ort, um große Sammeldokumente zu erstellen. Jede dauerhafte Datei sollte eine primäre Rolle haben:

• Einstiegspunkt oder Index: Routing, Autoritätsreihenfolge, Lesepfade und einzeilige Zusammenfassungen.
• Aktueller Zustand: Aktive Roadmap, aktuelle Phase, Blocker, nächstes Ziel und Übergabe.
• Themenkapsel: Eine kurze Zusammenfassung einer Domäne, Funktion, Einschränkungsmenge oder eines Arbeitsstroms mit Links zu Detail-Shards.
• Detail-Shard: Verträge, Alternativen, Randfälle, Implementierungshinweise, Rollout, Betrieb, Bereitschaft oder Repository-Hygienedetails für eine Leseraufgabe.
• Entscheidung: Eine stabile Wahl mit Kontext und Konsequenzen.
• Evidenz: Verifikationsdatensätze, Überprüfungsergebnisse, Artefaktlinks, akzeptierte Testzusammenfassungen oder Evidenzindizes.
• Verlauf/Archiv: Überholter Status, alte Ausführungsprotokolle, migriertes Quellmaterial und zurückgezogene Details.

Eine Datei nicht gleichzeitig Zusammenfassung, aktiven Zustand, Entscheidungen, lange Argumentationen, Protokolle, Evidenz und Verlauf tragen lassen. Wenn ein Update eine Datei ihre Rollengrenze überschreiten lassen würde, zuerst eine verknüpfte Abfrageeinheit erstellen oder aktualisieren, dann nur die prägnante Zusammenfassung und Links in der aktiven Datei belassen.

Diese Zeilenanzahlen als Aufteilungstrigger verwenden, nicht als harte Korrektheitstests:

• Root-README, Plan-README, Roadmap und Implementierungsstatus: Nahe 150 Zeilen oder weniger halten.
• Themenkapsel: Nahe 250 Zeilen oder weniger halten.
• Gewöhnlicher Detail-Shard: Um 400 Zeilen aufteilen oder indizieren.
• Verlaufs- oder Evidenzdateien: Um 500 Zeilen indizieren oder aufteilen.

Beim Aufteilen