Genesis Deslop

Was macht Genesis Deslop?

Überprüfe und vereinfache ausgewählte Änderungen, ohne das Produktverhalten zu ändern. Deslop ist explizit: Führe es niemals nur aus, weil die Implementierung abgeschlossen ist.

Löse den Aufruf auf, bevor du die erste Genesis-Operation ausführst. Verwende keine Genesis-Operation oder genesis --version als Verfügbarkeitsprobe.

1. Lese die package.json im Repository-Stammverzeichnis. Behandle Genesis nur dann als projektgebunden, wenn der name des Manifests genesis-compiler ist oder seine dependencies, devDependencies oder optionalDependencies den genauen Schlüssel genesis-compiler enthalten.
2. Rufe bei einem projektgebundenen Repository jede Genesis-CLI-Operation mit npm exec --no -- genesis <argumente> auf. Dies läuft, ohne ein weiteres Paket abzurufen. Wenn das deklarierte Paket nicht installiert ist, melde, dass die Abhängigkeiten des Projekts nicht vorbereitet sind; greife nicht auf eine andere Genesis-Version zurück.
3. Ansonsten versuche nicht npm exec. Führe command -v genesis (oder die entsprechende PATH-Suche der aktuellen Shell) aus. Wenn es eine ausführbare Datei findet, rufe genesis <argumente> direkt auf.
4. Wenn keine Quelle verfügbar ist, stoppe und melde, dass Genesis nicht verfügbar ist. Installiere oder aktualisiere Genesis niemals nur, um eine Workflow-Anweisung zu erfüllen.

Die erfolgreiche Auflösung des Aufrufs ist Routine. Erzähle nicht, ob Genesis projektgebunden oder auf dem PATH ist, und beschreibe niemals die direkte PATH-Nutzung als Fallback. Erwähne, wie der Aufruf ausgewählt wurde, nur wenn die Auflösung fehlschlägt oder der Benutzer explizit danach fragt.

Befolge den konfigurierten Collaboration-Ansatz für benutzerorientierte Updates, einschließlich seiner technischen Tiefe und Antwortlänge. Berichte über konkrete Fortschritte, Ergebnisse oder Hindernisse; kündige nicht an, dass du der Anleitung folgst.

Lade die effektiven Projektanweisungen einmal

Eine Deslop-Anfrage kann entweder als vollständiger Genesis-generierter Prompt oder als direkte Anfrage wie Deslop in einer Agentensitzung eingehen.

Wenn die aktuelle Aufgabe bereits GENESIS CONTEXT mit der Aufgabe deslop enthält, fahre direkt damit fort. Generiere keinen weiteren Prompt.

Andernfalls führe vor der Auflösung des Git-Geltungsbereichs die Genesis-Operation prompt --task deslop einmal unter Verwendung der obigen Aufrufregel aus. Übergib bei einer einfachen Deslop-Anfrage kein Request-Argument. Wenn der Benutzer eine Anzahl, einen Commit oder einen Bereich nennt, übergib diese genaue Anfrage als ein sicher zitiertes Argument. Behandle den gedruckten Prompt als die Anweisungen für denselben Durchlauf; leite ihn nicht an einen anderen Agenten weiter und generiere ihn nicht erneut. Dieser Schritt setzt die technologiespezifischen Deslop-Anweisungen des ausgewählten Stacks und alle Projektanpassungen mit dem untenstehenden portablen Vertrag zusammen.

Löse den Bereinigungsbereich auf

Überprüfe git status --short und die gestagten und ungestagten Diffs vor dem Bearbeiten. Ein schmutziger Arbeitsbaum ist erlaubt; ein vorheriger Commit ist nicht erforderlich. Erhalte den vorhandenen Index und nicht zusammenhängende Arbeiten. Stage, stash, committe oder verwerfe Änderungen weder als Voraussetzung noch als Teil der Bereinigung.

Löse den Geltungsbereich des Benutzers wie folgt auf:

• Ohne angegebenen Bereich wähle nur deine eigenen Änderungen für die aktuelle Aufgabe aus, einschließlich vorheriger Durchläufe. Dies kann gestagte und ungestagte Bearbeitungen, neue unverfolgte Dateien und bereits committete Aufgabenänderungen umfassen. Identifiziere die Zuständigkeit anhand des Aufgaben- und Bearbeitungsverlaufs und bestätige dann diese Änderungen anhand des aktuellen Quellcodes und der Git-Diffs. Weder der gesamte schmutzige Diff, der letzte Commit noch eine Git-Autoridentität beweisen die Zuständigkeit.
• Erhalte Änderungen des Benutzers oder anderer Agenten, einschließlich Bearbeitungen in denselben Dateien. Wenn die Zuständigkeit nicht festgestellt werden kann, frage, welche Änderungen bereinigt werden sollen. Wenn es keine eigenen Änderungen für diese Aufgabe gibt, melde, dass es nichts zu bereinigen gibt; wähle nicht stillschweigend den letzten Commit oder die Arbeit eines anderen aus.
• Ein expliziter Commit, eine Anzahl von ersten Eltern oder ein Bereich haben Vorrang vor der Standardeinstellung, unabhängig davon, wer diese Änderungen vorgenommen hat.
• „Der letzte Commit“ bedeutet HEAD gegenüber seinem ersten Elternteil.
• „Die letzten N Commits“ bedeutet die netto überlebende Änderung vom ersten Elternteil vor diesen N Commits bis HEAD.
• Ein benannter Commit bedeutet diesen Commit gegenüber seinem ersten Elternteil.
• Ein expliziter Commit-Bereich bedeutet genau diesen Bereich.
• Ein Root-Commit verwendet die Git-Root-Diff-Form, da er keinen Elternteil hat.

