xallindrome-labs/claude-code-ops

/runway

Ziel: Jede Frage wird jetzt gestellt, sodass bei Turn 40 nichts mehr gefragt werden muss. Danach genehmigt der Benutzer einen Plan und geht; sein Telefon wird nur bei Stop-Punkten kontaktiert.

Grundregeln (der Benutzer kann eigene in CLAUDE.md haben; diese gewinnen):

• Lokale und umkehrbare Arbeiten (Bearbeitungen, Builds, Tests, lokale Befehle, Commits auf einem Branch oder Worktree) laufen ohne Nachfrage.
• Immer anhalten für: Push oder Deploy, Senden einer Nachricht, Absenden einer Bewerbung, Geld ausgeben, Daten löschen, etwas Öffentliches veröffentlichen.
• Verwenden Sie günstigere Subagenten-Modelle für umfangreiche Arbeiten (Suchen, Testläufe, Log-Auswertung); das Top-Modell nur für Design und schwieriges Debugging.

0. Preflight (still, keine Fragen)

• Finden Sie das Repo-Root und seinen Zustand: git status, aktueller Branch, eine vorhandene SPEC.md, Test- und Build-Skripte (package.json, Makefile usw.). Fakten zu finden ist Ihre Aufgabe, nicht die des Benutzers.
• Prüfen Sie, ob Telefonfreigaben aktiv sind. Sie sind aktiv, wenn entweder ~/.claude/settings.json einen PermissionRequest-Hook mit phone-approve.js ausführt oder der Hook dieses Plugins aktiviert ist und ~/.claude/phone-approve.json existiert. Falls nicht, teilen Sie dies dem Benutzer einmal mit (Einrichtung: node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init ausführen, dann die ntfy-App für das in dieser Datei enthaltene Request-Thema abonnieren) und fahren Sie fort; Stop-Punkte fallen dann auf den Desktop-Dialog zurück.
• Stellen Sie sicher, dass Stop-Punkt-Befehle gezwungen sind, eine Eingabeaufforderung zu zeigen, da der Auto-Modus sie sonst ohne Telefonkontakt genehmigen könnte. Überprüfen Sie die Benutzer-, Projekt- und lokalen Einstellungen auf permissions.ask- (oder deny)-Regeln, die git push, die Deploy-Befehle dieses Repos (vercel, aws s3 sync, cdk deploy, npm publish, gh release, gh pr merge) und Löschbefehle (rm -r, git clean, git branch -D) abdecken. Wenn Regeln fehlen, schlagen Sie die spezifischen vor, zeigen Sie den Diff und fügen Sie sie nur hinzu, wenn der Benutzer zustimmt (das examples/permissions-ask.json des Plugins ist ein Ausgangspunkt). Fügen Sie niemals allow-Regeln für Senden-, Veröffentlichen- oder Deploy-Tools hinzu, und niemals Bash(*).

1. Interview, bis das Pflichtenheft vollständig ist

Wenn ein grilling- oder grill-me-Skill installiert ist, rufen Sie es auf und lassen Sie es auf diesem Feature laufen; dessen Regeln gelten vollständig. Wenn nicht, führen Sie das Interview selbst wie folgt durch: Fragen Sie in Runden; jede Runde enthält jede Frage, deren Voraussetzungen bereits geklärt sind, jede nummeriert, jede mit Ihrer empfohlenen Antwort, die so formuliert ist, dass „Ja“ sie akzeptiert. Warten Sie auf die Antworten, berechnen Sie neu, was jetzt fragbar ist, und wiederholen Sie. Schlagen Sie Umgebungsfakten selbst nach (verwenden Sie einen Subagenten für umfangreiche Suchen) und fragen Sie den Benutzer niemals nach etwas, das Sie selbst herausfinden können. Entscheidungen liegen beim Benutzer.

Wenn der Benutzer bereits früher im Gespräch eine Grilling-Sitzung zu diesem Feature durchgeführt und das gemeinsame Verständnis bestätigt hat, wiederholen Sie diese nicht: Verwenden Sie die Antworten erneut und fragen Sie nur nach Punkten der Checkliste, die noch offen sind.

Fahren Sie fort, bis nichts mehr von Folgendem offen ist:

1. Ziel: ein oder zwei Sätze, das für den Benutzer sichtbare Ergebnis.
2. Umfang: was sich ändern wird (Bereiche, Dateien, Oberflächen).
3. Nicht im Umfang: was nicht berührt werden darf.
4. Akzeptanzkriterien: eine Checkliste, bei der jedes Element durch Befehlsausgabe als wahr erwiesen werden kann.
5. Verifikationsbefehl: genau ein Befehl, dessen Exit-Code 0 „erledigt“ bedeutet (z. B. npm run lint && npm test && npm run build). Wenn keiner existiert, enthält das Pflichtenheft dessen Erstellung als erste Aufgabe.
6. Stop-Punkte: welche von Push / Deploy / Senden / Absenden / Ausgeben / Löschen / Veröffentlichen dieses Feature treffen wird und was der Benutzer an jedem erwartet (z. B. „Branch pushen, PR öffnen, nicht mergen“).
7. Entscheidungen, die Sie sonst während der Aufgabe treffen würden: Bibliotheken, Benennungen, Datenstrukturen, Texte, Verhalten an Grenzfällen. Fragen Sie jetzt, mit einer Empfehlung.
8. Turn-Limit (Standard 60) und etwaige Budgetbedenken.

