aigengame/skills

Zustand

Pflegen Sie STATE.md im Repository-Root: einen leichten sitzungsübergreifenden täglichen Bericht, damit der nächste Worker in ~15 Zeilen erfährt, wo das Projekt steht, was die letzte Sitzung getan hat, welche unmittelbaren Erfahrungen wiederverwendet werden können, was als nächstes aufzunehmen ist und welche unerledigten Punkte nicht vergessen werden dürfen. Dies ist die Feedbackschleife, die die Entwicklungserfahrung verstärkt, anstatt den Projektstatus bei jeder Sitzung neu zu entdecken.

STATE.md ist flüchtig („Wo stehen wir jetzt / was als nächstes“, wird jede Sitzung überschrieben) und in sich geschlossen – es ist nicht der Ort für dauerhafte Entscheidungen, Architektur oder ein Glossar und darf diese nicht duplizieren. Es wird lazy erstellt: Wenn es noch nicht existiert, erstellt der erste Lauf es.

Wo das Projekt eine Planungsinstanz (einen Issue-Tracker, Meilensteine) unterhält, besitzt diese Instanz was die Arbeit ist; sie schreibt nicht die Reihenfolge und Art der Ausführung vor – Issues laufen parallel, ein Issue erstreckt sich über mehrere Sitzungen, eingeschobene Arbeit verdrängt geplante Arbeit. STATE.md ist der Bericht des Workers über die Ausführung: Ergebnisse sowie die aktuelle Orchestrierung der verfolgten Arbeit (was als nächstes zu beginnen ist, was unterbrochen und geparkt wurde). Es zeichnet den Ausführungszustand auf; es wird niemals eine zweite Planungsinstanz.

Dieser Skill ist eigenständig und orthogonal zu allem, was ein Projekt sonst noch verwendet (Versionskontrolle, einen Issue-/Task-Tracker, Design-Dokumente). Er geht davon aus, dass solche Tools existieren können, hängt aber von keinem bestimmten ab – lesen Sie, welche Quellen das Projekt hat, überspringen Sie den Rest.

Schreiben Sie sparsam – lassen Sie lieber weg, als in die Irre zu führen. Jeder Inhaltsaufzählungspunkt in der Vorlage ist optional. Das aktualisierte Datum ist erforderlich, wann immer die Datei neu geschrieben wird. Schreiben Sie nur dann eine Inhaltszeile, wenn sie korrekt und für die nächste Sitzung nützlich ist. Wenn ein Wert fehlt, veraltet, unbestätigt oder nicht klar nützlich ist, lassen Sie ihn weg. Eine falsche oder Füllzeile ist schlimmer als eine fehlende. Das Backlog verwendet eine andere Entfernungsregel; befolgen Sie Schritt 4.

Wann ausführen

• Am Ende einer Arbeitssitzung/Wrap-up – Ihre Agenten-Laufzeitumgebung kann dies über einen Sitzungsende-Hook anstoßen, oder Sie führen es selbst aus.
• Auf Abruf, indem Sie den state-Skill mit der expliziten Skill-Syntax des Hosts aufrufen.

Der primäre Worker aktualisiert STATE.md einmal pro Sitzung. Parallele Unteraufgaben und Subagenten aktualisieren es nicht. Diese Regel verhindert gleichzeitige oder doppelte Schreibvorgänge.

No-op-Wächter: Wenn die Sitzung keine wesentliche Arbeit geleistet hat (z. B. eine triviale Q&A-Runde), lassen Sie STATE.md unverändert – aktualisieren Sie höchstens das Datum. Vermeiden Sie es, die Datei mit Nicht-Fortschritt zu füllen.

Arbeitsablauf

1. Sammeln, was diese Sitzung tatsächlich abgeschlossen oder geändert hat. Die primäre Quelle ist die aktuelle Konversation. Wenn das Projekt unterstützende Tools hat, korroborieren Sie leicht (aktuelle Versionskontrollhistorie, den Issue-/Task-Tracker) – behandeln Sie sie als optional, nicht erforderlich.
2. Geben Sie die Makro-Phase nur an, wenn Sie die aktuelle kennen. Tragen Sie nicht standardmäßig die Phase des vorherigen STATE.md weiter – wenn sie sich möglicherweise weiterentwickelt hat oder Sie die aktuelle Phase dieser Sitzung nicht bestätigen können, lassen Sie die Zeile weg, anstatt eine veraltete zu behaupten. (Eine abgeschlossene Phase, die als aktuell geschrieben wird, ist Fehlleitung.) Verwenden Sie die eigenen Begriffe des Projekts.
3. Wählen Sie die empfohlene nächste Arbeit – die offenen Punkte, mit denen eine neue Sitzung beginnen sollte, in Ausführungsreihenfolge. Bewerben Sie Backlog-Elemente hier, wenn sie der richtige nächste Start sind.
4. Gleichen Sie das Backlog ab. Wenden Sie diesen Algorithmus auf unerledigte sitzungsübergreifende Elemente an:
   • Übernehmen durch Filtern. Beginnen Sie mit dem vorherigen Backlog und allen „Next up“-Elementen, die nicht ausgeführt wurden. Entfernen Sie ein Element nur, wenn Beweise zeigen, dass es erledigt, veraltet, für „Next up“ ausgewählt oder im Tracker des Projekts aufgezeichnet ist. Ein Tracker-Verweis ist ein Beweis dafür, dass das Element ein neues Zuhause hat. Überprüfen Sie die Konversation und korroborieren Sie mit dem Tracker, falls vorhanden. Behalten Sie das Element, wenn sein Status unsicher ist.
   • Herabstufen unerledigter Arbeit. Verschieben Sie verlagerte Arbeit nur dann in das Backlog, wenn sie nicht für „Next up“ ausgewählt ist. Arbeit, die in der nächsten Sitzung fortgesetzt werden soll, gehört zu „Next up“.
   • Parken Sie aufgeschobene Arbeit. Fügen Sie ein neu akzeptiertes Element hinzu, wenn es über die nächste Sitzung hinaus verschoben wird und kein anderes Zuhause hat.
   • Geben Sie jedem Element ein Zuhause. Setzen Sie es entweder in „Next up“ oder in das Backlog, niemals beides.
   • Stempeln Sie jedes Backlog-Element. Notieren Sie sein Eintrittsdatum als seit YYYY-MM-DD.
   • Wenden Sie das Fünf-Elemente-Budget an. Wenn das Backlog fünf Elemente überschreitet oder ein Element eindeutig umfangreich ist, verschieben Sie Elemente älteste zuerst in den Tracker des Projekts. Entfernen Sie ein Element erst, nachdem der Tracker einen Verweis bereitstellt. Wenn kein Tracker existiert, behalten Sie jedes Element. Behalten Sie auch jedes Element, wenn kein autorisierter Autor den Tracker-Eintrag erstellen kann. Der sichtbare Überlauf ist das Signal, dass die Elemente noch ein dauerhaftes Zuhause brauchen.
