wshobson/superself

Was macht superself?

Superself ist eine Apache-2.0 CLI (npm install -g [email protected], Node 22.12+), die den Zustand eines Projekts – Ziele, Entscheidungen, Arbeitseinheiten, Berichte – als append-only Event-Log in einem separaten Git-Repository versioniert. Der Zustand wird bei Bedarf abgeleitet, sodass nichts darin manuell gepflegt wird. Dieser Skill weist einen Agenten an, diesen Zustand über die self-CLI zu lesen und zu schreiben. Er wird von den Superself-Autoren gewartet: https://github.com/fxylabs/superself

Wann dieser Skill angewendet wird

• Die AGENTS.md oder CLAUDE.md des Projekts enthält einen Block zwischen <!-- superself:begin und <!-- superself:end -->, oder self setup gibt das Arbeitsverzeichnis, das Projekt und den Store aus, zu dem dieses Verzeichnis aufgelöst wird.
• Überspringen Sie den Skill, wenn self --version fehlschlägt: Das Projekt verwendet Superself nicht, und nichts unten sollte von Hand erfunden werden. Dieser Skill ist für [email protected] geschrieben; eine andere Haupt- oder Nebenversion kann ein Verb oder Flag verschoben haben, überprüfen Sie also self <command> --help, bevor Sie sich auf eines verlassen.

Sitzungsbeginn

1. Führen Sie self context aus und behandeln Sie dessen Ausgabe als aktuelle Wahrheit: das Ziel, die aktiven Entscheidungen und Konventionen, offene Arbeit, aktuelle Berichte. Es wird aus dem Log gefaltet, niemals von Hand geschrieben.
2. Wenn etwas im Kontext fehlt, wurde es absichtlich aus dem gerenderten Satz entfernt; self search <query> findet Live-Einträge, die der Kontext ausgelassen hat, und self work show <id> zeigt die vollständige Kurzbeschreibung und den Berichtsverlauf einer Einheit.

Während der Arbeit

• Substantielle Arbeit wird an eine Arbeitseinheit angehängt. Erstellen Sie eine mit self work add "<erforderliches Ergebnis>" – das Ergebnis ist das, was wahr werden muss, nicht die Aufgabe – dann self work start <id>. start liest die Kurzbeschreibung und zeichnet auf, dass diese Sitzung die Einheit aufgenommen hat; wenn eine andere Sitzung sie hält, sagt die CLI, wer und seit wann, und lehnt nicht ab. Beurteilen Sie und fahren Sie fort.
• Nach dem Commit melden Sie den Fortschritt: self report <id> "<was passiert ist>". Der aktuelle HEAD-Commit wird automatisch als Beleg angehängt; --evidence <commit|note> hängt etwas anderes an, --file <path> hängt eine längere Kurzbeschreibung an.
• Zeichnen Sie eine vom Benutzer bestätigte Entscheidung auf: self decide "<text>" --why "<grund>". Verwenden Sie --proposed, wenn der Benutzer sie nicht bestätigt hat. Eine Entscheidung pro Ereignis.
• Blockiert? self work block <id> --on decision|dependency|external --why "...". Überholt oder verschoben? self work retire <id> --why "..." [--successor <id>]. Markieren Sie eine solche Einheit niemals als erledigt und lassen Sie sie niemals fälschlicherweise blockiert.
• Eine Lücke zwischen einem Ziel und dem aktuellen Zustand gefunden? Schlagen Sie die Arbeit mit self work propose und ihrer Kurzbeschreibung vor; der Benutzer akzeptiert oder lehnt sie ab.
• Der Benutzer hat einen nächsten Schritt oder eine Fortsetzung genehmigt? Registrieren Sie es sofort mit self work add und dem dazugehörigen Kontext. Ein Plan, der nur im Gespräch existiert, ist verloren, wenn das Gespräch endet.

Abschluss

• self work done <id> schließt eine Einheit nur, wenn ein Bericht einen Commit oder ein Artefakt enthält, oder das done selbst angibt, was nachweislich passiert ist: self work done <id> --report "<was nachweislich passiert ist>". Eine bloße Behauptung wird abgelehnt, und deklarierte Kriterien blockieren sie, bis jedes abgedeckt ist.
• Der Text einer Aufzeichnung ist nach Bestätigung unveränderlich. Korrigieren Sie ihn durch erneute Angabe: --supersedes <id> bei jedem Add-Verb zeichnet den neuen Wortlaut auf und behält die Herkunft bei. retract zieht eine Aufzeichnung zurück, ohne sie durch etwas zu ersetzen.

Regeln, die den Zustand vertrauenswürdig halten

• Aufzeichnungen – Ereignisse, Entscheidungen, Berichte, Konventionen – werden auf Englisch geschrieben, damit jeder, der sie als nächstes öffnet, sie lesen kann; antworten Sie der Person in ihrer eigenen Sprache.
• Ein Branch gelangt über einen Pull-Request in den Main: PR-Review und CI kontrollieren den Merge. Superself besitzt den Kontext und den Arbeitsgraphen, nicht das Merge-Gate.
• Bearbeiten Sie niemals generierte Zustandsdateien oder etwas unter .superself/ von Hand.
• Führen Sie in einem Projekt ohne Superself-Block zuerst self setup aus. Wenn es das Verzeichnis zu einem registrierten Projekt auflöst, fragen Sie den Benutzer einmal, ob self connect ausgeführt werden soll, das den verwalteten Block in AGENTS.md oder CLAUDE.md schreibt. Wenn es kein Projekt auflöst, fragen Sie einmal, ob es mit self project init registriert werden soll. Registrieren oder verbinden Sie niemals ein Projekt selbstständig.

Tiefergehend

self --help listet jedes Verb auf; self <command> --help zeigt die Flags eines Befehls ohne den Zustand zu berühren. Themenführungen werden mit der CLI ausgeliefert:

• self help agents – wie eine Sitzung diese CLI steuert, von Anfang bis Ende
• self help context – was self context rendert und warum etwas fehlt
• self help records – eine Entität hinter jeder Aufzeichnungsart und wie eine Aufzeichnung korrigiert wird
• self help placement – Umfang, Priorität und Sichtbarkeit – wie eine Aufzeichnung ihren Platz im Kontext erhält
• self help work – der Arbeitsgraph: Ergebnisse, Belege, Kriterien und Vorschläge
• self help goals – langfristige Ziele, Zielvorgaben, Meilensteine und was es braucht, um eines zu erreichen
• self help workspace – der Store, die darin enthaltenen Projekte und das Verschieben zwischen Rechnern