externer-kausaler-arbeitsbereich

Skill für externen kausalen Arbeitsbereich

Zweck

Diese Skill verwandelt einen Terminal-Agenten in ein deduktives System mit einem externen, überprüfbaren Arbeitsbereich.

Der Agent darf sich bei komplexen Aufgaben nicht wie ein einfacher Textgenerator verhalten. Er muss ein lokales Modell des Problems erstellen und verwalten, bevor er Schlussfolgerungen, Pläne, Patches oder Empfehlungen erstellt.

Ziel ist es, durch Werkzeuggebrauch und expliziten Zustand ein temporäres externes Weltmodell zu approximieren, das aus Objekten, Relationen, Constraints, Kausalitäten, Invarianten, konkurrierenden Hypothesen, Tests, Verifikationsnachweisen, Entscheidungen und Residualunsicherheit besteht.

Dies ist kein neuronaler latenter Raum. Es ist ein praktischer datenträgergestützter Ersatz: ein externer kognitiver Arbeitsbereich, der gelesen, aktualisiert, überprüft, geteilt und auditiert werden kann.

Wann diese Skill verwendet werden soll

Verwenden Sie diese Skill für komplexe oder hochriskante Aufgaben, insbesondere:

• Architekturanalyse;
• Debugging;
• Ursachenanalyse;
• Refactoring;
• Änderungen an mehreren Dateien;
• unklare oder instabile Anforderungen;
• strategische technische Entscheidungen;
• Kausalanalyse;
• leistungskritische Arbeiten;
• sicherheitskritische Arbeiten;
• Aufgaben mit mehreren plausiblen Erklärungen;
• Aufgaben, bei denen eine falsche Antwort zukünftige technische Schulden verursachen kann;
• Aufgaben, bei denen Verifikation, Rückverfolgbarkeit oder Falsifikation wichtig ist.

Verwenden Sie diese Skill nicht übermäßig für:

• triviale Fragen;
• kleine isolierte Änderungen;
• einfache Formatierung;
• direkte faktenbasierte Antworten, die nicht von der lokalen Projektrealität abhängen;
• Aufgaben, bei denen ein vollständiger Arbeitsbereich mehr Rauschen als Wert hinzufügt.

Wenn die Aufgabe einfach ist, antworten Sie direkt und erklären Sie kurz, dass die Skill nicht benötigt wurde.

Zielarbeitsbereich

Der aktive Arbeitsbereich ist das Verzeichnis, aus dem der Agent gestartet wurde, oder das vom Benutzer explizit identifizierte Projektstammverzeichnis.

Der kausale Arbeitsbereich gehört zum Zielprojekt, nicht zum Skill-Verzeichnis.

Verwenden Sie:

<Projektstamm>/.agent/current/

Das Skill-Verzeichnis enthält das Protokoll. Das Projektverzeichnis enthält den Aufgabenstatus.

Der Agent darf aufgabenspezifischen Denkzustand nicht in das Skill-Paket selbst schreiben.

Inspektion des aktuellen Arbeitsbereichs

Bevor der Agent auf eine repository- oder umgebungsspezifische Aufgabe reagiert, inspiziert er nur so viel des aktuellen Arbeitsbereichs wie nötig.

Identifizieren Sie dabei, wenn relevant:

• die Projektstruktur;
• relevante Dateien und Ordner;
• verfügbare Dokumentation;
• Build-, Test- und Validierungsbefehle;
• Einschränkungen durch die vorhandene Architektur;
• vorhandene AGENTS.md, Überschreibungsdatei, lokale Anweisungsdatei oder aufgabenspezifische Anleitung;
• ob .agent/current/ bereits existiert.

Der Agent darf die Architektur nicht aus dem Gedächtnis annehmen, wenn die Aufgabe von der lokalen Projektrealität abhängt.

Semantik eines neuen Durchlaufs

Zu Beginn jeder neuen Aufgabe, die diese Skill verwendet, setzen Sie .agent/current/ im Zielprojekt zurück.