5. Fügen Sie Erfahrung nur hinzu, wenn sie „Next up“ dient. Fügen Sie eine Notiz nur dann ein, wenn die Arbeit dieser Sitzung mit der empfohlenen nächsten Arbeit zusammenhängt oder darauf aufbaut, damit die Notiz tatsächlich wiederverwendet wird. Wenn die nächste Arbeit nicht zusammenhängt, lassen Sie sie weg – Erfahrung, die der nächsten Aufgabe nicht hilft, ist Rauschen, keine Kriegsgeschichten-Sammlung. Wenn das Projekt eine PITFALLS.md hat, bewahren Sie dort dauerhafte Umgebungs-, Tool-, Berechtigungs-, Sandbox- und Tool-Aufruf-Anleitungen auf. STATE.md kann auf einen relevanten Eintrag verweisen; es sollte diesen Eintrag nicht kopieren.
6. Schreiben Sie STATE.md aus der Vorlage neu. Überschreiben Sie die Datei; hängen Sie niemals an. Halten Sie sie auf 15 Zeilen oder weniger. Wenn die No-Loss-Regel in Schritt 4 mehr als fünf Backlog-Elemente hinterlässt, erlauben Sie eine zusätzliche Zeile für jedes zusätzliche Element. Entfernen Sie kein Element, um das Zeilenlimit zu erreichen. Lassen Sie Inhaltsaufzählungspunkte weg, die nicht korrekt und nützlich sind. Geben Sie das gefilterte Backlog als Teil des neuen Snapshots aus. Stempeln Sie das aktualisierte Datum.
7. Führen Sie keinen automatischen Commit durch. Lassen Sie das neu geschriebene STATE.md einfach im Arbeitsbaum. Ob es verfolgt oder als lokales Arbeitshilfsmittel beibehalten wird, ist die Wahl des Projekts – dieser Skill committed es nie.

Vorlage

# STATE — <Projekt>

_Sitzungsübergreifender täglicher Bericht (~15 Zeilen, jede Sitzung überschrieben über den `state`-Skill). Dauerhafte Entscheidungen leben woanders, nicht hier._

- **Phase/Meilenstein:** <aktuelle Phase, in den eigenen Begriffen des Projekts – weglassen, wenn Sie die *aktuelle* nicht bestätigen können>
- **Letzte Sitzung:** <was abgeschlossen/geändert wurde; eine Zeile, z. B. Issue #N>
- **Erfahrung:** <flüchtige Erfahrung, die „Next up“ hilft, oder ein Link zu einem relevanten Eintrag in `PITFALLS.md`; sonst weglassen>
- **Next up:** <empfohlene Elemente, um als NÄCHSTES zu STARTEN, in Ausführungsreihenfolge, z. B. Issue #N>
- **Backlog:** <unerledigte sitzungsübergreifende Übernahme, NICHT für „Next up“ ausgewählt; eine Zeile pro Element>
  - <unterbrochenes oder geparktes Element, verankert an einem Tracker-Verweis (#N), falls vorhanden> _(seit YYYY-MM-DD)_
  - <Element noch nicht im Tracker – ältestes zuerst dorthin verschieben, wenn die Liste überläuft> _(seit YYYY-MM-DD)_

_Aktualisiert: <YYYY-MM-DD>_

(Jeder Inhaltsaufzählungspunkt ist optional. _Aktualisiert ist erforderlich, wann immer die Datei neu geschrieben wird.)

Leitplanken

• Befolgen Sie Schritt 4 für jede Backlog-Änderung. Löschen Sie niemals unerledigte Arbeit, um ein Budget einzuhalten.
• Befolgen Sie Schritt 6 für das Überschreiben und die Zeilenlimits. STATE.md ist ein aktueller Snapshot, kein Verlaufsprotokoll.
• Notieren Sie nur das Delta dieser Sitzung. Das Backlog ist das einzige Feld, das den gefilterten Zustand weiterträgt.
• Halten Sie die Datei in sich geschlossen. Duplizieren Sie keine dauerhaften Entscheidungen oder hängen Sie von einem bestimmten Tracker oder Tool ab.
• Verwenden Sie die etablierte Terminologie des Projekts.