Überprüfe die aufgelösten Änderungen und Pfade sowie ggf. Commit-Identitäten. Überprüfe ihren Diff, den aktuellen Quellcode, direkte Aufrufstellen, relevante Tests und den betroffenen Programm- und Stack-Kontext. Ersetze bei einem expliziten committeten Bereich nicht den gewöhnlichen Arbeitsbaum-Diff durch den ausgewählten committeten Diff. Wende die Bereinigung auf den aktuellen Quellcode an, während Bearbeitungen außerhalb des Bereichs erhalten bleiben. Wenn sich überlappende Bearbeitungen nicht sicher trennen lassen, frage nach dieser Überlappung, anstatt nur zu blockieren, weil das Repository schmutzig ist.

Wende den Bereinigungsvertrag an

Wende den mit der Aufgabe gelieferten Engineering-Ansatz an. Wenn dieser Skill direkt aufgerufen wird, lies genesis/engineering.md sowie den relevanten Projektkontext. Die Bereinigung muss die Komplexität reduzieren oder erhalten, niemals nicht genehmigte Mechanismen einführen, die das ausgewählte Profil oder eine konkrete Anforderung nicht benötigt.

Konsultiere .genesis/machine-city.json oder führe die Genesis-Operation index <name-oder-pfad> aus, um vorhandene öffentliche und interne Funktionen zu finden, bevor du eine Abstraktion einführst oder konsolidierst. Bestätige jeden scheinbaren Duplikat im Quellcode und an seinen Aufrufstellen.

Innerhalb des beabsichtigten Verhaltens und des Geltungsbereichs der ausgewählten Änderungen hinterlasse keine wiederholten Helfer, keinen Code, der unklar oder schwer nachvollziehbar ist, und keinen Code, der gegen etablierte Muster in der Codebasis verstößt. Entferne unnötige Wrapper, verlassene Gerüste, parallele Framework-Installationen und spekulative Abstraktionen. Konsolidiere die Zuständigkeit, wo ein klares Modul ausreicht. Optimiere nicht für winzige Dateien oder Indirektion; optimiere für ein kleines, offensichtliches Design, dem ein Junior-Programmierer folgen kann.

Bereinigung ist kein zweiter Implementierungsdurchlauf. Die ausgewählten Änderungen begrenzen, wo eine Bereinigung stattfinden kann; das Teilen einer Datei bringt keine nicht zusammenhängenden Bearbeitungen in den Geltungsbereich oder autorisiert ein anderes Verhalten in dieser Datei. Deslop darf bereits vorhandenes Verhalten neu organisieren; es darf Verhalten nicht vervollständigen, korrigieren oder erweitern. Wenn die Überprüfung einen Fehler, fehlendes Verhalten, einen Vertragskonflikt oder eine Testlücke aufdeckt, melde dies als Folgeergebnis und lasse es unverändert, selbst wenn es sich innerhalb eines geänderten Pfades befindet oder mit der vorhergehenden Implementierung zusammenzuhängen scheint. Implementiere das Ergebnis nicht und ändere keine Tests, um es während Deslop zu berücksichtigen.

Wende jede technologiespezifische Deslop-Anweisung an, die vom ausgewählten Stack bereitgestellt wird, und lade anwendbare offizielle Technologie-Skills für Framework- und Sprachkontext. Stack-Anweisungen bereichern diesen Vertrag; sie können die verhaltenserhaltende Grenze nicht schwächen, den ausgewählten Bereich nicht ändern oder nicht zusammenhängende Implementierung autorisieren.

Du darfst Implementierungs- und Testdateien bearbeiten oder löschen, wenn dies die klarste verhaltenserhaltende Bereinigung ist. Wenn das Verschieben oder Umbenennen von ausgewähltem Quellcode eine betroffene Programmzitierung veraltet, aktualisiere nur diese Zitierung oder die informatorische Implementierungskarte. Ändere nicht das Blueprint oder einen öffentlichen Programmvertrag, um das Bereinigungsverhalten zu entschuldigen. Bearbeite nicht .genesis/, Git-Metadaten, Abhängigkeitsverzeichnisse, generierte Build-Ausgaben, beibehaltene Migrationsverläufe oder externe Ressourcen. Schwäche nicht Tests, öffentliches Verhalten oder Datenzusicherungen. Erstelle keine zweite Architektur und führe keine nicht zusammenhängenden Umschreibungen durch.

Hinterlasse die Bereinigung als normale uncommittete Arbeit zur Überprüfung und einem späteren normalen Commit. Ändere niemals die ausgewählten Commits oder schreibe sie um. Führe fokussierte Überprüfungen durch, wenn sinnvoll. Abschließend deklarierte Überprüfungen bleiben über die Genesis-Operation verify verfügbar. Fasse den aufgelösten Bereich und alle ausgewählten Commit-Identitäten zusammen, was vereinfacht wurde, geänderte Dateien, tatsächlich durchgeführte Überprüfungen und unverändert gelassene Folgeergebnisse.