Gehen Sie nicht weiter, bis der Benutzer das gemeinsame Verständnis bestätigt.

2. SPEC.md schreiben und lokal committen

Schreiben Sie SPEC.md im Repo-Root:

# <Feature-Name>
## Ziel
## Umfang
## Nicht im Umfang
## Akzeptanzkriterien
- [ ] ...
## Verifikationsbefehl
`<ein Befehl>`
## Stop-Punkte
| Aktion | Erwartete Handhabung |
## Bereits getroffene Entscheidungen
## Turn-Limit
60

Erstellen Sie einen Branch (git switch -c runway/<slug>) oder verwenden Sie einen Worktree, wenn andere Sitzungen dasselbe Verzeichnis bearbeiten, und committen Sie nur SPEC.md. Dies ist lokal und umkehrbar; nicht fragen. Niemals pushen.

3. Eine einzige Planfreigabe

Wechseln Sie in den Plan-Modus und präsentieren Sie einen einzigen Plan: geordnete Schritte, welche Schritte an Subagenten gehen (und mit welchem Modell), der Verifikationsbefehl und die Stop-Punkte mit ihrer erwarteten Handhabung. Dies ist die einzige Freigabe vor dem Lauf. Verlassen Sie den Plan-Modus und bitten Sie den Benutzer, „Ja, und Auto-Modus verwenden“ zu wählen. (Der Telefon-Hook überspringt absichtlich die Planfreigabe, sodass der Benutzer dies am Computer tut.)

Wenn der Auto-Modus nach der Freigabe nicht aktiv ist, sagen Sie dies und bitten Sie den Benutzer, umzuschalten. Führen Sie die Schleife nicht im manuellen Modus aus.

4. Unter /goal mit einem Turn-Limit ausführen

Eingebaute Slash-Befehle können nicht vom Modell aufgerufen werden. Beenden Sie daher den vorherigen Schritt, indem Sie dem Benutzer eine Zeile zum Einfügen geben (füllen Sie den echten Befehl und das Limit ein):

/goal <Verifikationsbefehl> gibt 0 zurück, jedes Akzeptanzkriterium in SPEC.md ist mit Nachweis im Transkript abgehakt, und nichts in der Nicht-im-Umfang-Liste von SPEC.md wurde berührt, oder stoppen Sie nach 60 Turns

Wenn die Sitzung bereits ein Ziel ausführt, ersetzt /goal es. Der Evaluator sieht nur das Transkript. Führen Sie daher während der Arbeit den Verifikationsbefehl häufig aus, geben Sie sein Ergebnis aus und haken Sie SPEC.md-Kriterien mit Nachweisen ab. Melden Sie den Fortschritt in Bezug auf das Turn-Limit in jedem Turn.

Während der Ausführung:

• Stellen Sie keine Fragen. Wenn etwas Unbestimmtes auftaucht, wählen Sie die Option, die dem Pflichtenheft am nächsten kommt, notieren Sie sie unter „Bereits getroffene Entscheidungen“ und fahren Sie fort. Halten Sie nur für eine Frage an, wenn das Fortfahren einen Stop-Punkt treffen oder dem Pflichtenheft widersprechen würde.
• Committen Sie Arbeiten in kleinen Commits auf dem Runway-Branch. Pushen Sie niemals ohne eine Stop-Punkt-Freigabe.
• Führen Sie an einem Stop-Punkt den Anruf normal durch; die Berechtigungsabfrage ist das, was das Telefon kontaktiert. Wenn sie verweigert wird, versuchen Sie keinen anderen Weg: Notieren Sie es, beenden Sie, was es nicht benötigt, und berichten Sie.
• Wenn 3 aufeinanderfolgende Turns keine Fortschritte machen, halten Sie an und berichten, was Sie blockiert hat.

5. Abschluss

Wenn die Verifikation bestanden ist (oder das Limit erreicht wurde), berichten Sie in dieser Reihenfolge:

1. Ergebnis: erledigt / teilweise erledigt / blockiert, plus der Branch und ein etwaiger PR-Link.
2. Diff-Statistiken (git diff --stat <Basis>...HEAD).
3. Verifiziert: nachgewiesene Kriterien, mit Befehl und Ergebnis.
4. Nicht verifiziert: nicht oder nur teilweise nachgewiesene Kriterien; alles, was an einem Stop-Punkt übersprungen oder verweigert wurde.
5. Verwendete Subagenten, auf welchem Modell und wo ein kleineres Modell schlechter abgeschnitten hat.
6. Turns und ungefähre Kosten im Verhältnis zum Limit.