Stoppe Geschwätz
Behalte nur das, was der Benutzer aktuell verlangt. Eine Korrektur sollte das Arbeitsziel ändern, nicht zu neuem Inhalt über den alten Fehler werden.
Wähle den leichtesten Modus
- Leichter Modus (Standard): Verwende ihn für gewöhnliche Korrekturen und spätere Ergänzungen. Behalte das Ziel im Arbeitskontext und befolge die untenstehenden Regeln. Erstelle keine flüchtigen Zustände oder andere Arbeitsablauf-Artefakte. Das Lesen dieses Skills oder die Wiederholung des Plans im Chat ist keine Auslieferung; ändere die Dateien.
- Bewachter Modus: Verwende ihn nur, wenn der Benutzer explizit danach fragt, oder wenn dasselbe zurückgezogene Element bereits zurückgekommen ist und der Prüfumfang auf diesen Rest begrenzt werden kann. Lies references/protocol.md, bevor du die Arbeitsergebnisse änderst, initialisiere einmal, dann führe die Prüfung vor der Auslieferung durch.
Wechsle nicht einfach in den bewachten Modus, nur weil die Aufgabe lang ist, Git betrifft oder sich über mehrere Dateien erstreckt. Nach Abschluss dieser Korrektur kehrt die normale Fortsetzung zum leichten Modus zurück. Eine explizite, nicht abgeschlossene Übergabe kann denselben Aufgabenstatus wiederverwenden; schreibe die zurückgezogene Liste nicht in den dauerhaften Speicher.
Erwähne weder „Stop Chatter" noch einen Compliance-Modus oder die Korrekturhistorie im Arbeitsergebnis. Halte die Zusammenfassung des Gesprächsabschlusses sinnvoll: Melde materielle Änderungen, Prüfungen und bekannte Grenzen, wenn der Benutzer sie benötigt, um sich über das Geschehene abzustimmen.
Kompiliere das aktuelle Ziel neu
Nach jeder Korrektur:
- Formuliere das Ziel als das aktuelle positive Ergebnis neu.
- Behalte nur noch aktive Anforderungen. Ein zurückgezogenes Element wird gelöscht, nicht als negative Anforderung beibehalten.
- Trenne Meta-Einschränkungen wie „präzise", „effizient" oder „nicht überentwickeln". Sie gestalten die Ausführung und dürfen nicht zu Titeln, Labels, UI-Texten, Versionsnamen oder dauerhaften Präferenzen werden.
- Behalte explizite Ausnahmen nur, wenn das Fehlen selbst ein aktiver externer Vertrag, eine Sicherheitseigenschaft oder ein Akzeptanzkriterium ist.
Setze dieses neu formulierte Ziel in die Dateien, bevor du Rückstände entfernst. Diese Runde hat etwas nicht erwähnt ≠ es zurückgezogen. Das Zurückziehen eines Elements autorisiert nicht das Entfernen noch aktiver Funktionen oder die Bereinigung des restlichen Projekts. Verwende nach diesem Schritt nicht das rohe Gespräch als fortlaufende Spezifikation.
Was entfernt werden darf
Nur explizit zurückgezogene Inhalte und Ableitungen, die sichtbare Beweise zeigen, dass sie ausschließlich dazu dienen, gelangen in die Bereinigung. Vorhandene Dateien und frühere Bearbeitungen des Benutzers bleiben standardmäßig erhalten. Noch gültige Funktionen, Sicherheitseigenschaften und Kompatibilitätsverträge bleiben bestehen. Wenn die Herkunft einer Datei unklar ist, behalte sie.
Nachdem das primäre Artefakt dem aktuellen Ziel entspricht, suche einmal nach Ableitungen, die ausschließlich dazu dienen, das zurückgezogene Element zu bedienen: Erinnerungs-Changelogs oder Release-Notizen für diese Korrektur, Tests, deren einzige Aufgabe darin besteht, zu beweisen, dass das zurückgezogene Element fehlt, Aufzeichnungen der abgelehnten Option und Dateien, die nach dem zurückgezogenen Feature benannt sind. Dieser Durchlauf ist keine projektsweite Bereinigung.
Frage nur, wenn Mehrdeutigkeit die Auslieferung blockiert. Füge keinen Bestätigungsschritt für jede Datei hinzu.
Füge keinen Test hinzu, der nur eine Korrektur würdigt oder beweisen soll, dass ein nicht angefordertes Element fehlt. Behalte einen negativen Test nur, wenn eine aktive Anforderung dieses Fehlen extern beobachtbar oder sicherheitskritisch macht. Die eigenen Dateioperations-Vertragstests des Prüfers können bleiben.
Verfolge die Dateioperationen dieser Runde
Jede in dieser Runde hinzugefügte oder geänderte Datei muss mindestens einer aktiven Anforderung zugeordnet sein. Die Zuordnung eines Pfads als änderbar autorisiert nicht das Löschen der gesamten Datei. Lösche eine ganze Datei nur, wenn sichtbare Aufgabenbeweise diese Entfernung stützen.
Kommentare erklären nicht offensichtliche Eigenschaften von Code, der noch existiert. PR- und Release-Texte beschreiben den resultierenden positiven Zustand. Die Benutzeroberfläche enthält benutzerseitigen Produktinhalt, niemals interne Anforderungen oder Korrekturhistorie. Füge keine Versionsnummern, Behauptungen unveränderlicher Veröffentlichungen, Hashes oder zusätzliche Zeremonien hinzu, es sei denn, der Benutzer oder der Release-Prozess verlangt sie.
Halte das Gedächtnis sauber
Behandle Korrekturen standardmäßig als aufgabenlokal. Persistiere eine nur, wenn der Benutzer explizit nach dauerhafter Erinnerung fragt oder eine stabile aufgabenübergreifende Präferenz klar angibt. Speichere das positive abstrakte Verhalten und den Umfang, nicht das abgelehnte Beispiel. Scanne nach Bearbeitungen die verbleibenden Dateien – einschließlich des Gedächtnisses – nach dem zurückgezogenen Element und seinen Aliasen in anderen Sprachen oder ähnlichen Namen; entferne diese Spuren nur.
Bewachte Prüfung
Initialisiere im bewachten Modus vor der Änderung der Arbeitsergebnisse. Wenn für diese Wurzel bereits ein gültiger Aufgabenstatus existiert, verwende ihn wieder; überschreibe ihn nicht und setze die Startbasis nicht zurück. Wenn der Status ungültig ist oder zu einer anderen Wurzel gehört, stoppe, anstatt ihn wiederzuverwenden oder zu ersetzen.
python3 <skill-verzeichnis>/scripts/stop_chatter.py init --root .
Ersetze die Vorlagenwerte durch das aktuelle Ziel, die schmalsten Pfade für Hinzufügen/Ändern, die genauen Pfade für must_remove, die durch sichtbare Beweise gestützt werden, zurückgezogene Labels und Aliase sowie Marker für durchgesickerte Meta-Anweisungen. Bearbeite nicht die beim Initialisieren erfasste Basis. Setze ready nur dann auf true, wenn diese Werte aktuell sind. Führe dann einmal die Prüfung durch:
python3 <skill-verzeichnis>/scripts/stop_chatter.py check --root . --cleanup-state-on-pass
Bei Erfolg entfernt derselbe Befehl nur .stop-chatter/state.json. Führe keine zweite erfolgreiche Prüfung oder einen separaten Bereinigungsbefehl aus. Lösche keine Interpreter-Caches, Test-Caches oder andere Benutzerdateien, um den „Zustand zu bereinigen". Bei Fehlschlag bleibt der Zustand erhalten; behebe nur belegte Umfangs- oder Restprobleme und führe dann höchstens einmal erneut aus.
Der Prüfer berichtet nur. Er löscht oder stellt keine Arbeitsergebnisse wieder her und entscheidet nicht über die Produktzuständigkeit. Ein Bestehen bedeutet, dass die konfigurierten Prüfungen bestanden wurden, nicht dass die Implementierung korrekt ist oder nichts mehr übrig ist.
Wenn eine aktive Übergabe den Zustand noch benötigt, lasse --cleanup-state-on-pass weg und entferne die Datei, wenn diese Übergabe endet. Fördere niemals das flüchtige zurückgezogene Hauptbuch in den Speicher.
Für Installationspfade und hostspezifische Aufrufe lies references/host-setup.md nur bei der Installation oder Diagnose der Erkennung.
Liefere das Ergebnis
Stoppe erst, wenn die Dateien dem aktuellen Ziel entsprechen. Gib das angeforderte Artefakt plus genügend Abschlussinformationen zurück, damit der Benutzer materielle Änderungen, Validierung und bekannte Grenzen versteht. Unterdrücke keinen nützlichen Status, nur um die Antwort sauber aussehen zu lassen. Halte das Artefakt selbst in der Sprache des aktuellen Zustands: bezeichne es nicht als korrigierte, saubere, präzise, ohne-X oder Endzustands-Version. Erwähne in der Antwort entfernte Historie, wenn der Benutzer nach einem Prüfpfad fragt oder wenn die Entfernung für den Umfang, die Migration, die Sicherheit oder die Kompatibilität materiell relevant ist.