Regeln:

• Wenn .agent/ nicht existiert, erstellen Sie es.
• Wenn .agent/current/ nicht existiert, erstellen Sie es.
• Wenn .agent/current/ bereits von einer vorherigen Aufgabe existiert, löschen oder überschreiben Sie dessen vorherigen Inhalt, bevor Sie die neue Aufgabe beginnen.
• Löschen Sie nicht .agent/notes/, .agent/reports/, .agent/tmp/ oder .agent/archive/, es sei denn, der Benutzer bittet explizit darum.
• Bewahren Sie standardmäßig keinen historischen Zustand auf.
• Wenn der Benutzer explizit bittet, den Verlauf zu bewahren, kopieren Sie das vorherige .agent/current/ nach .agent/archive/<Zeitstempel-oder-Aufgabenname>/, bevor Sie es zurücksetzen.

Der Zweck von .agent/current/ besteht darin, nur die aktuelle Aufgabe darzustellen. Es darf nicht stillschweigend veraltete Schlussfolgerungen aus vorherigen Aufforderungen ansammeln.

Eigentümerschaft des Arbeitsbereichs

Für eine gegebene Aufgabe muss .agent/current/ einen einzigen Schreiber haben.

Erstellen oder überschreiben Sie:

.agent/current/owner.md

owner.md muss angeben:

• Aufgabenname oder kurzes Ziel;
• verantwortlicher Agent oder Rolle, falls bekannt;
• Startzeit, falls verfügbar;
• Status: aktiv, abgeschlossen, teilweise, blockiert oder aufgegeben;
• ob der Arbeitsbereich frisch zurückgesetzt wurde.

Wenn ein anderer aktiver Eigentümer erkannt wird und der Benutzer nicht explizit eine neue Aufgabe gestartet hat, überschreiben Sie nicht stillschweigend. Behandeln Sie den Arbeitsbereich entweder als schreibgeschützt oder geben Sie an, dass ein neuer Durchlauf das Zurücksetzen von .agent/current/ erfordert.

Erforderliche dateibasierte Dateien

Erstellen oder aktualisieren Sie für jede komplexe, mehrdeutige, architektonische, Debug-, Refactoring-, strategische, kausale oder hochriskante Aufgabe mindestens:

.agent/current/owner.md
.agent/current/task.md
.agent/current/world.md
.agent/current/hypotheses.md
.agent/current/claims.md
.agent/current/verification.md
.agent/current/decision.md

Diese Dateien sind keine Dekoration. Sie sind der externe Arbeitsspeicher des Agenten.

Der Agent muss sie während der Aufgabe lesen und aktualisieren. Die endgültige Antwort muss mit .agent/current/decision.md und den beibehaltenen Anspruchsstatus in .agent/current/claims.md konsistent sein. Vor der endgültigen Antwort darf .agent/current/owner.md nicht mehr aktiv sein.

Erforderliche Dateirollen

owner.md

Identifiziert den aktuellen Durchlauf und verhindert versehentliches Überschreiben durch eine andere Aufgabe oder einen anderen Agenten.

Es sollte enthalten:

• aktuelle Aufgabe;
• Eigentümer;
• Modus: direkt, delegiert, erkundend, diagnostisch oder Implementierungsunterstützung;
• Status;
• Zurücksetzungsentscheidung.

task.md

Definiert die Aufgabengrenze.

Es sollte enthalten:

• Benutzerziel;
• interpretiertes Ziel;
• Umfang;
• nicht im Umfang enthalten;
• Einschränkungen;
• Erfolgskriterien;
• explizite Benutzerverbote;
• Annahmen, die noch verifiziert werden müssen.

world.md

Erstellt das lokale Modell des Problems.

Es sollte enthalten:

• Objekte: Komponenten, Dateien, Dienste, Akteure, Konzepte, Datenstrukturen;
• Relationen: Abhängigkeiten, Eigentümerschaft, Datenfluss, Aufruffluss, Lebenszyklus, zeitliche Abfolge;
• Einschränkungen: technische, funktionale, sicherheitsrelevante, architektonische, leistungsbezogene, Kompatibilitätsbeschränkungen;
• Kausalitäten: was erzeugt was, was zerbricht was, was hängt von was ab;
• Invarianten: was nach dem Eingriff wahr bleiben muss;
• Unsicherheitszonen: noch nicht verifizierte Fakten.

hypotheses.md

Verhindert Einzelhypothesen-Denken.

Es sollte konkurrierende Erklärungen oder Lösungspfade enthalten:

| Hypothese | Unterstützt | Widerspricht | Falsifikationstest | Status |
|---|---|---|---|---|
| H1 | ... | ... | ... | beibehalten/abgelehnt/zurückgestellt |
| H2 | ... | ... | ... | beibehalten/abgelehnt/zurückgestellt |

Hypothesen müssen explizit abgelehnt, beibehalten oder zurückgestellt werden.

claims.md

Verhindert Wahrheitsregime-Verwirrung.

Es sollte die wichtigen Behauptungen auflisten, die die Aufgabe materiell beeinflussen, typisiert und mit Status versehen:

| ID | Behauptung | Typ | Quelle / Nachweis | Status | Auswirkung | Notizen |
|---|---|---|---|---|---|---|
| C-001 | ... | Tatsache / Schlussfolgerung / Hypothese / Einschränkung / Invariante / Risiko / Wert / Entscheidung | Datei, Befehl, Benutzeraussage, Werkzeugergebnis, Argumentation | verifiziert / gefolgert / plausibel / zurückgestellt / abgelehnt / nicht geprüft | niedrig / mittel / hoch / kritisch | ... |

Regeln:

• Tatsache erfordert einen Nachweisanker.
• Schlussfolgerung muss die Tatsachen benennen, von denen sie abhängt.
• Hypothese muss bis zur Falsifikation oder Beibehaltung von Tatsachen unterscheidbar bleiben.
• Wert mag das Urteil leiten, darf sich aber nicht als empirischer Beweis ausgeben.
• Entscheidung muss durch beibehaltene Behauptungen gestützt werden und darf nicht stillschweigend von abgelehnten Behauptungen abhängen.

Verwenden Sie nur materiell wichtige Behauptungen. Machen Sie den Arbeitsbereich nicht zu einem ausführlichen Anspruchsdump.

verification.md

Verhindert falsche Verifikation.

Es sollte enthalten:

• tatsächlich ausgeführte Befehle;
• tatsächlich überprüfte Dateien;
• relevante Ausgaben oder Beobachtungen;
• bestandene, fehlgeschlagene, übersprungene oder nicht ausgeführte Prüfungen;
• Verifikationsgrenzen;
• warum eine stärkere Verifikation unmöglich war oder absichtlich übersprungen wurde.

Ein Verifikationsanspruch ist nur gültig, wenn er einen Nachweisanker hat: einen Befehl, eine überprüfte Datei, eine beobachtete Ausgabe, ein Werkzeugergebnis oder einen expliziten Grund, warum eine Verifikation nicht durchgeführt werden konnte.

decision.md

Stabilisiert die Schlussfolgerung vor der endgültigen Antwort.

Es sollte enthalten:

• beibehaltenes Modell;
• abgelehnte Pfade;
• empfohlene Aktion;
• minimaler sicherer nächster Schritt;
• Risiken;
• Verifikationsstatus;
• verbleibende Unsicherheit;
• ob die Implementierung erlaubt ist oder warten sollte.

Kernarbeitsprinzip

Erstellen Sie für jede komplexe Aufgabe zuerst ein lokales Modell des Problems.

Das Modell muss enthalten:

• Objekte;
• Relationen;
• Einschränkungen;
• Kausalitäten;
• Invarianten;
• konkurrierende Hypothesen;
• Unsicherheitszonen;
• Verifikationsmöglichkeiten;
• Anspruchstypen und -status für wichtige Behauptungen.

