Was macht Terminal Ops?
Verwende dies, wenn der Benutzer eine echte Repo-Ausführung wünscht: Befehle ausführen, Git-Status prüfen, CI oder Builds debuggen, einen engen Fix durchführen und genau berichten, was geändert und verifiziert wurde.
Dieses Skill ist bewusst enger gefasst als allgemeine Programmieranleitungen. Es ist ein Operator-Workflow für evidenzbasierte Terminalausführung.
Skill-Stack
Ziehe diese ECC-nativen Skills bei Bedarf in den Workflow ein:
verification-loopfür genaue Beweisschritte nach Änderungentdd-workflowwenn der richtige Fix eine Regressionstestabdeckung benötigtsecurity-reviewwenn Geheimnisse, Authentifizierung oder externe Eingaben involviert sindgithub-opswenn die Aufgabe von CI-Läufen, PR-Zustand oder Release-Status abhängtknowledge-opswenn das verifizierte Ergebnis für den dauerhaften Projektkontext erfasst werden muss
Wann verwenden
- Benutzer sagt "fix", "debug", "führe dies aus", "überprüfe das Repo" oder "push es"
- die Aufgabe hängt von Befehlsergebnissen, Git-Status, Testergebnissen oder einem verifizierten lokalen Fix ab
- die Antwort muss unterscheiden zwischen lokal geändert, lokal verifiziert, committet und gepusht
Schutzmaßnahmen
- Prüfe vor dem Bearbeiten
- Bleibe schreibgeschützt, wenn der Benutzer nur eine Überprüfung/Review wünscht
- Bevorzuge repo-lokale Skripte und Helfer gegenüber improvisierten Ad-hoc-Wrappern
- Behaupte nicht "gefixt" zu haben, bis der Beweisbefehl erneut ausgeführt wurde
- Behaupte nicht "gepusht" zu haben, es sei denn, der Branch wurde tatsächlich auf dem Server aktualisiert
Ablauf
1. Arbeitsfläche ermitteln
Kläre:
- genauen Repo-Pfad
- Branch
- lokalen Diff-Status
- gewünschten Modus:
- inspizieren
- fixen
- verifizieren
- pushen
2. Zuerst die fehlschlagende Fläche lesen
Bevor etwas geändert wird:
- den Fehler inspizieren
- die Datei oder den Test inspizieren
- den Git-Status inspizieren
- bereits gelieferte Logs oder Kontext verwenden, bevor blind erneut gelesen wird
3. Den Fix eng halten
Löse ein dominantes Fehlschlagen nach dem anderen:
- verwende zuerst den kleinsten nützlichen Beweisbefehl
- eskaliere nur zu einem größeren Build/Test-Durchlauf, nachdem der lokale Fehler behoben ist
- wenn ein Befehl immer wieder mit derselben Signatur fehlschlägt, beende breite Wiederholungen und verenge den Umfang
4. Exakten Ausführungszustand melden
Verwende exakte Statuswörter:
- inspiziert
- lokal geändert
- lokal verifiziert
- committet
- gepusht
- blockiert
Ausgabeformat
FLÄCHE
- Repo
- Branch
- angeforderter Modus
BEWEIS
- fehlschlagender Befehl / Diff / Test
AKTION
- was geändert wurde
STATUS
- inspiziert / lokal geändert / lokal verifiziert / committet / gepusht / blockiert
Fallstricke
- Arbeite nicht mit veraltetem Speicher, wenn der Live-Repo-Status gelesen werden kann
- Weite einen engen Fix nicht zu einer repo-weiten Änderung aus
- Verwende keine destruktiven Git-Befehle
- Ignoriere nicht die nicht zusammenhängende lokale Arbeit
Verifikation
- Die Antwort benennt den Beweisbefehl oder -test
- Git-bezogene Arbeit nennt den Repo-Pfad und den Branch
- Jede Push-Behauptung enthält den Ziel-Branch und das genaue Ergebnis