Testen Sie dann die Hypothesen durch:

• Inversion;
• Widerspruch;
• Randfälle;
• Absurditätsprüfungen;
• Prüfung kausaler Mechanismen;
• ausführbare Verifikation, wann immer möglich und sicher.

Erst nach dieser Stabilisierung darf der Agent eine Antwort, einen Plan, einen Patch oder eine Empfehlung erstellen.

Verbindliche Referenzen

Wenn diese Skill verwendet wird, befolgen Sie diese Protokolldateien aus dem Skill-Paket, wenn relevant:

• references/world-model-workspace.md: wie das externe lokale Modell erstellt und verwaltet wird.
• references/structural-reasoning-protocol.md: invariantenbasiertes Denken, Inversion, Widerspruch, Absurditätstest und Entropiereduktion.
• references/tool-verification-protocol.md: wie Werkzeuge, Tests, Skripte und Terminalbefehle als externe Kognition verwendet werden.
• references/claims-ledger-protocol.md: wie Tatsachen, Hypothesen, Schlussfolgerungen, Werte, Risiken und Entscheidungen getrennt werden.
• references/state-and-memory-protocol.md: wie der Arbeitszustand ohne Projektverschmutzung persistent gemacht wird.
• references/final-response-contract.md: wie Schlussfolgerungen, Änderungen, Grenzen und Residualunsicherheit berichtet werden.

Die Protokolldateien sind Teil der Skill. Die .agent/current/-Dateien sind Teil des Zielprojektarbeitsbereichs.

Standard-Ausführungsschleife

Verwenden Sie für komplexe Aufgaben diese Schleife:

1. Identifizieren Sie das eigentliche Ziel und ob diese Skill erforderlich ist.
2. Inspizieren Sie den Arbeitsbereich nur so viel wie nötig.
3. Setzen Sie .agent/current/ für die neue Aufgabe zurück oder erstellen Sie es.
4. Erstellen Sie owner.md, task.md, world.md, hypotheses.md, claims.md, verification.md und decision.md.
5. Erstellen Sie ein lokales Modell des Problems.
6. Identifizieren Sie Invarianten und Einschränkungen.
7. Zeichnen Sie materiell wichtige Tatsachen, Einschränkungen, Invarianten, Hypothesen, Risiken, Werte und Entscheidungen in claims.md auf.
8. Generieren Sie konkurrierende Hypothesen oder Lösungspfade.
9. Testen Sie sie logisch und, wo möglich, mit Werkzeugen.
10. Zeichnen Sie Nachweise und übersprungene Verifikation in verification.md auf und aktualisieren Sie die betroffenen Anspruchsstatus in claims.md.
11. Eliminieren Sie instabile Hypothesen.
12. Entwerfen Sie die beibehaltene Schlussfolgerung in decision.md nur aus beibehaltenen Behauptungen.
13. Handeln Sie nur innerhalb des validierten Umfangs, wenn Aktionen erlaubt sind.
14. Verifizieren Sie das Ergebnis, wenn eine Änderung vorgenommen wurde.
15. Finalisieren Sie decision.md.
16. Aktualisieren Sie den Status in owner.md auf abgeschlossen, teilweise, blockiert oder aufgegeben.
17. Führen Sie das finale Gate zur Integrität des Arbeitsbereichs durch.
18. Erstellen Sie erst dann die endgültige Antwort.

Verhaltensregeln

• Bevorzugen Sie Struktur vor Improvisation.
• Bevorzugen Sie verifizierte Fakten vor fließenden Annahmen.
• Bevorzugen Sie minimale, reversible Änderungen vor breiten spekulativen Bearbeitungen.
• Ändern Sie keine nicht zusammenhängenden Dateien.
• Verstecken Sie keine Unsicherheit.
• Behaupten Sie nicht, dass Tests bestanden wurden, es sei denn, sie wurden tatsächlich ausgeführt.
• Verwenden Sie Wörter wie verifiziert, validiert, bestätigt, getestet, bestanden, fehlgeschlagen, überprüft oder kontrolliert nur, wenn der Anspruch an einen Nachweisanker gebunden ist.
• Wenn auf statischem Lesen basierend, sagen Sie "gefolgert aus" und nennen Sie die überprüften Dateien.
• Leiten Sie Projektkonventionen nicht ab, wenn sie überprüft werden können.
• Lassen Sie nicht zu, dass veralteter .agent/current/-Inhalt eine neue Aufgabe nach dem Zurücksetzen beeinflusst.
• Lassen Sie nicht zu, dass untypisierte Annahmen in die endgültige Antwort gelangen, wenn sie die Schlussfolgerung materiell beeinflussen.
• Wenn die Aufgabe einfach ist, vermeiden Sie Over-Engineering des Denkprozesses.

Werkzeuggebrauch und Verifikation

Eine reine Sprachantwort ist für konzeptionelle Diskussionen akzeptabel.

Für Implementierung, Debugging, Architekturvalidierung, repositoryspezifische Behauptungen oder umgebungsspezifische Behauptungen bevorzugen Sie:

• Lesen von Dateien;
• Suchen nach Symbolen;
• Überprüfen der Konfiguration;
• Ausführen von Tests;
• Ausführen von Typprüfungen;
• Ausführen von Linters;
• Erstellen von Diffs;
• Verwenden kleiner Skripte;
• Erstellen reproduzierbarer Prüfungen.

Verwenden Sie die stärkste sinnvolle Verifikation, die verfügbar ist, ohne Benutzereinschränkungen zu verletzen.

Wenn ein Befehl destruktiv, produktionsbeeinträchtigend, teuer oder explizit verboten ist, führen Sie ihn nicht aus. Zeichnen Sie die übersprungene Verifikation und den Grund in verification.md auf.

Finales Gate zur Integrität des Arbeitsbereichs

Vor dem Schreiben der endgültigen Antwort MUSS der Agent ein finales Gate zur Integrität des Arbeitsbereichs durchführen.

Dieses Gate ist obligatorisch, wann immer .agent/current/ erstellt wurde.

Der Agent muss erneut öffnen oder überprüfen:

• .agent/current/owner.md
• .agent/current/task.md
• .agent/current/world.md
• .agent/current/hypotheses.md
• .agent/current/claims.md
• .agent/current/verification.md
• .agent/current/decision.md

Die endgültige Antwort ist erst erlaubt, wenn:

1. alle erforderlichen Dateien existieren;
2. .agent/current/owner.md nicht mehr status: aktiv enthält;
3. der Status einer der folgenden ist:
   • abgeschlossen
   • teilweise
   • blockiert
   • aufgegeben
4. .agent/current/decision.md die beibehaltene Schlussfolgerung enthält;
5. .agent/current/verification.md den Verifikationsmodus angibt;
6. der finale Arbeitsbereichs-Trace nur Dateien erwähnt, die tatsächlich existieren.

Wenn die Aufgabe zu einer brauchbaren Schlussfolgerung gelangt ist, verwenden Sie:

status: abgeschlossen

Wenn die Aufgabe nützliche Analyse hervorgebracht hat, die Verifikation jedoch unvollständig ist, verwenden Sie:

status: teilweise

Wenn erforderliche Informationen fehlen, verwenden Sie:

status: blockiert

Der Agent MUSS owner.md als letzten Schreibvorgang im Arbeitsbereich vor der endgültigen Antwort aktualisieren.

Lassen Sie owner.md niemals mit status: aktiv, nachdem die endgültige Antwort erstellt wurde.

Ausgabeerwartungen

Die endgültige Antwort muss prägnant, aber vollständig sein. Sie muss von .agent/current/decision.md abgeleitet sein.

Sie muss, wenn relevant, enthalten:

• was verstanden wurde;
• was überprüft wurde;
• welches

… [für die Übersetzung gekürzt]